Develop code — Edexcel GCSE Computer Science

Decomposition means breaking a large problem into smaller sub-problems that are easier to understand, design, code and test. Abstraction means removing unnecessary detail and keeping only the features that matter for solving the problem, such as modelling a shop till with items, prices and totals while ignoring the colour of the till. To analyse a problem, you identify inputs, processes and outputs, list the sub-tasks and decide which details are irrelevant. To solve it, you design and code each sub-problem, often as separate functions or modules, then combine them and test the whole solution. For example, a program to calculate student grades could be decomposed into reading marks, calculating an average, applying grade boundaries and displaying the result, while abstraction removes details such as the font used on screen.

This criterion requires you to work fluently with complete programs in a high-level language, not just isolated lines. Reading means tracing execution line by line, tracking variable values in a trace table and predicting output. Writing means building a working program from a specification, choosing suitable selection, iteration, subprograms and data structures. Analysing means explaining what a given program does, identifying inputs, processes and outputs, and locating logic errors such as an off-by-one loop bound or a condition that never becomes true. Refining means editing existing code to correct faults, improve readability with meaningful identifiers and comments, and make it more efficient or robust, for example adding validation so a menu rejects an out-of-range choice.

This criterion asks you to translate an algorithm expressed as a flowchart or pseudocode into a working program in a high-level language. The skill is faithful conversion: every symbol or pseudocode line must become equivalent code, with the same sequence, selection and iteration. Read the algorithm first and identify its inputs, its decisions and its loops. A flowchart decision diamond becomes an if statement, and a loop back to an earlier point becomes a while or for loop with the same condition. Pseudocode assignment becomes a variable assignment, and pseudocode input and output become the input and output statements of your language. Watch the details: a condition written as greater than or equal to must stay that way, and counters must be initialised before the loop.

Readable code lets another programmer follow the logic quickly and change it safely. Layout groups related statements so the sequence of actions is obvious. Indentation shows which statements sit inside a loop, selection or subroutine, so nesting depth is visible at a glance. Comments explain why a block exists or what a non-obvious value means, rather than restating each line. Meaningful identifiers name variables and subroutines after their purpose, so totalScore is clearer than t. White space separates logical blocks and operators, making expressions easier to scan. For example, a function that calculates a pupil's average mark should indent its loop body, use names such as markTotal and markCount, and carry a short comment describing the rounding rule. These techniques do not change what the program does; they change how easily a human reads, understands and later maintains it.

Debugging means finding why a program does not behave as intended, working out where the fault is, and fixing it. Syntax errors break the rules of the language, so the program will not run; an example is a missing closing bracket or a misspelled keyword. Logic errors let the program run but produce wrong results, such as using addition where subtraction is needed or writing a condition that is never true. Runtime errors occur while the program is running, for example dividing by zero or accessing an index outside the bounds of a list. To debug, read the error message, trace the values of variables, add temporary output statements, and test with known inputs. Once the fault is located, correct the code and re-test to confirm the fix and check that nothing else has broken.

Evaluation means judging whether a working program actually does the job it was written for, and how economically it does it. Start by restating the purpose in testable terms, then choose test data that exercises normal, boundary and erroneous cases. Run the program and compare each actual output with the expected output; a mismatch shows the program is not fit for purpose. Fitness also covers robustness: does it reject invalid input, handle an empty list or a zero divisor? Efficiency is judged separately from correctness. Count how many comparisons a search or sort makes, count how many times a loop body executes, and estimate memory by tracking how many variables, list elements or records are stored at once. For example, a linear search over 1000 items may need 1000 comparisons, while a binary search needs far fewer, so the same correct result can be reached more efficiently.