Chapter 46 — Engineering capstone II
Lesson map
Lesson 46 published. Map, example, EX136.
flowchart TD
N0["Learning outcomes"]
N1["46.1 Building the prototype"]
N2["46.2 Measuring results"]
N3["46.3 Handover"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX136"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["46.1 Building the prototype"]
N2["46.2 Measuring results"]
N3["46.3 Handover"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX136"]
[Learning outcomes]
|
v
[46.1 Building the prototype]
|
v
[46.2 Measuring results]
|
v
[46.3 Handover]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX136]
Learning outcomes
You will (1) build and test the capstone prototype; (2) measure it against requirements; (3) hand it over to operations.
46.1 Building the prototype
Aiyana builds the revocation pipeline in staging. A revocation request from an authorised operator creates a signed message with the key identifier, reason, time and sequence number. The message queue delivers it to billing, collectors' configuration service and monitoring. Each subscriber verifies the signature with the vetted library, checks the sequence number, updates its key state cache and acknowledges. Unacknowledged deliveries trigger alerts. The prototype uses only existing, approved components, so it can move to production without new security approvals for unfamiliar technology.
46.2 Measuring results
Aiyana runs 1,000 test revocations. The median time to reach all verifiers is four seconds and the slowest is thirty-eight seconds, within the one-minute requirement. Forged revocations signed with a wrong key are rejected by all subscribers. A verifier taken offline for an hour reconciles correctly on reconnect. She also measures operator effort: issuing a revocation takes under a minute through the approved interface. She reports one gap: monitoring dashboards show revocations but not acknowledgements per subscriber, which she adds. All runs are scripted so others can repeat them.
46.3 Handover
Handover includes the design, decision records, runbooks for issuing and auditing revocations, test results and a training session for operators. Operations runs a revocation exercise themselves before accepting the system. Aiyana stays available for two weeks of support. She records known limitations, such as dependence on the message queue's availability, with a fallback runbook for manual revocation distribution. A capstone that ends with a working handover, not just a demonstration, shows professional completeness. Operations signs an acceptance note listing any open issues and their owners.
Worked example
The prototype meets the one-minute target with a median of four seconds and maximum thirty-eight, rejects forgeries, reconciles offline verifiers and is handed over after an operations-run exercise.
Synthetic case. Measurements are invented.
Errors and limits
Staging performance may differ from production. Handover without operator practice leaves knowledge with the builder.
Exercises
- EX136 — Revocation message. What fields does a revocation message contain? Rubric: 3 = key identifier, reason, time, sequence number, signed;; 2 = three;; 1 = one;; 0 = none.
- EX137 — Timing results. Report median and maximum revocation times. Rubric: 3 = four seconds median, thirty-eight seconds maximum;; 2 = one;; 1 = wrong;; 0 = none.
- EX138 — Handover condition. What did operations do before accepting the system? Rubric: 3 = ran a revocation exercise themselves;; 2 = exercise;; 1 = vague;; 0 = none.
Synthesis
A capstone proves itself through measured performance against requirements and a handover that leaves operations able to run it.
Continue studying — chapter 46 of 50
← Chapter 45 (draft) · Course chapter index · Chapter 47 (draft) →