What is the System Development Lifecycle in the context of Cambridge IGCSE Computer Science?

The System Development Lifecycle (SDLC) is a structured process used in Cambridge IGCSE Computer Science to develop information systems. It involves several stages, including planning, analysis, design, implementation, testing, and maintenance. Each stage has specific tasks and deliverables that help ensure the successful development and deployment of a system.

Why is the System Development Lifecycle important in algorithm design and problem-solving?

The System Development Lifecycle is crucial in algorithm design and problem-solving because it provides a systematic approach to understanding and addressing complex problems. By following the SDLC stages, developers can ensure that algorithms are well-designed, tested, and implemented effectively, leading to reliable and efficient systems.

What are the key stages of the System Development Lifecycle?

The key stages of the System Development Lifecycle include: 1) Planning, where project goals and feasibility are assessed; 2) Analysis, where requirements are gathered and analyzed; 3) Design, where system architecture and algorithms are developed; 4) Implementation, where the system is built and coded; 5) Testing, where the system is rigorously tested for errors; and 6) Maintenance, where the system is updated and improved over time.

How does testing fit into the System Development Lifecycle?

Testing is a critical stage in the System Development Lifecycle that ensures the system meets the specified requirements and functions correctly. It involves various types of testing, such as unit testing, integration testing, and user acceptance testing, to identify and fix errors or bugs in the system. Effective testing helps improve the quality and reliability of the final product.

What role does maintenance play in the System Development Lifecycle?

Maintenance is the final stage of the System Development Lifecycle, where the system is monitored and updated to adapt to changing user needs and technological advancements. It involves fixing any issues that arise, enhancing system features, and ensuring the system remains efficient and relevant over time. Maintenance is essential for the long-term success and sustainability of a system.

Why is "Starting with 'design' instead of 'analysis'" a common mistake in System Development Lifecycle?

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. Source: 0478 Examiner Reports 2022-2024

Why is "Confusing parallel and phased changeover" a common mistake in System Development Lifecycle?

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 is "Forgetting evaluation as the final stage" a common mistake in System Development Lifecycle?

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 is "Confusing user and technical documentation" a common mistake in System Development Lifecycle?

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.

Algorithm design and problem-solvingCambridge IGCSE Computer Science (0478)

System Development Lifecycle

Work through the notes, try the practice questions, then take the quiz. The report tells you exactly what to revise next.

PreviousNext

Learn this Topic

Start with the slides for the quick version, then go deeper with the full study notes.

Short Study Notes in the form of Slides

Read the notes first. If the method in a worked example clicks, you're ready for the questions.

Page 1 / 0

Detailed Study Notes

Full prose, callouts and a recap — built for A* mastery, not just a quick scan.

Take these study notes with you

Download a branded PDF — full prose, callouts, recap and memorise list for System Development Lifecycle, ready to print or save offline.

System Development Lifecycle Study Notes — Cambridge IGCSE Computer Science 0478 (2026-2028 syllabus)

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.

What you’ll learn

Mapped to the Cambridge IGCSE 0478 syllabus (2026-2028).

1.16.1 — Identify and describe the stages of the SDLC.
1.16.2 — Identify methods of gathering information.
1.16.3 — Identify changeover methods and their trade-offs.
1.16.4 — Distinguish user and technical documentation.

The stages of the lifecycle

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.

Seven stages (some texts merge documentation and implementation).
Analysis comes FIRST — gather requirements before designing.
Evaluation comes LAST — feeds back into improvement.

See the full worked example for system development lifecycle →

Information-gathering methods

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.

Four methods: interviews, observation, questionnaires, document inspection.
Each has a strength + a weakness.
Use combinations — they catch different aspects.

See the full worked example for system development lifecycle →

Changeover methods

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.

Four methods: direct, parallel, phased, pilot.
Always mention trade-offs (speed, risk, cost).
Parallel is the safest; direct is the fastest.

See the full worked example for system development lifecycle →

User vs technical documentation

Different audiences need different content.

User documentation is for the people who USE the system day to day. Contents include:

How to install / log in.
How to perform each task.
Screenshots and walkthroughs.
Error messages and what to do about them.
Glossary of terms.
FAQ / troubleshooting.

Technical documentation is for the people who MAINTAIN and EXTEND the system. Contents include:

System architecture and module breakdown.
Data structures, file/database schema, algorithm descriptions.
API documentation.
Variable / function naming conventions.
Test plans and test results.
Deployment instructions.

Cambridge tip. When asked, name BOTH and give example contents. Mark schemes love specificity ('user docs include screenshots and step-by-step walkthroughs').

User docs — how to OPERATE.
Technical docs — how the system is BUILT.
Different audiences; different contents.

How it’s examined

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.

Master this Topic

Worked examples, formulae, definitions and the mistakes examiners flag — everything you need to push from a pass to an A*.

Take this whole topic with you

Download a branded revision sheet — worked examples, formulae, definitions and common mistakes for System Development Lifecycle, ready to print or save as PDF.

Step-by-step worked examples — System Development Lifecycle

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.

1Stages of the system development lifecycle (8 marks)
Extended• Adapted from 0478/22 May/Jun 2024 Q1• sdlc
Question
Identify and describe FOUR stages of the system development lifecycle. (8 marks)
Step-by-step solution
1. Step 1
  Analysis (2 marks). The analyst studies the EXISTING system (if any) and gathers requirements through interviews, observation, questionnaires and document inspection. Output: a clear specification of WHAT the new system must do.
2. Step 2
  Design (2 marks). The designer plans HOW the system will work — data structures, file/database design, input forms, output reports, validation rules, algorithm flowcharts. Output: design documents and prototypes.
3. Step 3
  Development and testing (2 marks). The programmer writes the code following the design and tests with normal, abnormal and boundary data. Bugs are fixed; tests are repeated until the system passes.
4. Step 4
  Implementation and evaluation (2 marks). The system is rolled out to users (direct, parallel, pilot or phased changeover). Documentation is prepared. After use, the system is evaluated against the original requirements and any issues feed into the next iteration.
Answer
Analysis → design → development & testing → implementation & evaluation. (Other valid: feasibility study, training, maintenance.)
2Compare changeover methods (6 marks)
Extended• changeover
Question
Describe THREE methods of changeover from an old system to a new system. (6 marks)
Step-by-step solution
1. Step 1
  Direct changeover (2 marks). Old system is switched off; new system goes live immediately. Fastest and cheapest. Highest risk — if the new system fails, there's no backup.
2. Step 2
  Parallel changeover (2 marks). Both systems run side-by-side until the new is proven reliable. Safest but most expensive — both systems' costs are paid simultaneously.
3. Step 3
  Phased changeover (2 marks). New system is introduced one part at a time. Reduces risk per phase; takes longer overall.
Answer
Direct (instant + risky), parallel (safe + expensive), phased (gradual + slow). PILOT changeover (one location/department first) is also valid.
3Information-gathering methods (6 marks)
Extended• analysis
Question
Describe THREE methods an analyst can use to gather information about an existing system. (6 marks)
Step-by-step solution
1. Step 1
  Interviews (2 marks). One-on-one conversations with users / stakeholders. Detailed responses; can probe for clarification. Time-consuming and biased by interviewer style.
2. Step 2
  Observation (2 marks). Watching users perform tasks in the existing system. Reveals what users actually do (often different from what they say they do). Users may behave differently when watched.
3. Step 3
  Questionnaires (2 marks). Standardised questions distributed to many users. Cheap; lets you survey a large sample. Limited depth; response rates vary; ambiguous questions ruin the data.
Answer
Interviews (depth), observation (reality), questionnaires (scale). DOCUMENT INSPECTION is a fourth common method.

Key Definitions and Keywords — System Development Lifecycle

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.

System Development Lifecycle (SDLC)
Examiner keyword
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.
Analysis
Examiner keyword
The stage where requirements are gathered and documented. Includes studying the existing system, identifying problems, defining what the new system must do.
Design
Examiner keyword
The stage where HOW the system will work is planned — data structures, screens, algorithms, validation rules.
Implementation
The stage where the system goes live and users start working with it. May include training and changeover from the old system.
Changeover
Examiner keyword
The transition from the old system to the new one. Methods: direct, parallel, phased, pilot.
Direct changeover
Examiner keyword
Old system switched off; new system goes live immediately. Fast and cheap; highest risk.
Parallel changeover
Examiner keyword
Both systems run simultaneously until the new system is proven reliable. Safest; most expensive.
Phased changeover
Examiner keyword
New system introduced one component at a time. Lower risk per phase; longer overall.
Pilot changeover
Examiner keyword
New system rolled out to ONE location/department first; if successful, rolled out everywhere.
Documentation
Examiner keyword
Written records that support the system — user documentation (how to operate the system) and technical documentation (how the system is built, for maintainers).
Evaluation
Comparing the actual system against the original requirements after it's been in use; identifies improvements for the next iteration.

Common Mistakes and Misconceptions — System Development Lifecycle

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.

✕Starting with 'design' instead of 'analysis'
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.
✕Confusing parallel and phased changeover
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.
✕Forgetting evaluation as the final stage
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.
✕Confusing user and technical documentation
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.

Practice questions

Exam-style questions with step-by-step worked solutions. Try one before checking the method.

Past paper style quiz

Get a report showing which sub-topics you've nailed and which ones still need work.

System Development Lifecycle — frequently asked questions

The things students keep getting wrong in this sub-topic, answered.

System Development Lifecycle

Short Study Notes in the form of Slides

Detailed Study Notes

What you’ll learn

How it’s examined

1Stages of the system development lifecycle (8 marks)

2Compare changeover methods (6 marks)

3Information-gathering methods (6 marks)

System Development Lifecycle (SDLC)

Analysis

Design

Implementation

Changeover

Direct changeover

Parallel changeover

Phased changeover

Pilot changeover

Documentation

Evaluation

✕Starting with 'design' instead of 'analysis'

✕Confusing parallel and phased changeover

✕Forgetting evaluation as the final stage

✕Confusing user and technical documentation

Practice questions

Past paper style quiz

Assess your understanding

System Development Lifecycle — frequently asked questions