The Program Development Life Cycle

🎯 Syllabus & Goals 3 min

Cambridge 7.1 · Program development life cycle Paper 2 · Algorithms, Programming and Logic

By the end of this lesson you can:

1. Name the four stages of the program development life cycle in order and state what happens in each.
2. Describe abstraction and decomposition and apply them to a real problem.
3. Explain what iterative testing is and how it differs from final testing.

Textbook: Chapter 7, §7.1 (pp. 258–259)

Recap / Warm-Up 5 min

Units 1–6 covered Paper 1: how computers store, move and process data. Unit 7 opens Paper 2. From now on you design, read and write algorithms.

Quick starter

A friend is asked to write an app for a school canteen. They open an editor and start typing code straight away. Give one thing that could go wrong.

🧠 Key Concept 14 min

1 · Four stages, always in the same order

Programs are not written in one go. Developers follow the program development life cycle (PDLC). Cambridge examines four stages: analysis, design, coding and testing.

2 · Analysis — what exactly is the problem?

Before anything is solved, the problem must be defined clearly so everybody understands what is needed. The result is a requirements specification. Two tools help at this stage.

3 · Design — how will it be solved?

Design uses the requirements specification to plan the program. When design is finished, the programmer knows every task, how each task is done and how the tasks work together. It is written down as structure diagrams, flowcharts and pseudocode (Lessons 2–5).

4 · Coding and iterative testing

The program is written in a programming language, one module at a time. Each module is tested as soon as it is written. If it fails, the code is amended and the test is repeated. This loop is iterative testing.

5 · Testing

The finished program is run many times with different sets of test data. This proves that all the modules work together as the design specified. Lesson 9 shows how to choose that data.

Worked Example 12 min

Worked example 1 · A library fine calculator through all four stages

A school library charges $0.50 for each day a book is late. The fine never goes above $10. The librarian wants a program to work it out.

1. Analysis — write the requirements. Input: number of days late. Output: the fine. Rule: 50 cents a day, capped at $10.everyone must agree what the program does before anyone plans or codes it.
2. Analysis — abstraction. Keep: days late, daily rate, the cap. Discard: book title, cover colour, the borrower's class.those details do not change the fine, so they only add clutter.
3. Analysis — decomposition. (a) get the days late, (b) calculate the fine, (c) apply the $10 cap, (d) output the fine.four small tasks are easier to design, code and test than one big one.
4. Design — pseudocode. Each sub-task becomes one or more statements:

   // Design: work out the fine for a late book
   DECLARE DaysLate : INTEGER
   DECLARE Fine : REAL
   INPUT DaysLate
   Fine ← DaysLate * 0.5
   IF Fine > 10
     THEN
       Fine ← 10
   ENDIF
   OUTPUT "Fine: $", Fine

   the design is language-free, so any programmer can code it.
5. Coding — first attempt, then iterative testing. The programmer's first version forgot the cap. Testing the module with 30 days late gives 15.0, but $10 was expected. The code is amended and the test is repeated:

   # Coding: the amended module (cap added after a failed test)
   days_late = int(input("Days late: "))
   fine = days_late * 0.5
   if fine > 10:
       fine = 10
   print("Fine: $", fine)

   Days late: 30
   Fine: $ 10

   a failed module test → amend → re-test is exactly what iterative testing means.
6. Testing — the whole program. Run it with several sets of data and compare with the expected results:

   Days late	Expected fine	Actual	Pass?
   0	0	0.0	✔
   3	1.5	1.5	✔
   20	10	10.0	✔
   30	10	10	✔

   20 days is exactly where the cap starts, so it is the value most likely to expose a fault.

Worked example 2 · Abstraction for a step-counter app

A fitness company wants an app that tells a user whether they reached 8000 steps today. Sort the details.

1. List everything you could know. Steps today, the goal of 8000, the user's shoe size, weather, phone colour, date, the user's favourite song.
2. Ask of each item: does the answer depend on it?

   Keep (key elements)

   • steps today
   • the goal (8000)
   • the date (to reset each day)

   Discard (unnecessary)

   • shoe size
   • weather
   • phone colour, favourite song
   abstraction is judged against the problem; weather matters for a running app, not here.
3. Write it as an exam answer. "Abstraction keeps the steps, goal and date, which decide the result, and discards details such as shoe size that do not affect it."a good answer names the rule and applies it to the scenario.

Try It Yourself 12 min

📝 Exam Practice 10 min

🗝️ Recap & Key Terms 3 min

Every program goes through analysis → design → coding → testing. Analysis defines the problem with abstraction and decomposition. Design plans the solution. Coding builds and iteratively tests each module. Testing checks that the whole program works.

Analysis

Investigating the problem, leading to a specification of what the program is required to do.

Design

Using the specification to show how the program will be developed (structure diagrams, flowcharts, pseudocode).

Coding

Writing the program or suite of programs.

Testing

Systematic checks on a program to make sure it works under all conditions.

Abstraction

Keeping the key elements needed for the solution and discarding unnecessary details.

Decomposition

Breaking a complex problem into smaller parts that can each be solved more easily.

Iterative testing

Testing a module, amending the code and repeating the tests until the module works as required.

Homework 1 min

Task (≤ 15 min): A café wants a program that takes customers' orders and totals the bill. Describe what would happen at each of the four stages of the program development life cycle. [8]