7.1 Program Development Life Cycle - IGCSE Computer Science

Learning Objectives

By the end of this lesson, you will be able to:

Describethe program development life cycle (SDLC) and name its four stages: analysis, design, coding and testing
Explainwhat happens during the analysis stage, including abstraction, decomposition, problem identification and requirements
Explainwhat happens during the design stage, including further decomposition, structure diagrams, flowcharts and pseudocode
Explainwhat happens during the coding stage, including writing program code and iterative testing
Explainwhat happens during the testing stage and how test data (normal, edge and invalid) is used
Applythe four stages to a complete worked example, such as a program to calculate the area of a rectangle
WriteCIE pseudocode and Python code for a simple problem that has been analysed and designed

Key Terms

Program Development Life Cycle (SDLC)

The set of distinct phases a programmer works through when developing a solution to a problem for a computer system.

Analysis

The stage where the problem is precisely understood before any solution is designed.

Abstraction

Removing unimportant details from a problem so you can focus on the important elements, such as core functionality and requirements.

Decomposition

Breaking a large problem down into smaller, more manageable sub-problems.

Problem Identification

Clearly defining the problem statement and understanding what the end user actually needs.

Requirements

A document that defines the problem and breaks it into clear, manageable parts. Each requirement is labelled, described and given success criteria.

Success Criteria

A statement explaining how you will know that a requirement has been met.

Design

The stage where techniques are used to produce a blueprint for the solution.

Structure Diagram

A diagram (such as a UML class diagram) that shows how the parts of a program are organised and related.

Flowchart

A diagram showing the flow of control in a program, including decision points, loops and actions.

Pseudocode

A high-level, human-readable description of program logic that does not worry about the exact syntax of a language.

Coding

Translating the design into actual program code using a programming language.

Iterative Testing

Testing each module as it is written, finding and fixing bugs, then retesting as new modules are added.

Debugging

Identifying and correcting errors (bugs) found in a program.

Testing

Running the finished program many times with different sets of test data to check it works as intended.

Test Data

Sets of input data chosen to cover a wide range of scenarios, including normal, edge and invalid cases.

Normal Test Data

Typical, sensible data that the program is expected to accept.

Edge (Boundary) Test Data

Data at the very limits of what is allowed (for example the smallest or largest acceptable value).

Invalid (Erroneous) Test Data

Data that should be rejected by the program, such as letters where numbers are expected.

1. Software Development Life Cycle — Overview

When developing a solution to a problem for a computer system, programmers work through a number ofdistinct phases. Together these phases are known as thesoftware development lifecycle (SDLC)— sometimes called theprogram development life cycle.

For Cambridge IGCSE you only need to know thefour main stages:

1. Analysis

Abstraction
Problem decomposition
Problem identification
Requirements

2. Design

Further decomposition
Structure diagrams
Flowcharts
Pseudocode

3. Coding

Writing program code
Iterative testing

4. Testing

Testing program code
Using test data

Interactive: The SDLC Cycle

The four stages are often drawn as a cycle because testing may reveal a problem that sends the developer back to analysis or design.Click any quadrantto see the key tasks for that stage.

AnalysisAbstraction · Decomposition
Identification · Requirements

DesignDecomposition · Structure diagrams
Flowcharts · Pseudocode

CodingWriting program code
Iterative testing

TestingTesting program code
Using test data

Click a stage aboveto explore what happens during that part of the life cycle.

Why a cycle?Developers rarely get everything right first time. Iterative testing during coding, and full testing at the end, can send the developer back to an earlier stage to fix a design or clarify a requirement.

Real-Life Example: Building a School Canteen Ordering App

Imagine your school wants an app where students pre-order lunch.

Analysis:Who will use it? What must it do? (take an order, show a menu, record payment). What can we ignore? (the colour of the canteen walls)
Design:Break it into modules — menu display, order entry, payment check. Draw a structure diagram and write pseudocode for the order entry module.
Coding:Programmers write each module in Python and test each one as it is finished.
Testing:Run the app with real menu prices, a zero-price item, and with letters typed where a number is expected.

Activity 1: Naming the Stages

A programmer is asked to write a program that works out a student's average mark from five test scores. Match each task below to the correct SDLC stage (analysis, design, coding or testing).

Deciding that only the five marks and the total are needed, and that the student's name is not relevant.
Writing a flowchart showing how the marks are read in and added together.
Typing the program into Python and running it after each function is written.
Running the program with the marks 0, 0, 0, 0, 0 to check it does not crash.
Writing a document listing what the program must do and how you will know it is finished.
Breaking the problem into "read marks" and "calculate average" sub-problems.

Solution:

Analysis— this is abstraction (removing unimportant details to focus on core functionality).
Design— a flowchart is a design technique.
Coding— writing program code and carrying out iterative testing as each part is written.
Testing— using edge-case test data on the finished program.
Analysis— producing the requirements document with success criteria.
Analysis— decomposition of the problem into manageable sub-problems.

Check Your Understanding: SDLC Overview

1. Name the four stages of the program development life cycle. [4 marks]

Answer

[1 mark]Analysis
[1 mark]Design
[1 mark]Coding
[1 mark]Testing
[Note]The order matters — analysis comes first because you must understand the problem before you can design a solution.

2. Why is the life cycle often drawn as a cycle rather than a straight line? [2 marks]

Answer

[1 mark]Because testing may reveal errors that mean the developer has to go back to an earlier stage
[1 mark]For example, a failed test may send the programmer back to the design stage to change the structure, or back to the coding stage to fix a bug
[Additional]Iterative testing during coding also means work constantly moves between coding and testing

3. Which stage of the SDLC produces a "blueprint" for the solution? [1 mark]

Answer

[1 mark]The design stage
[Explanation]During design, techniques such as structure diagrams, flowcharts and pseudocode are used to produce a blueprint that the programmer then turns into real code.

4. Explain what is meant by "iterative testing" and state which stage it belongs to. [3 marks]

Answer

[1 mark]Iterative testing happens during thecodingstage
[1 mark]Each module is tested and debugged thoroughly as it is written
[1 mark]Modules may need to be retested as new modules are created, to make sure they still interact correctly and do not cause errors
[Additional]The aim is to make sure each module accepts data without crashing or causing errors

5. A team is writing a program to control a school vending machine. Give one task the team would complete in the analysis stage and one task they would complete in the testing stage. [2 marks]

Answer

[1 mark] Analysis taske.g. identify what the vending machine must do and what it does not need to do (abstraction); break the problem into sub-problems (decomposition); produce a requirements document with success criteria
[1 mark] Testing taske.g. run the finished program with normal data (correct money inserted), edge data (exact price, empty stock) and invalid data (a foreign coin or a negative amount) to check it works as intended

6. A programmer skips the analysis and design stages and starts coding immediately. Give two problems this could cause. [2 marks]

Answer

[1 mark]The programmer may build the wrong solution because the problem was never properly understood
[1 mark]Requirements from the end user may be missed, so the program will not meet their needs
[Additional]Without a design there is no blueprint, so the code is harder to write, test and maintain, and more errors are likely

2. Stage 1 — Analysis

The purpose of theanalysisstage is toprecisely understand the problemthe program is intended to solve —beforeany solution is designed. It has four key tasks.

2.1 Abstraction

What is abstraction?

Abstractionis the act ofremoving unimportant detailsfrom the problem so that you can focus on theimportant elements, such as:

Core functionality
Requirements

Using abstraction helps to identify thefundamental componentsof what the program is going to solve.

Agreeing the goal

Before tackling a problem it needs to beclearly understood by everyone working on it. The team must agree on:

The overall goal of the solution
Anyconstraints, such as limited resources
Whether a platform-specific solution is required

Classic Example: The London Underground Map

The London Underground train route map is an example of abstraction. Travellers donotneed to know the true geographical layout of the routes — the real distances, curves and bends are all removed. All that matters is that getting on atstop Awill eventually transport you tostop B. The unimportant geographical detail has been stripped away so the important information (stations and connections) is easy to see.

2.2 Decomposition of the Problem

Decompositionmeansbreaking the problem down into smaller, manageable sub-problems. Instead of trying to solve one huge problem, the programmer solves several small ones. Each sub-problem is easier to understand, design, code and test.

Example: Decomposing a School Report Program

A program that produces end-of-term reports for 500 students could be broken into sub-problems:

Read in the student data
Validate that each mark is between 0 and 100
Calculate the average mark
Work out the grade from the average
Format and print the report

2.3 Identification of the Problem and Requirements

Problem identification

Clearly defining theproblem statementand understanding the requirementsfrom an end-user perspective. You must be able to say exactly what problem the program is solving and for whom.

Requirements document

To create a solution, arequirements documentis produced. It defines the problem and breaks it down into clear, manageable, understandable parts using abstraction and decomposition.

Each requirement is given:

Alabel
Adescription
Success criteria— how we know the requirement has been achieved

Requirement label	Description	Success criteria
R1	The program must accept the length and width of a rectangle	The user is prompted twice and both values are stored
R2	The program must calculate the area of the rectangle	Area = length × width is displayed correctly for at least three test cases
R3	The program must display the result with a clear message	The output includes the text "The area of the rectangle is:" followed by the value

Activity 2: Abstraction and Decomposition

A programmer is asked to write a program for a school library that lets students borrow books. The librarian has also mentioned the colour of the library shelves, the opening hours of the building, and the borrowing limit of three books per student.

Which of the librarian's details would be removed by abstraction, and why?
Which details are part of the core functionality?
Write three sub-problems the programmer could identify through decomposition.
Write two labelled requirements with success criteria for this program.

Solution:

Removed by abstraction:The colour of the shelves and the opening hours of the building. These are not part of the problem the program is solving — the program is about borrowing books, not about the furniture or the building's timetable.
Core functionality:The borrowing limit of three books per student, and the act of recording a loan and a return.
Possible sub-problems:
- Check the student ID is valid
- Check the student has fewer than three books on loan
- Record the book as borrowed and update the number on loan
- Record the book as returned

Example requirements:

Label	Description	Success criteria
R1	Only allow a student to borrow a book if they have fewer than three books on loan	A fourth borrow attempt is refused with a message
R2	Record every book returned by a student	The number of books on loan decreases by one after each return

Check Your Understanding: Analysis

1. Define the term "abstraction" and explain why it is useful in the analysis stage. [3 marks]

Answer

[1 mark]Abstraction is removing unimportant details from a problem
[1 mark]So that the programmer can focus on the important elements, such as core functionality and requirements
[1 mark]It helps identify the fundamental components of what the program is going to solve, and makes the problem easier for everyone on the team to understand
[Example]The London Underground map removes geographical detail so that only stations and connections are shown

2. What is meant by "decomposition" and why does it help a programmer? [3 marks]

Answer

[1 mark]Decomposition is breaking a problem down into smaller, manageable sub-problems
[1 mark]Each sub-problem is easier to understand, design, code and test on its own
[1 mark]It also allows different members of a team to work on different parts of the solution at the same time

3. What three things are recorded for each requirement in a requirements document? [3 marks]

Answer

[1 mark]A label (for example R1, R2, R3)
[1 mark]A description of what the requirement is
[1 mark]Success criteria — a statement of how we know the requirement has been achieved

4. A programmer is writing an app to track daily step counts. State two details that abstraction would remove and two details that would remain. [4 marks]

Answer

Removed (unimportant details):

The colour scheme of the phone the user owns
The brand of shoes the user is wearing
(Any other irrelevant detail, e.g. the weather on the day)

Remaining (important details):

The number of steps taken each day
The date the steps were taken
A daily target so progress can be shown

5. Explain the difference between "problem identification" and "requirements". [3 marks]

Answer

[1 mark]Problem identification is clearly defining the problem statement and understanding the requirements from an end-user perspective
[1 mark]Requirements are recorded in a requirements document, which defines the problem and breaks it into clear, manageable, understandable parts using abstraction and decomposition
[1 mark]Each requirement is labelled, described, and given success criteria stating how we know it has been achieved

6. Why must the whole team agree on the overall goal and constraints before work starts? [2 marks]

Answer

[1 mark]So that everyone is working towards the same solution, and the program meets the user's needs
[1 mark]Constraints such as limited resources or a platform-specific solution affect design choices, so they must be agreed early to avoid wasted work

3. Stage 2 — Design

Thedesignstage involves using techniques to come up with ablueprint for a solution. Ways the design of a solution can be presented include:

Structure diagrams

Show how the parts of the program fit together.

Flowcharts

Show the flow of control through the program.

Pseudocode

A high-level, human-readable description of the logic.

3.1 Further Decomposition

During design, the problem is broken downfurtherintomodules or components, each with aspecific function. This is sometimes called "further decomposition" because the analysis stage already split the problem into sub-problems — now each sub-problem is split again into the modules that will actually be coded.

Example: Modules for the Rectangle Area Program

Input validation module— checks the length and width entered by the user
Area calculation module— multiplies length by width
Output module— displays the result with a clear message

3.2 Structure Diagrams

Structure diagramsare created to visualise the structure of the program. Examples includeUML (Unified Modeling Language) class diagramsandentity-relationship diagrams. A UML class diagram shows the classes in a system, their attributes (data) and their methods (actions), and how the classes relate to each other.

Class	Attributes	Methods
Rectangle	length : REAL width : REAL	calculateArea()

In the PDF example, a UML class diagram is drawn with classes such asRectangleand methods such ascalculateArea(). The diagram also shows how classes relate — for example, aPerson"lives at" anAddress, and aProfessor"supervises" a number ofStudentobjects. The relationship arrows and multiplicities (such as 1 and 0..1) show how many objects take part in each relationship.

3.3 Flowcharts

Flowchartsrepresent theflow of controlwithin the program. They showdecision points,loops, and theactions taken based on conditions. A flowchart is drawn from the input to the output.

Visual: Flowchart for the Rectangle Area Program

This flowchart shows the flow of control from input to output for the rectangle area program. Follow the arrows from START to END.

START

Read Length

Read Width

Is Length > 0 AND Width > 0 ?

Yes

Area ← Length × Width

Display "The area of the rectangle is: ", Area

END

Key flowchart idea:The diamond shape is adecision point. If the answer is "No", the program would follow the other branch (for example, displaying an error message and asking again). This is how flowcharts showselectionandloops.

3.4 Pseudocode

Pseudocodeis ahigh-level description of the program logic, written using simple, human-readable language. It doesnotworry about the specific syntax of a programming language, so it can be converted into any language later.

Pseudocode for input validation and area calculation

Start
Read input for length from the user
Read input for width from the user
Calculate area as length multiplied by width and store it in the variable "area"
Display "The area of the rectangle is: " concatenated with the value of "area"
End

Same logic in CIE pseudocode

DECLARE Length : REAL
DECLARE Width : REAL
DECLARE Area : REAL
OUTPUT "Enter the length of the rectangle: "
INPUT Length
OUTPUT "Enter the width of the rectangle: "
INPUT Width
Area ← Length * Width
OUTPUT "The area of the rectangle is: ", Area

Notice the CIE pseudocode rules:DECLAREfor variables with a data type,INPUT/OUTPUTfor input and output, and the assignment arrow←.

Activity 3: Designing a Solution

A program is needed that reads in the marks for three tests and outputs the average mark.

List two modules the solution could be decomposed into.
Draw (or describe) a simple structure diagram for this program.
Write CIE pseudocode for the solution. Use DECLARE, INPUT, OUTPUT and the ← assignment arrow.
Explain one advantage of writing the design in pseudocode before writing real code.

Solution:

Modules:
- Input module — reads and validates the three marks
- Average calculation module — adds the marks and divides by 3
- Output module — displays the average
Structure diagram (described):
AverageProgram
  ├── ReadMarks()
  ├── CalculateAverage()
  └── DisplayAverage()
CIE pseudocode:
DECLARE Mark1 : INTEGER
DECLARE Mark2 : INTEGER
DECLARE Mark3 : INTEGER
DECLARE Average : REAL
OUTPUT "Enter mark 1: "
INPUT Mark1
OUTPUT "Enter mark 2: "
INPUT Mark2
OUTPUT "Enter mark 3: "
INPUT Mark3
Average ← (Mark1 + Mark2 + Mark3) / 3
OUTPUT "The average mark is: ", Average
Advantage of pseudocode:It is written in simple, human-readable language that does not depend on the syntax of any particular programming language, so the logic can be checked and corrected easily before any code is written. It can then be translated into Python, Java or any other language.

Check Your Understanding: Design

1. Name three ways the design of a solution can be presented. [3 marks]

Answer

[1 mark]Structure diagrams (for example UML class diagrams, entity-relationship diagrams)
[1 mark]Flowcharts
[1 mark]Pseudocode

2. What is the purpose of a structure diagram? [2 marks]

Answer

[1 mark]To visualise the structure of the program — how the classes, attributes, methods and relationships fit together
[1 mark]For example a UML class diagram shows classes such as Rectangle with methods such as calculateArea()
[Additional]Entity-relationship diagrams are another form of structure diagram

3. What does a flowchart show that pseudocode does not show as clearly? [2 marks]

Answer

[1 mark]A flowchart shows the flow of control visually — the order in which actions happen, and which way the program goes after a decision
[1 mark]It clearly shows decision points (diamonds), loops and the actions taken based on conditions, using arrows to show the direction of flow

4. Explain what is meant by "further decomposition" in the design stage. [3 marks]

Answer

[1 mark]The problem is broken down into modules or components, each with a specific function
[1 mark]This happens during design, after the analysis stage has already split the problem into sub-problems
[1 mark]For example, the rectangle area program is decomposed into an input validation module, an area calculation module and an output module

5. Write CIE pseudocode to declare two REAL variables called Length and Width, input them, and output their product. [4 marks]

Answer

DECLARE Length : REAL
DECLARE Width : REAL
DECLARE Product : REAL
OUTPUT "Enter the length: "
INPUT Length
OUTPUT "Enter the width: "
INPUT Width
Product ← Length * Width
OUTPUT "The product is: ", Product

Marking points:DECLARE with a data type for each variable, INPUT and OUTPUT statements, and the ← assignment arrow.

6. Give two reasons why a programmer should design a solution before writing any code. [2 marks]

Answer

[1 mark]The design acts as a blueprint, so the programmer knows exactly what code to write and in what order
[1 mark]Mistakes in logic are cheaper and faster to spot and fix in a design than in finished code
[Additional]A design also makes the program easier for other people to understand, test and maintain later

4. Stage 3 — Coding

In thecodingstage, developers begin programming modules in asuitable programming language. The modules work together to provide an overall solution to the problem.

4.1 Writing Program Code

Writing program codemeans translating the design into actual code using a programming language, following thesyntaxandrulesof that language.

What the programmer does

Writes code in a programming language (for example Python or Java) based on the design specifications
Implements functions/methods for input validation and area calculation
Uses appropriate syntax and follows coding conventions

Working as a team

Different developers may program different modules. Each module mustinteract correctlywith the others, so the interfaces between modules must match the design exactly.

4.2 Python Code for the Rectangle Area Program

# Taking user input for length and width
length = float(input("Enter the length of the rectangle: "))
width = float(input("Enter the width of the rectangle: "))
# Calculating area of the rectangle
area = length * width
# Displaying the area of the rectangle
print("The area of the rectangle is:", area)

Example Run (from the PDF)

Enter the length of the rectangle: 200
Enter the width of the rectangle: 50
The area of the rectangle is: 10000.0

The user entered 200 and 50. The program multiplied them (200 × 50 = 10000) and displayed the result. Becausefloat()was used, the answer is shown as10000.0rather than10000.

4.3 Iterative Testing

Iterative testingmeans testing the codein an iterative manner— that is, repeatedly, as each module is written. Errors or bugs are identified and fixed as they are found. This involvesdebuggingand making the necessary revisions to the code.

1. Write a module

Program one module, for example the input validation module.

2. Test it thoroughly

Run the module with a range of data to check it accepts data without crashing or causing errors.

3. Debug and retest

Fix any bugs found. As new modules are added, retest the older ones to make sure they still interact correctly.

Common misconception

Iterative testing isnotthe same as the final testing stage. Iterative testing happensduring coding, module by module, as the program is being built. The testing stage happensafterthe whole program is finished, when the complete solution is run many times with different sets of test data.

Activity 4: Coding and Iterative Testing

A student writes this Python module to work out the area of a rectangle:

length = input("Enter the length: ")
width = input("Enter the width: ")
area = length * width
print("The area is:", area)

The student runs the program and enters 5 and 4. Instead of 20, the output is5555. Explain why.
Write the corrected Python code.
Describe how the student would carry out iterative testing on this module.

Solution:

Why the output is 5555:
Theinput()function in Python always returns astring. When you use*on two strings it repeats the string rather than multiplying numbers. So"5" * "4"would normally be an error, but in the student's code the values entered are treated as text and the multiplication is performing string repetition — the result is not the number 20.
Corrected Python code:
length = float(input("Enter the length: "))
width = float(input("Enter the width: "))
area = length * width
print("The area is:", area)
Wrappinginput()infloat()converts the text into a number so that multiplication works correctly.
Iterative testing:The student runs the module after writing it, entering several sets of values (for example 5 and 4, 10 and 10, 2.5 and 4). They check that the output matches the expected answer each time. If a test fails, they debug the code, fix the error, and run the tests again until the module works correctly. When more modules are added later, this module is retested to make sure it still works with them.

Check Your Understanding: Coding

1. What is meant by "writing program code"? [2 marks]

Answer

[1 mark]Translating the design into actual code using a programming language
[1 mark]Following the syntax and rules of that language (for example Python or Java)

2. Define "iterative testing" and explain why it happens during the coding stage. [3 marks]

Answer

[1 mark]Iterative testing is testing the code repeatedly as each module is written, identifying and fixing errors or bugs as they are found
[1 mark]It involves debugging and making the necessary revisions to the code
[1 mark]It happens during coding so that each module is checked thoroughly before the next one is written, and so that bugs do not build up and become harder to find

3. Why might a module need to be retested after a new module is created? [2 marks]

Answer

[1 mark]To make sure the modules still interact correctly with each other
[1 mark]Because adding or changing a module can introduce new errors, and the older module may no longer work as it did before

4. The Python statementlength = input("Enter the length: ")stores a string. Why is this a problem for a calculation? [2 marks]

Answer

[1 mark]The value stored is text, not a number, so arithmetic cannot be performed on it correctly
[1 mark]It must be converted, for example usingfloat(input(...))orint(input(...)), so that multiplication gives the correct numeric answer

5. Explain the difference between an error found by iterative testing and an error found by the final testing stage. [3 marks]

Answer

[1 mark]Iterative testing finds bugs inside a single module while the program is still being built
[1 mark]Final testing finds problems with the whole finished program — for example, a module working alone but failing when another module passes it unexpected data
[1 mark]Final testing also checks that the program meets the requirements and success criteria set out in the analysis stage, and that it rejects invalid data

5. Stage 4 — Testing

Once the overall program (or set of programs) is created, it is runmany times using varying sets of test data. This ensures the program works as intended, as outlined in the initial requirements specification and design, and that itrejects any invalid datathat is input.

5.1 Testing Program Code Using Test Data

Testing usestest datato validate the program's functionality and ensure it produces the expected output under various conditions. Different sets of input data are created to cover a wide range of scenarios.

Normal test data

Typical values that the program should accept and process correctly. These check the program works for everyday use.

Edge (boundary) test data

Values right at the limit of what is allowed — the smallest or largest acceptable value. These check the boundaries of the program's rules.

Invalid (erroneous) test data

Values that should be rejected — for example letters where a number is expected, or a negative value where only positive values are allowed.

Example from the PDF: Password Validation Routines

Examples of test data includealphanumeric sequencesto test password validation routines — for instance checking that a password contains both letters and numbers, that it is the required length, and that invalid characters are rejected.

Interactive: Test Data for the Rectangle Area Program

The rectangle area program reads a length and a width. Choose a test case below and clickRun Testto see whether the program accepts the data or rejects it, and what the expected result is.

Length

Width

Area

Choose a test case above

How it works:Test data must cover normal cases (everyday values), edge cases (values at the limit of what is allowed, such as zero) and invalid cases (data that must be rejected, such as text or negative numbers). A complete test plan includes all three types.

5.2 The Testing Checklist

Prepare test data, including valid and invalid inputs (length and width)
Test the program with different sets of input data
Verify that the calculated area matches the expected results for all test cases
Debug and fix any errors encountered during testing

Type of test data	Length	Width	Expected result
Normal	200	50	10000.0 displayed
Normal	10	10	100.0 displayed
Edge	0	5	0.0 displayed (or rejected if the program requires values greater than zero)
Edge	0.1	0.1	0.01 displayed
Invalid	abc	5	Error message — value not numeric
Invalid	-3	4	Error message — length cannot be negative

Activity 5: Writing a Test Plan

A program asks a user to enter their age (a whole number between 11 and 18 inclusive) and prints a message telling them which school year they are in.

Give two examples of normal test data and the expected result.
Give two examples of edge test data and explain why each is an edge case.
Give two examples of invalid test data and the expected result.
Explain why testing only with normal data is not enough.

Solution:

Normal test data:
- Age = 14 → program accepts it and prints the correct school year message
- Age = 16 → program accepts it and prints the correct school year message
Edge test data:
- Age = 11 → the smallest value allowed, so it tests the lower boundary of the range
- Age = 18 → the largest value allowed, so it tests the upper boundary of the range
Invalid test data:
- Age = 10 (or 19) → outside the allowed range, so the program should reject it with an error message
- Age = "ten" (letters) → not a whole number, so the program should reject it with an error message
Why normal data is not enough:Normal data only shows the program works for typical users. It does not test whether the boundaries are handled correctly or whether invalid data is rejected. A program that crashes on invalid input is not fit for purpose, so edge and invalid data must also be tested.

Check Your Understanding: Testing

1. What is the purpose of the testing stage? [2 marks]

Answer

[1 mark]To make sure the program works as intended, as outlined in the initial requirements specification and design
[1 mark]To check that it rejects any invalid data that is input

2. Name and describe the three types of test data. [6 marks]

Answer

[2 marks]Normal test data— typical values the program should accept and process correctly, representing everyday use
[2 marks]Edge (boundary) test data— values at the very limit of what is allowed, such as the smallest or largest acceptable value
[2 marks]Invalid (erroneous) test data— data that should be rejected by the program, such as letters where numbers are expected

3. A program validates passwords. Describe test data you would use for the password validation routine. [3 marks]

Answer

[1 mark]Normal data:an alphanumeric sequence of acceptable length containing letters and numbers, e.g. "Passw0rd1"
[1 mark]Edge data:a password exactly at the minimum allowed length and exactly at the maximum allowed length
[1 mark]Invalid data:a password that is too short, contains only letters with no numbers, or contains spaces/symbols that are not allowed — these should be rejected
[Note]The PDF specifically mentions using alphanumeric sequences to test password validation routines

4. Why must the testing stage happen after the whole program is complete, not just after each module? [3 marks]

Answer

[1 mark]Each module can be tested on its own during coding, but that does not show whether the modules work together as a complete system
[1 mark]The finished program must be run many times with varying sets of test data to confirm it meets the requirements specification and design
[1 mark]It also confirms the program rejects invalid data that is input, which is a whole-system behaviour

5. A program is supposed to accept a percentage mark between 0 and 100. Suggest one normal, one edge and one invalid test value. [3 marks]

Answer

[1 mark]Normal: 67 (a typical mark in the middle of the range) — the program should accept it
[1 mark]Edge: 0 or 100 (the boundaries of the accepted range) — the program should accept them
[1 mark]Invalid: 101, −5, or "seventy" — the program should reject these with an error message

6. Explain how testing links back to the analysis stage. [3 marks]

Answer

[1 mark]The requirements document produced during analysis includes success criteria
[1 mark]Testing checks the finished program against those success criteria to prove each requirement has been met
[1 mark]This is why the life cycle is often shown as a cycle — if a requirement is not met, the developer must go back to analysis or design to correct it

6. Worked Example: Area of a Rectangle

The PDF walks through a complete example: developing a simple program to calculate the area of a rectangle. Follow each stage in order to see how the four stages fit together.

Stage 1 — Analysis

Abstraction:Focus on the necessary information — the length and width of the rectangle. Everything else is ignored.
Decomposition:Divide the problem into sub-problems: input validation and calculation of area.
Problem identification:Calculate the area of a rectangle given its length and width.

Stage 2 — Design

Decomposition:Identify modules — an input validation module and an area calculation module.
Structure diagram:Create a UML class diagram with classes likeRectangleand methods likecalculateArea().
Flowchart:Draw a flowchart depicting the flow of control from input to output.
Pseudocode:Write pseudocode for the input validation and area calculation logic.

Start
Read input for length from the user
Read input for width from the user
Calculate area as length multiplied by width and store it in the variable "area"
Display "The area of the rectangle is: " concatenated with the value of "area"
End

Stage 3 — Coding

Write code in a programming language (for example Python or Java) based on the design specifications.
Implement functions/methods for input validation and area calculation.
Use appropriate syntax and follow coding conventions.

# Taking user input for length and width
length = float(input("Enter the length of the rectangle: "))
width = float(input("Enter the width of the rectangle: "))
# Calculating area of the rectangle
area = length * width
# Displaying the area of the rectangle
print("The area of the rectangle is:", area)

C:\Users\n.tadjerout\PycharmProjects\pythonProject
Enter the length of the rectangle: 200
Enter the width of the rectangle: 50
The area of the rectangle is: 10000.0

Stage 4 — Testing

Prepare test data, including valid and invalid inputs (length and width).
Test the program with different sets of input data.
Verify that the calculated area matches the expected results for all test cases.
Debug and fix any errors encountered during testing.

Summary of the process

By following these stages and tasks, developers can systematicallyanalyse, design, code and testprograms, ensuring the development process isorganised and effective.

Interactive: Step Through the Rectangle Program

ClickNext Stepto watch the variables change as the program runs. This shows what is happening inside the computer at each line of the program.

Program Code

length = float(input("Enter the length: "))

width = float(input("Enter the width: "))

area = length * width

print("The area is:", area)

length

—

width

—

area

—

Variables

Step 0: Ready to run

Output:—

Activity 6: Full SDLC Walkthrough

A school wants a program that calculates the average of three test marks and prints the grade (A, B, C, D or F). Work through the full SDLC and produce:

Analysis notes — abstraction, decomposition, problem identification and one requirement with success criteria.
Design — modules, a simple structure diagram and pseudocode.
Coding — Python code for the program.
Testing — a test plan with normal, edge and invalid data.

Solution:

1. Analysis

Abstraction:Only the three marks, the average and the grade matter. The student's name, the subject and the teacher's name are not needed.
Decomposition:Sub-problems — read the marks, validate each mark, calculate the average, decide the grade, print the result.
Problem identification:Calculate the average of three test marks and print the corresponding grade.
Requirement R1:The program must reject any mark outside the range 0 to 100.
Success criteria:entering −5 or 101 displays an error message and the program does not calculate a grade.

2. Design

Modules:ReadMarks(), ValidateMarks(), CalculateAverage(), DecideGrade(), DisplayResult()
Structure diagram:

GradeProgram
  ├── ReadMarks()
  ├── ValidateMarks()
  ├── CalculateAverage()
  ├── DecideGrade()
  └── DisplayResult()

Pseudocode:

DECLARE Mark1 : INTEGER
DECLARE Mark2 : INTEGER
DECLARE Mark3 : INTEGER
DECLARE Average : REAL
DECLARE Grade : STRING
OUTPUT "Enter mark 1: "
INPUT Mark1
OUTPUT "Enter mark 2: "
INPUT Mark2
OUTPUT "Enter mark 3: "
INPUT Mark3
IF Mark1 < 0 OR Mark1 > 100 OR Mark2 < 0 OR Mark2 > 100 OR Mark3 < 0 OR Mark3 > 100 THEN
OUTPUT "Error: marks must be between 0 and 100"
ELSE
Average ← (Mark1 + Mark2 + Mark3) / 3
IF Average >= 80 THEN
Grade ← "A"
ELSE IF Average >= 70 THEN
Grade ← "B"
ELSE IF Average >= 60 THEN
Grade ← "C"
ELSE IF Average >= 50 THEN
Grade ← "D"
ELSE
Grade ← "F"
ENDIF
OUTPUT "Average: ", Average, " Grade: ", Grade
ENDIF

3. Coding (Python)

mark1 = int(input("Enter mark 1: "))
mark2 = int(input("Enter mark 2: "))
mark3 = int(input("Enter mark 3: "))
if mark1 < 0 or mark1 > 100 or mark2 < 0 or mark2 > 100 or mark3 < 0 or mark3 > 100:
print("Error: marks must be between 0 and 100")
else:
average = (mark1 + mark2 + mark3) / 3
if average >= 80:
grade = "A"
elif average >= 70:
grade = "B"
elif average >= 60:
grade = "C"
elif average >= 50:
grade = "D"
else:
grade = "F"
print("Average:", average, "Grade:", grade)

4. Testing

Type	Mark 1	Mark 2	Mark 3	Expected result
Normal	75	80	85	Average 80.0, Grade A
Normal	55	60	65	Average 60.0, Grade C
Edge	0	0	0	Average 0.0, Grade F
Edge	100	100	100	Average 100.0, Grade A
Invalid	−5	60	70	Error message displayed
Invalid	101	60	70	Error message displayed

Key Takeaways

Theprogram development life cycle (SDLC)has four stages:analysis, design, coding and testing.
Analysismeans precisely understanding the problem before designing a solution. It includes abstraction, decomposition, problem identification and requirements.
Abstractionremoves unimportant details so you can focus on core functionality and requirements (e.g. the London Underground map).
Decompositionbreaks a large problem into smaller, manageable sub-problems.
Arequirements documentlabels each requirement, describes it, and givessuccess criteriashowing how it will be achieved.
Designproduces a blueprint usingfurther decomposition, structure diagrams, flowcharts and pseudocode.
Structure diagrams(such as UML class diagrams) show the structure of the program;flowchartsshow the flow of control including decisions and loops.
Pseudocodeis a high-level, human-readable description of program logic that is independent of any specific language syntax.
Codingtranslates the design into real code, following the syntax and rules of the chosen language.
Iterative testinghappens during coding: each module is tested and debugged as it is written, and retested as new modules are added.
Testingruns the finished program many times with varying sets of test data, checking it meets the requirements and rejects invalid data.
Test datamust cover normal cases, edge (boundary) cases and invalid cases.
Testing links back to analysis: success criteria from the requirements document are used to judge whether the program works as intended.
Following all four stages systematically makes the development processorganised and effective.

Question Bank

1. Complete the table by naming the key tasks carried out in each stage of the program development life cycle. [8 marks]

Answer

Stage	Key tasks
Analysis	Abstraction · Problem decomposition · Problem identification · Requirements
Design	Further decomposition · Structure diagrams · Flowcharts · Pseudocode
Coding	Writing program code · Iterative testing
Testing	Testing program code using test data

2. A programmer is creating a system for a school library. Explain how abstraction and decomposition would be used in the analysis stage. [6 marks]

Answer

Abstraction:

[1 mark]Removing unimportant details from the problem, such as the colour of the shelves or the library opening hours
[1 mark]To focus on the important elements — the core functionality (borrowing and returning books) and the requirements
[1 mark]This helps to identify the fundamental components of what the program is going to solve

Decomposition:

[1 mark]Breaking the problem into smaller, manageable sub-problems
[1 mark]For example: check the student ID, check the number of books on loan, record the loan, record the return
[1 mark]Each sub-problem is easier to understand, design, code and test

3. Describe the difference between a structure diagram and a flowchart. [4 marks]

Answer

[1 mark]A structure diagram visualises thestructureof the program — how its classes, attributes, methods and relationships are organised (for example a UML class diagram or entity-relationship diagram)
[1 mark]It shows the parts of the program and how they relate, not the order in which instructions run
[1 mark]A flowchart represents theflow of control— the order in which actions happen, showing decision points, loops and actions taken based on conditions
[1 mark]Flowcharts are drawn from input to output using arrows between shapes; structure diagrams use boxes connected by relationship lines

4. Write CIE pseudocode for a program that asks the user for the length and width of a rectangle and displays the area. [5 marks]

Answer

DECLARE Length : REAL
DECLARE Width : REAL
DECLARE Area : REAL
OUTPUT "Enter the length of the rectangle: "
INPUT Length
OUTPUT "Enter the width of the rectangle: "
INPUT Width
Area ← Length * Width
OUTPUT "The area of the rectangle is: ", Area

Marking points:DECLARE with data types, INPUT and OUTPUT statements, correct use of the ← assignment arrow, and the correct calculation Length * Width.

5. The rectangle area program is tested with the following data. Identify each set as normal, edge or invalid, and state the expected result. [6 marks]
(a) length = 200, width = 50
(b) length = 0, width = 5
(c) length = "abc", width = 5
(d) length = −3, width = 4
(e) length = 0.1, width = 0.1
(f) length = 12, width = 12

Answer

Set	Type	Expected result
(a) 200, 50	Normal	10000.0 displayed — a typical, valid input
(b) 0, 5	Edge	0.0 displayed (or rejected if the program requires values above zero) — the boundary case of a zero dimension
(c) "abc", 5	Invalid	Error message — the value is not numeric and must be rejected
(d) −3, 4	Invalid	Error message — a negative length is not possible and must be rejected
(e) 0.1, 0.1	Edge	0.01 displayed — a very small valid value tests the precision of the calculation
(f) 12, 12	Normal	144.0 displayed — a typical valid input

6. Explain why the program development life cycle is often shown as a cycle rather than a straight line. [3 marks]

Answer

[1 mark]Because work does not always move forward in one direction — testing can reveal errors that require the developer to return to an earlier stage
[1 mark]For example, if a test fails because a requirement was misunderstood, the developer goes back to analysis; if the structure is wrong, they go back to design
[1 mark]Iterative testing during coding also means the developer repeatedly moves between coding and testing within a single stage

7. A developer writes the following Python code. Identify and correct the error, and explain why the error occurred. [4 marks]

length = input("Enter the length: ")
width = input("Enter the width: ")
area = length * width
print("The area is:", area)

Answer

[1 mark]The error is thatinput()returns a string, solengthandwidthhold text, not numbers
[1 mark]Multiplying two strings does not produce a numeric area — the result is not the expected number
[1 mark]The values must be converted usingfloat()orint()

Corrected code:

length = float(input("Enter the length: "))
width = float(input("Enter the width: "))
area = length * width
print("The area is:", area)

[1 mark]This error would be found during iterative testing in the coding stage, and fixed before the program moves on to the testing stage.

8. Compare the roles of the requirements document and the test data in the development of a program. [5 marks]

Answer

Aspect	Requirements document	Test data
Stage	Produced in the analysis stage	Prepared in the testing stage
Purpose	Defines the problem and breaks it into clear, manageable, understandable parts using abstraction and decomposition	Validates the program's functionality and ensures it produces the expected output under various conditions
Contents	Each requirement is labelled, described, and given success criteria	Different sets of input data covering normal cases, edge cases and invalid inputs
Link	The success criteria in the requirements document are what the test data is used to check. Testing verifies that each requirement has actually been met.

[Marks]Requirements description (2), test data description including the three types (2), link between them (1).