The GCSE computer science programming project (the non-exam assessment, or NEA) is a compulsory ~20-hour coursework task where students design, build, test and evaluate a piece of software. Under current England exam board rules it must be completed, but — unlike most GCSE coursework — it is not directly marked toward the final grade; instead it prepares students for programming questions in the written exams.
What is the programming project?
The programming project, often called the NEA (non-exam assessment) or "practical programming task," is a substantial independent coding task set by exam boards such as AQA and OCR as part of GCSE Computer Science. Students choose or are given a programming brief, then work through planning, developing, testing, and evaluating a working solution — usually in Python, though some boards permit other languages.
It sits alongside the two written examination papers that make up the GCSE, and schools typically run it in Year 11, though some begin groundwork in Year 10.
Why it doesn't count toward the final grade
This is the detail that confuses most parents and students. Ofqual required exam boards to remove NEA marks from the final GCSE Computer Science grade after concerns about malpractice and inconsistent marking made the coursework element unreliable as an assessment measure. As a result:
- The programming project is compulsory to attempt — schools must timetable it and students must complete it.
- The marks are not submitted to the exam board and do not contribute to the overall grade.
- Instead, the skills practised during the project are assessed indirectly through dedicated programming questions in the written exam papers, which test the same skills (reading, writing, tracing and correcting code) under exam conditions.
In short: the project is where students learn practical programming; the exam is where that learning is graded. Skipping the project rarely helps — students who don't complete it consistently under-perform on the programming questions in the written papers.
How long does it take?
Exam boards recommend around 20 hours of timetabled class time to complete the project, spread across several weeks. This typically breaks down as:
| Stage | Approximate time |
|---|---|
| Analysis and design | 3–4 hours |
| Development (coding) | 10–12 hours |
| Testing and refinement | 3–4 hours |
| Evaluation and write-up | 2–3 hours |
Schools vary in how they schedule this — some run it as consecutive lessons over a half-term, others spread it across the year alongside topic teaching.
Choosing a task
Exam boards publish a small set of approved task briefs each year (sometimes an open task and a more structured one), and schools usually select which brief their class will attempt. Students rarely get to invent their own project from scratch — the brief provides a real-world style problem (for example, a simple booking system, a data-processing tool, or a small game) with a defined set of requirements.
A good approach when a task is set:
- Read the brief slowly and list every explicit requirement it states.
- Identify what data the program needs to store, and roughly how.
- Sketch the overall structure before writing any code — this pays off heavily later.
The develop-test-evaluate cycle
The project is built around an iterative cycle rather than a single "build it once" approach:
- Design — outline inputs, outputs, processes, and any data structures needed. Simple flowcharts or pseudocode are usually expected here.
- Develop — write the program in manageable chunks. Most students use Python, since it's the language taught in the vast majority of GCSE schemes of work, though some boards accept alternatives.
- Test — check each part of the program works as intended, using a mix of normal, boundary, and erroneous test data. Testing is not a final step — good practice is to test continuously as each function or feature is added.
- Evaluate — reflect honestly on what works, what doesn't, and what could be improved with more time. Evaluation is a skill in itself: examiners' written-exam questions increasingly reward students who can critique code, not just write it.
Repeating develop → test → evaluate in short cycles, rather than writing the whole program and testing at the end, produces both a more robust program and clearer documentation of the process.
Documentation
Even though the project itself isn't formally marked, most schools ask students to keep a short written record covering:
- The original brief and requirements
- Design notes (structure, key algorithms, any pseudocode)
- Evidence of testing (test cases and results)
- A short evaluation of the final solution
This documentation matters for two reasons: it's genuinely useful revision material for the written exam's programming questions, and many schools use in-class assessment of the project (separate from the exam board's rules) to gauge progress and predicted grades.
Exam board differences
The two main GCSE Computer Science providers in England — AQA and OCR — both run a non-exam programming task with broadly the same purpose and structure, though the fine detail (which languages are permitted, how briefs are published, and internal timing guidance) differs between them and can change from year to year. Schools and students should always check the current specification and any task-setting guidance published directly by their exam board rather than relying on previous years' briefs, since Ofqual-driven changes to non-exam assessment have altered the format more than once in recent years.
How students should approach it
- Don't rush the design stage. Time spent planning structure and logic before coding saves far more time later than it costs upfront.
- Test as you go, not just at the end — this catches errors while the relevant code is still fresh in your mind.
- Keep the brief open throughout and check work against it regularly; it is easy to drift from the original requirements.
- Use the project to consolidate exam skills. Because the written papers test the same programming concepts, treating the NEA as active revision — not just a separate task to get through — pays off directly in exam performance.
- Ask for help early if stuck on a specific bug or concept; leaving problems unresolved compounds as the project grows in complexity.
Frequently asked questions
Does the GCSE computer science programming project count toward my final grade?
No. Under current rules in England, the marks from the non-exam assessment (NEA) are not submitted to the exam board and do not contribute to the final GCSE grade. It must still be completed, because the practical skills it develops are examined separately through programming questions in the written papers.
How long is the GCSE computer science programming project?
Exam boards recommend around 20 hours of class time, typically spread across several weeks in Year 11 (sometimes starting in Year 10), covering design, development, testing and evaluation.
What programming language is used for the NEA?
Most schools use Python, as it is the language most commonly taught across GCSE Computer Science schemes of work, though exam boards may permit other languages depending on their specification — check with your teacher or the relevant exam board's current guidance.
If it isn't graded, why does the programming project matter?
Because the written exam papers include dedicated programming questions that test the same skills — reading, writing, tracing and correcting code — the project is effectively hands-on practice for marks that do count. Students who skip or rush the NEA typically underperform on those exam questions.
For tailored exam preparation support across KS3 subjects, see aitutors.me.