You are viewing a free preview of this lesson.
Subscribe to unlock all 4 lessons in this course and every other course on LearningBro.
The Non-Exam Assessment is the one component of OCR A-Level Computer Science where you control the marks over months rather than minutes. The programming project is worth 70 marks — 20% of your A-Level — and it is internally marked by your centre and externally moderated by OCR (the component is sometimes seen as H446/03 or H446/04 depending on the assessment route, but the project and its criteria are the same). It rewards a genuinely complex problem, solved in code you understand, documented across five marked sections: Analysis, Design, Development, Testing and Evaluation. This lesson is candidate-facing and practical: it maps each stage to its marks, shows what moves you up a band at every stage, and includes a worked Specimen that contrasts banded Mid-band → Stronger → Top-band write-ups so you can see exactly what a high-mark Analysis requirement, a high-mark design justification, and a high-mark evaluation paragraph actually look like.
The programming skills the project draws on — data structures, algorithms, OOP, file handling, recursion — are taught in the Programming Techniques, Data Structures and Algorithms courses. Here the focus is on turning those skills into a high-scoring documented project.
A theme runs through every section below: the moderator marks what they can see and verify in your report, not the cleverness in your head. Two candidates can write equally capable programs and score very differently because one evidences the journey — a real stakeholder, measurable requirements, justified design choices, an iterative build, cross-referenced tests, an honest evaluation — while the other submits a polished listing with a thin write-up. Everything that follows is about making your competence visible to the person awarding the marks.
This lesson covers the assessment of the NEA programming project, the practical-portfolio component of H446. The project is assessed in five sections, each with its own band descriptors:
The component is synoptic by nature: a strong project naturally exercises computational thinking (2.1), programming techniques (2.2) and standard algorithms (2.3) from the taught content, applied to a real problem. The bands reward coherence across the sections — an Analysis requirement should reappear in the Design test plan, be implemented in Development, be checked in Testing and be judged in Evaluation.
The five sections carry very different weights. Knowing the shape tells you where to invest effort.
| Section | Indicative weight | What it credits |
|---|---|---|
| Analysis | Around an eighth | A genuine problem, a real stakeholder, numbered measurable requirements |
| Design | Around a fifth | Justified data structures/algorithms, UI plan, a test strategy written first |
| Development (Technical Solution) | The largest share, around two-fifths | A complex, well-structured, working coded solution with iterative evidence |
| Testing | Around a ninth | Normal/boundary/erroneous evidence cross-referenced to requirements |
| Evaluation | Around a tenth | Balanced, requirement-by-requirement critical judgement |
Key Point: Development is the single largest section, but it is gated by the others. The top band for Development requires a solution whose complexity was justified in Design and driven by the Analysis — a clever program with a thin analysis cannot reach the highest band, because the moderator cannot see that the complexity was warranted by the problem. Treat the five sections as one coherent argument, not five separate documents.
Project choice sets the maximum mark you can reach before you write a line of code. The bands reward complexity that is genuinely required by the problem, so you need a problem that demands an algorithm or a non-trivial data structure.
| A strong project... | Why it lifts the ceiling |
|---|---|
| Has a real, contactable stakeholder | Gives authentic requirements and authentic evaluation feedback |
| Genuinely needs a complex structure (tree, graph, hash table) | Lets Development reach the top complexity band honestly |
| Involves real algorithmic processing (search, sort, pathfinding, optimisation) | Demonstrates the computational thinking the bands reward |
| Has clear, testable requirements | Makes Testing and Evaluation straightforward and evidenced |
| Fits the available time | Avoids the single biggest mark-killer: an unfinished solution |
| A weak project... | Why it caps the marks |
|---|---|
| A simple data-entry/CRUD app | No algorithmic complexity — Development cannot reach the top band |
| Mostly UI work with little logic | The bands reward computational complexity, not visual polish |
| Wildly over-scoped (e.g. a full 3D engine) | Almost certainly unfinished; an incomplete solution caps every section |
| Has no real stakeholder | Analysis and Evaluation become artificial and lose marks |
Project archetypes that reliably carry enough complexity (each is achievable in the time if scoped tightly):
Key Point: Scope down an interesting hard problem rather than up an easy one. A tightly scoped route-finder that is finished beats an ambitious game engine that is half-built — completeness is rewarded across every section, and an unfinished Technical Solution drags Testing and Evaluation down with it.
Before you commit to an idea, score it against the questions the top Development band implicitly asks. If you cannot answer "yes" to at least the first three, the idea will struggle to reach the highest band no matter how well you execute it.
| Self-check question | Why it matters |
|---|---|
| Does the problem require a non-trivial data structure (tree, graph, hash table, priority queue)? | Primitive-only solutions cannot reach the top complexity band |
| Does it involve a real algorithm (search, sort, pathfinding, optimisation, recursion)? | Algorithmic processing is what the bands reward as "complex" |
| Will the data structure and algorithm be justified by the problem, not bolted on? | Justified complexity scores; gratuitous complexity does not |
| Can a real stakeholder use and judge it? | Drives authentic Analysis and Evaluation |
| Can I finish a working version in the time, then enhance it? | Completeness underpins every section |
A useful test is the "elevator description": if you can describe the interesting computational part of your project in one sentence — "it finds the shortest delivery route over a road network" — the project almost certainly has the algorithmic core the bands want. If the one-sentence description is "it lets users add and view records," it does not, and you should add a computational dimension before you proceed.
The Analysis must show you genuinely understand the problem and have turned it into precise, measurable requirements. The discriminator between bands is specificity: vague requirements cannot be tested or evaluated, so they leak marks in three sections at once.
What a top-band Analysis contains:
Numbering requirements is not bureaucratic neatness — it is the thread that lets your Testing and Evaluation cite requirements (R3, R7) and so demonstrate coherence. The contrast below shows the same requirement at three quality levels.
| Band | Example requirement | Why it sits here |
|---|---|---|
| Mid-band | "R3: The system should find routes quickly." | Untestable — "quickly" has no measurable threshold |
| Stronger | "R3: The system must return the shortest route within 2 seconds." | Measurable time, but no stated input scale |
| Top-band | "R3: For a graph of up to 500 nodes, the system must return the shortest route (or report that none exists) within 2 seconds on the target hardware." | Measurable, bounded by input size, and covers the failure case |
Key Point: Write every requirement so that, months later, a tester could mechanically decide pass or fail with no judgement calls. That single discipline lifts Analysis and protects your Testing and Evaluation marks.
The top band wants requirements that visibly originate in the stakeholder interview, not requirements you invented and retro-fitted. Show the chain explicitly. Suppose your stakeholder — a delivery-firm dispatcher — says in the interview:
"Drivers waste time because the current tool just lists addresses; it never tells them the quickest order to visit them, and on a bad day they might have forty drops."
A weak Analysis records the quote and then states a generic requirement with no visible link. A top-band Analysis traces the quote into one or more measurable requirements:
| From the interview | Derived requirement (measurable) |
|---|---|
| "never tells them the quickest order" | R1: The system must compute a visiting order that minimises total travel distance for a given set of drops. |
| "on a bad day... forty drops" | R2: The system must handle at least 40 delivery locations and return an order within 5 seconds. |
| "the current tool just lists addresses" | R3: The system must accept a list of addresses as input and display the optimised route to the driver. |
This explicit derivation does three things the bands reward: it demonstrates genuine stakeholder engagement, it produces measurable requirements (40 drops, 5 seconds), and it gives you R1-R3 to cite later in Testing and Evaluation. It also quietly justifies the project's complexity — minimising a visiting order is a real optimisation problem, which licenses the advanced algorithm your Development section will showcase. Contrast the levels:
Design is where you commit your structures, algorithms, interface and test strategy on paper before coding. The bands reward justification: a data structure named without a reason scores far less than one chosen because of a stated property of the problem.
A top-band Design includes:
A justification reads like this — note how it ties a structure property to a problem need:
A weighted graph (adjacency list) is used to model the road network because the problem requires shortest-path computation between arbitrary locations; an adjacency list is preferred over an adjacency matrix because the network is sparse (each junction connects to only a few others), so the list uses memory proportional to the number of roads rather than to the square of the number of junctions.
A worked test-strategy table (built before coding) might begin:
| Test ID | Requirement | Input | Expected outcome | Type |
|---|---|---|---|---|
| T1 | R3 | Two directly connected nodes A, B | Route A → B with correct distance | Normal |
| T2 | R3 | Start and end with no connecting path | "No route found" reported | Erroneous |
| T3 | R3 | A 500-node graph | Completes within 2 seconds | Boundary |
Key Point: Every design decision should answer "why this, rather than the obvious alternative?" The act of naming the alternative and rejecting it for a stated reason is exactly the evidence the top band asks for.
This is the coded artefact, and the bands reward complexity executed well together with evidence that you built it iteratively. You reach the top band by combining genuinely advanced techniques with clean, modular, well-structured code — and by showing the solution evolving (prototypes, incremental features, problems solved along the way), not appearing fully formed.
Subscribe to continue reading
Get full access to this lesson and all 4 lessons in this course.