- Attend the practical exam dry run During the lecture counted for participation
- Polish the product as per peer-testing results
- Draft the PPP
-
Prepare for the demo rehearsal - Double-check RepoSense compatibility
when setting the v1.4 deadline in GitHub milestones, remember that the v1.4 submission deadline is Week 13 Monday for everyone (does not vary by tutorial day). Set your own milestone deadline accordingly, or else our grading scripts will flag it as an 'unsuitable' deadline.
Remind yourself of the project grading criteria and our policy on reuse (e.g., how to give credit for reused code):
1 Attend the practical exam dry run During the lecture counted for participation
2 Polish the product as per peer-testing results
Allowed in the v1.4 milestone:
fixing bugs
improving documentation
purely cosmetic enhancements e.g., alignments, style changes
improving code quality
improving tests
removing features
Not allowed in v1.4: adding features or doing major changes to existing features.
The goal of freezing features in the pre-release iteration is to subject the features to at least one round of intensive non-dev testing before they are released to the users. In a real project, minor or critical changes might be allowed even near a deadline -- but here, we do not allow any feature changes because it can start us on a slippery slope and many "is this change allowed?" queries. Therefore, v1.4 should not have any features that was not already tested in the PE-D).
FAQs:
- Q: Can we add a missing validity check for a user input?
A: Yes, but only if its absence causes the software to mis-behave (i.e., it's omission can be considered a bug). - Q: Testers have reported a missing feature (or a feature suggestion). Can we add it?
A: Most teams receive such suggestions from testers as we allow feature suggestions in PE-D (but they are not allowed in the PE). You can use those suggestions when you envision future versions of the product (i.e., beyond v1.4 -- to improve your product design skills. But for now, focus on fixing bugs, and perfecting other aspects such as testing, documentation, code quality.
Also note that given there's a feature freeze in v1.4, some lower-priority features can be argued as out-of-scope if there were other higher priority features that took up the available time in previous versions. Every team has to draw the line somewhere as there wasn't a lot of time to implement features.
- Follow the procedure for dealing with PED bugs you received:
Fix bugs that were reported during the PE-D. Don't rely on PE-D alone to find bugs. Also keep in mind that bug fixing can cause regressions which you'll have to catch and fix.
Do more extensive testing yourselves.
- If your software has a GUI that has a large default size, ensure that it works even in lower-resolution screens (within reasonable limits). In the past, there were cases where the GUI opened up bigger than the screen with some important parts not visible, and users were unable to proceed further.
Update documentation to match the product. In particular, finalize the content of the DG early and check it thoroughly for bugs (reason: unlike the UG, the DG did not get tested in the PE dry run).
- Consider increasing test coverage by adding more tests if it is lower than the level you would like it to be. Take note of our expectation on test code (given in the panel below).
- After you have sufficient code coverage, fix remaining code quality problems and bring up the quality to your target level.
- As before, you may split this milestone into smaller iterations if you wish e.g.,
v1.4,v1.4b, ...
3 Draft the PPP
- Create the first version of your Project Portfolio Page (PPP).
Reason: Each member needs to create a PPP to describe your contribution to the project.
4 Prepare for the demo rehearsal
5 Double-check RepoSense compatibility
- Once again, double-check to ensure the code attributed to you by RepoSense is correct.