Chapter 29 — Capstone build

Lesson map

Lesson 29 published. Map, example, EX085.

flowchart TD
  N0["Learning outcomes"]
  N1["29.1 Defining the capstone"]
  N2["29.2 Building and testing"]
  N3["29.3 Documenting for operators"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX085"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["29.1 Defining the capstone"]
  N2["29.2 Building and testing"]
  N3["29.3 Documenting for operators"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX085"]

[Learning outcomes]
    |
    v
[29.1 Defining the capstone]
    |
    v
[29.2 Building and testing]
    |
    v
[29.3 Documenting for operators]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX085]

Learning outcomes

You will (1) define and build a capstone improvement; (2) test it with seeded data; (3) document it for operators.

29.1 Defining the capstone

Lucas's capstone is a reconciliation service that compares, each hour, credits granted on the ledger with approved workshops, including member identity, and compares credit spending with bookings. It sends alerts for mismatches and produces a monthly summary for the board. Objectives are measurable: detect all seeded mismatches, alert within fifteen minutes, raise no more than one false alarm per week and reduce manual checking time by half. The scope is read-only. Ms Adebayo approves the plan, noting it builds on gaps found in his evaluation.

29.2 Building and testing

Lucas builds the service in Python with the standard library and read-only access. He tests it with synthetic datasets containing seeded problems: a grant without a workshop, a grant to the wrong member, a spend without a booking and a duplicate grant. The service detects all four, alerting within nine minutes. On a clean month it raises one false alarm, caused by a booking cancelled and rebooked within a minute; he adjusts the matching window and the false alarm disappears. Every change is reviewed by a classmate before deployment.

29.3 Documenting for operators

Lucas writes an operator guide: what the service checks, what each alert means, the first steps for each and whom to contact. He adds runbook links and explains how to restart the service and where logs are stored. A volunteer follows the guide in a trial without help. He also writes a maintenance note listing dependencies and their versions. Documentation ensures the capstone continues to be useful after he graduates, which the makerspace board named as its main condition for adopting student work into daily operations.

Worked example

Lucas's read-only reconciliation service detects all four seeded problems within nine minutes and removes a rebooking false alarm by adjusting the matching window.

Synthetic case. The capstone and tests are synthetic.

Errors and limits

A capstone without operator documentation stops being used when its builder leaves.

Exercises

• EX085 — False-alarm limit. What weekly false-alarm limit was set?
  Show marking criteria

  Rubric: 3 = no more than one;; 2 = one;; 1 = ten;; 0 = none.
• EX086 — Seeded detection. How quickly did alerts arrive?
  Show marking criteria

  Rubric: 3 = within nine minutes;; 2 = nine minutes;; 1 = an hour;; 0 = none.
• EX087 — False alarm fix. What caused the false alarm?
  Show marking criteria

  Rubric: 3 = a booking cancelled and rebooked within a minute;; 2 = rebooking;; 1 = a node fault;; 0 = none.

Synthesis

A tested, documented capstone turns coursework into lasting operational value.

Continue studying — chapter 29 of 30

← Chapter 28 (draft) · Course chapter index · Chapter 30 (draft) →