This site is from a past semester! The current version will be here when the new semester starts.
CS2103/T 2020 Jan-Apr
  • 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
  • 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
  • Week 7 [Mar 2] - Project

    iP:

    1. Do any final clean-ups
    2. Submit the final version by Monday 2359

    tP: v1.1

    1. Update project website: AboutUs, ContactUs, README
    2. Update the UG
    3. Update the DG: user stories, glossary, NFRs, use cases
    4. Wrap up v1.1
    5. Draft a rough project plan
    6. start implementing a minimal version of your enhancement

    iP

    1 Do any final clean-ups

    • Finish leftover increments from the previous weeks, if any
    • Do any code cleanups, if necessary
    • Update the User Guide, if necessary

    2 Submit the final version by Monday 2359

    • Submission is to be done via GitHub releases. If there were any changes to the code since the last release, do a new release.
    • The jar file should be cross-platform and should work in a computer that has Java 11.

    Getting more out of the iP

    If you wish to cite the iP in your resume, you can do more to make it look more impressive to a potential employer. These improvements are not considered for grading and can be done after the semester is over. Some ideas:

    • Improve the GUI: Make the UI look nicer, unique, and memorable. You can get inspiration from what others have done (but remember to give credit if you reuse any code from them).
    • Add a demo video or an animated gif to your user guide to show how the app works.
    • Improve code quality: iP is the right size to cite as an example of your code quality. You can use the RepoSense link (</>) in the iP showcase page to point to your iP code.
    • Add more features.

    On a somewhat related note, you can also create similar product websites for your other projects (projects from other modules, pet projects).



    tP: v1.1

    1 Update project website: AboutUs, ContactUs, README

    Recommended procedure for updating docs:

    1. Divide among yourselves who will update which parts of the document(s).
    2. Update the team repo by following the recommended workflow.

    Update the following pages in your project repo:

    • About Us page: This page is used for module admin purposes. Please follow the format closely or else our scripts will not be able to give credit for your work.
      • Replace info of SE-EDU developers with info of your team. Include a suitable photo as described here.
      • Including the name/photo of the supervisor/lecturer is optional.
      • The filename of the profile photo (even a placeholder image) should be doc/images/githbub_username_in_lower_case.png e.g. docs/images/damithc.png. If your photo is in jpg format, name the file as .png anyway.
      • Indicate the different roles played and responsibilities held by each team member. You can reassign these roles and responsibilities (as explained in Admin Project Scope) later in the project, if necessary.
     

    The purpose of the profile photo is for the teaching team to identify you. Therefore, choose a recent individual photo showing your face clearly (i.e., not too small) -- somewhat similar to a passport photo. Some examples can be seen in the 'Teaching team' page. Given below are some examples of good and bad profile photos.

    If you are uncomfortable posting your photo due to security reasons, you can post a lower resolution image so that it is hard for someone to misuse that image for fraudulent purposes. If you are concerned about privacy, you may use a placeholder image in place of the photo in module-related documents that are publicly visible.

     

    Roles indicate aspects you are in charge of and responsible for. E.g., if you are in charge of documentation, you are the person who should allocate which parts of the documentation is to be done by who, ensure the document is in right format, ensure consistency etc.

    This is a non-exhaustive list; you may define additional roles.

    • Team lead: Responsible for overall project coordination.
    • Documentation (short for ‘in charge of documentation’): Responsible for the quality of various project documents.
    • Testing: Ensures the testing of the project is done properly and on time.
    • Code quality: Looks after code quality, ensures adherence to coding standards, etc.
    • Deliverables and deadlines: Ensure project deliverables are done on time and in the right format.
    • Integration: In charge of versioning of the code, maintaining the code repository, integrating various parts of the software to create a whole.
    • Scheduling and tracking: In charge of defining, assigning, and tracking project tasks.
    • [Tool ABC] expert: e.g. Intellij expert, Git expert, etc. Helps other team member with matters related to the specific tool.
    • In charge of[Component XYZ]: e.g. In charge of Model, UI, Storage, etc. If you are in charge of a component, you are expected to know that component well, and review changes done to that component in v1.3-v1.4.

    Ensure each of the important roles are assigned to one person in the team. It is OK to have a 'backup' for each role, but for each aspect there should be one person who is unequivocally the person responsible for it. Reason: when everyone is responsible for everything, no one is.

    • Contact Us Page: Update to match your product.

    • README.adoc page: Update it to match your project.

      • Add a UI mockup of your intended final product. Note that the image of the UI should be docs/images/Ui.png so that it can be downloaded by our scripts. Limit the file to contain one screenshot/mockup only and ensure the new image is roughly the same height x width proportions as the original one. Reason: when we compile these images from all teams into one page (example), yours should not look out of place.

      • The original README.adoc file (which doubles as the landing page of your project website) is written to read like the introduction to an SE learning/teaching resource. You should restructure this page to look like the home page of a real product (not a school project) targeting real users. For instance,

        • remove references to addressbook-level2
        • remove Learning Outcomes
        • mention your target users
        • add a marketing blurb
      • Update the link of the Travis build status badge (Build Status) so that it reflects the build status of your team repo. For the other badges,

        • either set up the respective tool for your project (AB3 Developer Guide has instructions on how to set up AppVeyor and Coveralls) and update the badges accordingly,
        • or remove the badge.
      • Acknowledge the original source of the code i.e. AddressBook-Level3 project created by SE-EDU initiative at https://se-education.org

    • Website heading: Update the website heading to match your product. Currently it is set to AddressBook Level 3 - ....

    If you updated the above pages correctly, details of your project in the Project List Page should look neat and complete i.e., no broken links.

    2 Update the UG

    • Move the draft UG into the User Guide page in your repository. If a feature is not implemented, mark it as 'Coming in v2.0' (example).
      As mentioned in week 6, we recommend that each person updates their own part of the docs so that we can easily track the contribution of each member using RepoSense.
      While it is more convenient for one person to update the entire UG, splitting the work will give you a good opportunity to learn to deal with merge conflicts.

    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.

    3 Update the DG: user stories, glossary, NFRs, use cases

    • Update the following in the DG, based on your project notes from the previous weeks.
      Some examples of these can be found in the AB3 Developer Guide.

      • Target user profile, value proposition, and user stories: Update the target user profile and value proposition to match the project direction you have selected. Give a list of the user stories (and update/delete existing ones, if applicable), including priorities. This can include user stories considered but will not be included in the final product.
      • Use cases: Give use cases (textual form) for a few representative user stories that need multiple steps to complete. e.g. Adding a tag to a person (assume the user needs to find the person first)
      • Non-functional requirements: Note: Many of the given project constraints can be considered NFRs. You can add more. e.g. performance requirements, usability requirements, scalability requirements, etc.
      • Glossary: Define terms that are worth recording.
      • [Optional] Product survey: Explore a few similar/related products and describe your findings i.e. Pros, cons, (from the target user's point of view).
     

    Requirements → Specifying Requirements → Use Cases →

    Introduction

    Use Case: A description of a set of sequences of actions, including variants, that a system performs to yield an observable result of value to an actor.[ 📖 : uml-user-guideThe Unified Modeling Language User Guide, 2e, G Booch, J Rumbaugh, and I Jacobson ]

    Actor: An actor (in a use case) is a role played by a user. An actor can be a human or another system. Actors are not part of the system; they reside outside the system.

    A use case describes an interaction between the user and the system for a specific functionality of the system.

    System: Online Banking System (OBS)
    Use case: UC23 - Transfer Money
    Actor: User
    MSS:
      1. User chooses to transfer money.
      2. OBS requests for details of the transfer.
      3. User enters the requested details.
      4. OBS requests for confirmation.
      5. User confirms.
      6. OBS transfers the money and displays the new account balance.
      Use case ends.
    
    Extensions:
      3a. OBS detects an error in the entered data.
        3a1. OBS requests for the correct data.
        3a2. User enters new data
        Steps 3a1-3a2 are repeated until the data entered are correct.
        Use case resumes from step 4.
      
      3b. User requests to effect the transfer in a future date.
          3b1. OBS requests for confirmation.
          3b2. User confirms future transfer.
          Use case ends.
      
      *a. At any time, User chooses to cancel the transfer.
          *a1. OBS requests to confirm the cancellation.
          *a2. User confirms the cancellation.
          Use case ends.
    
    • System: A Learning Management System (LMS)
    • Actor: Student
    • Use Case: Upload file
      1. Student requests to upload file
      2. LMS requests for the file location
      3. Student specifies the file location
      4. LMS uploads the file

    UML includes a diagram type called use case diagrams that can illustrate use cases of a system visually, providing a visual ‘table of contents’ of the use cases of a system.

    In the example on the right, note how use cases are shown as ovals and user roles relevant to each use case are shown as stick figures connected to the corresponding ovals.

    Unified Modeling Language (UML) is a graphical notation to describe various aspects of a software system. UML is the brainchild of three software modeling specialists James Rumbaugh, Grady Booch and Ivar Jacobson (also known as the Three Amigos). Each of them has developed their own notation for modeling software systems before joining force to create a unified modeling language (hence, the term ‘Unified’ in UML). UML is currently the de facto modeling notation used in the software industry.

    Use cases capture the functional requirements of a system.

     

    Requirements → Requirements →

    Non-Functional Requirements

    Requirements can be divided into two in the following way:

    1. Functional requirements specify what the system should do.
    2. Non-functional requirements specify the constraints under which system is developed and operated.

    Some examples of non-functional requirement categories:

    • Data requirements e.g. size, how often do data changevolatility, saving data permanenetlypersistency etc.,
    • Environment requirements e.g. technical environment in which system would operate or need to be compatible with.
    • Accessibility, Capacity, Compliance with regulations, Documentation, Disaster recovery, Efficiency, Extensibility, Fault tolerance, Interoperability, Maintainability, Privacy, Portability, Quality, Reliability, Response time, Robustness, Scalability, Security, Stability, Testability, and more ...
    • Business/domain rules: e.g. the size of the minefield cannot be smaller than five.
    • Constraints: e.g. the system should be backward compatible with data produced by earlier versions of the system; system testers are available only during the last month of the project; the total project cost should not exceed $1.5 million.
    • Technical requirements: e.g. the system should work on both 32-bit and 64-bit environments.
    • Performance requirements: e.g. the system should respond within two seconds.
    • Quality requirements: e.g. the system should be usable by a novice who has never carried out an online purchase.
    • Process requirements: e.g. the project is expected to adhere to a schedule that delivers a feature set every one month.
    • Notes about project scope: e.g. the product is not required to handle the printing of reports.
    • Any other noteworthy points: e.g. the game should not use images deemed offensive to those injured in real mine clearing activities.

    We may have to spend an extra effort in digging NFRs out as early as possible because,

    1. NFRs are easier to miss e.g., stakeholders tend to think of functional requirements first
    2. sometimes NFRs are critical to the success of the software. E.g. A web application that is too slow or that has low security is unlikely to succeed even if it has all the right functionality.

    Given below are some requirements of TEAMMATES (an online peer evaluation system for education). Which one of these are non-functional requirements?

    • a. The response to any use action should become visible within 5 seconds.
    • b. The application admin should be able to view a log of user activities.
    • c. The source code should be open source.
    • d. A course should be able to have up to 2000 students.
    • e. As a student user, I can view details of my team members so that I can know who they are.
    • f. The user interface should be intuitive enough for users who are not IT-savvy.
    • g. The product is offered as a free online service.

    (a)(c)(d)(f)(g)

    Explanation: (b) are (e) are functions available for a specific user types. Therefore, they are functional requirements. (a), (c), (d), (f) and (g) are either constraints on functionality or constraints on how the project is done, both of which are considered non-functional requirements.

     

    Requirements → Specifying Requirements → Glossary →

    What

    Glossary: A glossary serves to ensure that all stakeholders have a common understanding of the noteworthy terms, abbreviations, acronyms etc.

    Here is a partial glossary from a variant of the Snakes and Ladders game:

    • Conditional square: A square that specifies a specific face value which a player has to throw before his/her piece can leave the square.
    • Normal square: a normal square does not have any conditions, snakes, or ladders in it.
     

    Requirements → Gathering Requirements →

    Product Surveys

    Studying existing products can unearth shortcomings of existing solutions that can be addressed by a new product. Product manuals and other forms of documentation of an existing system can tell us how the existing solutions work.

    When developing a game for a mobile device, a look at a similar PC game can give insight into the kind of features and interactions the mobile game can offer.

    4 Wrap up v1.1

    • After all changes that can be merged before the milestone deadline have been merged, use git tag feature to tag the current version with the milestone v1.1 and push the tag to the team repo.

    5 Draft a rough project plan

    • Decide which enhancements each member will do by v1.4. We realize that it will be hard for you to estimate the effort required for each feature as you are not very familiar with the code base yet. Nevertheless, come up with a project plan as per your best estimate; this plan can be revised at later stages. It is better to start with some plan rather than no plan at all. If in doubt, choose to do less than more; we don't expect you to deliver a lot of big features anyway.

    • Divide each of those features into two increments, to be released at v1.2, v1.3 (v1.4 omitted deliberately as a buffer). Each increment should deliver a end-user visible enhancement.

      * Jake Woo: Profile photo feature
      * v1.2: show a place holder for photo, showing a generic default image
      * v1.3: can specify photo location if it is in local hard disk,
      show photo from local hard disk
    • Reflect the above plan in the issue tracker by assigning the corresponding issues (create new issues if necessary) to yourself and to the corresponding milestone. For example, the user story pertaining to the increment show a place holder for photo, showing a generic default image should be assigned to Jake and to milestone v1.2

    6 start implementing a minimal version of your enhancement

    • While we do not require you to do functionality changes in v1.1, if you have time, start implementing the version of your feature to be delivered in v1.2. We recommend that you break your v1.2 feature down to even smaller increments.