This site is from a past semester! The current version will be here when the new semester starts.

Week 5 [Feb 10] - Admin Info

+ Other info relevant to this week:

Admin tP: Grading

Note that project grading is not competitive (not bell curved). CS2103T projects will be assessed separately from CS2103 projects. Given below is the marking scheme.

Total: 65 marks ( 55 individual marks + 10 team marks)

See the sections below for details of how we assess each aspect.

1. Project Grading: Product Design [/ 5 marks]

Evaluates: how well your features fit together to form a cohesive product (not how many features or how big the features are) and how well does it match the target user

Evaluated by:

tutors (based on product demo and user guide)
peers from other teams (based on peer testing and user guide)

In addition, feature flaws reported in the PE will be considered when grading this aspect.

These are considered feature flaws:
The feature does not solve the stated problem of the intended user i.e., the feature is 'incomplete'
Hard-to-test features
Features that don't fit well with the product
Features that are not optimized enough for fast-typists or target users

2. Project Grading: Implementation [ 10 15 marks]

2A. Code quality

Evaluates: the quality of the parts of the code you claim as written by you

Evaluation method: manual inspection by tutors + automated-analysis by a script

Criteria:

At least some evidence of these (see here for more info)
- logging
- exceptions
- assertions
- defensive coding
No coding standard violations e.g. all boolean variables/methods sounds like booleans. Checkstyle can prevent only some coding standard violations; others need to be checked manually.
SLAP is applied at a reasonable level. Long methods or deeply-nested code are symptoms of low-SLAP.
No noticeable code duplications i.e. if there multiple blocks of code that vary only in minor ways, try to extract out similarities into one place, especially in test code.
Evidence of applying code quality guidelines covered in the module.

2B. Effort

Evaluates: how much value you contributed to the product

Method:

Step 1: Evaluate the effort for the entire project. This is evaluated by peers who tested your product, and tutors.

Step 2: Evaluate how much of that effort can be attributed to you. This is evaluated by team members, and tutors.

3. Project Grading: QA [ 10 15 marks]

3A. Developer Testing:

Evaluates: How well you tested your own feature

Based on:

functionality bugs in your work found by others during the Practical Exam (PE)
your test code (note our expectations for automated testing)

These are considered functionality bugs:
Behavior differs from the User 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

3B. System/Acceptance Testing:

Evaluates: How well you can system-test/acceptance-test a product

Based on: bugs you found in the PE. In addition to functionality bugs, you get credit for reporting documentation bugs and feature flaws.

Grading bugs found in the PE

Of 3A and 3B 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 type of the bug: type.FunctionalityBug > type.DocumentationBug > type.FeatureFlaw
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 more 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 difficult 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 unethical attempt to game the system, will be penalized.

4. Project Grading: Documentation [ 10 20 marks]

Evaluates: your contribution to project documents

Method: Evaluated in two steps.

Step 1: Evaluate the whole UG and DG. This is evaluated by peers who tested your product, and tutors.

Step 2: Evaluate how much of that effort can be attributed to you. This is evaluated by team members, and tutors.

In addition, UG and DG bugs you received in the PE will be considered for grading this component.

These are considered UG bugs (if they hinder the reader):

Use of visuals

Not enough visuals e.g., screenshots/diagrams
The visuals are not well integrated to the explanation
The visuals are unnecessarily repetitive e.g., same visual repeated with minor changes

Use of examples:

Not enough or too many examples e.g., sample inputs/outputs

Explanations:

The explanation is too brief or unnecessarily long.
The information is hard to understand for the target audience. e.g., using terms the reader might not know

Neatness:

looks messy
not well-formatted

These are considered DG bugs (if they hinder the reader):

These are considered UG bugs (if they hinder the reader):

Use of visuals

Not enough visuals e.g., screenshots/diagrams
The visuals are not well integrated to the explanation
The visuals are unnecessarily repetitive e.g., same visual repeated with minor changes

Use of examples:

Not enough or too many examples e.g., sample inputs/outputs

Explanations:

The explanation is too brief or unnecessarily long.
The information is hard to understand for the target audience. e.g., using terms the reader might not know

Neatness:

looks messy
not well-formatted

Architecture:

Symbols used are not intuitive
Indiscriminate use of double-headed arrows
e.g., the sequence diagram showing interactions between main componentsarchitecture-level diagrams contain lower-level details
Description given are not usufficiently high-level

UML diagrams:

notation incorrect or not compliant with the notation covered in the module.
Some other type of diagram used when a UML diagram would have worked just as well.
The diagram used is not suitable for the purpose it is used.
The diagram is too complicated.

Code snippets:

Excessive use of code e.g., a large chunk of code is cited when a smaller extract of would have sufficed.

Problems in User Stories. Examples:

Incorrect format
All three parts are not present
Benefit does not match the function
Important user stories missing

Problems in Use Cases. Examples:

Incorrect step numbering
Missing extensions
Unnecessary UI details mentioned
Formatting/notational errors

Problems in NFRs. Examples:

Not really a Non-Functional Requirement
Not well-defined (i.e., hard to decide when it has been met)
Not reasonably achievable
Highly relevant NFRs missing

Problems in Glossary. Examples:

Unnecessary terms included
Important terms missing

5. Project Grading: Project Management [ 5 + 5 = 10 marks]

5A. Process:

Evaluates: How well you did in project management related aspects of the project, as an individual and as a team

Based on: tutor/bot observations of project milestones and GitHub data

Grading criteria:

Milestones need to be reached the midnight before of the tutorial for it to be counted as achieved. To get a good grade for this aspect, achieve at least 60% of the recommended milestone progress.
Good use of GitHub milestones
Good use of GitHub release mechanism
Good version control, based on the repo
Reasonable attempt to use the forking workflow
Good task definition, assignment and tracking, based on the issue tracker
Good use of buffers (opposite: everything at the last minute)
Project done iteratively and incrementally (opposite: doing most of the work in one big burst)

5B. Team-tasks:

Evaluates: How much you contributed to team-tasks

Based on: peer evaluations, tutor observations

Grading criteria: To earn full marks, you should have done close to a fair share of the team tasks. You can earn bonus marks by doing more than your fair share.

Admin Apdx B (Policies) → Policy on project work distribution

Policy on project work distribution

As most of the work is graded individually, it is OK to do less or more than equal share in your project team.

Admin Apdx B (Policies) → Policy on email response time

Policy on email response time

Normally, the prof will respond within 24 hours if it was an email sent to the prof or a forum post directed at the prof. If you don't get a response within that time, please feel free to remind the prof. It is likely that the prof did not notice your post or the email got stuck somewhere.

Similarly we expect you to check email regularly and respond to emails written to you personally (not mass email) promptly.

Not responding to a personal email is a major breach of professional etiquette (and general civility). Imagine how pissed off you would be if you met the prof along the corridor, said 'Hi prof, good morning' and the prof walked away without saying anything back. Not responding to a personal email is just as bad. Always take a few seconds to at least acknowledge such emails. It doesn't take long to type "Noted. Thanks" and hit 'send'.

The promptness of a reply is even more important when the email is requesting you for something that you cannot provide. Imagine you wrote to the prof requesting a reference letter and the prof did not respond at all because he/she did not want to give you one; You'll be quite frustrated because you wouldn't know whether to look for another prof or wait longer for a response. Saying 'No' is fine and in fact a necessary part of professional life; but saying nothing is not acceptable. If you didn't reply, the sender will not even know whether you received the email.

Admin Apdx C (FAQs) → Why so much bean counting? : OPTIONAL

Why so much bean counting? : OPTIONAL

Sometimes, small things matter in big ways. e.g., all other things being equal, a job may be offered to the candidate who has the neater looking CV although both have the same qualifications. This may be unfair, but that's how the world works. Students forget this harsh reality when they are in the protected environment of the school and tend to get sloppy with their work habits. That is why we reward all positive behavior, even small ones (e.g., following precise submission instructions, arriving on time etc.).

But unlike the real world, we are forgiving. That is why you can still earn full marks for participation even if you miss a few things here and there.

Related article: This Is The Personality Trait That Most Often Predicts Success (this is why we reward things like punctuality).