Sixteen Weeks From Idea to Handoff

The Capstone Project

COACH

DR. MICHAEL LITMAN, PH.D.

Master Computer Scientist

A capstone is not a big homework assignment. It is the first project you own end to end — and the first one you have to hand to somebody else. You will wear every hat a software team wears, produce every artifact a real project produces, and finish holding a repository a stranger could clone, run, and take over.

START WEEK 1 SEE THE SYLLABUS
16
Weeks
240
Hours budgeted
1
Project, shipped
14
Milestones

A 16-week senior capstone. You bring the idea; this book brings the process. Roughly 240 hours of work — about 15 a week — carried through the full software development life cycle: inception, requirements, design and specification, planning, construction, verification, documentation, deployment, and handoff. Every week ships a milestone that becomes part of the final deliverable: a GitHub repository with working software, a requirements specification, a technical specification, an honest hours log, architecture decision records, a test suite and defect log, a README that walks a stranger through running it, and a handoff guide that lets the next engineer take the project over. It ends with a 30-minute presentation and a submitted repository link.

— SYLLABUS

Part One

Week 1
Ch 1 — The Hats You Will Wear
What a capstone actually is; the modern software development life cycle and the seven hats a solo capstone forces you to wear; the 240-hour budget and where it goes; and standing up your engineering system — repository, project board, and hours log — in Week 1, before you have an idea
P1Project Charter & Engineering System
Week 2
Ch 2 — Finding an Idea Worth 240 Hours
Generating candidate ideas from problems rather than technologies; testing an idea for feasibility, scope, novelty, and evidence of a real user; the arithmetic of right-sizing to 240 hours; and killing two of your three candidates on purpose
P2Idea Portfolio & Scoping Decision
Week 3
Ch 3 — Requirements: Saying Exactly What You Will Build
Elicitation from stakeholders; personas and user stories; functional requirements written so that a stranger could verify them; acceptance criteria; unique identifiers and priority with MoSCoW; and a long side-by-side gallery of bad requirements rewritten into good ones
P3Software Requirements Specification v1
Week 4
Ch 4 — The Requirements Nobody Writes Down
Non-functional requirements made measurable — performance, reliability, security, privacy, accessibility, usability, maintainability, portability; constraints and assumptions; licensing and data obligations; the requirements traceability matrix; and a definition of done you will actually be held to
P4Non-Functional Requirements, Constraints & Definition of Done
Week 5
Ch 5 — Choosing a Stack That Holds Together
Evaluating technologies against your requirements instead of against fashion; integration risk and the cost of learning four new things at once; build versus buy; hosting, cost, and licensing; and recording the decision permanently in architecture decision records
P5Technology Evaluation & Architecture Decision Records
Week 6
Ch 6 — The Technical Specification
Turning requirements into a buildable design: context and component diagrams, module responsibilities, interface and API contracts, the data model, sequence flows for the critical paths, error handling and edge cases — with good and bad specifications shown side by side
P6Technical Specification (System Design Document)
Week 7
Ch 7 — Planning the Build: Estimates, Schedule, and Risk
Wearing the project-manager hat: decomposing the specification into a work breakdown, estimating tasks when you have never done them before, scheduling against the hours you actually have, tracking with a burn-down, and running a risk register with owners, triggers, and responses
P7Work Breakdown, Schedule & Risk Register
Week 8
Ch 8 — The Design Review
The formal review as practiced in industry: roles, preparation, the walkthrough, logging defects instead of debating them; then freezing the specification into a baseline, and running change control for everything that comes after — the midterm checkpoint of the course
Design Review & Midterm Checkpoint

Part Two

Week 9
Ch 9 — The Walking Skeleton
Construction begins with the thinnest possible end-to-end slice: repository structure, branching and commit discipline, a reproducible development environment, continuous integration that runs on every push, issue tracking wired to your requirements, and one real request travelling the whole system
P9Walking Skeleton & Continuous Integration
Week 10
Ch 10 — Iteration One: Building the Core
The developer hat at full speed: working in vertical slices, a per-task definition of done, code review when you are the only reviewer, AI-assisted implementation with real accountability, and keeping the hours log honest while you are too busy to keep it
P10Core Increment & Demo
Week 11
Ch 11 — Testing, Quality, and the Defect Log
Verification as a phase, not an afterthought: the test plan, unit and integration and acceptance levels, traceability from requirement to test case, test data, defect reporting and triage by severity and priority, regression discipline, and knowing when quality is good enough
P11Test Plan, Test Suite & Defect Log
Week 12
Ch 12 — Iteration Two: Integration and the Hard Parts
Integrating the pieces and confronting what you deferred: performance against your own targets, a security pass, third-party failure modes, and the discipline of change control — accepting, deferring, or refusing scope with a written impact analysis instead of a shrug
P12Integrated Release Candidate & Change Log
Week 13
Ch 13 — Documentation Is a Deliverable
Writing the documentation set that carries the largest share of your grade and all of your project's future: the README that actually gets a stranger running, the architecture overview, the runbook, the onboarding guide, the decision record index, and the clean-machine test that proves any of it works
P13Documentation Set & the Clean-Machine Test
Week 14
Ch 14 — Deployment, Reproducibility, and the Handoff
Making the project run somewhere that is not your laptop and continue without you: configuration and secrets, scripted or containerized setup, deployment and rollback, versioning and release tagging, licensing the repository, and assembling the handoff package that lets the next engineer take over
P14Deployable Release v1.0 & Handoff Package
Week 15
Ch 15 — The Thirty-Minute Case
Building and rehearsing the presentation that carries 10 percent of your grade: the arc from problem to result, allocating thirty minutes honestly, slide design that survives a projector, demo discipline and the recorded fallback, answering questions you cannot answer, and telling the truth about what did not get done
P15Presentation Deck, Demo Script & Rehearsal
Week 16
Ch 16 — Delivery Day
Closing the project: the final submission checklist run against the grading rubric, tagging and submitting the repository link, delivering the talk, and the retrospective that turns sixteen weeks into something you can carry into an interview and a career
P16The Final Submission