Skip to main content
← AT CS Study Guide

Unit 9 · Assessed seriously

Computing and Society

The consequences of the systems built in the other nine units. It is assessed with the same rigour as the technical material and rewards specific, traceable reasoning rather than general opinion.

What a strong answer looks like

A strong Unit 9 answer names a specific group, a specific mechanism, and a specific consequence, rather than asserting that a technology is good or bad.

Topics in this unit

1

Algorithmic Bias

Know

A system trained on or built around historical data reproduces the patterns in that data, including its inequities. The bias is in the data and the framing, not in the arithmetic.

Apply

Trace a disparate outcome back to the data or the objective that produced it.

Watch out

Attributing bias to the algorithm as though it were a coding error. It is usually a data and design consequence.

Study move

Take a described system with unequal outcomes and name the specific data property that produced them.

2

Privacy and Data Collection

Know

Collecting data creates obligations. The relevant questions are what is collected, why it is necessary, who can see it, and how long it is kept.

Apply

Apply data minimisation: collect only what the stated purpose requires.

Watch out

Treating anonymisation as absolute. Combining datasets can re-identify individuals.

Study move

List what a school attendance app truly needs to store and what it should not.

3

Accessibility and Inclusion

Know

A system that cannot be used by part of its intended audience has failed for that audience regardless of its technical quality.

Apply

Evaluate against real constraints: screen readers, contrast, input methods, and bandwidth.

Watch out

Treating accessibility as an optional final polish rather than a design constraint.

Study move

Audit an interface you have built against three concrete accessibility criteria.

4

Responsibility and Trade-offs

Know

Engineering decisions distribute benefit and harm unevenly, and the reasoning is what is assessed rather than the conclusion.

Apply

State who benefits, who bears the cost, and what alternative was available.

Watch out

Answering with a general position instead of an argument about the specific system in the question.

Study move

Argue both sides of a deployment decision, then state which you would choose and why.

Emphasized in this unit

Connections and techniques that receive extra attention in this unit.

  • Naming specific groups and mechanisms rather than generalities
  • Applying data minimisation as a default
  • Treating accessibility as a design constraint

Varies by course

Related topics some schools attach to this unit and others leave out. Covered on request rather than assumed.

  • Case studies. The specific examples used differ widely by teacher and by year.
  • Assessment format. Some sections assess this in writing and others through discussion or project reflection.

Mastery checklist

  • Trace a biased outcome to its cause in data or framing.
  • Apply data minimisation to a described system.
  • Evaluate an interface against accessibility criteria.
  • Argue a trade-off naming beneficiaries and costs.

Check yourself

  • Why is algorithmic bias usually a data problem rather than a coding error?
  • What can defeat anonymisation?
  • What makes a societal answer specific rather than general?

Modeling drill

A school proposes an attendance system using facial recognition. Argue the decision, naming who benefits, who bears risk, and one less invasive alternative.

Algorithmic biasData minimisationAnonymisationRe-identificationAccessibilityTrade-off