Chapter 35 — Capstone proposal
Lesson map
Lesson 35 published. Map, example, EX103.
flowchart TD
N0["Learning outcomes"]
N1["35.1 The need"]
N2["35.2 Objectives"]
N3["35.3 Success criteria"]
N4["35.4 Method"]
N5["35.5 Risks"]
N6["35.6 Approval"]
N7["Timeline"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX103"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["35.1 The need"]
N2["35.2 Objectives"]
N3["35.3 Success criteria"]
N4["35.4 Method"]
N5["35.5 Risks"]
N6["35.6 Approval"]
N7["Timeline"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX103"]
[Learning outcomes]
|
v
[35.1 The need]
|
v
[35.2 Objectives]
|
v
[35.3 Success criteria]
|
v
[35.4 Method]
|
v
[35.5 Risks]
|
v
[35.6 Approval]
|
v
[Timeline]
|
v
[Worked example] --> [Exercise EX103]
Learning outcomes
You will (1) propose a capstone that addresses a real need; (2) set objectives and success criteria; (3) plan method, timeline and risks; (4) obtain approval.
35.1 The need
Several student projects at Hollowbrook share the same problems CampusEats faced. Lena proposes a "secure project starter": a template repository with secret scanning, lockfile hash checks, SBOM generation, signing and provenance, update bot configuration and ASVS-based tests.
Each part of the template is something CampusEats already uses and has measured, so the starter packages tested practice rather than new ideas. Lena checks with Grace's office that no similar template already exists. The proposal names the projects that have asked for help with supply-chain problems, so the need is shown with evidence.
35.2 Objectives
Make it easy for new projects to start with good supply-chain hygiene; measure adoption and effect.
The first objective is about ease, because projects adopt what is simple to set up. The second makes the proposal testable: it is not enough to publish the template; Lena must show whether projects use it and whether it reduces problems such as leaked secrets. Each objective links to a success criterion, so the evaluation at the end can be clear. Both are agreed with Grace.
35.3 Success criteria
At least four projects adopt it in a term; zero secrets reach public repositories in adopting projects; setup takes under one hour.
Each criterion can be checked with data already available: adoption from the template's usage records, secrets from server-side scanning and setup time from a timed trial with new members. The thresholds are modest so that success is achievable in one term, and Lena records what she would conclude if a criterion is narrowly missed. These were agreed before the pilot.
35.4 Method
Build the template, pilot with two projects, improve, then offer to all.
The two pilot projects are chosen to differ, one web app and one data project, so the template is tested in more than one setting. Lena times each setup, records every problem the pilot teams hit and fixes the template before the wider offer. Changes are tracked in the template's repository, so the final version can be compared with the first and each improvement linked to the pilot problem that caused it.
35.5 Risks
Low adoption (mitigate with a workshop); maintenance burden (Grace's office agrees to own it after Lena graduates).
Other risks include the template becoming out of date and projects copying it without understanding its checks. Lena plans quarterly updates and a short guide explaining each check. Each risk has an owner and a mitigation, and the plan is reviewed at the midpoint of the project. A further risk is that the template's checks slow builds enough to annoy members, so Lena includes build time in the pilot measures and sets a limit.
35.6 Approval
Grace and Lena's supervisor sign off.
The sign-off records the objectives, success criteria and scope, and it names Grace's office as the future owner. Any later change to the plan is noted in a dated addendum that both sign. With approval in place, Lena begins the pilot, knowing exactly what she will be evaluated against at the end of the year. Copies are kept with the template's repository and in the university's project records, so the plan can be found by later members.
Timeline
The plan runs over two terms: four weeks to build the template, four weeks piloting with two projects, two weeks improving it, and the rest of the year for rollout and measurement. Each phase ends with a short review with Grace. The timeline includes slack for exams, when volunteer time drops sharply, which earlier society projects had forgotten.
Measuring adoption
Adoption is measured by counting projects created from the template and checking that their CI checks are active, not just present. Lena plans a short survey after one term to learn what projects found hard, so the template can improve. She also plans to compare secrets found in adopting and non-adopting projects, while noting the groups may differ in other ways.
Worked example
The proposal review asks how the template stays current. Lena adds a monthly automated job that updates the template's own dependencies and checks it still passes.
Synthetic case. The proposal is synthetic.
Errors and limits
Templates help new projects; existing projects need a migration guide.
Exercises
- EX103 — Template contents. List four features of the starter template. Rubric: 3 = secret scanning, hash checks, SBOM, signing/provenance, update bot, ASVS tests (four); 2 = two; 1 = one; 0 = none.
- EX104 — Success criteria. Give the success criteria. Rubric: 3 = ≥4 projects; zero secrets; setup <1 h; 2 = two; 1 = one; 0 = none.
- EX105 — Staying current. How will the template stay current? Rubric: 3 = monthly automated update job; 2 = partial; 1 = vague; 0 = none.
Synthesis
A capstone proposal names a real need, measurable success and an owner after you leave.
Continue studying — chapter 35 of 40
← Chapter 34 (draft) · Course chapter index · Chapter 36 (draft) →