Chapter 44 — Engineering capstone I

Chapter 44 — Engineering capstone I

Lesson map

Lesson 44 published. Map, example, EX130.

flowchart TD
  N0["Learning outcomes"]
  N1["44.1 Choosing the problem"]
  N2["44.2 Planning evidence"]
  N3["44.3 Agreement and boundaries"]
  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 problem"]
  N2["44.2 Planning evidence"]
  N3["44.3 Agreement and boundaries"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX130"]

[Learning outcomes]
    |
    v
[44.1 Choosing the problem]
    |
    v
[44.2 Planning evidence]
    |
    v
[44.3 Agreement and boundaries]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX130]

Learning outcomes

You will (1) define a capstone architecture problem with scope and success criteria; (2) plan the capstone's evidence; (3) secure supervisor and partner agreement.

44.1 Choosing the problem

For her capstone Sofia chooses the security architecture of Corvia's account-based ticketing back office, building on Design Studio II but at implementation depth for a defined slice: tap ingestion, fare calculation and dispute handling. The problem is real, bounded and assessable. She writes success criteria: all high-priority threats mitigated or accepted by owners; verification tests passing for every security requirement in scope; a recovery trial meeting a stated recovery time; and an independent review with no unresolved critical findings. Clear criteria let examiners judge success without relying on impressions.

44.2 Planning evidence

Sofia plans the evidence she will produce: the requirements and traceability table, threat model, control specifications, verification reports, a recovery trial report, metrics baselines and the independent review report. Each piece of evidence supports a claim in the final assurance case. She schedules them backwards from the submission date, leaving time for revisions after the independent review. Daniel warns that capstones fail more often from late evidence than from poor design, because students leave testing and documentation until the end when there is no time to fix what they reveal.

44.3 Agreement and boundaries

Sofia writes a capstone charter signed by her university supervisor, Daniel and Corvia's head of fare systems. It states scope, deliverables, the lab environment she may use, data restrictions and how Corvia may use her work. It excludes production changes; any implementation happens in a lab mirror. It also covers intellectual property and publication: her thesis may describe the architecture in general terms but not reveal specific weaknesses. Agreeing these points early prevents disputes later and protects both the student and the partner.

Worked example

Sofia scopes a three-component capstone with four success criteria, schedules seven evidence items backwards from submission and signs a charter with three parties.

Synthetic case. The capstone, charter and parties are synthetic.

Errors and limits

Success criteria can be gamed if too narrow. Lab mirrors may lack production complexity.

Exercises

• EX130 — Success criteria. Name two of Sofia's capstone success criteria. Rubric: 3 = two of threats mitigated or accepted, verification tests passing, recovery time met, review with no critical findings;; 2 = one;; 1 = vague;; 0 = none.
• EX131 — Common failure. Why do capstones often fail, according to Daniel? Rubric: 3 = evidence produced too late to fix what it reveals;; 2 = late evidence;; 1 = bad design;; 0 = none.
• EX132 — Charter exclusion. What does the charter exclude? Rubric: 3 = production changes; work happens in a lab mirror;; 2 = production;; 1 = vague;; 0 = none.

Synthesis

A capstone starts with a bounded problem, measurable success criteria, a planned evidence trail and a signed charter.

Continue studying — chapter 44 of 50

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