4.14.3.3–4.14.3.4, 4.14.5.3 - Technical solutions, proficiency and coding style (VB.NET)

Completeness and demonstrated skill

A technically interesting program can still fail to solve its user's problem. Judge completeness against the requirements agreed during analysis, and judge proficiency from what the implemented solution demonstrably achieves. A proposed feature, an imported library name or a comment promising an algorithm is not evidence that the skill has been applied successfully.

The official technical solution has 42 available marks: 15 for completeness and 27 for techniques used. The tables below explain those reference criteria; a short NovaLearn activity does not award these NEA marks.

For an independent equipment-loan example, a requirement might be “reject a loan when no item is available”. A working catalogue and attractive interface do not compensate for accepting impossible loans. A requirement matrix should link each requirement to its implementation location and evidence, including honest failures or limitations. Do not delete a failed essential requirement simply to make the solution appear complete.

The assessment process first considers the attempted level of demand, then checks the proficiency actually demonstrated. If the implementation does not demonstrate proficiency at that level, consider the lower level where it does. Having identified a matching band, the extent to which its criteria are met, coding style and effectiveness determine the mark within it. They are connected judgements, not a count of techniques.

Within Group A demand, just-adequate to fully-adequate implementation with some excellent style and limited-to-fair effectiveness describes below-average performance; well-programmed work with a majority of excellent characteristics and an effective solution describes average performance; stronger-to-excellent implementation with almost all excellent characteristics and greater effectiveness describes above-average performance. For Group B, the comparable progression runs from adequate implementation with almost all relevant good style but at most one excellent characteristic, through well-programmed work with some excellent style, to stronger implementation with a majority of excellent style. For Group C, severely limited implementation with basic style and little effectiveness is below average; well-programmed work with some relevant good style and an effective simple solution is average; stronger-to-excellent implementation with almost all relevant good style and a highly effective simple solution is above average.

Technical Groups A, B and C as indicative examples

The groups illustrate standards of demand; they are not a shopping list from which including an item automatically earns a band. Select a technique because it suits the problem and demonstrate that it works. An appropriate simpler model can be more effective than an unnecessary complicated one, while a complex problem needs enough implemented demand to solve it.

Group C examples

Models include single-dimensional arrays, appropriate simple data types and a single-table database. Algorithms include linear search, simple calculations such as an average and non-SQL table access. For example, a small attendance tool may search an array of names and calculate the average attendance. Clear, correct implementation still matters at this demand.

Group B examples

Models include a simple database with two or three interlinked tables; multidimensional arrays, dictionaries and records; text files or sequential-access files; simple scientific, mathematical, robotics, control or business models; simple OOP models and simple client-server models. Algorithms include single-table or non-parameterised SQL, bubble sort, binary search, file reading/writing, simple user-defined calculations and generation of objects using a simple OOP model. Simple client-server examples include server-side request/response objects and extensions, or Web-service calls that parse JSON/XML.

A dictionary can map an equipment identifier to its loan count, but putting values into a dictionary alone does not demonstrate that validation, look-up and updates work. Similarly, binary search must operate on appropriately ordered data and handle missing items.

Group A examples

Models include complex databases with several interlinked tables; hash tables, lists, stacks, queues, graphs, trees or equivalent structures; direct-access files; complex scientific, mathematical, robotics, control or business models; complex user-defined OOP using features such as inheritance, composition, polymorphism and interfaces; and complex client-server models.

Algorithm examples include cross-table parameterised SQL, SQL aggregates and user/CASE-generated DDL; graph/tree traversal, list operations, linked-list maintenance, stack/queue operations and hashing; advanced matrix operations and recursion; complex user-defined optimisation, minimisation, scheduling or pattern-matching algorithms; merge sort or a similarly efficient sort. They also include dynamic object generation using complex user-defined OOP, and complex client-server processing using server-side request/response objects and extensions or parameterised Web-service APIs with JSON/XML parsing.

These examples span different kinds of problem. You do not need every example, and an alternative algorithm or data model can demonstrate equivalent demand. A substantial hardware project may not fit the table easily; the official process calls for the teacher to consult the AQA NEA adviser or explain the judgement fully when submitting work for moderation. A short online check cannot replace that judgement.

The same language feature can support different levels of demand. A class containing two fields is not automatically a complex OOP model. Show why the relationships and behaviour are needed and how your own implementation handles them.