The tP spans ten weeks, and is to be done in breadth-first iterative fashion.
The first half of the tP will be spent of laying out the foundation for the iterations, as illustrated below (note that the diagrams above show the relative size of tasks i.e., smaller tasks are shown as shorter bar).
- Form teams
- Set weekly meeting times
- Decide on a general direction for the project (i.e., target user profile, and problem addressed)
- Gather requirements in the form of user stories.
- Decide which of them will go into the first version.
- Decide how the product will look like at v1.2.
- Record that product concept in the form of a user guide.
Ensure development environment is set up.
Plan the next iteration i.e., decide who will do which parts by when.
- Do a practice iteration (v1.1) to get used to the workflow. In this iteration, only some documents will be updated.
The first half of the tP is light because you will be doing the iP in parallel during that time.
The second half of the tP is divided into three iterations, each of which is expected to produce a working version of the product by evolving the product delivered in the previous iteration.
- This is the first proper iteration.
- Aim to deliver an version of the product.
- This version will be tested by peers and you will receive the bug reports without any penalty.
- Aim to deliver all so that you can get them tested for free.
- This iteration is shorter (slightly more than one week).
- Changes to features are not allowed in this iteration. Use it for bug fixing, code quality improvements, improving the tests, and polishing up documentation only.
The final submission will be at the start of week 13. Deliverables include an executable jar file, a product website (containing both user and developer documentation), a demo video, among other things.
- The final submission is subjected to a intensive peer testing (in a so called practical exam).
- You will get credit for finding bugs in others' deliverables and penalized for bugs found in your deliverables.