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

Week 6 [Feb 17] - Project

iP:

Finalize the features
Set up a product website
Release the product

tP:

Set up the project repo
Get familiar with the code base
Conceptualize v2.0
Draft the UG
Refine the product design

iP

Aim to finish the iP by this week!
Although the official iP submission deadline is Week 7 Monday, aim to finish the iP by this week's i.e., 2359 before the tutorialweekly deadline so that you can devote more time to the tP after this week. The extra time for the iP (i.e., from week 6 to 7) is meant as a buffer for those lagging behind in the iP.

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

2 Set up a product website

Add a representative screenshot of the product to the docs folder.
- The file name 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)

A-UserGuide: User Guide

A-UserGuide

↳ Add a User Guide

Add a User Guide to the project. Here is one simple way to do it.

Update the given docs\README.md. See this guide to GitHub flavored Markdown (GFMD).
Go to the settings page of your Duke fork and enable GitHub pages to publish from the docs folder (you can select a theme too).
Go to http://{your username}.github.io/duke/ to view the user guide of your product.

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

3 Release the product

Create a new jar file using Gradle. Creating jar file using Intellij is not recommended unless the project is very simple.
Do the following smoke tests to ensure the jar file works (reason: it will be used to grade 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.
Create a new release on GitHub (e.g., v0.2) and upload the jar file.

A-Release: Release

A-Release

↳ Release the product

Release the product to be used by potential users. e.g., you can make it available on GitHub

tP: mid-v1.1

indicates an individual milestone (i.e., each team member has to do their part of the milestone, graded individually) while indicates a team milestone (some or all members may do the work; graded for the whole team).

Milestone progress is graded. Be reminded that reaching individual and team milestones are considered for grading the project management component of your project grade.

Most aspects 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 spend 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 Set up the project repo

Set up the team org and the team repo as explained below:

2 Get familiar with the code base

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-field and 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.
Ideally, you should do the above tutorials by week 6 (i.e., midnight before the tutorial), but you may take an extra week (i.e., by the week 7 tutorial) to finish them without penalty.
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 use to merge code in your tP:

3 Conceptualize v2.0

Based on your user story categorization in the previous week, given module requirements/constraints for the project, and the current state of the product, select which user stories you are likely to include in v2.0.
Conceptualize the product in terms of how it will look like at v2.0.

4 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 v2.0.
- We recommend that you follow the existing 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 asciidoc 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 the end of the semester.
- Consider including some UI mock-ups too (they can be hand-drawn or created using a tool such as PowerPoint, PlantUML or Balsamiq).
- Submission: Save the draft UG as a PDF file, name it {team-id}.pdf e.g., CS2103T-W09-1.pdf, and upload to LumiNUS.

Recommended: Divide documentation work (in the User Guide and the Developer Guide) 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.

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