We encourage sharing, but you should share with everyone in the class, not just a selected group. That is,
You can even reuse each other's work subject to the 'reuse policy' given below.
If you submit code (or adopt ideas) taken from elsewhere, you need to comply with our reuse policy.
Detection:
Penalties:
Reuse is encouraged. However, note that reuse has its own costs (such as the learning curve, additional complexity, usage restrictions, and unknown bugs). Furthermore, you will not be given credit for work done by others. Rather, you will be given credit for using work done by others.
Given below are how to give credit for things you reuse from elsewhere. These requirements are specific to this module i.e., not applicable outside the module (outside the module you should follow the rules specified by your employer and the license of the reused work)
If you used a third party library:
README.adoc (under the Acknowledgements section)If you reused code snippets found on the Internet e.g. from StackOverflow answers or
referred code in another software or
referred project code by current/past student:
//Solution below adapted from https://stackoverflow.com/a/16252290
{Your implmentation of the reused solution here ...}
@@author tags//@@author {yourGithubUsername}-reused
//{Info about the source...}
{Reused code (possibly with minor modifications) here ...}
//@@author
persons = getList()
//@@author johndoe-reused
//Reused from https://stackoverflow.com/a/34646172 with minor modifications
Collections.sort(persons, new Comparator<CustomData>() {
@Override
public int compare(CustomData lhs, CustomData rhs) {
return lhs.customInt > rhs.customInt ? -1 : (lhs.customInt < rhs.customInt) ? 1 : 0;
}
});
//@@author
return persons;
Annotate both functional and test code There is no need to annotate documentation files.
Annotate only significant size code blocks that can be reviewed on its own e.g., a class, a sequence of methods, a method.
Claiming credit for code blocks smaller than a method is discouraged but allowed. If you do, do it sparingly and only claim meaningful blocks of code such as a block of statements, a loop, or an if-else statement.
Do not try to boost the quantity of your contribution using unethical means such as duplicating the same code in multiple places. In particular, do not copy-paste test cases to create redundant tests. Even repetitive code blocks within test methods should be extracted out as utility methods to reduce code duplication. Individual members are responsible for making sure code attributed to them are correct. If you notice a team member claiming credit for code that he/she did not write or use other questionable tactics, you can email us (after the final submission) to let us know.
If you wrote a significant amount of code that was not used in the final product,
{project root}/unused//@@author {yourGithubUsername}-unused to mark unused code in those files (note the suffix unused)
e.g.//@@author johndoe-unused
method 1 ...
method 2 ...
Please put a comment in the code to explain why it was not used.
If you reused code from elsewhere, mark such code as //@@author {yourGithubUsername}-reused (note the suffix reused)
e.g.
//@@author johndoe-reused
method 1 ...
method 2 ...
You can use empty @@author tags to mark code as not yours when RepoSense attribute the to you incorrectly.
Code generated by the IDE/framework, should not be annotated as your own.
Code you modified in minor ways e.g. adding a parameter. These should not be claimed as yours but you can mention these additional contributions in the Project Portfolio page if you want to claim credit for them.
At the end of the project each student is required to submit a Project Portfolio Page.
Objective:
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:
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.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.
In general, you are not allowed to involve outsiders in your project except your team members and the teaching team. However, It is OK to give your product to others for the purpose of getting voluntary user feedback. It is also OK to learn from others as long as they don't do your project work themselves.
There is no midterm.
The final exam has two parts:
Both papers will be given to you at the start but you need to answer Part 1 first (i.e. MCQ paper). It will be collected half an hour after the exam start time (even if arrived late for the exam). You are free to start part 2 early if you finish Part 1 early.
Each MCQ question gives you a statement to evaluate.
An example statement
Testing is a Q&A activity
Unless stated otherwise, the meaning of answer options are
A: Agree/True. If the question has multiple statements, agree with all of them.
B: Disagree/False. If the question has multiple statements, disagree with at least one of them
C, D, E: Not used
The exam paper has 50 questions. All questions carry equal marks.
The weightage of the Part 1 of the final exam is 25 marks out of the total score of 100.
Note that you have slightly more than ½ minute for each question, which means you need to go through the questions fairly quickly.
Given the fast pace required by the paper, to be fair to all students, you will not be allowed to clarify doubts about questions (in Part 1) by talking to invigilators.
Questions in Part 1 are confidential. You are not allowed to reveal Part 1 content to anyone after the exam. All pages of the assessment paper are to be returned at the end of the exam.
You will be given OCR forms (i.e., bubble sheets) to indicate your answers for Part 1. Indicate your student number in the OCR form.
The exam paper is open-book: you may bring any printed or written materials to the exam in hard copy format. However, given the fast pace required by Part 1, you will not have time left to refer notes during that part of the exam.
💡 Mark the OCR form as you go, rather than planning to transfer your answers to the OCR form near the end.
💡 Write the answer in the exam paper as well when marking it in the OCR form. Reason: It will reduce the chance of missing a question. Furthermore, in case you missed a question, it will help you correct the OCR form quickly.
💡 We have tried to avoid deliberately misleading/tricky questions. If a question seems to take a very long time to figure out, you are probably over-thinking it.
You will be given a practice exam paper to familiarize yourself with this slightly unusual exam format.
Unlike in part 1, you can ask invigilators for clarifications if you found a question to be unclear in part 2.
Yes, you may use pencils when answering part 2.
The weightage of the Part 2 of the final exam is 15 marks out of the total score of 100.
Past exam papers will be uploaded on IVLE.
If you do not have a laptop or prefer not to bring the laptop, it is up to you to show your work to the tutor in some way (e.g. by connecting to your home PC remotely), without requiring extra time/effort from the tutor or team members.
Reason: As you enjoy the benefits of not bring the laptop; you (not others) should bear the cost too.
The source code are publicly available and are available for reuse by others without any restrictions.
Is publishing submissions unfair to the team? We don't think so. If you were the first to think of something your peers are willing to adopt later, that means you are already ahead of them and they are unlikely to earn more marks by adopting your ideas.