Topic study hub
Marking criteria
Official AQA 7517 section 4.14.3.
0
Objectives
10
Flashcards
10
Questions
90 min
Study time
AqaA LevelComputer ScienceNon-exam assessment - the computing practical
Choose a revision tool
Start revising Marking criteria
Syllabus checklist
What you need to know
0 objective pages available
Analysis (9 marks)1 objectives
- Analysis (9 marks): Level Mark range Description 3 7-9 Fully or nearly fully scoped analysis of a real problem, presented in a way that a third party can understand. Requirements fully documented in a set of measurable and appropriate specific objectives, covering all required functionality of the solution or areas of investigation. Requirements arrived at by considering, through dialogue, the needs of the intended users of the system, or recipients of the outcomes for investigative projects. Problem sufficiently well modelled to be of use in subsequent stages. 2 4-6 Well scoped analysis (but with some omissions that are not serious enough to undermine later design) of a real problem. Most, but not all, requirements documented in a set of, in the main, measurable and appropriate specific objectives that cover most of the required functionality of a solution or areas of investigation. Requirements arrived at, in the main, by considering, through dialogue, the needs of the intended users of the system, or recipients of the outcomes for investigative projects. Problem sufficiently well modelled to be of use in subsequent stages. 1 1-3 Partly scoped analysis of a problem. Requirements partly documented in a set of specific objectives, not all of which are measurable or appropriate for developing a solution. The required functionality or areas of investigation are only partly addressed. Some attempt to consider, through dialogue, the needs of the intended users of the system, or recipients of the outcomes for investigative projects. Problem partly modelled and of some use in subsequent stages.
Documented design (12 marks)1 objectives
- Documented design (12 marks): Level Mark range Description 4 10-12 Fully or nearly fully articulated design for a real problem, that describes how all or almost all of the key aspects of the solution/investigation are to be structured/are structured. 3 7-9 Adequately articulated design for a real problem that describes how most of the key aspects of the solution/ investigation are to be structured/are structured. 2 4-6 Partially articulated design for a real problem that describes how some aspects of the solution/investigation are to be structured/are structured. 1 1-3 Inadequate articulation of the design of the solution so that it is difficult to obtain a picture of how the solution/ investigation is to be structured/is structured without resorting to looking directly at the programmed solution.
Completeness of solution (15 marks)1 objectives
- Completeness of solution (15 marks): Level Mark range Description 3 11-15 A system that meets almost all of the requirements of a solution/an investigation (ignoring any requirements that go beyond the demands of A-level). 2 6-10 A system that achieves many of the requirements but not all. The marks at the top end of the band are for systems that include some of the most important requirements. 1 1-5 A system that tackles some aspects of the problem or investigation. 100
Techniques used (27 marks)1 objectives
- Techniques used (27 marks): Level Mark Range Description Additional information 3 19-27 The techniques used are appropriate and demonstrate a level of technical skill equivalent to those listed in Group A in Table 1. Program(s) demonstrate(s) that the skill required for this level has been applied sufficiently to demonstrate proficiency. Above average performance: Group A equivalent algorithms and model programmed more than well to excellent; all or almost all excellent coding style characteristics; more than to highly effective solution. Average performance: Group A equivalent algorithms and/or model programmed well; majority of excellent coding style characteristics; an effective solution. Below average performance: Group A equivalent algorithms and/or model programmed just adequately to fully adequate; some excellent coding style characteristics; less than effective to fairly effective solution. 2 10-18 The techniques used are appropriate and demonstrate a level of technical skill equivalent to those listed in Group B in Table 1. Program(s) demonstrate(s) that the skill required for this level has been applied sufficiently to demonstrate proficiency. Above average performance: Group B equivalent algorithms and model programmed more than well to excellent; majority of excellent coding style characteristics; more than to highly effective solution. Average performance: Group B equivalent algorithms and/or model programmed well; some excellent coding style characteristics; effective solution. Below average performance: Group B equivalent algorithms and/or model programmed just adequately to fully adequate; all or almost all relevant good coding style characteristics but possibly one example at most of excellent characteristics; less than effective to fairly effective solution. Level Mark Range Description Additional information 1 1-9 The techniques used demonstrate a level of technical skill equivalent to those listed in Group C in Table 1. Program(s) demonstrate(s) that the skill required for this level has been applied sufficiently to demonstrate proficiency. Above average performance: Group C equivalent model and algorithms programmed more than well to excellent; almost all relevant good coding style characteristics; more than to highly effective simple solution. Average performance: Group C equivalent model and algorithms programmed well; some relevant good coding style characteristics; effective simple solution. Below average performance: Group C equivalent algorithms and/or model programmed in a severely limited to limited way; basic coding style characteristics; trivial to lacking in effectiveness simple solution. Select the band, 1, 2 or 3 with level of demand description that best matches the techniques and skill that the student’s program attempts to cover. The emphasis is on what the student has actually achieved that demonstrates proficiency at this level rather than what the student has set out to use and do but failed to demonstrate, eg because of poor execution. Check the proficiency demonstrated in the program. If the student fails to demonstrate proficiency at the initial level of choice, drop down a level to see if what the student has done demonstrates proficiency at this level for the lower demand until a match is obtained. Table 1 is indicative of the standard required and is not to be treated as just a list of things for students to select from and to be automatically credited for including in their work. As indicated above, having selected the appropriate level for techniques used and proficiency in their use, the exact mark to award should be determined based upon: • the extent to which the criteria for the mark band have been achieved • the quality of the coding style that the student has demonstrated (see Table 2 for exemplification of what is expected) • the effectiveness of the solution. 102
Table 1: Example technical skills1 objectives
- Table 1: Example technical skills: Group Model (including data model/structure) Algorithms A Complex data model in database (eg several interlinked tables) Hash tables, lists, stacks, queues, graphs, trees or structures of equivalent standard Files(s) organised for direct access Complex scientific/mathematical/robotics/ control/business model Complex user-defined use of object- orientated programming (OOP) model, eg classes, inheritance, composition, polymorphism, interfaces Complex client-server model Cross-table parameterised SQL Aggregate SQL functions User/CASE-generated DDL script Graph/Tree Traversal List operations Linked list maintenance Stack/Queue Operations Hashing Advanced matrix operations Recursive algorithms Complex user-defined algorithms (eg optimisation, minimisation, scheduling, pattern matching) or equivalent difficulty Mergesort or similarly efficient sort Dynamic generation of objects based on complex user-defined use of OOP model Server-side scripting using request and response objects and server-side extensions for a complex client-server model Calling parameterised Web service APIs and parsing JSON/XML to service a complex client-server model Group Model (including data model/structure) Algorithms B Simple data model in database (eg two or three interlinked tables) Multi-dimensional arrays Dictionaries Records Text files File(s) organised for sequential access Simple scientific/mathematical /robotics/ control/business model Simple OOP model Simple client-server model Single table or non-parameterised SQL Bubble sort Binary search Writing and reading from files Simple user defined algorithms (eg a range of mathematical/statistical calculations) Generation of objects based on simple OOP model Server-side scripting using request and response objects and server-side extensions for a simple client-server model Calling Web service APIs and parsing JSON/XML to service a simple client- server model C Single-dimensional arrays Appropriate choice of simple data types Single table database Linear search Simple mathematical calculations (eg average) Non-SQL table access Note that the contents of Table 1 are examples, selected to illustrate the level of demand of the technical skills that would be expected to be demonstrated in each group. The use of alternative algorithms and data models is encouraged. If a project cannot easily be marked against Table 1 (for example, a project with a considerable hardware component) then please consult your AQA non-exam assessment Adviser or provide a full explanation of how you have arrived at the mark for this section when submitting work for moderation. 104
Table 2: Coding styles1 objectives
- Table 2: Coding styles: Style Characteristic Excellent Modules (subroutines) with appropriate interfaces. Loosely coupled modules (subroutines) – module code interacts with other parts of the program through its interface only. Cohesive modules (subroutines) – module code does just one thing. Modules(collections of subroutines) – subroutines with common purpose grouped. Defensive programming. Good exception handling. Good Well-designed user interface Modularisation of code Good use of local variables Minimal use of global variables Managed casting of types Use of constants Appropriate indentation Self-documenting code Consistent style throughout File paths parameterised Basic Meaningful identifier names Annotation used effectively where required The descriptions in Table 2 are cumulative, ie for a program to be classified as excellent it would be expected to exhibit the characteristics listed as excellent, good and basic not just those listed as excellent.
Testing (8 marks)1 objectives
- Testing (8 marks): Level Mark range Description 4 7-8 Clear evidence, in the form of carefully selected representative samples, that thorough testing has been carried out. This demonstrates the robustness of the complete or nearly complete solution/thoroughness of investigation and that the requirements of the solution/ investigation have been achieved. Level Mark range Description 3 5-6 Extensive testing has been carried out, but the evidence presented in the form of representative samples does not make clear that all of the core requirements of the solution/ investigation have been achieved. This may be due to some key aspects not being tested or because the evidence is not always presented clearly. 2 3-4 Evidence in the form of representative samples of moderately extensive testing, but falling short of demonstrating that the requirements of the solution/ investigation have been achieved and the solution is robust/ investigation thorough. The evidence presented is explained. 1 1-2 A small number of tests have been carried out, which demonstrate that some parts of the solution work/some outcomes of the investigation are achieved. The evidence presented may not be entirely clear. Evidence for the testing section may be produced after the system has been fully coded or during the coding process. It is expected that tests will either be planned in a test plan or that the tests will be fully explained alongside the evidence for them. Only carefully selected representative samples are required.
Evaluation (4 marks)1 objectives
- Evaluation (4 marks): Level Mark Description 4 4 Full consideration given to how well the outcome meets all of its requirements. How the outcome could be improved if the problem was revisited is discussed and given detailed consideration. Independent feedback obtained of a useful and realistic nature, evaluated and discussed in a meaningful way. 3 3 Full or nearly full consideration given to how well the outcome meets all of its requirements. How the outcome could be improved if the problem was revisited is discussed but consideration given is limited. Independent feedback obtained of a useful and realistic nature but is not evaluated and discussed in a meaningful way, if at all. 106 Level Mark Description 2 2 The outcome is discussed but not all aspects are fully addressed either by omission or because some of the requirements have not been met and those requirements not met have been ignored in the evaluation. No independent feedback obtained or if obtained is not sufficiently useful or realistic to be evaluated in a meaningfully way even if attempted. 1 1 Some of the outcomes are assessed but only in a superficial way. No independent feedback obtained or if obtained is so basic as to be not worthy of evaluation.
Key terms
Measurable objectiveProblem modelArticulated designKey aspectsCompleteness of solutionRequirementDemonstrated proficiencyCoding style characteristicsParameterised SQLDirect accessInterfaceModularisation
Exam tips
- Link every judgement to the criteria: When selecting a level or mark range, refer explicitly to scope, measurable objectives, coverage, dialogue with intended users, and the usefulness of the problem model.
- Match both coverage and clarity: When selecting a level, consider how many key aspects are described and whether the solution structure can be understood from the design itself.
Common mistakes
- Using broad aims instead of measurable objectives: Document specific, appropriate objectives that can be checked and that cover the required functionality or investigation areas.
- Confusing partial coverage with nearly complete coverage: Use Level 2 for some aspects, Level 3 for most aspects, and reserve Level 4 for all or almost all key aspects.
Practice preview
Continue by objective
Objectives are grouped by subtopic so students can jump straight to the exact skill they want to revise.
Related topics