Chapter 44 — Engineering capstone I
Lesson map
Lesson 44 published. Map, example, EX130.
flowchart TD
N0["Learning outcomes"]
N1["44.1 Scope"]
N2["44.2 Work plan"]
N3["44.3 Risks"]
N4["44.4 Acceptance criteria"]
N5["44.5 Approval"]
N6["Risk responses"]
N7["Schedule"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX130"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["44.1 Scope"]
N2["44.2 Work plan"]
N3["44.3 Risks"]
N4["44.4 Acceptance criteria"]
N5["44.5 Approval"]
N6["Risk responses"]
N7["Schedule"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX130"]
[Learning outcomes]
|
v
[44.1 Scope]
|
v
[44.2 Work plan]
|
v
[44.3 Risks]
|
v
[44.4 Acceptance criteria]
|
v
[44.5 Approval]
|
v
[Risk responses]
|
v
[Schedule]
|
v
[Worked example] --> [Exercise EX130]
Learning outcomes
You will (1) define the capstone scope; (2) plan work and risks; (3) set acceptance criteria.
44.1 Scope
The capstone delivers the full self-restoring hardened public PC service, documented and handed to Fernhill.
Delivering a full service means more than working PCs. It includes the documentation, the runbooks, the dashboard, the trained staff and the evidence that the system meets its requirements. Mateo defines the scope as the set of things Fernhill must have to run the system without him. Features that would be nice but are not needed for that, such as full attestation, are listed as future work.
44.2 Work plan
Remaining tasks: dashboard, firmware update process, final documentation.
The dashboard comes from the second studio's critique, the firmware update process from the safety chapter and the independent review, and the documentation from the maintainability work. Each task has an estimate, an owner and a milestone. Mateo breaks the firmware process into small steps because it is the riskiest, as the worked example explains. Tasks are tracked on a simple board that Marta and Dr Novak can see, and finished tasks link to their evidence.
44.3 Risks
Hardware delays, staff availability and vendor changes.
Hardware delays would hold up the Eastgate disk replacement, which several later tasks depend on. Staff availability matters because the technician is the only other person trained on the restore system. Vendor changes, such as a new booking system version, could break integration without warning. Each risk has a response, described below, and a trigger that tells Mateo when to act. The risk table is reviewed every week, and any risk whose trigger fires gets an action that same day.
44.4 Acceptance criteria
All ten requirements passing; restore within window for 30 consecutive nights; documentation tested by a new technician.
Thirty consecutive nights within the window shows the restore works reliably in service, not just in a pilot week. The documentation test repeats the approach used for maintainability, with a technician who has not worked on the project. All three criteria are measurable and were agreed with Marta and Dr Novak before work began, so there is no room for argument when the time comes to check them.
44.5 Approval
Marta and Dr Novak approve the plan.
Approval is recorded with the plan's version and date, and the plan is stored in the repository with the other project documents. Both approvers can ask for changes at any monthly update. Approval does not freeze the plan: when the hardware delay happens, the plan is updated and the change is approved again. What approval fixes is the acceptance criteria, which change only with both approvers' agreement. Copies are kept by both approvers.
Risk responses
For hardware delays, he orders replacement disks early. For staff availability, tasks are scheduled around the technician's leave. For vendor changes, he subscribes to vendor notices. Each risk has an owner and a trigger for action.
The plan is a one-page table reviewed weekly with Dr Novak.
Schedule
The capstone runs over two terms with milestones every four weeks.
Quality
Each milestone includes tests against requirements.
Communication
Monthly updates go to the board.
Contingency
Two weeks of slack absorb delays.
Stakeholder sign-off
Branch managers confirm the rollout schedule.
Scope control
New requests go to a future list unless they affect requirements.
Tracking
A simple board tracks tasks.
Assumptions
The plan assumes hardware arrives on time and staff remain available.
Approval record
Approvals are stored.
Visibility
The plan is visible to all stakeholders.
Reporting
Progress is reported monthly.
Why criteria matter
Acceptance criteria tell everyone when the project is finished. Without them, work tends to grow without end. Mateo's criteria are measurable and agreed in advance, so acceptance is a check, not a negotiation.
Plan updates
When the hardware delay happens, the plan is updated and stakeholders informed.
Worked example
The firmware update process is the riskiest task; Mateo schedules it first so problems surface early.
Synthetic case. Synthetic.
Errors and limits
Leaving the riskiest task last risks failure at the end.
Exercises
- EX130 — Remaining tasks. What tasks remained? Rubric: 3 = dashboard, firmware process, documentation; 2 = two; 1 = one; 0 = none.
- EX131 — Criteria. State the acceptance criteria. Rubric: 3 = 10 passing, 30 nights, docs tested; 2 = two; 1 = one; 0 = none.
- EX132 — Ordering. Why schedule firmware first? Rubric: 3 = riskiest; surface problems early; 2 = partial; 1 = vague; 0 = none.
Synthesis
Set clear acceptance criteria and tackle risks early.
Continue studying — chapter 44 of 50
← Chapter 43 (draft) · Course chapter index · Chapter 45 (draft) →