Launching your learning experience…
Detailed notes on Algorithm design and problem-solving for Cambridge IGCSE Computer Science, covering key concepts, explanations, examples, and exam-focused revision points.
How professional software gets built. The end-to-end lifecycle (analysis, design, development, testing, implementation, documentation, evaluation), the methods analysts use to gather requirements, and the four ways to switch from an old system to a new one.
Mapped to the Cambridge IGCSE 0478 syllabus (2026-2028).
Analysis → design → develop & test → implement → evaluate.
The SDLC (System Development Lifecycle) is the structured sequence of stages a professional software project follows.
1. Analysis. The analyst studies the existing system (if any) and gathers requirements. Output: a clear specification of WHAT the new system must do. Methods: interviews, observation, questionnaires, document inspection.
2. Design. The designer plans HOW the system will work — data structures, file/database design, input forms, output reports, validation rules, algorithm flowcharts, screen layouts. Output: design documents and prototypes.
3. Development. The programmer writes the code following the design.
4. Testing. The system is tested with normal, abnormal, boundary and extreme data. Bugs are fixed; tests are repeated until the system passes.
5. Implementation. The system goes live. Includes user training, data migration and CHANGEOVER from the old system.
6. Documentation. Two flavours — USER documentation (how to operate the system) and TECHNICAL documentation (how the system is built, for maintainers and future developers).
7. Evaluation. The system is reviewed against the original requirements. Successes and shortcomings feed into the next iteration.
Cambridge tip. Mark schemes name analysis, design, testing, implementation and evaluation explicitly. Documentation is sometimes folded into implementation. Always include the EVALUATION step — students often forget it.
See the full worked example for system development lifecycle →
Interviews, observation, questionnaires, document inspection.
In the analysis stage, the analyst needs to UNDERSTAND the existing system and the new requirements. Four standard methods:
Interviews. One-on-one conversations with users, managers, stakeholders. Strength: detailed, can probe for clarification. Weakness: time-consuming, biased by interviewer style.
Observation. Watching users perform tasks in the existing system. Strength: reveals what users ACTUALLY do (often different from what they say they do). Weakness: users may behave differently when watched.
Questionnaires. Standardised written questions distributed to many users. Strength: cheap to scale; large samples possible. Weakness: limited depth; response rates vary; ambiguous questions ruin the data.
Document inspection. Examining the existing system's paperwork, manuals, reports, screens. Strength: reveals what the system formally does and what it produces. Weakness: documents may be out of date; doesn't capture informal practices.
Cambridge tip. Mark scheme rewards naming the method PLUS one strength AND one weakness. Don't just list methods — characterise each one.
See the full worked example for system development lifecycle →
Direct, parallel, phased, pilot — speed vs risk vs cost.
Once the new system is built and tested, the OLD one needs to be replaced. Four methods:
Direct changeover. Old system off; new system on. Fastest, cheapest to deploy; highest risk — if the new system fails, there's no fallback. Suitable when the systems can't run side-by-side, time is critical, or the old system has stopped working.
Parallel changeover. Both systems run simultaneously until the new one is proven reliable. Safest — easy to revert to the old system if needed; outputs can be compared for accuracy. Most expensive — both systems' running costs are paid simultaneously; users have to do everything twice.
Phased changeover. New system introduced one component at a time (e.g. payments first, then accounts, then reporting). Reduces risk per phase; lets users adjust gradually. Slower overall.
Pilot changeover. New system rolled out to ONE location/department first; if successful, rolled out elsewhere. Limits early-failure damage. Slower; the pilot site bears the disruption.
| Method | Speed | Risk | Cost |
|---|---|---|---|
| Direct | Fast | High | Low |
| Parallel | Slow | Low | High |
| Phased | Medium | Medium | Medium |
| Pilot | Medium | Low/Medium | Medium |
Cambridge tip. Mark schemes typically expect at least direct, parallel and one of phased/pilot — with a stated trade-off for each.
See the full worked example for system development lifecycle →
Different audiences need different content.
User documentation is for the people who USE the system day to day. Contents include:
Technical documentation is for the people who MAINTAIN and EXTEND the system. Contents include:
Cambridge tip. When asked, name BOTH and give example contents. Mark schemes love specificity ('user docs include screenshots and step-by-step walkthroughs').
Verbatim phrases and definitions Cambridge mark schemes credit.
SDLC appears on every Paper 2. Most-tested questions: stages of the SDLC (8 marks), changeover methods (6 marks), info-gathering with strengths and weaknesses (6 marks). Examiner reports flag candidates who skip analysis or evaluation as the most common error.
Sources: Cambridge IGCSE Computer Science 0478 syllabus (2026-2028); 0478 Examiner Reports 2022-2024; 0478/22 May/Jun 2024 question paper and mark scheme. Last reviewed 2026-05-09.
Step-by-step solutions to past-paper-style questions on system development lifecycle, written exactly the way a tutor would explain them at the board.
Question
State the FOUR stages of the program development life cycle, in the order they are normally carried out. (2 marks)
Step-by-step solution
Step 1
Recall the standard 0478 list — the four stages are analysis, design, coding, testing.
Step 2
Give them in order. The order matters: you cannot design before you know the requirements (analysis), and you cannot test before code exists (coding).
Answer
Examiner tip
A list question — no description needed. Marks are lost only for missing a stage or putting design before analysis.
Question
Explain the purpose of the DESIGN stage of the program development life cycle. (2 marks)
Step-by-step solution
Step 1
Pin down what design is FOR: it plans HOW the program will solve the problem identified in analysis, before any code is written.
Step 2
Name the deliverables that show this planning — the solution is broken down (structure diagram) and the logic is set out (flowchart / pseudocode), ready for the coding stage.
Answer
The design stage plans HOW the program will work (1) — it breaks the problem into sub-tasks and sets out the logic using tools such as structure diagrams, flowcharts and pseudocode so the program can be coded from a clear plan (1).
Examiner tip
Contrast with analysis (WHAT the program must do) vs design (HOW it will do it). Naming a design tool secures the second mark.
Question
A programmer is designing a solution to a problem. Identify THREE design tools the programmer could use and state what each one shows. (3 marks)
Step-by-step solution
Step 1
Structure diagram (1 mark). Shows top-down decomposition — the problem broken into sub-problems / modules arranged in a hierarchy.
Step 2
Flowchart (1 mark). Shows the flow of control through the solution using standard boxes (process, decision, input/output) joined by arrows.
Step 3
Pseudocode (1 mark). Sets out the algorithm in structured English-like statements (e.g. loops, IF…THEN…ELSE) that are close to code but not tied to a programming language.
Answer
Structure diagram (decomposition into sub-problems), flowchart (flow of control via standard symbols), pseudocode (algorithm in structured English-like statements).
Examiner tip
One mark each, but the mark is only earned if WHAT the tool shows is stated — naming the tool alone is not enough.
Question
For each activity, state which stage of the program development life cycle it belongs to: (a) writing program code in Python, (b) drawing a structure diagram, (c) running the program with abnormal data, (d) identifying the inputs, processes and outputs required. (4 marks)
Step-by-step solution
Step 1
(a) Writing program code in Python → Coding (the design is turned into a working program in a programming language).
Step 2
(b) Drawing a structure diagram → Design (a design tool used to plan the solution).
Step 3
(c) Running the program with abnormal data → Testing (checking the program behaves correctly, here with rejected/invalid data).
Step 4
(d) Identifying the inputs, processes and outputs required → Analysis (working out WHAT the program must do).
Answer
(a) Coding (b) Design (c) Testing (d) Analysis. (1 mark each.)
Examiner tip
Classic discriminator: students mislabel (d) as design. Identifying requirements (the I-P-O of the problem) is ANALYSIS; planning HOW to meet them is design.
Question
During testing, a program crashes when a negative number is entered. Explain how the stages of the program development life cycle interact to fix this, referring to iterative refinement. (5 marks)
Step-by-step solution
Step 1
Testing has revealed an error (the crash on negative input) — this is exactly the purpose of the testing stage: to expose faults before the program is released.
Step 2
Control loops BACK to the coding stage: the programmer edits the code to handle negative input (e.g. add validation that rejects negatives, or change the algorithm to use the absolute value).
Step 3
If the fault is more fundamental (the requirement for negatives was never planned), control may loop back further to the DESIGN stage to update the flowchart/pseudocode, and occasionally to ANALYSIS if the requirements themselves were wrong.
Step 4
After re-coding, the program is RE-TESTED with the same negative-number data, plus normal and boundary data, to confirm the fix works and has not introduced new faults (regression).
Step 5
This loop of test → refine → re-test is iterative refinement — the stages repeat in cycles until the program meets all its requirements, rather than running once in a straight line.
Answer
Testing finds the error → loop back to coding (add validation / fix algorithm) → possibly back to design/analysis if the requirement was missed → re-test with normal, abnormal and boundary data → repeat until the program is correct. This repeating cycle is iterative refinement.
Examiner tip
Top marks need the FEEDBACK direction made explicit (testing → coding, not just 'fix it') and the re-test step. Mentioning regression / boundary data shows AO2 understanding.
Question
Describe the FOUR stages of the program development life cycle and state the purpose of each. (8 marks)
Step-by-step solution
Step 1
Analysis (2 marks). The problem is studied and the requirements are worked out — the inputs, processes and outputs the program needs. Purpose: establish WHAT the program must do before any solution is planned.
Step 2
Design (2 marks). The solution is planned using design tools — structure diagrams (decomposition), flowcharts and pseudocode. Purpose: set out HOW the program will work / its algorithm before coding begins.
Step 3
Coding (2 marks). The design is translated into program code in a chosen programming language (e.g. Python). Purpose: produce a working program that implements the designed algorithm.
Step 4
Testing (2 marks). The program is run with test data — normal, abnormal and boundary — and the actual results are compared with expected results. Purpose: find and remove errors so the program works correctly, looping back to earlier stages if faults are found.
Answer
Analysis (find requirements — WHAT) → Design (plan the solution with structure diagrams/flowcharts/pseudocode — HOW) → Coding (turn the design into program code) → Testing (run with normal/abnormal/boundary data to find and remove errors). 1 mark for naming + 1 mark for purpose in each stage.
Examiner tip
Mark scheme awards 1 for the stage and 1 for its purpose, ×4. A bare list (the 2-mark question) scores half. Use the WHAT/HOW contrast for analysis vs design to avoid the common merge.
High-scoring sample answers for system development lifecycle on the Cambridge IGCSE 0478 paper, with examiner-style notes mapping each response to the mark scheme and assessment objectives.
State the stage of the program development life cycle in which a design is turned into a working program in a programming language. [1]
Model answer
Coding (also accept: programming / writing the code).
Why this scores
1 mark (AO1 recall): identifying the coding stage. 'Implementation' is not accepted here — in 0478 Paper 2 the stage is called coding.
Explain the purpose of the testing stage of the program development life cycle. [2]
Model answer
The testing stage runs the program to check it works correctly (1) by finding and removing errors / confirming the actual output matches the expected output for the test data (1).
Why this scores
2 marks (AO1×1, AO2×1): mark 1 for 'check the program works / is correct'; mark 2 for the mechanism — finding errors or comparing actual vs expected results. 'To make it work' alone is too vague for the second mark.
Testing uses different types of test data. Identify the THREE types of test data and give one example of each for a field that should accept a whole number from 1 to 100. [3]
Model answer
Normal data — a value the program should accept, e.g. 50 (1). Abnormal data — a value the program should reject, e.g. 150 or 'cat' (1). Boundary data — a value on the edge of the accepted range, e.g. 1 or 100 (1).
Why this scores
3 marks (AO2): 1 per correctly named type WITH a valid example. An example alone, or a type with a wrong example (e.g. boundary 'given as 50'), scores 0 for that line.
In the design stage a programmer can use a structure diagram, a flowchart and pseudocode. Describe what each of these design tools is used for. [5]
Model answer
Structure diagram: shows the breakdown / decomposition of the problem into smaller sub-problems or modules arranged in a top-down hierarchy (1), making the structure of the solution clear (1). Flowchart: shows the flow of control / order of steps through the solution using standard symbols (process, decision, input/output) connected by arrows (1). Pseudocode: sets out the algorithm as structured statements close to a programming language but not specific to one (1), e.g. using IF…THEN…ELSE and loops to express the logic before coding (1).
Why this scores
5 marks (AO1/AO2): up to 2 for structure diagram (decomposition + hierarchy), 1 for flowchart (flow of control with standard symbols), up to 2 for pseudocode (language-independent algorithm + example of structured constructs). Capped at 5 — cannot earn all of every bullet.
Describe how the four stages of the program development life cycle relate to one another, including how iterative refinement is used. [6]
Model answer
The stages are normally carried out in order: analysis → design → coding → testing (1). Analysis identifies what is required, which is then used to plan the solution in design (1); the design (structure diagram / flowchart / pseudocode) is the basis for the program written in the coding stage (1); the coded program is then run in the testing stage (1). The stages are not strictly one-way: when testing finds an error, control loops back to coding, and if a deeper problem is found it can loop back to design or even analysis (1). The program is then re-tested, and this test–refine–re-test loop is repeated — iterative refinement — until the program meets all its requirements (1).
Why this scores
6 marks (AO1/AO2/AO3): up to 4 for the forward links between the four stages (each output feeding the next), 1 for the feedback/loop-back direction on finding errors, 1 for naming/explaining iterative refinement as a repeating cycle until requirements are met. Must show feedback as well as the linear flow to reach full marks.
Describe the four stages of the program development life cycle and explain the purpose of each stage. [8]
Model answer
Analysis — the problem is examined and the requirements are determined, including the inputs, processes and outputs needed (1); its purpose is to establish WHAT the program must do before any solution is planned (1). Design — the solution is planned using design tools such as a structure diagram, a flowchart and pseudocode (1); its purpose is to set out HOW the program will work / its algorithm before coding starts (1). Coding — the design is translated into program code written in a programming language such as Python (1); its purpose is to produce a working program that implements the designed algorithm (1). Testing — the program is run with normal, abnormal and boundary test data and the actual results are compared with the expected results (1); its purpose is to find and remove errors so the program works correctly, looping back to earlier stages if faults are found (1).
Why this scores
8 marks (AO1/AO2): 2 per stage = 1 for a correct description of the activity + 1 for its purpose. Common loss: merging analysis and design — keep WHAT (analysis) separate from HOW (design). A bare list of the four names scores a maximum of 4 (descriptions) and 0 for purpose.
Definitions to memorise and the exact keywords mark schemes credit for system development lifecycle answers — sharpened from recent examiner reports for the 2026 0478 sitting.
The four stages used to develop a program — analysis, design, coding, testing — carried out in order and repeated through iterative refinement until the program meets its requirements.
The stage where the design is translated into program code in a programming language. Purpose: produce a working program from the planned algorithm.
The stage where the program is run with test data and actual results are compared with expected results to find and remove errors. Uses normal, abnormal and boundary data.
Repeating the test → refine → re-test loop, looping back from testing to coding (or design/analysis), until the program meets all its requirements.
A design tool that shows top-down decomposition — the problem broken into sub-problems / modules arranged in a hierarchy.
A design tool that shows the flow of control through a solution using standard symbols (process, decision, input/output) joined by arrows.
A design tool that sets out an algorithm in structured English-like statements (IF…THEN…ELSE, loops) that are close to code but not tied to a specific programming language.
Test data types: normal = values the program should accept; abnormal = values it should reject; boundary = values on the edge of the accepted range.
A structured sequence of stages used to develop a new system or replace an existing one. Typical stages: analysis, design, development, testing, implementation, documentation, evaluation.
The stage where requirements are gathered and documented — the inputs, processes and outputs the program needs. Establishes WHAT the program must do.
The stage where HOW the program/system will work is planned using structure diagrams, flowcharts and pseudocode — algorithms, data structures, screens, validation rules.
The stage where the system goes live and users start working with it. May include training and changeover from the old system.
The transition from the old system to the new one. Methods: direct, parallel, phased, pilot.
Old system switched off; new system goes live immediately. Fast and cheap; highest risk.
Both systems run simultaneously until the new system is proven reliable. Safest; most expensive.
New system introduced one component at a time. Lower risk per phase; longer overall.
New system rolled out to ONE location/department first; if successful, rolled out everywhere.
Written records that support the system — user documentation (how to operate the system) and technical documentation (how the system is built, for maintainers).
Comparing the actual system against the original requirements after it's been in use; identifies improvements for the next iteration.
The traps other students keep falling into on system development lifecycle questions — taken from recent Cambridge IGCSE 0478 examiner reports and mark schemes — and how to avoid them.
0478 Examiner Reports 2022-2024
Why it happens
Both feel like planning, so students blur them together.
How to avoid it
ANALYSIS = WHAT the program must do (the requirements / inputs, processes, outputs). DESIGN = HOW it will do it (structure diagram, flowchart, pseudocode). Use the WHAT-vs-HOW test on every activity.
Why it happens
The list is taught in a straight line: analysis → design → coding → testing.
How to avoid it
Testing loops BACK to coding (and sometimes design/analysis) when errors are found, then the program is re-tested. This repeating loop is iterative refinement — name it for the higher-tariff marks.
Why it happens
Questions ask to 'identify a design tool', so students stop at the name.
How to avoid it
Mark schemes pair the tool with its use: structure diagram = decomposition, flowchart = flow of control, pseudocode = language-independent algorithm. State the use to earn the mark.
0478 Examiner Reports 2022-2024
Why it happens
Students assume coding/design is the 'real work'.
How to avoid it
Without ANALYSIS (gathering requirements first), you don't know WHAT to design. Skipping it leads to building the wrong thing — a frequent project failure.
Why it happens
Both involve overlapping use of two systems.
How to avoid it
PARALLEL = both ENTIRE systems run at once. PHASED = parts of the new system replace parts of the old, one piece at a time. PILOT = entire new system in one LOCATION first.
Why it happens
Students stop at 'implementation = done'.
How to avoid it
EVALUATION feeds learning back. Mark schemes for SDLC questions reward listing it explicitly.
Why it happens
'Documentation' as one word.
How to avoid it
USER docs = how to OPERATE the system. TECHNICAL docs = how the system is BUILT (for maintainers and future developers). Different audiences, different content.
The things students keep getting wrong in this sub-topic, answered.