PE Overview

PE Preparation

• It's similar to,

PE Phase 1: Bug Reporting

• When, where: Week 13 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 [20 minutes]

• This slot is for reporting documentation bugs only. You may report bugs related to UG and 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 [10 minutes]

• Evaluate the following aspects. Submit 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

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 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.

# Team's Response
{replace this with your response}
## Duplicate status (if any):

# 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

PE Phase 3: Tester Response

• In this phase you will get to state whether you agree or disagree with the dev response to the bugs you reported. If a bug reported has been subjected to any of the below by the receiving 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 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.
• This phase is optional. If you do not respond to a dev response, we'll assume that you agree with it.
• Deadline: Reading week Thursday 2359
• Procedure:

Team chose ['response.IssueUnclear']

- [x] I disagree

**Reason for disagreement:** I think one can easily reproduce the problem by following the steps I gave.

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 we need your inputs, the tutor will contact you.

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 to evaluate 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 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

• [Optional] 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.

• [Optional] 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.

• [Optional] 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).

PPP Format

• File name: docs/team/githbub_username_in_lower_case.adoc e.g., docs/team/goodcoder123.adoc

• Follow the example in the AddressBook-Level3

• You can use the Asciidoc's include feature to include sections from the developer guide or the user guide in your PPP. Follow the example in the sample.

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.