Chapter 44 — Engineering capstone I
Lesson map
Lesson 44 published. Map, example, EX130.
flowchart TD
N0["Learning outcomes"]
N1["44.1 Scope"]
N2["44.2 Evaluation plan"]
N3["44.3 Criteria"]
N4["44.4 Risks"]
N5["Linking criteria to requirements"]
N6["Baseline for comparison"]
N7["Schedule and checkpoints"]
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 Scope"]
N2["44.2 Evaluation plan"]
N3["44.3 Criteria"]
N4["44.4 Risks"]
N5["Linking criteria to requirements"]
N6["Baseline for comparison"]
N7["Schedule and checkpoints"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX130"]
[Learning outcomes]
|
v
[44.1 Scope]
|
v
[44.2 Evaluation plan]
|
v
[44.3 Criteria]
|
v
[44.4 Risks]
|
v
[Linking criteria to requirements]
|
v
[Baseline for comparison]
|
v
[Schedule and checkpoints]
|
v
[Worked example] --> [Exercise EX130]
Learning outcomes
You will (1) define the capstone scope; (2) plan evaluation; (3) set success criteria.
44.1 Scope
The capstone covers the whole segmentation and VPN project across all eight offices: the zone model, office firewalls, IKEv2 tunnels with certificates, central logging, monitoring and the operational processes that keep them working. It excludes endpoint protection and application security, which belong to other council teams, though Kofi notes where they interact, such as host firewalls on servers. Stating scope clearly protects the evaluation from being judged on things the project never aimed to change, and stops the project from quietly expanding beyond what can be finished and measured.
44.2 Evaluation plan
Kofi chooses six measures: reachable zone pairs, unexpected denies per week, VPN availability, latency added by the firewalls, change failure rate and requirement coverage. For each, the plan states how it is measured, from which data, over what period and by whom. Reachable pairs come from the policy model; denies and availability from central logs; latency from lab and live measurements; change failures from the change log; coverage from the traceability table. Defining measurement in advance stops later arguments about which numbers count.
44.3 Criteria
Measures need targets that define success. Kofi sets four criteria: guest isolation verified by both lab and production tests; every requirement supported by passing evidence; VPN availability above 99.9 percent over the measurement period; and added latency within the one-millisecond budget. Each criterion is clear enough that two people would agree whether it was met. The criteria are agreed with Dr Vasquez and the council before results are collected, which prevents the temptation to adjust targets after seeing the numbers.
If VPN availability came in at 99.8 percent, for example, that criterion would be reported as not met rather than reframed.
44.4 Risks
Kofi lists the risks to completing the capstone. Procurement delays could postpone second links and shorten the availability measurement. Staff availability matters because migrations need council engineers present. A serious incident elsewhere in the council could pull the team away for weeks. Each risk has a likelihood, an impact and a response: links are ordered early, migrations are scheduled around known leave, and the plan identifies which measures could still be reported if time runs short. Managing project risk is part of engineering, not separate from it.
Linking criteria to requirements
Each success criterion traces back to one or more requirements and to the original problem. Guest isolation verified addresses R1 and the guest malware incident that started the project. All requirements evidenced covers R1 to R8 through the traceability table. Availability above 99.9 percent relates to R6 and to the council's need for reliable access to central services. Latency within budget protects the phone system. Writing these links explicitly prevents the capstone from drifting into measuring things that are easy to count but unrelated to what the council actually needed, and makes it clear to examiners why each measure matters.
Baseline for comparison
A result only has meaning against a baseline. Kofi uses the measurements gathered before any change, documented in the early chapters: thirty reachable zone pairs on the flat network, no logging of internal traffic, a single VPN path per office and no record of changes. Where a baseline value was not measured, such as availability under the old design, he estimates it from service desk records and states it as an estimate. He resists the temptation to compare against an imagined worst case, which would make improvements look larger than they are. A fair baseline makes the capstone results credible.
Schedule and checkpoints
The capstone runs over two academic terms. Kofi sets checkpoints every four weeks: migrations complete, monitoring baselines stable, failover trials done, measurements collected and analysis written. At each checkpoint, he and Dr Vasquez review progress against the plan and decide whether to adjust scope. One planned extra, an evaluation of a newer wireless authentication method, is deferred at the second checkpoint because procurement for the second links has slipped. Recording these decisions shows that scope was managed deliberately rather than abandoned, and keeps the core evaluation on schedule with sufficient time left for writing.
Worked example
The capstone plan is approved by Dr Vasquez and the council.
Synthetic case. The plan is synthetic.
Errors and limits
Changing criteria after results undermines credibility.
Exercises
- EX130 — Criteria list. List four success criteria. Rubric: 3 = four;; 2 = three;; 1 = fewer;; 0 = none.
- EX131 — Criteria timing. Why fix criteria early? Rubric: 3 = avoid moving goalposts;; 2 = credibility;; 1 = vague;; 0 = none.
- EX132 — Capstone risk. Name one capstone risk. Rubric: 3 = procurement delay;; 2 = risk;; 1 = vague;; 0 = none.
Synthesis
Clear criteria frame the capstone evaluation.
Continue studying — chapter 44 of 50
← Chapter 43 (draft) · Course chapter index · Chapter 45 (draft) →