This site is from a past semester! The current version will be here when the new semester starts.
TIC4001 2020
**Schedule**
  • Full Timeline
  • Week 1 [Mon, Aug 10th]
  • Week 2 [Fri, Aug 14th]
  • Week 3 [Fri, Aug 21st]
  • Week 4 [Fri, Aug 28th]
  • Week 5 [Fri, Sep 4th]
  • Week 6 [Fri, Sep 11th]
  • Week 7 [Fri, Sep 18th]
  • Week 8 [Fri, Oct 2nd]
  • Week 9 [Fri, Oct 9th]
  • Week 10 [Fri, Oct 16th]
  • Week 11 [Fri, Oct 23rd]
  • Week 12 [Fri, Oct 30th]
  • Week 13 [Fri, Nov 6th]
  • Textbook
  • Admin Info
    • **Links**
  • Report Bugs
  • Forum
  • Gitter (Chat)
  • Instructors
  • Announcements
  • Files
  • Java Coding Standard
  • Git Conventions
  • Participation Dashboard
    •  Individual Project (iP):
  • Individual Project Info
  • iP List
  • iP Upstream Repo
  • iP Code Dashboard
  • iP Progress Dashboard
    •  Team Project (tP):
  • Team Project Info
  • Team List
  • tP Code Dashboard
  • tP Progress Dashboard
    •

    • Week 5 [Fri, Sep 4th] - Admin Info

    1. Submit post-lecture quiz counted for participation
    2. Practice peer evaluation on TEAMMATES Thu, Sep 10th 2359 counted for participation

    1 Submit post-lecture quiz counted for participation

    • Post-lecture quiz: Read weekly topics allocated for this week and submit the post-lecture quiz before the following lecture.

    2 Practice peer evaluation on TEAMMATES Thu, Sep 10th 2359 counted for participation

    • You should receive the submission link by Monday noon. Email tic4001@comp.nus.edu.sg if you did not receive the submission link on time.

    This module leverages peer feedback/evaluations in many ways. In particular, we do several rounds of peer evaluations using TEAMMATES.

    Tool: TEAMMATES (for Peer Evaluations)

    We use the TEAMMATES online peer evaluation system. TEAMMATES is a project run by NUS SoC students and used by over 0.5 million users from over 1000 universities.

    Preparation: When the first feedback session is open on TEAMMATES, you will receive an eamil from TEAMMATES. There is nothing for you to do until then.

    When you do receive that email, it will contain a unique link that you can use to access TEAMMATES without logging in first. Logging in to TEAMMATES using a Google account is optional (but doing so will allow you to see all your TEAMMATES sessions in one page).

    Submitting peer evaluations is compulsory. If you routinely miss submitting peer evaluations, you can lose participation marks.

    Session: Practice Peer Evaluation

    • Objective: to give you a chance to familiarize with the TEAMMATES tool
    • Held early in the semester
    • Submission is compulsory. However, your responses will not considered for grading as this session is for practice only.

    Policy on deadline extensions : OPTIONAL

    Learning to honor deadlines is a learning outcome of this module. Therefore, we do not normally extend module deadlines to accommodate those who missed the deadline, unless there are some extraordinary circumstances.

    + Other info relevant to this week:

    Admin tP: Grading

    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,

    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:

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

    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.

    Individual Expectations

    Individual Expectations on Implementation

    • Expectation Contribute to the functional code of the product.
      • User-visible features are preferred, but it is not a strict requirement.:
      • The enhancement(s) should fit with the rest of the software (and the target user profile) and should have the consent of the team members. You will lose marks if you go 'rogue' and add things that don't fit with the product.

    • Tip: Contribute to all aspects of the project e.g. write backend code, frontend code, test code, user documentation, and developer documentation. Reason: If you limit yourself to certain aspects only, you could lose marks allocated for the aspects you did not do. In addition, the final exam assumes that you are familiar with all aspects of the project.

    • Tip: Do all the work related to your enhancement yourself. Reason: If there is no clear division of who did which enhancement, it will be difficult to divide project credit (or assign responsibility for bugs detected by testers) later.

    Individual Expectations on Documentation

    • Objective: showcase your ability to write both user-facing documentation and developer-facing documentation.
    • Expectation Update the User Guide (UG) and the Developer Guide (DG) parts that are related to the enhancements you added. The minimum requirement is given below. (Reason: Evaluators will not be able to give you marks unless there is sufficient evidence of your documentation skills.)
      • UG: 0.5 or more pages
      • DG: 1.5 or more pages
    • Tip: If the UG/DG updates for your enhancements are not enough to reach the above requirements, you can make up the shortfall by documenting 'proposed' features and alternative designs/implementations.
    • Expectation Use at least 2 types of UML diagrams in your DG updates i.e., diagrams you added yourself or those you modified significantly.

    Individual Expectations on Testing

    • Expectation Write some automated tests so that we can evaluate your ability to write tests.

    🤔 How much testings is enough? We expect you to decide. You learned different types of testing and what they try to achieve. Based on that, you should decide how much of each type is required. Similarly, you can decide to what extent you want to automate tests, depending on the benefits and the effort required.
    There is no requirement for a minimum coverage level. Note that in a production environment you are often required to have at least 90% of the code covered by tests. In this project, it can be less. The weaker your tests are, the higher the risk of bugs, which will cost marks if not fixed before the final submission.

    Individual Expectations on Teamwork

    • Expectation Do an equal share of the team-tasks.

    Team-tasks are the tasks that someone in the team has to do.

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

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

    • Expectation Carry an equal share of project roles and responsibilities.

    Roles indicate aspects you are in charge of and responsible for. E.g., if you are in charge of documentation, you are the person who should allocate which parts of the documentation is to be done by who, ensure the document is in right format, ensure consistency etc.

    This is a non-exhaustive list; you may define additional roles.

    • Team lead: Responsible for overall project coordination.
    • Documentation (short for ‘in charge of documentation’): Responsible for the quality of various project documents.
    • Testing: Ensures the testing of the project is done properly and on time.
    • Code quality: Looks after code quality, ensures adherence to coding standards, etc.
    • Deliverables and deadlines: Ensure project deliverables are done on time and in the right format.
    • Integration: In charge of versioning of the code, maintaining the code repository, integrating various parts of the software to create a whole.
    • Scheduling and tracking: In charge of defining, assigning, and tracking project tasks.
    • [Tool ABC] expert: e.g. Intellij expert, Git expert, etc. Helps other team member with matters related to the specific tool.
    • In charge of[Area XYZ] of the code: e.g. In charge of the code that deals with storage, etc. If you are in charge of an area, you are expected to know that area well, and review changes done to that code.

    Ensure each of the important roles are assigned to one person in the team. It is OK to have a 'backup' for each role, but for each aspect there should be one person who is unequivocally the person responsible for it. Reason: when everyone is responsible for everything, no one is.

    • Expectation Review each others work. Reason: reviewing skills is a learning outcome, and it is mutually beneficial.