Chapter 44 — Engineering capstone I
Lesson map
Lesson 44 published. Map, example, EX130.
flowchart TD
N0["Learning outcomes"]
N1["44.1 Problem definition"]
N2["44.2 Plan"]
N3["44.3 Dependencies"]
N4["44.4 Scope control"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX130"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["44.1 Problem definition"]
N2["44.2 Plan"]
N3["44.3 Dependencies"]
N4["44.4 Scope control"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX130"]
[Learning outcomes]
|
v
[44.1 Problem definition]
|
v
[44.2 Plan]
|
v
[44.3 Dependencies]
|
v
[44.4 Scope control]
|
v
[Worked example] --> [Exercise EX130]
Learning outcomes
You will (1) define a capstone problem with a client; (2) plan a substantial security engineering project; (3) manage scope and risk.
44.1 Problem definition
Lindiwe's capstone addresses a problem Saltmarsh identified: recovering dispatch within four hours after ransomware, the objective agreed earlier. Current backups are verified, but nobody has rebuilt the whole dispatch service from scratch. The capstone will design, build and test a recovery process in an isolated environment. Prof. Hale and the security lead sign the problem statement, which lists deliverables, constraints and the criterion for success. The security lead also confirms which systems may be copied into the isolated environment and that only synthetic customer data will be used.
44.2 Plan
Lindiwe divides the project into stages: document dependencies of dispatch, build an isolated recovery environment, script the rebuild of each component, restore data from immutable backups and run timed trials. Each stage has a deliverable and a review. She identifies risks to the project itself, such as delays obtaining test hardware, and plans alternatives, including using virtual machines on a spare server if hardware arrives late. She sets fortnightly review meetings with Prof. Hale and the security lead, each focused on one stage.
44.3 Dependencies
Documenting dependencies reveals surprises. Dispatch needs the directory for logins, the message queue, the mapping service, certificates and a licence server for one component. The licence server had not appeared in any diagram. Without it, the rebuilt service would refuse to start. Lindiwe adds it to the asset model and recovery plan. Prof. Hale notes that hidden dependencies are a common reason recovery takes far longer than planned. She also records the version and owner of each dependency, so the recovery plan can be kept current.
44.4 Scope control
Midway, the operations manager asks whether the capstone could also cover payroll recovery. Lindiwe assesses the effort and explains that adding payroll would risk finishing neither properly. She proposes documenting payroll dependencies only, as input for a later project. The client agrees. She learns that protecting scope is part of delivering value, and that saying no with a clear reason maintains trust better than overpromising. She records the decision in the project log with the operations manager's agreement and a note of the estimated extra effort.
Worked example
Lindiwe defines a dispatch recovery capstone with a four-hour target, plans staged deliverables, finds a hidden licence server dependency and protects scope by deferring payroll.
Synthetic case. The capstone is synthetic.
Errors and limits
Undocumented dependencies make recovery far slower than planned.
Exercises
- EX130 — Success criterion. What is the capstone's success criterion? Rubric: 3 = recover dispatch within four hours;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX131 — Hidden dependency. What dependency was missing from diagrams? Rubric: 3 = a licence server;; 2 = partly correct;; 1 = other;; 0 = none.
- EX132 — Scope decision. What is done about payroll? Rubric: 3 = document dependencies only;; 2 = partly correct;; 1 = full;; 0 = none.
Continue studying — lesson 44 (chapter 44 of 50)
← Chapter 43 · Course chapter index · Chapter 45 →
Continue to the next authored lesson.