How the Capstone Works¶
CSE120 is not a traditional lecture course. Students work on real software projects with external stakeholders — campus departments, community organizations, and industry partners — using industry-standard tools and workflows. The course is designed to bridge the gap between academic programming and professional software engineering.
Course Philosophy¶
The course operationalizes a simple equation:
Software Engineering = Programming + Time + Scale + Trade-offs
Students enter CSE120 knowing how to write code. They leave understanding how to manage code over time, collaborate at scale, and make engineering trade-offs. This shift — from construction to engineering — is the core pedagogical goal.
The recommended reading stack reflects this philosophy: Engineering Software as a Service (ESaaS), Software Engineering at Google, The DevOps Handbook, and Building Microservices.
The Actionable Agenda Lab¶
Lab sessions span 2 hours and 50 minutes — and every minute has a purpose. The traditional "catch-all" lab format has been replaced by the Actionable Agenda model:
| Phase | Duration | What Happens |
|---|---|---|
| Stand-up | 20 min | Teams report blockers, share progress, coordinate |
| Individual Demos | 5 min/student | Each student demonstrates their contributions to the TA — a high-pressure, one-on-one technical validation |
| Workshop Time | Remaining | Hands-on work, triage, peer collaboration |
Before each lab, students must complete a "v0.1" flipped-classroom prerequisite — the initial version of a workshop task done at home using provided Wiki guides.
Team-Based Deliverables¶
Teams work through a series of milestones across the semester:
Labs 1–3: Design Phase¶
Teams produce architecture diagrams, user stories, wireframes, and system designs. Design artifacts must be created programmatically — Mermaid or PlantUML only — hand-drawn diagrams are formally forbidden.
Lab 4: Implementation Phase¶
- Lab 4.0 — DevOps Infrastructure: Individual setup of Docker, CI/CD pipelines, and cloud infrastructure. This is the "you must set up before you can build" phase.
- Lab 4.1 — Walking Skeleton: The first end-to-end integration — a Steel Thread connecting UI → API → Backend → Database → Round-Trip. Proves the architecture works on real infrastructure.
- Lab 4.2 — Core MVP: Teams build out their Minimum Viable Product using MoSCoW prioritization and Tracer Bullets (thin vertical slices).
Midterm¶
A generative midterm where each student receives a unique application concept with a randomized set of technical features — no two students solve the same problem. Vector similarity matching flags submissions with >90% overlap.
Reporting: Changelogs, Not Essays¶
Traditional lab reports — sprawling prose documents — have been replaced by changelog-driven reporting. Teams submit versioned changelogs using semantic versioning (0.X.Y):
- 0.X.0 — A new feature (X increment)
- 0.0.Y — A bug fix or patch (Y increment)
Each version bump must correspond to a merged PR. This approach: - Prevents "automation laziness" — students must manually curate their changelogs, forcing them to understand their own architecture - Trains students to categorize work into Added, Changed, and Fixed — thinking critically about the nature of their contributions - Creates a narrative git history that tells the story of the project's evolution
Tools & Infrastructure¶
| Tool | Purpose |
|---|---|
| GitHub Organizations | Course repository management with branch protection rules |
| GitHub Actions | CI/CD — tests run on every push, merges blocked on failure |
| GitHub Projects | Task tracking and sprint management |
| Codespaces | Standardized development environments |
| T4 (Time & Task Tracker) | Bridges GitHub activity with project management — creates an immutable audit trail of individual contributions |
| UMACS | User Management and Access Control — RBAC across all teaching tools |
| AI Chatbot (LLM + RAG) | Specialized chatbot trained on each team's project description — limited to two 60-minute sessions per team |
Grading Philosophy¶
Grades are computed through a combination of: - Team score (10-point technical rubric: Report Quality 0-2, Steel Thread 1-3, Engineering Practices 1-5) - Individual Multiplier (40% TA assessment, 50% Peer evaluation, 10% Self evaluation) that differentiates individual contributions within teams - Objective repository metrics (Gini coefficient, procrastination index, PR-to-Push ratio)
The negative skew in grade distributions is intentional — teams building working systems score higher. But rigorous individual differentiation prevents low-effort participants from riding team coattails.
Related Projects¶
- GradeFlow — Grading pipeline builder implementing this course's evaluation design.
- Capstone Survey — Collects the student preferences feeding into team formation.
- Team Evaluation — Peer assessment platform providing individual differentiation data.
- T4 + TA Copilot — Task tracking used to monitor team contributions throughout the semester.
- Psephos — Underlying survey engine for course instrumentation.