Chapter 29 — Capstone build
Lesson map
Lesson 29 published. Map, example, EX085.
flowchart TD
N0["Learning outcomes"]
N1["29.1 Choosing the build"]
N2["29.2 Building and testing"]
N3["Lab — Suppliers due for re-verification"]
N4["29.3 Documentation"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX085"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["29.1 Choosing the build"]
N2["29.2 Building and testing"]
N3["Lab — Suppliers due for re-verification"]
N4["29.3 Documentation"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX085"]
[Learning outcomes]
|
v
[29.1 Choosing the build]
|
v
[29.2 Building and testing]
|
v
[Lab — Suppliers due for re-verification]
|
v
[29.3 Documentation]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX085]
Learning outcomes
You will (1) build a capstone improvement for the programme; (2) plan and test it; (3) document it for handover.
29.1 Choosing the build
For his capstone, Lucas builds a simple supplier verification tool. Managers use the shared spreadsheet of verified numbers, but it has become messy and sometimes out of date. His tool is a small web form on Brightwell's internal site: managers search for a supplier, see the verified number with the date it was checked and log each callback. The tool also flags numbers not verified in the last year. The aim is to make the callback procedure quicker and more reliable.
29.2 Building and testing
Lucas builds the tool with a small database and a simple interface, using the data model approach from chapter 4. He tests it with synthetic suppliers, checking searches, logging and flags. He then asks three managers to complete tasks using it while he observes. They complete all tasks; one asks for a button to call directly from the screen, which he adds. The lab checks how many suppliers need re-verification based on synthetic dates. Managers also suggest clearer labels for the search box, which he changes before launch.
Lab — Suppliers due for re-verification
# Suppliers due for re-verification (verified more than 365 days ago), synthetic.
from datetime import date
today = date(2026, 10, 12)
ages = [30, 90, 400, 120, 500, 200, 380, 60, 45, 700, 15, 300, 410, 220, 100, 365, 366, 80, 20, 10,
150, 160, 170, 180, 190, 250, 260, 270, 280, 290, 5, 25, 35, 55, 65, 75, 85, 95, 105, 800]
due = [a for a in ages if a > 365]
print(f"suppliers {len(ages)}; due for re-verification {len(due)}")
Run with python3 lab_suppliers.py. Verified output:
suppliers 40; due for re-verification 7
29.3 Documentation
Lucas documents the tool for the practice manager and IT contractor: purpose, how to use it, how to back it up and how to add suppliers. He includes a short troubleshooting section and notes known limits, such as the need for someone to re-verify flagged numbers. He stores the code in Brightwell's repository with comments. Documentation makes the capstone useful after he leaves, which Marta reminds him is the real test of a technologist's work. The contractor reviews the guide and approves it.
Worked example
Lucas builds a supplier verification tool, tests it with managers, adds a call button and documents it for handover.
Synthetic case. The tool and data are synthetic.
Errors and limits
Tools need maintenance. Re-verification needs time.
Exercises
- EX085 — Tool purpose. What is the tool's aim? Rubric: 3 = make callback verification quicker and more reliable;; 2 = callbacks;; 1 = vague;; 0 = none.
- EX086 — Manager request. What did a manager ask for? Rubric: 3 = a button to call directly from the screen;; 2 = call button;; 1 = vague;; 0 = none.
- EX087 — Lab flags. How many of 40 suppliers needed re-verification in the lab? Rubric: 3 = 7 of 40;; 2 = a figure near 7 (5 to 9);; 1 = vague;; 0 = none.
Synthesis
A capstone build solves a real problem, is tested with users and is documented for others.
Continue studying — chapter 29 of 30
← Chapter 28 (draft) · Course chapter index · Chapter 30 (draft) →