This site is from a past semester! The current version will be here when the new semester starts.
CS2113/T 2021 Jan-May
  • Full Timeline
  • Week 1 [Mon, Jan 11th]
  • Week 2 [Mon, Jun 21st]
  • Week 3 [Mon, Jun 28th]
  • Week 4 [Mon, Jul 5th]
  • Week 5 [Mon, Jul 12th]
  • Week 6 [Mon, Jul 19th]
  • Week 7 [Mon, Jul 26th]
  • Week 8 [Mon, Aug 9th]
  • Week 9 [Mon, Aug 16th]
  • Week 10 [Mon, Aug 23rd]
  • Week 11 [Mon, Aug 30th]
  • Week 12 [Mon, Sep 6th]
  • Week 13 [Mon, Sep 13th]
  • Textbook
  • Admin Info
  • Dashboards
  •  Individual Project (iP):
  • Individual Project Info
  • iP Upstream Repo
  • iP Code Dashboard
  • iP Progress Dashboard

  •  Team Project (tP):
  • Team Project Info
  • Reference AB3
  • Team List
  • tP Code Dashboard
  • tP Progress Dashboard
  • Java exercises
  • Report Bugs
  • Forum
  • Gitter (Chat)
  • Instructors
  • Announcements
  • Files (handouts, submissions etc.)
  • Tutorial Schedule
  • Java Coding Standard
  • Git Conventions
  • Forum Activities Dashboard
  • Participation Dashboard
  • Week 6 [Mon, Jul 19th] - 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

    Level 6. Delete

    Add support for deleting tasks from the list.

    Example:

    list
        ____________________________________________________________
         Here are the tasks in your list:
         1.[T][X] read book
         2.[D][X] return book (by: June 6th)
         3.[E][ ] project meeting (at: Aug 6th 2-4pm)
         4.[T][X] join sports club
         5.[T][ ] borrow book
        ____________________________________________________________
    
    delete 3
        ____________________________________________________________
         Noted. I've removed this task: 
           [E][ ] project meeting (at: Aug 6th 2-4pm)
         Now you have 4 tasks in the list.
        ____________________________________________________________
    

    When implementing this feature, you are also recommended to implement the following extension:

    A-Collections

         Use Java Collections classes

    Use Java Collections classes for storing data. For example, you can use an ArrayList<Task> to store the tasks.

    Duke Level-7: Save

    Level 7. Save

    Save the tasks in the hard disk automatically whenever the task list changes. Load the data from the hard disk when Duke starts up. You may hard-code the file name and location e.g., [project_root]/data/duke.txt

    The format of the file is up to you. Example:

    T | 1 | read book
    D | 0 | return book | June 6th
    E | 0 | project meeting | Aug 6th 2-4pm
    T | 1 | join sports club
    

    If you use file paths in your code,

    • remember to use relative paths rather than absolute paths such as C:\data. If not, your app can cause unpredictable results when used in another computer.
    • remember to specify file paths in an OS-independent way. If not, your app might not work when used on a different OS.

    Your code must i.e., if the file is missing, your code must creat ithandle the case where the data file doesn't exist at the start. Reason: when someone else takes your Duke and runs it for the first time, the required file might not exist in their computer. Similarly, if you expect the data file to be in as specific folder (e.g., ./data/), you must also handle the folder-does-not-exist-yet case.

    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

    A-Jar

         Package the App as a JAR file

    Package the app as an executable JAR file so that it can be distributed easily.

    You can assume the user will run the jar file in the following way only:

    • Copy the jar file into an empty folder
    • Open a command window in that folder
    • Run the command java -jar {filename}.jar e.g., java -jar Duke.jar (i.e., run the command in the same folder as the jar file)

    Refer to the tutorial Working with JAR files @SE-EDU/guides to find how to create JAR files.

    Do not commit the JAR file created. Instead, you can make the JAR file available in the following manner.

    • Go to your fork on GitHub and create a new release.
    • In the page where you fill the details of the release,
      • give an appropriate version number e.g., v0.1
      • attach the JAR file where it says Attach binaries by dropping them ....

    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.
     

    Requirements → Specifying Requirements → Feature Lists →

    What

    Feature list: A list of features of a product grouped according to some criteria such as aspect, priority, order of delivery, etc.

    A sample feature list from a simple Minesweeper game (only a brief description has been provided to save space):

    1. Basic play – Single player play.
    2. Difficulty levels
      • Medium levels
      • Advanced levels
    3. Versus play – Two players can play against each other.
    4. Timer – Additional fixed time restriction on the player.
    5. ...

    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 i.e., work related to the User Guide and the Developer Guidedocumentation work 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.

    4. Project Grading: Documentation [ 10 marks]

    Evaluates: your contribution to project documents

    Method: Evaluated in two steps.

    • Step 1: Evaluate the whole UG and DG. This is evaluated by peers who tested your product, and tutors.

    Q Compared to AddressBoook-Level3 (AB3), the overall quality of the UG you evaluated is,
    Evaluate based on fit-for-purpose, from the perspective of a target user. For reference, the AB3 UG is here.

    Q Compared to AB3, the overall quality of the DG you evaluated is,
    Evaluate based on fit-for-purpose from the perspective of a new team member trying to understand the product's internal design by reading the DG. For reference, the AB3 DG is here.

    • Step 2: Evaluate how much of that effort can be attributed to you. This is evaluated by team members, and tutors.

    Q The team members' contribution to the User Guide is,

    Q The team members' contribution to the Developer Guide is,

    • In addition, UG and DG bugs you received in the PE will be considered for grading this component.

    These are considered UG bugs (if they hinder the reader):

    Use of visuals

    • Not enough visuals e.g., screenshots/diagrams
    • The visuals are not well integrated to the explanation
    • The visuals are unnecessarily repetitive e.g., same visual repeated with minor changes

    Use of examples:

    • Not enough or too many examples e.g., sample inputs/outputs

    Explanations:

    • The explanation is too brief or unnecessarily long.
    • The information is hard to understand for the target audience. e.g., using terms the reader might not know

    Neatness/correctness:

    • looks messy
    • not well-formatted
    • broken links, other inaccuracies, typos, etc.
    • hard to read/understand
    • unnecessary repetitions (i.e., hard to see what's similar and what's different)

    These are considered DG bugs (if they hinder the reader):

    These are considered UG bugs (if they hinder the reader):

    Use of visuals

    • Not enough visuals e.g., screenshots/diagrams
    • The visuals are not well integrated to the explanation
    • The visuals are unnecessarily repetitive e.g., same visual repeated with minor changes

    Use of examples:

    • Not enough or too many examples e.g., sample inputs/outputs

    Explanations:

    • The explanation is too brief or unnecessarily long.
    • The information is hard to understand for the target audience. e.g., using terms the reader might not know

    Neatness/correctness:

    • looks messy
    • not well-formatted
    • broken links, other inaccuracies, typos, etc.
    • hard to read/understand
    • unnecessary repetitions (i.e., hard to see what's similar and what's different)

    UML diagrams:

    • Notation incorrect or not compliant with the notation covered in the module.
    • Some other type of diagram used when a UML diagram would have worked just as well.
    • The diagram used is not suitable for the purpose it is used.
    • The diagram is too complicated.

    Code snippets:

    • Excessive use of code e.g., a large chunk of code is cited when a smaller extract would have sufficed.

    Problems in User Stories. Examples:

    • Incorrect format
    • All three parts are not present
    • The three parts do not match with each other
    • Important user stories missing

    Problems in NFRs. Examples:

    • Not really a Non-Functional Requirement
    • Not scoped clearly (i.e., hard to decide when it has been met)
    • Not reasonably achievable
    • Highly relevant NFRs missing

    Problems in Glossary. Examples:

    • Unnecessary terms included
    • Important terms missing

    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.

    1. Project Grading: Product Design [ 5 marks]

    Evaluates:

    • how well your features fit together to form a cohesive product
      (not how many features or how big/novel/interesting/difficult the features are)
    • how well it matches the target user

    Evaluated by:

    • the teaching team (based on product demo and user guide)
    • peers from other teams (based on peer testing and user guide)

    Q Quality of the product design,
    Evaluate based on the User Guide and the actual product behavior.

    Criterion Unable to judge Low Medium High
    target user Not specified Clearly specified and narrowed down appropriately
    value proposition Not specified The value to target user is low. App is not worth using Some small group of target users might find the app worth using Most of the target users are likely to find the app worth using
    optimized for target user Not enough focus for CLI users Mostly CLI-based, but cumbersome to use most of the time Feels like a fast typist can be more productive with the app, compared to an equivalent GUI app without a CLI
    feature-fit Many of the features don't fit with others Most features fit together but a few may be possible misfits All features fit together to for a cohesive whole

    In addition, feature flaws reported in the PE will be considered when grading this aspect.

    Note that 'product design' or 'functionality' are not critical learning outcomes of the tP. Therefore, the bar you need to reach to get full marks will be quite low. For example, the Medium level in the rubric given in the panel above should be enough to achieve full marks. Similarly, only cases of excessive 'feature flaw' bugs will affect the score.

    These are considered feature flaws:
    The feature does not solve the stated problem of the intended user i.e., the feature is 'incomplete'
    Hard-to-test features
    Features that don't fit well with the product
    Features that are not optimized enough for fast-typists or target users