Notes · Computer ScienceUK · A-Levels

Non-exam assessment – the computing practical project

The non-exam assessment (NEA) is the practical programming project worth 20% of the A-Level. Unlike the rest of the specification it is assessed by coursework rather than in a written examination: students independently develop a substantial coded solution to a real problem for a real user, documented across analysis, design, technical solution, testing and evaluation. These notes explain what the NEA requires and how to approach it well, applying the systematic problem-solving methodology in practice.

3 sections~11 min reading time3 competenciesLevel Foundation 1 · Standard 2

T·141414 / 14

Exam profile

AO3 · Design, program and evaluate a substantial solution to a real problem (the majority of the NEA marks)AO2 · Apply programming and computational-thinking skills to build and test the solutionAO1 · Demonstrate knowledge and understanding through appropriate technical choices

Operators:analysedesigndeveloptestevaluatejustify

basic level

The NEA is a full A-Level (A2) component; AS students complete shorter practical work rather than the full project.

higher level

The full A-Level NEA is a substantial, independently-developed project marked across analysis, design, technical solution, testing and evaluation - the principal place practical programming is assessed.

Depth

Text

Contents · 3 sections

Non-exam assessment – the computing practical project

What the NEA is and how it is weighted#

FoundationAQA 7517 4.14DfE GCE Computer Science - practical project

The five NEA sections and their marks

Fig. 1The 75-mark NEA is reported across five sections. The technical solution carries the most marks, reflecting that the NEA principally assesses the ability to build a working, appropriately complex program; analysis, design, testing and evaluation document and justify it. (Mark allocations follow the AQA 7517 specification.)

The non-exam assessment (NEA) is the practical component of A-Level Computer Science: a substantial, independently-developed programming project in which a student analyses a real problem, designs and builds a working coded solution for a real end user, tests it and evaluates it. It is worth 75 marks - 20% of the A-Level - and, unlike the two written papers, it is marked by the centre (your teacher) and moderated by the awarding body rather than sat under timed exam conditions. Honestly, then, it is not a topic to be revised for an exam but a project to be carried out well over an extended period.

The NEA is the principal place the practical programming skills of the course are assessed at length. Where Paper 1 tests programming under timed, on-screen conditions, the NEA gives space to demonstrate the full development of a non-trivial solution - the kind of work a professional developer does. It rewards appropriate complexity: a solution that genuinely exercises programming techniques (data structures, algorithms, file or database handling, a sensible modular structure) rather than a trivial program, matched to a problem worth solving.

The single most important requirement is that the work is the student's own, independent effort. The teacher may give general guidance but the analysis, design, coding, testing and evaluation must be the candidate's own, and the work is authenticated as such. Using third-party libraries is allowed and normal, but they must be acknowledged and the student's own contribution must be clear and substantial - the marks are for what you designed and built.

Because it is 20% of the grade and developed over months, the NEA rewards starting early, working steadily, and keeping good records. It draws directly on the systematic problem-solving methodology of the previous chapter and on the programming, data-structures and algorithms chapters - it is where the whole course comes together in practice. Understanding its structure and standards (below) is the first step to doing it well.

Worked example

How the NEA contributes to the final grade

The A-Level is Paper 1 (100 marks, 40%), Paper 2 (100 marks, 40%) and the NEA (75 marks, 20%). Explain what the NEA's weighting means for how a student should treat it.

Its share
The NEA is 20% of the whole A-Level - a fifth of the final grade - carried by 75 centre-marked, moderated marks.
Compare with a paper
That is half the weight of either written paper, but earned over months of steady work rather than 2.5 hours - so every section done well is reliably bankable marks.
Implication
Because it is substantial and developed over time, starting early and doing each of the five sections thoroughly is a dependable way to secure a fifth of the grade before the exams.

Result: The NEA is worth 20% of the A-Level. Its coursework nature makes it the most controllable component - thorough, early, independent work turns it into secure marks.

Typical mistakes

Treating the NEA as something to revise for an exam - it is an extended project to be planned and built, not memorised.
Choosing a trivial problem that cannot demonstrate appropriate programming complexity, or leaving the project too late to develop and test properly.

Active revision

Explain how the NEA differs from Papers 1 and 2 in what it assesses and how it is marked, and state two features that make a project of 'appropriate complexity' rather than trivial.

Active recall

Recall the key points — then reveal.

Sources: GCE AS and A level subject content for computer science (Department for Education) · AQA A-level Computer Science 7517 specification (AQA)

The five assessment sections#

StandardAQA 7517 4.14DfE GCE Computer Science - project sections

The NEA report is marked across five sections that mirror the development lifecycle. Analysis investigates the problem with the real end user, establishes the requirements, and sets measurable, testable success criteria against which the finished solution will be judged; it should also justify why the problem is amenable to a computational solution. Vague aims score poorly here - the criteria must be specific enough to test at the end.

Documented design describes the intended solution in enough detail that a competent third party could implement it: the algorithms (as pseudocode, flowcharts or structure charts), the data structures and any database design (tables, keys, validation), the user interface, and how the parts fit together. Good design is where decomposition and abstraction are demonstrated, and it directly enables the next section. Technical solution - the largest section by marks - is the working, coded solution itself, assessed on its completeness and appropriate complexity (genuine use of programming techniques) and on being well-structured, readable and robust.

Testing provides a robust, evidenced test strategy: a test plan covering normal, boundary and erroneous data across all the requirements, with evidence (such as annotated screenshots) that each test was run and its outcome. Testing should demonstrate the solution works and fails gracefully, and should be traceable back to the success criteria. Evaluation then judges the finished solution against those success criteria, taking each in turn, stating with evidence whether it was met, gathering independent feedback from the end user, and proposing realistic improvements.

The five sections are not separate exercises but a connected argument: the success criteria set in analysis drive the design, which is realised in the technical solution, verified by the testing, and judged in the evaluation. The strongest projects keep this thread visible - every design decision traces to a requirement, every test to a criterion, every evaluation point to the original analysis - so the report reads as a coherent, honest account of a solved problem.

Worked example

Threading one requirement through all five sections

Show how a single requirement - 'the system must prevent double-booking of a time slot' - runs through the analysis, design, technical solution, testing and evaluation of a booking project.

Analysis
Success criterion: 'The system shall reject any booking for a slot that is already booked, and inform the user.' - specific and testable.
Design and solution
Design: before saving, query existing bookings for that slot; if one exists, refuse and message the user. The technical solution implements this check (e.g. a database query or a search of the bookings structure).
Testing
Boundary/erroneous test: attempt to book an already-booked slot - expected outcome: rejected with a clear message. Evidence: an annotated screenshot of the refusal.
Evaluation
Against the criterion: state that double-booking was prevented in testing and confirmed by the tutor's feedback, noting any limitation (e.g. behaviour under simultaneous requests).

Result: One requirement traces cleanly from a measurable criterion, through design and code, to a specific test and an evaluation point - exactly the connected argument the NEA rewards.

Typical mistakes

Writing sections in isolation so the testing and evaluation do not trace back to the analysis's success criteria.
A thin technical solution with little real complexity, or testing that shows only normal data working rather than boundary and erroneous cases.

Active revision

For a project to build a booking system for a small tutor, write one measurable success criterion, describe one matching design decision, and give one test (with its class and expected outcome) and one evaluation point that all trace to that same criterion.

Active recall

Recall the key points — then reveal.

Sources: AQA A-level Computer Science 7517 specification (AQA)

Choosing a problem and working well#

StandardAQA 7517 4.14DfE GCE Computer Science - project practice

Iterative development

Fig. 2Rather than building the whole solution then testing once, develop in cycles: design a part, implement it, test it, refine it, and repeat for the next part. This keeps the project working, surfaces problems early, and builds the evidence trail the testing section needs.

The choice of problem shapes the whole project, and a good one has three features: it is real (there is an actual end user with a genuine need, who can be consulted and give feedback), it is of appropriate complexity (it can only be solved well with genuine programming techniques - data structures, algorithms, file or database handling - not a trivial script), and it is achievable in the time and with the skills available (ambition tempered by realism). A problem that is too simple cannot earn the technical-solution marks; one that is too ambitious will be left unfinished and untested.

Development should be iterative, as the previous chapter's lifecycle shows (a development cycle is shown opposite): build the solution in stages, testing each part as it is written rather than leaving all testing to the end, and refining the design when a stage reveals a problem. Incremental development keeps the project always in a working state, surfaces difficulties early while there is time to solve them, and produces the evidence trail the testing section needs. Regular consultation with the end user keeps the solution on target.

Good working practice protects the project. Use version control (or at least regular, dated backups) so that work is never lost and progress is recorded; keep documentation as you go rather than reconstructing it at the end, when detail is forgotten; and maintain the thread from success criteria to evidence throughout. Above all the work must be your own - properly acknowledging any libraries or sources used and being able to explain and justify every part of your solution.

The projects that do best combine a well-judged problem, steady iterative development with continuous testing, honest and thorough documentation, and a genuinely reflective evaluation. The NEA is the course's opportunity to show that you can take a real problem from analysis to a working, tested, evaluated solution - the essence of computer science as a practical discipline, and the skill the whole A-Level has been building towards.

Worked example

Judging whether a problem is suitable

Evaluate whether 'a program to store and search a personal book collection for a friend, with lending records' is a suitable NEA problem.

Real end user?
Yes - a specific friend with a genuine need who can state requirements and give feedback, satisfying the real-user criterion.
Appropriate complexity?
Yes - it needs persistent storage (a file or database), searching and sorting, data validation, and tracking of loans and returns, which exercise real programming techniques.
Achievable?
Yes - the scope can be sized to fit the time by fixing the core features (add, search, record a loan) and treating extras (statistics, reminders) as optional extensions.

Result: It is a suitable problem: a real user, genuine complexity (storage, search, validation, loan tracking) and a scope that can be sized to the available time - a sound basis for a strong project.

Typical mistakes

Choosing a problem with no real user or too little complexity, so the technical-solution and evaluation marks cannot be earned.
Leaving all coding, testing and documentation to the end, losing the evidence trail and the chance to fix problems early.

Active revision

A student proposes, as a project, a program that converts temperatures between Celsius and Fahrenheit. Explain why this is unlikely to be a suitable NEA problem and suggest how it could be extended, or replaced, to reach appropriate complexity for a real user.

Active recall

Recall the key points — then reveal.

Sources: AQA A-level Computer Science 7517 specification (AQA)

References & sources

Sources

Department for Education

GCE AS and A level subject content for computer science

AQA

AQA A-level Computer Science 7517 specification

Non-exam assessment – the computing practical project

3 sections~11 min reading time3 competenciesLevel Foundation 1 · Standard 2

Non-exam assessment – the computing practical project

Key points

How the NEA contributes to the final grade

Key points

Threading one requirement through all five sections

Key points

Judging whether a problem is suitable

Sources

Non-exam assessment – the computing practical project

Key points

How the NEA contributes to the final grade

Key points

Threading one requirement through all five sections

Key points

Judging whether a problem is suitable

Sources