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

Week 6 [Fri, Sep 9th] - 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
  3. Refine the product design

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

  • In case this 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).
  • Upload the jar file to your fork as explained in the panel below.
Duke A-Jar: Create a JAR File

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

  • 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 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.0.
    • Include only features that will be delivered in 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 LumiNUS.

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.

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.