This site is from a past semester! The current version will be here when the new semester starts.
CS2113/T 2020 Jan-Apr
**Schedule**
  • Full Timeline
  • Week 1 [from Mon Jan 13]
  • Week 2 [from Wed Jan 15 noon]
  • Week 3 [from Wed Jan 22 noon]
  • Week 4 [from Wed Jan 29 noon]
  • Week 5 [from Wed Feb 5 noon]
  • Week 6 [from Wed Feb 12 noon]
  • Week 7 [from Wed Feb 19 noon]
  • Week 8 [from Wed Mar 4 noon]
  • Week 9 [from Wed Mar 11 noon]
  • Week 10 [from Wed Mar 18 noon]
  • Week 11 [from Wed Mar 25 noon]
  • Week 12 [from Wed Apr 1 noon]
  • Week 13 [from Wed Apr 8 noon]
  • Textbook
  • Admin Info
    • **Links**
  • Report Bugs
  • Forum
  • Instructors
  • Announcements
  • File Submissions
  • Tutorial Schedule
  • repl.it link
  • Java Coding Standard
  • Forum Activities Dashboard
  • Participation Dashboard
    •  Individual Project (iP):
  • Individual Project Info
  • Duke Upstream Repo
  • iP Code Dashboard
  • iP Progress Dashboard
    •  Team Project (tP):
  • Team Project Info
  • Team List
  • tP Code Dashboard
  • tP Progress Dashboard
    •

    • Week 1 [from Mon Jan 13] - Admin Info

    Admin info relevant to the week will appear in this tab.

    1. Set up the tools before the lecture
    2. Submit the pre-module survey by Wednesday 2359
    3. Learn about the module
    4. Attend the first lecture

    1 Set up the tools before the lecture

    • Follow the Preparation instructions of the following tools.

    The main language used in this module is Java. You should use Java for all programming activities, the project, and exam answers.

    The exam expects you to know Java to the extent that you should be familiar with it by virtue of using it in the module exercises/projects.

    Preparation:

    We require you to use Java 11 (the Oracle version or the OpenJDK version) for all module work. It is your duty to ensure the code you write (and executables you produce) are compatible with that version of Java. Any incompatibilities will be considered as bugs.

    Java coding standard

    This module follows the this Java coding standard.

    You are required to follow basic guidelines (those marked as ⭐️) in the module projects. Intermediate and advanced guidelines are optional.

    Tool Used: GitHub (for Code Hosting)

    You are required to use GitHub as the hosting and collaboration platform of your project (i.e., to hold the Code repository, Issue Tracker, etc.).

    Preparation:

    Create a GitHub account (if you don't have one yet), as explained in the panel below.

    Create a personal GitHub account if you don't have one yet.

    1. You are advised to choose a sensible GitHub username as you are likely to use it for years to come in professional contexts.

    2. Strongly recommended: Complete your GitHub profile. In particular,

      • Specify your full name.
      • Upload a profile photo that matches our requirements.

      The GitHub profile is useful for the tutors and classmates to identify you. If you are reluctant to share your info in your long-term GitHub account, you can remove those details after the module is over or create a separate GitHub account just for the module.

    3. You are discouraged from changing your GitHub username during the semester/exam/grading period as it can cause our auto-grading scripts to miss your GitHub activities. If you do change your GitHub username during that period, please let us know immediately.

     

    The purpose of the profile photo is for the teaching team to identify you. Therefore, choose a recent individual photo showing your face clearly (i.e., not too small) -- somewhat similar to a passport photo. Some examples can be seen in the 'Teaching team' page. Given below are some examples of good and bad profile photos.

    If you are uncomfortable posting your photo due to security reasons, you can post a lower resolution image so that it is hard for someone to misuse that image for fraudulent purposes. If you are concerned about privacy, you may use a placeholder image in place of the photo in module-related documents that are publicly visible.

    More info: See Appendix E - Using GitHub.

    Tool Used: Git (for Revision Control)

    You are required to use Git. Other revision control software are not allowed. The recommended GUI client for Git is SourceTree, but you may use any other, or none.

    Preparation:

    Install Git and a Git GUI client on your computer.
    SourceTree comes with bundled with Git i.e., if you install SourceTree, you get both Git and a GUI client in one shot.

    Set Git user.name: We use various tools to analyze your code. For us to be able to identify your commits, we encourage you to set your Git user.name in all computers you use to a sensible string that uniquely identifies you. For example, you can set it to your GitHub username or your full name. If this user name is not set properly or if you use multiple user names for Git, our tools might miss some of your work and as a result you might not get credit for some of your work.

    After installing Git in a computer, you can set the Git username as follows:

    1. Open a command window that can run Git commands (e.g., Git bash window)
    2. Run the command git config --global user.name YOUR_GITHUB_USERNAME (omit the --global flag to limit the setting to the current repo only)
      e.g., git config --global user.name JohnDoe

    More info about setting Git username is here.

    Tool Used: Intellij IDE

    You are recommended to use Intellij IDEA for module-related programming work. While the use of Intellij is not compulsory, note that module materials are optimized for Intellij. Use other IDEs at your own risk.

    Preparation:

    • Install the IDE in your computer. You may use the Intellij community edition (free) or the ultimate edition (free for students).
    • If you have an older version of the IDE, we recommend updating to the latest version (i.e., 2019 edition).

    Tool Used: Repl.it (for Coding Exercises)

    • We'll be using Repl.it for coding exercises (compulsory).

    Preparation:

    • Create an account on https://repl.it.
    • Make sure you set your first name in your repl.it user profile to be exactly the same as your GitHub username (so that our grading scripts can trace your repl.it submissions). The last name field is not used by the scripts (i.e., you can set it to any value).
    • Join the repl.it classroom cs2113-2020 Jan-Apr using this link https://repl.it/classroom/invite/jmu7TQ6.

    2 Submit the pre-module survey by Wednesday 2359

    • Submit the pre-module survey (compulsory)
      Pre-Module Survey will be available on LumiNUS Week 1 Monday - Friday 2359. We need all of you to submit it because it tells us some important information about you, especially your GitHub username.

    3 Learn about the module

    • Read the following admin info about the module.

    Workload

    As 60% of this module is based on CA, it can appear to be heavy. However, it is not expected that you will spend more time on this module than its e.g., if this module is core for you, it should not take more time than other level 2 core modules in your programpeer modules.

    • Note that the module contains more things than a typical students can do, in order to provide enough things for even the strongest students to learn as much as they wish to.
    • This means it is perfectly OK if you don't have time to learn everything the module offers. Control your workload based on time you spend for the module in a week e.g., 1-1.5 days per week.
    • We have provided a star rating system to guide you when prioritizing which things to do.

    Star Rating System

    We use a star rating system indicate the importance of module components. Start with things that are rated one-star and progress to things with more stars. Things rated four stars are optional.

    Star ratings for topics (and textbook sections):

    • One-star topics are essential to keep up with the module. We recommend you to learn these topics if you want to pass the module (i.e. up to a C grade).
    • Two-stars topics can get you up to a B+.
    • Three-stars topics can get you up to an A.
    • Four-stars topics : OPTIONAL can push you beyond the limits of the module, and help you get into a level above those who merely limit themselves to the topics of the module. They are not examinable.

    Star ratings for other things e.g., admin info sections:

    • The module uses a similar star rating system to indicate the importance of other info in this website. i.e., information rated as one-star are the most essential. Info rated four stars are non-essential and can be ignored without affecting your ability to follow the module.

    The Schedule page is your main source of information for CS2113/T. You will need to refer to it weekly. For an overview of the full schedule, refer to the Full Timeline page.

    More details for the upcoming weeks will be added as the weeks progress. In general, information given for more than 1 week into the future should be treated as tentative.

    Browser compatibility

    Most of this will work on most mainstream Browsers, but embedded slides are best viewed using Chrome.

    Information layers

    This book tries to layer information so that readers can decide to omit less important layers if they wish to.

    More important information are in bold or highlighted while less important information are dimmed or in collapsed panels such as the below.

    Less important info

    Less important info

    Less important info

    Tabs indicate alternative formats of the same content (e.g. video vs text). You can choose the one you like and ignore the other tabs.

    Some textual description of X

    Video describing X

    Dotted underlines indicate tool tips (activated by hovering over it) and dashed underlines indicate modal windows (activated by clicking) containing additional information.

    Tooltip Example
    Additional information
    Additional information

    This website uses a star rating system to indicate the priority level of contents.

    Star Rating System

    We use a star rating system indicate the importance of module components. Start with things that are rated one-star and progress to things with more stars. Things rated four stars are optional.

    Star ratings for topics (and textbook sections):

    • One-star topics are essential to keep up with the module. We recommend you to learn these topics if you want to pass the module (i.e. up to a C grade).
    • Two-stars topics can get you up to a B+.
    • Three-stars topics can get you up to an A.
    • Four-stars topics : OPTIONAL can push you beyond the limits of the module, and help you get into a level above those who merely limit themselves to the topics of the module. They are not examinable.

    Star ratings for other things e.g., admin info sections:

    • The module uses a similar star rating system to indicate the importance of other info in this website. i.e., information rated as one-star are the most essential. Info rated four stars are non-essential and can be ignored without affecting your ability to follow the module.

    Conventions used

    Shorthand headings

    Meaning of some shortened headings:

    • What : the meaning of the concept in concern

    • Why : the motivation behind the concept in concern

    • How : the usage of the concept in concern

    • When : the pros and cons of the concept in concern, when to use the concept

    Boxed-text styles

    additional info warning positive message important message an error to avoid tip definition

    Meaning of icons

    extra : tangential info, can be ignored if not interested
    : direct link to the LO. Ctrl+Click to open the LO in new window/tab.
    : learning outcomes
    : prerequisite learning outcome
    : examples
    : resources
    : exercises
    : printable version
    : preview/more info
    : video
    >_ : a command to be run in a terminal
    : textual description
    : slides
    : output produced by running code
    question without answer
    question with answer

    : tasks to do
    : lecture
    : tutorial
    : evidence you can use to prove you have achieved a learning outcome
    ⏰ : deadline

    Searching for keywords

    Use the search box in the top navigation bar to search for keywords in the website pages. If you cannot find the content related to a keyword, let us know by posting in the forum so that we can add the missing keyword to our search index.

    Saving as PDF files

    1. Use Chrome to load the page you want to save as pdf.

    2. Click on the Print option in Chrome’s menu.

    3. Set the destination to Save as PDF, then click Save to save a copy of the file in PDF format. For best results, use the settings indicated in the screenshot below.

    Printing Textbook Content

    Printer-friendly version (indicated by icon) have been provided for each chapter and the whole book. You can use them for saving as pdf files or printing.

    Making this Website Better

    This website was generated using the MarkBind software developed at NUS. We welcome bug reports, suggestions, and contributions, to be submitted at the website issue tracker.

    [Wednesday (previous week)]

    • Attend the lecture to,
      • see a recap of the preceding week's topics
      • get an introduction to the current week's topics
      • submit the in-lecture quiz/activities (if any)

    Timing/venue:

    Module Venue Time
    CS2113/T LT15 1200-1400

    Lectures start on time sharp and end around 15 minutes before official end time.

    Attendance: Attendance for the first lecture is compulsory.

    Handouts: There are no handouts. All learning materials are organized around topics, are given in Web format, can be found in the Textbook section (organized by topics), and are also embedded in the Schedule page (organized by order of coverage).

    Slides: Our lecture slides are not suited for printing or to be used as a reference during the lecture/exams. They are only an aid for lecture delivery. Slides will be uploaded to LumiNUS after the lecture.

    [Wednesday (previous week) - Tutorial day]

    • Use the relevant learning resources to learn the topics.
    • Self-test your knowledge using exercises given in the learning resources.
    • Submit the post-lecture quiz/exercises (if any)
    • Do project tasks (e.g., attend weekly project meeting, finish weekly deliverables)
    • If you don't have time to learn all topics assigned to the week, use the star rating system to decide which ones to do first.

    [Tutorial Day (Monday - Tuesday)]

    • Attend the tutorial to,
      • demonstrate evidence of your learning weekly topics to the tutor
      • learn from peer demos of showing evidence of their own learning

    Tutorial Timetable

    Our tutorial IDs are different from LumiNUS. Format: CS2113T-W09 means a tutorial of CS2113T module, held on Wednesday at 0900, and so on.

    Module Venue Time Tutorial ID
    in LumiNUS
    (don't use this!)    		 Our Tutorial ID
    (use this!)    		 Tutors
    (contact details)
    CS2113T COM1-B103[1] Mon 16:00 LC03 CS2113T-M16 Damith
    CS2113T COM1-B103 Mon 17:00 LC04 CS2113T-M17 TBD
    CS2113T COM1-B103 Tue 12:00 LC01 CS2113T-T12 Ryan, Wei Xiang
    CS2113T COM1-B103 Tue 13:00 LC02 CS2113T-T13 Tejas, Wei Xiang
     CS2113  COM1-B103 Tue 14:00 T01 CS2113-T14 Glen, Rachel
     CS2113  COM1-B103 Tue 15:00 T02 CS2113-T15 Jerry, Manaswini

    What happens during the tutorial:

    • A tutorial group is handled by two tutors. Each tutor will work with two teams.

    • The tutor will facilitate tutorial activities, observe your progress, and give feedback. If you are facing difficulties with a weekly activity, the tutor can direct you to get help from another student in the tutorial.

    • Please bring your laptop to tutorials. You'll need it for tutorial tasks.

    What if I don’t carry around a laptop? : OPTIONAL

    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 role of our tutors is different from tutors in other modules.

    • No direct tech help: Tutors are prohibited from giving direct technical help, other than to give you some general direction to finding a solution. Rationale: We want you to learn the vital survival skill of troubleshooting technical problems.

    This guide is mostly about getting tech help, but it also applies to getting clarifications on module topics too. e.g. what is the difference between refactoring and rewriting?

    Keep in mind that instructors don't have ready solutions to all technical problems. Unlike tutorial questions for which instructors have model solutions, given the complexity of industry tools we use (Gradle, Travis, Git, ...) and the rapid pace they are updated, instructors don't have ready solutions to most technical problems you face in this module. The only realistic way to solve those problems at a large scale is crowd-sourcing i.e., someone else who faced a similar problem might know how to fix it.

    What not to do:

    • Send a help request to an instructor: When faced with a technical problem or a doubt about a concept, don't fire off an email lecturer/tutor immediately, unless it is something only the lecturer/tutor is supposed to know.
    • Request to meet the instructor to solve the problem: That can only work if the person is supposed to know how to solve all technical problems, which is not the case.

    What to do:

    • Double-check the given instructions: Often, technical problems arise due to deviations in how you perform a step or a difference in your environment.

    • Get your team to meet for a weekly work-together session. When you do module tasks together, it is easy to compare with each other and figure out what deviation is causing the problem. That is, crowd-source your team first.

    • Search: It is very likely the answer already exists somewhere in the cyberspace. Almost every programming-related question has been answered in places like stackoverflow. Don't give an opportunity for someone to ask you to STFW.
      Pay attention to the error message you encounter. Sometimes it also contains hints as to how to fix the problem. Even if not, a web search on the error message is a good starting point.  

    • Ask in the module forum:

      • Give full details of the problem Conversations via online forums take time. If you post everything that is relevant to your problem, your chances of getting an answer in the first try is higher. If others have to ask you more questions before they can help you, it will take longer. But this doesn't mean you dump too much information into the thread either.

        • Include full error message, screenshots, code snippets, stack traces, etc.
        • If the problem is code-related, push the current state of the code to a branch in your fork and give the link to the branch. That gives a chance for someone to reproduce the state of your project in their computer.

      • Avoid addressing the question to one person (e.g., the prof), unless really necessary. Doing so will discourage others from answering that question.

      • Isolate the problem. "My code doesn't work" isn't going to help even if you post the whole code. Others don't have time to go through all of your code. Isolate the part that doesn't work and strip it down to the bare minimum that is enough reproduce the error. Sometimes, this process actually helps you to figure out the problem yourself (have you heard about Rubber Duck Debugging?).

        How to isolate problematic code? Delete code (one bit at a time) that is confirmed as not related to the problem. Do that until you can still reproduce the problem with the least amount of code remaining.

      • Generalize the problem. "How to write tasks to a text file using Java" is too specific to what you are working on. You are more likely to find help if you post a thread called (or search for) "How to write to a file using Java".

      • Remember to thank those you try to help, and close the issue after the issue has been resolved.


    Rubber duck debugging is an informal term used in software engineering to refer to a method of debugging code. The name is a reference to a story in the book The Pragmatic Programmer in which a programmer would carry around a rubber duck and debug his code by forcing himself to explain it, line-by-line, to the duck.

    [for more, see wikipedia entry]
    • Ask the world using programming forums such as stackoverflow.

      • PLEASE search for existing answers before you post your question in those public forums; You don't want to appear as a 'clueless' or 'too lazy to do your research' person in a public forum.

        Know what these stand for: RTFM, STFW, GIYF
    • Raise your question during a tutorial. Some questions can be discussed with the tutor and tutorial-mates. What kind of questions are suitable to discuss with the tutor? Consider these two questions you might want to ask a tutor:
      • Good This is how I understood/applied coupling. Is that correct? - Such questions are welcome. Reason:This question shows you have put in some effort to learn the topic and seeking further clarification from the tutor.
      • Bad What is coupling? - Such questions are discouraged. Reason: This question implies you haven’t done what you could to learn the topic in concern.
    • Ask the lecturer: Failing all above, you can talk to the lecturer before/after the lecture, or email the lecturer.

    Some technical problems can take a long time to resolve. Therefore, plan ahead and schedule your work much earlier than the deadline.

    Some problems might not get resolved at all; while waiting for a solution, explore alternatives and workarounds.

    Resources

    • No ‘teaching’: Tutors are prohibited from “teaching” concepts that are covered in lectures or other learning resources given to you as self-learning is a vital part of the module. For example, the tutor will not do a mini-lecture at the start of the tutorial. Of course tutors can help you clarify doubts under the right circumstances.
    • Raise your question during a tutorial. Some questions can be discussed with the tutor and tutorial-mates. What kind of questions are suitable to discuss with the tutor? Consider these two questions you might want to ask a tutor:
      • Good This is how I understood/applied coupling. Is that correct? - Such questions are welcome. Reason:This question shows you have put in some effort to learn the topic and seeking further clarification from the tutor.
      • Bad What is coupling? - Such questions are discouraged. Reason: This question implies you haven’t done what you could to learn the topic in concern.

    • No leading from the front: Tutors are not expected to lead your project effort. They will not tell you how to do project tasks or when to do project tasks. You have to figure those out yourselves. But tutors will give you feedback on how you are doing (or have done) project tasks so that you can improve further.

    Timing/venue:

    • Please refer to the Schedule page for further details on each tutorial.
    • You are expected to arrive on time. Punctuality is considered for participation marks.
    • You may leave the class 15 minutes before the hour if you have another class right after. There is no need to wait till the tutor dismisses you. However, inform the tutor (as a courtesy) before leaving if you leave before the class is dismissed.
    • Vacate the table 5 minutes before the hour so that the next group can start on time.
    • In the past, many students have requested to increase the tutorial duration because a mere hour is barely enough to get through all the tutorial tasks. Increasing the tutorial time is not possible due to lack of venues and tutors. Instead, let's try to make the best of the one hour available by coming well prepared and starting on time. Note that the better prepared you are, the higher the chance of completing e all activities allocated to a tutorial within time.

    Grading:

    • Your conduct in tutorials will be evaluated by team members and the tutor which can affect your participation marks.

    An iterative introduction to Software Engineering...

    CS2113/T is an introductory Software Engineering module covering a balance of basic SE theory and practical skills needed to work in a project that has a software component. The module follows an going through SE topics several times while increasing depth, as opposed to going through topics sequentiallyiterative approach to covering topics. The module also introduces you to the Java programming language, the OOP paradigm, and some basic UML models.

    • The theory side of this module is supported by a customized online textbook Software Engineering for Self-Directed Learners, integrated into this module website.

    • On the practice side, you will first ramp up your technical skills by doing a small individual project in which you will develop a personal assistant chatbot called Duke. Then, you will move to a team project in which you will build another small Comman Line InterfaceCLI app while working as a team.

    4 Attend the first lecture

    • Attend the Week 1 lecture (Week 1 lecture is compulsory).
    • Bring your computer to the lecture. Some lecture activities will need it.

    + Other info relevant to this week:

    Admin Apdx C (FAQs) → Where is everything?

    Where is everything?

    The Schedule page presents all you need to know in chronological order while the other pages have some of the same content organized by topic.

    The Schedule page is the one page you need to refer weekly. Although there is a lot of content in the Admin Info page and the Textbook page -- which you are welcome to read in those respective pages -- the same content is also embedded in the relevant weeks of the Schedule page. Embedded extracts usually appear in expandable panels and can be identified by the symbol in the panel title.

    Admin tP: Forming Teams


    [Picture: The team that was at the top of early Google]

    When to form teams

    • CS2113T: Your team will be formed by the CS2101 side.
    • CS2113: Your team will be formed at the start of the week 3 tutorial. Please try to arrive on time for that tutorial; if you are not there at the team forming time and others in the class are unaware which team you wanted to be in, we'll have to put you into a team randomly.

    Team size

    • The default team size is five.

    Team composition

    • We allow some freedom in choosing team members, subject to these constraints:
      • All team members should be in the same tutorial. Delay forming teams until your place in a tutorial is confirmed. We do not allow changing tutorials to team up with your preferred team mates.
      • Teams of single nationality are not allowed unless the only language common among all team members is English. e.g. an all-Singaporean team that include both Chinese and Malay students. Rationale: to train you to work in multicultural teams, to ensure that English is used for all project communication
      • No more than one exchange students per team Rationale: to increase interaction between exchange students and NUS students.
      • Same gender teams are discouraged but allowed. Rationale: to train you for mixed-gender work environments.
    • We may modify teams when circumstances call for it. There is no avenue for you to object. Staying with your preferred team is not guaranteed.

    Admin Textbooks

    This module is supported by a customized online textbook Software Engineering for Self-Directed Learners (CS2113 edition), integrated into this module website. While it is in a dynamic Web page format, there is a way to save the main text as pdf files. Printer-friendly versions have been provided too. In addition, a PDF version of the full textbook will be provided at the start of the semester, via LumiNUS.

    Saving as PDF files

    1. Use Chrome to load the page you want to save as pdf.

    2. Click on the Print option in Chrome’s menu.

    3. Set the destination to Save as PDF, then click Save to save a copy of the file in PDF format. For best results, use the settings indicated in the screenshot below.

    Admin Grade Breakdown

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

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

    • Programming exercise (if any):
      • Submitted correct solutions at least 75% of the exercises: 3 points
      • Submitted correct solutions to 50-74% of the exercises: 2 points
      • Submitted correct solutions to 25-49% of the exercises: 1 point
    • Post-lecture quiz (if any):
      • Answered at least 75% of the questions correctly: 3 points
      • Answered 50-74% questions correctly: 2 points
      • Answered less than 50% questions correctly but answered more than 50% of the questions: 1 point
    • Compulsory administrative tasks e.g., submitting peer evaluations: 2 for each task

    Lecture in week N:

    • In-lecture quiz and other activities are counted for week N lecture participation.
    • Post-lecture quiz (if any) is counted for Week N+1

    B Received good peer evaluations

    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.

    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?

    • -1 for each professional conduct criterion in which you score below average (based on the average of ratings received).
    • No penalty for scoring low on competency criteria.

    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 5.

    • [For lecture participation] Received at least half of the points for lecture activities in at least 10 lectures: 1 mark
      • In-lecture quizzes (using pollev.com): scoring is similar to the post-lecture quizzes
      • Other in-lecture activities: scoring is case-by-case basis
    • [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

    Examples:

    • Alicia earned 1/2, 3/5, 2/5, 5/5, 5/5, 5/5, 5/5, 5/5, 5/5, 5/5, 4/5, 5/5 in the first 12 weeks. As she received at least half of the points in 11 of the weeks, she gets 5 participation marks. Bonus marks are not applicable as she has full marks already.
    • Benjamin managed to get at least half of the participation points in 9 weeks only, which gives him 5-1 = 4 participation marks. But he participated in 10 lectures, and hence get a bonus mark to make it 5/5.
    • Chun Ming met the participation points bar in 8 weeks only, giving him 5-2 = 3 marks. He lost 2 more marks because he received multiple negative ratings for two criteria, giving him 1/5 participation marks.

    Your participation progress can be tracked in this page from week 3 onward. The page will be updated about once a week.

    Final Exam

    • The final exam will be on Saturday May 2nd, 1-3pm (as per normal exam schedule), and will count for 20% of the final grade.
    • The exam will be done online. Tools used: LumiNUS, Zoom, Microsoft Teams.

    Early preparations

    • Set up Zoom: Follow the Zoom exam instructions provided by NUS (note the requirement for SSO login).
      • Update the name of your Zoom profile to match the exact name on your student card, including whether the family name is give first or last (reason: we need to manually locate your name in the attendance list, which is sorted by your name in LumiNUS). You will not be admitted to the Zoom meeting if you do not comply with the requirement.
      • Note the requirements for camera placement: Your Zoom video feed need to capture your upper body and the work area, including the computer screen (as explained in this example). That means the built-in camera of your computer is not suitable for this purpose. Use either a separate web cam (attached to your Computer) or use Zoom through your smart phone. If neither of those options are available to you, let the prof know ASAP (deadline: April 24).

    You will not be allowed into the Zoom meeting unless your Zoom name complies with the above requirement.
    Your exam submission will not be accepted if your Zoom video feed does not comply with the above requirement.

    As per NUS requirements, your Zoom video feed is recorded by us and will be shared with NUS administration. If you do not consent to that, please let us know ASAP (deadline: April 24) so that we can put you in touch with the NUS administration to sort it out.

    15 30 minutes before the exam

    • Aim to join the Zoom waiting room around 12.30pm.
    • Ensure your computer and the phone (if applicable) are charged and within reach of a power supply.
    • In your computer, close all other apps and browser tabs other than the ones permitted to be use for the exam. Remember to exit other background apps that starts automatically such as telegram.
    • Launch MS-Teams, login to it, and close the app without exiting (which makes it run in the background).
    • Login to LumiNUS. The password to open the quiz will be broadcast via Zoom (audio announcement plus chat message) by the invigilator later.
    • If you are using Zoom from your phone, remember to disable the auto-sleep/lock feature so that the phone doesn't go to sleep in the middle of the exam.
    • Launch Zoom, login, ensure profile name and camera complies with our requirements, and join the meeting. Wait for the invigilator to take you into the meeting.
    • Do not use more than one Zoom device at a time.
      • If it is inconvenient to use the Zoom device for PM'ing the invigilator (e.g., if you are using Zoom through a smart phone mounted on a stand), use MS-Teams (via your computer) to PM the invigilator.
      • Exception: if you use a phone as your primary Zoom device but it not convenient to use it for audio (e.g., its speaker volume not high enough),
        1. Get our permission to use the PC as a second Zoom device.
        2. Install Zoom in the PC.
        3. Use the PC for audio/chat only (i.e., switch off the video) and the phone for video only.
        4. Name your Zoom profile name in the PC as [PC] Your Name as in Student Card e.g., [PC] John Doe
    • Once you are inside the Zoom meeting, wait patiently until all students have been admitted and the exam is ready to start. This wait could be as long as 30-45 minutes.
    • Note that the quiz will not appear on LumiNUS until a few minutes before we release the password.

    During the exam

    • Keep both the video and speaker switched-on (but microphone muted) in your Zoom during the entire exam.
    • Do not use MS-Teams during the exam unless the invigilator uses to contact you, you need to contact the invigilator, or you need to contact CIT for tech help.
    • Stay in the video frame for the entire exam duration, except during the toilet break.
    • Do not to use virtual backgrounds in Zoom. Do not use pre-recorded videos as your video feed.
    • As the exam is open-book, you can refer to any printed/written materials or use the computer to read any PDF/word documents that are in your computer. You may also access the online version of the textbook in the module website but strongly encouraged to use the PDF or printed version of the textbook instead.
      Do not visit any other websites, use any other apps, or online search engines during the exam.
    • Remain in the video frame until the invigilator ends the exam, even after you have submitted the quiz. Do not use the computer or other communication devices (not even Kindle) during that period (suggestion: have something in hard-copy form to ready to read during this time e.g., printed lecture notes of another module).
    • Do not communicate with any person other than the invigilator during the exam, as per normal exam rules.
    • When the invigilator asks you to do a face check, turn your face towards the camera, move closer to the camera, remove face mask (if any), and hold the pose until the invigilator tells you to go back to your working position.

    Troubleshooting exam problems

    • If you have a doubt/query about a question, or want to make an assumption about a question, please write it down in the 'justification' text box. Do not try to communicate those with the invigilator during the exam. We'll take your doubt/query/assumption into account when grading. For example, if many had queries about a specific question, we can conclude that the question is unclear and omit it from grading.
    • If you encounter a serious problem that prevents you from proceeding with the exam (e.g., the password to open the quiz doesn't work), contact the invigilator using Zoom chat or MS-Teams.
    • If your computer crashed/restarted during the exam, try to get it up again and resume the exam. LumiNUS will allow you to resume from where you stopped earlier. However, note that there is a deadline to finish the quiz and you will overrun that deadline if you lose more than 5 minutes due to the computer outage.

    Format

    • The exam will be given as quizzes in LumiNUS.
      For the ease of administration, the exam is split into two equal size quizzes: part 1, part 2.
    • Each quiz,
      • consists of 15 MCQ questions (plus one easy bonus question and a dummy question to collect comments)
      • is to be done in 30+5 minutes (if you spend around 2 minutes per question, you'll have a 5 minutes buffer)
    • All 30 normal questions have the same the weight and each question is expected to take a similar amount of time.
    • The questions will be presented in random order.
    • You are not allowed to go back to previous questions.
    • You are required to give a justification for your answer. The question will specify what should be included in the justification.
      Answers without the correct justification will not earn full marks. However, we'll give full marks up to two correct answers (per 15 questions) that do not have justifications (to cater for cases where you accidentally proceeded to the next question before adding the justification).
    • Here is an example question. The answer is a and the justification can be OOP is only one of the choices for an SE project.

    Choose the incorrect statement.

    [Justification: why is it incorrect?]

    • Almost all questions will ask you to choose the INCORRECT statement and justify why it is incorrect.

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

    • 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.

    Project Management [5 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

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

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

    Total: 35 55 marks ( 25 45 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)

    Q Quality of the product design,
    Evaluate based on the User Guide and the actual product behavior.

    Criterion Unable to judge Low Medium High
    target user not specified clearly specified and narrowed down appropriately
    value proposition not specified The value to target user is low. App is not worth using Some small group of target users might find the app worth using Most of the target users are likely to find the app worth using
    optimized for target user Not enough focus for CLI users Mostly CLI-based, but cumbersome to use most of the time feels like a fast typist can be more productive with the app, compared to an equivalent GUI app without a CLI

    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

    Note that 'product design' or 'functionality' are not critical learning outcomes of the tP. Therefore, the bar you need to reach to get full 5 marks will be quite low. For example, the Medium level in the rubric given in the panel above should be enough to achieve full marks. Similarly, only cases of excessive 'feature flaw' bugs will affect the score.

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

    • 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 peers who tested your product, and tutors.

    Q [For each member] The functional code contributed by the person is,
    Consider implementation work only (i.e., exclude testing, documentation, project management etc.)
    The typical iP refers to an iP where all the requirements are met at the minimal expectations given.
    Use the person's PPP and RepoSense page to evaluate the effort.

    • 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 15 marks]

    3A. Developer Testing:

    Evaluates: How well you tested your own feature

    Based on:

    1. functionality bugs in your work found by others during the Practical Exam (PE)
    2. your test code (note our expectations for automated 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.

    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 Developer Testing component, based on the bugs found in your code3A and System/Acceptance Testing component, based on the bugs found in others' code3B 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 attempt to game the system, will be penalized.

    4. Project Grading: Documentation [ 5 10 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.

    Q Compared to AddressBoook-Level3 (AB3), the overall quality of the UG you evaluated is,
    Evaluate based on fit-for-purpose, from the perspective of a target user. For reference, the AB3 UG is here.

    Q Compared to AB3, the overall quality of the DG you evaluated is,
    Evaluate based on fit-for-purpose from the perspective of a new team member trying to understand the product's internal design by reading the DG. For reference, the AB3 DG is here.

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

    Q The team members' contribution to the User Guide is,

    Q The team members' contribution to the Developer Guide is,

    • 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/Correctness:

    • looks messy
    • not well-formatted
    • broken links, other inaccuracies, typos, etc.

    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/Correctness:

    • looks messy
    • not well-formatted
    • broken links, other inaccuracies, typos, etc.

    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 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 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:

    • No e.g., the product is not working at all by the milestone deadlinemajor mishaps at v1.0 and v2.0.
    • Good attempt to use of at least some Git and GitHub features (e.g., milestones, releases, issue tracker, PRs)
    • 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

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

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

    • you have done close to a fair share of the team tasks. You can earn bonus marks by doing more than your fair share.
    • you have merged code in at least four of weeks 7, 8, 9, 10, 11, 12

    Admin Participation Marks

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

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

    • Programming exercise (if any):
      • Submitted correct solutions at least 75% of the exercises: 3 points
      • Submitted correct solutions to 50-74% of the exercises: 2 points
      • Submitted correct solutions to 25-49% of the exercises: 1 point
    • Post-lecture quiz (if any):
      • Answered at least 75% of the questions correctly: 3 points
      • Answered 50-74% questions correctly: 2 points
      • Answered less than 50% questions correctly but answered more than 50% of the questions: 1 point
    • Compulsory administrative tasks e.g., submitting peer evaluations: 2 for each task

    Lecture in week N:

    • In-lecture quiz and other activities are counted for week N lecture participation.
    • Post-lecture quiz (if any) is counted for Week N+1

    B Received good peer evaluations

    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.

    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?

    • -1 for each professional conduct criterion in which you score below average (based on the average of ratings received).
    • No penalty for scoring low on competency criteria.

    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 5.

    • [For lecture participation] Received at least half of the points for lecture activities in at least 10 lectures: 1 mark
      • In-lecture quizzes (using pollev.com): scoring is similar to the post-lecture quizzes
      • Other in-lecture activities: scoring is case-by-case basis
    • [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

    Examples:

    • Alicia earned 1/2, 3/5, 2/5, 5/5, 5/5, 5/5, 5/5, 5/5, 5/5, 5/5, 4/5, 5/5 in the first 12 weeks. As she received at least half of the points in 11 of the weeks, she gets 5 participation marks. Bonus marks are not applicable as she has full marks already.
    • Benjamin managed to get at least half of the participation points in 9 weeks only, which gives him 5-1 = 4 participation marks. But he participated in 10 lectures, and hence get a bonus mark to make it 5/5.
    • Chun Ming met the participation points bar in 8 weeks only, giving him 5-2 = 3 marks. He lost 2 more marks because he received multiple negative ratings for two criteria, giving him 1/5 participation marks.

    Your participation progress can be tracked in this page from week 3 onward. The page will be updated about once a week.

    Admin Apdx C (FAQs) → What are the differences between CS2113T and CS2113? : OPTIONAL

    What are the differences between CS2113T and CS2113? : OPTIONAL

    Same lecture content (but possibly different lecture slots), same exam. Separate tutorials, separate project grading. Unless specified otherwise, whatever is stated for one module applies to the other.

    Admin Apdx C (FAQs) → Why the workload is so high? : OPTIONAL

    Why the workload is so high? : OPTIONAL

    CS2113/T prepares you for many higher-level project modules (CS3216/7, CS3203, CS3281/2, etc.), each requiring a slightly different skill set. It is also the only SE module some of you do before going for industry internships. Therefore, we have to cover many essential SE concepts/skills and also provide enough exercises for you to practice those skills. This is also why we don't have time to go very deep into any of the topics.

    Remember, everything you learn here is going to be useful in a SE-related career.

    Also, consider this a gradual introduction to 'heavy' modules; most project modules you do after this are going to be much heavier 😛

    How to reduce the workload? You can omit Learning Outcomes rated : OPTIONAL. Furthermore, control the project workload by using no more than a fixed amount of time weekly on the project (e.g., 1 day).

    Admin Apdx C (FAQs) → What are the extra requirements to get an A+?

    What are the extra requirements to get an A+?

    In CS2113/T, A+ is not given simply based on the final score. To get an A+ you should,

    • score enough to get an A
    • be considered technically competent by peers and tutor (based on peer evaluations and tutor observations)
    • be considered helpful by peers (based on peer evaluations and tutor observations)
      • In particular, you are encouraged to be active on the forum and give your inputs to ongoing discussions so that other students can benefit from your relatively higher expertise that makes you deserve an A+.
      • Whenever you can, go out of your way to review PRs created by other team members.

    1. COM1-B103 is also known as the Active Learning Lab

    COM1-B103 is also known as the Active Learning Lab