§ Year 11 · Digital Solutions · QCAA Senior
Year 11 Digital Solutions.
The year coding becomes engineering, not vibes.
Digital Solutions is the senior subject for students who actually want to build software. Year 11 is where you stop hacking together scripts and start designing — user requirements, algorithms, data structures, testing. The students who treat it as 'just coding' fall behind the ones who treat it as engineering. We tutor Year 11 Digital Solutions with one objective: build the design-first habit before Year 12 starts grading on it.
100% online·Sessions on Google Meet, anywhere in Queensland
§ What Year 11 covers
The syllabus, in plain English.
Year 11 Digital Solutions covers QCAA Units 1 and 2. Unit 1 (Creating with code) runs Terms 1 and 2 — understanding digital problems, gathering user requirements, and applying algorithms and programming techniques. Unit 2 (Application and data solutions) runs Terms 3 and 4 — data-driven problems, data exchange, and prototype data solutions. None of the Year 11 IAs count toward ATAR. What they do is build the design-and-documentation discipline Year 12 grades hard on.
Unit 1: Creating with code
- Understanding digital problems — decomposition, scope, constraints
- User requirements — functional and non-functional, gathering and documenting
- Algorithms — pseudocode, flowcharts, control structures (sequence, selection, iteration)
- Programming techniques — variables, data types, functions, modular design
- Testing — test data design, expected vs actual outcomes, debugging strategies
Unit 2: Application and data solutions
- Data-driven problems and solution requirements
- Data modelling — entities, attributes, relationships
- Database fundamentals — tables, primary and foreign keys, basic SQL
- Data exchange — formats (JSON, XML, CSV), APIs, basic protocols
- Prototype data solutions — building, testing, evaluating against requirements
§ Assessment
Schools deliver formative assessments through Year 11 — typically a technical proposal, a coded prototype with documentation, and a combination response exam. None count toward ATAR. They are used to build the design-document-build-test workflow Year 12 will mark you on.
Formative — Technical proposal
Formative
A document defining a digital problem, user requirements, proposed solution architecture, and evaluation criteria. Builds the structure your child will be graded on in the Year 12 IA1 technical proposal worth 25% of ATAR.
Formative — Coded prototype with documentation
Formative
A working software prototype with accompanying design documentation (pseudocode/flowcharts, test plan, evaluation). Mirrors the format of Year 12 IA2 and IA3. The marks live in the documentation as much as in the code working.
Formative — Combination response exam
Formative
Multi-choice, short response and extended response on algorithm tracing, data structure questions, and digital impacts. Practice for the Year 12 EA which is worth 25% of ATAR.
§ Where Year 11s get stuck
Common pitfalls — and how to dodge them.
Designing the UI before defining the user need
Year 11s want to open the IDE and start building. The IA process explicitly grades the upstream work — user requirements, problem decomposition, solution design — before any code is written. A pretty UI built without a documented user requirement loses the requirements marks even if the app works. Discipline: requirements first, design second, code third, test fourth.
Writing code without algorithm planning
Students who write code straight into the IDE produce solutions that work for the happy path and break on edge cases. The QCAA approach grades the pseudocode and flowchart as evidence of design thinking — and those artefacts force you to think about edge cases before you hit them. The students who plan in pseudocode first write less code overall, and that code has fewer bugs.
Confusing functional and non-functional requirements
Functional requirements describe what the system does ("the user can submit a form"). Non-functional requirements describe how well it does it ("the form submits in under 2 seconds and works on mobile screens 360px wide"). Year 11s typically list 20 functional requirements and 0 non-functional ones, then lose marks on the requirements criterion. Most real-world failures are non-functional. List both.
Test cases that only test the happy path
A high-band test plan includes valid inputs, invalid inputs, edge cases (empty input, maximum input, boundary values), and error scenarios. Year 11s submit test plans with three valid-input cases and call it done. The marker is checking whether you have systematically tested the solution — not whether you have tested it at all.
No version control or testing log
Year 12 IAs expect evidence of iterative development — version control history, testing logs, change rationale. Students who write the whole solution in one Friday-night sprint cannot produce this evidence and lose process marks. Year 11 is the year to build the habit of committing small changes with meaningful messages, and keeping a test log as you go.
§ Worked examples
A question. A walkthrough. The marks.
Example 1
Poorly-structured pseudocode, refactored
The question
A user wants a program that calculates the average grade of a list of test scores, ignoring any score below 0 (invalid). The original student pseudocode reads: SET total = 0 FOR each score in scores total = total + score END FOR SET average = total / length(scores) PRINT average
Walkthrough
The original pseudocode has three problems. First, it does not filter out invalid scores (below 0) as the requirement asks. Second, it divides by the total list length, not the count of valid scores — so an empty list or a list of all-invalid scores will divide by zero or produce a wrong average. Third, it does not handle the edge case of zero valid scores. Refactored pseudocode: SET totalValid = 0 SET countValid = 0 FOR each score in scores IF score >= 0 THEN totalValid = totalValid + score countValid = countValid + 1 END IF END FOR IF countValid > 0 THEN SET average = totalValid / countValid PRINT "Average of valid scores: " + average ELSE PRINT "No valid scores provided." END IF What changed: (1) added a filter (IF score >= 0) so invalid scores are excluded from both the running total and the count, (2) divided by the count of valid scores rather than the list length, (3) handled the edge case of zero valid scores with a clear user-facing message instead of a division-by-zero crash. In a QCAA-style marking, the refactored version would earn marks for: meeting the functional requirement, handling edge cases, producing user-readable output, and demonstrating sound algorithmic structure. The original would lose marks for requirement-mismatch and missing error handling — even though it 'works' on a list of valid inputs.
Example 2
A UX flow critique with reasoning
The question
A student has designed a login flow: 1. User lands on home page. 2. Clicks Login. 3. Enters email. 4. Clicks Next. 5. Enters password on a separate page. 6. Clicks Login. 7. Redirected to dashboard. The error message for a wrong password is 'Invalid credentials.' Critique this flow.
Walkthrough
Issue 1 — Email and password on separate pages adds friction for low-security contexts. The two-page pattern (email first, password second) is a security pattern used by services that want to allow single-sign-on detection on email entry (e.g. corporate Google accounts). For a student project without SSO logic, the separation adds a page transition and a click without a real reason. A single login form would be faster and less error-prone. Issue 2 — 'Invalid credentials' is deliberately ambiguous (don't reveal whether the email exists or whether the password is wrong) — which is good for security. But it should still tell the user what to do next ('Try again, or use Forgot Password'). The flow as designed has no Forgot Password option visible, so a locked-out user has no path forward. Issue 3 — There is no loading state described between step 6 and step 7. If the authentication takes more than a second (typical for network requests), the user sees nothing happening and may click Login again, triggering a duplicate request or thinking the form is broken. A loading state on the Login button is a 5-minute fix that prevents a real usability problem. Issue 4 — There is no successful-login confirmation before the redirect. The user clicks Login, then suddenly they are on a different page. A brief 'Welcome back' toast or a 200ms transition would make the success state legible. The refactored flow: single page, email + password + Forgot Password link visible, loading state on submit, brief success transition into the dashboard. Functionally identical, materially better UX. In a QCAA design-rationale section, this kind of critique is what high-band marks reward — not just describing the flow but evaluating it against user-experience criteria.
§ Why Pythora for Year 11 Digital Solutions
Not generic tutoring. Specifically this.
Tutors who actually code outside of school
Every Pythora Digital Solutions tutor codes — not just in the QCAA Python or JavaScript subset, but in real personal or work projects. They know what good design looks like because they have shipped working software themselves.
Design-first discipline built early
The students who score well in senior Digital Solutions are the ones who treat design and documentation as seriously as the code. We drill the requirements-design-build-test workflow until it becomes the natural way your child approaches every project.
Real Python, JavaScript or whatever your school uses
We do not lock you into one language. Whatever your child's school is using (most commonly Python, sometimes JavaScript or Java), we tutor in that language. We also support the design-document side, which is language-agnostic.
A written recap after every session
You see what was covered, where the student struggled, what was set as homework, and what the next session will focus on. In your inbox inside six minutes of the lesson ending.
§ Real student
“My first IA was a B because the code worked but the documentation was thin. My tutor showed me how to write requirements and test plans properly. The next IA was an A and I actually understood what I was building.”
§ Where this fits
One step on the path.
Year 11 Digital Solutions assumes basic familiarity with programming (loops, conditionals, variables) but not depth. Students arrive with very different starting points — some have been coding in their spare time for years, others have never written a function. Either way, the design-and-documentation skills are what differentiate at the senior level, and Year 11 is the year to build them.
Builds from
Year 10 Digital Technologies
Leads to
Year 12 Digital Solutions§ Questions
Frequently asked.
My child has never coded before. Can they still take Year 11 Digital Solutions?
Yes, but the first term is steep. Students who arrive without prior coding experience need to learn syntax, control flow, and the basics of program structure in parallel with everything else. One-on-one tutoring is genuinely helpful here — class teachers cannot stop to walk a single student through the basics. With consistent practice (1-2 hours of coding per week beyond the tutoring session), a beginner can be at the same level as peers by end of Term 2.
Is Year 11 Digital Solutions useful if my child is going into engineering or CS at uni?
Very. The design-and-documentation discipline is exactly what first-year software engineering courses assume you have. Students who arrive at uni already fluent in writing requirements, designing algorithms before coding, and writing test plans are 6-12 months ahead of their peers. The QCAA subject is a real preparation, not a watered-down version.
What language do the tutors use?
Whatever your child's school is using. Most Queensland schools teach Digital Solutions in Python; some use JavaScript or Java. We match the school. We also tutor the language-agnostic side — algorithm design, data structures, testing methodology — which carries between any language.
How much does Year 11 Digital Solutions tutoring cost?
Year 11 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 11 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