Chapter 35 — Capstone proposal

Chapter 35 — Capstone proposal

Lesson map

Lesson 35 published. Map, example, EX103.

flowchart TD
  N0["Learning outcomes"]
  N1["35.1 Choosing the capstone"]
  N2["35.2 Scope and deliverables"]
  N3["35.3 Evaluation and agreement"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX103"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["35.1 Choosing the capstone"]
  N2["35.2 Scope and deliverables"]
  N3["35.3 Evaluation and agreement"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX103"]

[Learning outcomes]
    |
    v
[35.1 Choosing the capstone]
    |
    v
[35.2 Scope and deliverables]
    |
    v
[35.3 Evaluation and agreement]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX103]

Learning outcomes

You will (1) write a capstone proposal for a security architecture project; (2) define scope, deliverables and evaluation; (3) obtain agreement from sponsors.

35.1 Choosing the capstone

Lucas proposes his capstone: a security architecture for Fernway's planned second warehouse, which will use automated picking robots and a new warehouse management system. The project is real enough to matter to Fernway, bounded enough for one student over two terms, and rich in architecture questions: new suppliers, operational technology on the network, new staff roles and integration with the existing stock system. Dr Bellini approves the topic on condition that the scope excludes the robots' internal safety systems, which need specialist engineers.

35.2 Scope and deliverables

The proposal defines deliverables: an architecture overview for the warehouse, a data-flow model with trust boundaries, a STRIDE and attack-tree analysis, a control set linked to risks, verification tests for five key requirements, and an evaluation. It lists what is out of scope, including robot safety and the supplier's internal development practices. It sets milestones each month. Writing exclusions down protects the student from scope creep and tells the sponsor clearly what will not be delivered, so expectations stay realistic.

35.3 Evaluation and agreement

Lucas defines how the capstone will be judged: whether Fernway adopts the design, whether verification tests pass, and whether an independent reviewer, a security architect from a partner co-operative, finds major gaps. He writes these criteria in the proposal so success is not defined after the fact. Hannah signs as sponsor, Dr Bellini as supervisor, and the warehouse project manager agrees to share documents. The proposal takes four pages and becomes the contract for the next two terms. Copies are kept by all three signatories.

Worked example

Lucas proposes a warehouse security architecture capstone, defines deliverables and exclusions, sets evaluation criteria in advance and obtains three signatures.

Synthetic case. The warehouse and people are synthetic.

Errors and limits

Real projects slip, affecting student timelines. Sponsors may change priorities.

Exercises

• EX103 — Excluded area. What did Dr Bellini require to be excluded? Rubric: 3 = the robots' internal safety systems;; 2 = robot safety;; 1 = vague;; 0 = none.
• EX104 — Why list exclusions. Why write exclusions into the proposal? Rubric: 3 = to prevent scope creep and set sponsor expectations;; 2 = scope;; 1 = vague;; 0 = none.
• EX105 — Advance criteria. Why define evaluation criteria in the proposal? Rubric: 3 = so success is not defined after the fact;; 2 = advance;; 1 = vague;; 0 = none.

Synthesis

A capstone proposal fixes scope, deliverables, exclusions and evaluation before work begins.

Continue studying — chapter 35 of 40

← Chapter 34 (draft) · Course chapter index · Chapter 36 (draft) →