CSE 403 Project 3: Architecture and Implementation Plan
The goal of this assignment is to think about and document your software's
architecture, and also to revise your project proposal and plan.
Like all project assignments for this class, this submission should build on
your previous one (in this case, the project proposal).
You will revise the same document that you are submitting now,
and it will eventually become your final project report.
This submission should satisfy all the requirements of
the the project proposal, except that the
length restriction is lifted. (Please don't write more than is necessary.)
This submission must address all the feedback your team has
received so far.
You are allowed to change the topic of your project, but that requires a
meeting with the instructor well in advance of the deadline.
Just as in a real software project, after this point you are not allowed to
make significant changes to your project (goals, methodology, etc.) without
management and customer approval. Request those of the staff in writing.
Commit, to the
a single PDF named
report.pdf. Submit the same
document via Canvas.
Your document should include:
- An architecture diagram showing the major components and how they relate
to one another, with explanatory text.
- If your software will have a graphical user interface, include a mockup.
- If your software does not have a GUI, clearly explain how the user interacts with it, and how it
interacts with the larger system it lives within.
- If your system provides APIs (say, for extension), fully document them.
- If you are extending an existing system, explain that system's
architecture (sufficiently to understand how your component fits in)
and describe whether your changes will affect the architecture.
- Discuss the technologies (tools, APIs, etc.) that you plan to use.
As with other aspects of your project, you are allowed to change this
in the future with staff approval, but you should already have a
concrete plan, and a justification for it, now.
Indicate which parts of your system each individual on your team will
be responsible for. We recommend that you split your team into two
sub-teams, one to focus on evaluation and for implementation.
Evaluation is as important for your project as implementation, and it
requires imaginative design and implementation.
As always, you should write a single, coherent document. Don't just
append new information to the end of your existing document, but
integrate it in sensible locations.
Your team will act as another team's customer.
Peer review rubric
- (1pt) The document builds on the original project proposal
- (1pt) There is an architecture diagram
- (1pt) The architecture diagram is explained in English
- (1pt) The system's interface is documented. (For graphical interfaces, a UI mockup should be included. For command-line interfaces, the document should explain how a user interacts with it. For components of larger systems, the document should explain how the component interacts with the system around it.)
- (1pt) The document contains discussion of tools and APIs that the team plans to use