§ Year 12 · Digital Solutions · QCAA Senior
Year 12 Digital Solutions.
Where the documentation is half the mark.
Year 12 Digital Solutions is unusual among senior subjects — 75% of your ATAR is internal, in the form of a technical proposal and two coded solutions. The student who treats it as 'just code' loses marks they could have earned by writing better. The student who treats it as engineering — requirements, design, build, test, evaluate — scores in the top band. Pythora tutors Year 12 Digital Solutions with one objective: every artefact, every section, mark-grade.
100% online·Sessions on Google Meet, anywhere in Queensland
§ What Year 12 covers
The syllabus, in plain English.
Year 12 Digital Solutions covers QCAA Units 3 and 4. Unit 3 (Digital innovation) runs Terms 1 and 2 — interactions between users, data and digital systems; real-world problems and solution requirements; innovative digital solutions. Unit 4 (Digital impacts) runs Term 3 — digital methods for exchanging data, complex data exchange problems, and analysis of data security factors. Four summative assessments, each weighted 25%. The external is sat in November.
Unit 3: Digital innovation
- Interactions between users, data and digital systems
- Real-world problems and solution requirements (functional and non-functional)
- Algorithm design — pseudocode, flowcharts, complexity awareness
- Object-oriented programming — classes, objects, inheritance, encapsulation
- User-centred design and prototyping for innovative solutions
Unit 4: Digital impacts
- Digital methods for exchanging data — JSON, XML, REST APIs
- Complex digital data exchange problems and solution requirements
- Data security — confidentiality, integrity, availability (CIA triad)
- Encryption fundamentals (symmetric vs asymmetric, hashing)
- Ethical, legal and social impacts of digital systems
§ Assessment
Four summative assessments, each weighted 25%. Three internal (technical proposal, digital solution, digital solution). One external (combination response exam, sat in November).
IA1 — Technical proposal
25%
A written technical proposal — typically 8-12 pages — defining a digital problem, gathering user requirements, proposing a solution architecture, and evaluating against criteria. No code in IA1, but the design thinking is graded heavily. Sat in Term 1.
IA2 — Digital solution
25%
A working coded solution to a digital problem, plus full documentation (requirements, design, code, testing, evaluation). Typically 6-8 weeks of project time. Marks are split across the artefacts — the code working is necessary but not sufficient.
IA3 — Digital solution
25%
A second coded solution, typically focused on a data exchange or API-driven problem from Unit 4. Same artefact set as IA2 (requirements, design, code, testing, evaluation). Sat in Term 3.
External Assessment
25%
QCAA-set combination response exam covering Units 3 and 4. Multi-choice, short response and extended response. Tests algorithm tracing, code reading, data structure understanding, and digital impacts analysis. Sat in November.
Free tool
Want to see your predicted ATAR? Plug in your subjects.
§ Where Year 12s get stuck
Common pitfalls — and how to dodge them.
IA1 written like a school essay, not a technical proposal
IA1 is graded as a technical document — structured, sectioned, evidence-based. Students who write it as a flowing essay (introduction, body, conclusion) lose marks for communication and miss the criterion-by-criterion structure the marker expects. The proposal should have explicit sections: problem analysis, user requirements (functional and non-functional listed separately), solution architecture, evaluation criteria.
Code that works but documentation that does not match
A common Year 12 mistake is iterating the code through the project and never updating the design documentation. The marker reads the pseudocode, then reads the code, and finds they describe different algorithms. Marks are lost for traceability — the design should match the implementation, and if you change the implementation, update the design. Treat the documentation as a living artefact, not a one-off.
Test plans that cover happy path only
A high-band test plan systematically covers valid inputs, invalid inputs, boundary cases, edge cases, and error scenarios. Each test case has expected output, actual output, and a pass/fail with notes. Students who submit three valid-input test cases lose 4-6 marks even when the code works correctly. The test plan is graded for systematic coverage, not for the result.
Evaluation section that summarises instead of evaluating
The evaluation criterion asks: did the solution meet the requirements you defined in IA1? What are the strengths, limitations, and proposed improvements? Students who write "the solution worked well and met the requirements" earn the lowest band. The high-band response goes requirement by requirement, evidences whether each was met, identifies specific limitations, and proposes specific improvements with rationale.
No version control or evidence of iteration
The marker expects evidence that the solution was developed iteratively — git history, dated change log, screenshots from intermediate builds. Students who commit the entire solution in one push (or worse, paste a single .py file into the submission with no history) lose process marks. Year 12 is where iterative-development evidence becomes mandatory.
EA failure on code-reading and algorithm-trace questions
The EA includes "trace through this algorithm and state the value of variable X after iteration 5" questions. Students who only know how to write code, not read it, lose these marks. Algorithm-trace practice is its own skill — we drill it weekly in the lead-up to November.
§ Worked examples
A question. A walkthrough. The marks.
Example 1
A poor IA1 user requirements section, rewritten
The question
A student is proposing a mobile app to help Year 11 students track their study time across subjects. Their user requirements section reads: "The app should be easy to use. Users should be able to log their study time. The app should show how much time they have spent on each subject. The app should be reliable."
Walkthrough
The original section conflates functional with non-functional requirements, has no measurable criteria, and would earn the lowest band. Refactored: Functional requirements: FR1 — A user can create an account using email and password authentication. FR2 — A user can add a subject to their tracked list (name + colour). FR3 — A user can start and stop a timer associated with a specific subject. FR4 — A user can manually log a study session (subject, start time, duration) without using the timer. FR5 — A user can view a weekly summary showing total study time per subject as a bar chart. FR6 — A user can view a monthly summary in the same format. FR7 — A user can edit or delete a logged study session. Non-functional requirements: NFR1 — The app launches to the home screen in under 2 seconds on a mid-range Android phone (e.g. Pixel 6a). NFR2 — All user-facing screens are usable on screen widths from 360px to 430px. NFR3 — User data is persisted between app sessions (local storage) and not lost on app close. NFR4 — Passwords are stored as salted hashes, never plaintext. NFR5 — The app degrades gracefully when offline — timer and logging work without network, sync occurs when reconnected. What changed: (1) every requirement is testable — there is a specific behaviour and a specific criterion for whether it is met, (2) functional and non-functional are separated, (3) the non-functional requirements address performance, responsiveness, persistence, security and offline behaviour — the real-world concerns. The high-band marker is checking exactly these things.
Example 2
An algorithm trace, walked through
The question
Trace the following pseudocode for the input list [4, 2, 7, 1, 5]. State the final value of the variable result. FUNCTION mystery(numbers) SET result = numbers[0] FOR i FROM 1 TO length(numbers) - 1 IF numbers[i] > result THEN result = numbers[i] END IF END FOR RETURN result END FUNCTION
Walkthrough
Step 1 — Initialise. numbers = [4, 2, 7, 1, 5]. result = numbers[0] = 4. (Indexing from 0.) Step 2 — Iterate i from 1 to length(numbers) − 1 = 4 (inclusive). i = 1: numbers[1] = 2. Is 2 > 4? No. result stays 4. i = 2: numbers[2] = 7. Is 7 > 4? Yes. result = 7. i = 3: numbers[3] = 1. Is 1 > 7? No. result stays 7. i = 4: numbers[4] = 5. Is 5 > 7? No. result stays 7. Step 3 — Return result = 7. The algorithm finds the maximum value in the list. The trace technique: list each iteration, the value of i, the value of numbers[i], whether the condition is met, and the resulting value of result after the iteration. EA markers grade the trace, not just the final answer — students who write only "result = 7" without the trace can lose half the marks on a question worth several marks. Common mark loss: students lose track of the index versus the value (writing "result = 2" because i = 1 has value 2 at position 1, then carrying the index instead of the value). Drilling trace tables (one row per iteration, columns for i, numbers[i], condition, result) prevents this.
§ Why Pythora for Year 12 Digital Solutions
Not generic tutoring. Specifically this.
A tutor who sat the same EA your child will sit
Pythora Digital Solutions tutors sat the QCAA Digital Solutions external in the last few years. They remember exactly what the algorithm-trace and code-reading questions look like, and where students lose time.
IA documentation that earns the documentation marks
Year 12 Digital Solutions is 75% internal. The marks are not in the code working — they are in the design, the test plan, and the evaluation. We grade your child's IA drafts against the QCAA criteria, section by section, and we do not let them submit until each section is in the band they are targeting.
Code-reading drilled, not just code-writing
The EA grades the ability to read and trace algorithms — a different skill from writing them. We drill algorithm traces, code-reading exercises and short-answer code questions every session in the lead-up to November.
A written recap inside six minutes of every session
You see exactly what was covered, where the student struggled, what was set as homework, and what the next session will focus on.
§ Real student
“My IA2 code was fine but I lost marks on the test plan and evaluation. My tutor walked through the criteria with me and we rewrote both sections. IA3 came back as an A. I would have left those marks on the table.”
§ Where this fits
One step on the path.
Year 12 Digital Solutions builds the object-oriented programming and data exchange layer on top of Year 11's algorithm and data fundamentals. Students who arrive without solid Year 11 design-and-documentation habits spend Term 1 building artefacts that lose easy marks before the code is even reviewed.
Builds from
Year 11 Digital Solutions (Units 1-2)Leads to
Final year — this is the end of the road
§ Questions
Frequently asked.
My child can code well but loses marks on the documentation. What is going on?
Welcome to senior Digital Solutions. The QCAA criteria explicitly grade the design, testing and evaluation artefacts — not just the working code. Strong coders who treat the documentation as a chore lose the documentation marks (which are typically 50-60% of the total). The fix is mechanical: structure each artefact against the criterion sheet, mark every draft section before submitting, and treat the writing with the same care as the code.
How is Year 12 Digital Solutions scaled in ATAR?
Digital Solutions sits in the middle of the scaling range — not as aggressive as Methods or Specialist, but a high A is a real ATAR contribution and a strong differentiator for software engineering, computer science and IT pathways at university.
Will a tutor write any of the IA code or documentation?
No. That breaches academic integrity. What a tutor will do is review the work in progress, point out where requirements are weak, suggest test cases the student might have missed, walk through how to structure an evaluation section, and explain a bug rather than fix it. The student does the work; the tutor checks and challenges it.
How early should we start tutoring for Year 12 Digital Solutions?
Term 1 is ideal. IA1 (the technical proposal) is sat in Term 1, and it is worth 25% of ATAR. Students who start tutoring in Term 2 are usually already locked into an IA1 grade. The next leverage point is IA2 (Term 2) and IA3 (Term 3). Starting late means a smaller share of the ATAR is influenceable.
How much does Year 12 Digital Solutions tutoring cost?
Year 12 Digital Solutions is $85 per hour as a senior QCAA subject. Billed weekly for completed sessions, no lock-in. Every new family gets a free trial session with their matched tutor first.
Year 12 Digital Solutions.
Done properly.
One short form. We’ll match you with a tutor and call within 24 hours.
From $85/hour · Billed weekly · Pause or cancel anytime