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

Completeness and demonstrated skill

A technical solution must address its requirements and demonstrate that its chosen techniques have been implemented proficiently. Completeness concerns how much of the required solution works. Proficiency concerns the technical skill actually demonstrated by the implementation. They are connected, but a long list of planned features is evidence of neither.

The official NEA technical-solution section has 42 marks: 15 for completeness and 27 for techniques used with demonstrated proficiency. The tables below explain that reference framework. They are not the marking rubric for a six-mark exercise in this course.

Requirements beyond A-level demand are disregarded for this judgement. A missing core booking operation matters more than an unimplemented decorative extra. Link each requirement to a visible implemented feature and test result instead of counting completed screens.

First identify the level of demand attempted, then check what the program actually achieves. If the intended higher-demand approach does not demonstrate proficiency, consider the lower level supported by the implemented work. Within a matched band, the extent of achievement, coding style and effectiveness determine the mark; including a named structure does not automatically earn the band.

For Group A demand, performance ranges from an adequately implemented, less effective solution with some excellent style characteristics, through a well-programmed effective solution with most excellent characteristics, to excellent programming and a highly effective solution with all or almost all excellent characteristics. Group B similarly ranges from just adequate implementation with good style and at most one excellent characteristic, through effective well-programmed work with some excellent characteristics, to stronger programming and effectiveness with most excellent characteristics. Group C ranges from severely limited implementation with basic style and little effectiveness, through effective simple work with some good characteristics, to strong simple implementation with almost all relevant good characteristics. These are descriptions of overall evidence, not separate checkbox awards.

Consider two independent prototypes. One reliably fulfils every requirement using a simple list and linear search. Another declares a tree class but never inserts or searches its nodes correctly. The first supplies real completeness and skill evidence; the second does not demonstrate tree proficiency merely by naming the class. Conversely, a technically strong core may still omit an important requirement, so its completeness evidence must be considered separately.

Technical Groups A, B and C as indicative examples

The official technical groups illustrate levels of demand through both models and algorithms. A model represents the relevant data or system; an algorithm operates on that representation. Choose techniques because they solve the problem, then demonstrate how they work. Adding unnecessary complexity can reduce effectiveness.

The table is indicative. Equivalent algorithms and data models are encouraged. A Python list used only as a short fixed collection does not automatically establish Group A proficiency: examine the demand of the model and operations, their appropriateness and how sufficiently they are used. Nor does one API call turn a simple script into a complex client–server solution.

For example, a club tool that reads a text file, stores member records in a dictionary and calculates simple totals resembles Group B examples. A dependency planner whose graph model supports correctly implemented traversal and scheduling can demonstrate a different level of demand. The label depends on actual implemented work and effectiveness, not a count of libraries imported. If a substantial hardware project does not fit the examples readily, the official procedure is for the centre to consult the AQA NEA Adviser or explain the marking rationale when submitting for moderation; this course cannot certify that judgement.

A practical technique justification connects a requirement to a choice and its consequence: “Lookup by membership ID is needed repeatedly, so a dictionary keyed by that unique ID avoids manually searching every record. Missing IDs are handled explicitly.” It should also recognise constraints and alternatives, such as the memory cost and the adequacy of a simpler linear search for a very small collection.

Cohesion, coupling and defensive code

Cohesion means the operations within a module serve one clear purpose. Coupling concerns its dependency on other parts of the program. A cohesive function that receives data through parameters and returns a result has a clear interface; a function that secretly changes a global list or depends on a hard-coded file path is harder to reuse and test.

Separate reading, interpreting and presenting data. load_scores(filename) deals with the file; mean_score(scores) computes a result; the caller chooses what to display. The file path is parameterised, so tests can use a different file without editing the function. Related functions can later be grouped in a module. Good interfaces make assumptions and outcomes explicit.