The course explores engineering principles for building non-trivial software-intensive systems: requirement specification, design, implementation, verification, and maintenance. The course uses a group project as the basic learning vehicle, providing students with an environment for applying the learned principles in practice while coping with constraints encountered when working on a real team: uncertain requirements, tight deadlines, etc. Students are evaluated based on their understanding of the software engineering principles and their ability to apply these principles in practice.
By the end of the course, students will learn several fundamental skills in modern software development:
| Instructor |
Julia Rubin |
|---|---|
| TAs |
Erik Dolinsky Duling Lai Joey Li |
One of EECE 210, CPEN 221, CPSC 210, EECE 309.
The class meets two times a week for lectures and once a week for a lab section. Lab sections are reserved for group meetings. Each group should meet with a TA for 30 minutes a week, preferably during the lab time. In exceptional cases, an alternative time can be arranged in coordination with your TA.
Classroom material will be enhanced with assigned reading. The grading will be based on ~4 in-class quizzes and the group project. There is no final exam.
A major part of the course is the group project. The project simulates real development settings, where development teams communicate with customers to implement software that satisfies the customers’ requirements. The intent of this project is to give you the opportunity to apply the course concepts to a real system.
Scope: You are required to develop a client-server software system; the client side of the system must be a native mobile application that runs on a mobile device (i.e., not in a web browser). The server component can run on a physical machine or in a cloud data center. An example of a reasonably-scoped project is here.
Projects are performed by groups of 3-4 students, which are further paired to form communities. A community consists of two groups, A and B, with 3-4 students in each group. Groups A and B act as customer and development teams to each other. That is, group A acts as a customer of group B, while group B implements the system proposed by group A. At the same time, group B acts as the customer for group A, which implements the idea proposed by group B.
Technology: You have full freedom to choose both client and server technology (i.e., you can use Android, iOS, or a cross-platform mobile framework such as React Native or Xamarin). Your mobile app must run both on an emulator and on some mobile device, but it does not have to run on arbitrary mobile devices.
If you are interested in hosting the backend components on a cloud infrastructure, please let the course staff know and we can provide you with additional resources, such as Microsoft Azure credit.
All development artifacts must be stored in Git – a popular version control system. You will need a GitHub or Bitbucket account, but feel free to create a throw-away or anonymous account for this course, if that makes you more comfortable. Being familiar with Git is essential; please take a look at the 'getting started' part of the Atlassian Git Introduction if you are not familiar with Git. A shorter, less formal, guide is also available.
Logistics: All students in the same community must be in the same lab section; if you want to work with someone who is in another section, one of you will have to transfer lab sections.
Groups must be formed by the end of the second week (i.e., by September 15). Please choose your team members carefully, as no changes will be permitted. If you do not have a team organized after the first lecture, please go to Piazza and find your partners there; otherwise, we will assign you randomly to a team. Everyone should have partners by the end of the second week of the course.
Communities must be formed by the end of the third week (i.e., by September 22); no changes will be permitted. If you cannot find a peer group, we will randomly assign you one.
Communities are required to have regular weekly meetings to synchronize and to report on the work progress. Each meeting must be summarized in a 1-page report and submitted to the course staff. Weekly status reports help to keep the staff and yourselves informed about your progress. The team status must include (a) the deliverables for the week, (b) the plans for next week, (c) major decisions and changes in the scope of the project, and (d) the contributions of individual team members.
Weekly meetings will take around 30 minutes (15 minutes for each “customer” in the community), and will be facilitated and evaluated by the TAs. A staff member will contact your community to set up a meeting during your lab section.
In exceptional cases, meetings outside the lab hours can be arranged in coordination with the TAs. However, the meetings must be held during the same week. Late deliverables will be subject to the following penalties:
Project milestones
Submission guidelines
Grading for this course is based on two components:
There is no final exam.
Note that this is a week-by-week guide only and is subject to change. Reading will assigned at a later point.
| Date | Topic | Project Milestones | Reading Material / Other Comments | |
|---|---|---|---|---|
| W1 | Thu, Sept 7, 2017 | Intro, what is SE | ||
| W2 | Tue, Sept 12, 2017 | Process, Software Lifecycle | Tutorials on Mobile Reading: Git Introduction and Guide |
|
| Thu, Sept 14, 2017 | RE/User Stories | Groups formed Project descriptions due |
||
| W3 | Tue, Sept 19, 2017 | Project pitches | Last day to withdraw | |
| Thu, Sept 21, 2017 | Project pitches | Communities formed | ||
| W4 | Tue, Sept 26, 2017 | UML | Requirements discussed | Reading: Articles on Continous Integration by the Agile Alliance and Martin Fowler |
| Thu, Sept 28, 2017 | Quiz 1 | |||
| W5 | Tue, Oct 3, 2017 | Design, Design Patterns | User stories presented | Reading: composite structure diagram and package diagram. |
| Thu, Oct 5, 2017 | Guest lecture | |||
| W6 | Tue, Oct 10, 2017 | More on design | Design presented | Reading:
1. Design Patterns: Factory Method, Abstract Factory, Decorator, Proxy, and Visitor. 2. The Coming Software Apocalypse |
| Thu, Oct 12, 2017 | Code Reviews, Anti-patterns | |||
| W7 | Tue, Oct 17, 2017 | Teamwork, Version Control | MVP | Reading: Coding Horror "Code Smells", A Taxonomy for Bad Code Smells |
| Thu, Oct 19, 2017 | Quiz 2 (in SWNG 221) | |||
| W8 | Tue, Oct 24, 2017 | Guest lecture | Code Review | |
| Thu, Oct 26, 2017 | Testing | |||
| W9 | Tue, Oct 31, 2017 | Static Analysis | Test plan presented | |
| Thu, Nov 2, 2017 | Symbolic Execution, Model Checking | |||
| W10 | Tue, Nov 7, 2017 | - | Test results presented | |
| Thu, Nov 9, 2017 | Quiz 3 (in PHRM 1101) | |||
| W11 | Tue, Nov 14, 2017 | Guest lecture | Refined specifications presented | |
| Thu, Nov 16, 2017 | DevOps and Microservices | |||
| W12 | Tue, Nov 21, 2017 | More on Microservices + Recap + Quiz 4 preparation + Research in SE | “Almost final” product presented | |
| Thu, Nov 23, 2017 | Quiz 4 (in PHRM 1101) | |||
| W13 | Tue, Nov 28, 2017 | Project presentations | ||
| Thu, Nov 30, 2017 | Project presentations and awards |
We gratefully acknowledge the inspiration we drew part of the material that we adapted from the previous editions of CPEN 321 and CPSC 310, as well as from CSE 403 (University of Washington), CSC C01 (University of Toronto), and CS 169 (UC Berkley).