DGT 3.4: Complex Outcome

Set Up GitHub Classroom at the Start

Create a GitHub Classroom organisation before the unit begins. Commit history is direct evidence of development process and is very difficult to fake retroactively. Students who commit regularly will find the final portfolio much easier to compile.

Weekly Stand-Ups as Formative Assessment

Run 5-minute stand-ups each week: what did you do, what will you do next, what is blocking you? These keep students on track, give you formative snapshots without marking burden, and mirror industry practice that students will encounter in employment.

Require an MVP by Lesson 4

Set a hard deadline for a working Minimum Viable Product (MVP) by Lesson 4 of the unit. This prevents last-minute panic builds and gives students time to conduct meaningful usability testing and iterate. An MVP that barely works is still more useful than a perfect plan with no code.

Brief Students on NZQA Implication Categories

Explicitly teach the four NZQA implication categories: social , cultural , environmental , and legal . Require each student to identify which one (or more) applies to their outcome and show how it influenced at least one concrete design or implementation decision.

Ngā Whāinga Akoranga — Learning Intentions

• Develop a complex digital outcome that solves a genuine problem for a defined user or community.
• Use project evidence such as commits, sprint notes, user testing, and refinements to show iterative development.
• Justify technical and design decisions in relation to user needs, implications, and outcome quality.

Hononga Marautanga — Curriculum Alignment

This standard aligns with senior Digital Technologies learning where students create authentic outcomes, integrate multiple digital techniques, and evaluate how technological decisions affect people and contexts. Strong evidence in this unit comes from the link between identified need, purposeful development process, and a refined final outcome that clearly serves its users.

Teacher Planning Snapshot

• Front-load project scoping so students define one user problem, one success metric, and one manageable technical stack before they start building.
• Collect process evidence weekly through commits, stand-up notes, screenshots, and test records so the final submission is not a reconstruction.
• Schedule user testing cycles at MVP, mid-build, and near-final stages so refinement evidence is strong enough for Merit and Excellence.

Proximinal Guidance

• Entry: provide bounded project options and starter architectures so students can focus on solving a real problem rather than inventing an unmanageable scope.
• On-level: expect students to manage their own backlog, implement a working MVP, and respond to user feedback with visible refinements.
• Extension: push students toward deeper synthesis such as database design, API integration, accessibility auditing, deployment, or more sophisticated state and data flows.