Overview study guide

1. Reason from the purpose, not from the format

The project is not simply a report. Its central purpose is to create a programmed solution to a realistic problem or to carry out a computer-science investigation. A useful first question is therefore: What will the finished programmed solution or investigation enable me to demonstrate? The answer should connect the problem to practical programming and to a sufficient degree of technical skill. Supporting documentation remains important, but the mark distribution gives the technical solution 42 of 75 marks, while analysis, documented design, testing and evaluation together account for the remaining 33 marks.

2. Test an idea against the two selection questions

Suppose a student considers creating a membership system for an organisation. The idea is not automatically suitable merely because it is a familiar type of application. The student should reason in two stages:

• Knowledge access: Do they already know enough about the organisation's field, or are they in a position to find out about it?
• Technical opportunity: Is the proposed solution likely to provide enough scope to demonstrate the necessary technical skill?

If the answer to either question is weak, the student should reconsider the problem, obtain relevant understanding or refine the proposed solution. The same reasoning applies to a simulation, optimisation problem, computer game, artificial-intelligence application, control system, dynamic website, mobile app or investigation involving data science or machine-learning algorithms.

3. Distinguish documentation order from development order

The final documentation has a required presentation order: analysis, documented design, technical solution, testing and evaluation. This is an assessment structure, not a requirement to complete development through a rigid traditional systems life cycle. In actual project work, a discovery made while coding may require the analysis or design to be revisited. A discovery during testing may also change the design or implementation. This is iterative development: earlier work is refined in response to later understanding.

A strong planning explanation should therefore distinguish between how the evidence is presented and how the project is developed. The evidence can be organised in the five required sections even when the work itself has moved backwards and forwards between activities.

4. Apply the critical-path strategy

Identify the part of the project that everything else depends on for a working system or a complete investigation result. This is the critical path. For example, in a proposed dynamic website, the essential dependency might be the part on which the rest of the working system relies; in an optimisation investigation, it might be the part required to obtain a complete investigation result. The precise critical path depends on the chosen problem. The reasoning is always the same: find the dependency whose failure would prevent the rest of the project from achieving its purpose, then investigate it early.

This is why early prototyping and coding are recommended. An early prototype can expose whether the central dependency is workable while there is still time to revisit the analysis or design. It also prevents the student from building extensive supporting work around an untested core.

5. Use the assessment sections as a self-check

Before submission, ask:

• Analysis: Is the problem or investigation clearly identified?
• Documented design: Is the intended solution or investigation plan documented?
• Technical solution: Is there a programmed solution or technical outcome that demonstrates the project's potential?
• Testing: Is testing documented rather than merely implied?
• Evaluation: Is the completed work evaluated?

These questions do not require the project to have been developed linearly. They check whether the final documentation covers all five assessed sections in the required order.

Self-check prompts

1. What existing knowledge or opportunity to find out about the field supports the chosen problem?
2. What aspect of the idea demonstrates the necessary degree of technical skill?
3. What is the critical path, and what would depend on it?
4. Which earlier decisions might need revisiting after prototyping or coding?
5. Can the final document be organised into analysis, documented design, technical solution, testing and evaluation without pretending that development followed a rigid sequence?
6. Is the problem sufficiently different from other students' problems to avoid one student's work informing another's?