C07 — Skills in Developing the Software Solution

The Hamilton and Alexandra College · Year 12 · 2026

Study material and grading standard for VCE Software Development, Unit 4 Outcome 1, Criterion 7 — Skills in developing the software solution — for students building their SAT in Godot / GDScript.

Each page covers one indicator: the VCE definition, the GDScript conventions, labelled examples — from the shared Myki fare app domain and from the projects we studied in class — and the evidence standard: what earns each tick and what does not. Your checkpoint and validation feedback is graded against these pages, so what they say is the standard.

Where C7 is assessed: C7 does not run its own validation. All three indicators are assessed live in Part B of the single 100-minute Live Coding Validation, on your comment-stripped copy of the one feature the teacher picks: a naming audit (C7-1), writing the internal documentation from scratch (C7-2), and adding input validation with a test run to show the checks fire (C7-3).

Using these pages for your checkpoint

Pick a nominated feature you have built.
Walk the lookup table below: for each code, open its page and compare your code against the Earns the tick line.
Label the exact line (# C721a — …), and for every ✍️ code write the actual prose — the label alone earns nothing there.
Anything you cannot label yet is your to-do list — each page shows the smallest pattern that earns the tick.

How the codes work

21 skill codes across three indicators: C7-1 naming conventions (5 codes, 25%), C7-2 internal documentation (9 codes, 40%), C7-3 validation techniques (7 codes, 35%).
Checkpoint sheet: three boxes per code — label C711a / C711b / C711c for your first, second and third nominated feature (63 marks).
Validation sheet: one box per code (21 marks), ticked only for skills demonstrated live during Part B — naming audit, internal documentation, input validation. Practise doing all three on your own code without notes.
✍️ = written evidence required. These codes need real prose in the comments, not just the label. All nine C7-2 codes are ✍️ — a student who labels well but writes nothing loses nearly half the criterion.
Label as you code. A skill the marker cannot find earns nothing — put the code in a comment on the line (or block) that shows it. Every example on these pages carries its own label to model exactly this.

Levels of performance: Not shown (0) · 1–2 very low · 3–4 low · 5–6 medium · 7–8 high · 9–10 very high.

Quality qualifiers decide the band

Unlike C6, the C7 descriptors carry quality words that matter as much as the code itself:

Band	C7-2 clarity	C7-3 consistency
5–6	some issues with clarity	some inconsistencies
7–8	minor issues	minor inconsistencies
9–10	clear and concise	no inconsistencies

And C7-2 climbs a verb ladder: identifies (1–2) → outlines (3–4) → describes (5–6) → explains (7–8) → explains all, clear and concise (9–10).

Code → page lookup

Code	Indicator	Level	Skill	✍️	Page
C711	C7-1	1–2	identifies naming conventions		Naming Conventions
C712	C7-2	1–2	identifies functioning	✍️	Internal Documentation
C713	C7-3	1–2	identifies input data for validation		Validation
C721	C7-1	3–4	applies naming to variables		Naming Conventions
C722	C7-2	3–4	outlines functioning	✍️	Internal Documentation
C723	C7-3	3–4	existence checking		Validation
C724	C7-3	3–4	type checking		Validation
C725	C7-3	3–4	range checking		Validation
C731	C7-1	5–6	applies naming to interface controls		Naming Conventions
C732	C7-2	5–6	describes functionality	✍️	Internal Documentation
C733	C7-2	5–6	describes use of data	✍️	Internal Documentation
C734	C7-2	5–6	evidence of code maintenance	✍️	Internal Documentation
C735	C7-3	5–6	two validation checks		Validation
C741	C7-1	7–8	applies naming to code structures		Naming Conventions
C742	C7-2	7–8	explains functionality	✍️	Internal Documentation
C743	C7-2	7–8	explains use of data	✍️	Internal Documentation
C744	C7-2	7–8	explains use of code structures	✍️	Internal Documentation
C745	C7-3	7–8	all three validation checks		Validation
C751	C7-1	9–10	applies naming to ALL solution elements		Naming Conventions
C752	C7-2	9–10	explains ALL, clear and concise	✍️	Internal Documentation
C753	C7-3	9–10	validates ALL input data, reasonableness and completeness	✍️	Validation

C6 → C7 synergy

The reasoning comments C6 already asked for (C629/C638/C645/C658 — why this type / structure / source) are also C7-2 evidence: they describe and explain your use of data. Good internal documentation earns marks on both criteria at once.

Example code

Snippets come from two places, and the pages keep both:

The Myki fare app domain (balance, fares, zones, concession, journeys) — minimal made-for-purpose examples.
Real code from the projects studied in class, attributed in the snippet's first comment line: connect-go-dots, tile-matching-game and club-ladder — whose comments and naming are the model this criterion asks for (club-ladder especially).