Marking criteria revision notes

What is assessed?

The marking criteria assess how well a real problem or investigation is analysed, designed, implemented and evaluated. The sections are Analysis (9 marks), Documented design (12 marks), Completeness of solution (15 marks), Techniques used (27 marks), Testing (8 marks) and Evaluation (4 marks). The criteria distinguish between the quality of the work produced and the technical demand and proficiency demonstrated.

Analysis

High-level analysis is fully or nearly fully scoped, understandable to a third party and based on the needs of intended users or recipients. Requirements should be documented as measurable, appropriate and specific objectives. They should cover all required functionality or areas of investigation. The problem should also be sufficiently well modelled to support later stages. A partly scoped problem, objectives that are not measurable, or limited consideration of user needs restricts the mark.

Documented design

A strong design explains how all or almost all key aspects of the solution or investigation are structured. It should give a third party a clear picture of the intended structure without needing to inspect the programmed solution. A design that describes only some aspects is partial; an inadequate design makes the structure difficult to understand.

Completeness and techniques

Completeness concerns how many requirements the system meets. A system meeting almost all requirements reaches the highest level, while a system addressing only some aspects remains at the lowest level. Techniques used are judged by both demand and demonstrated proficiency. Group A examples include complex interlinked database structures, graphs, trees, recursive algorithms, hashing, mergesort, advanced matrix operations and complex user-defined algorithms. Group B examples include records, dictionaries, multi-dimensional arrays, text files, bubble sort, binary search and simple object-oriented programming. Group C examples include single-dimensional arrays, simple data types, linear search and simple mathematical calculations. These are indicative examples, not a checklist. The emphasis is on what has actually been achieved.

Coding style, testing and evaluation

Excellent coding style includes appropriate interfaces, loosely coupled and cohesive modules, defensive programming and good exception handling. Good characteristics include a well-designed user interface, modularisation, local variables, few global variables, constants, indentation, self-documenting code and consistent style. Basic characteristics include meaningful identifiers and effective annotation. Testing should use carefully selected representative samples and be planned or explained. Evaluation should consider every requirement, improvements if the problem were revisited, and useful independent feedback.

Common errors

Do not confuse listing a technique with demonstrating proficiency. Do not claim complete testing from a few examples. Do not ignore unmet requirements during evaluation. Do not describe a design only by referring to the final code; the documented design must itself explain the structure.