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

Week 6 [Fri, Feb 16th] - Project

iP:

  1. Add Increments as parallel branches: Level-6, Level-7
  2. Add Increment: A-Jar

tP:

  1. Conceptualize v1.0
  2. Draft the UG midnight before the tutorial

iP

1 Add Increments as parallel branches: Level-6, Level-7

  • Practice using parallel git branches, as explained below:
    1. First, do Level-6 in a branch named branch-Level-6, but do not merge it.
    2. Then, go back to the master branch and implement Level-7 in a separate branch named branch-Level-7.
    3. Now, go back to the master branch and merge the two branches one after the other.
      If there are merge conflicts, you'll have to resolve them first.
    4. As before, tag the commit (in the master branch, after merging) that achieves the respective deliverable, and push to your fork.
  • As before, Merge without a fast-forward so that git creates a separate commit for the merge.
    Advanced git users: do not delete the branch after merging.
Duke Level-6: Delete
Duke Level-7: Save

2 Add Increment: A-Jar

Duke A-Jar: Create a JAR File

Note that if A-Jar increment does not require any code changes, you may tag the commit at which this was achieved as A-Jar (even if that commit has another tag already). Otherwise, tag the latest commit as usual. In both cases, push the tag to the fork.

tP: Conceptualize the product

1 Conceptualize v1.0

  • Based on your user stories selected previously, conceptualize the product in terms of how it will look like at v1.0 in the form of a feature list.
    Note down the feature list in your online project notes document.

FAQ: How many features should we put in v1.0?
A: Aim for the smallest set of features the product cannot do without. Even a most basic version of those features is enough. After completing that feature set, you can add more if there is time left.

2 Draft the UG midnight before the tutorial

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 can't count as 'early'.

  • 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.0.
    • We recommend that you follow the AB3 User Guide in terms of structure and format.
    • As this is a draft only 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. You can also limit this to just the 'Features' section only and omit the other sections.
      While the UG draft need not be 'polished', it should be detailed enough to tell the user how to use the product features in concern.
    • IMPORTANT:
      • Specify the precise/full command syntax for the CLI commands that you will deliver at v1.0. i.e., we want you to know exactly what you plan to deliver at v1.0 -- while it is fine to change this plan later, it is still important to have a plan first.
      • Include all features that will be available in v1.0. There is no need to include features that will be delivered beyond v1.0.
    • Consider including examples of expected outputs too.
    • Submission [one person per team]: Save the draft UG as a PDF file, name it {team-id}.pdf e.g., CS2113-T09-2.pdf, and upload to Canvas.

Recommended: Divide 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.

If you are not sure what we mean by 'enhancements/features each person would be adding' mentioned above, see the panel below for our recommendation on how to divide the tP work: