1. Chapter 49
Non-Exam Assessment

2. Learning objectives In this chapter you will learn:
how to select an appropriate problem for your project
how to tackle each section of the project
how to interpret the mark scheme
what programming skills and techniques you should use to achieve a good mark
how to document your project.

3. Overview
The A-Level non-exam assessment constitutes 20% of the total A-Level Grade.
It requires you to work on a project either to identify a real problem that can be solved with a computer-based solution or to investigate a specific aspect computer science.
You are required to work through all of the stages of system development to produce a programmed solution.
This is a major piece of work that should take at least 50 hours, with the majority of the marks available for the technical solution.

4. Characteristics of the project (1)
You are expected to either:
identify a realistic problem with a real end user and create a system that allows interaction with the user and involves the storage, manipulation and output of data, or
investigate a specific aspect of computing, such as artificial intelligence or 3D graphical modelling with reference to a project supervisor.

5. Characteristics of the project (2)
Planning is adaptive, which means that it may need to change during the stages of development.
Developments may evolve as the technical solution is being written, for example, after a prototype has been created.
Technical solutions should be completed well ahead of schedule to allow time for changes to be made.
There should be a culture of continuous improvement, which may mean adding to or changing aspects of your code.

6. Mark allocation Analysis 9 Documented design 12 Technical solution 42
Testing 8
Evaluation 4
Total 75

7. Choosing a project
Considerable thought should be given to the choice of project.
Start with family and friends to see if there is anything they do on which you could base a project. For example, you could choose something based on their work.
Many students base projects on their own work experience placements, particularly if they still have contacts at the organisation.
Another source of projects is your own hobbies and interests. For example, you may be able to create systems related to gaming, social media, clubs or societies that you are involved in.
You should also base your choice on the tools and skills that you know are available in your centre, and on your level of expertise with different software.

8. Project ideas (1)
A simulation into a business or scientific issue. For example, a business issue such as modelling share prices, or a scientific issue such as modelling flu epidemics.
An investigation of a well-known problem such as the game of life, the Towers of Hanoi or the travelling salesman problem.
A solution to a data processing problem for an organisation, such as: membership systems (e.g. clubs, gyms), booking systems for organisations such as holiday companies or medical appointments; stock control systems; student timetabling and school reporting systems.
The solution of an optimisation problem, such as production of a rota, shortest-path problems or route finding.

9. Project ideas (2) A computer game.
An application of artificial intelligence or investigation into machine learning algorithms.
A control system operated using a device such as an Arduino board, Raspberry Pi or robotic arm.
A website with dynamic content, driven by a database back-end. Note that the creation of a static website will not be sufficient for A level.
Rendering a three-dimensional world on screen.
An app for a mobile phone or tablet of a suitable complexity, perhaps chosen from the list above.
Exploring large datasets, looking for and visualising correlations.

10. Analysis (1)
General background information on the organisation or person you are creating the system for. This should be sufficiently clear for a third party to read and understand.
A description of the problem with a clear statement that describes the problem area and the specific problem that is being solved/investigated.
An analysis of the critical path of the project in terms of identifying the main stages, the sequence in which these should be done and the dependency between the stages. 
An outline of how the problem was researched, which might include an interview or questionnaire involving the user/supervisor.

11. Analysis (2)
Source documents from the current system where relevant, or evidence of research into the chosen aspect of computing.
Observation of the existing system where relevant.
A list of the user’s requirements and any limitations.
A list of general and specific objectives that are realistic, achievable and measurable.
Any modelling that helps inform the Design stage, which may include: graph models, entity-relationships models, data flow diagrams.

12. How the Analysis section is assessed
How well the problem has been scoped and whether it has been explained in a way that is easy to understand.
Whether there is a fully documented set of measurable and appropriate specific objectives.
Whether the requirements were identified through proper research and dialogue with the user.
Whether the problem has been sufficiently well modelled to be of use in subsequent stages.

13. Design (1)
The overall system design, perhaps in the form of a top-down design diagram, system flow chart or entity relationship model.
A description of the main modules that will make up the system.
A description of the data items including data types and structures.
A description of the file structures being used.
Explanation of the main algorithms that will be used. It may be appropriate to use pseudo-code or specific code, for example SQL queries.

14. Design (2)
A sample of rough designs of inputs and outputs including forms and reports.
Examples of the design of the human computer interface.
An explanation of any library software that will be used e.g. scientific or data visualisation libraries.
An explanation of any database or web design frameworks being used.

15. How the Design section is assessed
This section is marked by looking at how well your design describes how the key aspects of the solution are structured:
Fully/nearly fully explained
Adequately explained
Partially explained
Inadequately explained

16. Technical solution
This is the main part of the project where most marks are awarded. It is split into two parts:
The completeness of the solution
The techniques used

17. The completeness of the solution
A total of 15 marks are available here and awarded depending on how well your solution meets the requirements that you identified in your analysis.
The three bands are:
Meets almost all requirements
Meets many requirements
Meet some requirements.
The total marks awarded will be a matter of judgement.

18. The techniques used
27 marks are available in this section and are awarded based on how proficient you are at using certain programming techniques.
Note that to be proficient means that you have successfully implemented a particular part of the code. That is, your code must actually work.

19. Evidence required
Self-documenting code, which means code that uses meaningful identifiers, logical structures and annotation (comments) that allows a third party to understand it.
An overview guide which, amongst other things, includes the names of entities such as executables, data filenames/URLs, database names and pathnames.
Explanations of particularly difficult-to-understand code sections.
A careful division of the presentation of the code listing into appropriately labelled sections.

20. System testing
An overview of the test strategy, including an explanation of the test data used.
Test data should include normal (typical), boundary and erroneous data.
As well as testing individual functions there should be ‘whole system’ tests that help to prove that the original objectives of the system have been met.
Evidence that tests have been carried out, including annotated hard copies.
All possible outcomes should be tested, with a table to show expected and actual outcome.
Samples of screenshots or actual print-outs as evidence.

21. How the Testing section is assessed
This section is marked according to two main criteria:
clear, well-presented evidence of testing
evidence that the testing proves that the system is robust and works as intended.

22. Evaluation
Copy the original objectives that you wrote in the analysis section. Go through each and explain whether you met the objective. If you met the objective, explain how effectively it was met and, if you did not meet the objective, explain why not.
Give your user a chance to use the system and ask them for general and specific comments. Don’t invent the user/supervisor feedback – it will be obvious.
Address the user/supervisor feedback, explaining how you may incorporate any changes they have requested.
Based on these comments and your own opinions, identify any ways in which the system could be improved or enhanced.

23. How the Evaluation section is assessed
This section is marked according to three main criteria:
whether you have considered and addressed suggestions for improvements
whether you have obtained real feedback from you user(s)/supervisor
whether you have fully considered how well the solution meets its objectives.

24. General advice on projects
Students who do well in coursework:
plan the project well
stick to deadlines
ask their teachers lots of sensible questions
refer to the specification and other resources provided by AQA, such as the Examiner’s Report on last year’s projects
have a real user/supervisor, and use real feedback
consult with the user/supervisor throughout the project
have an interest in the problem they have chosen to solve
work on the project outside lesson time.