Chapter 46 — Engineering capstone II
Lesson map
Lesson 46 published. Map, example, EX136.
flowchart TD
N0["Learning outcomes"]
N1["46.1 Building"]
N2["46.2 Testing"]
N3["46.3 Demonstration"]
N4["46.4 Evaluation"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX136"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["46.1 Building"]
N2["46.2 Testing"]
N3["46.3 Demonstration"]
N4["46.4 Evaluation"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX136"]
[Learning outcomes]
|
v
[46.1 Building]
|
v
[46.2 Testing]
|
v
[46.3 Demonstration]
|
v
[46.4 Evaluation]
|
v
[Worked example] --> [Exercise EX136]
Learning outcomes
You will (1) build and test the capstone governance package; (2) demonstrate it; (3) evaluate it against success criteria.
46.1 Building
Kofi builds the package on synthetic data: a pressure data generator with realistic daily cycles, the rule library extended with sensor categories, lineage including complaint analysis, catalogue entries and an alert dashboard. He uses only the Python standard library, as planned, which keeps the code readable for operations engineers. He documents each component with its purpose, owner and test. The build follows the release process from earlier chapters, with code review by a classmate and tests before each merge. Each merge is logged.
46.2 Testing
He injects errors into the synthetic data: stuck sensors, sudden spikes, missing hours and a valve setting changed without a record. The controls detect most errors. Missing hours at one district are detected late, because the completeness check runs daily rather than hourly. He changes the check to hourly for critical sites. A further run detects all injected errors within the agreed times, and he records both runs in the test log with the change between them. The change is approved by the operations engineer.
46.3 Demonstration
Kofi demonstrates the package to an audience of operations staff, an owner and Prof. Varga. He walks through an incident: a stuck sensor at a critical site, the alert, the runbook, the degraded mode procedure and the effect on the leakage estimate. Operations staff ask practical questions about alert volumes and false alarms. He shows alert statistics from the test period. The audience confirms they understood the demonstration and could use the dashboard. They also suggest adding sensor location maps, which Kofi includes afterwards.
46.4 Evaluation
Kofi evaluates the project against success criteria. Owners are named and accepted for all data sets; rules cover safety-relevant thresholds; injected errors were all detected after the hourly change; the operations audience understood the demonstration. He notes limits: synthetic data cannot capture all real behaviour, and long-term operation is untested. Prof. Varga approves the evaluation, praising its honesty about limits alongside clear evidence for each criterion. The evaluation is written as a short report, with each criterion followed by its measure, the result achieved and the evidence that supports it, so that examiners can check every claim.
Worked example
Kofi builds a standard-library governance package for pressure data, finds late detection of missing hours and moves to hourly checks for critical sites, demonstrates an incident walkthrough and evaluates against criteria.
Synthetic case. The package and data are synthetic.
Errors and limits
Demonstrations that hide failures mislead; show the test log.
Exercises
- EX136 — Late detection. What was detected late at first? Rubric: 3 = missing hours at one district;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX137 — Fix for late detection. What fixed it? Rubric: 3 = hourly completeness checks for critical sites;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX138 — Stated limits. Name one limit Kofi stated. Rubric: 3 = synthetic data or untested long-term operation;; 2 = one;; 1 = vague;; 0 = none.
Continue studying — lesson 46 (chapter 46 of 50)
← Chapter 45 · Course chapter index · Chapter 47 →
Continue to the next authored lesson.