Algorithm design and problem-solving: program development life cycle and the role of algorithms

What you'll learn

This revision guide covers the program development life cycle and the fundamental role of algorithms in solving computational problems. You'll understand each stage of software development from initial analysis through to maintenance, and learn how to design, represent and evaluate algorithms effectively. These concepts form the foundation of structured problem-solving in Computer Science and are regularly assessed in both Paper 1 and Paper 2.

Key terms and definitions

Algorithm — A sequence of precise, unambiguous instructions that can be followed to solve a problem or complete a task in a finite amount of time.

Program development life cycle — The structured process of creating software, consisting of analysis, design, coding, testing and maintenance stages.

Decomposition — Breaking down a complex problem into smaller, more manageable sub-problems that can be solved independently.

Abstraction — Removing unnecessary detail from a problem to focus on the essential information needed to solve it.

Pseudocode — A method of representing algorithms using structured English-like statements that are independent of any specific programming language.

Flowchart — A diagrammatic representation of an algorithm using standardised symbols connected by arrows to show the flow of control.

Trace table — A table used to manually track the values of variables as an algorithm executes, step by step, to verify correctness.

Dry run — The process of manually working through an algorithm with test data to check it functions correctly before implementation.

Core concepts

The program development life cycle

The program development life cycle provides a systematic approach to creating software. Each stage must be completed thoroughly before moving to the next, though iteration back to earlier stages often occurs when problems are identified.

Analysis stage

During analysis, the problem is clearly defined and requirements are established:

• Identify the problem that needs solving
• Determine the inputs required from the user or system
• Define the processes that must be performed on the data
• Specify the outputs that should be produced
• Consider any constraints (time, cost, hardware limitations)
• Document user and system requirements

Design stage

The design stage involves planning the solution before any code is written:

• Break down the problem using decomposition into manageable sub-problems
• Apply abstraction to identify essential elements and remove unnecessary detail
• Design algorithms using flowcharts or pseudocode
• Plan data structures and variables needed
• Design the user interface (where applicable)
• Create test plans with suitable test data

Coding stage

During coding, the designed solution is implemented in a programming language:

• Select an appropriate programming language
• Translate algorithms from pseudocode/flowcharts into executable code
• Follow good programming practices (meaningful identifiers, comments, indentation)
• Code modules or subroutines separately where decomposition was used
• Use appropriate programming constructs (sequence, selection, iteration)

Testing stage

Testing verifies that the program works correctly and meets requirements:

• Perform dry runs using trace tables to check algorithm logic
• Test with normal data (typical, valid inputs)
• Test with boundary data (extreme valid values)
• Test with erroneous data (invalid inputs)
• Identify and correct errors (debugging)
• Check outputs match expected results from test plan
• Verify all requirements from analysis stage are met

Maintenance stage

After deployment, the program requires ongoing maintenance:

• Corrective maintenance: fixing bugs discovered during use
• Adaptive maintenance: modifying the program to work with new hardware, operating systems or requirements
• Perfective maintenance: improving performance or adding new features requested by users
• Documentation must be updated to reflect any changes made

The role of algorithms in problem-solving

Algorithms are fundamental to computer science because they provide precise instructions that computers can follow. Well-designed algorithms ensure programs are efficient, reliable and solve problems correctly.

Why algorithms are important

• Algorithms define the logic of a solution independent of programming language
• They can be tested and refined before coding begins, saving development time
• Multiple programmers can understand and implement the same algorithm consistently
• Algorithm efficiency directly affects program performance
• Good algorithms produce correct outputs for all valid inputs

Characteristics of good algorithms

An effective algorithm must have these properties:

• Unambiguous: each instruction has only one possible interpretation
• Finite: the algorithm must terminate after a finite number of steps
• Inputs: clearly defined inputs (may be zero inputs for some algorithms)
• Outputs: produces at least one output
• Effective: each instruction must be basic enough to be carried out
• Efficient: solves the problem in reasonable time using reasonable resources

Representing algorithms

Algorithms can be represented in several ways, each with advantages for different purposes.

Pseudocode representation

Pseudocode uses structured English-like statements to describe algorithms. CIE IGCSE uses specific pseudocode conventions:

// Assignment and output
Variable ← value
OUTPUT "message"
INPUT UserValue

// Selection
IF condition THEN
    statements
ELSE
    statements
ENDIF

// Iteration - count-controlled
FOR counter ← start TO end
    statements
NEXT counter

// Iteration - condition-controlled
WHILE condition DO
    statements
ENDWHILE

REPEAT
    statements
UNTIL condition

Flowchart representation

Flowcharts use standardised symbols:

• Oval/rounded rectangle: Start and End (terminators)
• Parallelogram: Input and Output
• Rectangle: Process (calculations, assignments)
• Diamond: Decision (conditions with Yes/No branches)
• Arrows: Flow of control showing sequence

Advantages of flowcharts: visual representation makes logic flow clear; easy for non-programmers to understand.

Disadvantages of flowcharts: complex algorithms become cluttered; difficult to modify; no standard level of detail.

Advantages of pseudocode: closer to actual code; easier to convert to programming language; more concise for complex logic.

Disadvantages of pseudocode: less visual than flowcharts; requires understanding of programming concepts.

Dry running and trace tables

A dry run involves manually working through an algorithm with specific test data to verify correctness. A trace table records the values of variables at each step.

Creating a trace table

1. List all variables as column headings
2. Add a column for output (if applicable)
3. Work through the algorithm line by line
4. Record variable values as they change in new rows
5. Only write new values when a variable changes

Example trace table structure:

Trace tables help identify:

• Logic errors in conditions or loops
• Variables not initialised correctly
• Incorrect calculations
• Loops that don't terminate

Problem-solving techniques

Decomposition in practice

Large problems should be broken into sub-problems:

• Each sub-problem can be solved independently
• Sub-problems can be coded as separate subroutines/functions
• Different team members can work on different sub-problems
• Sub-problems can be tested separately before integration

Example: A library system could decompose into:

• User registration module
• Book search module
• Borrowing/return module
• Fine calculation module
• Report generation module

Abstraction in practice

Abstraction focuses on relevant details and removes unnecessary complexity:

• Identify essential inputs, processes and outputs
• Hide implementation details that users don't need to know
• Use meaningful names that describe purpose, not method
• Focus on what the solution does, not how it does it

Example: Calculating student grades

• Essential: marks, grade boundaries, output grade
• Unnecessary: student home address, date of birth (unless required for specific functionality)

Worked examples

Example 1: Analysis and design (6 marks)

Question: A school needs a program to calculate student grades. Students take three tests, each marked out of 100. The average mark determines the grade: 70+ is A, 60-69 is B, 50-59 is C, below 50 is D.

(a) State the inputs, processes and outputs required. [3] (b) Draw a flowchart showing the algorithm to calculate a student's grade. [3]

Mark scheme answer:

(a)

• Inputs: Three test marks (or mark1, mark2, mark3) [1]
• Process: Calculate average of three marks; determine grade based on average [1]
• Output: Grade (A, B, C or D) / average mark [1]

(b) [3 marks available]

Flowchart must include:

• Start terminator [1]
• Input of three marks
• Process to calculate average
• Decision structure to determine grade (nested IF or equivalent) [1]
• Output of grade
• End terminator [1]

(Award marks for correct symbols, flow and logic - 1 mark each for three correct elements)

Example 2: Trace table (5 marks)

Question: Complete the trace table for this algorithm with input values: 8, 3

INPUT Num1
INPUT Num2
Total ← 0
Count ← 1
WHILE Count <= Num2 DO
    Total ← Total + Num1
    Count ← Count + 1
ENDWHILE
OUTPUT Total

Mark scheme answer:

[5 marks: 1 mark for each correct row of values, tracking the multiplication algorithm]

Example 3: Program development life cycle (4 marks)

Question: A company has developed accounting software. After six months of use, customers report that the software crashes when processing more than 1000 transactions in one day.

(a) Identify which stage of the program development life cycle failed to identify this problem. [1] (b) Explain why this problem was not detected. [2] (c) State which type of maintenance is now required. [1]

Mark scheme answer:

(a) Testing (stage) [1]

(b) Any two from:

• Insufficient/inadequate test data was used [1]
• Boundary values for large datasets were not tested [1]
• Testing did not include scenarios with 1000+ transactions [1]
• The test plan did not consider high-volume usage [1]

(c) Corrective maintenance / adaptive maintenance (accept either) [1]

Common mistakes and how to avoid them

• Confusing the stages of the program development life cycle: Remember the order — Analysis, Design, Coding, Testing, Maintenance. Each stage has distinct activities. Testing happens before deployment, not after maintenance.

• Incomplete trace tables: Always create a new row when ANY variable changes value. Don't skip steps even if they seem obvious. Include a column for output and only write output values when an OUTPUT statement executes.

• Vague problem analysis: When identifying inputs, processes and outputs, be specific. Don't write "data" — specify what data (e.g., "customer name", "product price"). For processes, state what calculation or operation occurs.

• Mixing flowchart symbols: Learn the standard symbols. Don't use rectangles for decisions or diamonds for processes. Ensure all paths from decision diamonds are labelled (Yes/No or True/False).

• Ignoring the question command words: "State" requires brief answers; "Explain" requires reasoning; "Identify" needs you to name something specific. Match your answer length and detail to the command word and mark allocation.

• Confusing corrective and adaptive maintenance: Corrective maintenance fixes bugs. Adaptive maintenance modifies the program for new environments or requirements. Both happen after deployment, but for different reasons.

Exam technique for algorithm design and problem-solving

• Command word awareness: "State" (1 mark) needs just the fact. "Describe" (2 marks) needs features or characteristics. "Explain" (2-3 marks) requires reasons or justification using connectives like "because", "therefore" or "so that".

• Trace table accuracy: Work methodically through each line of pseudocode. Check loop conditions carefully — boundary errors are common. If the trace table has 4 rows in the template, you'll likely need approximately 4 steps.

• Algorithm representation choice: If asked to use pseudocode, use CIE conventions exactly (WHILE...ENDWHILE, IF...ENDIF). For flowcharts, ensure all paths merge and arrows show clear direction of flow. Use a ruler if possible.

• Mark allocation guides detail: A 4-mark question needs 4 distinct points. If you only write 2 sentences for a 4-mark "explain" question, you're unlikely to achieve full marks. Count your points and match them to available marks.

Quick revision summary

The program development life cycle consists of five stages: analysis (define the problem), design (plan the solution using decomposition and abstraction), coding (implement in a programming language), testing (verify correctness with dry runs and trace tables), and maintenance (corrective, adaptive or perfective). Algorithms are precise, unambiguous instruction sequences represented through pseudocode or flowcharts. Good algorithms are finite, effective and efficient. Testing uses normal, boundary and erroneous data. Understanding each stage and how algorithms solve problems is essential for both exam papers.