Chapter 30 — Capstone assessment
Lesson map
Lesson 30 published. Map, example, EX088.
flowchart TD
N0["Learning outcomes"]
N1["30.1 Assessing against objectives"]
N2["30.2 Operator feedback"]
N3["30.3 Presenting results and next steps"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX088"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["30.1 Assessing against objectives"]
N2["30.2 Operator feedback"]
N3["30.3 Presenting results and next steps"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX088"]
[Learning outcomes]
|
v
[30.1 Assessing against objectives]
|
v
[30.2 Operator feedback]
|
v
[30.3 Presenting results and next steps]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX088]
Learning outcomes
You will (1) assess the capstone against objectives; (2) gather operator feedback; (3) present results and next steps.
30.1 Assessing against objectives
Lucas assesses his capstone. It detected all seeded mismatches; alerts arrived within nine minutes against a fifteen-minute target; false alarms averaged 0.5 per week over a month of live use; and manual checking time fell from about two hours to forty minutes a week, a reduction of two thirds. He presents each result with evidence: test logs, alert timestamps and volunteers' time records. Assessing against pre-defined objectives makes his claims checkable, and the assessors can trace each figure to its source in the project folder.
30.2 Operator feedback
Four volunteers who used the service for a month give feedback. They find alerts clear and the monthly summary useful for board meetings. One suggests grouping several small alerts into one message during busy periods. Another asks for a simple page showing the last successful run, so they know the service is working. Lucas implements the status page and plans the grouping as future work. Feedback shows how real operators experience the tool, which matters as much as technical performance when deciding whether a tool will continue to be used.
30.3 Presenting results and next steps
Lucas presents to assessors and the makerspace board with one diagram, four results and one limitation: the service depends on a single node for ledger data. He recommends reading from two nodes and comparing. Assessors ask how he would know if the service itself stopped; he shows the new status page. The board adopts the service permanently. Reflecting on three years, Lucas notes that the most valuable lessons were careful checking, clear documentation and respect for the people who run systems every day.
Worked example
The capstone meets all objectives, cutting manual checking by two thirds with 0.5 false alarms a week, and a status page is added after operator feedback.
Synthetic case. The assessment, feedback and presentation are synthetic.
Errors and limits
A monitoring service with no visible status can fail silently without anyone noticing.
Exercises
- EX088 — Time saving. How much did manual checking fall? Rubric: 3 = from about two hours to forty minutes, two thirds;; 2 = two thirds;; 1 = vague;; 0 = none.
- EX089 — Feedback implemented. Which feedback did Lucas implement? Rubric: 3 = a status page showing the last successful run;; 2 = status page;; 1 = alert grouping;; 0 = none.
- EX090 — Stated limitation. What limitation did Lucas state? Rubric: 3 = dependence on a single node for ledger data;; 2 = single node;; 1 = vague;; 0 = none.
Synthesis
Evidence-based assessment, operator feedback and honest limits complete a technologist's capstone.
Continue studying — chapter 30 of 30
← Chapter 29 (draft) · Course chapter index · Worked results ↓ · Next course via chapter index →