Programming Project Guidance (H446/03 NEA)

This lesson covers the OCR A-Level Computer Science Non-Exam Assessment (NEA) — the programming project worth 70 marks and 20% of your A-Level. It explains how to choose a project, structure your analysis, design your solution, implement it effectively, test it thoroughly, and write a strong evaluation. We also break down the mark scheme and highlight common mistakes that cost students marks.

---

Overview of the NEA

The NEA is a substantial programming project that you complete during your A-Level course. It is internally assessed by your teacher and externally moderated by OCR. The project must demonstrate your ability to analyse a problem, design a solution, implement it in code, test it, and evaluate your work.

Feature	Detail
Component code	H446/03
Total marks	70
Weighting	20% of A-Level
Assessment	Internal assessment, external moderation
Language	Any appropriate programming language
Approximate time	Centres typically allocate 40-60 hours

---

Mark Scheme Breakdown

The NEA is marked across five assessment sections:

Section	Marks	Percentage of NEA	What It Covers
Analysis	10	14%	Understanding the problem, stakeholder needs, requirements
Design	15	21%	Data structures, algorithms, UI design, test strategy
Technical Solution	30	43%	The actual coded program — quality, complexity, techniques used
Testing	8	11%	Evidence of testing, including normal, boundary, and erroneous data
Evaluation	7	10%	Critical review of the solution against requirements

Key Point: The Technical Solution section is worth 30 marks — nearly half of the NEA total. However, you cannot earn full marks in this section without a strong Analysis and Design to justify your implementation decisions.

---

Choosing a Project

Your project choice is one of the most important decisions you will make. A good project is complex enough to demonstrate advanced programming skills but achievable within the time available.

Characteristics of a Good Project

Good Choice	Why
Has a real stakeholder (client) you can interview	Provides genuine requirements for the Analysis section
Requires at least one complex data structure (trees, graphs, hash tables)	Demonstrates the data structure knowledge expected at A-Level
Involves algorithmic problem-solving (searching, sorting, pathfinding, optimisation)	Shows computational thinking
Has a clear, testable set of requirements	Makes testing and evaluation straightforward
Can be completed in 40-60 hours	Avoids an over-ambitious scope that leads to an incomplete project

Characteristics of a Poor Project

Poor Choice	Why
A simple CRUD application with no algorithmic complexity	Does not demonstrate A-Level programming skills
A project where 90% of the work is UI design rather than code	The mark scheme rewards programming complexity, not visual design
A game that is too complex to finish (e.g., a full 3D engine)	An incomplete project cannot earn high marks in any section
A project with no real stakeholder	Makes the Analysis section artificial and weak

Example Project Ideas

• A route-finding application using Dijkstra's algorithm or A* search on a graph
• A chess or draughts game with an AI opponent using minimax with alpha-beta pruning
• A data analysis tool that processes CSV files, uses sorting and searching, and produces statistical summaries
• An encryption/decryption tool implementing multiple cipher algorithms
• A scheduling system using priority queues and constraint-based logic

---

Analysis (10 marks)

The Analysis section requires you to demonstrate a thorough understanding of the problem you are solving.

What to Include

1. Stakeholder identification and interview (2-3 marks)

• Identify who your client/end-user is
• Conduct an interview (include the questions and responses)
• Extract requirements from their answers

2. Problem definition (2-3 marks)

• Clearly state what the problem is
• Explain why a computational solution is appropriate
• Identify what currently exists (if anything) and why it is insufficient

3. Requirements specification (3-4 marks)

• List specific, measurable, testable requirements
• Use a numbered list so you can refer back to them during testing and evaluation
• Separate functional requirements (what the system must do) from non-functional requirements (performance, usability, reliability)

Example requirements:

ID	Requirement	Type	Priority
R1	The system must find the shortest route between two locations	Functional	Must have
R2	The system must display the route on a visual map	Functional	Should have
R3	Route calculation must complete within 2 seconds for up to 500 nodes	Non-functional	Must have
R4	The user interface must be usable without training	Non-functional	Should have

4. Success criteria (1-2 marks)

• Define how you will know the project is successful
• Link success criteria directly to the requirements

Common Analysis Mistakes

Mistake	Impact
Fabricating a stakeholder interview	Moderators can tell when interviews are not genuine; this undermines the entire Analysis
Writing vague requirements like "the system should work well"	Untestable requirements cannot be evaluated, losing marks in Testing and Evaluation too
Not numbering requirements	Makes cross-referencing in Testing and Evaluation difficult

---

Design (15 marks)

The Design section shows the examiner your plan before you start coding.

What to Include

1. Data structures and justification (3-4 marks)

• Describe the data structures you will use (arrays, linked lists, trees, graphs, hash tables, etc.)
• Explain WHY each data structure is appropriate for the task
• Include diagrams showing the structure (e.g., entity relationship diagrams, tree diagrams)

2. Algorithm design (4-5 marks)

• Write pseudocode or flowcharts for the key algorithms
• Include the main processing logic, not just simple input/output
• Show algorithmic complexity awareness (Big O)