Marking criteria study guide

A connected way to reason about the criteria

Begin with the problem and its intended users or recipients. Analysis should establish what is required, why it is required and how each objective can be measured. For example, an objective should describe specific required functionality rather than merely stating that the system should be useful. Then model the problem sufficiently for the next stage. The model and objectives should lead naturally to a documented design that explains how the solution or investigation will be structured.

Next distinguish completeness from techniques. Completeness asks whether the implemented system meets the requirements. Techniques used asks what technical demand has been attempted and, more importantly, what level of proficiency the program actually demonstrates. A project can attempt a Group A technique but fail to demonstrate proficiency; in that situation, the appropriate lower demand level is considered. Conversely, including a technique is not automatically credited simply because it appears in the work. The effectiveness of the solution and the demonstrated coding style also affect the exact mark within a band.

Worked reasoning pattern

Suppose a project has measurable objectives covering most functionality, considers user needs through dialogue and models the problem sufficiently for design. This evidence is stronger than a partly scoped analysis, but omissions prevent the highest Analysis level. If the design explains most key structures but leaves important aspects unclear, it fits the adequately articulated rather than fully articulated description. If the completed system achieves many requirements but not all, Completeness is below its highest level. For Techniques used, inspect the implemented program: identify the model and algorithms, compare their demand with the indicative Groups A, B and C, then check whether proficiency is demonstrated. Finally inspect coding style, solution effectiveness and the quality of evidence for testing.

Testing and evaluation

Testing evidence should consist of representative samples, not an unstructured collection of tests. For the strongest testing level, the samples should provide clear evidence that testing is thorough, the complete or nearly complete solution is robust and the requirements have been achieved. Lower levels may involve moderately extensive or extensive testing where important requirements are not clearly demonstrated. Tests should be planned or fully explained alongside their evidence.

Evaluation must be separate from testing. Testing shows what happened when the solution was checked; evaluation considers how well the outcome meets all requirements. A strong evaluation discusses improvements in detail if the problem were revisited and obtains useful, realistic independent feedback, then evaluates that feedback meaningfully. Ignoring unmet requirements or providing only a superficial assessment limits the evaluation.

Self-check questions

• Are all objectives specific, measurable and appropriate?
• Were requirements derived by considering intended users or recipients through dialogue?
• Could a third party understand the design without inspecting the code?
• Does the completed system meet almost all, many, or only some requirements?
• What technical demand is actually demonstrated, rather than merely claimed?
• Does the code show the relevant basic, good and excellent style characteristics?
• Do representative tests cover the core requirements and is the evidence explained?
• Does the evaluation address every requirement, improvements and useful independent feedback?

When making a judgement, match the whole description that best fits the evidence. Avoid awarding a higher level because one isolated feature appears; the criteria emphasise the extent of achievement, demonstrated proficiency, coding quality and effectiveness.