Notes · Computer ScienceUK · A-Levels

Systematic approach to problem solving

Producing good software is not a matter of jumping straight to code but of following a disciplined process from understanding the problem to evaluating the finished solution. This chapter sets out that systematic development lifecycle - analysis, design, implementation, testing and evaluation - and the techniques within it: decomposition and abstraction, algorithm and data design, and a rigorous testing strategy with well-chosen test data. These skills underpin both Paper 1 and the non-exam assessment.

3 sections~11 min reading time3 competenciesLevel Standard 3

T·131313 / 14

Exam profile

AO1 · Know the stages of the development lifecycle and the classes of testing and test dataAO2 · Apply decomposition and abstraction to a problem and design appropriate test dataAO3 · Design, develop and evaluate a solution systematically against its requirements

Operators:analysedesigndecomposetestevaluatejustify

basic level

AS-Level expects the outline of the development stages and the idea of testing with suitable data.

higher level

The full A-Level expects a systematic, evidenced approach - decomposition, abstraction, algorithm and data design, and a testing strategy with normal, boundary and erroneous data - as applied throughout the NEA.

Depth

Text

Contents · 3 sections

Systematic approach to problem solving

The stages of problem solving#

StandardAQA 7517 4.13.1DfE GCE Computer Science - problem solving

The systematic development lifecycle

Fig. 1Analysis, design, implementation, testing and evaluation follow in order, but the process is iterative - testing and evaluation feed back into earlier stages, so development cycles rather than running once straight through.

Software is developed through a systematic lifecycle of stages, each building on the last (shown opposite). Analysis establishes what the problem is and what the solution must do: understanding the problem and the end user, gathering requirements, and identifying the inputs, processes and outputs. Design decides how the solution will meet those requirements - the algorithms, the data structures, the interfaces - in enough detail to be built. Implementation writes the code. Testing checks the solution works correctly and robustly. Evaluation judges the finished product against the original requirements and success criteria.

The stages are not strictly linear but usually iterative: testing reveals faults that send you back to implementation or even design; user feedback in evaluation prompts refinement. This is why the lifecycle is often drawn as a cycle, and why real development revisits earlier stages rather than marching once through them. A good process makes this iteration deliberate - fixing the design when testing exposes a flaw, rather than patching over it - which is exactly the disciplined approach the NEA rewards.

Central to analysis is establishing measurable success criteria - concrete, testable statements of what a successful solution will do ('the system shall validate that a mark entered is an integer between 0 and 100') rather than vague aims ('the system should be easy to use'). Measurable criteria give something definite to design towards and, crucially, to evaluate against at the end, so the whole process is anchored to agreed goals from the outset.

Following the lifecycle matters because skipping stages is the commonest cause of software failure: coding without proper analysis produces a solution to the wrong problem; coding without design produces tangled, unmaintainable code; shipping without thorough testing produces unreliable software. The discipline of moving through analysis, design, implementation, testing and evaluation - and iterating - is what separates a professional solution from a hack, and it is the backbone of the practical project.

Worked example

Turning an aim into measurable success criteria

A client wants a quiz program that is 'good and fair'. Rewrite this as three measurable success criteria suitable for evaluation.

Make each aim testable
Replace vague words with concrete, checkable statements tied to inputs, processes and outputs.
Draft the criteria
1: The program shall present exactly 10 questions drawn at random from a bank of at least 50. 2: The program shall award one mark per correct answer and display the total out of 10 at the end. 3: The program shall reject a non-numeric answer with a clear message and re-prompt.
Check measurability
Each can be objectively tested pass/fail during evaluation, unlike 'good and fair'.

Result: Three measurable criteria replace the vague aim, giving definite targets to design towards and to evaluate the finished program against.

Typical mistakes

Treating the lifecycle as a one-way sequence - testing and evaluation routinely send development back to design or implementation.
Writing vague, unmeasurable requirements ('user-friendly') that cannot be tested or evaluated against.

Active revision

A sports club wants a program to record members and their subscription payments. List the stages of development you would follow, and write two measurable success criteria the finished program could be evaluated against.

Active recall

Recall the key points — then reveal.

Sources: GCE AS and A level subject content for computer science (Department for Education) · AQA A-level Computer Science 7517 specification (AQA)

Decomposition, abstraction and design#

StandardAQA 7517 4.13.2DfE GCE Computer Science - design

A hierarchy (structure) chart

Fig. 2The whole task at the top is decomposed into main sub-tasks, each broken down further until every leaf is simple enough to code directly. The chart maps onto a program of well-named subroutines, each independently designed and tested.

The design stage relies on the two computational-thinking tools met earlier. Decomposition breaks the whole problem into smaller sub-problems, each of which can be understood, designed and tested on its own, and then broken down further until each piece is simple enough to code directly. The result is naturally drawn as a hierarchy (structure) chart (shown opposite), with the whole task at the top and increasingly specific sub-tasks beneath - which maps directly onto a program of well-named subroutines.

Abstraction complements decomposition by hiding the detail of each sub-problem behind a clear interface, so that when designing one part you can treat the others as solved black boxes described by what they do, not how. Together, decomposition and abstraction let a designer reason about a large system one manageable piece at a time - the only way complex software is ever built - and they make the pieces independently testable and reusable.

Design produces concrete artefacts. Algorithms are designed in a language-neutral form - pseudocode, flowcharts or structure charts - so the logic can be checked before coding. Data design chooses the data structures and, for a database-backed solution, the tables, keys and validation. Interface design plans the inputs and outputs and how the user interacts. Good design records enough detail that a competent third party could implement the solution from the design alone - the standard the NEA explicitly sets.

The payoff of investing in design is code that is modular, maintainable and testable: each subroutine does one well-defined job, changes are localised, and each piece can be tested in isolation. Skipping design in favour of coding 'organically' produces tangled code where everything depends on everything else. Being able to decompose a stated problem into a sensible hierarchy and to justify the design decisions is examined directly and is fundamental to the project.

Worked example

Decomposing a problem

Decompose the task 'run a quiz' into a hierarchy of sub-tasks, and explain how abstraction helps.

Top level
The whole task 'run a quiz' splits into main sub-tasks: set up the quiz, ask questions, and report the result.
Break down further
'Ask questions' decomposes into: select a question, display it, read the answer, check the answer, update the score - each small enough to become a subroutine.
Apply abstraction
When designing 'check the answer' you can treat 'select a question' as a solved black box that returns a question and its correct answer, ignoring how it does so.

Result: A two-level hierarchy of subroutines emerges. Abstraction lets each sub-task be designed against the interfaces of the others without knowing their internals - the key to managing complexity.

Typical mistakes

Producing a decomposition that is too shallow (a single monolithic task) or in which sub-tasks overlap rather than being distinct.
Designing at too vague a level to implement - the design must be detailed enough for a competent third party to build from.

Active revision

Decompose the problem 'manage a small library's loans' into a hierarchy of at least six sub-tasks arranged under two or three main tasks, and explain how abstraction lets you design the 'record a loan' sub-task without yet designing the others.

Active recall

Recall the key points — then reveal.

Sources: AQA A-level Computer Science 7517 specification (AQA)

Testing and evaluation#

StandardAQA 7517 4.13.3DfE GCE Computer Science - testing

Classes of test data

Fig. 3A robust test plan covers all three classes. Boundary tests at the very edges of validity catch off-by-one and wrong-operator faults; erroneous tests confirm the program rejects bad input gracefully rather than crashing. The examples are for a field accepting an integer from 0 to 100.

Testing checks that a solution works correctly and robustly, and it must be systematic - guided by a test plan that lists, for each test, the input, the expected result and the actual result, with evidence. The purpose is not to show the program works on easy cases but to try to make it fail, so that faults are found and fixed before release. Well-chosen test data falls into three classes (shown opposite): normal (typical valid data the program should accept and process correctly), boundary (values right at the edges of validity - the program should accept those just inside and reject those just outside), and erroneous (invalid data the program should reject gracefully rather than crash on).

Boundary testing is especially productive because faults cluster at the edges - the off-by-one errors and wrong comparison operators from the programming chapter. For a field accepting an integer from 0 to 100, the boundary tests are 0 and 100 (must be accepted) and -1 and 101 (must be rejected); the boundaries, not a value like 50 in the middle, are where a wrong

<

versus

\leq

shows up. Designing the right test data - covering all three classes and every requirement - is a core, examinable skill.

Testing is also classified by approach. Black-box testing checks inputs against expected outputs without regard to the internal code - testing what the program does against its specification. White-box (structural) testing uses knowledge of the code to ensure every path, branch and condition is exercised - testing how it does it. The stages of testing progress from alpha testing (in-house, during development), through beta testing (by a limited group of real users before release), to acceptance testing (by the client, to confirm the solution meets the agreed requirements).

Evaluation is the final judgement of the finished solution against the original success criteria, honestly assessing what works, what does not, and how well the solution meets the user's needs - ideally with independent feedback from the actual end user. A good evaluation is specific and balanced: it takes each success criterion in turn, states whether it was met with evidence, acknowledges limitations, and proposes realistic improvements. This closes the loop back to analysis and is where the reflective, evaluative marks are earned.

Worked example

Designing test data for a validation rule

A program accepts an age as a whole number from 18 to 65 inclusive. Design test data covering normal, boundary and erroneous cases.

Normal
A typical valid value well inside the range: 30 - should be accepted.
Boundary
The exact edges: 18 and 65 should be accepted; 17 and 66 (just outside) should be rejected. These catch a wrong < versus <= comparison.
Erroneous
Data of the wrong type or form: 'thirty', an empty entry, and 25.5 (not a whole number) - each should be rejected with a clear message, not crash the program.

Result: A complete test set: normal 30; boundary 18, 65 (accept) and 17, 66 (reject); erroneous 'thirty', empty, 25.5. Covering all three classes, especially the boundaries, is what makes testing rigorous.

Typical mistakes

Testing only normal data and omitting boundary and erroneous cases, where most faults actually hide.
Choosing boundary values that are not truly at the edge (e.g. testing 50 instead of 0 and 100 for a 0-100 range).

Active revision

A field must accept a whole number of tickets from 1 to 6 inclusive. Design a full set of test data giving a normal, boundary and erroneous example for each relevant case, stating the expected outcome of each.

Active recall

Recall the key points — then reveal.

Sources: AQA A-level Computer Science 7517 specification (AQA)

References & sources

Sources

Department for Education

GCE AS and A level subject content for computer science

AQA

AQA A-level Computer Science 7517 specification

Systematic approach to problem solving

3 sections~11 min reading time3 competenciesLevel Standard 3

Systematic approach to problem solving

Key points

Turning an aim into measurable success criteria

Key points

Decomposing a problem

Key points

Designing test data for a validation rule

Sources

Systematic approach to problem solving

Key points

Turning an aim into measurable success criteria

Key points

Decomposing a problem

Key points

Designing test data for a validation rule

Sources