4.14.1.1–4.14.1.3, 4.14.4 - Independent projects, suitable problems and evidence

Real problems and investigations

A project gives you time to develop a programmed solution or investigate a computing problem that matters to identifiable users or recipients.

A solution project creates a system to meet requirements: for example, a membership system for an organisation, a route finder, a computer game, a database-driven dynamic website, a mobile app or a device-based control system. An investigation uses programming to explore a question: for example, comparing simulations, rendering a three-dimensional scene, analysing lawful public data or studying a machine-learning algorithm. A business/scientific simulation or an artificial-intelligence application may fit either approach, depending on its purpose. These are possible directions, not an approved list of guaranteed high-mark topics.

Ask two questions before committing. Do you already understand the field, or can you obtain reliable knowledge about it? Will the problem give you scope to demonstrate the technical skill appropriate to your potential? A project about a sport you understand may have accessible users and meaningful data. A large medical prediction system may require expertise, permissions and evidence you cannot realistically obtain. Interest helps sustained work, but it does not replace feasibility.

Identify the recipient of an investigation too. “Compare two search strategies on controlled datasets for a computing club” gives a question and audience; “research search algorithms” is too open. Define what will be programmed, varied, measured and concluded. A report assembled from existing sources without a meaningful programmed investigation misses the central practical purpose.

Problems within a centre should be sufficiently different that one student's work does not inform another student's solution to the same problem. Discuss suitability and originality with the teacher, who records this on the Candidate Record Form and can consult the AQA adviser if necessary. You still produce your own analysis, design, code, testing and evaluation.

A-level standard and feasible scope

The right project is challenging enough to demonstrate substantial computing skills while remaining possible to complete and explain independently.

A very simple calculator or a static page may offer too little problem-solving opportunity. A vast unfinished system can also fail to show a coherent solution. Scope the core behaviour and the technical decisions it requires, then check the official technical-skill and coding-style guidance with your teacher. Named techniques and tidy code are evidence only in relation to the actual problem; inserting a complex technique that serves no purpose does not automatically earn marks.

For example, a route-planning investigation might model locations and weighted links, implement a suitable search, vary input sizes or constraints and test results against cases with known outcomes. Each element has a purpose. Adding unrelated encryption simply to claim another technique makes the design harder to justify.

AQA restricts marks when a selected problem is below A-level standard. For sections other than the technical solution, the specification says to shift the assessed standard down by two marking levels; evaluation is reduced by two marks, with the lowest level used where the shift cannot be made. The technical solution already takes the problem's standard into account through its criteria. This is a formal teacher marking rule, not a way for NovaLearn to calculate an NEA award. It is a reason to resolve unsuitable scope early.

Iteration and the critical path

Begin investigating the dependency that could prevent the whole project from working, rather than postponing it until the interface is polished.

For a sensor controller, obtaining trustworthy sensor readings may be the critical dependency. For a route finder, the core route computation must work with the available data. Prototype that risky behaviour early. If a library cannot read the required data format or a proposed method is too slow, early evidence leaves time to revise the design and scope.

Development is normally iterative. Research can change the requirements; a prototype can reveal a missing case; testing can require a design change. Revisit earlier decisions and keep the current objectives and design consistent with the solution. Starting code early is compatible with analysis and design: the small prototype answers a defined question, and its results inform the next decision.

The order in which documentation is presented is not a demand for a rigid waterfall process. Keep a concise development record so a reader can see which evidence led to a change. An attractive finished interface is weak progress if the underlying operation on which everything depends has never been demonstrated.

Five assessed sections and concise evidence

The formal NEA framework gives greatest weight to the programmed technical solution and expects supporting documentation to be clear and concise.

The technical solution's 42 marks include 15 for completeness and 27 for techniques used. This weighting explains why a lengthy report cannot substitute for your own meaningful programmed achievement. For marking, present documentation in the section order shown, although the development work may have moved repeatedly between them.

Keep evidence selective but sufficient: an objective reference, a justified design decision, a representative test with actual output and a reasoned evaluation are more useful than dozens of unexplained screenshots. Avoid duplicating the same information across sections. Concise means removing irrelevant repetition while keeping enough detail for a third party to understand and verify the work.

The short exercises here use original formative point rubrics. Their marks are practice feedback, not a scaled version of the 75-mark NEA grid. Your centre supervises, authenticates and marks assessed work; an automated tutor cannot certify your independent achievement.