◇ OpenCyber Academy
Technologist · Chapter 27 · English

Chapter 27 — Deployment and validation

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 27 — Deployment and validation

Lesson map

Lesson 27 published. Map, example, EX079.

flowchart TD
  N0["Learning outcomes"]
  N1["27.1 Remaining deployment"]
  N2["27.2 Validating with users"]
  N3["27.3 Requirements in operation"]
  N4["27.4 Temporary arrangements"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX079"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["27.1 Remaining deployment"]
  N2["27.2 Validating with users"]
  N3["27.3 Requirements in operation"]
  N4["27.4 Temporary arrangements"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX079"]

[Learning outcomes]
    |
    v
[27.1 Remaining deployment]
    |
    v
[27.2 Validating with users]
    |
    v
[27.3 Requirements in operation]
    |
    v
[27.4 Temporary arrangements]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX079]

Learning outcomes

You will (1) deploy remaining changes; (2) validate with users; (3) confirm requirements in operation.

27.1 Remaining deployment

In the spring holiday, Gareth and Tomás deploy the remaining changes: student wireless individual accounts, client isolation on student wireless and the VPN for remote staff. They follow the same staged approach: lab rehearsal, change window, tests and rollback plan. The deployment takes two days. One problem appears: some older student laptops cannot use the new wireless authentication method. They are placed on a temporary restricted network until replaced, with an end date agreed. The rollback plan is ready but not needed.

27.2 Validating with users

Validation asks whether the network meets people's real needs, not just the written requirements. Tomás asks a sample of teachers, office staff and students, through a short form, whether anything they need stopped working or became harder. Most report no change; three report issues, including a teacher who cannot reach a shared folder from home, which was missing from the VPN's allowed list. Validation catches needs that requirements missed and builds users' confidence. Every reported issue receives a reply explaining the fix.

27.3 Requirements in operation

Tomás rechecks the requirements under normal school operation rather than test conditions. Logs from a full week show no denied traffic suggesting a broken need, other than the reported folder, now fixed. Drift reports show no unapproved changes. Alerts are reviewed on time. Confirming requirements in operation matters because tests in quiet holidays may miss behaviour that only appears when 1,200 people use the network during lessons. He records the week used and the counts found, so the operational check can be repeated each term with the same method.

27.4 Temporary arrangements

Temporary arrangements, such as the restricted network for old laptops, tend to become permanent if nobody tracks them. Tomás records each with an owner, a reason and an end date in the open items list. Gareth reviews the list monthly. When the old laptops are replaced at the end of the year, the temporary network is removed. Tracking temporary measures is a simple habit that prevents gradual weakening of the design. The list also shows each item's age, making old exceptions stand out.

Worked example

Remaining changes are deployed in two days; user validation finds three issues, all fixed; one temporary network is tracked to removal.

Synthetic case. Deployment is synthetic.

Errors and limits

Temporary exceptions without end dates become permanent weaknesses.

Exercises

Synthesis

Staged deployment, user validation and tracked exceptions confirm the design works in daily use.

Continue studying — chapter 27 of 30

← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →