Chapter 44 — Engineering capstone I | Engineering Cryptography and trust services

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 44 — Engineering capstone I

Lesson map

Lesson 44 published. Map, example, EX130.

flowchart TD
  N0["Learning outcomes"]
  N1["44.1 Choosing the capstone"]
  N2["44.2 Milestones and evidence"]
  N3["44.3 Project risks"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX130"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["44.1 Choosing the capstone"]
  N2["44.2 Milestones and evidence"]
  N3["44.3 Project risks"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX130"]

[Learning outcomes]
    |
    v
[44.1 Choosing the capstone]
    |
    v
[44.2 Milestones and evidence]
    |
    v
[44.3 Project risks]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX130]

Learning outcomes

You will (1) scope a capstone project on the trust service; (2) plan milestones and evidence; (3) identify risks to the project itself.

44.1 Choosing the capstone

For her capstone Aiyana chooses to design and prototype the automated revocation pipeline: when a meter is reported stolen or a key is suspected exposed, revocation must reach every verifier within one minute and be auditable. The project combines earlier topics: key states, message queues, monitoring and runbooks. She writes a scope statement that includes design, a prototype in staging, tests and an operations handover, and excludes changes to meter firmware, which would need vendor involvement beyond the capstone's time.

44.2 Milestones and evidence

Aiyana plans milestones: requirements and threat model by week three, design review by week six, prototype by week ten, verification tests by week twelve and handover by week fifteen. For each milestone she defines evidence: documents, review minutes, test results and a demonstration recording. Her supervisor and Marcus agree the evidence will be assessed against the engineering programme's criteria. Defining evidence early prevents the common capstone failure of a working prototype with no documented reasoning. Missing evidence at a milestone counts as a missed milestone.

44.3 Project risks

Aiyana lists risks to the project: staging environment availability, dependency on the operations team's time, and the possibility that her design conflicts with a planned key service upgrade. Mitigations include booking staging slots early, agreeing a weekly hour with operations, and meeting the key service team in week two. She keeps a risk log updated weekly. Treating the capstone as an engineering project, with its own risks and controls, practises the habits she will need professionally. Risks that grow are escalated to her supervisor the same week.

Worked example

Aiyana scopes a one-minute auditable revocation pipeline capstone, sets five evidence-backed milestones, and logs three project risks with mitigations.

Synthetic case. The capstone plan is invented.

Errors and limits

Capstones often over-scope; firm exclusions protect delivery. Evidence planned late is usually incomplete.

Exercises

EX130 — Capstone goal. What must the revocation pipeline achieve? Rubric: 3 = revocation reaches every verifier within one minute and is auditable;; 2 = one minute;; 1 = vague;; 0 = none.
EX131 — Exclusion. What did Aiyana exclude from scope and why? Rubric: 3 = meter firmware changes, needing vendor involvement beyond the time available;; 2 = firmware;; 1 = vague;; 0 = none.
EX132 — Project risk. Name one project risk and its mitigation. Rubric: 3 = e.g. key service upgrade conflict mitigated by early meeting;; 2 = risk only;; 1 = vague;; 0 = none.

Synthesis

A well-scoped capstone with evidence-backed milestones and its own risk log practises professional engineering on a real security need.

Continue studying — chapter 44 of 50

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