This site is from a past semester! The current version will be here when the new semester starts.

Week 12 [Fri, Nov 3rd] - Project

tP:

  1. Attend the practical exam dry run During the lecture on Fri, Nov 3rd
  2. Start fixing PED bugs Before the tutorial
  3. Polish the deliverables
  4. Draft the PPP
  5. Double-check RepoSense compatibility

tP: mid-v2.1

1 Attend the practical exam dry run During the lecture on Fri, Nov 3rd

  • See info in the panel below:

2 Start fixing PED bugs Before the tutorial

  1. Triage the bugs you received in the PE-D, by following the procedure given below:

  1. Freeze features. As mentioned earlier, you are strongly discouraged from adding/updating features in this iteration. The remaining time is to be spent fixing problems discovered late and wrapping up the final release.

  2. Start fixing bugs that you selected to fix in this iteration. 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.

As before, you may split this milestone into smaller iterations if you wish e.g., v2.1, v2.1b, ...

Expectations at mid-v2.1 (i.e., by the tutorial date):

  • Minimal: all PE-D bugs have been triaged, bugs to be fixed in the current iteration have been chosen, and assigned to relevant team members.
  • Recommended: all (or almost all) the PE-D bugs that you have chosen to fix have been fixed already.

3 Polish the deliverables

  • Do more extensive testing yourselves. The panel below contains guidelines your peers will use when determining bugs in the final product -- knowing them might be useful in preventing such bugs in your product in the first place.

Admin Practical Exam → Guidelines for determining bugs

  • 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.
    Refactoring code does not violate a feature freeze (as refactoring doesn't change the behavior). Still, it is not advisable to (but you are allowed to) do major refactorings this close to a major release.

4 Draft the PPP

This task is time-sensitive. If done later than the deadline, it will not be counted as 'done' (i.e., no grace period). Reason: This is 'an early draft'; if done late, it is the 'final version' already.

  • 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.

Convert the PPP to a PDF to see if the page-count is within expectations (the PDF version can be longer than what you would expect by looking at the HTML version).

5 Double-check RepoSense compatibility

  • Once again, double-check to ensure the code attributed to you by RepoSense is correct.