Skip to the page
Year 10 · Computer Science · Spring 2 · Algorithm design and problem solving

The development cycle, decomposition and structure diagrams

What this lesson covers

7.1 The program development life cycle

Cambridge IGCSE Computer Science 0478 · Topic 7: Algorithm design and problem-solving · Paper 2

7.2 Systems, decomposition and design tools

Cambridge IGCSE Computer Science 0478 · Topic 7: Algorithm design and problem-solving · Paper 2

You will learn to

  • Describe the four stages of the program development life cycle: analysis, design, coding and testing.
  • Explain abstraction and decomposition, with an example from a scenario.
  • Decompose a problem into inputs, processes, outputs and storage.
  • Draw a structure diagram for a past-paper scenario.

Success criteria

  • I can say what each stage of the life cycle produces.
  • I can break a scenario into sub-systems and draw them as a structure diagram.
  • I can explain the difference between abstraction and decomposition.
The syllabus points for these sections
  • Name the four stages: analysis, design, coding and testing.
  • Explain abstraction and decomposition in the analysis stage.
  • Name the design tools: structure diagrams, flowcharts and pseudocode.
  • Explain iterative testing during coding and testing with test data.
  • Explain that a computer system is made of sub-systems.
  • Decompose a problem into inputs, processes, outputs and storage.
  • Draw and read a structure diagram.
  • Draw and read flowcharts using the six standard symbols.
  • Read and write simple Cambridge pseudocode.

Key words

Say each word, then read what it means. Every one is in the glossary too.

Algorithm
A precise, ordered set of steps that solves a problem.
Program development life cycle
The four stages of making a program: analysis, design, coding and testing.
Abstraction
Removing details that do not matter so you can focus on the ones that do.
Decomposition
Breaking a problem into smaller parts that are easier to solve.
Sub-system
A smaller part of a system that does one job.
Structure diagram
A top-down diagram that shows how a system is split into sub-systems.
Flowchart
A diagram of an algorithm using standard shapes joined by flow lines.
Pseudocode
A structured, code-like way of writing an algorithm that is not tied to one language.
Check digit
An extra digit calculated from the other digits, used to catch typing errors.
Normal data
Test data that should be accepted.
Abnormal data
Test data that should be rejected.
Extreme data
The largest and smallest values that should be accepted.

The explanation

Read it here, or open the study page below to go one step at a time with things to try.

7.1 The program development life cycle

Four stages, in order

The program development life cycle is the set of stages a programmer goes through to make a program.

There are four stages: analysis, design, coding and testing.

It is called a cycle because problems found in testing send you back to an earlier stage.

StageQuestion it answersWhat is produced
AnalysisWhat must the program do?A list of requirements
DesignHow will it do it?Structure diagrams, flowcharts, pseudocode
CodingCan we build it?Program code, tested as it is written
TestingDoes it work for all data?Test results with test data
?Why?

Planning before coding is faster overall. A mistake fixed in the design costs minutes. The same mistake found after coding can cost hours.

!Watch out

Learn the four names exactly. Cambridge uses analysis, design, coding, testing. Words like 'planning' or 'making' do not earn the mark.

Analysis: understand the problem

In analysis you find out exactly what the problem is and what the program must do. These needs are the requirements.

Abstraction means removing the details that do not matter, so you can focus on what does.

Decomposition means breaking a big problem into smaller parts that are easier to solve.

e.g.Example
Problem: a school canteen wants a top-up system for student cards. Requirements: input the card number and amount, add the amount to the balance, show the new balance. Abstraction: the colour of the card and the student's hair colour do not matter. Keep card number, name and balance. Decomposition: read card → choose amount → take payment → update balance.
?Why?

Abstraction stops you wasting time on details that will not affect the program. Decomposition turns one scary problem into several small, easy ones.

Design, coding and testing

In design you plan how the program will work. You decompose further and use structure diagrams, flowcharts and pseudocode.

In coding you write the program. You test each part as you write it. This is called iterative testing: write a bit, test it, fix it, repeat.

In testing you run the finished program with planned test data to check it works for every kind of input.

e.g.Example
Canteen system: Design: a flowchart for 'take payment'. Coding: write 'update balance' and test it with one card before writing the next part. Testing: try a top-up of 10 euros (normal), -5 euros (abnormal) and the largest allowed amount (extreme).
!Watch out

Do not mix up iterative testing and final testing. Iterative testing happens during coding, part by part. Final testing uses a full test plan on the finished program.

7.2 Systems, decomposition and design tools

Sub-systems, and inputs, processes, outputs and storage

A system is a set of parts that work together to do a job. Each part is a sub-system. A sub-system can be split again until each part is small enough to code easily.

Example: a supermarket self-checkout is a system. Scanning, weighing, payment and printing the receipt are its sub-systems.

Every problem can also be decomposed into four parts.

Inputs: the data going in. Processes: what is done to the data. Outputs: the results that come out. Storage: data that must be kept for later.

PartSupermarket self-checkout
InputsBarcode of each item, weight, payment card
ProcessesLook up the price, add to the running total, check the weight
OutputsItem name and price on screen, total, receipt
StorageProduct file of barcodes and prices, record of the sale
?Why?

Small parts are easier to write, test and fix. Different programmers can work on different sub-systems at the same time.

!Watch out

Do not put the same thing in two places. 'Total' is calculated (process) and then shown (output). Say which one you mean.

Structure diagrams

A structure diagram shows how a system is broken down into sub-systems. The whole system is in the top box.

Each level below shows smaller parts. Read it top to bottom. Boxes on one level are usually read from left to right.

It shows what the parts are, not the order of every step or the decisions.

?Why?

A structure diagram is a picture of decomposition. It helps a team share out the work: one person can code 'Take payment' while another codes 'Update card'.

There is a diagram for this step in the IGCSE library.

Flowcharts: the six symbols

A flowchart shows the steps of an algorithm as shapes joined by arrows. Each shape has one meaning.

Follow the flow lines from START to STOP. A decision diamond has two exits, labelled Yes and No.

A loop is drawn as a flow line that goes back up to an earlier step.

e.g.Example
Flowchart to count passes in 6 marks: START (terminator) → Count ← 0, Index ← 1 (process) → INPUT Mark (input/output) → Mark >= 25? (decision) Yes → Count ← Count + 1 (process); No → go on → Index ← Index + 1 (process) → Index > 6? (decision) No → back up to INPUT Mark; Yes → go on → OUTPUT Count (input/output) → STOP (terminator)
!Watch out

Use the right shape. INPUT and OUTPUT go in a parallelogram, not a rectangle. Every decision diamond needs two labelled exits.

There is a diagram for this step in the IGCSE library.

Pseudocode: Cambridge's planning language

Pseudocode is a way of writing an algorithm that looks like code but is not tied to one language.

Cambridge has its own rules. Keywords are in CAPITALS. Assignment uses `←`. Comments start with `//`. Not equal is `<>`.

Paper 2 answers must be in pseudocode. Program code only earns marks in the 15-mark scenario question.

JobCambridge pseudocode
Make a variable`DECLARE Total : INTEGER`
Store a value`Total ← 0`
Input and output`INPUT Mark` and `OUTPUT "Total: ", Total`
Array of 30 items`DECLARE Marks : ARRAY[1:30] OF INTEGER`
Selection`IF … THEN … ELSE … ENDIF`
Count-controlled loop`FOR Index ← 1 TO 10` … `NEXT Index`
Pre-condition loop`WHILE … DO` … `ENDWHILE`
Post-condition loop`REPEAT` … `UNTIL …`
DECLARE Mark : INTEGER
OUTPUT "Enter your mark: "
INPUT Mark
IF Mark >= 25
  THEN
    OUTPUT "Pass"
  ELSE
    OUTPUT "Fail"
ENDIF
mark = int(input("Enter your mark: "))
if mark >= 25:
    print("Pass")
else:
    print("Fail")
?Why?

Pseudocode lets you think about the logic without worrying about the exact rules of Python. An examiner can read it whatever language you learned.

Study it

Open the study page and go one step at a time.

Check yourself

One question at a time. The reason shows after each answer.

Saved on this device.