Project report #2

As with report #1, the content of your intermediate reports will depend on your selected development methodology and on the milestones you laid out in your project plan (and any updates you have made to it). Remember that their purpose is to provide visibility to the client and demonstrate whether or not your project is on track. While the report is mostly open-ended, you should consider including the following elements in your second report:

• Status of any milestones whose target dates have passed, along with updates to the project plan (especially schedule and risk) if changes are required. Be sure to include explanations for any missed milestones and a clear plan for how you will get back on track. If you have achieved your milestones, be sure to include evidence of this (e.g., links to code commits, documentation, client feedback, etc.).
• Deliverables ready by the report deadline (including summaries and takeaways from client demos). Be sure to include evidence of these deliverables (e.g., links to code commits, documentation, client feedback, etc.). For heavyweight methodologies, you should also include evidence of client approval of gating deliverables (be sure to request such approval explicitly in separate communication with your client).
• Code information: If you have started development, you should include information about the code you have written so far, including links to your code repository and any relevant documentation. You should also include a summary of your development process so far, including any challenges you have encountered and how you have addressed them. Ideally include commit/pull request information to show the work you have done so far, and to demonstrate that all team members are contributing to the project. Consider adding a table with lines of code contributed by each member in this sprint.
• Software engineering practices: You should also include information about the software engineering practices you are following, including your branching strategy, code review process, testing strategy, and any other relevant practices. You should also include information about how you are ensuring that all team members are contributing to the project and following these practices.
• UI Prototype: If you have a UI prototype ready by the report deadline, you should include information about it in your report, including screenshots, a link to the prototype, and a summary of the feedback you have received from your client and any other stakeholders on the prototype.
• Testing: You should include information about any testing you have done so far, including unit tests, integration tests, and user acceptance tests. You should also include information about your testing strategy and how you plan to ensure that your code is thoroughly tested before deployment.
• Team Roles: Add a table of team members and the tasks they were responsible for in this sprint.
• Reflections from midpoint presentation and client meeting feedback: Include a summary of the feedback you received from your client and any other stakeholders during your midpoint presentation and client meetings, as well as how you have addressed that feedback in your project plan and development process.

Please discuss with your client whether there are other things that you should include in this report.

Grading: This report will be graded based on the completeness and quality of the above elements, as well as the overall clarity and professionalism of the report. The report should be well-organized, clearly written, and free of spelling and grammatical errors. We will also be looking for evidence of progress towards your milestones and deliverables, as well as a clear plan for how you will continue to make progress in the next phase of the project. You may lose points if your report does not include all of the above elements, if it is poorly organized or written, or if you did not achieve your milestones or deliverables without a clear explanation of why and how you plan to get back on track, or if your code repository contributions do not follow proper software engineering practices (e.g., if they do not include clear commit messages, if they do not demonstrate that all team members are contributing, or if they do not follow the branching strategy outlined in your project plan). You may also lose points if you did not address any client feedback received since the last report, or if you did not update your risk analysis to reflect any new risks that have been identified since the last report.