This site is from a past semester! The current version is here.
CS2113/T Aug '19
  • Week 1 [Aug 12]
  • Week 2 [Aug 19]
  • Week 3 [Aug 26]
  • Week 4 [Sep 2]
  • Week 5 [Sep 9]
  • Week 6 [Sep 16]
  • Week 7 [Sep 30]
  • Week 8 [Oct 7]
  • Week 9 [Oct 14]
  • Week 10 [Oct 21]
  • Week 11 [Oct 28]
  • Week 12 [Nov 4]
  • Week 13 [Nov 11]
  • Textbook
  • Admin Info
  • Report Bugs
  • Slack
  • Forum
  • Project Info
  • Instructors
  • Announcements
  • File Submissions
  • Tutorial Schedule
  • Duke
  • Project Phase1 Dashboard
  • Java Coding Standard
  • samplerepo-things
  • Projects List
  • config.json templates for Reposense
  • PersonalAssistant-Duke
  • Project Phase2 Dashboard
  • Reference project - Addressbook
  • Repl.it classroom
  • Previous Week

    Week 13 [Nov 11]

    Project Milestone: v1.4

    Final tweaks to docs/product, release product, demo product, evaluate peer projects.

    Summary of submissions:

    Team/Individual Item Name format Upload to
    Source code tag as v1.4 GitHub
    Jar file [team][product name].jar
    e.g. [CS2113T-F10-3][ContactsPlus].jar
    LumiNUS
    User Guide [TEAM_ID][product Name]UserGuide.pdf
    e.g.[CS2113T-F10-3][Contacts Plus]UserGuide.pdf
    LumiNUS
    Developer Guide [TEAM_ID][product Name]DeveloperGuide.pdf
    e.g. [CS2113T-F10-3][Contacts Plus]DeveloperGuide.pdf
    LumiNUS
    Product Website README page, Ui.png, AboutUs page GitHub
    Project Portfolio Page [TEAM_ID][Your Name]PPP.pdf
    e.g.[CS2113T-F10-3][John Doe]PPP.pdf
    LumiNUS
    • Deadline for all v1.4 submissions is Week 13 Monday 23.59 unless stated otherwise.
    • Submit to LumiNUS folder we have set up, not to your project space.
      • CS2113T students: documents should be submitted to both modules. It's not enough to submit to CS2101 side only.
    • Penalty for late submission:
      -1 mark for missing the deadline (up to 2 hour of delay).
      -2 for an extended delay (up to 24 hours late).
      Penalty for delays beyond 24 hours is determined on a case by case basis.
      • Even a one-second delay is considered late, irrespective of the reason.
      • For submissions done via LumiNUS, the submission time is the timestamp shown by LumiNUS.
      • When determining the late submission penalty, we take the latest submission even if the same exact file was submitted earlier. Do not submit the same file multiple times if you want to avoid unnecessary late submission penalties.
    • The whole team is penalized for problems in team submissions. Only the respective student is penalized for problems in individual submissions.
    • Please follow submission instructions closely. Any non-compliance will be penalized. e.g. wrong file name, wrong file format, etc.
    • For pdf submissions, ensure the file is usable and hyperlinks in the file are correct. Problems in documents are considered bugs too  e.g. broken links, outdated diagrams/instructions etc..
    • Do not update the repo during the 14 days after the deadline. Get our permission first if you need to update the repo during that freeze period. You can continue to evolve your repo after that.

    Grading:

    Described in [Admin: Project: Assessment]

    v1.4 Product

    Relevant: [Admin Project → Deliverables → Executable ]

     
    • The product should be delivered as an executable jar file.
    • Ideally, the product delivered at v1.4 should be a releasable product. However, in the interest of lowering your workload, we do not penalize if the product is not releasable, as long as the product is acceptance testable.

    Submission: See summary of submissions above

    v1.4 Source Code

    Relevant: [Admin Project → Deliverables → Source Code ]

     
    • The source code should match the executable, and should include the revision history of the source code, as a Git repo.

    Submission: Push the code to GitHub and tag with the version number. Source code (please ensure the code reported by RepoSense as yours is correct; any updates to RepoSense config files or @@author annotations after the deadline will be considered a later submission). Note that the quality of the code attributed to you accounts for a significant component of your final score, graded individually.

    v1.4 User Guide

    Relevant: [Admin Project → Deliverables → User Guide ]

     
    • The User Guide (UG) of the product should match the proposed v2.0 of the product and in sync with the current version of the product.
    • Features not implemented yet should be clearly marked as Coming in v2.0
    • Ensure the UG matches the product precisely, as it will be used by peer testers (and any inaccuracy in the content will be considered bugs).

    Submission: Submit the pdf file to LumiNUS. See summary of submissions above for the file name format.

    • If you have used adoc to write your documentation, ensure that all necessary pages are included in the rendered HTML file. Convert the HTML to PDF and submit the PDF on Luminus.

    v1.4 Developer Guide

    Relevant: [Admin Project → Deliverables → Developer Guide ]

     
    • The Developer Guide (DG) of the product should match the proposed v2.0 of the product and should be in sync with the current version of the product.
    • The appendix named Instructions for Manual Testing of the Developer Guide should include testing instructions to cover the features of each team member.
      💡 What to include in the appendix Instructions for Manual Testing? This appendix is meant to give some guidance to the tester to chart a path through the features, and provide some important test inputs the tester can copy-paste into the app. There is no need to give a long list of test cases including all possible variations. It is upto the tester to come up with those variations. However, if the instructions are inaccurate or deliberately misses/mis-states information to make testing harder  i.e. annoys the tester, the tester can report it as a bug  (because flaws in developer docs are considered as bugs).
    • Ensure the DG parts included in PPPs match the product precisely, as PPPs will be used by peer evaluators (and any inaccuracy in the content will be considered bugs).

    Submission: Similar to UG

    v1.4 Project Portfolio Page (PPP)

    Relevant: [Admin Project → Deliverables → Project Portfolio Page ]

     

    At the end of the project each student is required to submit a Project Portfolio Page.

    • Objective:

      • For you to use  (e.g. in your resume) as a well-documented data point of your SE experience
      • For us to use as a data point to evaluate your,
        • contributions to the project
        • your documentation skills
    • Sections to include:

      • Overview: A short overview of your product (can use the product introduction you wrote earlier) to provide some context to the reader.

      • Summary of Contributions:

        • Code contributed: Give a link to your code on Project Code Dashboard, which should be https://nuscs2113-ay1920s1.github.io/dashboard/#=undefined&search=github_username_in_lower_case (replace github_username_in_lower_case with your actual username in lower case e.g., johndoe). This link is also available in the Project List Page -- linked to the icon under your photo.
        • Features implemented: A summary of the features you implemented. If you implemented multiple features, you are recommended to indicate which one is the biggest feature.
        • Other contributions:
          • Contributions to project management e.g., setting up project tools, managing releases, managing issue tracker etc.
          • Evidence of helping others e.g. responses you posted in our forum, bugs you reported in other team's products,
          • Evidence of technical leadership e.g. sharing useful information in the forum
      • Relevant descriptions/terms/conventions: Include all relevant details necessary to understand the document, e.g., conventions, symbols or labels introduced by you, even if it was not introduced by you.

      • Contributions to the User Guide: Reproduce the parts in the User Guide that you wrote. This can include features you implemented as well as features you propose to implement.
        The purpose of allowing you to include proposed features is to provide you more flexibility to show your documentation skills. e.g. you can bring in a proposed feature just to give you an opportunity to use a UML diagram type not used by the actual features.

      • Contributions to the Developer Guide: Reproduce the parts in the Developer Guide that you wrote. Ensure there is enough content to evaluate your technical documentation skills and UML modelling skills. You can include descriptions of your design/implementations, possible alternatives, pros and cons of alternatives, etc.

      • If you plan to use the PPP in your Resume, you can also include your SE work outside of the module (will not be graded)

    • Format:

      • File name: [TEAM_ID]-[Your Name]PPP.pdf e.g., [AY1920S1-CS2113T-F10-3][John Doe]PPP.pdf

      • Use one-half spacing between the lines for legibility

      • Follow this example. A PDF version of the same has been uploaded on LumiNUS.

      • 💡 You are free to choose any (collaborative) software to write the documents. However, try to follow the format of the sample user guide, developer guide and PPP given.

      • Do note that extra effort is needed in duplicating and maintaining consistency across UG/DG and PPP. This is a cost of not using automated document generation.

      • It is assumed that all contents in the PPP were written primarily by you. If any section is written by someone else  e.g. someone else described the feature in the User Guide but you implemented the feature, clearly state that the section was written by someone else  (e.g. Start of Extract [from: User Guide] written by Jane Doe).  Reason: Your writing skills will be evaluated based on the PPP

    • Page limit:

      Content Limit
      Overview + Summary of contributions 0.5-1 (soft limit)
      Contributions to the User Guide 2-4 (soft limit)
      Contributions to the Developer Guide 3-5 (soft limit)
      Total 5-8 (strict)
      • Reason for page limit: These submissions are peer-graded (in the PE) which needs to be done in a limited time span.

      • If you have more content than the limit given above, you can give a representative samples of UG and DG that showcase your documentation skills. Those samples should be understandable on their own. For the parts left-out, you can give an abbreviated version and refer the reader to the full UG/DG for more details.

      • It's similar to giving extra details as appendices; the reader will look at the UG/DG if the PPP is not enough to make a judgment. For example, when judging documentation quality, if the part in the PPP is not well-written, there is no point reading the rest in the main UG/DG. That's why you need to put the most representative part of your writings in the PPP and still give an abbreviated version of the rest in the PPP itself. Even when judging the quantity of work, the reader should be able to get a good sense of the quantity by combining what is quoted in the PPP and your abbreviated description of the missing part. There is no guarantee that the evaluator will read the full document.

    Submission: Similar to UG

    v1.4 Product Website

    Relevant: [Admin Project → Deliverables → Product Website ]

     
    • Include an updated version of the online UG and DG that match v1.4 executable
    • README :
      • Ensure the Ui.png matches the current product

    💡 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.
    • 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
    • Avoid annotations (arrows, callouts, explanatory text etc.); it should look like the product is being in use for real.
         
    • AboutUs : Ensure the following:
      • Use a suitable profile photo
    • The purpose of the profile photo is for the teaching team to identify you. Therefore, you should 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 can request permission to omit your photo from the page by writing to prof.

    • Contains a link to each person's Project Portfolio page
    • Team member names match full names used by LumiNUS

    Submission: Push the code to GitHub. Ensure the website is auto-published.

    v1.4 Demo

    Relevant: [Admin Project → Deliverables → Demo ]

     
    • Duration: Strictly 18 minutes for a 5-person team and 15 minutes for a 4-person team. Exceeding this limit will be penalized. Any set up time will be taken out of your allocated time.

    • 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 but they are familiar with CLI based products. The actual audience are the evaluators (the team supervisor and another tutor).

    • Scope:

      • Each person should demo the enhancements they added. However, it's ok for one member to do all the typing.
      • Subjected to the constraint mentioned in the previous point, as far as possible, organize the demo to present a cohesive picture of the product as a whole, presented in a logical order.  Remember to explain the profile of the target user profile and value proposition early in the demo.
      • It is recommended you showcase how the feature improves the user’s life rather than simply describe each feature.
      • No need to cover design/implementation details as the manager is not interested in those details.
      • Mention features you inherited from Duke only if they are needed to explain your new features.  Reason: existing features will not earn you marks, and the audience is already familiar with Duke features.
    • Structure:

      • Demo the product using the same executable you submitted, on your own laptop, using the TV.
      • It can be a sitting down demo: You'll be demonstrating the features using the TV while sitting down. But you may stand around the TV if you prefer that way.
      • It will be an uninterrupted demo: The audience members will not interrupt you during the demo. That means you should finish within the given time.
      • The demo should use a sufficient amount of realistic demo data.  e.g at least 20 data items. Trying to demo a product using just 1-2 sample data creates a bad impression.
      • Dress code : The level of formality is up to you, but it is recommended that the whole team dress at the same level.
    • Optimizing the time:

      • Spend as much time as possible on demonstrating the actual product. Not recommended to use slides (if you do, use them sparingly) or videos or lengthy narrations.
        Avoid skits, re-enactments, dramatizations etc. This is not a sales pitch or an informercial. While you need to show how a user use the product to get value, but you don’t need to act like an imaginary user. For example, [Instead of this] Jim get’s a call from boss. "Ring ring", "hello", "oh hi Jim, can we postpone the meeting?" "Sure". Jim hang up and curses the boss under his breath. Now he starts typing ..etc. [do this] If Jim needs to postpone the meeting, he can type … It’s not that dramatization is bad or we don’t like it. We simply don’t have enough time for it.
        Note that CS2101 demo requirements may differ. Different context → Different requirements.
      • Rehearse the steps well and ensure you can do a smooth demo. Poor quality demos can affect your grade.
      • Don’t waste time repeating things the target audience already knows. e.g. no need to say things like "We are students from NUS, SoC".
      • 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.
    • Special circumstances:

      • If a significant feature was not merged on time: inform the evaluator and get permission to show the unmerged feature using your own version of the code. Unmerged features earn much less marks than a merged equivalent but something is better than nothing.
      • If you have no user visible features to show, you can still contribute to the demo by giving an overview of the product (at the start) and/or giving a wrap of of the product (at the end).
      • If you are unable to come to the demo due to a valid reason, you can ask a team member to demo your feature. Remember to submit the evidence of your excuse e.g., MC to prof. The demo is part of module assessment and absence without a valid reason will cause you to lose marks.

    • Venue: Same as the tutorial venue unless informed otherwise.
    • Schedule: Your demo timing is same as your tutorial time in week 13.
      • Please arrive on time and remain outside the venue until called in.
      • There is an automatic penalty if you are not ready to start on time.
      • You should bring your own adapter if the display adapters available in your tutorial venue don't work for you.

    v1.4 Practical Exam

    Relevant: [Admin Project → Deliverables → Practical Exam ]

     

    Objectives:

    • Evaluate your manual testing skills, product evaluation skills, effort estimation skills
    • Peer-evaluate your product design , implementation effort , documentation quality
      • Note that significant project components are not graded solely based on peer ratings. Rather, PE data are mostly used to cross-validate tutors' grades and identify cases that need further investigation. When peer inputs are used for grading, they are usually combined with tutor evaluations with appropriate weight for each. In some cases ratings from team members are given a higher weight compared to ratings from other peers, if that is appropriate.
    • Do note that the PE is not a means of pitting you against each other. Developers and testers play for the same side; they need to push each other to improve the quality of their work -- not bring down each other.

    Grading:

    • Your performance in the practical exam will be considered for your final grade (under the QA category and under Implementation category, about 10 marks in total).
    • You will be graded based on your effectiveness as a tester (e.g., the percentage of the bugs you found, the nature of the bugs you found) and how far off your evaluation/estimates are from the evaluator consensus. Explanation: we understand that you have limited expertise in this area; hence, we penalize only if your inputs don't seem to be based on a sincere effort to test/evaluate.
    • The bugs found in your product by others will affect your v1.4 marks. You will be given a chance to reject false-positive bug reports.

    Preparation:

    • Similar to PE-Dry run
    • Ensure that you have accepted the invitation to join the GitHub org used by the module. Go to https://github.com/nusCS2113-AY1920S1 to accept the invitation.
      • If you cannot find the invitation, post in our forum.
    • Ensure you have access to a computer that is able to run module projects  e.g. has the right Java version.
    • Download the latest CATcher and ensure you can run it on your computer.
    • Create a public repo in your GitHub account with the following name:
      • PE Dry Run: ped
      • PE: pe
    • Enable its issue tracker and add the following labels to it (the label names should be precisely as given).

    Bug Severity labels:

    • severity.Low : A flaw that is unlikely to affect normal operations of the product. Appears only in very rare situations and causes a minor inconvenience only.
    • severity.Medium : A flaw that causes occasional inconvenience to some users but they can continue to use the product.
    • severity.High : A flaw that affects most users and causes major problems for users. i.e., makes the product almost unusable for most users.

    Bug Type Labels:

    • type.FeatureFlaw: some functionality missing from a feature delivered in v1.4 in a way that the feature becomes less useful to the intended target user for normal usage. i.e., the feature is not 'complete'. In other words, an acceptance testing bug that falls within the scope of v1.4 features. These issues are counted against the 'depth and completeness' of the feature.
    • type.FunctionalityBug: the bug is a flaw in how the product works.
    • type.DocTypo: A minor spelling/grammar error in the documentation. Does not affect the user.
    • type.DocumentationBug: A flaw in the documentation that can potentially affect the user e.g., a missing step, a wrong instruction
    • Have a good screen grab tool with annotation features so that you can quickly take a screenshot of a bug, annotate it, and post in the issue tracker.

      • 💡 You can use Ctrl+V to paste a picture from the clipboard into a text box in GitHub issue tracker.
    • Download the product to be tested after you have been notified of which team you have been allocated to test.

      • Do this before you come to the testing session to minimize the network clogging due to large number of downloads happening at once.
    • Charge your computer before coming to the PE session. The testing venue (lecture theatre) does not have enough charging points.

    Phase 1: Testing / bug reporting

    When, where: Week 13 lecture

    Testing
    1. Take note of your team to test. It will be given to you by the teaching team (distributed via LumiNUS gradebook).
    2. Download from LumiNUS all files submitted by the team (i.e. jar file, User Guide, Developer Guide, and Project Portfolio Pages) into an empty folder.
    3. [60 minutes] Test the product and report bugs as described below:
    Testing instructions for PE and PE Dry Run

    Launching the JAR file

    • Put the jar file in an empty folder.
    • Open a command window. Run the java -version command to ensure you are using Java 11.
    • Launch the jar file using the java -jar command (do not use double-clicking).
    • If the product doesn't work at all: If the product fails catastrophically e.g., cannot even launch, you can test the fallback team allocated to you. But in this case you must inform us immediately during/after the session so that we can send your bug reports to the correct team.
      • PE-D: Download the JAR file from their GitHub page
      • PE: Download from LumiNUS all files submitted by the team (i.e. jar file, User Guide, Developer Guide, and Project Portfolio Pages) into an empty folder.

    What to test:

    • PE Dry Run (at v1.3):
      • Test the product based on the User Guide (the UG is most likely accessible using the help command).
      • Do system testing first i.e., does the product work as specified by the documentation?. If there is time left, you can do acceptance testing as well i.e., does the product solve the problem it claims to solve?.
    • PE (at v1.4):
      • Test based on the Developer Guide (Appendix named Instructions for Manual Testing) and the User Guide. The testing instructions in the Developer Guide can provide you some guidance but if you follow those instructions strictly, you are unlikely to find many bugs. You can deviate from the instructions to probe areas that are more likely to have bugs.
      • As before, do both system testing and acceptance testing but give priority to system testing as system testing bugs can earn you more credit.

    These are considered bugs:

    • Behavior differs from the User Guide (or Developer Guide)
    • A legitimate user behavior is not handled e.g. incorrect commands, extra parameters
    • Behavior is not specified and differs from normal expectations e.g. error message does not match the error
    • The feature does not solve the stated problem of the intended user i.e., the feature is 'incomplete'
    • Problems in the User Guide e.g., missing/incorrect info

    About posting suggestions:

    • PE Dry Run (at v1.3): You can also post suggestions on how to improve the product. 💡 Be diplomatic when reporting bugs or suggesting improvements. For example, instead of criticising the current behavior, simply suggest alternatives to consider.
    • PE (at v1.4): Do not post suggestions. But if a feature is missing a critical functionality that makes the feature less useful to the intended user, it can be reported as a bug.

    How/where/when to report bugs:

    • Post bugs as you find them (i.e., do not wait to post all bugs at the end) because bugs filed outside the testing duration will not be considered.
      • Do not use team ID in bug reports. Reason: to prevent others copying your bug reports
    • Launch CATcher, and login to the correct profile:
      • PE Dry Run: CS2113/T PE Dry run
      • PE: CS2113/T PE
    • Post bugs using CATcher.
    • Post bug reports in the following repo you created earlier:
      • PE Dry Run: ped
      • PE: pe

    Bug report format:

    • Each bug should be a separate issue.
    • Write good quality bug reports; poor quality (e.g., giving only screenshot with no description, details incomplete, etc.,) or incorrect bug reports will not earn credit.
    • Use a descriptive title.
    • Give a good description of the bug with steps to reproduce and screenshots.
    • Assign exactly one severity.* label to the bug report. Bug report without a severity label are considered severity.Low (lower severity bugs earn lower credit).

    Bug Severity labels:

    • severity.Low : A flaw that is unlikely to affect normal operations of the product. Appears only in very rare situations and causes a minor inconvenience only.
    • severity.Medium : A flaw that causes occasional inconvenience to some users but they can continue to use the product.
    • severity.High : A flaw that affects most users and causes major problems for users. i.e., makes the product almost unusable for most users.
    • Assign exactly one type.* label to the bug report. Bug report without a severity label are considered severity.Low (lower severity bugs earn lower credit).

    Bug Type Labels:

    • type.FeatureFlaw: some functionality missing from a feature delivered in v1.4 in a way that the feature becomes less useful to the intended target user for normal usage. i.e., the feature is not 'complete'. In other words, an acceptance testing bug that falls within the scope of v1.4 features. These issues are counted against the 'depth and completeness' of the feature.
    • type.FunctionalityBug: the bug is a flaw in how the product works.
    • type.DocTypo: A minor spelling/grammar error in the documentation. Does not affect the user.
    • type.DocumentationBug: A flaw in the documentation that can potentially affect the user e.g., a missing step, a wrong instruction
    Product evaluation

    [Remainder of the session] Evaluate the following aspects. Note down your evaluation in a hard copy (as a backup). Submit via TEAMMATES. You are recommended to complete this during the PE session but you have until the end of the day to submit (or revise) your submissions.

    • A. Product Design []:
      Evaluate the product design based on how the product V2.0 (not V1.4) is described in the User Guide.

      • unable to judge: You are unable to judge this aspect for some reason e.g., UG is not available or does not have enough information.
      • target user specified and appropriate: The target user is clearly specified, prefers typing over other modes of input, and not too general (should be narrowed to a specific user group with certain characteristics).
      • value specified and matching: The value offered by the product is clearly specified and matches the target user.
      • value: low: The value to target user is low. App is not worth using.
      • value: medium: Some small group of target users might find the app worth using.
      • value: high: Most of the target users are likely to find the app worth using.
      • feature-fit: low: Features don't seem to fit together.
      • feature-fit: medium: Some features fit together but some don't.
      • feature-fit: high: All features fit together.
      • polished: The product looks well-designed.
    • B. Quality of user docs []:
      Evaluate based on the parts of the user guide written by the person, as reproduced in the project portfolio. Evaluate from an end-user perspective.

      • UG/ unable to judge: Less than 1 page worth of UG content written by the student or cannot find PPP
      • UG/ good use of visuals: Uses visuals e.g., screenshots.
      • UG/ good use of examples: Uses examples e.g., sample inputs/outputs.
      • UG/ just enough information: Not too much information. All important information is given.
      • UG/ easy to understand: The information is easy to understand for the target audience.
      • UG/ polished: The document looks neat, well-formatted, and professional.
    • C. Quality of developer docs []:
      Evaluate based on the developer docs cited/reproduced in the respective project portfolio page. Evaluate from the perspective of a new developer trying to understand how the features are implemented.

      • DG/ unable to judge: Less than 0.5 pages worth of content OR other problems in the document e.g. looks like included wrong content.
      • DG/ too little: 0.5 - 1 page of documentation
      • DG/ types of UML diagrams: 1: Only one type of diagram used (types: Class Diagrams, Object Diagrams, Sequence Diagrams, Activity Diagrams, Use Case Diagrams)
      • DG/ types of UML diagrams: 2: Two types of diagrams used
      • DG/ types of UML diagrams: 3+: Three or more types of diagrams used
      • DG/ UML diagrams suitable: The diagrams used for the right purpose
      • DG/ UML notation correct: No more than one minor error in the UML notation
      • DG/ diagrams not repetitive: Same diagram is not repeated with minor differences
      • DG/ diagrams not too complicated: Diagrams don't cram too much information into them
      • DG/ diagrams integrates with text: Diagrams are well integrated into the textual explanations
      • DG/ easy to understand: The document is easy to understand/follow
      • DG/ just enough information: Not too much information. All important information is given.
      • DG/ polished: The document looks neat, well-formatted, and professional.
    • D. Feature Quality []:
      Evaluate the biggest feature done by the student for difficulty, completeness, and testability. Note: examples given below assume that AB3 did not have the commands edit, undo, and redo.

      • Feature/ difficulty: unable to judge: You are unable to judge this aspect for some reason.
      • Feature/ difficulty: low: e.g. make the existing find command case insensitive.
      • Feature/ difficulty: medium: e.g. an edit command that requires the user to type all fields, even the ones that are not being edited.
      • Feature/ difficulty: high: e.g., undo/redo command
      • Feature/ completeness: unable to judge: You are unable to judge this aspect for some reason.
      • Feature/ completeness: low: A partial implementation of the feature. Barely useful.
      • Feature/ completeness: medium: The feature has enough functionality to be useful for some of the users.
      • Feature/ completeness: high: The feature has all functionality to be useful to almost all users.
      • Feature/ not hard to test: The feature was not too hard to test manually.
      • Feature/ polished: The feature looks polished (as if done by a professional programmer).
    • E. Amount of work []:
      Evaluate the amount of work, on a scale of 0 to 30.

      • Consider this PR (history command) as 5 units of effort which means this PR (undo/redo command) is about 15 points of effort. Given that 30 points matches an effort twice as that needed for the undo/redo feature (which was given as an example of an A grade project), we expect most students to be have efforts lower than 20.
      • Count all implementation/testing/documentation work as mentioned in that person's PPP. Also look at the actual code written by the person.
      • Do not give a high value just to be nice. If your estimate is wildly inaccurate, it means you are unable to estimate the effort required to implement a feature in a project that you are supposed to know well at this point. You may lose marks if your estimate is wildly inaccurate

    Phase 2: Developer response phase

    Duration: The review period will start around 1 day after the PE (exact time to be announced) and will last until the following Tuesday midnight. However, you are recommended to finish this task ASAP, to minimize cutting into your exam preparation work.

    Bug reviewing is recommended to be done as a team as some of the decisions need team consensus.

    Instructions for Reviewing Bug Reports

    • First, don't freak out if there are lot of bug reports. Many can be duplicates and some can be false positives. In any case, we anticipate that all of these products will have some bugs and our penalty for bugs is not harsh. Furthermore, it depends on the severity of the bug. Some bug may not even be penalized.
    • CATcher does not come with a UG, but the UI is fairly intuitive (there are tool tips too). Do post in the forum or ask in slack if you need any guidance with its usage.
    • Also note that CATcher hasn't been battle-tested for this phase, in particular, w.r.t. multiple team members editing the same issue concurrently. It is ideal if the team members get together and work through the issues together. If you think others might be editing the same issues at the same time, use the Sync button at the top to force-sync your view with the latest data from GitHub.
  • Launch CATcher, and login to the profile CS2113/T PE. It will show all the bugs assigned to your team, divided into three sections:
    1. Issues Pending Responses - Issues that your team has not processed yet.
    2. Issues Responded - Your job is to get all issues to the second category.
    3. Faulty Issues - e.g., Bugs marked as duplicates of each other, or causing circular duplicate relationships. Fix the problem given so that no issues remain in this category.
  • Respond to the bug reports shown.
  • Issues created for PE-D and PE need to be in a precise format for our grading scripts to work. Incorrectly-formatted responses will have to discarded. Therefore, you are strongly recommended to use CATcher for PE-D and PE activities. If you want to give your response via GitHub instead, please get our permission first.

    • Go to the dev-response issue tracker
    • Use tutorial.* and team.* labels to filter bug reports your team received.
    • Do not edit the subject or the description. Your response (if any) should be added as a comment.
    • Add a comment using the following exact template.
      # Team's Response
      {replace this with your response}
      

      ## Duplicate status (if any):

      Here is an example:
      # Team's Response

      Yes this is a bug. But it is a duplicate. * Changed the bug type because this is just a bug in the UG. * Lowered the severity because users can still use the feature.

      ## Duplicate status (if any): Duplicate of #67

    • Do not close the bug report after you are done processing it.
    • Use the exact Duplicate of #123 format to indicate duplicates.
    • There should be exactly one comment per issue. If there are multiple comments, the last one will be taken for processing.
    • If a bug seems to be for a different product (i.e. wrongly assigned to your team), let us know ASAP (email prof).

    • If the bug is reported multiple times,

      • Mark all copies EXCEPT one as duplicates of the one left out (let's call that one the original) using the duplicate tag.
      • If the duplicates have different severity levels, you should keep the one with the highest severity as the original. But you can downgrade the severity of the original or the duplicates.
      • For each group of duplicates, all duplicates should point to one original i.e., no multiple levels of duplicates, and no cyclical duplication relationships.
      • If the duplication status is eventually accepted, all duplicates will be assumed to have inherited the type.* and severity.* from the original.

    • Apply exactly one of these labels (if missing, we assign: response.Accepted)

    Response Labels:

    • response.Accepted: You accept it as a bug.
    • response.NotInScope: It is a valid issue but not something the team should be penalized for e.g., it was not related to features delivered in v1.4.
    • response.Rejected: What tester treated as a bug is in fact the expected behavior. The may lose marks for rejecting a bug without an explanation or using an unjustifiable explanation.
    • response.CannotReproduce: You are unable to reproduce the behavior reported in the bug after multiple tries.
    • response.IssueUnclear: The issue description is not clear. Don't post comments asked the tester to give more info. The tester will not be able to see those comments because the bug reports are anonymized.
    • Apply exactly one of these labels (if missing, we assign: type.FunctionalityBug)

    Bug Type Labels:

    • type.FeatureFlaw: some functionality missing from a feature delivered in v1.4 in a way that the feature becomes less useful to the intended target user for normal usage. i.e., the feature is not 'complete'. In other words, an acceptance testing bug that falls within the scope of v1.4 features. These issues are counted against the 'depth and completeness' of the feature.
    • type.FunctionalityBug: the bug is a flaw in how the product works.
    • type.DocTypo: A minor spelling/grammar error in the documentation. Does not affect the user.
    • type.DocumentationBug: A flaw in the documentation that can potentially affect the user e.g., a missing step, a wrong instruction
    • If you disagree with the original severity assigned to the bug, you may change it to the correct level, in which case add a comment justifying the change. All such changes will be double-checked by the teaching team.

    Bug Severity labels:

    • severity.Low : A flaw that is unlikely to affect normal operations of the product. Appears only in very rare situations and causes a minor inconvenience only.
    • severity.Medium : A flaw that causes occasional inconvenience to some users but they can continue to use the product.
    • severity.High : A flaw that affects most users and causes major problems for users. i.e., makes the product almost unusable for most users.
    • Decide who should fix the bug. Use the Assignees field to assign the issue to that person(s). There is no need to actually fix the bug though. It's simply an indication/acceptance of responsibility. If there is no assignee, we will distribute the penalty for that bug (if any) among all team members.

      • If it is not easy to decide the assignee(s), we recommend (but not enforce) that the feature owner should be assigned bugs related to the feature, Reason: The feature owner should have defended the feature against bugs using automated tests and defensive coding techniques.

    • As far as possible, choose the correct type.*, severity.*, and assignees even for bugs you are not accepting or for bugs that are marked as duplicates. Reason: your non-acceptance or duplication status may be rejected in a later phase, in which case we need to grade it as an accepted/non-duplicate bug.

    • Justify your response. For all of the following cases, you must add a comment justifying your stance. Testers will get to respond to all those cases and will be double-checked by the teaching team in later phases. Indiscriminate/unreasonable dev/tester responses, if deemed as a case of trying to game the system, will be penalized.
      • downgrading severity
      • non-acceptance of a bug
      • changing the bug type
      • non-obvious duplicate

    Time/venue: week 13 lecture slot