Week 13 [Fri, Nov 6th] - Project

• Should be an executable jar file.
• Should be i.e., it can be used by end-usersreleasable. While some features may be scheduled for later versions, the features in v1.4 should be good enough to make it usable by at least some of the target users.
• Also note the following constraint:

• Should match v1.4 deliverables i.e., executable, docs, website, etc.
• To be delivered as a Git repo. Ensure your GitHub team repo is updated to match the executable.

In UG/DG, using hierarchical section numbering and figure numbering is optional (reason: it's not easy to do in Markdown), but make sure it does not inconvenience the reader (e.g., use section/figure title and/or hyperlinks to point to the section/figure being referred to). Examples:

In the section Implementation given above ...

CS2103 does not require you to indicate author name of DG/UG sections (CS2101 requirements may differ). We recommend (but not require) you to ensure that the code dashboard reflect the authorship of doc files accurately.

• The main content you add should be in the docs/UserGuide.md file (for ease of tracking by grading scripts).
• Should cover all v1.4 features.
  Ensure those descriptions match the product precisely, as it will be used by peer testers (inaccuracies will be considered bugs).
• Optionally, can also cover future features. Mark those as Coming soon.
• Also note the following constraint:

• The main content you add should be in the docs/DeveloperGuide.md file (for ease of tracking by grading scripts).
  If you use PlantUML diagrams, commit the diagrams as .puml files in the docs/diagrams folder.
• Should match the v1.4 implementation.

• OPTIONAL You can include proposed implementations of future features.
• Include an appendix named Instructions for Manual Testing, 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.
  • Cover all user-testable features but no need to cover existing AB3 features if you did not touch them.
  • 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.
  • Information in this appendix should complement the UG. Minimize repeating information that are already mentioned in the UG.
  • Inaccurate instructions will be considered bugs.

DG Tips

• Aim to showcase your documentation skills. The stated objective of the DG is to explain the implementation to a future developer, but a secondary objective is to serve as evidence of your ability to document deeply-technical content using prose, examples, diagrams, code snippets, etc. appropriately. To that end, you may also describe features that you plan to implement in the future, even beyond v1.4 (hypothetically).
  For an example, see the description of the undo/redo feature implementation in the AddressBook-Level3 developer guide.
• Diagramming tools:

  • AB3 uses PlantUML (see the guide Using PlantUML @SE-EDU/guides for more info).
    

  • You may use any other tool too (e.g., PowerPoint). But if you do, note the following:
    Choose a diagramming tool that has some 'source' format that can be version-controlled using git and updated incrementally (reason: because diagrams need to evolve with the code that is already being version controlled using git). For example, if you use PowerPoint to draw diagrams, also commit the source PowerPoint files so that they can be reused when updating diagrams later.

  • Can i.e., automatically reverse engineered from the Java codeIDE-generated UML diagrams be used in project submissions? Not a good idea. Given are three reasons each of which can be reported by evaluators as 'bugs' in your diagrams, costing you marks:

    • They often don't follow the standard UML notation (e.g., they add extra icons).
    • They tend to include every little detail whereas we want to limit UML diagrams to important details only, to improve readability.
    • Diagrams reverse-engineered by an IDE might not represent the actual design as some design concepts cannot be deterministically identified from the code. e.g., differentiating between multiplicities 0..1 vs 1, composition vs aggregation
• Use multiple UML diagram types. Following from the point above, try to include UML diagrams of multiple types to showcase your ability to use different UML diagrams.
• Keep diagrams simple. The aim is to make diagrams comprehensible, not necessarily comprehensive.
  Ways to simplify diagrams:
  • Omit less important details. Examples:
    • a class diagram can omit minor utility classes, private/unimportant members; some less-important associations can be shown as attributes instead.
    • a sequence diagram can omit less important interactions, self-calls.
  • Omit repetitive details e.g., a class diagram can show only a few representative ones in place of many similar classes (note how the AB3 Logic class diagram shows concrete *Command classes using a placeholder XYZCommand).
  • Limit the scope of a diagram. Decide the purpose of the diagram (i.e., what does it help to explain?) and omit details not related to it. In particular, avoid showing lower-level details of multiple components in the same diagram unless strictly necessary e.g., note how the this sequence diagram shows only the detailed interactions within the Logic component i.e., does not show detailed interactions within the model component.
  • Break diagrams into smaller fragments when possible.
    • If a component has a lot of classes, consider further dividing into sub-components (e.g., a Parser sub-component inside the Logic component). After that, sub-components can be shown as black-boxes in the main diagram and their details can be shown as separate diagrams.
    • You can use ref frames to break sequence diagrams to multiple diagrams. Similarly, rakes can be used to divide activity diagrams.
  • Stay at the highest level of abstraction possible e.g., note how this sequence diagram shows only the interactions between architectural components, abstracting away the interactions that happen inside each component.
  • Use visual representations as much as possible. E.g., show associations and navigabilities using lines and arrows connecting classes, rather than adding a variable in one of the classes.
  • For some more examples of what NOT to do, see here.
• Integrate diagrams into the description. Place the diagram close to where it is being described.
• Use code snippets sparingly. The more you use code snippets in the DG, and longer the code snippet, the higher the risk of it getting outdated quickly. Instead, use code snippets only when necessary and cite only the strictly relevant parts only. You can also use pseudo code instead of actual programming code.
• Resize diagrams so that the text size in the diagram matches the the text size of the main text of the diagram. See example.

These class diagrams seem to have lot of member details, which can get outdated pretty quickly:

---

This class diagram seems to have too many classes:

---

These sequence diagrams are bordering on 'too complicated':

In this negative example, the text size in the diagram is much bigger than the text size used by the document:

It will look more 'polished' if the two text sizes match.

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

PPP Objectives

• For you to use (e.g. in your resume) as a well-documented data point of your SE experience
• For evaluators to use as a data point for evaluating your project contributions

PPP Sections to include

• Overview: A short overview of your product to provide some context to the reader. The opening 1-2 sentences may be reused by all team members. If your product overview extends beyond 1-2 sentences, the remainder should be written by yourself.
• Summary of Contributions --Suggested items to include:
  • Code contributed: Give a link to your code on tP Code Dashboard. The link is available in the Project List Page -- linked to the icon under your profile picture.
  • Enhancements implemented: A summary of the enhancements you implemented.
  • Contributions to documentation: Which sections did you contribute to the UG?
  • Contributions to the DG: Which sections did you contribute to the DG? Which UML diagrams did you add/updated?
  • Contributions to team-based tasks :
  • Review/mentoring contributions: Links to PRs reviewed, instances of helping team members in other ways
  • Contributions beyond the project team:
    • 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

Team-tasks are the tasks that someone in the team has to do.

Here is a non-exhaustive list of team-tasks:

1. Setting up the GitHub team org/repo
2. Necessary general code enhancements e.g.,
   1. Work related to renaming the product
   2. Work related to changing the product icon
   3. Morphing the product into a different product
3. Setting up tools e.g., GitHub, Gradle
4. Maintaining the issue tracker
5. Release management
6. Updating user/developer docs that are not specific to a feature e.g. documenting the target user profile
7. Incorporating more useful tools/libraries/frameworks into the product or the project workflow (e.g. automate more aspects of the project workflow using a GitHub plugin)

• [Optional] Contributions to the Developer Guide (Extracts): Reproduce the parts in the Developer Guide that you wrote. Alternatively, you can show the various diagrams you contributed.
• [Optional] Contributions to the User Guide (Extracts): Reproduce the parts in the User Guide that you wrote.

PPP Format

• File name (i.e., in the repo): docs/team/githbub_username_in_lower_case.md e.g., docs/team/goodcoder123.md
• Follow the example in the AddressBook-Level3

PPP Page Limit

• The page limits given above are after converting to PDF format. The actual amount of content you require is actually less than what these numbers suggest because the HTML → PDF conversion adds a lot of spacing around content.

When setting up your team repo, you would be configuring the GitHub Pages feature to publish your documentation as a website.

Website Home page

• Update to match your product.

Website AboutUs Page

• Use a suitable profile photo.

• Include a link to each person's PPP page.
• Team member names match full names used by LumiNUS.

Website UG (Web Page)

• Should match the submitted PDF file.

Website DG (Web Page)

• Should match the submitted PDF file.

PE Overview

Objectives:

• The primary objective of the PE is to increase the rigor of project grading. Assessing most aspects of the project involves an element subjectivity. As the project counts for a large percentage of the final grade, it is not prudent to rely on evaluations of tutors alone as there can be significant variations between how different tutors assess projects. That is why we collect more data points via the PE so as to minimize the chance of your project being affected by evaluator-bias.
• PE is also used to evaluate your manual testing skills, product evaluation skills, effort estimation skills etc.
• Note that significant project components are not graded solely based on peer ratings. Rather, PE data are cross-validated with tutors' grades to identify cases that need further investigation. When peer inputs are used for grading, they are usually combined with tutors' grades 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.
• 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 affect your final grade and your peers', as explained in Admin: Project Grading section.
• As such, we have put in measures to identify and penalize insincere/random evaluations.
• Also see:

Grading bugs found in the PE

• Of Developer Testing component, based on the bugs found in your code3A and System/Acceptance Testing component, based on the bugs found in others' code3B above, the one you do better will be given a 70% weight and the other a 30% weight so that your total score is driven by your strengths rather than weaknesses.
• Bugs rejected by the dev team, if the rejection is approved by the teaching team, will not affect marks of the tester or the developer.
• The penalty/credit for a bug varies based on the severity of the bug: severity.High > severity.Medium > severity.Low > severity.VeryLow
• The three types (i.e., type.FunctionalityBug, type.DocumentationBug, type.FeatureFlaw) are counted for three different grade components. The penalty/credit can vary based on the bug type. Given that you are not told which type has a bigger impact on the grade, always choose the most suitable type for a bug rather than try to choose a type that benefits your grade.
• The penalty for a bug is divided equally among assignees.
• Developers are not penalized for duplicate bug reports they received but the testers earn credit for duplicate bug reports they submitted as long as the duplicates are not submitted by the same tester.
• i.e., the same bug reported by many testersObvious bugs earn less credit for the tester and slightly higher penalty for the developer.
• If the team you tested has a low bug count i.e., total bugs found by all testers is low, we will fall back on other means (e.g., performance in PE dry run) to calculate your marks for system/acceptance testing.
• Your marks for developer testing depends on the bug density rather than total bug count. Here's an example:
  • n bugs found in your feature; it is a big feature consisting of lot of code → 4/5 marks
  • n bugs found in your feature; it is a small feature with a small amount of code → 1/5 marks
• You don't need to find all bugs in the product to get full marks. For example, finding half of the bugs of that product or 4 bugs, whichever the lower, could earn you full marks.
• Excessive incorrect downgrading/rejecting/marking as duplicatesduplicate-flagging, if deemed an attempt to game the system, will be penalized.

PE Preparation

• It's similar to,

PE Phase 1: Bug Reporting

PE Phase 1 will conducted under exam conditions. We will be following the SoC's E-Exam SOP, combined with the deviations/refinements given below. Any non-compliance will be dealt with similar to a non-compliance in the final exam.

• Proctoring will be done via Zoom. No admission if the following requirements are not met.
  • You need two Zoom devices (PC: chat, audio video, Phone: video, audio), unless you have an external web cam for your PC.
  • Add your [PE_seat_number] in front of the first name of your Zoom display name, in your Zoom devices. Seat numbers can be found in here. e.g.,
    • [M48] John Doe (M18 is the seat number)
    • [M48][PC] John Doe (for the PC, if using a phone as well)
  • Set your camera so that all the following are visible:
    • your head (side view)
    • the computer screen
    • the work area (i.e., the table top)
      
• Join the Zoom waiting room 15-30 minutes before the start time. Admitting you to the Zoom session can take some time.
• In case of Zoom outage, we'll fall back on MS Teams (MST). Make sure you have MST running and have joined the matching MST Team CS2103_AY2021S1_12pm_lecture or CS2103_AY2021S1_4pm_lecture.
• Recording the screen is not required.
• You are allowed to use head/ear phones.
• Only one screen is allowed.
• Do not use the public chat channel to ask questions from the prof. If you do, you might accidentally reveal which team you are testing.
• Do not use more than one CATcher instance at the same time. Our grading scripts will red-flag you if you use multiple CATcher instances in parallel.
• Use MS Teams (not Zoom) private messages to communicate with the prof. Fall back on Zoom chat only if you didn't receive a reply via MST.
• Do not view video Zoom feeds of others while the testing is ongoing. Keep the video view minimized.
• During the bug reporting periods (i.e., PE Phase 1 - part I and PE Phase 1 - part II), do not use websites/software not in the list given below. In particular, do not visit GitHub. However, you are allowed to visit pages linked in the UG/DG for the purpose of checking if the link is correct. If you need to visit a different website or use another software, please ask for permission first.
  • Website: LumiNUS
  • Website: Module website (e.g., to look up PE info)
  • Software: CATcher, any text editor, any screen grab software
  • Software: PDF reader (to read the UG/DG or other references such as the textbook)
• Do not use any other software running in the background e.g., telegram chat
• This is a manual testing session. Do not use any test automation tools or custom scripts.

• When, where: Week 13 lecture slot. Use the same Zoom link used for the regular lecture.

PE Phase 1 - Part I Product Testing [60 minutes]

Test the product and report bugs as described below. You may report both product bugs and documentation bugs during this period.

PE Phase 1 - Part II Evaluating Documents [30 minutes]

• This slot is for reporting documentation bugs only. You may report bugs related to the UG and the DG.
• For each bug reported, cite evidence and justify. For example, if you think the explanation of a feature is too brief, explain what information is missing and why the omission hinders the reader.

PE Phase 1 - Part III Overall Evaluation [15 minutes]

• To be submitted via TEAMMATES. You are recommended to complete this during the PE session itself, but you have until the end of the day to submit (or revise) your submissions.

PE Phase 2: Developer Response

Deadline: Tue, Nov 17th 2359

This phase is for you to respond to the bug reports you received.

Duration: The review period will start around 1 day after the PE (exact time to be announced) and will last for 2-3 days. 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

• 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 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 CS2103/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 this 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.

You must use CATcher. You are strictly prohibited from editing PE bug reports using the GitHub Web interface as it can can render bug reports unprocessable by CATcher, sometimes in an irreversible ways, and can affect the entire class. Please contact the prof if you are unable to use CATcher for some reason.

• If a bug seems to be for a different product (i.e. wrongly assigned to your team), let us know ASAP.
• 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 A Duplicate of tick box.
  • 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 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, or the tester was mistaken in some other way.
• 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 asking the tester to give more info. The tester will not be able to see those comments because the bug reports are anonymous.

• Apply one of these labels (if missing, we assign: type.FunctionalityBug)

Type labels:

• type.FunctionalityBug: A functionality does not work as specified/expected.
• 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 product design aspect of the project.
• type.DocumentationBug: A flaw in the documentation e.g., a missing step, a wrong instruction, typos

• If you disagree with the original severity assigned to the bug, you may change it to the correct level.

Bug Severity labels:

• severity.VeryLow : A flaw that is purely cosmetic and does not affect usage e.g., a typo/spacing/layout/color/font issues in the docs or the UI that doesn't affect usage.
• 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.

When applying for documentation bugs, replace user with reader.

• If you need the teaching team's inputs when deciding on a bug (e.g., if you are not sure if the UML notation is correct), post in the forum. Remember to quote the issue number shown in CATcher (it appears at the end of the issue title).

• Broken links in UG/DG: Severity can be low or medium depending on how many such cases and how much inconvenience they cause to the reader.
• UML notation variations caused by the diagramming tool: Can be rejected if not contradicting the standard notation (as given by the textbook) i.e., extra decorations that are not misleading.
  If the same problem is reported for multiple diagrams, can be flagged as duplicates.
  Omitting optional notations is not a bug as long it doesn't hinder understanding.
• Minor typos and grammar errors: These are still considered as severity.VeryLow type.DocumentationBug bugs (even if it is in the actual UI) which carry a very tiny penalty.
• How to prove that something is 'not in scope': In general, features not-yet-implemented (and hence, not in scope) are the features that have a lower priority that the ones that are implemented already. In addition, the following (at least one) can be used to prove that a feature was left out deliberately because it was not in scope:
  • The UG specifies it as not supported or coming in a future version.
  • The user cannot attempt to use the missing feature or when the user does so, the software fails gracefully, possibly with a suitable error message i.e., the software should not crash.
• If a missing feature is essential for the app to be reasonably useful, its omission can be considered a feature flaw even if it can be proven as not in scope as given in the previous point.
• If a bug report contains multiple bugs (i.e., despite instructions to the contrary, a tester included multiple bugs in a single bug report), you have to choose one bug and ignore the others. If there are valid bugs, choose from valid bugs. Among the choices available, choose the one with the highest severity (in your opinion). In your response, mention which bug you chose.
• How to decide the severity of bugs related to missing requirements (e.g., missing user stories)? Depends on the potential damage the omission can cause. Keep in mind that not documenting a requirement increases the risk of it not getting implemented in a timely manner (i.e., future developers will not know that feature needs to be implemented).
• You can reject bugs that you i.e., the current behavior is same as AB3 and you had no reason to change it because the feature applies similarly to your new productinherited from AB3.

• 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.*, response.*, assignees, and duplicate status even for bugs you are not accepting or marking 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

• You can also refer to the below guidelines:

PE Phase 3: Tester Response

Start: Within 1 day after Phase 2 ends.

Deadline: Fri, Nov 20th 2359

• In this phase you will get to state whether you agree or disagree with the dev team's response to the bugs you reported. If a bug reported has been subjected to any of the below by the receiving dev team, you can record your objections and the reason for the objection.
  • not accepted
  • severity downgraded
  • bug type changed
• As before, consider carefully before you object to a dev team's response. If many of your objections were overruled by the teaching team later, you will lose marks for not being able to evaluate a bug report properly.
• If you disagree with the team's decision but would like to revise your own initial type/severity/response as well, you can state that in your explanation e.g., you rated the bug severity.High and the team changed it to severity.Low but now you think it should be severity.Medium.
• You can also refer to the below guidelines:

• This phase is optional. If you do not respond to a dev response, we'll assume that you agree with it.
• Procedure:

PE Phase 4: Tutor Moderation

• In this phase tutors will look through all dev responses you objected to in the previous phase and decide on a final outcome.
• In the unlikely case we need your inputs, the tutor will contact you.