Chapter 44 — Engineering capstone I
Lesson map
Lesson 44 published. Map, example, EX130.
flowchart TD
N0["Learning outcomes"]
N1["44.1 The need"]
N2["44.2 Requirements"]
N3["44.3 Success measures"]
N4["44.4 Plan"]
N5["44.5 Risks"]
N6["44.6 Agreement"]
N7["Scope control"]
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 The need"]
N2["44.2 Requirements"]
N3["44.3 Success measures"]
N4["44.4 Plan"]
N5["44.5 Risks"]
N6["44.6 Agreement"]
N7["Scope control"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX130"]
[Learning outcomes]
|
v
[44.1 The need]
|
v
[44.2 Requirements]
|
v
[44.3 Success measures]
|
v
[44.4 Plan]
|
v
[44.5 Risks]
|
v
[44.6 Agreement]
|
v
[Scope control]
|
v
[Worked example] --> [Exercise EX130]
Learning outcomes
You will (1) define a capstone project addressing a real supply-chain need; (2) set requirements and success measures; (3) plan work and risks; (4) secure stakeholder agreement.
44.1 The need
Coastline's mobile app builds now run in CI, but the app has no independent check that what riders install matches the signed build. Kwame's capstone: design and build a verification service that checks published app versions against provenance and signatures, and alerts on mismatches.
App stores add a step between Coastline's build and the rider's phone. If a release were altered there, or uploaded by someone who obtained store access, Coastline's own records would not show it. The service fills that gap by checking what the store actually distributes.
44.2 Requirements
Check each new app store release within one hour; compare its digest with the signed build record; verify provenance policy; alert on mismatch; produce a monthly report.
Each requirement is testable. One hour matches how quickly a released app spreads to riders' phones; comparing with the signed record checks integrity; the provenance check confirms the source and builder; alerts reach someone able to act, and the monthly report gives evidence over time. Kwame checks that none of them depends on a manual step, so the service keeps working when he is away.
44.3 Success measures
All releases checked within one hour; zero missed mismatches in a test set of 20 synthetic releases with 5 deliberate mismatches; false alerts under one per month.
The test set checks detection directly: five mismatches hidden among twenty releases, all of which must be found. The false alert limit protects the people who receive alerts, since a noisy verifier would be ignored. Measures are set before building, so they cannot be adjusted afterwards to fit the results. Ingrid agrees them in writing.
44.4 Plan
Twelve weeks: design (2), build (5), test (3), report (2). Weekly reviews with Ingrid and a tutor.
Building takes the largest share because it includes the store integration and the alerting. Three weeks of testing allows time for the test set and fixing what it reveals. Two weeks of reporting is planned rather than squeezed into the end. Weekly reviews catch delays early, while there is still time to adjust scope. Each phase ends with a short demonstration, so progress is shown rather than reported, and the plan states which features would be cut first if the schedule slipped.
44.5 Risks
App store APIs may change; mitigation: abstract the fetch step. Access to signing records needs approval; mitigation: request early.
Each risk has a mitigation the team can act on now. Wrapping store access in one module means an API change affects only that module. Requesting access to signing records early allows time for the approval process. Kwame reviews the risk list weekly and adds new ones, such as a reviewer's leave clashing with the testing phase, and records when each risk closes.
44.6 Agreement
Ingrid and the course tutor sign the project plan.
The signed plan records the scope, requirements, success measures and timeline that all parties accepted. It protects Kwame from requests that would expand the project beyond twelve weeks, and it gives Ingrid confidence that the result will be usable by the platform team. Changes later need agreement from both signers, with the reason recorded. The tutor's signature confirms the project meets the course's academic standards as well as Coastline's needs, so the work can be assessed fairly at the end.
Scope control
Kwame lists what is out of scope: verifying third-party libraries inside the app, checking older releases, and blocking releases automatically. Keeping scope tight lets him deliver a working system in twelve weeks, and the list becomes the starting point for future work.
Stakeholders
Stakeholders are the platform team, which will operate the verifier, the mobile team, whose releases it checks, and the security lead, who receives alerts. Kwame meets each group in the first week to learn their needs and constraints, and records them in the plan.
Worked example
During planning, Kwame learns that app stores may re-sign or repackage apps, so digests may legitimately differ. He revises the requirement: compare the inner application files, not the outer package digest, and documents the reasoning.
Synthetic case. The project is synthetic.
Errors and limits
Capstones must fit time; plan a minimum viable version first.
Exercises
- EX130 — Capstone aim. What does the capstone build? Rubric: 3 = service checking app store releases vs provenance/signatures; alerts; 2 = partial; 1 = vague; 0 = none.
- EX131 — Success test. Describe the test set. Rubric: 3 = 20 synthetic releases, 5 mismatches, zero missed; 2 = partial; 1 = vague; 0 = none.
- EX132 — Revised requirement. Why compare inner files? Rubric: 3 = stores may re-sign/repackage; 2 = partial; 1 = vague; 0 = none.
Synthesis
A good capstone starts from a real need with measurable success and managed risks.
Continue studying — chapter 44 of 50
← Chapter 43 (draft) · Course chapter index · Chapter 45 (draft) →