Chapter 44 — Engineering capstone I
Lesson map
Lesson 44 published. Map, example, EX130.
flowchart TD
N0["Learning outcomes"]
N1["44.1 Project choice"]
N2["44.2 Scope"]
N3["44.3 Risks"]
N4["44.4 Success criteria"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX130"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["44.1 Project choice"]
N2["44.2 Scope"]
N3["44.3 Risks"]
N4["44.4 Success criteria"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX130"]
[Learning outcomes]
|
v
[44.1 Project choice]
|
v
[44.2 Scope]
|
v
[44.3 Risks]
|
v
[44.4 Success criteria]
|
v
[Worked example] --> [Exercise EX130]
Learning outcomes
You will (1) define a capstone project on governed data; (2) plan scope, risks and evidence; (3) agree success criteria.
44.1 Project choice
Kofi's capstone project is to design and demonstrate a governance package for the pressure management programme, which adjusts valves to reduce leakage. Pressure data affect safety and leakage, so the project combines lessons from the whole course. He chooses it because the programme is expanding and its data currently lack owners, rules and lineage. The capstone must produce a working demonstration on synthetic data, documentation and evidence that controls work. The operations director supports the choice and agrees to provide an engineer as a contact, which makes the project relevant to Tidewater.
44.2 Scope
Kofi limits scope to pressure sensor data, valve settings and the link from pressure changes to leakage estimates in three synthetic districts. He excludes the control logic of the valves themselves, which belongs to operations engineers. Clear scope prevents the project from growing beyond what one student can deliver in a term. He lists deliverables: lineage, owner map, rule catalogue, control tests, a dashboard sketch and a decision record for each major choice. The scope statement is signed by Prof. Varga and the operations engineer.
44.3 Risks
He identifies project risks: synthetic data that do not reflect real pressure behaviour, limited access to operations engineers and time lost to tool problems. For each risk he plans a response, such as validating synthetic patterns with an operations engineer early and keeping the code simple using only the standard library. He reviews risks weekly. Prof. Varga reminds him that project risk management is a professional skill in its own right, separate from the technical content. The risk log is kept with the project files.
44.4 Success criteria
Kofi agrees success criteria with Prof. Varga and an operations engineer: owners named and accepted for all data sets in scope, rules covering safety-relevant thresholds, injected errors detected at an agreed rate and a demonstration understood by an operations audience. Each criterion has a measure. He notes that agreeing criteria at the start prevents disputes later about whether the project succeeded and focuses effort on what matters to the people who will use the results. The criteria are written into the project plan and cannot be changed without agreement.
Worked example
Kofi chooses governance for pressure management, scopes it to sensors, valve settings and three districts, plans risks with early validation and agrees measurable success criteria.
Synthetic case. The project is synthetic.
Errors and limits
Unclear scope is the most common capstone failure; write it down.
Exercises
- EX130 — Excluded area. What did Kofi exclude from scope? Rubric: 3 = valve control logic;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX131 — Synthetic risk response. How will Kofi check synthetic pressure data? Rubric: 3 = validate patterns with an operations engineer early;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX132 — Audience criterion. Who must understand the demonstration? Rubric: 3 = an operations audience;; 2 = partly correct;; 1 = other;; 0 = none.
Continue studying — lesson 44 (chapter 44 of 50)
← Chapter 43 · Course chapter index · Chapter 45 →
Continue to the next authored lesson.