◇ OpenCyber Academy
Bachelor's · Chapter 38 · English

Chapter 38 — Capstone implementation

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

Chapter 38 — Capstone implementation

Lesson map

Lesson 38 published. Map, example, EX075.

flowchart TD
  N0["Learning outcomes"]
  N1["38.1 Executing the plan"]
  N2["38.2 Reproducibility"]
  N3["38.3 Scope changes"]
  N4["38.4 Decision records"]
  N5["38.6 Practical activity"]
  N6["38.8 Working with supervisors"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX075"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["38.1 Executing the plan"]
  N2["38.2 Reproducibility"]
  N3["38.3 Scope changes"]
  N4["38.4 Decision records"]
  N5["38.6 Practical activity"]
  N6["38.8 Working with supervisors"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX075"]

[Learning outcomes]
    |
    v
[38.1 Executing the plan]
    |
    v
[38.2 Reproducibility]
    |
    v
[38.3 Scope changes]
    |
    v
[38.4 Decision records]
    |
    v
[38.6 Practical activity]
    |
    v
[38.8 Working with supervisors]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX075]

Learning outcomes

You will (1) execute your capstone plan with milestones; (2) maintain reproducible code and lab records; (3) manage scope changes; and (4) document decisions as you go.

38.1 Executing the plan

Work in milestones: environment ready; first data or model; first analysis; full analysis; draft report. At each milestone, compare progress with the plan and record deviations. Small, frequent progress beats large late pushes.

Plan a buffer before the draft report milestone, since analysis almost always takes longer than expected. If a milestone slips, say so early and adjust what follows, rather than compressing the writing into the final weeks. A short note at each milestone, saying what was done and what is next, makes later reporting much easier.

38.2 Reproducibility

Use version control for code, configuration and text. Record environment versions. Write scripts that regenerate every figure and table from raw inputs. Keep synthetic data generators with fixed seeds so results can be reproduced exactly, as the labs in this book do.

Test reproducibility yourself before submission by cloning the repository into a clean environment and running everything from scratch. Anything that fails there would fail for an examiner too. Record the date and result of that check in your lab record, so you can show it was done.

38.3 Scope changes

Discoveries change plans. If a vendor's documentation shows that a planned lab is impossible, record the change, its reason and its effect on aims, and agree it with your supervisor. Silent scope changes make evaluation unfair and conclusions unclear.

Keep scope changes in the same place as decision records, so that the final report can list them together. A change that narrows the work is acceptable if it is explained; a change hidden in the results is not. Your evaluation will be judged against the agreed scope, so make sure it is current.

38.4 Decision records

Keep short decision records: context, options, decision, consequences. "We chose ML-KEM-768 rather than -1024 for the lab because the synthetic HCU policy requires category 3 and the TLS group uses -768." Decision records make the final report easier to write and defend.

Write each record at the time of the decision. A record written months later tends to justify the outcome rather than explain the reasoning, and reviewers can usually tell the difference. For the capstone, a folder of dated one-page records is enough.

38.5 Worked example

The capstone from Chapter 35 builds a 60-asset synthetic HCU CBOM generator with a fixed seed, a ranking script sweeping z from 10 to 25 years and a report generator. At milestone 3 the student finds that the top-five ranking changes at z = 12 because member records enter. Decision record: report the change as a finding and add a sensitivity figure rather than adjusting assumptions to make the ranking stable.

The sensitivity figure later became one of the main results of the capstone. It was kept in the final report.

38.6 Practical activity

Set up your repository with code, data generator, lab record template and decision-record folder; complete your first milestone review.

The milestone review should compare what you planned with what you have done and record any changes. Check that a fresh clone of the repository can run the data generator and reproduce the first results. If it cannot, fix that before going further, because the problem only grows as more code and data are added. Then plan the second milestone with dates.

38.7 Common errors and limits

Each makes the final report harder to write and harder to defend. Most can be avoided with a fixed weekly routine of commits, notes and a brief check against the plan.

38.8 Working with supervisors

Share milestone reviews with your supervisor briefly and regularly: what was done, what was learned, what is blocked and what decision you need. Supervisors can only help with problems they know about, and a short written update creates a record that later shows how the work evolved.

Keep the updates in the repository. A good update fits in a few lines and ends with a clear question when you need a decision. Record the answer in your decision records, so that agreed changes to method or scope are visible later and are not reopened at the evaluation stage.

Exercises

Synthesis

Milestones, version control, reproducible scripts, recorded scope changes and decision records turn a capstone plan into credible work.

Continue studying — chapter 38 of 40

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