Chapter 38 — Capstone implementation

Lesson map

Lesson 38 published. Map, example, EX112.

flowchart TD
  N0["Learning outcomes"]
  N1["38.1 Doing the work"]
  N2["38.2 Managing change"]
  N3["38.3 Traceability"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX112"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["38.1 Doing the work"]
  N2["38.2 Managing change"]
  N3["38.3 Traceability"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX112"]

[Learning outcomes]
    |
    v
[38.1 Doing the work]
    |
    v
[38.2 Managing change]
    |
    v
[38.3 Traceability]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX112]

Learning outcomes

You will (1) carry out the capstone architecture work; (2) manage changes in a live project; (3) keep traceability from risks to controls.

38.1 Doing the work

Lucas works through the capstone deliverables for the new warehouse. He models the warehouse management system, the robot controllers, the stock system integration and the supplier's remote support link. He marks a boundary between the robot network and the office network, with only the warehouse management system allowed to talk to both. He runs STRIDE and an attack tree for the goal "stop picking during peak season", which reveals that the supplier's remote support link is the easiest path because it uses a shared password.

38.2 Managing change

Midway, Fernway switches warehouse management vendors after a pricing dispute. Lucas's models are partly obsolete. He reviews which deliverables are affected, informs Hannah and Dr Bellini, and agrees a revised milestone. The new vendor's system uses a cloud service rather than an on-site server, so the boundary moves. He reuses his method and most of his risk list, updating only what changed. The experience teaches him that architecture documents must be designed to change, with clear assumptions so readers know what to revisit.

38.3 Traceability

Lucas keeps a table from each risk to its controls, requirements and verification tests, as in chapter 24. When the vendor changes, the table shows which controls depend on the old system and need replacing. The supplier remote support link becomes a requirement for named accounts with multi-factor authentication and session recording, verified by a test login. By the end, every high risk traces to at least one verified control. Traceability makes the capstone auditable and lets Fernway maintain the design after Lucas leaves.

Worked example

Lucas models the warehouse, finds a shared-password support link, adapts to a vendor switch and maintains risk-to-test traceability.

Synthetic case. The warehouse and vendors are synthetic.

Errors and limits

Vendor changes can invalidate earlier tests. Traceability tables need ownership to stay current.

Exercises

• EX112 — Easiest path. What was the easiest path to stopping picking?
  Show marking criteria

  Rubric: 3 = the supplier's remote support link with a shared password;; 2 = support link;; 1 = vague;; 0 = none.
• EX113 — Vendor switch. How did Lucas handle the vendor switch?
  Show marking criteria

  Rubric: 3 = reviewed affected deliverables, agreed new milestones, reused method and updated what changed;; 2 = adapted;; 1 = restarted;; 0 = none.
• EX114 — Support link control. What requirement replaced the shared support password?
  Show marking criteria

  Rubric: 3 = named accounts with multi-factor authentication and session recording;; 2 = named;; 1 = vague;; 0 = none.

Synthesis

Capstone implementation succeeds through solid models, adaptation to change and traceability from risk to verified control.

Continue studying — chapter 38 of 40

← Chapter 37 (draft) · Course chapter index · Chapter 39 (draft) →