The main part of the project will be done in several sprints. In each sprint you will have to work on several tasks:
- An update of your specification and design documents (Requirements and Design). In Sprint 1 and Sprint 2 you will have extra time to write the first version of the Design document.
- A completion of a running version of your code with a partial set of features
- Testing support and tests for the implemented features
- A (short) progress report
Revised requirements/spec and design documents
Update the specification and design documents based on the progress you made so far.
- Update the implementation and testing plans (in the design document) to reflect what you have already accomplished.
- Identify the features you are going to implement in the current sprint. Add user stories (to the requirements document), task breakdowns (design doc), and assignments (design doc). You may need to update tasks that weren't completed in the last sprint. Reassess the task difficulties if necessary.
- Flesh out your list of possible features for future sprints (requirements document). Ideally, you should have a rough outline in place for all sprints. You will change this as we do each sprint, but having a general plan in place will be helpful to everyone involved.
- Identify any changes in the requirements, system architecture and design details.
- Ensure the design document is current for the set of features you've implemented to date and will implement in the next sprint.
- Discuss design decisions that affect testing and describe any test interfaces built into the system (in the testing plan section).
You must mark clearly the parts of the document that were changed. Use the Changes section at the start of the document and use a different font color for the changed parts.
Sprint Progress Report
Write a short (1~2 pages) summary for sprint and submit it along with the revised documents.
- What were the main difficulties so far? You should consider both technical and organization issues.
- Were there any features you did not implement as planned, and why? Are you pushing some features to later sprints, and if so, why?
- What tests did you prepare for this sprint, and what are they covering? Did the tests you wrote deviate from your plan? What features are you not testing yet? Did you use any test frameworks?
- You must include in your progress report a test coverage report. The coverage metric must be over 80%. If it's below 80%, you will lose 10% of the overall score of that sprint. This number may change each sprint.
You must specify what tool did you use, and you must include one or more screenshots showing:
- The overall coverage metric
- The list of classes with lowest coverage. Explain why is the coverage low, and what (if anything) you plan to do about it
- Contribution of team members
- Tag a branch or revision in your repository to identify the code you want to submit for sprintN (replace N with 1, 2, ...). The date and time of this revision should be before the deadline. This branch should include a README file with instructions on how to run the application and tests.
Submission
Each team must send an email to [email protected] by the deadline. The subject line of the email message must start with the word “[SWPP] sprintN” (replace N with 1, 2, ...) followed by your project's name. The email should contain:
Pointers to the (previously submitted) requirements document and design document.
The sprint summary progress report, as described above.
Instructions for your TA to be able to check out a tagged version of the code that constitutes your sprint release.
A url and instructions for using the app in the current stage.
Additionally, in the project progress presentation you will have to demonstrate a running version of your sprint release.