- Do final tweaks to the feature
- Submit deliverables by Monday 2359
- Wrap up the milestone by Wednesday 2359
- Demo the product during the tutorial
- Prepare for the practical exam before the lecture
- Attend the practical exam during the lecture
1 Do final tweaks to the feature
- Do the final tweaks to the feature and the documentation. We strongly recommend not to do major changes to the product this close to the submission deadline.
2 Submit deliverables by Monday 2359
- 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.
cs2103T 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/format.
- 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 code during the 14 days after the deadline. Get our permission first if you need to update the code in the repo during that freeze period.
- You can update issues/milestones/PRs even during the freeze period.
- You can update the code during the freeze period if the change is related to a late submission approved by us.
- You can continue to evolve your repo after the freeze period.
Submissions:
- Product:
- Do a release on GitHub, tagged as
v1.4. - Upload the jar file to LumiNUS.
File name:[TEAM_ID][product name].jare.g. [CS2103T-W09-1][Contacts Plus].jar
- Do a release on GitHub, tagged as
Admin tP → Deliverables → Executable
- Source Code: 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
@@authorannotations 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.
Admin tP → Deliverables → Source Code
- User Guide: Convert the pdf (AB3 dev guide has some instructions on converting project docs to pdf) and upload to LumiNUS.
File name:[TEAM_ID][product Name]UG.pdfe.g.[CS2103T-W09-1][Contacts Plus]UG.pdf
Admin tP → Deliverables → User Guide
- Developer Guide: submit similar to UG
File name:[TEAM_ID][product Name]DG.pdfe.g. [CS2103T-W09-1][Contacts Plus]DG.pdf
Admin tP → Deliverables → Developer Guide
- Project Portfolio Page (PPP):
- PDF file: submit similar to UG
File name:[TEAM_ID][Your full Name as Given in LumiNUS]PPP.pdfe.g.[CS2103T-W09-1][Leow Wai Kit, John]PPP.pdf
Use-in place of/if your name has it e.g.,Ravi s/o Veegan→Ravi s-o Veegan(reason: Windows does not allow/in file names) - HTML version: make available on
github.io
- PDF file: submit similar to UG
Admin tP → Deliverables → Project Portfolio Page
- Product Website: Update (e.g.,
READMEpage,Ui.png,AboutUs) on GitHub. Ensure the website is auto-published.
Admin tP → Deliverables → Product Website
- UML diagrams:
- PDF file: submit to LumiNUS
File name:[TEAM_ID][Your full Name as Given in LumiNUS]UML Diagrams.pdfe.g.[CS2103T-W09-1][Leow Wai Kit, John]UML Diagrams.pdf
Use-in place of/if your name has it e.g.,Ravi s/o Veegan→Ravi s-o Veegan(reason: Windows does not allow/in file names)
- PDF file: submit to LumiNUS
Admin tP → Deliverables → UML Diagrams
3 Wrap up the milestone by Wednesday 2359
- As usual, wrap up the milestone on GitHub. Note that the deadline for this is the same for everyone (i.e., does not depend on your tutorial).
4 Demo the product during the tutorial
Admin tP → Deliverables → Demo
- Venue: Same as the tutorial venue unless informed otherwise. You'll be using the TV at your regular tutorial table (not the projector) for the demo.
- Schedule: Your demo timing is same as your tutorial time in week 13.
- Teams
1and3will start at 05-minutes mark (e.g., 11.05 am), and teams2and4start at 30-minutes mark (e.g., 11.30 am). - Please arrive before time and remain outside the venue until called in. Late arrival or absence is liable to a penalty.
- Any delay in starting the presentation is deducted out of your time allotment e.g., if you are scheduled to demo at 11.05-11.23 am (i.e., 18 minutes), you'll have to stop at 11.23 am even if you start at 11.10 am.
- Teams
- You should bring your own adapter if the display adapters available in your tutorial venue don't work for you.
5 Prepare for the practical exam before the lecture
Admin → Deliverables → 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 45% 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 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.
- 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 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:
Admin tP Grading → Notes on how marks are calculated for PE
Admin → Deliverables → PE-D/PE Preparation
-
Ensure that you have accepted the invitation to join the GitHub org used by the module. Go to https://github.com/nus-cs2103-AY1920S2 to accept the invitation.
-
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.
Issues created for PED 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 PED and PE activities. If you want to give your response via GitHub instead, please get our permission first.
- Create a public repo in your GitHub account with the following name:
- PE Dry Run:
ped - PE:
pe
- PE Dry Run:
- Enable its issue tracker and add the following labels to it (the label names should be precisely as given).
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.
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 'depth and completeness' of the feature.type.DocumentationBug: A flaw in the documentation that can potentially affect the user e.g., a missing step, a wrong instruction, typos that affect users
-
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 bug report.
-
Download the product to be tested notifications are likely to go out on the morning of the PE/PE-D sessionafter you have been notified of which team you have been allocated to test.
-
Charge your computer before coming to the session. The testing venue might not have enough charging points.
6 Attend the practical exam during the lecture
- Attend the practical test, to be done during the lecture.
Admin tP → Deliverables → Practical Exam