[7.1] Program development life cycle

The Programme Development Life Cycle

From problem to working solution

The programme development life cycle (PDLC) is a structured set of stages that guides teams from an initial problem to a tested, working solution. At IGCSE level you should be able to describe what happens at each stage, recognise common documents produced, and explain why skipping steps leads to defects, delays, and extra cost. Although real organisations may use different methods, the essential stages are consistent: analysis, design, coding, and testing. This page explains the purpose of each stage and how they fit together in practice.

The PDLC is not always strictly linear. Teams may iterate: feedback from testing can uncover missing requirements, design constraints can influence analysis, and coding lessons can refine designs. What matters is that each stage has clear goals and outputs so the next stage starts with reliable information.

Stage 1: Analysis

Understanding the problem and requirements

Analysis is about discovering and documenting what the solution must do. The focus is on the problem domain and user needs, not on how the code will be written. Good analysis avoids later rework by clarifying assumptions early.

Inputs: interviews with stakeholders, observation of current processes, any existing forms or data, policies, and constraints such as budget or deadlines.
Outputs: a requirements specification that lists functional requirements (what the system must do) and non-functional requirements (qualities like performance, security, usability, and reliability). It may also include user stories, data requirements, and acceptance criteria.
Success criteria: clear, testable statements that will later guide acceptance testing, e.g. “The system must calculate weekly pay with tax and National Insurance deductions for up to 1,000 employees within 10 seconds.”

Exam tip: If a scenario mentions stakeholders who disagree, you should recommend resolving conflicts during analysis, not by guessing in the design or coding stages.

Stage 2: Design

Planning the solution before writing code

Design converts requirements into a solution plan. This stage reduces risk by making decisions about structure, data, and interaction before coding. Designs should be clear and traceable to the analysis outputs.

Algorithm design: structured English, flowcharts, or pseudocode that describe the steps to solve each requirement.
Data design: identifying the data structures (e.g. arrays, records), file formats, and validations.
User interface design: screen layouts, error messages, and navigation logic. The aim is to support usability requirements.
System architecture: how components interact, including inputs, processing, storage, and outputs.

A strong design makes coding faster and testing more reliable. It also improves communication in a team because each member can work from the same blueprint.

Contrasting design choices

Validation checks whether input data is reasonable at the point of entry, such as range checks and presence checks. Verification checks that data has been transferred or copied correctly, such as double entry or parity-like checks when moving files. Both are planned during design so they can be implemented consistently in coding and confirmed during testing.

Black-box testing designs test cases from the specification without seeing the internal code. It focuses on inputs and expected outputs. White-box testing uses knowledge of the internal structure to ensure each path or branch is exercised. During design you can plan both: black-box tests from requirements and white-box tests from algorithm flowcharts.

An array (list) is best for a simple sequence of similar items, such as daily temperatures. A record groups different fields for one entity, such as a student’s Name, Form, and Average Mark. Choosing well at design time simplifies coding and prevents logic errors later.

Stage 3: Coding

Translating designs into a working program

Coding is where programmers implement the designed algorithms in a programming language. At IGCSE, your language may be Python or another high-level language, but the principles are the same: follow the design, name variables clearly, and keep modules small and testable.

Good practices: consistent naming, meaningful comments, and decomposition into procedures and functions that each have a single responsibility.
Defensive programming: input validation, sensible defaults, and clear error messages to prevent run-time failures.
Traceability: each piece of code should map to a design element and a requirement. This makes reviews and testing easier.

Common pitfall: jumping into coding with only a vague idea. Without a design, programs become hard to test and extend, and subtle logic errors are more likely.

Stage 4: Testing

Providing evidence that the solution works

Testing shows that the programme meets the specification and behaves reliably with normal and extreme data. Testing should be planned from the start, using the requirements as a guide. You should know the main levels of testing and the types of test data to use.

Levels of testing: purpose and examples

Unit testing checks small parts, such as a function that calculates a discount. It finds local logic errors before they spread. Evidence might include a table listing input values and expected outputs for the function.

Integration testing verifies that units work together, e.g. the discount function and the receipt printing procedure share data correctly. This can reveal interface problems like wrong parameter order or missing conversions.

System testing checks the whole application against the specification. Acceptance testing is performed with stakeholders to confirm the solution meets their needs in realistic conditions. Acceptance criteria should come from the analysis stage.

Test data categories

Normal data are typical, valid values that the programme expects most of the time. They confirm the usual path works, e.g. a valid age of 16 for a cinema ticket system.

Boundary data are values at the edges of the valid range or just inside/outside them. They reveal off-by-one and comparison mistakes, e.g. testing 0, 1, and −1 when the minimum allowed number is 0.

Erroneous data are invalid inputs that the system should reject gracefully, such as letters where a number is required. Good programmes give helpful error messages and do not crash.

Putting it together: a small case study

Canteen pre-order application

Imagine a school wants a simple application for students to pre-order lunches. During analysis, you discover stakeholders (students, kitchen staff, bursar) and list requirements: select items, show allergens, limit orders to before 9:30, and produce a daily summary for the kitchen. In design, you plan a menu screen, a data structure for items with price and allergens, validation so orders cannot be placed after the cut-off, and a summary report grouped by item. In coding, you implement modules that match the design, e.g. a function to calculate totals and a procedure to output the summary. In testing, you create normal cases (orders at 9:00), boundary cases (orders exactly at 9:30), and erroneous cases (blank student ID). You would expect acceptance criteria like “Staff can print a correct summary by 10:00”.

This case study shows how each stage supports the next. If the acceptance test fails because allergen information is missing, the team revisits analysis to add the requirement and then updates design, coding, and tests accordingly.

Key terminology

Term	Definition
Requirements specification	A document listing what the solution must do and the qualities it must have.
Functional requirement	A behaviour or feature of the system, e.g. “calculate total price”.
Non-functional requirement	A quality constraint such as performance, security, or usability.
Validation	Automatic checks that input data is reasonable before processing.
Verification	Checks that data is copied or transferred accurately.
Unit/integration/system/acceptance testing	Testing at component, combined, whole-system, and stakeholder sign-off levels.
Test plan	A table of test cases with inputs, expected results, and actual results.

Key Takeaways

The PDLC stages are analysis, design, coding, and testing; each has clear goals and outputs.
Good analysis creates testable requirements and acceptance criteria that guide the whole project.
Careful design of algorithms, data, and interfaces reduces coding mistakes and simplifies testing.
Coding should follow the design, use clear structure, and include defensive checks for invalid input.
Testing uses normal, boundary, and erroneous data across unit, integration, system, and acceptance levels to provide evidence of correctness.
Iteration is normal: findings in testing can lead to refined analysis and updated designs.