Overview revision notes

Purpose of the project

The project gives students an opportunity to develop practical skills while solving a realistic problem or carrying out an investigation. It is also a learning experience: students work independently over an extended period, extend their programming skills and deepen their understanding of computer science. The most important assessed skill is the ability to create a programmed solution to a problem or investigation. This is reflected in the allocation of 42 of the 75 marks to the technical solution.

Selecting a suitable problem

There are no restrictions on the type of problem or on the development tools, including the programming language. However, two questions should guide selection:

1. Does the student already understand the field, or can they find out enough about it?
2. Is the proposed solution likely to demonstrate enough technical skill to achieve a mark that reflects the student's potential?

Possible directions include a data-processing solution such as a membership system, an optimisation problem such as rota production or shortest-path route finding, a simulation, a computer game, an artificial-intelligence application, a control system, a dynamic database-backed website, a mobile app, or an investigation involving data science or machine-learning algorithms.

A problem should also be sufficiently distinct from those chosen by other students in the centre. If projects are too similar, one student's work could inform another student's work. Teachers must record that this guideline has been followed.

Documentation structure

The project documentation is presented in this order:

1. Analysis — 9 marks: explain the problem or investigation that is being addressed.
2. Documented design — 12 marks: document the proposed design or plan.
3. Technical solution — 42 marks: show the programmed solution or technical outcome.
4. Testing — 8 marks: document testing of the work.
5. Evaluation — 4 marks: evaluate the completed work.

The total is 75 marks. The order of the documentation does not mean that the project must be developed through a rigid traditional systems life cycle.

Iteration and the critical path

Project development is likely to be iterative. Later discoveries can require earlier analysis, design or code to be revisited. Therefore, students are encouraged to prototype and write code early. A useful planning strategy is to identify the critical path: the part of the project on which everything else depends for a working system or a complete investigation result. Tackling this early can reveal important difficulties before too much work is built around an uncertain foundation.

Common errors

• Choosing an idea because it sounds interesting without checking whether it can demonstrate the necessary technical skill.
• Selecting a field without existing knowledge or a realistic way to find out about it.
• Treating analysis, design and coding as permanently separate stages rather than revisiting earlier work when discoveries are made.
• Delaying all prototyping and coding until the end.
• Choosing a problem so similar to another student's that the work could inform that student's work.
• Giving disproportionate attention to supporting documentation when the technical solution is the largest assessed section.