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

tP week 10: mid-v1.3tP week 12: mid-v1.4


tP week 11: v1.3

  1. Deliver v1.3
  2. Update user docs
  3. Release as a jar file
  4. Wrap up v1.3
  5. Demo v1.3 before the tutorial

1 Deliver v1.3

  • Deliver the features that you planned for v1.3.

Have any suggestions to improve AB3?

Now that you have worked with AB3 codebase for a while, if you have any suggestions on how to improve AB3 (for future batches), feel free to post in the AB3 upstream issue tracker.
Examples: places where the design/code can be simplified, hard to understand parts of the code, tips you can share with future batches, ...

2 Update user docs

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.

  • Update the v1.3 user guide to match the current version of the product. Reason: testers will need to refer to the UG during the practical exam dry run.
    • Remove mentions of any features not implemented yet, if any. As you are not allowed to change features during the iteration v1.4, there is no point keeping those in the UG.
    • For those features already implemented, ensure their descriptions match the exact behavior of the product e.g. replace mockups with actual screenshots
  • Landing page (docs/index.md): Update to look like a real product (rather than a project for learning SE) if you haven't done so already. In particular, update the Ui.png to match the current product ( tips).

3 Release as a jar file

  • Do a as described in the Developer Guide. Aim to release it by the usual soft deadline (i.e., midnight before your tutorial). Do some manual tests to ensure the jar file works.
  • You can do an additional JAR release before the PE dry run (PE-D) if you wish, as long as you do it before 10 am Friday. That additional JAR is still considered part of v1.3 and therefore, can contain new features. When doing this additional release, do not delete the previous one (reason: it is good to preserver the release history) -- testers are expected to take the latest JAR file anyway. You may use any suitable version number for this JAR file e.g., v1.3.1.
    Waiting till Friday 10am to release the v1.3 JAR file is strongly discouraged because if you miss that deadline, your team will not be able to benefit from the PE-D at all. It is better to have an earlier release to fall back on in case that happens.
  • The feature freeze will apply at the point you released the JAR file that was used in the PE-D i.e., the features submitted in the final v1.4 two weeks later should be the same as the features tested during PE-D, which is the rationale for the feature freeze anyway.

4 Wrap up v1.3

  • as before

5 Demo v1.3 before the tutorial

  • [one member] As was done in v1.2,
    • Run your application using the JAR file that you released for v1.3.
    • Take screenshots of each available feature in action (or screen-record a demo -- need not be polished).
    • Add those screenshots (or upload the demo video somewhere and give the link) to your project notes document with an appropriate heading e.g., v1.3 features demo.


tP week 10: mid-v1.3tP week 12: mid-v1.4