Project → mid-v1.4 [week 12]

Overview: tweak as per peer-testing results, draft Project Portfolio Page, practice product demo

Project Management:

• Freeze features around this time. Ensure the current product have all the features you intend to release at v1.4. Adding major changes after this point is risky. The remaining time is better spent fixing problems discovered late or on fine-tuning the product.

Product:

• Consider increasing code 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.
• After you have sufficient code coverage, fix remaining code quality problems and bring up the quality to your target level.

• There is no requirement for a minimum coverage level. Note that in a production environment you are often required to have at least 90% of the code covered by tests. In this project, it can be less. The less coverage you have, the higher the risk of regression bugs, which will cost marks if not fixed before the final submission.
• You must write some tests so that we can evaluate your ability to write tests.
• How much of each type of testing should you do? We expect you to decide. You learned different types of testing and what they try to achieve. Based on that, you should decide how much of each type is required. Similarly, you can decide to what extent you want to automate tests, depending on the benefits and the effort required.
• Applying TDD is optional. If you plan to test something, it is better to apply TDD because TDD ensures that you write functional code in a testable way. If you do it the normal way, you often find that it is hard to test the functional code because the code has low testability.

Documentation:

• Update documentation to match the product.

• 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. Creating a PPP takes a significant effort; it is too risky to leave it to the last week of the project.

Demo:

• Do a product demo to serve as a rehearsal for the final project demo at v1.4
  • Follow final demo instructions as much as possible.
  • Cover all features, not just the ones added in the recent iteration.
  • Try to make it a 'well prepared' demo i.e., know in advance exactly what you'll do in the demo.

null