CS2103/T: Software Engineering
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 |