4.14.3.3–4.14.3.4, 4.14.5.3 - Technical solutions, proficiency and coding style (Java)
Learn to judge technical choices by what they achieve, improve the structure of Java source and make a solution understandable to another reader. These are independent formative project skills; they do not complete or certify an assessed NEA. The Java route is incomplete: runnable support pending, with written source tasks and no Run.
Completeness and demonstrated proficiency
A technical solution must both address the problem's requirements and demonstrate competent use of appropriate techniques.
The official NEA has 75 marks: analysis 9, design 12, technical solution 42, testing 8 and evaluation 4. The technical solution separates completeness (15) from techniques used and demonstrated proficiency (27). These are references to the official framework, not marks awarded by this lesson's short exercises.
Completeness is judged against the requirements of the solution or investigation, ignoring requirements beyond A-level demand. The official completeness bands are:
| Band | Official mark range | What the evidence establishes |
|---|---|---|
| 3 | 11–15 | Almost all relevant requirements are met |
| 2 | 6–10 | Many, but not all, requirements are met; the upper end includes some of the most important requirements |
| 1 | 1–5 | Some aspects of the problem or investigation are tackled |
A library-loan prototype might create a loan but fail to return items or save changes. The existence of a working screen is not evidence for the missing requirements. A requirements-to-evidence table can link “prevent two current loans for one item” to the relevant source and tests. It should also expose missing or partially implemented behaviour.
Proficiency means the skill actually demonstrated in using a technique effectively. A declared class with no useful behaviour, or an imported library that is never used, does not establish sophisticated implementation. The official techniques/proficiency bands have ranges 19–27 for Group A equivalent demand, 10–18 for Group B and 1–9 for Group C. First consider the attempted demand, then check the achieved proficiency. If proficiency at that demand is not demonstrated, consider the lower band rather than awarding it for the ambition alone.
Within an appropriate band, the degree of achievement, coding style and effectiveness of the solution determine the mark. The official descriptions distinguish performance within each demand level:
| Demand | Above-average performance | Average performance | Below-average performance |
|---|---|---|---|
| Group A equivalent | Algorithms and model implemented very well to excellently; all or almost all excellent style characteristics; more than effective to highly effective solution | Algorithms and/or model implemented well; a majority of excellent style characteristics; effective solution | Algorithms and/or model implemented just adequately to fully adequately; some excellent style characteristics; less than effective to fairly effective solution |
| Group B equivalent | Algorithms and model implemented very well to excellently; a majority of excellent style characteristics; more than effective to highly effective solution | Algorithms and/or model implemented well; some excellent style characteristics; effective solution | Algorithms and/or model implemented just adequately to fully adequately; all or almost all relevant good style characteristics, with at most one excellent example; less than effective to fairly effective solution |
| Group C equivalent | Model and algorithms implemented very well to excellently; almost all relevant good style characteristics; more than effective to highly effective simple solution | Model and algorithms implemented well; some relevant good style characteristics; effective simple solution | Model and/or algorithms implemented in a severely limited to limited way; basic style characteristics; trivial to ineffective simple solution |
These are contextual judgements of achieved work, not three sets of automatic feature points. A named technique, a line count or a screenshot cannot determine the exact mark on its own.
Indicative technical groups
The technical groups illustrate levels of demand; they are not a shopping list of features that automatically earn marks.
Choose a model and algorithm because they solve the problem. A queue is useful when requests must be served in arrival order. A graph is useful when relationships and paths are central. Replacing a simple array with a graph that adds no relevant behaviour can make a solution harder to understand without improving it.
The official examples can be organised as follows. “Equivalent” matters: a suitable alternative algorithm or model can demonstrate the same standard.
| Group | Examples of models and data structures | Examples of algorithms and operations |
|---|---|---|
| A | Complex interlinked database model; hash tables, lists, stacks, queues, graphs or trees; direct-access files; complex scientific, mathematical, robotics, control or business model; complex user-defined OOP using relationships such as inheritance, composition, polymorphism or interfaces; complex client-server model | Cross-table parameterised SQL, aggregate functions or user/CASE-generated DDL; graph/tree traversal, list operations or linked-list maintenance, stack/queue operations and hashing; advanced matrix work, recursion, complex optimisation/scheduling/pattern matching or equivalent algorithms; merge sort or similarly efficient sorting; dynamic object generation within complex OOP; server-side request/response processing and extensions, or parameterised web-service calls with JSON/XML parsing, for a complex client-server model |
| B | Simple database model, for example two or three interlinked tables; multidimensional arrays, dictionaries or records; text or sequential-access files; simple scientific, mathematical, robotics, control or business model; simple OOP or client-server model | Single-table or non-parameterised SQL; bubble sort or binary search; file reading/writing; simple user-defined mathematical/statistical calculations; generating objects in simple OOP; server-side request/response processing or web-service calls and JSON/XML parsing for a simple client-server model |
| C | One-dimensional arrays; suitable simple types; a single-table database | Linear search, simple calculations such as an average, or non-SQL table access |
The distinction depends on the actual model, algorithm and competent use, not the spelling of a Java library name. A simple dictionary lookup and a carefully designed hashing solution can have different demands. Likewise, using a built-in sort does not by itself demonstrate that the student implemented and understands an efficient sorting algorithm.
Consider a route planner. A well-used graph with an appropriate traversal may demonstrate demanding technical work; evidence should explain the node/edge model, show the relevant source and establish correct behaviour. A screen saying “graph loaded” establishes very little. A simpler stock lookup might be well solved with an array and linear search; its simpler demand can still be implemented proficiently.
These tables are indicative. Alternative algorithms and data models are encouraged. If a project, such as one with substantial hardware, does not fit the examples easily, the official guidance directs the centre to its AQA NEA adviser or to explain the marking rationale for moderation. This is a teacher/centre judgement, not an automatic award available from a learner selecting a group in an app.
Appropriate demand, achieved proficiency, coding style and effectiveness work together. Adding a technique without a purpose or without competent implementation does not establish a higher standard.
Continue this lesson.
You’re previewing NovaLearn without an account. Create a free account to read the rest.
Create free account