Chapter 38 — Capstone implementation | Bachelor's Critical infrastructure and sector security

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 38 published. Map, example, EX075.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["38.1 Working to a plan"]
  N2["38.2 Building the supporting model"]
  N3["38.3 Collecting evidence from people and hosts"]
  N4["38.4 Surprising and negative results"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX075"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["38.1 Working to a plan"]
  N2["38.2 Building the supporting model"]
  N3["38.3 Collecting evidence from people and hosts"]
  N4["38.4 Surprising and negative results"]
  N5["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX075"]

[Learning outcomes and connection]
    |
    v
[38.1 Working to a plan]
    |
    v
[38.2 Building the supporting model]
    |
    v
[38.3 Collecting evidence from people and hosts]
    |
    v
[38.4 Surprising and negative results]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX075]

Learning outcomes and connection

After this chapter you can (1) execute a capstone plan while controlling scope and recording decisions; (2) collect and manage evidence so that every result traces to its source; (3) build a small, reproducible model or lab that supports your comparison; and (4) handle setbacks — lost access, surprising results — honestly. It builds on Chapters 25, 30, 34, 35 and 37 and prepares the evaluation (Chapter 39).

38.1 Working to a plan

Implementation turns the proposal (Chapter 35) into evidence. Keep three living documents. A project log (date, what you did, what you decided and why). An evidence register (item, source, date, type, how obtained, where stored, which criterion it supports — Chapter 15). A change record for any departure from the proposal, with your supervisor's agreement. Scope creep is the commonest capstone failure: new questions are interesting, but each must either replace something or wait for "future work". In the week-14 checkpoint below, the change record states what replaced the declined second interview, a document review of two public guidance sources, and the validity cost: practitioner input now rests on one interview.

38.2 Building the supporting model

Most bachelor capstones need a small artefact: an exposure model, a dependency simulation, a detector comparison, a coded dataset. Build it with the habits of the labs: standard tools, fixed seeds, scripts not manual steps, outputs saved with the script hash, and tests that check the model on cases with known answers before you trust it on new ones (Chapter 8). Document what the model leaves out. A model that reproduces a hand-calculated simple case and states its assumptions is worth more than an elaborate one nobody can check.

38.3 Collecting evidence from people and hosts

Interviews follow the approved protocol and consent (Chapter 33). Host documents are handled under the placement agreement (Chapter 36). Anything about a real operator's vulnerabilities is held securely and appears in the thesis only in sanitised, host-approved form. If access is withdrawn, use the fallback in your proposal and record the change; do not quietly substitute guesses for data. For the unsupported-devices capstone, interview notes are pseudonymised on the day, stored encrypted, and deleted on the schedule in the consent form. If the host withdraws its device list, the proposal's synthetic inventory replaces it, and the change record says so.

38.4 Surprising and negative results

Results that contradict your expectation are evidence too. If restore drills in your lab model show that the option you expected to win cannot meet the objective, report it and investigate why — perhaps a dependency you had not modelled, such as the image-archive connections that the vendor gateway in 38.5 does not mediate. Do not adjust parameters until the result "looks right"; if you change a parameter, record why and show both results. Honest negative findings are among the most useful outputs a capstone can produce for a host.

38.5 Worked example: an implementation checkpoint (synthetic)

This checkpoint is synthetic. Week 14 of the unsupported-devices capstone (Chapter 35). Done: synthetic inventory of 120 devices built from published categories (script make_inventory.py, seed 38, hash recorded); exposure model for three options with tests reproducing a hand-worked 5-device case; one interview completed, one declined. Changed: the second interview is replaced by a document review of two public guidance sources (change record approved by supervisor; validity note: practitioner perspective now rests on one interview). Surprise: the vendor-gateway option reduced exposure least for imaging devices, because those devices also accept connections from the image archive, which the gateway does not mediate. Instead of treating this as an error, the student models archive-side controls as a variant and records the finding. Next: sensitivity analysis on weights; evidence grading; draft results chapter.

38.6 Common errors and limits

Losing the link between results and the evidence behind them.
Manual analysis steps that cannot be repeated.
Tuning a model until it agrees with expectations.
Silent changes of scope or method.

The week-14 checkpoint avoids each: the inventory script has a seed and hash, the model is tested on a hand-worked case, the gateway surprise is kept, and the interview substitution is recorded. Changing the vendor-gateway parameters until imaging exposure looked smaller would have been the third error. In the checkpoint, the hash of make_inventory.py and the supervisor-approved change record were both written on the day, not reconstructed at thesis time.

Exercises — chapter 38

EX075 — Evidence register. Objective: make traceability concrete. Inputs: the week-14 checkpoint in this chapter. Steps: write five rows of the evidence register with all fields. Expected evidence: table. Rubric: 3 = five complete rows (inventory script output with hash, model test results, interview notes reference, two guidance documents) each linked to a criterion; 2 = missing fields; 1 = list; 0 = none.

EX076 — Report a surprise. Objective: handle unexpected results honestly. Inputs: the gateway finding from the week-14 checkpoint. Steps: write a 150-word results paragraph that reports the finding, its cause, the variant tested and its limits. Expected evidence: paragraph. Rubric: 3 = clear finding, mechanism, variant result reported separately, limits (synthetic inventory, one model), no overclaiming; 2 = partial; 1 = hides or minimises the surprise; 0 = none.

Chapter synthesis

Implementation is disciplined evidence collection: log decisions, register evidence, record changes, build small tested reproducible models, protect host and participant data, and report surprises as findings. The capstone's credibility rests on the trace from each claim back to its evidence.