Marking criteria common mistakes

Common mistakes

• Using broad aims instead of measurable objectives

  Writing aims such as "make the system good" or "include useful features" and treating them as complete requirements.

  Fix itDocument specific, appropriate objectives that can be checked and that cover the required functionality or investigation areas.

• Confusing partial coverage with nearly complete coverage

  Awarding Level 4 when a design describes only some or most key aspects.

  Fix itUse Level 2 for some aspects, Level 3 for most aspects, and reserve Level 4 for all or almost all key aspects.

• Treating Level 3 as requiring every possible requirement

  Assuming that a system cannot receive Level 3 unless it meets every proposed requirement, including requirements beyond A-level demands.

  Fix itApply the Level 3 description by considering whether almost all relevant requirements are met and ignoring requirements that go beyond the demands of A-level.

• Rewarding intention instead of achievement

  Selecting a level because the student planned to use high-level techniques, even though the program does not demonstrate proficiency in them.

  Fix itJudge what the program actually achieves. If proficiency is not demonstrated at the chosen level, check the next lower level.

• Treating every database as the same level

  Assuming that using any database demonstrates a Group A skill.

  Fix itIdentify the database structure and access method. A single-table database is a Group C example, a simple multi-table model is Group B, and a complex model with several interlinked tables and cross-table parameterised SQL is Group A.

• Treating excellent as a separate, non-cumulative category

  Assuming that a program can be excellent by showing only the characteristics listed under excellent.

  Fix itRemember that the classifications are cumulative: an excellent program is expected to show the excellent, good and basic characteristics.

• Listing tests without proving coverage

  Presenting many tests but failing to show that key aspects and all core requirements have been considered.

  Fix itSelect representative samples and explain how they demonstrate thorough testing and achievement of the requirements.

• Listing feedback without evaluating it

  Writing what an independent person said but not explaining what that feedback shows about the outcome or its requirements.

  Fix itInterpret the feedback and link it to specific requirements, strengths or weaknesses of the outcome.