Choosing the project
A capstone project is either a programmed solution to a real problem or an investigation (for example, comparing two algorithms or testing a machine-learning model) supported by your own code.
- Pick a field you know: a hobby, a sport, a family business, a school club. You will understand the users and stay interested for months.
- Find a real user (client) who can tell you what they need and test your work.
- Example types: a simulation (traffic, epidemics, physics), a game with a computer opponent, an AI or machine-learning tool, a data-science analysis, a web or mobile app with a database.
- Enough technical depth: the project must let you show advanced skills: complex data structures (graphs, trees, hash tables, objects), non-trivial algorithms (search, optimisation, recursion), database design or networking. A simple quiz app with a list of questions is usually too thin.
- Right size: big enough to show skill, small enough to finish. Plan a core version first and extensions later.
Report sections and how marks are shared
Most schemes mark the same five parts. One common A-level scheme uses 75 marks:
| Section | Marks | Share | What goes in |
|---|---|---|---|
| Analysis | 9 | 12% | Problem statement, the user, research (interviews, existing systems), measurable objectives, any data or models needed |
| Documented design | 12 | 16% | Overall structure (module / class diagrams), data structures, file or database design, key algorithms in pseudocode or flowcharts, interface sketches |
| Technical solution | 42 | 56% | The full code listing, showing complex techniques and good coding style |
| Testing | 8 | 11% | Test plan and evidence (screenshots or video) that the system works |
| Evaluation | 4 | 5% | How well each objective was met, user feedback, improvements |
| Total | 75 | 100% |
Measurable objectives are the backbone. "Make it fast" is vague; "Search 10 000 records and show results in under 1 second" can be tested. Write each objective so you can later say clearly "met" or "not met".
Technical skill and coding style
Levels of technical skill
Mark schemes sort techniques into groups by difficulty. Roughly:
- Group A (most demanding): complex data models (cross-linked tables, objects with inheritance and polymorphism), graph or tree traversal, recursion, hashing, complex mathematical models, dynamic data structures you build yourself, client–server or networking code.
- Group B: simple OOP, multi-dimensional arrays, files or a simple database, records, sorting and searching with standard algorithms.
- Group C (basic): single-table data, simple arrays, linear search, straightforward input and output.
To reach high marks, the project must contain several Group A techniques that work and are your own.
Coding style
- Basic: meaningful names for variables and subroutines; consistent layout.
- Good: modular code (subroutines with parameters and return values), few global variables, constants named, useful comments.
- Excellent: cohesive modules (each does one job well), loosely coupled parts that talk through clear interfaces, defensive code that validates input and handles errors (try/except, range checks), and reusable, well-tested components.
Testing and evaluation evidence
Test plan
A good test table has: test number, what is tested (linked to an objective), test data, type of data, expected result, actual result, pass/fail and a reference to evidence.
- Normal data: typical valid input (age 15).
- Boundary data: values at the edge of what is allowed (ages 11 and 18 if 11–18 is valid).
- Erroneous data: invalid input that must be rejected (age −3, "abc").
Show evidence: annotated screenshots or a short video. When a test fails, record the bug, the fix and the re-test: this shows real development.
Evaluation
- Go through every objective from the analysis and judge it: fully met, partly met or not met, with evidence.
- Collect user feedback: let your real user try the system and quote their comments.
- Suggest realistic improvements and explain how you would make them.
Try it: write three objectives today
Choose a small problem at home (for example, tracking who does which chores). Write three objectives that can be tested, each with a number in it ("show this week's chores for up to 6 people on one screen"). For one objective, write a normal, a boundary and an erroneous test. Then use the free-play step to see which section your work belongs to.
Key formulas and definitions
- Stages: Analysis → Design → Technical solution → Testing → Evaluation
- Measurable objective = can be judged met / not met with evidence
- Section share = section marks ÷ total marks × 100%
- Test types: normal, boundary, erroneous
- Good modules: high cohesion, low coupling
- Defensive code = validate input + handle errors
- Evaluation = objectives + evidence + user feedback + improvements
Worked examples
1. Which is the better project idea: (a) a times-tables quiz with 20 fixed questions, (b) a route planner for a school bus using a graph and Dijkstra's algorithm?
(b). It has a real user, a graph data structure and a non-trivial algorithm, so it shows advanced technical skill. (a) is too simple.
2. Rewrite "The app should be easy to use" as a measurable objective.
For example: "A new user can book a lesson in at most 4 clicks, and 4 of 5 test users can do it without help."
3. Valid scores are 0 to 100. Give one normal, two boundary and one erroneous test value.
Normal: 57. Boundary: 0 and 100 (also 101 and −1 just outside). Erroneous: "ten" or −20.
4. Using the 75-mark scheme, what percentage of marks is the technical solution?
42 ÷ 75 × 100% = 56%.
Common mistakes
- Choosing a project that is too simple to show advanced techniques, or so big that it is never finished.
- Writing vague objectives ("user-friendly") that cannot be tested or evaluated.
- Testing only normal data and skipping boundary and erroneous data, or giving no evidence.
- Writing the evaluation as a story of what you did instead of judging each objective with evidence and user feedback.