Chapter 44 — Engineering capstone I

Chapter 44 — Engineering capstone I

Lesson map

Lesson 44 published. Map, example, EX087.

flowchart TD
  N0["Learning outcomes"]
  N1["44.1 Capstone brief"]
  N2["44.2 Deliverables for Capstone I"]
  N3["44.3 Assessment"]
  N4["Engineering note"]
  N5["44.6 Agreeing the capstone baseline"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX087"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["44.1 Capstone brief"]
  N2["44.2 Deliverables for Capstone I"]
  N3["44.3 Assessment"]
  N4["Engineering note"]
  N5["44.6 Agreeing the capstone baseline"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX087"]

[Learning outcomes]
    |
    v
[44.1 Capstone brief]
    |
    v
[44.2 Deliverables for Capstone I]
    |
    v
[44.3 Assessment]
    |
    v
[Engineering note]
    |
    v
[44.6 Agreeing the capstone baseline]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX087]

Learning outcomes

You will (1) scope a capstone migration project; (2) produce requirements, architecture and plan; (3) build a first increment; and (4) present progress with evidence. It integrates Chapters 20–43.

44.1 Capstone brief

Migrate BPA's partner-facing ecosystem — edge TLS, partner VPNs, bills-of-lading signatures and customs exports — to quantum-resistant key establishment and a defined path for signatures, with crypto-agility and measurement, within an 18-month programme. Capstone I covers scoping through a first increment; Capstone II (Chapter 46) completes and validates.

The 18-month window is deliberately shorter than a full migration, so students must choose a meaningful first increment and show how the rest follows. Partner-facing systems are chosen because they combine the longest-lived data with the dependencies that set the pace.

44.2 Deliverables for Capstone I

1. Scope statement and stakeholder map.
2. Requirements with traceability (Chapter 21).
3. Asset-flow model and CBOM baseline (Chapters 22, 29).
4. Threat and FMEA analysis (Chapter 23).
5. Architecture with alternatives and decisions (Chapters 25–27).
6. First increment: hybrid TLS on the partner API in a test environment with measurement.
7. Plan for Capstone II with risks.

The deliverables follow the order of the book's earlier chapters, so each draws on a practised method. The first increment matters most because it turns plans into evidence: a hybrid TLS test environment with measurement shows that the team can deliver, and its results feed the canary design for production. The plan for Capstone II lists dependencies such as HSM procurement explicitly.

44.3 Assessment

Assessors look for traceability from requirements to design to tests, honest unknowns in the CBOM, a working increment with evidence, and a plan whose dependencies are visible.

Assessors trace at least one requirement end to end, from source through design decision to test result, and check that the CBOM's unknown share is reported, not hidden. A plan whose critical path is visible earns more credit than one with more features but no dependencies shown. Submissions that state limits clearly are rated higher than those that claim more than their evidence supports.

44.4 Worked example

A model Capstone I submission identifies 37 exposed long-lived flows, chooses hybrid key exchange everywhere external, defers public certificate migration with rationale, demonstrates the partner-API increment with 0 failures in 20,000 lab connections (95% upper bound 1.5 × 10^-4) and lists HSM procurement as the critical path.

The upper bound comes from the rule of three: three divided by 20,000 connections gives one and a half in ten thousand, which is within the availability budget in REQ-AV-01. Naming HSM procurement as the critical path shows the team understood the dependency graph from the integration chapter, where the HSM gated five work packages. Deferring public certificates is accepted because the rationale cites browser support and the active-attack argument.

44.5 Common errors and limits

• Scope too broad to deliver an increment.
• No baseline measurement.
• Plans without dependencies.

A scope covering the whole port cannot deliver a working increment in the time available, so the submission becomes a plan with no evidence. Without a baseline measurement, Capstone II cannot show improvement, as the baseline agreed at the start makes clear. Plans without dependencies miss long-lead items such as HSMs, which then delay several work packages at once. Assessors check for all three in the first week so teams can still correct them.

Engineering note

Keep a decision log from the first day of the capstone. Each entry records the date, decision, alternatives considered, evidence and who agreed. The log feeds the architecture chapter of the thesis, answers reviewers' "why" questions quickly and protects the team when a later discovery makes an earlier decision look wrong — it shows what was known at the time. Examiners consistently rate capstones with clear decision logs higher than those with polished but unexplained designs.

44.6 Agreeing the capstone baseline

Capstone I begins by recording BPA's starting state: which links use hybrid key exchange, which certificates chain to classical roots, and which inventory entries are still unverified. Progress in Capstone II is measured against this baseline, so later claims of improvement can be checked by the assessor.

The baseline is signed by the assessor and stored in the dossier before any change is made. It uses the same measurement methods that Capstone II will use, such as passive telemetry for negotiated groups, so differences reflect real change rather than a new method. Unknown entries are counted explicitly, since reducing them is one of the capstone's goals.

Exercises

• EX087 — Scope. Write the capstone scope statement with in/out of scope. Rubric: 3 = deliverable increment, explicit exclusions.
• EX088 — Increment evidence. Define the evidence package for the first increment. Rubric: 3 = configuration, tests, measurements, traceability.

Synthesis

Capstone I proves that the student can scope, model, design and deliver a first measured increment of a real-shaped migration.

Continue studying — chapter 44 of 50

← Chapter 43 (draft) · Course chapter index · Chapter 45 (draft) →