◇ OpenCyber Academy
Engineering · Chapter 44 · English

Chapter 44 — Engineering capstone I

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 44 — Engineering capstone I

Lesson map

Lesson 44 published. Map, example, EX130.

flowchart TD
  N0["Learning outcomes"]
  N1["44.1 Choosing a scope"]
  N2["44.2 Charter"]
  N3["44.3 Team roles"]
  N4["44.4 Ethics approval"]
  N5["44.5 Risk register"]
  N6["Practice note — first milestone"]
  N7["Supervisor cadence"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX130"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["44.1 Choosing a scope"]
  N2["44.2 Charter"]
  N3["44.3 Team roles"]
  N4["44.4 Ethics approval"]
  N5["44.5 Risk register"]
  N6["Practice note — first milestone"]
  N7["Supervisor cadence"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX130"]

[Learning outcomes]
    |
    v
[44.1 Choosing a scope]
    |
    v
[44.2 Charter]
    |
    v
[44.3 Team roles]
    |
    v
[44.4 Ethics approval]
    |
    v
[44.5 Risk register]
    |
    v
[Practice note — first milestone]
    |
    v
[Supervisor cadence]
    |
    v
[Worked example] --> [Exercise EX130]

Learning outcomes

You will (1) scope a capstone extending Lantern; (2) write a project charter with requirements, risks and milestones; (3) form a team with clear roles; (4) secure ethical approval for any data use.

44.1 Choosing a scope

Capstones should be ambitious but finishable in two semesters. Kofi's team chooses: "An OT vendor-watch service that turns vendor advisories and partner reports into approved, interlocked recommendations for BEN's OT engineers." It touches requirements, data models, controls, integration, validation and safety.

The team weighed two other scopes, a phishing triage tool and a partner quality dashboard, and rejected both as either too narrow or already done well by existing products. Vendor-watch drew on the OT engineers' request recorded during the engineering context work, so it had a real user waiting for it.

44.2 Charter

Problem statement, stakeholders, measurable objectives (for example, vendor-relevant alerts reach the OT queue within 15 minutes with fewer than 10% irrelevant), constraints (standard library prototypes, synthetic data, no OT automation), milestones, risks and a communication plan.

Writing the objective as a number on a defined test set made it possible to say at the end whether the team succeeded. The constraint against OT automation was set by the team itself after the safety discussion, so the service only recommends; it never changes OT systems directly. The charter is two pages and is signed by the supervisor.

44.3 Team roles

Lead engineer, data modeller, controls and safety owner, validation owner. Roles rotate for some tasks so everyone touches the whole system.

Kofi took the lead engineer role and a classmate took controls and safety, which meant she had authority to stop a change that weakened an interlock. Rotation came through paired tasks: the data modeller and the validation owner wrote the acceptance scenarios together, so each understood the other's constraints. Roles are written in the charter, with a named backup for each in case someone is ill near a deadline.

44.4 Ethics approval

The project uses synthetic advisories and synthetic OT asset lists. If any real vendor advisories are used, only public CLEAR documents qualify, and their terms are checked. The approval is filed with the charter.

The approval was quick because the plan contained no personal data and no live systems. The team still recorded a check of the terms of each public advisory site they planned to read. Approval covers the plan as written; any change that would bring in real data needs a new request before the work starts.

44.5 Risk register

Risks: scope creep, unavailable OT reviewer, ambiguous vendor naming, overconfidence in automated relevance scoring. Each has an owner and mitigation.

Kofi's team scored each risk at the start and reviewed the register every two weeks. The unavailable reviewer became real halfway through, when the OT engineer went on leave; the mitigation, a second engineer named in advance, kept the project moving. Ambiguous vendor names were handled with a synonym list built from synthetic advisories. Overconfidence in relevance scoring was checked by having a person rate a sample each week.

Practice note — first milestone

The first milestone is a thin end-to-end slice — one synthetic advisory flowing to one OT ticket — before any component is polished.

Supervisor cadence

The team meets its supervisor every two weeks with a one-page status: progress against milestones, risks that changed and decisions needed. Short, regular check-ins catch scope creep before it costs a semester.

Worked example

The charter's first draft promised "detect all threats to OT". The supervisor rejects it as unverifiable. The revised objective names a measurable relevance rate and timeliness on a defined synthetic test set.

Synthetic case. The team and charter are invented.

Errors and limits

Capstones fail more often from scope than from technology. Real OT data are out of bounds unless formally approved.

Exercises

Synthesis

Scope to finish, charter with measurable aims, assign roles, file ethics approval and build a thin slice first.

Continue studying — chapter 44 of 50

← Chapter 43 (draft) · Course chapter index · Chapter 45 (draft) →