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

tP week 11: v1.3tP week 13: v1.4


tP week 12: mid-v1.4

  1. Attend the practical exam dry run During the weekly briefing on Fri, Apr 5th
  2. Start fixing PED bugs Before the tutorial
  3. Polish the deliverables
  4. [Optional] Draft the PPP
  5. Try PDF conversions early
  6. Ensure the code is RepoSense-compatible
As we start working towards v1.4, keep the following iteration goals in mind:

v1.4

  • Product goal: Stabilize the product for release.
  • Process goal: Minimize delivery risks i.e., risks of bugs in the product, or overshooting the deadline.
  • Strategy: Limit changes to bug fixes only. Improve tests, documentation, code quality

when setting the v1.4 deadline in GitHub milestones, remember that the v1.4 submission deadline is early in Week 13 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):

Admin tP → Grading


Admin Policy on reuse


1 Attend the practical exam dry run During the weekly briefing 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. Note what is allowed in this milestone:

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 other words, avoiding behavior changes unless they are strictly necessary, so that we minimize the possibility of introducing more bugs.
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 behaviors that were not already tested in the ). Hence, the feature freeze comes into effect at the point you released the JAR file that was used for the PE-D.

While the info below provides you what to do and what not to do in v1.4 specific cases, the important thing is to understand and follow the spirit of the feature freeze (i.e., do not change features further; correct unintentional errors only).

Allowed in the v1.4 milestone:

  • fixing bugs (but not feature flaws) -- we use a very restrictive definition of 'bugs' for the feature freeze; to avoid violating the feature freeze unintentionally, be sure to check the FAQs below before you do any fixes/tweaks.
  • improving documentation (e.g., update UG, DG, code comments)
  • improving code quality
  • improving the testing aspect (e.g., add more tests)
  • removing features (i.e., removing an entire feature or a part of a feature)

Not allowed in v1.4:

  • adding/changing features (even minor behavior enhancements/tweaks)
  • any UI enhancements (even purely cosmetic enhancements e.g., alignments, style changes are not allowed)
  • updates to the contents of data files bundled with the JAR file (as they control the behavior of the app)

Using 'Planned Enhancements' DG section to counter known feature flaws: Given you are not allowed to fix feature flaws in v1.4, we allow you to optionally add a section named Appendix: Planned Enhancements to the end of the DG. More details in the panel below:

FAQs on what is allowed during the feature freeze:

[Q0] What's the penalty for violating the feature freeze?


[Q1] How to differentiate between bugs vs enhancements?


[Q2] Will we be penalized for feature flaws not fixed during the feature freeze?


[Q3] What if an issue is related to a behavior not specifically stated in the UG?


[Q4] What if a feature is mentioned in the UG but not available fully in the product?


[Q5] Can we tweak validity checks for a user input, or error/exception handling?


[Q6] Can we tweak UI text (i.e., error/help messages or other text shown to the user)?


[Q7] Can we tweak case-sensitivity of a feature?


[Q8] A UI text gets truncated (or overflows) for certain inputs (or certain Windows sizes); can we fix them?


[Q9] Can we tweak the command format?


[Q10] What if the UI is inconsistent with the data?


[Q11] The tester has categorized a PE-D issue as a feature-flaw but we think it is a bug (or vice versa). How to proceed?


[Q12] We already merged a PR that violates the feature freeze. Now what?


[Q13] How to decide between recording a feature flaw as a 'known issue' (in the UG) and a 'planned enhancement' (in the DG)?


[Q14] What if the same bug is reported in the PE?


  1. 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., v1.4, v1.4b, ...

Expectations at mid-v1.4 (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.

On the tutorial day, one member should post a message in your team's MS-Teams channel (i.e., the one inside the MS-Teams used for tutorials) stating if PE-D bug triaging is done, how many bugs were selected as 'must fix' and 'good to fix' in v1.4 and how many of them have been done already. Remember to tag the tutor in that post. Note that this post will be counted as a team progress deliverable e.g.,

Our team's mid-v1.4 progress:

  • PE-D issues received: 47
  • Unique bugs: 14
    • Not allowed to fix in v1.4: 3
    • Must fix: 6 (fixed: 5)
    • Good to fix: 4 (fixed: 1)
    • Won't fix / invalid: 1

If you have 0 for the category Not allowed to fix in v1.4 when doing the above, we urge you to take another harder look at constraints imposed by the feature freeze, to confirm you are not violating the feature freeze inadvertently (which can cost you marks later). It is common for some of the PE-D bug reports to be related to enhancements rather than bugs that are allowed to be fixed in v1.4. Therefore, it is 'unusual' to have 0 bugs for that category.

  1. Submit peer evaluations for PE-D testers: Submit your peer-evaluation of PE-D testers to indicate how well they helped your team.
    Deadline: by Tue, Apr 16th 2359
    The submission is to be done via the TEAMMATES system.
    Only one team member needs to submit on behalf of the team but discuss among team members first.
    Base the evaluation on the quality/usefulness of the bugs reported as well as the quantity.
    Here are the two questions you'll need to answer in the evaluation:

PE-D bug titles will be prefixed with tester ID e.g., ([PE-D][Tester A] UG does not load) to make it easy for you to bugs reported by each tester.
Furthermore, tester ID mapping (i.e., who is Tester A, Tester B, etc.) will be sent to you via email within 1 day after the PE-D.

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 [Optional] Draft the PPP

  • Create the first version of your Project Portfolio Page (PPP) if you opt to submit a PPP -- the panel below to learn when you should opt to submit it..

Admin tP → Deliverables → Project Portfolio Page

At the end of the project each student is required to submit a Project Portfolio Page. To reduce workload, this deliverable has been made optional this semester. You need to submit this only if you think your team members are not fully aware of your contribution to the tP. Also, we will ask you to submit this if there is a dispute about your contribution level.

Details ... (read only if you opted to submit this deliverable)

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
  • PDF file submission: not required.


5 Try PDF conversions early

  • Take note of the following project constraint:

  • Take note of the following info about the PDF conversion, appearing in next week's project tasks. Particularly, note the suggestion to try PDF conversions early.

6 Ensure the code is RepoSense-compatible

  • Ensure your code is and the code it attributes to you is indeed the code written by you, as explained below:

    • Go to the tp Code Dashboard. Click on the </> icon against your name and verify that the lines attributed to you (i.e., lines marked as green) reflects your code contribution correctly. This is important because some aspects of your project grade (e.g., code quality) will be graded based on those lines.

    • More info on how to make the code RepoSense compatible:

FAQ: What if someone took over a feature from another team member?



tP week 11: v1.3tP week 13: v1.4