This site is from a past semester! The current version will be here when the new semester starts.
CS2113/T 2021 Jan-May
**Schedule**
  • 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
    • **Project Links**
     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
    •
    **Other Links**
  • 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 12 [Mon, Sep 6th] - Tutorial

    Guidance for the item(s) below:

    There is no formal tutorial in this week. Use the tutorial slot for project work.

    Attempt this question by yourself. The model answer will be released later.

    1 Exercise: test case design

    • Divide into two sub-teams and do the following exercises on the white board.

    1. What are the equivalence partitions for the parameter day of this method?

      /**
 * Returns true if the three values represent a valid day
 */
boolean isValidDay(int year, int month, int day) {

}

    2. What are the boundary values for the parameter day in the question above?

    3. Give 10 test inputs you would use for the parameter day in the question above.

    No tutorial this week. Take a break and prepare for the last burst of tP activities coming up soon.

    This tutorial is used for tP project demos. Demo instructions are repeated below for your easy reference.

    • Record a demo of all the product features, in a reasonable order.
      • You may choose to screen record each feature and tie it up (see the "Suggested tools" below for options), OR
      • Schedule + record a zoom meeting within the team, where you share your screens and do the demo.
    • The quality of the demo will not affect marks as long as it serves the purpose (i.e., demonstrates the product features). Hence, don't waste too much time on creating the video.
    • Audio explanations are strongly encouraged.
    • Annotations and other enhancements to the video are optional (those will not earn any extra marks).
    • All members taking part in the demo video is encouraged but not compulsory.
    • File name: [TEAM_ID][product Name].mp4 e.g.[CS2113-T09-2][Contacts Plus].mp4 (other video formats are acceptable but use a format that works on all major OS'es).
    • File size: Recommended to keep below 200MB. You can use a low resolution as long as the video is in usable quality.
    • Submission: Submit to LumiNUS (different folder).
    • Deadline: 2 days after the main deadline
    • Suggested tools:
      • Ink2Go: You can use this to record your screen and annotate if necessary. Here are some instructions from NUS CIT to help you get started.
      • Handbrake: A free/open-source tool to help convert videos to MP4.

    Demo Duration

    • Strictly 18 minutes for a 5-person team, 15 minutes for a 4-person team, 21 minutes for a 6-person team. Exceeding this limit will be penalized.

    Demo Target audience

    • Assume you are giving a demo to a higher-level manager of your company, to brief him/her on the current capabilities of the product. This is the first time they are seeing the new product you developed. The actual audience are the evaluators (the team supervisor and another tutor).

    Demo Scope

    • Start by giving an overview of the product so that the evaluators get a sense of the full picture early. Include the following:
      • What is it? e.g., FooBar is a product to ensure the user takes frequent standing-breaks while working.
      • Who is it for? e.g., It is for someone who works at a PC, prefers typing, and wants to avoid prolonged periods of sitting.
      • How does it help? Give an overview of how the product's features help to solve the target problem for the target user

    Here is an example:

    Hi, welcome to the demo of our product FooBar. It is a product to ensure the user takes
frequent standing-breaks while working.
It is for someone who works at a PC, prefers typing, and wants to avoid prolonged periods
of sitting.
The user first sets the parameters such as frequency and targets, and then enters a
command to record the start of the sitting time, ... The app shows the length of the
sitting periods, and alerts the user if ...
...
    • There is no need to introduce team members or explain who did what. Reason: to save time.
    • Present the features in a reasonable order: Organize the demo to present a cohesive picture of the product as a whole, presented in a logical order.
    • No need to cover design/implementation details as the manager is not interested in those details.

    Demo Structure

    • Demo the product using the same executable you submitted
    • Use a sufficient amount of Mr aaa is not a realistic person namerealistic demo data. e.g at least 20 data items. Trying to demo a product using just 1-2 sample data creates a bad impression.

    Demo Tips

    • Plan the demo to be in sync with the impression you want to create. For example, if you are trying to convince that the product is easy to use, show the easiest way to perform a task before you show the full command with all the bells and whistles.