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

Week 6 [Fri, Feb 10th] - Project

iP:

  1. Add Increments: A-BetterGui, A-Personality, A-MoreErrorHandling, A-MoreTesting
  2. Finalize the features
  3. Set up a product website
  4. Submit the final version Fri, Feb 17th 2359

tP:

  1. Conceptualize v1.2
  2. Draft the UG
  3. Refine the product design
  4. Set up the project repo
  5. Get familiar with the code base

iP

1 Add Increments: A-BetterGui, A-Personality, A-MoreErrorHandling, A-MoreTesting

  • As before, we recommend (but not require) that each increment is done as a separate branch and merged to the master branch when ready fully done.
Duke A-BetterGui: Better GUI optional
Duke A-Personality: A unique personality optional
Duke A-MoreErrorHandling: More error handling optional
Duke A-MoreTesting: More testing optional

2 Finalize the features

  • You may give the product any name, but do not rename the repo.
  • Reminder: you can give the chatbot any personality (there is no need to follow the exact command/response formats given)
  • Remember to give credit to any code you reused or solutions you adopted from others. Reuse without giving credit is plagiarism and will be reported to the university for disciplinary action.

3 Set up a product website

  • Add a representative screenshot of the product to the docs folder.
    • The file should be in the docs folder and named Ui.png exactly (even if the file format is not png, name it png)
    • Ideally, the product name is visible in the screenshot e.g., in the title bar of the Window

  • Add a brief User Guide (UG)
Duke A-UserGuide: User Guide

  • If you added the Ui.png correctly and set up the product website correctly, you should be able to see your screenshot in the iP Showcase page (a link to the iP Showcase page is also available in the top navigation menu → Links) and you should be able to access the image using the link https://{your user name}.github.io/{repo name}/Ui.png (e.g., https://johndoe.github.io/ip/Ui.png).

4 Submit the final version Fri, Feb 17th 2359

  • Soft deadline: midnight before the tutorial

  • Create a new jar file

    • Create the JAR file using Gradle.
    • The JAR file should be cross-platform and should work in a computer that has Java 11.

  • Do the following smoke tests to ensure the jar file works (reason: a similar flow will be used when grading your iP).

    1. Copy the jar file to an empty folder and test it from there. This should surface issues with hard-coded file paths.
    2. Pass the jar file to team members and ask them to do a test drive. Assuming some of your team members' OS differ from yours, this should verify if the app is cross-platform.
      If you don't have ready access to a specific OS, post a link to your JAR in the forum and ask others to help with the smoke testing -- some of them will even appreciate the opportunity to help a classmate.

  • Create a new release on GitHub (e.g., v0.2) and upload the JAR file.

    • Recommended to refrain from uploading multiple JAR files as this can cause extra work for the evaluators.
Duke A-Release: Release

tP: Conceptualize the product

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.

PR review comments matter! Remember to do proper PR reviews throughout the tP, at least for non-trivial changes, as the quality and quantity of PR review comments you have given to peers affect your tP marks (under the project management aspect).

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.

FAQ: How many features should we put in v1.2?
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

  • 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 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.2. i.e., we want you to know exactly what you plan to deliver at v1.2 -- 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.2. There is no need to include features that will be delivered beyond v1.2.
    • Consider including some UI mock-ups too (they can be hand-drawn or created using a tool such as PowerPoint, PlantUML, Figma, etc. -- they can be very low-fidelity mock-ups, as they are meant to be temporary).
    • Submission [one person per team]: Save the draft UG as a PDF file, name it {team-id}.pdf e.g., CS2103-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 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

FAQ: Is this a team task or an individual task?
A: It's an individual task (note the icon above), to be done by each member, as we want every member to be 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
      • We recommend that you put in a sincere effort into this tutorial because tracing through the code of an unfamiliar code base is an important skill that you will not be able to learn/practice it later in the project as the code will no longer be 'unfamiliar' to you later.
      • Submission [optional]: Post an issue in your team's repo with the title Tutorial: tracing code. In the description, add a 2-3 screenshots you took while at various points of the tutorial. You may close the issue soon after.
    • Tutorial 2 - 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. You may close the PR soon after.
      • FAQ: Do we have to write/update test cases too?
        A: Not a strict requirement, but given the purpose of this tutorial is to learn the code base, it's ideal if you do. It will familiarize you with the existing testing infrastructure. Otherwise you can run into difficulties when you are writing test cases for your own features later.
    • Tutorial 3 - Removing a field from an entity
      • This tutorial is optional to do, but at least give it a quick read.
      • Submission: not required.
  • 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: