This site is from a past semester! The current version will be here when the new semester starts.
CS2103/T 2020 Jan-Apr
Schedule
  • Full Timeline
  • Week 1 [Jan 13]
  • Week 2 [Jan 20]
  • Week 3 [Jan 27]
  • Week 4 [Feb 3]
  • Week 5 [Feb 10]
  • Week 6 [Feb 17]
  • Week 7 [Mar 2]
  • Week 8 [Mar 9]
  • Week 9 [Mar 16]
  • Week 10 [Mar 23]
  • Week 11 [Mar 30]
  • Week 12 [Apr 6]
  • Week 13 [Apr 13]
  • Textbook
  • Admin Info
    • Links
  • Report Bugs
  • Forum
  • Instructors
  • Announcements
  • File Submissions
  • Tutorial Schedule
  • Java Coding Standard
  • Participation Marks List
    •  Individual Project (iP):
  • Individual Project Info
  • Duke Upstream Repo
  • iP Code Dashboard
  • iP Showcase
    •  Team Project (tP):
  • Team Project Info
  • Team IDs
  • Addressbook-level3
  • Addressbook-level 1,2,4
  • tP Code Dashboard
  • tP Showcase
    •

    • tP: mid-v1.3 [week 10] tP: mid-v1.4 [week 12]


    tP: v1.3 [week 11]

    1. Deliver the feature
    2. Update user docs
    3. Release as a jar file
    4. Wrap up v1.3
    5. Attend the practical exam dry run During the lecture

    1 Deliver the feature

    • Ideally, this version of the feature should be a release-candidate for the v1.4 i.e., has the functionality expected of v1.4.

    2 Update user docs

    • v1.3 user guide should be updated to match the current version of the product. Reason: testers will need to refer to the UG during the practical exam dry run.

      • Clearly indicate which features are not implemented yet e.g. tag those features with a Coming in v2.0.
      • For those features already implemented, ensure their descriptions match the exact behavior of the product e.g. replace mockups with actual screenshots

    • README page: Update to look like a real product (rather than a project for learning SE) if you haven't done so already. In particular, update the Ui.png to match the current product ( tips).

     

    Some common sense tips for a good product screenshot

    Ui.png represents your product in its full glory.

    • Before taking the screenshot, populate the product with data that makes the product look good. For example,
    • If the product is supposed to show photos, use real photos instead of dummy placeholders.
    • If the product doesn't have nice line wrapping for long inputs/outputs, don't use such inputs/outputs for the screenshot.
    • It should show a state in which the product is well-populated i.e., don't leave data panels largely blank
    • Choose a state that showcase the main features of the product i.e., the login screen is not usually a good choice
    • Take a clean screenshot with a decent resolution. Some screenshot tools can capture a specified window only. If your tool cannot do that, make sure you crop away the extraneous parts captured by the screenshot.
    • Avoid annotations (arrows, callouts, explanatory text etc.); it should look like the product is in use for real.
     

    Reason: Distracting annotations.

      

    Reason: Not enough data.

      

    Reason: screenshot not cropped cleanly (contains extra background details)

      

    3 Release as a jar file

    • Do a resulting in a jar file on GitHub that can be downloaded by potential usersproper product release as described in the Developer Guide. Do some manual tests to ensure the jar file works.

    4 Wrap up v1.3

    • as before

    5 Attend the practical exam dry run During the lecture

    • See info in the panel below:


    tP: mid-v1.3 [week 10] tP: mid-v1.4 [week 12]