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

Week 1 [Mon, Jan 11th] - Admin Info

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

Set up the tools before the lecture
Submit the pre-module survey by Friday 2359
Learn about the module
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.

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.

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

You are advised to choose a sensible GitHub username as you are likely to use it for years to come in professional contexts e.g., in job applications.
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.
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.

More info: See Appendix E - Using GitHub.

Tool: 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 bundled with Git i.e., if you install SourceTree, you get both Git and a GUI client in one shot. If you are already comfortable using Git command line, you need not install/use a GUI client.

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 usernames for Git, our grading scripts might miss some of your work.

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

Open a command window that can run Git commands (e.g., Git bash window)
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: 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.

Tools: for communication

Forum (for longer-running discussions)

The preferred channels for module-related communication is the forum on GitHub https://github.com/nus-cs2113-AY2021S2/forum/issues (not the LumiNUS forum)
When communicating with instructors, use the forum. Use private channels (e.g., emails, private messages, face-to-face, private chat groups) only when the forum is not suitable. Rationale: 1. More classmates can benefit from the discussions, 2. It is also safer because the prof can monitor information you receive for accuracy.

You are encouraged to help others in the forum (e.g., share tips, help with technical problems). We consider such sharing when giving out A+ grades and when recruiting tutors.

Preparation:

We encourage all to watch the forum to get alerts when new issues/comments are posted

Gitter (for quick chats)

The module Gitter channel is https://gitter.im/nus-cs2113-AY2021S2/community.
We opted to use Gitter because it is GitHub-friendly (you can use your GitHub account to access Gitter) and programmer-friendly (e.g., supports code syntax highlighting).
Do not use Gitter for technical help requests. Such requests can lead to long-running discussions which are better suited for the forum.

Preparation:

Join https://gitter.im/nus-cs2113-AY2021S2/community.
Recommended: Install the Gitter mobile app (search for it in your mobile phone's app store).

Tool: Github Classrooms (for coding exercises)

We'll be using Github Classrooms for coding exercises (compulsory).

Preparation:

We will share a file containing the assignment links by early Week 2.
- The file will be updated each week to reflect exercises pertaining to that week
More information about Github Classrooms will be given in the first lecture.

2 Submit the pre-module survey by Friday 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.

Here are some important expectations of the module from you.

Workload

As 70% of this module is based on CA (see grade breakdown), 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 core modules at the same level 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 to 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 here means can affect the grade during evaluation of various components, not necessarily limited to the final exam (if any)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

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 some additional infotool tips (activated by hovering over it) and dashed underlines indicate modal windows (activated by clicking) containing additional information.

Tooltip Example

Additional information

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

Star Rating System

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 here means can affect the grade during evaluation of various components, not necessarily limited to the final exam (if any)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 (example)

Implementation → Refactoring →

What

The first version of the code you write may not be of production quality. It is OK to first concentrate on making the code work, rather than worry over the quality of the code, as long as you improve the quality later. This process of improving a program's internal structure in small steps without modifying its external behavior is called refactoring.

Refactoring is not rewriting: Discarding poorly-written code entirely and re-writing it from scratch is not refactoring because refactoring needs to be done in small steps.
Refactoring is not bug fixing: By definition, refactoring is different from bug fixing or any other modifications that alter the external behavior (e.g. adding a feature) of the component in concern.

Improving code structure can have many secondary benefits: e.g.

hidden bugs become easier to spot
improve performance (sometimes, simpler code runs faster than complex code because simpler code is easier for the compiler to optimize).

Given below are two common refactorings (more).

Refactoring Name: Consolidate Duplicate Conditional Fragments

Situation: The same fragment of code is in all branches of a conditional expression.

Method: Move it outside of the expression.

Example:

if (isSpecialDeal()) {
    total = price * 0.95;
    send();
} else {
    total = price * 0.98;
    send();
}

→

if (isSpecialDeal()) {
    total = price * 0.95;
} else {
    total = price * 0.98;
}
send();

if is_special_deal:
    total = price * 0.95
    send()
else:
    total = price * 0.98
    send()

→

if is_special_deal:
    total = price * 0.95
else:
    total = price * 0.98
    
send()

Refactoring Name: Extract Method

Situation: You have a code fragment that can be grouped together.

Method: Turn the fragment into a method whose name explains the purpose of the method.

Example:

void printOwing() {
    printBanner();

    // print details
    System.out.println("name:	" + name);
    System.out.println("amount	" + getOutstanding());
}

void printOwing() {
    printBanner();
    printDetails(getOutstanding());
}

void printDetails(double outstanding) {
    System.out.println("name:	" + name);
    System.out.println("amount	" + outstanding);
}

def print_owing():
    print_banner()

    # print details
    print("name:	" + name)
    print("amount	" + get_outstanding())

def print_owing():
    print_banner()
    print_details(get_outstanding())

def print_details(amount):
    print("name:	" + name)
    print("amount	" + amount)

Some IDEs have builtin support for basic refactorings such as automatically renaming a variable/method/class in all places it has been used.

Refactoring, even if done with the aid of an IDE, may still result in regressions. Therefore, each small refactoring should be followed by regression testing.

Choose the correct statements.

a. Refactoring can improve understandability
b. Refactoring can uncover bugs
c. Refactoring can result in better performance
d. Refactoring can change the number of methods/classes

a, b, c, d

Explanation:

(a, b, c) Although the primary aim of refactoring is to improve the internal code structure, there are other secondary benefits.
(d) Some refactorings result in adding/removing methods/classes.

Do you agree with the following statement? Justify your answer.

Statement: Whenever you refactor code to fix bugs, you need not do regression testing if the bug fix was minor.

There are two flaws in the given statement.

DISAGREE.

Even a minor change can have major repercussions on the system. You MUST do regression testing after each change, no matter how minor it is.
Fixing bugs is technically not refactoring.

Explain what refactoring is and why it is not the same as rewriting, bug fixing, or adding features.

Why : the motivation behind the concept in concern (example)

How : the usage of the concept in concern (example)

When : the pros and cons of the concept in concern, when to use the concept (example)

Meaning of icons

: additional info
: warning
: positive message
or : important message
: error or danger to avoid
or : tip
: definition or topic
extra : tangential info, can be ignored if not interested
: 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

Follow this guide @SE-EDU/guides.

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.

CS2113/T week vs normal academic week

Each CS2113/T week starts with the lecture and ends just before the following week's lecture. The only exception is week 1, which starts on the Monday of the first week of the semester.

As our lecture is on Monday, CS2113/T week starts a few days earlier than the normal NUS academic week. For example, CS2113/T week 2 starts on the Monday of NUS week 1. See the full timeline for exact dates.

Deadline for weekly tasks

The deadline to complete tasks allocated to the week is the e.g., if your tutorial is on Thursday, the deadline is Wednesday 23.59midnight before your tutorial day, unless stated otherwise. Our grading scripts that detect your work run at midnight and only the work that's done by midnight will be eligible for marks (for cases where the task is graded).

The typical weekly cycle

[Lecture day (Monday)]

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	~~ICube Auditorium~~ Zoom	1400-1600

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

Mode:

Will be done using Zoom. More information coming soon.

Tips for watching lecture videos

You can watch video lectures at faster speeds (x1.25 or even x1.5) to save time.
Lecture videos require NUSNET login.

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.

[End of lecture - Start of tutorial]

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.

Before attempting weekly project tasks, go through the weekly topics (and do the weekly programming exercises/activities, if any) as the knowledge from those topics may be needed to complete the project tasks.

[During tutorial]

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~~ Zoom	Wed 09:00	~~LC02~~	`CS2113T-W09`	TBD
CS2113	~~COM1-B103~~ Zoom	Wed 10:00	T1	`CS2113-W10`	TBD
CS2113T	~~COM1-B103~~ Zoom	Thu 09:00	~~LC01~~	`CS2113T-T09`	TBD
CS2113	~~COM1-B103~~ Zoom	Thu 10:00	T2	`CS2113-T10`	TBD
CS2113T	~~COM1-B103~~ Zoom	Fri 08:00	~~LC03~~	`CS2113T-F08`	TBD
CS2113	~~COM1-B103~~ Zoom	Fri 10:00	T3	`CS2113-F10`	TBD

The mode

Tutorials will be conducted using Zoom.
MS Teams will be used for file sharing.
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.

Slides and tutorial recordings:

The Zoom recording of a tutorial will be made available to you after the tutorial.
Slides used in tutorials will not be distributed to students. You are expected to take notes (or screenshots) during the tutorial as necessary.

The role of our tutors is different from tutors in other modules.

Not a source of admin information: Given the humongous amount of admin info contained in this module and the fact that it is constantly evolving, tutors may not be aware of the recent subtle changes to the admin information. To safeguard you from receiving incorrect admin info, tutors are prohibited from answering admin queries. If you have an admin query, please post in the forum (or email the prof at cs2113@comp.nus.edu.sg but only if the question is not appropriate for the forum).
No inputs for yet-to-be-graded components: Tutors are prohibited from giving inputs for components not graded yet. Reason: work submitted for grading should be your own.
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, GitHub, 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 almost never 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.
  - Give a meaningful title to the post. Be as specific as you can.
    Bad testing problem
    Good runtest.bat fails with ClassNotFound error
  - Include full error message, screenshots, code snippets, stack traces, etc.
    Note that it is better to give code in text form rather than as screenshots, to allow others to easily copy-paste the code in their reply.
    You can use GFM syntax when posting in the forum.
  - If the problem is code-related, share the full code if possible (e.g., 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. Sharing just a snippet of your choosing might not be enough as the problem may not be where you think it is.
- 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.
- Share the solution. If you eventually managed to solve the problem on your own, share the solution in the thread for the benefit of others, and give closure to those who tried to help you. Don't leave the thread hanging or close it with something like Never mind. I figured it out.
- Don't hijack other threads: It is OK to chime in if you have the same problem as the Original PosterOP but don't ask a different (even if somewhat related) question in someone else's thread. That prevents the OP from closing the thread after the original question has been resolved. Instead, post your question as a separate thread.

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, LMGTFY

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

[lifehacker article] Google Tips and Tricks Every Student Should Know
[Article] How To Ask Questions The Smart Way by Eric Steven Raymond

No ‘mini-lectures’: Tutors are prohibited from 'teaching' concepts that are covered in lectures or other learning resources given to you (reason: 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.

Timing/venue:

Please refer to the Schedule page for further details on each tutorial.
You are expected to be present on time. Punctuality is considered for participation marks.

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.

[End of tutorial - Start of lecture]

Downtime (or catch-up with missed tasks)

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 Command Line InterfaceCLI app while working as a team.

What does mean to 'follow an iterative approach in covering topics'?

It means, we cover a little bit of i.e., requirements, design, testing, project management, ...all SE aspects at first and then iteratively go deeper into them later, revisiting each aspect many time over the course of the semester. In contrast, a sequential approach would have covered one SE aspect before moving to the next (e.g., teach the requirements aspect completely before moving to the design aspect).

The choice of which topics are covered each week is driven by the project i.e., we give priority to topics that you'll need to apply soon in the project that you will be doing in parallel.

This way of 'jumping around' topics feels chaotic but consider the benefits:

It allows you to start doing SE projects early, and iteratively too. That is, you can start with a small project from the very start and make it bigger progressively, learning from earlier mistakes, and getting multiple chances improve on previous attempts.
Important SE aspects such as testing can be practiced from the very beginning. If we followed a sequential approach, you an only learn it near the end of the semester.
Lower risk of missing out some SE aspects altogether. For example, suppose your schedule got heavier in the second half of the semester and you could barely follow the module during that half. You still go away with the basic knowledge of all SE aspects rather than knowing some aspects fully and missing some other aspects altogether.

To help you cope with the non-sequential progression of topics, this module website contains two versions of the topics. In the Schedule page, you'll find the topics organized into the order we cover them in each week. In the Textbook page, you'll find the topics in their natural sequential order. This format is suitable for exam reference.

4 Attend the first lecture

Attend the first lecture on Mon, Jun 21st (compulsory).

Timing/venue:

Module	Venue	Time
CS2113/T	~~ICube Auditorium~~ Zoom	1400-1600

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

Mode:

Will be done using Zoom. More information coming soon.

Tips for watching lecture videos

You can watch video lectures at faster speeds (x1.25 or even x1.5) to save time.
Lecture videos require NUSNET login.

Attendance: Attendance for the first lecture is compulsory.

+ 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: Team forming will be done at the start of the week 3 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.
If you prefer not to form teams yourselves, not to worry; we'll put you in a team.
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

Follow this guide @SE-EDU/guides.

Admin Grade Breakdown

To receive full 5 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), if any:
- Quizzes open around the lecture time and stay open until the next lecture starts. In some weeks, there will be two quizzes (because two smaller quiz is easier for you to manage than one big quiz).
- 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.
Weekly programming exercise (if any):
- 3 points if you submitted correct solutions for at least 75% of the exercises
- 2 points if you submitted correct solutions for 50-74% of the exercises
- 1 point if you submitted correct solutions for 25-49% of the exercises
TEAMMATES peer evaluation sessions: 2 points per session
Other weekly activities:
- There could be other activities related to the lecture, tutorial, or the administration of the module.
- Refer the activity description for evaluation criteria.
- Each activity earns 2 points unless specified otherwise.

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

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

[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

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.

Total: 20 marks

Implementation [10 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 (both Java and Git conventions)
- 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 [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 (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.

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: 45 marks ( 40 individual marks + 5 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/novel/interesting/difficult the features are)
how well it matches the target user

Evaluated by:

the teaching team (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
`feature-fit`		Many of the features don't fit with others	Most features fit together but a few may be possible misfits	All features fit together to for a cohesive whole

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

Note that 'product design' or 'functionality' are not critical learning outcomes of the tP. Therefore, the bar you need to reach to get full 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.

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

Unable to judge
Significantly less than a typical iP
Slightly less than a typical iP
At least as much as a typical iP

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)

Note: Effort put into non-user-visible implementation work (e.g., major refactorings) can also be counted for this component of grading, but it is upto you to describe that work in your PPP so that evaluators can factor those in.

3. Project Grading: QA [ 10 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 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 three types (i.e., type.FunctionalityBug, type.DocumentationBug, type.FeatureFlaw) are counted for three different grade components. The penalty/credit can vary based on the bug type. Given that you are not told which type has a bigger impact on the grade, always choose the most suitable type for a bug rather than try to choose a type that benefits your grade.
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 higher 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 big 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.

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)
Milestones reached on time (i.e., the midnight before of the tutorial) (to get a good grade for this aspect, achieve at least 75% of the recommended milestone progress).
Good use of GitHub milestones mechanism.
Good use of GitHub releases mechanism.
Good version control, based on the repo.
Reasonable attempt to use the forking workflow at least for the early part of the project.
Good task definition, assignment and tracking, based on the issue tracker.
Good use of buffers (opposite: everything at the last minute).

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

There is no midterm exam. Information about the final exam is given below.

The final exam will be as per the normal exam schedule, and will count for 30% of the final grade.
We will use Examplify for the final exam this time.

Exam structure

The exam duration is 90 minutes.

The final exam has two types of questions:

MCQ questions - includes True/False like concept questions and some multiple choice/response questions
Short-answer questions

All questions will be displayed at once as Examplify doesn't allow creating sections
Based on the question you are answering, you need to manage your time appropriately
Weightage of the questions will be displayed to help you with time management

Exam briefing, mock exam, practice exam paper

There will be an exam briefing in the penultimate lecture that covers Examplify usage.
You will be given a practice exam paper (smaller than the full paper) to help you practice timing. That practice paper will be released at least one week before the exam.

Admin Participation Marks

To receive full 5 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), if any:
- Quizzes open around the lecture time and stay open until the next lecture starts. In some weeks, there will be two quizzes (because two smaller quiz is easier for you to manage than one big quiz).
- 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.
Weekly programming exercise (if any):
- 3 points if you submitted correct solutions for at least 75% of the exercises
- 2 points if you submitted correct solutions for 50-74% of the exercises
- 1 point if you submitted correct solutions for 25-49% of the exercises
TEAMMATES peer evaluation sessions: 2 points per session
Other weekly activities:
- There could be other activities related to the lecture, tutorial, or the administration of the module.
- Refer the activity description for evaluation criteria.
- Each activity earns 2 points unless specified otherwise.

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

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

[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

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.

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.

Week 1 [Mon, Jan 11th] - Admin Info

1 Set up the tools before the lecture

Tool: GitHub (for code hosting)

Tool: Git (for revision control)

Tool: Intellij IDE

Tools: for communication

Forum (for longer-running discussions)

Gitter (for quick chats)

Tool: Github Classrooms (for coding exercises)

2 Submit the pre-module survey by Friday 2359

3 Learn about the module

Workload

Star Rating System

Browser compatibility

Information layers

Star Rating System

Conventions used

Shorthand headings

What

Why

How

When

Meaning of icons

Searching for keywords

Saving as PDF files

Printing Textbook Content

Making this Website Better

CS2113/T week vs normal academic week

Deadline for weekly tasks

The typical weekly cycle

Tips for watching lecture videos

Tutorial Timetable

Tutorial Structure

4 Attend the first lecture

Tips for watching lecture videos

+ Other info relevant to this week:

Where is everything?

When to form teams

Team size

Team composition

Saving as PDF files

Peer Evaluation Criteria: Professional Conduct

Peer Evaluation Criteria: Competency

Where to find your participation marks progress

1. Project Grading: Product Design [ 5 marks]

2. Project Grading: Implementation [ 10 marks]

3. Project Grading: QA [ 10 marks]

Grading bugs found in the PE

4. Project Grading: Documentation [ 10 marks]

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

Exam structure

Exam briefing, mock exam, practice exam paper

Peer Evaluation Criteria: Professional Conduct

Peer Evaluation Criteria: Competency

Where to find your participation marks progress

What are the differences between CS2113T and CS2113? : OPTIONAL

Why the workload is so high? : OPTIONAL

What are the extra requirements to get an A+?