Chapter 35 — Design studio II | Engineering Systems, endpoints and hardware security

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

Lesson map

Lesson 35 published. Map, example, EX103.

flowchart TD
  N0["Learning outcomes"]
  N1["35.1 Presentation"]
  N2["35.2 Critique"]
  N3["35.3 Responses"]
  N4["35.4 Improvements"]
  N5["35.5 Prioritising"]
  N6["Turning critique into a plan"]
  N7["Demonstration"]
  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 Presentation"]
  N2["35.2 Critique"]
  N3["35.3 Responses"]
  N4["35.4 Improvements"]
  N5["35.5 Prioritising"]
  N6["Turning critique into a plan"]
  N7["Demonstration"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX103"]

[Learning outcomes]
    |
    v
[35.1 Presentation]
    |
    v
[35.2 Critique]
    |
    v
[35.3 Responses]
    |
    v
[35.4 Improvements]
    |
    v
[35.5 Prioritising]
    |
    v
[Turning critique into a plan]
    |
    v
[Demonstration]
    |
    v
[Worked example] --> [Exercise EX103]

Learning outcomes

You will (1) present the integrated design; (2) respond to expert critique; (3) prioritise improvements.

35.1 Presentation

Mateo presents the design with measurements: restore times, availability and allowlist results.

This time the presentation leads with evidence rather than plans. Restore times show the nightly design fits the window. The availability estimate shows the benefit in downtime. The allowlist results show the control working and the accessibility fix. Guests can question the numbers directly, which makes the critique sharper than in the first studio, where most discussion was about intentions. Mateo brought the raw data in case guests wanted to check a figure.

35.2 Critique

A guest from another library asks about cost of maintaining the allowlist. Another asks about patrons who need software not on the list.

Both questions came from people who maintain public computers themselves. The first concerns sustainability: a control that needs more staff time than Fernhill has will decay. The second concerns fairness and service: patrons sometimes need a program for a course or a job application that nobody anticipated. Mateo recorded the questions word for word, as he had in the first studio.

35.3 Responses

Maintenance takes about an hour a week; a request form lets librarians propose additions, reviewed weekly.

The hour a week comes from Mateo's own records during the pilot, so it is measured rather than guessed. The request form asks what the program is for and who publishes it, which is enough for Marta to judge whether it can be signed in safely. Most requests are answered within a week. Patrons who need a program urgently are directed to staff PCs where a librarian can help.

35.4 Improvements

Add a dashboard for librarians; automate weekly reimage reports.

The dashboard would let librarians see at a glance which PCs are ready and which are out of service, without calling IT. Automating the weekly reimage report would save Marta's team the time spent collecting results by hand. Both ideas came from the critique, and both serve the fourth objective of reducing manual effort. Guests also suggested a printed weekly summary for branch managers, which Mateo listed as a lower priority because the dashboard could provide the same figures.

35.5 Prioritising

Dashboard first, because librarians are the daily users.

Librarians deal with PC problems first and most often, so a tool that helps them pays back daily. The reimage report helps Marta's small team, which matters too, but less urgently. Mateo estimated the effort for each and found the dashboard could reuse the tables already built for restore results, keeping the work small. The order was agreed with Marta and Dr Novak and recorded with the critique table. Work starts the following week.

Turning critique into a plan

Mateo lists studio comments in a table with response and priority. Dashboard for librarians: high, because it reduces calls to IT. Automated reimage reports: medium. Read-only USB: rejected with reasons. Thin clients: future. The table goes to Marta and Dr Novak, who agree the order.

He sends the table to the studio guests, closing the loop.

Demonstration

The studio includes a live demonstration of a session being restored overnight, using a lab PC and a recorded timelapse.

Peer learning

Mateo also learns from peers' designs, borrowing the idea of a simple status page.

Studio outcome

The design is approved for deployment.

Feedback record

Comments and responses are stored.

Dashboard design

The dashboard shows, per branch, PCs ready, out of service and blocked programs this week, with simple colours and text labels. Librarians test a mock-up and ask for a clear 'call IT' button, which is added.

Prioritising time

Mateo estimates hours for each improvement.

Work begins on the dashboard.

Timing

Work starts next week.

Worked example

A peer questions read-only USB again. Mateo presents his evaluation: the scenario ranking shows USB malware at 12, so he keeps USB storage blocked and offers email and cloud saving.

Synthetic case. Synthetic.

Errors and limits

Improvements without priority compete for limited time.

Exercises

EX103 — Maintenance. How much time does allowlist maintenance take?
Show marking criteria
Rubric: 3 = about an hour a week; 2 = partial; 1 = vague; 0 = none.
EX104 — Requests. How can librarians request software?
Show marking criteria
Rubric: 3 = form reviewed weekly; 2 = partial; 1 = vague; 0 = none.
EX105 — USB decision. Why keep USB storage blocked?
Show marking criteria
Rubric: 3 = malware scenario 12; alternatives offered; 2 = partial; 1 = vague; 0 = none.

Synthesis

Present evidence and prioritise improvements for users.

Continue studying — chapter 35 of 50

← Chapter 34 (draft) · Course chapter index · Chapter 36 (draft) →

Chapter 35 — Design studio II