Year 11 · 120 minutes · Deployment
What is the best system when quality is only one constraint?
Deployment design combines model quality with capacity, latency, privacy and cost. This simulation routes synthetic requests between local and hosted queues using explicitly supplied scenario coefficients. It calculates queue completion times, budget use and exposed data categories. These are modelled outcomes, not hardware benchmarks, vendor prices or measured quality. The exercise is to defend choices under constraints and test sensitivity to assumptions.
Plan two 60-minute sessions. Read the supplied fictional local/hosted coefficients and request sensitivity labels. State a school data boundary and budget before optimisation. Make clear that hardware names denote extension targets, not measured browser simulation performance.
Interpret latency distributions and compare cost and quality trade-offs. Useful earlier investigations: y7-errors, y9-calibration Use pairs for investigation, with operator/reviewer swaps after each comparison. Keep individual predictions, journals and a short oral defence so group work does not hide understanding.
Queensland Digital Solutions 2025 v1.4: Unit 3 · objective 3, Unit 3 · objective 4, Unit 3 · objective 7. Selected aspects only. This activity contributes evidence; it does not cover the full descriptor or achievement standard. A programming descriptor is not claimed for merely moving controls. ACARA AI curriculum connection · V9 Technologies These are planning connections, not ACARA endorsement or exhaustive descriptor alignment.
Teams rank functional requirements and distinguish hard privacy boundaries from preferences.
Ask: “Can a cheaper option compensate for a prohibited data transfer?”
Listen for: “No, a hard boundary rules it out.”
Predict queue delay when arrival rate approaches local capacity.
Ask: “Why might per-request compute time understate user wait?”
Listen for: “Requests can wait behind others.”
Allocate local and hosted capacity and routing proportion. Inspect the queue timeline, cost and quality coefficients. Hold requests fixed during comparisons.
Ask: “Which result is calculated from assumptions rather than measured?”
Listen for: “All displayed deployment outcomes in this simulation.”
Introduce a sensitive request during local overload; inspect why capacity pressure must not silently send it externally.
Ask: “Which constraint takes precedence?”
Listen for: “The stated data boundary; the request may need to wait or fail safely.”
In session two, choose a policy, test low and peak loads, vary one uncertain coefficient and draft a fallback procedure. Record queue delay, cost and unmet requirements.
Ask: “Does the policy remain acceptable when your optimistic assumption changes?”
Listen for: “We need a sensitivity test to know.”
Present routing, assumptions, required real benchmarks and accountable owner.
Ask: “What must be measured before a real launch?”
Listen for: “Actual latency, quality, failure behaviour, data handling and costs.”
The biggest model is always the best system.
Increase arrival rate with compute capacity fixed. Predict how waiting time changes before viewing the queue.
A sensitive request cannot be routed to an otherwise fast hosted service when policy forbids that data transfer; the system needs a safe overload outcome.
Create a policy satisfying the data boundary, evaluate peak load and document any budget or latency failures with a fallback.
Require labels distinguishing simulated coefficients from real measurements. Check the overload policy preserves privacy and communicates failure.
Start with two queues, one request type and a fixed budget; introduce sensitivity labels after learners can trace completion times.
Compare queue policies such as first-come-first-served and prioritised short requests, including who bears increased waiting time.
A deployment decision brief with routing diagram, scenario results, fallback and benchmark plan.
All requests, quality values and costs are synthetic. No cloud service is contacted and no procurement claim should be inferred. Senior syllabus mapping must be verified locally.
Run a real device matrix workload and a vectorised FIFO queue sensitivity study. Change arrival spacing and compare scenario service times and latency; measured execution time is reported separately from simulated service latency.
| Criterion | Beginning | Secure | Extending |
|---|---|---|---|
| Constraint analysis | Optimises quality alone | Separates hard constraints and preferences | Tests conflicts and overload explicitly |
| Deployment evidence | Treats scenario values as benchmarks | Reports calculated outcomes and assumptions | Performs sensitivity tests and specifies real validation work |
Queensland Digital Solutions 2025 v1.4
References: Unit 3 · objective 3, Unit 3 · objective 4, Unit 3 · objective 7. Read the current source (checked 2026-09-07).
Evidence to assess: Workload and requirements analysis; justified comparison of candidate implementations.
Selected aspects only. This activity contributes evidence; it does not cover the full descriptor or achievement standard. A programming descriptor is not claimed for merely moving controls. A supporting classroom task, not a QCAA-approved assessment instrument. Teachers must set their own assessment conditions and confirm alignment with their course. Other jurisdictions require local mapping.
These are planning estimates to test with your class. A short session develops one supported claim; it does not compress the whole senior project.
| Stage | 45 minute focus | 60 minute investigation |
|---|---|---|
| Readiness and prediction | 0–5 | 0–5 |
| Trace the supplied example | 5–13 | 5–15 |
| Author and run cases | 13–25 | 15–35 |
| Counterexample and redesign | 25–35 | 35–45 |
| Explain and discuss | 35–42 | 45–55 |
| Export and handover | 42–45 | 55–60 |
For a longer project, use three 50-minute sessions. Session 1 (0–50): readiness, model, hypothesis and initial cases. Export a project and record the next test. Session 2 (50–100): reopen, check settings, author counterexamples and revise the design. Export the changed project and identify unresolved evidence. Session 3 (100–150): independent peer test, final artefact, individual explanation and moderation. If using two 60-minute sessions, stop at minute 60 after saving the first comparison; use 60–120 for redesign, independent test and defence.
Entry check: Interpret latency distributions and compare cost and quality trade-offs. Ask the learner to demonstrate it before choosing the level of support.
Preparation: allow about 25 minutes to run the starter, print the cards and check a project can be reopened. This estimate has not yet been measured in a classroom pilot.
Read the entry question aloud, model one row, and label the units. Offer the case table as a large-print sheet. Keep mathematical derivations optional until the learner can explain the comparison.
For one device, use a projector: one pair predicts, one operates, and the class records on paper. Swap roles after the first comparison. For individual access, support keyboard controls and a written table equivalent to each visual. Learners may explain orally or with an annotated diagram. Never require personal data, a recorded voice, or a photograph.
Mixed readiness: if the entry check is difficult, use the linked prerequisite and the first two case cards; retain the same central question. If secure, ask the learner to design an unseen test and state which explanation it could disprove.
Simulate a single FIFO worker; start each job after both arrival and the previous completion. Report wait, finish, cost and privacy routing.
Starting parameters: Cost per service second = 0.01, Local only for sensitive = True
Single FIFO worker, supplied row order. Check arrivals are chronological; all timings are simulated.
| job | arrival | wait | finish | cost | route |
|---|---|---|---|---|---|
| 1 | 0 | 0 | 2 | 0.02 | either permitted |
| 2 | 1 | 1 | 5 | 0.03 | local required |
| 3 | 2 | 3 | 6 | 0.01 | either permitted |
| 4 | 3 | 3 | 10 | 0.04 | local required |
These are authored examples, not work collected from children. Assess reasoning using the lesson rubric, not whether the first prediction was correct.
Beginning: “It worked because the result looks right.” This identifies no exact case, control or measurement. Ask the learner to point to one row and say what happened.
Developing: “In the first case I recorded job: 1; arrival: 0; wait: 0; finish: 2; cost: 0.02; route: either permitted.” This cites evidence, but does not yet explain how the result follows from the rule. Ask the learner to trace the relevant step.
Secure: “For the first supplied case, job: 1; arrival: 0; wait: 0; finish: 2; cost: 0.02; route: either permitted. I can trace it using this mechanism: Simulate a single FIFO worker; start each job after both arrival and the previous completion. Report wait, finish, cost and privacy routing. My result supports a claim about these supplied cases. It does not establish that the same result holds outside them.” Look for an accurate trace, the actual settings and a bounded claim; accept equivalent oral or visual evidence.
Extending: The learner constructs and reruns a new case, reports whether the first explanation survives, and defends a revised design. Use this concrete challenge: Supply a workload trace, privacy boundary and budget. Compare simulated and measured timings without treating them as equivalent. Require the original and changed evidence and this boundary: A simulator does not measure actual hardware. Add measured traces before making procurement claims.
Moderation: first assess independently against each lesson criterion. Compare the exact trace or artefact that led to your judgement. Resolve differences using evidence, not polished language. Keep each learner's individual explanation even when the artefact was produced in a group.