Chapter 35 — Capstone proposal

Chapter 35 — Capstone proposal

Lesson map

Lesson 35 published. Map, example, EX103.

flowchart TD
  N0["Learning outcomes"]
  N1["35.1 Choosing the capstone"]
  N2["35.2 Methods and evaluation"]
  N3["35.3 Scope and risk"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX103"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["35.1 Choosing the capstone"]
  N2["35.2 Methods and evaluation"]
  N3["35.3 Scope and risk"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX103"]

[Learning outcomes]
    |
    v
[35.1 Choosing the capstone]
    |
    v
[35.2 Methods and evaluation]
    |
    v
[35.3 Scope and risk]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX103]

Learning outcomes

You will (1) define a capstone problem and objectives; (2) plan methods and evaluation; (3) manage scope and risk.

35.1 Choosing the capstone

For her capstone Sofia proposes to build a monitoring service for the cooperative that checks the voucher ledger against its invariants and the shift database every hour, alerts volunteers to mismatches and privileged actions, and produces a monthly report. The problem is clear: current checks are spread across scripts and manual steps. Objectives are measurable: detect all seeded mismatches in test data, alert within ten minutes, and reduce weekly routine time by a third. Dr Asante approves the proposal, noting that it builds directly on her earlier labs and research.

35.2 Methods and evaluation

Sofia plans to build the service with Python's standard library and read-only access to a validator and the reporting database. She will evaluate it with synthetic datasets containing seeded mismatches, measure detection and alert time, and ask volunteers to rate its usefulness after a month of use. She defines success before starting, so results cannot be reinterpreted later. Evaluation also includes checking false alarms, because a monitor that alerts too often will be ignored. The plan lists each evaluation step with its expected output and the evidence it will produce.

35.3 Scope and risk

Sofia limits scope: the service will only read data and send alerts, never change the ledger or database. Features such as automatic pausing are excluded, because they would require write access and careful governance. She lists project risks: delays in getting test data, volunteer availability for evaluation and her own exam schedule. For each she plans a response, such as preparing synthetic data herself if needed. Clear scope protects both the cooperative and the project timeline, and read-only design means a bug in her service cannot alter any member's balance.

Worked example

Sofia proposes a read-only hourly monitor with targets of detecting all seeded mismatches, alerting within ten minutes and cutting routine time by a third.

Synthetic case. The capstone proposal is synthetic.

Errors and limits

Giving a student monitoring project write access adds risk without adding needed function.

Exercises

• EX103 — Capstone objective. Name one measurable objective. Rubric: 3 = alert within ten minutes;; 2 = detect all seeded mismatches;; 1 = be fast;; 0 = none.
• EX104 — Excluded feature. Which feature is excluded and why? Rubric: 3 = automatic pausing, needing write access;; 2 = auto-pause;; 1 = reporting;; 0 = none.
• EX105 — False alarm concern. Why evaluate false alarms? Rubric: 3 = a monitor that alerts too often is ignored;; 2 = alert fatigue;; 1 = irrelevant;; 0 = none.

Synthesis

Clear objectives, pre-defined evaluation and tight scope make a capstone achievable.

Continue studying — chapter 35 of 40

← Chapter 34 (draft) · Course chapter index · Chapter 36 (draft) →