The Programming Project (NEA)
How the 70 mark project is actually marked, what separates a high band analysis from an average one, and the mistakes that cost the most marks.
Analysis and design
The project is worth 70 marks and around 20 per cent of the A Level. It is marked in four sections.
Analysis, 10 marks
Problem identification. Describe a problem that is genuinely suitable for a computational solution, explaining why it is solvable computationally and why it is worth solving.
Stakeholders. Identify who will use the solution and who else is affected, describing each specifically and explaining how the solution addresses their particular needs. Generic stakeholders lose marks.
Research. Examine existing similar solutions, identifying what each does well and where it falls short, and interview or survey your stakeholders. Evidence the research: include the questions asked and the answers received.
Requirements. Produce specific, measurable, testable requirements, covering hardware and software requirements too.
Success criteria. Each must be independently testable, because you will evaluate against them at the end. "The system will be easy to use" is not testable. "A new user can add a booking in under 60 seconds without assistance" is.
Design, 15 marks
Decomposition. Break the problem down and show the structure, typically as a structure diagram or a hierarchy chart.
Algorithms. Present the key algorithms as pseudocode or flowcharts, with enough detail that a competent third party could implement them.
Usability. Show interface designs and explain how they address the needs of specific stakeholders, referring to usability principles rather than simply presenting screens.
Data structures. Justify each choice against the operations required, not merely state it.
Validation. Specify validation for every input.
Test data. Plan tests using normal, boundary and erroneous data, with the expected result stated for each before development begins.
Justification. Every design decision must be explained in terms of the requirements it serves, and every algorithm must be detailed enough to implement without further invention.
- Analysis, design, development, testing and evaluation, in that order.
- Each stage has its own evidence.
- Testing leads back to development, so the project iterates.
- Collect the evidence as you work, not at the end.
Development, testing and evaluation
Development, 25 marks
The largest section, and it rewards evidence of an iterative process, not merely a finished program.
Work in cycles, and for each one:
- State what you are building and why it comes next
- Show annotated code, explaining the technique used and why it was chosen
- Show it working, with screenshots including the input used
- Test it, including the cases where it should fail
- Review it, describing what worked, what did not, and what you changed as a result
- Show any refinement made in response
Technical skill is assessed on the difficulty of what you attempt as well as its correctness. Complex data structures, recursion, file or database handling, OOP where appropriate, and effective algorithms all count. A perfectly working but trivial program cannot reach the top band.
Code quality is assessed too: meaningful identifiers, sensible modular structure, comments explaining why, consistent style, and no unnecessary duplication.
Screenshots taken during development, dated review notes, and version history. Reconstructing this at the end is obvious to a moderator and takes far longer than doing it properly.
Testing, 10 marks
Testing during development shows each component working as it was built, and is evidenced within the development cycles.
Post development testing tests the complete system against the test plan written during design, with evidence for every test, and follow up evidence showing that any failure was corrected.
Usability testing involves real stakeholders using the system while you observe, recording what they struggled with and what you changed as a result.
Cover normal, boundary and erroneous data for every input, and test the requirements, not just the code you happen to have written.
Evaluation, 10 marks
Against success criteria. Take each criterion in turn, present the evidence, and state honestly whether it was fully met, partly met or not met.
Usability. Report what stakeholders said and did, including the negative feedback, and describe what you changed.
Maintenance and development. Describe specific limitations of the finished system and realistic further developments, explaining how each would be implemented.
An honest evaluation identifying real weaknesses scores far more highly than one claiming everything worked perfectly. Moderators read hundreds of these, and an evaluation with no criticism reads as an evaluation that was never actually done.
The five most costly mistakes
- Choosing a problem that is too simple. The band is capped by the difficulty attempted.
- No real stakeholder. Without one, the analysis, usability and evaluation sections all lose marks.
- Evidence gathered at the end. It is always visible, and it is worth many marks.
- Success criteria that cannot be tested. These make the evaluation impossible to write well.
- A dishonest evaluation. Claiming everything worked perfectly is the surest way to lose evaluation marks.
- Four levels: unit, integration, system and acceptance. Unit tests are many and fast, acceptance tests are few and cover the most.
- Black box: test the inputs and outputs without seeing the code.
- White box: test every path through the code.
Key terms you must be able to define
- Stakeholder
- A person who will use or be affected by the solution, identified specifically.
- Success criterion
- A specific, independently testable statement of what the finished system must achieve.
- Decomposition
- Breaking the problem into sub problems, evidenced with a structure diagram.
- Iterative development
- Building in cycles of implement, test and review, with evidence at each cycle.
- Post development testing
- Testing the complete system against the plan written during the design stage.
- Usability testing
- Observing real stakeholders using the system and recording what they struggle with.
- Boundary data
- Test data at the very edge of the acceptable range, where errors are most likely.
- Erroneous data
- Test data of the wrong type entirely, which the system should reject.
Flashcards
Say the definition out loud before you flip the card. Retrieving it from memory is what builds recall, reading it again is not.
Reach the top grade on this topic
- Choose a problem with genuine technical depth: real data structures, algorithms, persistence
- Secure a real stakeholder early and keep documented contact throughout
- Write success criteria that can each be objectively tested with a yes or no
- Capture evidence at the moment it happens, never afterwards
- Justify every design decision against a specific requirement
- Evaluate honestly, and describe what you would change and why
Mistakes that cost marks here
- Choosing a problem too simple to demonstrate technical skill, capping the mark band.
- Inventing a stakeholder rather than working with a real one.
- Writing success criteria such as 'the system will be user friendly', which cannot be tested.
- Producing a finished program with no evidence of the iterative process behind it.
- Testing only the paths that work.
- Writing an evaluation claiming everything succeeded perfectly.
The single most common reason for losing marks on the project is not weak code. It is evidence: excellent work that was never documented as it happened, and cannot be reconstructed afterwards.
Knowledge check
Exam-style questions
Five written questions in the style of the real paper. Write a full answer, then let the marker check it against the mark scheme.
- LThe evaluation assesses the finished system against them
- LA vague criterion cannot be shown to have been met or not met
- LA measurable criterion allows objective evidence to be presented
The success criteria written during the analysis stage are what the finished system is evaluated against, so they determine whether the evaluation can be written convincingly at all. A criterion such as the system will be easy to use is subjective, and there is no evidence that could settle whether it was achieved, so the evaluation of it becomes an unsupported opinion. A measurable criterion such as a new user can complete a booking in under sixty seconds without assistance can be tested directly by observing a real user with a stopwatch, which produces objective evidence that can be presented and judged. Writing testable criteria at the start therefore makes both the testing and the evaluation possible, and it also clarifies during design exactly what the system has to achieve.
- LA statement of what is being built and why it comes next
- LAnnotated code explaining the techniques used
- LEvidence of it working, such as screenshots with the input used
- LTesting of that component including cases that should fail
- LA review describing what worked, what did not and what was changed
Each development cycle should begin with a clear statement of what is being built in that iteration and why it is the sensible next step, which demonstrates that the development was planned rather than arbitrary. The code produced should then be presented with annotation explaining the techniques used and why they were chosen over alternatives, rather than simply pasted in. Evidence that it works must follow, in the form of screenshots that show both the input given and the output produced, since a screenshot of output alone proves nothing. That component should then be tested, including deliberately with data that should be rejected, and the results shown. Finally the cycle should close with a review that honestly describes what worked, what did not, and what was consequently changed, with evidence of the refinement. It is this review and refinement, repeated across cycles, that evidences a genuinely iterative process rather than a single linear attempt.
- LStakeholders provide the requirements the system must meet
- LTheir needs justify design decisions during the design stage
- LThey can be observed using the system during usability testing
- LThe evaluation depends on their feedback and on the criteria derived from them
Real stakeholders matter because three separate sections of the project depend on them. In analysis, they are the source of the requirements: interviewing them establishes what the system actually needs to do rather than what the developer imagines, and the success criteria are derived from those needs. In design, their particular characteristics justify decisions, so choosing large controls and minimal text can be defended by reference to the specific users rather than being asserted as good practice in general. In testing and evaluation, they are the people who use the system while the developer observes, which reveals usability problems the developer cannot possibly see because they already know where everything is, and their feedback is the evidence against which the finished system is judged. A project with an invented stakeholder has nothing genuine to test against and loses marks in all of these areas.
- LEach success criterion is addressed in turn with evidence
- LIt states whether each was fully met, partly met or not met
- LUsability feedback from stakeholders is reported, including negative feedback
- LLimitations and possible further developments are described
- LAn evaluation with no identified weaknesses appears not to have been genuinely carried out
The evaluation should work through each success criterion established during analysis in turn, presenting the evidence relating to it and stating clearly whether it was fully met, partly met or not met, with an explanation where it fell short. It should then report the usability feedback obtained from stakeholders who actually used the system, including the criticism they gave and what was changed in response to it. Finally it should describe the limitations of the finished system honestly, and set out realistic further developments with an explanation of how each would be implemented. Honesty scores more highly because the marks are awarded for the quality of the judgement rather than for the quality of the outcome being described. An evaluation claiming that every criterion was fully met and every user was entirely satisfied is not credible, since no software project achieves that, and it demonstrates either that the evaluation was not genuinely carried out or that the student cannot identify weaknesses in their own work. Identifying a specific shortcoming, explaining why it occurred and describing precisely how it would be addressed shows exactly the critical understanding the mark scheme rewards.
- LIt must be genuinely solvable by a computational approach
- LIt must have sufficient technical depth to demonstrate skill
- LIt should involve data structures, algorithms and persistence rather than trivial operations
- LIt must have real stakeholders whose needs can be researched
- LIt must be achievable within the available time
A suitable problem must first be genuinely amenable to a computational solution, meaning it can be defined precisely, the necessary data is obtainable and the rules governing it can be stated explicitly. It must then have enough technical depth to allow the student to demonstrate real skill, because the mark band is capped by the difficulty of what is attempted, so a flawlessly implemented but trivial program cannot reach the highest marks. In practice this means the problem should naturally require non trivial data structures, meaningful algorithms, validated input and some form of persistent storage, rather than being a sequence of simple calculations. There must be real stakeholders who can be interviewed at the analysis stage and observed at the testing stage, since the requirements, usability testing and evaluation all depend on them. Finally the problem must be achievable within the time available, because an over ambitious project that is left incomplete loses marks across development, testing and evaluation, and a well executed project of moderate ambition scores far better than an unfinished one of great ambition.