Week 6 [Mon, Sep 16th] - Project

iP:

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

tP:

  1. Conceptualize the MVP version
  2. Draft the UG midnight before the tutorial
  3. Set up the project repo during 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: Define MVP, set up repo

Intro to tP Week 6

1 Conceptualize the MVP version

  • Task: Based on your user stories selected previously, conceptualize the MVP in the form of a feature list.

  • Why?: So far, we have user stories we want to include in the MVP version. But user stories simply tell us user needs. To move towards a product design, we need to design product features of the product can fulfill those user needs.

  • Submission: Note down the feature list in your online project notes document.

FAQ How many features should we put in the MVP?

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).

  • 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:

3 Set up the project repo during the tutorial

  1. [/ one member] Set up the team org:
    While only one member needs to do this, it may be useful to do this as a team while that member is screensharing, so that others get to see how it is done too.

  1. [/ one member] Set up the team repo (including the issue tracker):

  1. [ each member] Set up individual forks: