Content Area 1: Problem Solving

Rate each point. Be honest: 'Secure' means you could answer an exam question on it now without notes.

1.1.1–3	Define computational thinking, say when it is used, and give its benefits and drawbacks
1.1.4–5	Name the four components (decomposition, pattern recognition, abstraction, algorithmic design) and give benefits and drawbacks of each
1.1.6–8	Explain the purpose and tasks of decomposition and use it to break down a problem
1.1.9–10	Represent decomposition with block diagrams, information flow diagrams, flowcharts, code and written descriptions
1.1.11–12	Explain and use pattern recognition: trends, similarities, common features, predictions
1.1.13–16	Explain the tasks of abstraction and use it: inputs, outputs, variables, constants, key actions, repeated processes
1.1.17	Judge how the components of computational thinking relate and when to use them
1.2.1	Define an algorithm and describe its characteristics and purpose
1.2.2–5	Express algorithms as flowcharts, written descriptions and code; give benefits and drawbacks of each
1.2.6	Use sequence, selection and iteration to control the order of steps
1.2.7–10	Work out what an algorithm does and its output; identify and correct errors
1.2.11–12	Translate between notations; design algorithms
1.3.1–2	Explain top-down, bottom-up and modularisation, with benefits and drawbacks
1.3.3–4	Explain root cause analysis: five whys, FMEA, event tree analysis; log, close, escalate
1.3.5	Describe the high-level problem-solving strategy
1.3.6	Judge which strategy suits a problem

Computational thinking is a way of approaching a problem so that the solution can be expressed clearly enough for a computer, or another person, to carry it out. It is used at the start of any development task, when a problem is complex or unfamiliar, and when a solution needs to be explained to a team.

Benefits (1.1.3)	Drawbacks
Complex problems become manageable Solutions are logical and repeatable Parts of a problem can be shared out across a team Reuse of existing solutions saves time Errors are easier to find in small parts	Takes time up front before any code is written Over-simplifying (too much abstraction) can miss important detail Not every problem suits a step-by-step approach, e.g. creative design decisions Needs practice and skill to do well

The four components (1.1.4–1.1.5)

Component	What it means	Benefits	Drawbacks
Decomposition	Breaking a problem down into smaller parts	Each part is easier to solve, test and assign	Parts must be recombined; interfaces between parts can be missed
Pattern recognition	Spotting similarities within and between problems	Reuse existing solutions; make predictions	False patterns lead to wrong assumptions
Abstraction	Keeping what matters and removing unnecessary detail	Focus on the essentials; simpler models	Removing too much makes the solution unrealistic
Algorithmic design	Writing the step-by-step solution	Clear, testable instructions that can become code	Time-consuming; errors in logic carry through to code

Decomposition (1.1.6–1.1.10)

Purpose: to make a large problem manageable, so each part can be understood, built and tested on its own and shared across a team.

Tasks of decomposition:

1. Identify the main features of the problem.
2. Characterise each feature: what does it need to do?
3. Break the problem down into smaller, more manageable parts.
4. Break the solution down into smaller, more manageable parts (modules, functions).

Computational thinking

A set of problem-solving techniques for breaking a problem down and expressing a solution so that a computer (or person) could carry it out.

Decomposition

Breaking a problem or solution down into smaller, more manageable parts.

Abstraction

Identifying the information that is needed and filtering out or hiding unnecessary detail.

Algorithmic design

Producing a step-by-step set of instructions to solve the problem.

Takeaway ordering app

Accounts

• Register
• Log in
• Reset password

Menu

• Browse
• Search
• Filter allergens

Basket and checkout

• Add / remove
• Calculate total
• Take payment

Delivery tracking

• Assign driver
• Live map
• Notify customer

Method of representation	Use it to show	Example
Block diagram	The parts of a system and how they break down	Diagram above
Information flow diagram	How information moves between people and systems	Diagram below
Flowchart	The steps and decisions of one part	See 1.2
Code	Each part as a function or module	def calculate_total(basket):
Written description	Each part described in numbered steps	1. Accounts 1.1 Register 1.2 Log in

Flowchart

A diagram that shows an algorithm using standard symbols joined by arrows.

Decision

Flowchart symbol (diamond) for a question with two or more outcomes, such as Yes/No.

Block diagram

A diagram of boxes showing how a system is broken down into parts.

Information flow diagram

A diagram showing how information moves between people, systems and processes.

Pattern recognition

Finding similarities and trends within and between problems so existing solutions can be reused.

Pattern recognition (1.1.11–1.1.12)

Purpose: to spot what is the same so effort isn't repeated, and to use patterns to make predictions.

Use	Example
Find and interpret trends and similarities within and between problems and processes	Registering for a gym app and a library app both need: enter details, validate, confirm email.
Find common features between a given problem and existing solutions	A new booking system for a barber's is similar to an existing restaurant booking system, so its design can be adapted.
Make predictions and assumptions based on identified patterns	Website traffic rises every Friday evening, so add server capacity on Fridays.

Abstraction (1.1.13–1.1.16)

Purpose: to focus only on what matters for the problem. The London Underground map is the classic example: it keeps stations, lines and connections and removes real distances and geography.

Tasks: identify information that is needed; filter out unnecessary details; hide details of internal workings (e.g. you call sort() without needing to know how it works).

Using abstraction: ask...	Example: parking charge machine
What inputs are needed?	Number plate, arrival time, departure time
What are the expected outputs and outcomes?	Charge displayed; ticket/receipt; barrier opens after payment
What will vary?	Length of stay, number plate, payment method
What will remain constant?	Hourly rate, maximum daily charge, free period of 20 minutes
What key actions must the solution perform?	Calculate time parked, calculate charge, take payment
What processes are repeated?	Calculating the charge for every car; reading plates at entry and exit
What is filtered out?	Car colour, driver's name, make of car

Algorithm

A finite, ordered set of unambiguous instructions that solves a problem.

Terminator

Flowchart symbol (rounded rectangle) for the start or end of an algorithm.

Sub-process

Flowchart symbol (rectangle with double sides) for a predefined process described elsewhere, such as a function.

An algorithm is a finite, ordered set of unambiguous instructions that solves a problem. Characteristics: clear and unambiguous steps; a defined start and end; inputs and outputs; finite (it stops); correct (it solves the problem). Purpose: to plan a solution before coding, communicate it to others, and check the logic.

Flowcharts (1.2.2)

Worked example: one algorithm in three notations

A login allows three attempts at a password before locking the account.

Written description with hierarchical markers

Step	Instruction
1	Set attempts to 0
2	Repeat:
2.1	Input password
2.2	If password is correct:
2.2.1	Output "Welcome" and stop
2.3	Otherwise add 1 to attempts
2.4	If attempts equals 3:
2.4.1	Output "Account locked" and stop

Code

PASSWORD = "Leeds2026"
attempts = 0
while True:
    password = input("Password: ")
    if password == PASSWORD:
        print("Welcome")
        break
    attempts = attempts + 1
    if attempts == 3:
        print("Account locked")
        break

Password: leeds
Password: Leeds2025
Password: Leeds2026
Welcome

Benefits and drawbacks of each notation (1.2.3–1.2.5)

Notation	Benefits	Drawbacks
Flowchart	Visual; easy to follow decisions and loops; understood by non-programmers; language independent	Large algorithms become huge and messy; slow to draw and edit; hard to show complex data processing
Written description	Quick to write; no special knowledge needed; good for explaining to clients	Can be ambiguous; long descriptions hard to follow; can't be run or tested directly
Code	Precise and unambiguous; can be run and tested; becomes the final product	Needs programming knowledge to read; tied to one language; syntax distracts from logic

Controlling the order of steps (1.2.6)

Action	Flowchart	Python
Sequence	Symbols follow one after another	Lines run top to bottom
Selection	Decision diamond with labelled Yes/No arrows	if, elif, else, match/case
Iteration	An arrow loops back to an earlier step	for, while

Tracing, finding and correcting errors (1.2.7–1.2.10)

To find the purpose and output of an algorithm, trace it with sample input. This algorithm should output the largest number entered, stopping when 0 is entered.

Step	Instruction
1	Set largest to 0
2	Input number
3	While number is not 0:
3.1	If number < largest, set largest to number
3.2	Input number
4	Output largest

Trace it with inputs 4, 9, 2, 0 yourself, then click to check.

Trace with inputs 4, 9, 2, 0: largest stays 0 every time because no number is less than 0. Output: 0. Error: step 3.1 uses < instead of >. Correction: 'If number > largest, set largest to number'. A further problem: if every number is negative, largest stays 0. Better: set largest to the first number entered.

Corrected in Python

number = int(input("Number (0 to stop): "))
largest = number
while number != 0:
    if number > largest:
        largest = number
    number = int(input("Number (0 to stop): "))
print("Largest:", largest)

Number (0 to stop): 4
Number (0 to stop): 9
Number (0 to stop): 2
Number (0 to stop): 0
Largest: 9

Approaches to solving problems (1.3.1–1.3.2)

Approach	What it is	When used	Benefits	Drawbacks
Top-down	Start with the whole problem and break it into smaller sub-problems until each is simple.	New systems where the overall goal is clear	Clear overview; work easy to divide; matches decomposition	Low-level problems found late; detail may be wrong until built
Bottom-up	Build and test small components first, then combine them into bigger parts.	When reliable components or libraries already exist; hardware-led projects	Components tested early; reuse encouraged	Overall design may not fit together; easy to lose sight of the goal
Modularisation	Split the solution into self-contained modules with clear interfaces.	Team projects; large systems	Modules developed and tested in parallel; reusable; easier maintenance	Interfaces between modules must be agreed; integration testing needed

Root cause analysis (1.3.3–1.3.4)

Purpose: to find and fix the real cause of a problem so it does not happen again, instead of repeatedly treating symptoms. Used after incidents, repeated faults, outages, or failed releases.

Five whys

Question	Answer
Why did customers get charged twice?	The payment request was sent twice.
Why was it sent twice?	Users pressed 'Pay' again because nothing appeared to happen.
Why did nothing appear to happen?	The page took 12 seconds to respond with no loading message.
Why did it take 12 seconds?	The payment API call waits for a slow fraud check.
Why is there no protection against double submission?	The button isn't disabled after the first click. Root cause.

Benefits: quick, simple, no special tools. Drawbacks: can stop at a symptom; depends on the knowledge of the people asking; may miss multiple causes.

Top-down

Starting with the whole problem and breaking it into smaller sub-problems.

Bottom-up

Starting with small, detailed components and combining them into a larger solution.

Modularisation

Splitting a solution into self-contained modules that can be developed and tested separately.

Root cause analysis

A process for finding the underlying cause of a problem, rather than just treating the symptoms.

Failure mode and effects analysis (FMEA)

FMEA lists each way a part could fail, the effect, and scores severity, occurrence (likelihood) and detection (how hard to spot) from 1–10. Multiplying them gives a risk priority number (RPN) to rank what to fix first. It is usually done before problems happen.

Component	Failure mode	Effect	S	O	D	RPN	Action
Login service	Database unavailable	No one can log in	9	3	2	54	Add replica database
Payment form	Double submission	Customer charged twice	7	5	6	210	Disable button after click
Image upload	File too large	Upload fails with no message	4	6	3	72	Validate size and show error

Try it: RPN calculator

Event tree analysis (ETA)

ETA starts from a single initiating event and branches at each safeguard into success or failure, showing every possible outcome. It shows whether safeguards are enough.

Actions after root cause analysis

Action	When
Log	Record the problem, cause and fix in an incident or fault log so trends can be spotted and the knowledge kept.
Close	The cause is fixed and tested; the ticket is closed and the user informed.
Escalate	The problem is beyond your authority or skill: pass to a manager, a specialist (e.g. the network team) or an external third party (e.g. the software vendor).

FMEA

Failure mode and effects analysis: listing how each part could fail, the effect, and rating severity, likelihood and detection to prioritise action.

Event tree analysis

A diagram that starts from one initiating event and branches through success/failure of each safeguard to show possible outcomes.

Escalate

Pass a problem to someone with more authority or expertise: a manager, specialist or external third party.

The high-level problem-solving strategy (1.3.5)

Step	What happens	Example: staff can't access shared drive
1 Define the problem	State clearly what is wrong and its scope	Since Monday, the sales team can't open the S: drive
2 Gather information	Collect facts: logs, error messages, who is affected, what changed	Only sales affected; error 'access denied'; permissions update on Monday
3 Analyse the information	Look for patterns and the likely cause	The update removed the sales group from the folder's permissions
4 Make a plan of action	Decide the fix, who does it, when, and how to test it	Re-add the group at lunchtime; test with two users
5 Implement the solution	Carry out the plan	Permissions restored
6 Review the solution	Check it worked and prevent it recurring	All sales staff can access; add permissions check to the update checklist

Five whys

Asking 'why?' repeatedly (often five times) to move from a symptom to the root cause.

Hierarchical markers

Numbering such as 1, 1.1, 1.2, 2 used in written descriptions to show the order and nesting of steps.

Trace table

A table used to record variable values line by line as an algorithm runs.

Flashcards

Every Quick recall definition on this page. Click the card to flip it; use the arrow keys to move.

Random questions on CA1 from the course question bank. Pick a topic or question type, answer in your head or on paper, then check. Your score is saved on this device.

Allow about 80 minutes. Answer each question before you look at its mark scheme.

My corrections: what I need to go back over