TIC4001 - Admin: Grade Breakdown

To receive full 10 marks allocated for participation, meet the criteria A, B, and C.

A Earned more than half of weekly participation points in at least 10 weeks.

Weekly quiz(es):
- Quizzes open around the lecture time and stay open until the next lecture starts.
- When awarding participation points for quizzes, we look for two conditions:
  - Condition 1: submitted early i.e., within four days of the lecture i.e., lecture day + three more days (reason: to encourage learning the weekly topics before doing the weekly tasks)
  - Condition 2: answered correctly i.e., least 70% of the answers are correct (reason: to discourage random answers)
- You earn:
  - 3 points if you satisfy both conditions.
  - 2 points if only one of the conditions is satisfied.
  - 1 point if submitted but both conditions are not satisfied.
Other weekly activities:
- There could be other activities related to the lecture, or the administration of the module.
- Refer the activity description for evaluation criteria.

B Received good peer evaluations

-1 for each professional conduct criterion in which you score below average (based on the average of ratings received).

Q The team members' conduct in the project and during tutorials,

Evaluated based on the following criteria, on a scale Poor/Below Average/Average/Good/Excellent:

Peer Evaluation Criteria: Professional Conduct

Professional Communication :
- Communicates sufficiently and professionally. e.g. Does not use offensive language or excessive slang in project communications.
- Responds to communication from team members in a timely manner (e.g. within 24 hours).
Punctuality: Does not cause others to waste time or slow down project progress by frequent tardiness.
Dependability: Promises what can be done, and delivers what was promised.
Effort: Puts in sufficient effort to, and tries their best to keep up with the module/project pace. Seeks help from others when necessary.
Quality: Does not deliver work products that seem to be below the student's competence level i.e. tries their best to make the work product as high quality as possible within her competency level.
Meticulousness:
- Rarely overlooks submission requirements.
- Rarely misses compulsory module activities such as pre-module survey.
Teamwork: How willing are you to act as part of a team, contribute to team-level tasks, adhere to team decisions, etc. Honors all collectively agreed-upon commitments e.g., weekly project meetings.

No penalty for scoring low on competency criteria.

Q The competency of the team member demonstrated in the project and during the tutorials,

Considered only for bonus marks, A+ grades, and tutor recruitment
Evaluated based on the following criteria, on a scale Poor/Below Average/Average/Good/Excellent:

Peer Evaluation Criteria: Competency

Technical Competency: Able to gain competency in all the required tools and techniques.
Mentoring skills: Helps others when possible. Able to mentor others well.
Communication skills: Able to communicate (written and spoken) well. Takes initiative in discussions.

Q [Optional] Any ANONYMOUS feedback you want to give the classmates you reviewed above?

Q [Optional] Any CONFIDENTIAL comments about any team members?

C Tutorial attendance/participation not too low

Low attendance/participation can affect participation marks directly (i.e., attended fewer than 7) or indirectly (i.e., it might result in low peer evaluation ratings).

In addition, you can receive bonus marks in the following ways. Bonus marks can be used to top up your participation marks but only if your marks from the above falls below 10.

[For lecture participation] Participated in lecture activities (e.g., in lecture polls/quizzes) in at least 10 lectures: 1 mark
[For perfect peer ratings] Received good ratings for all 10 peer evaluations criteria: 1 mark
[For helping classmates] Was very helpful to classmates e.g., multiple helpful posts in forum: 1 mark

Your participation progress can be tracked in this page from week 3 onward.

Total: 30 marks

Implementation [15 marks]: Requirements to get full marks:

Achieve more than 90% of all deliverables by the end.
- Requirements marked as optional or if-applicable are not counted when calculating the percentage of deliverables.
- When a requirement specifies a minimal version of it, simply reaching that minimal version of the requirement is enough for it to be counted for grading -- however, we recommend you to go beyond the minimal; the farther you go, the more practice you will get.
The code quality meets the following conditions:
- Reasonable use of OOP e.g., at least some use of inheritance, code divided into classes in a sensible way
- No blatant violations of the coding standard
- At least some errors are handled using exceptions
- At least half of public methods/classes have javadoc comments
- The code is neat e.g., no chunks of commented out code
- Reasonable use of SLAP e.g., no very-long methods or deeply nested code

Project Management [10 marks]: To get full marks, you should achieve,

Submit some deliverables in at least 4 out of the 6 iP weeks (i.e., week 2 - week 7)
Follow other requirements specified (e.g., how to use Git/Github for each increment, do peer reviews) in at least 4 weeks

Documentation [5 marks]: To get full marks, you should achieve,

The product web site and the user guide is reasonable (i.e., functional, not hard to read, covers all features, no major formatting errors in the published view).

You can monitor your iP progress (as detected by our scripts) in the iP Progress Dashboard page.

Total: 60 marks ( 35 individual marks + 25 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 the product features.

2. Project Grading: Implementation [ 20 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
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:

This is evaluated by tutors.
The score could be further moderated by this question answered by team members.

Q The team members' contribution to the product implementation (excluding UG, DG, and team-based tasks) is,

Equal share i.e., if the team has 4 members, this person did 1/4 of the work
Equal share + 10% i.e., this person did about 10% more than an equal share (equal share x 1.10)
Equal share + 20% i.e., this person did about 20% more than an equal share (equal share x 1.20)
...
Equal share - 10% i.e., this person did about 10% less than an equal share (equal share x 0.90)
Equal share - 20% i.e., this person did about 20% less than an equal share (equal share x 0.80)

3. Project Grading: QA [/ 10 marks]

Evaluated by tutors.

Based on,

the robustness of your product
the quality of test cases

4. Project Grading: Documentation [/ 15 marks]

Evaluated by tutors

Based on the quality of your UG and DG, adjusted based on your individual contribution to the UG/DG.

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:

Project done iteratively and incrementally (opposite: doing most of the work in one big burst)

No e.g., the product is not working at all by the milestone deadlinemajor mishaps at v1.0, v2.0, and v3.0 milestone deadlines.
Good attempt to use of at least some Git and GitHub features (e.g., milestones, releases, issue tracker, PRs)

5B. Team-tasks:

Evaluates: How much you contributed to team-tasks

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

Setting up the GitHub team org/repo
Necessary general code enhancements
Setting up tools e.g., GitHub, Gradle
Maintaining the issue tracker
Release management
Updating user/developer docs that are not specific to a feature e.g. documenting the target user profile
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)

Based on: peer evaluations, tutor observations

Grading criteria: Do these to earn full marks.

Do close to an equal share of the team tasks (you can earn bonus marks by doing more than an equal share).
Merge code in at least four of weeks 7, 8, 9, 10, 11, 12

Grade Breakdown