Chapter 39 — Human factors and cyber policy: maintainability
Lesson map
Lesson 39 published. Map, example, EX115.
flowchart TD
N0["Learning outcomes"]
N1["39.1 Lasting design"]
N2["39.2 Content lifecycle"]
N3["Lab — Content items due for review by quarter"]
N4["39.3 Handover"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX115"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["39.1 Lasting design"]
N2["39.2 Content lifecycle"]
N3["Lab — Content items due for review by quarter"]
N4["39.3 Handover"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX115"]
[Learning outcomes]
|
v
[39.1 Lasting design]
|
v
[39.2 Content lifecycle]
|
v
[Lab — Content items due for review by quarter]
|
v
[39.3 Handover]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX115]
Learning outcomes
You will (1) design the programme to be maintained over years; (2) manage content and template lifecycles; (3) plan handover and documentation.
39.1 Lasting design
Programmes often decline when their founder leaves. Aiko designs Greyford's programme to be maintainable: documented procedures, a charter with owners, a content library with review dates and measures produced automatically from the triage tool. She avoids custom software where a supported product feature exists, because custom tools need specialists to maintain. She also budgets a fixed amount of staff time each year for review and update, so that maintenance does not depend on spare time that may never appear in a busy utility.
39.2 Content lifecycle
Every guide, refresher and simulation template has an owner, a creation date and a review date. Content older than a year is reviewed against current attack reports, such as the latest Verizon DBIR, and against Greyford's own reported emails. Templates are retired when they no longer reflect real lures or when complaints show they cause harm. The lab counts items due for review each quarter so that the work can be planned. A small, current library is better than a large one full of outdated examples.
Lab — Content items due for review by quarter
# Content items due for review by quarter (synthetic library of 40 items).
due = {"Q1": 9, "Q2": 11, "Q3": 14, "Q4": 6}
for q, n in due.items(): print(f"{q}: {n} items")
print("busiest:", max(due, key=due.get), "total:", sum(due.values()))
Run with python3 lab_lifecycle.py. Verified output:
Q1: 9 items
Q2: 11 items
Q3: 14 items
Q4: 6 items
busiest: Q3 total: 40
39.3 Handover
Aiko writes a handover pack: the charter, the operations calendar, the requirements and verification table, the measures with their definitions and the ethical rules for simulations. A deputy shadows each task for one cycle before taking it on. She records short videos explaining the reasoning behind key decisions, because documents often record what was done but not why. Prof. Kerr notes that the reasons are what allow successors to adapt wisely rather than either freezing or abandoning the design. The pack is reviewed annually.
Worked example
Aiko designs for maintenance with owners and review dates, plans content review by quarter and writes a handover pack with reasons.
Synthetic case. Content data are synthetic; the Verizon DBIR is real.
Errors and limits
Review dates are often missed. Handover packs go stale.
Exercises
- EX115 — Custom software. Why avoid custom software? Rubric: 3 = it needs specialists to maintain;; 2 = maintenance;; 1 = vague;; 0 = none.
- EX116 — Lab review load. Which quarter had the most content due for review? Rubric: 3 = Q3 with 14 items;; 2 = Q3;; 1 = vague;; 0 = none.
- EX117 — Recording reasons. Why record the reasons for decisions? Rubric: 3 = so successors can adapt wisely;; 2 = adapt;; 1 = vague;; 0 = none.
Synthesis
Maintainable programmes have owners, review dates, planned effort and handovers that explain why.
Continue studying — chapter 39 of 50
← Chapter 38 (draft) · Course chapter index · Chapter 40 (draft) →