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

Week 12 [Fri, Apr 5th] - Project

tP:

  1. Attend the practical exam dry run During the lecture on Fri, Apr 5th
  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, Apr 5th

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

  • 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 can't count as 'early'.

  • Create the first version of your Project Portfolio Page (PPP).Each member needs to create a PPP to describe your contribution to the project.

Admin tP → Deliverables → Project Portfolio Page

At the end of the project each student is required to submit a Project Portfolio Page.

PPP Objectives

  • For you to use (e.g. in your resume) as a well-documented data point of your SE experience
  • For evaluators to use as a data point for evaluating your project contributions

PPP Sections to include

  • Overview: A short overview of your product to provide some context to the reader. The opening 1-2 sentences may be reused by all team members. If your product overview extends beyond 1-2 sentences, the remainder should be written by yourself.
  • Summary of Contributions --Suggested items to include:
    • Code contributed: Give a link to your code on tP Code Dashboard. The link is available in the Project List Page -- linked to the icon under your profile picture.
    • Enhancements implemented: A summary of the enhancements you implemented.
    • Contributions to the UG: Which sections did you contribute to the UG?
    • Contributions to the DG: Which sections did you contribute to the DG? Which UML diagrams did you add/updated?
    • Contributions to team-based tasks
    • Review/mentoring contributions: Links to PRs reviewed, instances of helping team members in other ways.
    • Contributions beyond the project team:
      • Evidence of helping others e.g. responses you posted in our forum, bugs you reported in other team's products,
      • Evidence of technical leadership e.g. sharing useful information in the forum

Keep in mind that evaluators will use the PPP to estimate your project effort. We recommend that you mention things that will earn you a fair score e.g., explain how deep the enhancement is, why it is complete, how hard it was to implement etc.

  • OPTIONAL Contributions to the Developer Guide (Extracts): Reproduce the parts in the Developer Guide that you wrote. Alternatively, you can show the various diagrams you contributed.
  • OPTIONAL Contributions to the User Guide (Extracts): Reproduce the parts in the User Guide that you wrote.

PPP Format

  • File name (i.e., in the repo): docs/team/github_username_in_lower_case.md e.g., docs/team/goodcoder123.md
  • Follow the example in the AddressBook-Level3
  • For the final submission of the PPP (at the end of the tP), you need to save your PPP as a PDF file. Therefore, ensure the PDF version of the PPP looks OK at least a few days before the final submission.

Don't take PDF conversion lightly: To convert the UG/DG/PPP into PDF format, go to the generated page in your project's github.io site and use this technique to save as a pdf file. Using other techniques or not following the settings suggested in the given technique can result in issues such as missing background colors, poor quality resolution , unnecessarily large files (the last two can be considered as bugs).

The PDF versions of the UG/DG/PPP should be usable by the target readers, even if not as neat/optimized as the Web versions. For example, margins and page breaks need not be optimized, but they should not hinder the reader either. Assume some will occasionally choose the PDF version over the Web version e.g, for printing, offline viewing, annotating etc.

PE uses the PDF versions of UG/DG, not the Web version! Any problems in those PDF files (e.g., broken links, messed up formatting) can be reported as bugs.

Ensure hyperlinks in the pdf files work. Broken/non-working hyperlinks in the PDF files will be considered as bugs and will count against your project score. Again, use the conversion technique given above to ensure links in the PDF files work.

PDF files should,

  • be paginated at a reasonable page size (e.g., A4). Reason: single-page PDF files don't work well in some PDF viewers, and not suitable for printing either.
  • allow copying text so that readers can copy text from them (e.g., copy an example command from the UG).

Try the PDF conversion early. If you do it at the last minute, you may not have time to fix any problems in the generated PDF files (such problems are more common than you think).

PPP Page Limit

Content Recommended Hard Limit
Overview + Summary of contributions 0.5-1 2
[Optional] Contributions to the User Guide 1
[Optional] Contributions to the Developer Guide 3
  • The page limits given above are after converting to PDF format. The actual amount of content you require is actually less than what these numbers suggest because the HTML → PDF conversion adds a lot of spacing around content.

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.