- Conceptualize v1.2
- Draft the UG
- Refine the product design
- Set up the project repo
- Get familiar with the code base
indicates an individual task (i.e., each team member has to do the task, graded individually) while indicates a team task (some or all members may do the work; graded for the whole team).
tP tasks progress is graded. Completing individual and team tasks are considered for grading the project management component of your project grade.
Most aspects of project progress are tracked using automated scripts. Please follow our instructions closely or else the script will not be able to detect your progress. We prefer not to waste admin resources processing requests for partial credit for work that did not follow the instructions precisely, unless the progress was not detected due to a bug in the script.
Milestone requirements are cumulative. The recommended progress for the mid-milestone is an implicit requirement for the actual milestone unless a milestone requirement overrides a mid-milestone requirement e.g., mid-milestone requires a document to be in a temp format while the actual milestone requires it to be in the proper format. Similarly, a requirement for milestone n is also an implicit requirement for milestone n+1 unless n+1 overrides the n requirement. This means if you miss some requirement at milestone n, you should try to achieve it before milestone n+1 or else it could be noted again as a 'missed requirement' at milestone n+1.
1 Conceptualize v1.2
- Based on your user stories selected previously, conceptualize the product in terms of how it will look like at v1.2 in the form of a feature list.
Note down the feature list in your online project notes document.
2 Draft the UG
- Draft a user guide in a convenient medium (e.g., a GoogleDoc) to describe what the product would be like when it is at v1.2.
- We recommend that you follow the AB3 User Guide in terms of structure and format.
- As this is a very rough draft and the final version will be in a different format altogether (i.e., in Markdown format), don't waste time in formatting, copy editing etc. It is fine as long as the tutor can get a rough idea of the features from this draft. You can also do just the 'Features' section and omit the other parts.
- Do try to come up with concrete command syntax for the CLI commands that you will deliver at v1.2.
- Include only features that will be delivered in v1.2.
- Consider including some UI mock-ups too (they can be hand-drawn or created using a tool such as PowerPoint, PlantUML or Balsamiq).
- Submission [one person per team]: Save the draft UG as a PDF file, name it
{team-id}.pdfe.g.,CS2103-T09-2.pdf, and upload to LumiNUS.
Recommended: Divide i.e., work related to the User Guide and the Developer Guidedocumentation work among team members equally; preferably based on enhancements/features each person would be adding e.g., If you are the person planing to add a feature X, you should be the person to describe the feature X in the User Guide and in the Developer Guide.
Reason: In the final project evaluation your documentation skills will be graded based on sections of the User/Developer Guide you have written.
3 Refine the product design
- Review the UG to ensure the features written by each member fit together to form a cohesive product. Note that cohesiveness of the product can affect the grading of the product design aspect.
4 Set up the project repo
- Set up the team org, the team repo, and individual forks as explained below:
5 Get familiar with the code base
- Ideally, you should do this task in this week (i.e., midnight before the week 6 tutorial), but you may take an extra week (i.e., by the week 7 tutorial) to finish them without penalty.
- Do the following tutorials to get familiar with the codebase
- Tutorial 1 - Tracing a Command Execution Path
- Tutorial 2 - Removing a field from an entity
- If you are an experienced programmer, you can remove a different field than the one given in the tutorial.
- Submission: Do your changes in a branch named
tutorial-removing-fieldand push to your fork.
- Tutorial 3 - Adding a new Command
- If you are an experienced programmer, you can add a different command than the one given in the tutorial.
- Submission: Do your changes in a branch named
tutorial-adding-command, push to your fork, and create a PR from your fork to your team's repo.
- The PRs created for tutorials need not be merged, unless the changes are actually in line with your project idea.
- For reference, given below is the workflow you should follow when merging code in your tP: