Designing, creating and refining algorithms — OCR GCSE Computer Science
Teaching note checked against the official specification.
Test yourself on Designing, creating and refining algorithms with OCR GCSE practice questions.
A week of Premium from your first lesson · Then the free plan continues · No card, no charge
Designing, creating and refining algorithms explained
Designing, creating and refining algorithms covers 5 specification points, including Identify the inputs, processes, and outputs… and Structure diagrams.
Read the full explanation
Open a point below for its explanation and revision guidance.
Identify the inputs, processes, and outputs for a problem
Every computational problem can be described as a system that takes inputs, transforms them through processes and produces outputs. Inputs are the data or signals entering the system, such as a customer's age typed into a ticket machine. Processes are the operations, calculations or decisions performed on that data, such as checking whether the age is below 16 and calculating the price. Outputs are the results presented or stored, such as displaying the ticket price or writing a record to a file. Identifying these three elements forces you to clarify what data is needed, what must be done with it and what the user or another system receives. This structure supports later algorithm design because each process can become a step, decision or sub-program, and it is assessed by applying the model to scenarios rather than by listing definitions.
Structure diagrams
A structure diagram is a top-down design tool that breaks a whole problem into successively smaller sub-problems until each part is simple enough to code as a module. The top box names the overall system; each lower level shows a decomposition of the box above it. For example, a 'Quiz Game' box might split into 'Load Questions', 'Ask Question', 'Check Answer' and 'Update Score', and 'Check Answer' might split again into 'Compare Input' and 'Award Mark'. Reading downwards shows decomposition; reading upwards shows how modules combine. Structure diagrams show hierarchy and sequence of refinement, not the order in which code runs, so they differ from flowcharts, which show control flow. They help plan modular programs, support testing of separate modules and make large problems easier to divide among a team.
Create, interpret, correct, complete, and refine algorithms using Pseudocode Flowcharts Reference language/high-level programming language
An algorithm is a precise sequence of steps that solves a problem. This statement covers five skills across four notations: pseudocode, flowcharts, OCR reference language and a high-level language such as Python. Creating means writing a correct algorithm from a problem description. Interpreting means reading an algorithm and stating its purpose or output. Correcting means finding and fixing logic errors. Completing means filling gaps so the algorithm works. Refining means improving an already working algorithm, for example by removing repeated code or handling invalid input. The same logic can be expressed in any notation: a count-controlled loop is 'for i = 1 to 10' in pseudocode, a loop-back arrow in a flowchart, and 'for i in range(1, 11):' in Python. Assessment focuses on whether the logic is correct and complete, not on decorative presentation.
Identify common errors
Identifying common errors means reading an algorithm and finding where it will not do what is intended. You check each line against the purpose: syntax errors break the rules of the language, such as a missing bracket or a misspelled keyword; logic errors run but give wrong output, such as using < instead of > or adding instead of subtracting; runtime errors stop the program, such as dividing by zero or reading past the end of an array. A useful method is to trace a small input by hand, compare the result with the expected result, then fix the first error and retest. In an exam you may be shown pseudocode or a program and asked to state the error and the correction, so name the line and explain the effect.
Trace tables
A trace table records how variable values change as an algorithm runs, line by line. Set up a column for each variable, plus columns for output or conditions, then work through the algorithm with a chosen input. At each step, write the new value of any variable that changes, showing the program state after every assignment. Trace tables test an algorithm by hand, find logic errors, and reveal the algorithm's purpose. For example, tracing a loop with inputs 3, 5 and 2 gives running totals 3, 8 and 10, showing the purpose is to sum the inputs. In an exam, you may complete a given table or produce one, so keep columns aligned with variables and update only the cells that change.
Your focus
- Identify inputs, processes and outputs in a given problem scenario.
- Classify each element correctly and justify the classification.
- Use the input-process-output model to plan the steps of a solution.
Show all 16 objectives
- Draw a structure diagram that decomposes a given problem into at least three levels of sub-tasks.
- Interpret a supplied structure diagram by describing the purpose of each module and its relationship to its parent.
- Complete or correct a partly drawn structure diagram so that every parent task is fully decomposed into implementable modules.
- Create a working algorithm in pseudocode, a flowchart, OCR reference language or a high-level language to solve a stated problem.
- Interpret a given algorithm by tracing it and stating its purpose, output and behaviour for sample and edge-case inputs.
- Correct, complete or refine an algorithm by identifying logic errors or improvements and applying precise amendments.
- Identify syntax, logic and runtime errors in a given algorithm.
- Trace an algorithm with test data to locate an error and describe its effect.
- Suggest and justify a correction that makes the algorithm meet its purpose.
- Construct a trace table with appropriate columns for a given algorithm.
- Complete a trace table accurately by following the algorithm step by step.
- Use a trace table to detect and explain a logic error in an algorithm.
- Use a trace table to determine the purpose of an algorithm.
Designing, creating and refining algorithms flashcards
Card 1 of 11
Structure diagram
Designing, creating and refining algorithms exam tips
Marking Points
- Identifies inputs as the data or signals that enter the system, naming specific items from the scenario rather than saying 'data'.
- Identifies processes as the operations, calculations or decisions carried out on the inputs, including any comparisons or validation.
- Identifies outputs as the results produced, such as displayed values, printed documents, stored records or control signals.
- Classifies each item correctly when a scenario mixes data entry, calculation and display, avoiding placing a calculation in the input list.
- Links inputs to the processes that use them and processes to the outputs they produce, showing the flow through the system.
- Uses the identified elements to outline a solution, for example turning a process into a step or decision in an algorithm.
- A structure diagram decomposes a problem from a single top-level box into progressively smaller sub-problems at lower levels.
- Each box represents a module or task, and boxes on the same level are sibling sub-tasks of the parent box directly above them.
- The diagram shows hierarchy and decomposition, not the order of execution, so it is not a flowchart and has no decision diamonds or flow arrows.
- A well-formed diagram stops decomposing when each leaf module is simple enough to be written as a single subroutine or small block of code.
- Structure diagrams support modular design, so modules can be written, tested and maintained independently and work can be shared across a team.
- Interpreting a diagram means tracing from the top-level task down to leaf modules and explaining what each module must do and how it contributes to the whole.
- Creating an algorithm means translating a problem description into ordered steps using sequence, selection and iteration in the required notation.
- Interpreting an algorithm means tracing it with sample data to state its purpose, outputs or behaviour, including edge cases.
- Correcting an algorithm means locating logic errors such as wrong conditions, off-by-one loop bounds or misplaced statements, then amending them.
- Completing an algorithm means supplying missing lines or symbols so that it fulfils the stated purpose without changing the given logic.
- Refining an algorithm means improving a working solution, for example by removing duplication, using a loop or function, or validating input.
- The same algorithm can be represented in pseudocode, a flowchart, OCR reference language or a high-level language, and translating between them preserves the logic.
- Distinguishes syntax, logic and runtime errors and gives a correct example of each in pseudocode or a high-level language.
- Locates an error by tracing a short input through the algorithm and comparing the actual output with the expected output.
- Explains the effect of an error, such as an infinite loop, an incorrect total, or a program crash, rather than only naming the line.
- States a valid correction, for example changing a comparison operator, swapping two statements, or adding a missing initialisation.
- Checks boundary cases such as an empty list, a zero value, or the first and last items, where errors often appear.
- Uses test data that includes normal, boundary and erroneous values to expose different faults.
- Creates a column for each variable, output, and condition, allocating a row for each step or iteration of the algorithm.
- Follows the algorithm sequentially, applying assignment, selection, and iteration logic correctly at each step.
- Updates variable values accurately upon change, including counters, running totals, and Boolean flags.
- Records output values exactly at the point they are generated, rather than at the end of the algorithm.
- Uses the completed trace table to identify logic errors, such as an infinite loop or an incorrect running total.
- Analyses the pattern of values and outputs in the table to deduce the overall purpose of the algorithm, such as finding a maximum value.
- Accurately traces boundary cases, such as a loop that executes zero times or an array containing a single item.
Examiner Tips
- 💡Use the scenario's own words when naming inputs and outputs so each item is clearly tied to the problem.
- 💡Present your answer as three labelled groups, inputs, processes and outputs, so the classification is unambiguous.
- 💡Check each process and ask which input it uses and which output it produces, removing any item that does not fit the flow.
- 💡Read the question wording: 'decompose' or 'break down' signals a structure diagram, while 'sequence', 'selection' or 'iteration' signals a flowchart or pseudocode task, so check whether the question asks for a diagram or code.
- 💡When completing a partly drawn diagram, match the level of detail of the boxes already given and keep sibling boxes at a similar size.
- 💡When interpreting, name the top-level task, then state what each lower-level module does and how it combines to solve the whole problem.
- 💡Trace algorithms line by line with a trace table, recording each variable after every change, to interpret output and spot errors.
- 💡When completing code, check indentation and matching constructs such as ENDIF, NEXT or closing brackets before submitting.
- 💡When refining, state what you changed and why, for example 'replaced repeated input statements with a while loop to validate the entry'.
- 💡Quote the line or statement that contains the error, then state the correction separately so both parts are clear.
- 💡Use the words syntax, logic and runtime accurately; do not use them as synonyms.
- 💡When asked to identify an error, describe what the code does now and what it should do instead.
- 💡Draw the table before starting and label columns with the exact variable names used in the algorithm.
- 💡Work through the algorithm one line at a time and write values as you go; do not try to calculate the final answer first.
- 💡Check the number of iterations against the loop condition so you do not add or miss a row.
- 💡When asked for the purpose, look at the final output and the pattern of values, then state the overall task in one sentence.
Common Mistakes
- Listing the keyboard or screen as the input or output; correction: the input is the data entered and the output is the information produced, while the device is only the hardware involved.
- Putting a calculation such as working out a total in the input list; correction: a calculation is a process because it transforms data rather than supplying it.
- Forgetting stored results such as a saved file or updated database record; correction: an output can be stored data as well as something displayed to a user.
- Drawing a flowchart with arrows and decision symbols instead of a hierarchy: correction is to use only boxes connected by plain lines showing parent-child decomposition.
- Putting steps in time order across a level: correction is to treat boxes on one level as independent sub-tasks, because a structure diagram does not show sequence.
- Decomposing forever or stopping too early: correction is to stop when each leaf module is small enough to implement as one subroutine, and to check every parent is fully broken down.
- Confusing '=' with '==' in conditions: correction is to use a single '=' for assignment and '==' for comparison in pseudocode and Python.
- Using 1-based counting in Python loops: correction is to remember range(1, 11) produces 1 to 10, and that Python indexes lists from 0.
- Correcting an algorithm by rewriting it entirely: correction is to make the smallest change that fixes the logic error while keeping the given structure and variable names.
- Confusing a logic error with a syntax error. Correction: a syntax error prevents the program running at all, while a logic error runs but produces wrong output.
- Assuming an algorithm is correct because it works for one input. Correction: test several inputs, including boundary values, before deciding there is no error.
- Changing many lines at once when correcting an algorithm. Correction: fix one error, retest, then continue so you can see which change solved the problem.
- Writing the final value of a variable in every row instead of the value after each step. Correction: update a cell only when that variable changes.
- Losing track of which line is being executed inside a loop. Correction: number the lines or mark the current line as you work through each iteration.
- Forgetting to record output or a condition result. Correction: include a column for output or for the condition so the full behaviour is visible.
- Describing what the algorithm does line by line instead of stating its overall purpose. Correction: summarise the effect of the whole algorithm, for example 'it counts how many values are above 10'.