- Submit pre-lecture quiz Mon, Aug 17th 2359 counted for participation
- Set up the tools before the lecture
- Submit the pre-module survey Fri, Aug 14th 2359 counted for participation
- Learn about the module
- Attend the first lecture
1 Submit pre-lecture quiz Mon, Aug 17th 2359 counted for participation
- Read prerequisite Topics allocated for week 1. Submit
Week 1 Quiz(on LumiNUS) to test your knowledge of those topics. Ideally, finish the quiz before the first lecture, latest by the given deadline. The quiz is counted for participation.
Admin Participation
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.
- 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.
B Received good peer evaluations
- -1 for each professional conduct criterion in which you score below average (based on the average of ratings received).
Admin Peer Evaluations → Criteria (Conduct)
- 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.
Admin Peer Evaluations → Criteria (Competency)
- 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.
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).
+ Bonus Marks
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.
Where to find your participation marks progress
Your participation progress can be tracked in this page from week 3 onward.
2 Set up the tools before the lecture
- Follow the Preparation instructions of the following tools.
Admin Programming Language
 |
The main language used in this module is Java. You should use Java for all programming activities, the project, and exam answers. The module doesn’t “teach” Java. We assume you already know Java basics. We expect you to learn on your own any Java constructs not covered in your previous modules. The exam expects you to know Java to the extent that you should be familiar with it as a result 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.
Admin Tools - GitHub
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.
Admin Appendix E - GitHub: Creating an Account
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.
Why am I being encouraged to complete my GitHub profile?
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.
The purpose of the profile photo is for the reader to identify you. Therefore, choose a recent individual photo showing your face clearly (i.e., not too small) -- somewhat similar to a passport photo. 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.
Admin Tools - RCS
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--globalflag 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.
Admin Tools - IDE
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.
Admin Tools - Communication
Tools: for communication
Forum (for longer-running discussions)
- The preferred channels for module-related communication is the
forumon GitHub https://github.com/nus-cs2103-AY2021S1/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-cs2103-AY2021S1/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-cs2103-AY2021S1/community.
- Recommended: Install the Gitter mobile app (search for it in your mobile phone's app store).
3 Submit the pre-module survey Fri, Aug 14th 2359 counted for participation
- 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.
4 Learn about the module
- Read the following admin info about the module.
Admin Module expectations and the star rating system
Here are some important expectations of the module from you.
## Prior Knowledge: Java and OOPThis module requires you to write Java code almost every week, starting from the very first week. If your Java skills are rusty, do brush up your Java programming skills.
In particular, you may want to have a look at the new Java 8 features such as streams, lambdas, Optionals, that may not have been covered in previous Java modules.
CS2103 students: This module assumes a reasonable prior knowledge of Java and OOP because most students taking this module have taken two Java modules before. If you are totally new to Java, you may be better off switching to CS2113 (Software Engineering & Object-Oriented Programming) instead.
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.
- Topics marked with two icons e.g., : , : , : are relevant topics you are expected to have learned in prerequisite modules. They are given for reference, but are examinable. The number of stars indicates the progression of topics, similar to the star rating system above i.e., one-star prerequisite topics are the most basic and the most important. four-star pre-requisite topics can be ignored without affecting CAP.
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.
Admin Using this website [essential info]
The Schedule page is your main source of information for CS2103/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.
Some less important info in a minimized panel
Less important info
Some less important info in a boarder-less panel
Less important info
Some less important info in a panel
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 ExampleThis website uses a star rating system to indicate the priority level of contents.
Admin Module Expectations → Star Rating System
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.
- Topics marked with two icons e.g., : , : , : are relevant topics you are expected to have learned in prerequisite modules. They are given for reference, but are examinable. The number of stars indicates the progression of topics, similar to the star rating system above i.e., one-star prerequisite topics are the most basic and the most important. four-star pre-requisite topics can be ignored without affecting CAP.
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.
Admin Using this website [more info]
Conventions used
Shorthand headings
Meaning of some shortened headings:
- What : the meaning of the concept in concern (example)
Implementation → Refactoring →
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).
- Java: http://refactoring.com/catalog/ -- This is a list of common refactorings maintained by Martin Fowler, a leading authority on refactoring. He is also the author of the ‘bestseller’ on refactoring: Refactoring: Improving the Design of Existing Code
- Python: https://refactoring.guru/refactoring/catalog -- A catalog of refactorings applicable to Python code.
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:
|
→ |
|
|
→ |
|
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.
Exercises
Results of Refactoring
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? Refactoring and regression testing
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 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)
Implementation → Documentation → Guidelines → Describe Top-Down →
The main advantage of the top-down approach is that the document is structured like an upside down tree (root at the top) and the reader can travel down a path she is interested in until she reaches the component she is interested to learn in-depth, without having to read the entire document or understand the whole system.
- How : the usage of the concept in concern (example)
Implementation → Refactoring →
Given below are some more commonly used refactorings. A more comprehensive list is available at refactoring-catalog.
- Java: http://refactoring.com/catalog/ -- This is a list of common refactorings maintained by Martin Fowler, a leading authority on refactoring. He is also the author of the ‘bestseller’ on refactoring: Refactoring: Improving the Design of Existing Code
- Python: https://refactoring.guru/refactoring/catalog -- A catalog of refactorings applicable to Python code.
- When : the pros and cons of the concept in concern, when to use the concept (example)
Implementation → Refactoring →
You know that it is important to refactor frequently so as to avoid the accumulation of ‘messy’ code which might get out of control. But how much refactoring is too much refactoring? It is too much refactoring when the benefits no longer justify the cost. The costs and the benefits depend on the context. That is why some refactorings are ‘opposites’ of each other (e.g. extract method vs inline method).
Exercises
‘Extract method’ and ‘Inline method’ refactorings
‘Extract method’ and ‘Inline method’ refactorings
a
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
: 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.
Admin Weekly schedule
Admin Module overview
A balanced, iterative, and brown-field introduction to Software Engineering...
CS2103/T is an introductory Software Engineering module. It has a 50-50 balance of basic SE theory knowledge and practical skills that you need to gain before industry internships or e.g., CS3203, CS3216/7, CS3281&2, etc.higher-level project modules. The module follows an going through SE topics several times while increasing depth, as opposed to going through topics sequentiallyiterative approach to covering topics. It is also one of the rare SE modules that includes a i.e., working in an existing projectbrown-field project, in addition to a i.e., a project that is started from scratchgreen-field project.
-
On the theory side, this module is supported by a customized online textbook Software Engineering for Self-Directed Learners, integrated into this module website.
-
The practice side, you will first ramp up your technical skills by doing a small individual project (green-field) in which you will develop a personal assistant chatbot called Duke. Then, you will move to a team project (brown-field) in which you will take over an existing project AddressBook-Level3 (AB3) -- a relatively small yet non-trivial (6 KLoC) generic product -- and enhance it into a better product or evolve it into a different product.
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.
Given below is a summary of what the module covers and does not cover.
| Topic | Covered | Not covered |
|---|---|---|
| Java | Used heavily, but not taught | syntax (reason: expected prerequisite knowledge) |
| OOP | Used in a non-trivial project, e.g., Single Responsibility Principle, Open-Closed Principleintermediate OOP principles | basics (reason: expected prerequisite knowledge) |
| SE tools/practices | e.g., revision control, continuous integration, practices, test automation, code reviews, pull requeststhose typically used in a mature, high-rigor SE project | those specific to start-ups |
| Modeling | e.g., class diagrams, sequence diagrams, activity diagramsSome UML notations (sufficient to be able to describe SE artifacts using models, such as seen in this Developer Guide of AB3) | intensive creating detailed UML models before starting to codeupfront design modeling |
| Requirements | e.g., user stories, use casesSome lightweight techniques to gather and document project requirements | rapid prototyping, heavy UI design, designing a product from scratch |
| Documentation | Documentation targeting end users (example) as well as those targeting developers (example) | Marketing materials |
| Project Management | Iterative delivery of a product, working collaboratively with team members, on-site as well as remotely | Setting up project infrastructure from scratch |
| Testing | e.g., automated unit/integration/system testingbasic developer testing and e.g., acceptance testinguser testing | e.g., security testing, performance testing, usability testingtesting for non-functional aspects |
| Applications domains | Cross-platform desktop applications | Web programming, Mobile programming, Database programming |
Admin FAQ: What are the differences between CS2103 and CS2103T?
5 Attend the first lecture
- Attend the first lecture on Fri, Aug 14th (compulsory).
Admin Lectures
Timing/venue:
| Module | Venue | Time |
|---|---|---|
| CS2103 | Friday 1200-1400 | |
| CS2103T | Friday 1600-1800 |
- As the lectures are repeats of each other, you may attend any of the two, except in weeks the lecture is used for the practical exam (PE) or the PE dry run.
- As Zoom has a limitation of 300 participants (and CS2103T has more than 300 students while CS2103 has ~90 students), CS2103T students are encouraged to attend the earlier lecture (except in weeks mentioned above) if you are free during that time. If you can't join the Zoom lecture because it already has 300 participants, we'll make the lecture recording available to you the same day.
Lectures start on time sharp and end around 15 minutes before official end time.
Mode:
- Will be done using Zoom. More information coming soon.
- Some topics come with pre-recorded lecture videos.
Tips for watching lecture videos
- You can watch video lectures at faster speeds (
x1.25or evenx1.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.
