Chapter 44 — Engineering capstone I | Engineering Digital forensics and malware analysis

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 44 — Engineering capstone I

Lesson map

Lesson 44 published. Map, example, EX130.

flowchart TD
  N0["Learning outcomes"]
  N1["44.1 Capstone goal"]
  N2["44.2 Objectives"]
  N3["44.3 Plan"]
  N4["44.4 Risks"]
  N5["44.5 Data collection"]
  N6["44.6 Ethics"]
  N7["44.7 Progress reports"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX130"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["44.1 Capstone goal"]
  N2["44.2 Objectives"]
  N3["44.3 Plan"]
  N4["44.4 Risks"]
  N5["44.5 Data collection"]
  N6["44.6 Ethics"]
  N7["44.7 Progress reports"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX130"]

[Learning outcomes]
    |
    v
[44.1 Capstone goal]
    |
    v
[44.2 Objectives]
    |
    v
[44.3 Plan]
    |
    v
[44.4 Risks]
    |
    v
[44.5 Data collection]
    |
    v
[44.6 Ethics]
    |
    v
[44.7 Progress reports]
    |
    v
[Worked example] --> [Exercise EX130]

Learning outcomes

You will (1) plan the capstone deployment of EvidenceDesk; (2) set measurable objectives; (3) manage scope and risk; (4) report progress.

44.1 Capstone goal

Deploy EvidenceDesk 1.5 for a three-month pilot covering all new intakes at Northfield, and evaluate it against the paper process.

A pilot on all new intakes, rather than a few chosen ones, tests EvidenceDesk under normal variety, including awkward items and busy weeks. Three months is long enough to include routine updates, staff absence and at least one unplanned event. Comparing with the paper process gives a baseline, so results can be judged against the existing way of working rather than in isolation.

44.2 Objectives

O1: 100% of new items registered in EvidenceDesk. O2: 0 examinations started on unverified copies. O3: custody records complete for every item. O4: examiner satisfaction no worse than baseline.

Each objective is measurable from records the pilot will produce. The first three are absolute targets because anything less would mean evidence outside the system or unverified work. The fourth is relative: Priya does not expect enthusiasm, only that the system does not make examiners' work worse. All four are agreed with Northfield's manager before the pilot begins.

44.3 Plan

Weeks 1–2 install and train; 3–14 pilot; 15–16 evaluation. Paper process runs in parallel for the first two weeks as fallback.

Two weeks of installation and training allow for setup problems without eating into the pilot. Running paper in parallel at first means a failure in week one cannot lose records. Evaluation gets its own fortnight so analysis is not squeezed into the last days. Key dates are shared with the lab so case planning can allow for them. Week 8 includes a mid-pilot review with the manager.

44.4 Risks

Staff resistance (mitigation: early involvement); server failure (offline export, restore procedure); scope creep (change control).

For each risk, Priya also names an early warning sign: rising exception counts for staff resistance, failed daily checks for server problems, and requests arriving outside the change log for scope creep. Watching the signs lets her act before a risk becomes an incident. The register is reviewed at each fortnightly report. Each risk also has an owner, usually Priya, though server failure belongs to the IT officer.

44.5 Data collection

System records, exception logs, a short examiner survey at start and end, and comparison with paper records from the prior quarter.

System records show what happened; exception logs show where the system did not fit reality; surveys capture how staff felt; paper records from the prior quarter provide a comparison. Each source answers a different objective. Priya writes the analysis plan for each before the pilot begins, so she cannot pick whichever comparison looks best afterwards. Survey questions stay identical at start and end.

44.6 Ethics

The survey is anonymous and voluntary, approved through the university process; no case content is collected.

Anonymity matters because staff may hesitate to criticise a system their manager has endorsed. Voluntary means nobody is pressed to respond and no record is kept of who did. The approval process checks that the survey questions are necessary and that responses are stored securely, then deleted after the capstone report is assessed. Participants see a short information sheet explaining all of this before answering, and may skip any question.

44.7 Progress reports

Fortnightly one-page reports to Hugo and her supervisor: done, next, risks, decisions needed.

Keeping reports to one page forces Priya to say what matters. 'Decisions needed' is the most useful line for Hugo, because it tells him what he must act on that week. Reports are dated and kept, so the final capstone report can show how the project unfolded rather than reconstructing it from memory. When a risk turns red, the report says so on the first line rather than burying it below routine progress, and it names the decision needed and by when.

44.8 Scope control

A request to add laboratory scheduling is logged and deferred.

Scheduling is a reasonable request, but adding it mid-pilot would change the system being evaluated and stretch Priya's time. Logging it means the idea is not lost; deferring it means the pilot stays comparable from start to finish. The change log records who asked, when and why it was deferred, so the request can be picked up after the capstone. Small bug fixes needed for the pilot still go through change control, but they are approved quickly by Hugo.

Stakeholder communication

Before launch, Priya presents the pilot plan at the lab's staff meeting: what changes for each role, where to get help, and how to raise problems. She circulates a one-page quick guide and names a deputy who can answer questions when she is at university. Examiners are invited to note friction in a shared log, which she reviews every Friday, replying to each entry and recording whether it led to a change. A short weekly summary goes to the lab manager so that leadership sees problems early rather than in the final report.

Worked example

Week 4 report: 61 items registered, 0 unverified examinations, 2 exceptions (server reboot during update — both reconciled). Risk raised: one examiner still uses paper first, then enters records later. Decision needed: whether to allow it during the pilot.

Synthetic case. The pilot data are invented.

Errors and limits

A three-month pilot shows early behaviour; long-term use may differ.

Exercises

EX130 — Objectives. State two measurable pilot objectives. Rubric: 3 = e.g. 100% registered; 0 unverified examinations; 2 = one; 1 = vague; 0 = none.
EX131 — Survey ethics. What makes the survey ethical? Rubric: 3 = anonymous, voluntary, approved, no case content; 2 = partial; 1 = vague; 0 = none.
EX132 — Week 4 risk. What risk did the week 4 report raise? Rubric: 3 = examiner entering paper records later; 2 = partial; 1 = server; 0 = none.

Synthesis

A capstone needs measurable objectives, a fallback, ethical data collection and regular honest reports.

Continue studying — chapter 44 of 50

← Chapter 43 (draft) · Course chapter index · Chapter 45 (draft) →