Project report #2
The content of your intermediate reports will depend on your selected development methodology and on the milestones you laid out in your project plan. Remember that their purpose is to provide visibility to the client and demonstrate whether or not your project is on track. To that extent, these reports should always address the status of any milestones whose target dates have passed and include updates to the project plan if changes are required. They should also include or account for any deliverables ready by the report deadline (including summaries and takeaways from client demos). For heavyweight methodologies, these reports may be a natural place to request client approval of gating deliverables.
Here are some recommended elements to include in your second report for methodologies commonly used by CS 5150 projects:
- Modified waterfall
- Formal requirements document, including supporting documentation (e.g. scenarios)
For examples of formal requirements documents, see the optional reading from Lecture 6. - Iterative refinement
- First draft of requirements, provisional design, demo of first prototype
- Agile
- Collection of user stories, system-level design, first sprint plan
Additionally, your second report must document the architecture of the pre-existing system you are enhancing. This documentation should include:
- Deployment diagrams for client deployments (may include production deployments, staging areas, and/or acceptance test setups)
- Component diagrams showing which services/components/subsystems you expect to be interfacing with or modifying in order to implement your enhancements
You may find that architecture documentation and diagrams already exist for your host application. You should of course reference these, but what you submit with your report must be your own work taylored to this semester’s project.