Chapter 44 — Engineering capstone I
Lesson map
Lesson 44 published. Map, example, EX130.
flowchart TD
N0["Learning outcomes"]
N1["44.1 Choosing the project"]
N2["44.2 Evidence for the need"]
N3["44.3 Scope"]
N4["44.4 Requirements"]
N5["44.5 Plan"]
N6["44.6 Verification and validation plan"]
N7["44.7 Risks"]
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 the project"]
N2["44.2 Evidence for the need"]
N3["44.3 Scope"]
N4["44.4 Requirements"]
N5["44.5 Plan"]
N6["44.6 Verification and validation plan"]
N7["44.7 Risks"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX130"]
[Learning outcomes]
|
v
[44.1 Choosing the project]
|
v
[44.2 Evidence for the need]
|
v
[44.3 Scope]
|
v
[44.4 Requirements]
|
v
[44.5 Plan]
|
v
[44.6 Verification and validation plan]
|
v
[44.7 Risks]
|
v
[Worked example] --> [Exercise EX130]
Learning outcomes
You will (1) define a capstone project with scope, requirements and plan; (2) justify the project from evidence; (3) plan verification and validation; (4) manage risks and stakeholders.
44.1 Choosing the project
Amara's capstone closes the depot gap found in validation: "Detect remote logons from depot networks to domain controllers within 15 minutes, with no more than 5 false alerts per week."
Choosing a gap found by validation means the capstone addresses a real, evidenced weakness rather than a topic picked for interest alone. The requirement states the behaviour, the time limit and the acceptable noise, so success can be measured objectively at the end. Her tutor and Paolo approve the choice before work begins.
44.2 Evidence for the need
Two simulated techniques left no trace in depot networks (chapter 38); the threat analysis ranks depot-to-domain-controller movement high (chapter 23).
Two sources point to the same gap: simulations showed the SOC was blind there, and the threat analysis ranked the risk highly. Together they justify the effort. A capstone resting on a single weak signal would be harder to defend to the panel. Amara cites both in the capstone proposal, quoting the exact simulation outcomes and the risk ranking, so assessors can trace the motivation to evidence rather than to her own preference.
44.3 Scope
In: allowed-connection logging at the depot boundary for domain-controller ports; enrichment; one detection; playbook. Out: agents on depot devices; changes to depot applications.
Stating what is out matters as much as what is in. Agents on depot devices are excluded because the old software cannot host them; application changes are excluded because they belong to other teams. A tight scope makes twelve weeks realistic and keeps the project focused on the logging and detection that close the gap. Any request to widen the scope goes through the change log.
44.4 Requirements
Functional: log allowed depot-to-DC connections; alert on interactive logons from depot devices not on the approved list. Non-functional: 15-minute latency; completeness 99.9%; ≤5 false alerts per week.
Each requirement can be tested: logs either arrive or not, alerts either fire for unapproved devices or not, times and rates can be measured. The approved list is the key design element, since it decides which logons count as suspicious, and it needs an owner to keep it current. Each requirement has an identifier and appears in a traceability table, linked to its source and its planned test.
44.5 Plan
Weeks 1–3 design and review; 4–6 build in test; 7–8 pilot at three depots; 9–10 rollout; 11–12 verification, validation and report.
Three weeks of design and review give time to catch problems before building. Building in the test environment avoids disrupting depots. A three-depot pilot tests real conditions on a small scale. Two weeks of rollout and two of evaluation complete the cycle, with the report at the end. Fortnightly reviews with Paolo check progress against these dates. If the pilot slips by more than a week, rollout is shortened rather than evaluation, because evaluation produces the evidence the capstone depends on.
44.6 Verification and validation plan
Unit tests for logic, pipeline tests, timed synthetic logons, and a purple-team re-test of the two missed techniques.
Unit and pipeline tests verify the build; timed synthetic logons verify the latency requirement. Re-testing the two missed techniques with the purple team validates that the gap is actually closed, which is the point of the project. Each test has expected results written before it runs, so outcomes are judged against criteria rather than impressions. The purple-team re-test uses the same technique descriptions as the original validation, making the before-and-after comparison fair.
44.7 Risks
Log volume could exceed estimates; depot changes could disrupt dispatch. Mitigations: volume estimate from a one-day capture; pilots and change windows.
A one-day capture gives a real measurement of log volume before committing to the design, rather than relying on guesses. Pilots and change windows reduce the chance of disrupting dispatch. Each risk has an owner and a trigger for action if it begins to materialise. The risk list is reviewed at each fortnightly meeting with Paolo. New risks are added as they appear.
Stakeholder map
Amara maps stakeholders for the capstone: depot managers (dispatch continuity), IT operations (firewall load), the SOC (alert quality) and the privacy officer (connection metadata). Each gets a named contact and a planned update at the end of each phase, so nobody is surprised when changes reach their area.
Worked example
The capstone proposal is reviewed by Paolo, her tutor and the IT operations lead. The operations lead adds a requirement: logging changes must not add more than 2% CPU on boundary firewalls. Amara adds it with a measurement method.
Synthetic case. The project is invented.
Errors and limits
Capstone scope must fit the time available; resist adding features.
Exercises
- EX130 — Capstone requirement. State the capstone's headline requirement. Rubric: 3 = detect depot-to-DC remote logons within 15 min, ≤5 false/week; 2 = partial; 1 = vague; 0 = none.
- EX131 — Scope boundaries. What is out of scope, and why does that matter? Rubric: 3 = agents on depot devices, app changes; keeps project feasible; 2 = partial; 1 = vague; 0 = none.
- EX132 — Added requirement. What did the operations lead add? Rubric: 3 = ≤2% firewall CPU, with measurement; 2 = partial; 1 = vague; 0 = none.
Synthesis
A capstone is justified by evidence, bounded in scope, planned with verification and shaped by stakeholders.
Continue studying — chapter 44 of 50
← Chapter 43 (draft) · Course chapter index · Chapter 45 (draft) →