Chapter 35 — Capstone proposal
Lesson map
Lesson 35 published. Map, example, EX103.
flowchart TD
N0["Learning outcomes"]
N1["35.1 Proposal"]
N2["35.2 Scope"]
N3["35.3 Method"]
N4["35.4 Criteria"]
N5["35.5 Approval"]
N6["Professional responsibilities"]
N7["Raising concerns"]
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 Proposal"]
N2["35.2 Scope"]
N3["35.3 Method"]
N4["35.4 Criteria"]
N5["35.5 Approval"]
N6["Professional responsibilities"]
N7["Raising concerns"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX103"]
[Learning outcomes]
|
v
[35.1 Proposal]
|
v
[35.2 Scope]
|
v
[35.3 Method]
|
v
[35.4 Criteria]
|
v
[35.5 Approval]
|
v
[Professional responsibilities]
|
v
[Raising concerns]
|
v
[Worked example] --> [Exercise EX103]
Learning outcomes
You will (1) propose a capstone; (2) define scope, method and success criteria.
35.1 Proposal
A sustainable endpoint security programme for Bramley.
Sustainable means the programme continues after Aisha leaves, run by Gareth and a trained colleague within his normal week. The proposal covers inventory, a five-setting baseline, encryption, patching, server services, logon review and recovery testing. Each element has an owner, a routine step and a report that shows whether it is working. The proposal's success depends on the routine fitting into about one hour of Gareth's week after handover. Gareth's assistant is named as cover for the routine in the proposal.
35.2 Scope
Laptops and servers; excludes phones and website.
The scope matches the scope statement from chapter 19: Bramley's 45 laptops and four servers. Phones, the website and suppliers' systems are named as out of scope, so nobody assumes they are covered. Requests that fall outside the scope, such as phone management, are recorded as future work rather than added mid-project. Keeping the scope fixed also keeps the evaluation fair, because the final figures cover the same devices as the baseline. Phone management becomes the top follow-up recommendation at the end.
35.3 Method
Baseline, implement, verify, measure, hand over.
Each of these five stages has already been tried on a smaller scale in earlier chapters. The baseline uses the five evidence files from chapter 15; implementation follows the staged groups from chapter 24; verification repeats the encryption and services labs; measurement reruns the baseline method; and handover passes the routine, labs and role documents to Gareth. Writing the stages in this order means each result can be traced to a step. Each stage's output is listed in the proposal, so Dr Grant can check progress against named documents and lab runs.
35.4 Criteria
100% encrypted; 90% patched within 14 days; zero unneeded services; unmanaged devices at most one.
Each criterion is tied to a baseline figure: 32 of 45 encrypted, 26 of 45 within 14 days, four unneeded services and six unmanaged devices. 90% of 45 is 40.5, so at least 41 laptops must be patched within 14 days to meet the patching target. Writing the criteria before implementation means the evaluation cannot move the target to match the result. Unknown devices count as failing for every criterion, so missing reports cannot help the project meet its targets.
35.5 Approval
Dr Grant and Bramley approve.
Dr Grant approves the method and the criteria for the university. Bramley's manager signs the proposal, which states what data are used, who sees them, how long they are kept and how staff are informed. The signed proposal gives Aisha written permission for the work, in addition to the original agreement signed by the chief executive. Any change to scope or criteria after approval needs both signatures again, which keeps the targets from moving quietly.
Professional responsibilities
IT staff have privileged access, which brings duties: use access only for work, respect privacy, report problems honestly and keep skills current. Professional codes, such as those of the BCS and ACM, express these duties. Aisha discusses them with Gareth, who notes that small organisations rarely write them down but rely on them heavily.
In the project, these duties show up in concrete choices. Logon records are reviewed only for security. Survey data are anonymous. The stolen laptop incident is reported to the regulator as required, and the report is honest about what was not in place.
Aisha also considers her own role as a student: she has access only to synthetic copies and summary reports, not tenant records, which Bramley's manager confirms in writing.
Raising concerns
If Aisha had found something serious, such as an ongoing breach, the agreed route was to tell Gareth and the manager immediately, not to investigate alone.
Learning
She lists courses Gareth could take to keep skills current, within budget.
Accountability
Every privileged action in the project is traceable to a named account and a recorded reason. This protects staff as well as tenants, because it shows that access was used properly.
Project log entry
The capstone proposal itself is reviewed for ethics: it states what data are used, who sees them, how long they are kept and how staff are informed. Bramley's manager signs the proposal, giving Aisha clear written permission for the work she will do.
Worked example
Gareth asks whether 90% is ambitious. Aisha shows the current 73% after reminders and argues 90% is achievable with forced restarts.
Synthetic case. Synthetic.
Errors and limits
Criteria without a baseline are guesses.
Exercises
- EX103 — Criteria. State the success criteria. Rubric: 3 = 100% enc, 90% patched, 0 services, ≤1 unmanaged; 2 = three; 1 = two; 0 = none.
- EX104 — Method. Give the method steps. Rubric: 3 = baseline, implement, verify, measure, handover; 2 = four; 1 = two; 0 = none.
- EX105 — 90% case. Why is 90% achievable? Rubric: 3 = 73% now plus forced restarts; 2 = partial; 1 = vague; 0 = none.
Synthesis
Base criteria on measured baselines.
Continue studying — chapter 35 of 40
← Chapter 34 (draft) · Course chapter index · Chapter 36 (draft) →