55AA Security Lab

55AA-001

Software Engineering

Level
Undergraduate
Status
Under development

Note: this course is still being designed and calibrated; the page content is for reference and does not represent the final teaching version.

Syllabus

Course Overview

This course is for undergraduates who already have basic programming experience. It trains students to turn an ambiguous problem into maintainable, testable, and evolvable software. The design draws on MIT 6.102's emphasis on construction quality, CMU 17-313's treatment of engineering process and teamwork, Berkeley CS 169A's agile and user-value orientation, and UW CSE 403's focus on real project delivery. In the 55AA context, software engineering is taught as disciplined work for reliability, security, and long-term maintenance.

This is the engineering entry course in the 55AA curriculum and a practical foundation for later courses in software security, program analysis, and security baseline automation.

Prerequisites

  • Ability to program independently in at least one general-purpose language and complete programs of roughly 1000 lines.
  • Basic understanding of data structures, modularity, command-line tools, Git, and unit testing.
  • Willingness to work in a team under code review, refactoring, and continuous delivery constraints.

Learning Outcomes

  • Decompose open-ended requirements into user stories, quality attributes, acceptance criteria, and schedulable tasks.
  • Design modules, interfaces, and data models with clear boundaries and explain the tradeoffs.
  • Use version control, code review, static checks, tests, and CI to maintain team code quality.
  • Write tests that cover normal paths, boundary cases, error handling, and regression risks.
  • Deliver a working system iteratively and support maintenance through monitoring, documentation, and release processes.
  • Identify common engineering risks including requirements drift, technical debt, dependency risk, security flaws, and team coordination failure.

Course Format

  • Two meetings per week: one for concepts and cases, one for design review, code review, or project studio work.
  • A deliverable iteration every two weeks, including a working demo, test results, and a short retrospective.
  • The course project is completed by teams of 4 to 5 students, preferably on lab tooling, course platforms, data processing, or security engineering systems.

Weekly Plan

Week 1

Why software engineering is hard

Analyze a failed project; set up the team repository and working agreement.

Session 1Why software engineering is hard: Concepts, Cases, and Method90 minSession 2Why software engineering is hard: Lab, Review, and Transfer90 min
Week 2

Requirements, user stories, and quality attributes

Turn an open-ended topic into user stories, acceptance criteria, and a risk list.

Session 3Requirements, user stories, and quality attributes: Concepts, Cases, and Method90 minSession 4Requirements, user stories, and quality attributes: Lab, Review, and Transfer90 min
Week 3
Week 4
Week 5
Week 6
Week 7
Week 8

Midterm project review

Demo the second iteration; submit a midterm retrospective and revised roadmap.

Session 15Midterm project review: Concepts, Cases, and Method90 minSession 16Midterm project review: Lab, Review, and Transfer90 min
Week 9
Week 10

Security requirements and secure coding basics

Perform threat modeling and fix at least two security or robustness issues.

Session 19Security requirements and secure coding basics: Concepts, Cases, and Method90 minSession 20Security requirements and secure coding basics: Lab, Review, and Transfer90 min
Week 11
Week 12
Week 13
Week 14
Week 15
Week 16

Final demo and engineering retrospective

Deliver the final version, technical report, demo, and individual reflection.

Session 31Final demo and engineering retrospective: Concepts, Cases, and Method90 minSession 32Final demo and engineering retrospective: Lab, Review, and Transfer90 min

Assessment

Individual assignments

Short assignments on requirements analysis, interface design, test design, refactoring, and failure review.

20%
Team project

Four iterative deliveries graded on user value, engineering quality, test evidence, maintainability, and security awareness.

40%
Code review and engineering records

Pull request quality, review feedback, issue management, design records, and release notes.

15%
Final technical report and demo

A report covering system goals, architecture, key implementation choices, testing and deployment, known limits, and a roadmap.

20%
Participation

Participation in discussions, reviews, project meetings, and peer feedback.

5%

Course Project

The team project must have real users or a clear usage scenario. Minimum deliverables include a runnable deployment, core feature demo, automated tests, code review records, threat-modeling notes, release notes, and maintenance documentation. Students are encouraged to build systems the lab can continue to use, such as course material management, publication and project pages, lab platforms, data ingestion tools, lightweight security scanners, or compliance checkers.

Policies

  • AI tools are allowed, but generated code, lab notes, and design suggestions must be reviewed by the student and disclosed in the report.
  • Students may not submit code, proofs, configuration, or experimental results they cannot explain; each member must defend their own design, tests, and tradeoffs.
  • Late work affects iteration grades, but the course values reproducible, auditable, and maintainable results over last-minute accumulation.

Reference Courses

International

China 985 Universities