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.
- Follow
-
Duration: Strictly
(teamSize x 3) + 1minutes e.g. 17 minutes for a 5-person team. Exceeding this limit will be penalized. The extra minute is for the first speaker to give an overview of the product. -
Target audience: Assume you are giving a demo to a higher-level manager of your company, to brief him/her on the current capabilities of the product. This is the first time they are seeing the new product you developed but they are familiar with the AddressBook-level4 (AB4) product.
-
Scope:
- Each person should demo the enhancements they added. However, it's ok for one member to do all the typing.
- Subjected to the constraint mentioned in the previous point, as far as possible, organize the demo to present a cohesive picture of the product as a whole, presented in a logical order. Remember to explain the profile of the target user profile and value proposition early in the demo.
- It is recommended you showcase how the feature improves the user’s life rather than simply describe each feature.
- No need to cover design/implementation details as the manager is not interested in those details.
- Mention features you inherited from AB4 only if they are needed to explain your new features. Reason: existing features will not earn you marks, and the audience is already familiar with AB4 features.
-
Structure:
- Demo the product using the same executable you submitted, on your own laptop, using the TV.
- It can be a sitting down demo: You'll be demonstrating the features using the TV while sitting down. But you may stand around the TV if you prefer that way.
- It will be uninterrupted demo: The audience members will not interrupt you during the demo. That means you should finish within the given time.
- The app should be populated with a significant amount of realistic data at the start. e.g at least 20 contacts.
- Dress code : The level of formality is up to you, but it is recommended that the whole team dress at the same level.
-
Optimizing the time:
- Spend as much time as possible on demonstrating the actual product. Not recommended to use slides (if you do, use them sparingly) or videos or lengthy narrations.
Avoid skits, re-enactments, dramatizations etc. This is not a sales pitch or an informercial. While you need to show how a user use the product to get value, but you don’t need to act like an imaginary user. For example, [Instead of this]Jim get’s a call from boss. "Ring ring", "hello", "oh hi Jim, can we postpone the meeting?" "Sure". Jim hang up and curses the boss under his breath. Now he starts typing ..etc.[do this]If Jim needs to postpone the meeting, he can type …
It’s not that dramatization is bad or we don’t like it. We simply don’t have enough time for it.
Note that CS2101 demo requirements may differ. Different context → Different requirements. - Rehearse the steps well and ensure you can do a smooth demo. Poor quality demos can affect your grade.
- Don’t waste time repeating things the target audience already knows. e.g. no need to say things like "We are students from NUS, SoC".
- Bring sufficient amount of sample data and know how to load them to the system. You should not plan to type all the sample data during the demo itself. On the other hand, trying to demo a product using just 1-2 sample data creates a bad impression too.
- Plan the demo to be in sync with the impression you want to create. For example, if you are trying to convince that the product is easy to use, show the easiest way to perform a task before you show the full command with all the bells and whistles.
- Limit the demo to CLI inputs only. There is no point explaining GUI inputs because they don't earn marks.
- Spend as much time as possible on demonstrating the actual product. Not recommended to use slides (if you do, use them sparingly) or videos or lengthy narrations.