Project Roadmap¶

Thirty projects and ten capstones, arranged so that each one asks you for something you have not done before. This page is the path: what to do when, in what order, and what each step is actually testing.

The tiers differ in how much design freedom you get, not in how long they take. A mini project tells you the classes. A capstone tells you the problem and nothing else.

  Mini            Intermediate        Advanced             Capstone
  ────            ────────────        ────────             ────────
  1–3 classes     4–8 classes         8–15 classes         whatever it needs
  2–5 hours       10–18 hours         1–3 weeks            a term
  1 idea each     a small system      a design you defend  a system you own

  Modules 1–8     Modules 8–13        Modules 12–15        Modules 1–16

The path in one table¶

Stage	After	Do	What it proves
1	Module 2	Mini 1, Mini 2	You can write a class with an invariant, from scratch
2	Module 5	Mini 3, Mini 4	Operators and class-level state are things you can design, not copy
3	Module 8	Mini 5, Mini 6, Mini 7	You can put a polymorphic container together and keep the lifetimes straight
4	Module 10	Mini 8, Mini 9, Mini 10	Templates, exceptions and the STL are usable, not just known
5	Module 11	Two intermediate projects	You can hold a small system together on your own
6	Module 13	Two more intermediate projects	Failure behaviour is part of your design, not an afterthought
7	Module 15	One or two advanced projects	You can make, name and defend a design decision
8	Module 16	One capstone	You can carry a system from problem statement to design report

If you are studying to a schedule, the minimum honest path is: three mini projects, four intermediate, one advanced, one capstone. That is enough to have built something with every element in the course at least once, and it is roughly the workload of a single term's project plus exercises.

What each tier demands, and what it leaves to you¶

	Mini	Intermediate	Advanced	Capstone
Class list	Given or suggested	Yours, with the elements stated	Yours	Yours
Relationships	One or two	An ownership diagram required	Diagram, multiplicities, justified	Diagram, justified, marked as a deliverable
Polymorphism	Where it is the topic	Required	Required, with no type tags in the core	Required
The STL	Optional but likely	Required, with reasons	Required, with measurements or arguments	Required
Exceptions	Refusals only	A failure policy required	Guarantees designed and tested	Guarantees, failures and recovery designed
Patterns	None	Considered, not required	Two named and one declined, argued	Two required and one declined, argued
Persistence	No	Usually required	Required, with a versioned format	Required, with hand-editing tolerated
Tests	A checklist run	Assertions, invariants and boundaries	Assertions plus a deliberate bug caught	Full suite, plus a design report
Writing	A checklist	A one-page design note	One to two pages, with decisions reversed	A design report, with one decision reversed

Concept coverage: where each idea is first forced¶

Every concept in the course appears at least twice across the tiers. The first project that forces it — as opposed to allowing it — is listed here.

Concept	First forced by
Encapsulation and invariants	Mini 1 — Temperature Converter
Operator overloading	Mini 3 — Fraction Type
Static members and lifetimes	Mini 4 — Visitor Counter
Inheritance and abstract interfaces	Mini 5 — Shape Areas
Copy and move semantics	Mini 6 — Stopwatch
Ownership with smart pointers	Mini 7 — Playlist Ownership
Templates and non-type parameters	Mini 8 — Generic Ring Buffer
Exception hierarchies and guarantees	Mini 9 — Report Parser
Containers and algorithms with reasons	Mini 10 — Word Frequency
Composition and ownership across objects	Intermediate 1 — Virtual Zoo
Rules that vary by configuration	Intermediate 2 — Student Gradebook
Undo, as a design decision	Intermediate 3 — Shape Editor
State machines	Intermediate 6 — Vending Machine
Golden-file testing	Intermediate 10 — Shipping Quote Engine
A named design pattern, justified	Advanced 1 — Chess Engine Core
Recalculation and dependency graphs	Advanced 2 — Spreadsheet Engine
Deterministic simulation	Advanced 5 — Elevator Simulation
Compile-time versus run-time decisions	Advanced 6 — Policy-Based Cache
Extension without editing the host	Advanced 8 — Plugin Command Runner
A whole system, designed and defended	Capstone options

Choosing what to do, if you have limited time¶

Two weeks. Pick three mini projects that cover concepts you have not yet used in your own code — usually the ones you have only read about. Then stop; a rushed capstone is worse than none.

A month. Four mini projects, then two intermediate projects from different skill columns (one for invariants, one for persistence). Write both design notes properly.

A term, with an assessed project. Two mini, two intermediate, one advanced, then one capstone. Do not start the capstone before the advanced project is finished and reviewed, because the capstone assumes you can already make design decisions unaided.

A term, self-study, no assessment. Follow the eight stages in the table above. The value is in the order, not in the count: each project prepares you for the next, and skipping stages shows up as a design that cannot survive a change.

When the last project is done: teach it

The one test of understanding that nothing else substitutes for is explaining it. Rewrite your hardest module from memory as though you were teaching it, then correct it against the real page — the corrections are your revision list. Or take an advanced project you finished and implement one part a second, different way, then write down which version you would keep and why. That comparison is the design judgement the capstone is marked on.

How the tiers build on each other¶

Each tier reuses a skill the previous one introduced, but not the same domain or the same code. That is deliberate: a project that starts from your own previous solution is an extension, not a project — and the capstone briefs explicitly rule out reusing the lab system for the same reason.

Mini → Intermediate. Mini teaches one class with an invariant. Intermediate asks for several classes with relationships, and for the invariant to survive operations that touch two objects.
Intermediate → Advanced. Intermediate asks for a system that works. Advanced asks for a system whose structure you chose, can name, and would defend under challenge.
Advanced → Capstone. Advanced asks for one deep decision, named and justified. The capstone asks for many, held together: a documented format, a multi-file layout, a test suite, patterns justified by requirements, and a design report that names the decision you would reverse.

The no-solutions rule, across the whole ladder¶

None of these projects comes with a complete solution in this course. The sixteen labs have reference solutions because the labs teach techniques; the projects exist to make you practise choosing among them. Each brief gives you requirements, constraints, a design discussion that raises the questions without answering them, and checklists that are strict enough to serve as a code review.

Reading a solution to a project you have attempted teaches you less than re-reading your own design note. That is not a motivational claim; it is what the rubric measures.