4.14.3.3–4.14.3.4, 4.14.5.3 - Technical solutions, proficiency and coding style (C#)

Completeness and demonstrated proficiency

Completeness asks how much of the agreed solution has been achieved; proficiency asks how skilfully appropriate techniques have actually been implemented.

A booking tool might implement storage and allocation correctly but omit a required cancellation facility. It can demonstrate genuine technical skill while remaining incomplete. Conversely, a small tool may meet every simple requirement without demonstrating advanced programming demand. Keep a requirement-to-evidence table: the requirement, relevant source section, observed behaviour and any limitation. A polished screenshot or a planned feature is not evidence that its underlying algorithm works.

The AQA technical-solution allocation is 42 marks: completeness contributes up to 15 and techniques used and proficiency up to 27. The following tables explain the official framework; they are not rubrics for the short exercises in this lesson.

Demand alone does not establish proficiency. Identify the level of the techniques attempted, then inspect what is actually achieved. If execution does not demonstrate proficiency at that level, consider the lower level until achieved demand and proficiency match. Within the appropriate band, the extent of achievement, coding style and effectiveness determine the mark. No relevant achievement earns no credit; the presence of a named technique does not guarantee a band.

The above-average, average and below-average descriptions refine each band. At Level 3, performance ranges from just adequate to fully adequate use of Group A equivalents with some excellent characteristics and less than effective to fairly effective operation, through well-programmed techniques with most excellent characteristics and an effective solution, to more than well-programmed or excellent work with all or almost all excellent characteristics and high effectiveness. At Level 2, it ranges from just adequate to fully adequate Group B implementation with all or almost all relevant good characteristics and at most one excellent example, through well-programmed work with some excellent characteristics and an effective solution, to more than well-programmed or excellent work with most excellent characteristics and high effectiveness. At Level 1, it ranges from severely limited to limited Group C implementation, basic style and a trivial or ineffective simple solution, through well-programmed simple work with some good characteristics and an effective simple solution, to more than well-programmed or excellent simple work with almost all relevant good characteristics and high effectiveness.

These descriptions require judgement about the whole evidence. They are not a calculation such as “one class plus one queue equals a particular mark”. Formal NEA judgement and authentication belong to the centre and AQA processes, rather than these practice answers.

Indicative technical groups

The technical groups illustrate levels of model and algorithm demand, so a choice must be justified by the problem and demonstrated through implementation.

The model column concerns how information and relationships are represented; the algorithm column concerns the operations performed. A useful technique solves a genuine requirement. For example, a booking system with dependencies between events might justify graph traversal to identify connected bookings. Adding an unused graph class does not demonstrate this skill. A dictionary used only to look up two constant values is not automatically equivalent to a substantial user-defined hashing solution.

The examples are indicative: alternative algorithms and data models of equivalent demand are encouraged. The table is not a list from which techniques earn automatic credit. The same library call can contribute to very different demands depending on the actual model, integration and evidence. A complicated design that the developer cannot implement or explain is weaker evidence than an appropriate achieved solution.

In C#, List<Booking> names a collection type; using the type alone does not explain the algorithmic demand. Demonstrating an appropriate ordering, allocation or relationship algorithm, with meaningful data, boundary cases and a correctness explanation, makes the skill inspectable. Choose the simplest suitable representation, then justify why it supports the requirements. Do not make a solution needlessly complex to chase a group label.

For assessed work that cannot readily be compared with the table, such as a substantial hardware project, the specification directs the centre to consult its AQA NEA adviser or provide a full explanation of the technical-solution judgement for moderation. A learner should raise this with the teacher; this lesson cannot declare an equivalence or certify a mark.