Chapter 12.1: Software Development - Program Development Life Cycle

9618 AS Computer Science

📚 Learning Objectives

Show understanding of purpose of development life cycle
Show understanding of analysis, design, coding, testing and maintenance stages in program development life cycle
Show understanding of need for different development life cycles depending on program being developed
Describe principles, benefits and drawbacks of each type of life cycle
Compare Waterfall, Iterative, and RAD models

📖 Prior Knowledge Required

Basic understanding of what a computer program is
Knowledge of programming concepts (variables, loops, conditions)
Understanding of what an algorithm is
Basic knowledge of flowcharts and pseudocode
Familiarity with high-level programming languages

🌟 Did You Know?

In order to develop a successful program that is going to be used by others to perform a specific task or solve a given problem, the development needs to be well ordered and clearly documented, so that it can be understood and used by other developers!

1. Program Development Life Cycle Overview

The Program Development Life Cycle (PDLC) is a structured process used to develop software in a systematic way. It consists of five main stages that ensure a program is developed correctly, efficiently, and meets user requirements.

1.1 Purpose of PDLC

📖 Definition

The Program Development Life Cycle provides a structured framework for developing software that ensures:

Requirements are clearly understood before development begins
Development is well-ordered and systematic
Documentation is created throughout the process
Quality is verified through testing
The software can be maintained and updated over time

2. Analysis Stage

The Analysis stage is the first step in solving a problem. It involves investigating issues and the current system if there is one. The problem needs to be defined clearly and precisely.

2.1 Three Steps in Analysis

📝 Step 1: Investigation and Problem Definition

Investigate the issues and current system
Define the problem clearly and precisely
Draw up a Requirements Specification
Document what the program is required to do

📝 Step 2: Planning a Solution

Sometimes there is more than one solution
Evaluate each possible solution
Decide which is most appropriate
Consider constraints: time, budget, resources, skills

📝 Step 3: Decide How to Solve Problem

Bottom-Up Approach: Start with a small sub-problem and then build on this
Top-Down Approach: Stepwise refinement using pseudocode, flowcharts or structure charts

💡 Exam Tip

Remember: Analysis is about understanding WHAT needs to be built, not HOW it will be built. The output of analysis is a Requirements Specification document!

3. Design Stage

The Design stage uses the program specification from the analysis stage to show HOW the program should be developed. This is where you plan your solution in detail.

3.1 Creating an Identifier Table

To design a solution, an identifier table is a good starting point. This leads to thinking about:

📖 Key Design Considerations

Data Structures: Do we need a 1D array or a 2D array to store data?
File Storage: Do we need a file to store data long-term?
Variables: What variables and constants will be needed?
Functions/Procedures: What modules will be required?

3.2 Planning the Algorithm

📝 Algorithm Design Tools

Flowcharts: Visual representation using standard symbols
Pseudocode: Written description using structured English
Structure Charts: Show hierarchy of modules

4. Coding Stage

After designing the solution, we need to choose a suitable high-level programming language. If we know more than one programming language, we have to weigh up pros and cons of each one.

4.1 The Coding Process

This stage is often referred to as implementation. When you start writing programs:

📝 Coding Steps

Write code based on design documents
Several attempts may be needed before program compiles
When it compiles, you can execute it
Program might 'crash' - stops working unexpectedly
Debug the code to fix errors
Test if program produces expected output

4.2 Types of Errors

Error Type	Description	When Found
Syntax Error	A 'grammatical' error where a statement does not follow rules of the language	During compilation/interpretation - flagged by IDE
Logic Error	Program runs but produces incorrect results	During testing - output is wrong
Runtime Error	Program crashes during execution	During execution - program stops

⚠️ Important: IDE Features

Depending on program IDE, we may have some helpful facilities:

Syntax highlighting - colour-codes different parts of code
Auto-completion - suggests code as you type
Error detection - flags syntax errors as you write
Debugger - helps find and fix logic errors

💡 Exam Tip

The "Eureka moment" - 'It works!!!!' - doesn't mean the program does what it was meant to do! Always verify against the requirements specification.

5. Testing Stage

Testing ensures the program really works under all circumstances. The purpose of testing is to discover any errors which are present in the software.

⚠️ Important Truth About Testing

Testing can never be guaranteed to find all errors! It can only show that errors are present, not prove they are absent.

5.1 Testing Methods

📝 Trace Tables

Testing can be done through a trace table, which records the values of variables as the program executes step by step.

Manually step through algorithm with test data
Record variable values at each step
Verify output matches expected results

5.2 When Testing Takes Place

Development Model	When Testing Occurs
Waterfall Model	Only when all coding is completed
Iterative Model	Testing is on-going; done after every iteration
RAD Model	Testing is an on-going process throughout development

5.3 Types of Testing

📖 Testing Types

Unit Testing: Testing individual modules/components
Integration Testing: Testing how modules work together
System Testing: Testing the complete system
Acceptance Testing: User tests to confirm requirements met

6. Maintenance Stage

Maintenance is the process of making sure that the program continues to work during use. The program is maintained throughout its life to ensure it continues to work effectively.

6.1 Types of Maintenance

Maintenance Type	Purpose	Example
Corrective	Fixing bugs and errors discovered after release	Patching a security vulnerability
Adaptive	Adapting program to meet new requirements or environments	Updating for new operating system
Perfective	Improving functionality or performance	Adding new features users requested
Preventive	Preventing future problems	Refactoring code for better structure

6.2 Maintenance Activities

📝 What Maintenance Involves

Dealing with any problems that arise during use
Correcting any errors that come to light
Improving functionality of the program
Adapting program to meet new requirements
Updating documentation to reflect changes

🌟 Did You Know?

Studies show that maintenance typically accounts for 60-80% of the total cost of software over its lifetime. This is why good documentation and clean code design are so important!

7. The Waterfall Model

The Waterfall Model is a linear sequential development cycle where each stage is completed and signed off before the next stage is begun. This is the simplest model which can be easily understood.

📖 Key Principles

Linear: Each stage is completed before the next is begun
Well documented: Full documentation completed at every stage
Low customer involvement: Only involved at start and end of process
Sequential: Stages do not overlap

7.1 Waterfall Model Stages

💡 When to Use Waterfall

The Waterfall model is most suitable for projects where:

Requirements are well understood and unlikely to change
High quality and compliance are essential
There is a clear understanding of goals and constraints
Projects are smaller with short timescales

7.2 Waterfall Model - Benefits & Drawbacks

Benefits	Drawbacks
Simple and linear - easy to understand and follow	Inflexible - difficult to make changes once development begins
Clear stages and milestones - easy to track progress	Expensive to fix late problems - issues found late are harder to resolve
Ideal for well-defined projects - works best when requirements are fixed	Long development cycle - each stage must be completed before moving on
Stages do not overlap - completed one at a time	Not suitable for programs where requirements could change
Easy to manage due to fixed stages	No working software produced until late in the life cycle
Each stage has specific deliverables	Not suitable for long, complex, object-oriented projects
Works well for smaller programs where requirements are known	Difficult to measure progress within stages
	Integration done at end - doesn't identify technical issues early

❌ Common Mistakes to Avoid

Don't use Waterfall if requirements are likely to change!
Don't assume the model allows going back - each stage is signed off
Remember: no working software until late in the cycle
The model is NOT suitable for large, complex, or object-oriented projects

🧠 Memory Trick

Think of a waterfall: water flows DOWN only, it can't flow back UP. Similarly, in the Waterfall model, you can't easily go back to previous stages!

8. The Iterative Model

The Iterative Model (also known as Agile) is a software development methodology that promotes adaptability and high customer involvement. It first develops a simple subset of requirements, then expands or enhances the model and runs the development cycle again.

📖 Key Principles

Incremental development: Program development lifecycle is repeated
Working programs are produced for part of system at every iteration
High customer involvement: Part of system can be shown after every iteration
Continuous testing: Testing is ongoing, not saved for the end

8.1 Iterative Model Stages

8.2 Sprint Process

📝 Sprint (Iteration) Steps

Identify requirements - Work with stakeholders, write user stories
Plan the sprint - Break down requirements, choose tasks for current sprint
Design the solution - Focus on simple, adaptable design
Develop features - Write code, often working in pairs
Test continuously - Unit, integration, acceptance testing during sprint
Review progress - Demo working software, collect feedback
Reflect on process - Team improves for next sprint
Repeat - Move to next sprint with updated priorities

8.2 Iterative Model - Benefits & Drawbacks

Benefits	Drawbacks
Some working programs developed quickly at early stage	Only large software projects can benefit - hard to break small systems into modules
Easier to test and debug smaller programs	Design issues may arise because not all requirements gathered at beginning
More flexible - easier to alter requirements	More resources may be required
Progress can be measured	Needs good planning overall and for every stage
Customers involved at each iteration - no surprises	Defining increments may require definition of complete system
Software produced early - facilitates customer feedback	Requires experienced team members
Better suited for large, mission-critical projects	Risk of team burnout - intense collaboration can tire team
Parallel development can be planned	May lack documentation - flexibility reduces written records
Less costly to change scope/requirements	Scope creep risk - changing goals may lead to uncontrolled growth
Risks identified and resolved during iteration
Easier to manage risk - high-risk part done first

💡 When to Use Iterative

The Iterative model is most suitable for:

Small to medium-sized projects where requirements can change
Projects with high customer involvement
When major requirements are known but details may evolve
Large, mission-critical projects needing risk management

9. Rapid Application Development (RAD)

Rapid Application Development (RAD) is a software development methodology that emphasizes fast and iterative development. Different parts of requirements are developed in parallel, using prototyping to provide early user involvement in testing.

📖 Key Principles

Minimal planning - focus on getting working software quickly
Reuses previously written code where possible
Automated code generation where possible
High customer involvement - customers use prototypes during development
Parallel development - multiple teams work on different parts simultaneously

9.1 RAD Model Stages

📝 RAD Process Steps

Requirement planning: Gather general requirements, define constraints
User design & prototyping: Collaborate with users, develop prototypes
Construction: Build incrementally with continuous feedback
Cutover/Deployment: Transition to live environment, training
Maintenance: Continue adapting based on feedback

9.2 RAD Model - Benefits & Drawbacks

Benefits	Drawbacks
Reduced overall development time	System needs to be modular
Rapid, frequent customer feedback informs development	Needs strong teams of skilled developers and designers
Very flexible - requirements evolve from feedback	Not suitable for short, simple projects
Modification easier - each part works independently	Best for component-based, scalable systems
Progress can be measured	Requires strong team collaboration
Reduces development time	Potential quality issues - speed may reduce testing
Encourages customer feedback	Scope creep risk - flexibility can expand requirements

💡 When to Use RAD

RAD is most suitable for:

Projects where rapid delivery is required
Requirements can be developed and refined on the go
Complicated projects needing short timeframe
Systems that are component-based and scalable

10. Comparison of All Models

Feature	Waterfall	Iterative	RAD
Customer Involvement	Low (start/end only)	High (every iteration)	Very High (continuous)
Flexibility	Low	High	Very High
Documentation	Extensive	Minimal	Minimal
Testing	At end only	Continuous	Continuous
Best For	Small, well-defined projects	Large, evolving projects	Rapid delivery needed
Risk Management	Low	High (risks found early)	Medium

11. Exam-Style Questions

1. Describe the five stages of the Program Development Life Cycle. [5 marks]

Answer:

Analysis: Investigating the problem, defining requirements, creating a requirements specification
Design: Planning the solution using flowcharts, pseudocode, structure charts, and identifier tables
Coding: Writing the program in a high-level language, debugging syntax errors
Testing: Verifying the program works under all conditions using trace tables and test data
Maintenance: Ensuring the program continues to work, fixing bugs, adding features

2. Explain the difference between the top-down and bottom-up approaches to problem solving. [4 marks]

Answer:

Top-down: Start with the main problem and break it down into smaller sub-problems (stepwise refinement)
Uses pseudocode, flowcharts, or structure charts to decompose the problem
Bottom-up: Start with a small sub-problem and build up to the complete solution
Develops individual modules first, then combines them into larger system

3. Describe the principles of the Waterfall model and explain when it would be appropriate to use it. [6 marks]

Principles:

Linear sequential development - each stage completed before next begins
Well documented at every stage with specific deliverables
Low customer involvement - only at start and end of process
Stages do not overlap and are completed one at a time

When to use:

Projects with well-defined, fixed requirements
Smaller projects with short timescales

4. Compare the Waterfall and Iterative models in terms of customer involvement and flexibility. [4 marks]

Answer:

Customer involvement: Waterfall has low involvement (start/end only); Iterative has high involvement (every iteration)
Flexibility: Waterfall is inflexible - difficult to change requirements; Iterative is highly flexible
In Waterfall, requirements must be fixed upfront; in Iterative, they can evolve
Iterative shows working software to customers regularly; Waterfall only at the end

5. Explain two benefits and two drawbacks of the RAD model. [4 marks]

Benefits:

Reduced development time - parallel development speeds up process
Rapid customer feedback - prototypes allow early user input

Drawbacks:

Requires skilled developers and strong team collaboration
Not suitable for short, simple projects

11. Exam-Style Questions (Continued)

6. Explain why testing can never be guaranteed to find all errors in software. [3 marks]

Answer:

Testing can only show that errors are present, not that they are absent
Impossible to test all possible inputs and combinations
Some errors may only occur under specific conditions not covered by tests
Edge cases and unexpected user behaviour may not be anticipated

7. A software company is developing a large, complex banking system where requirements may change during development. Recommend which development model they should use and justify your answer. [5 marks]

Recommend: Iterative Model

Suitable for large, complex projects - can be broken into manageable modules
Flexible - allows requirements to change during development
Risk management - high-risk parts can be done first
Working software early - stakeholders can see progress
Testing throughout - crucial for banking system reliability

NOT Waterfall (too inflexible for changing requirements); NOT RAD (banking system needs thorough testing and documentation)

8. Describe three different types of maintenance that may be carried out on software after it has been released. [3 marks]

Answer:

Corrective maintenance: Fixing bugs and errors discovered after release
Adaptive maintenance: Adapting program to new requirements or environments (e.g., new OS)
Perfective maintenance: Improving functionality or performance based on user feedback
Preventive maintenance: Preventing future problems through code refactoring

9. Explain the difference between syntax errors and logic errors. Give an example of each. [4 marks]

Syntax Error:

A 'grammatical' error where statement does not follow language rules
Found during compilation - flagged by IDE
Example: Missing semicolon, misspelled keyword (PRINt instead of PRINT)

Logic Error:

Program runs but produces incorrect results
Found during testing when output doesn't match expected
Example: Using + instead of *, infinite loop, wrong condition in IF statement

10. Discuss the suitability of each development model for a project to create a simple calculator program with fixed requirements and a one-month deadline. [6 marks]

Waterfall - MOST SUITABLE:

Requirements are fixed and well-defined
Simple, small project with short timescale
Easy to manage with clear milestones

Iterative - NOT SUITABLE:

Overkill for small project - hard to break into smaller modules
Requires more planning and resources than needed

RAD - NOT SUITABLE:

Designed for complex projects, not simple ones
Requires skilled teams and modular architecture
Too much overhead for a simple calculator

12. Glossary

📖 Key Terms

Analysis	First stage of PDLC - investigation leading to specification of what program is required to do
Coding	Stage of PDLC - writing the program or suite of programs
Design	Stage of PDLC - uses specification from analysis to show how program should be developed
Iterative Model	Development cycle where simple subset is developed, then enhanced, cycle repeated until full system complete
Logic Error	Error where program runs but produces incorrect results
Maintenance	Stage of PDLC - ensuring program continues to work during use
Prototyping	Creating early version of software to get user feedback
RAD	Rapid Application Development - develops different parts in parallel with prototyping
Requirements Specification	Document defining what the program is required to do
Syntax Error	Grammatical error where statement doesn't follow language rules
Testing	Stage of PDLC - verifying program works under all conditions
Trace Table	Table recording variable values during step-by-step algorithm execution
Waterfall Model	Linear sequential development cycle - each stage completed before next begins

13. Exam Success Tips

💡 PDLC Stages - Remember the Order

Analysis → Design → Coding → Testing → Maintenance
Memory trick: "A Dog Can Teach Monkeys" or "Always Design Code To Maintain"
Analysis = WHAT, Design = HOW, Coding = DO IT, Testing = VERIFY, Maintenance = KEEP IT RUNNING

💡 Development Models - Quick Comparison

Waterfall: Like a real waterfall - flows ONE way only, can't go back
Iterative: Like climbing stairs in circles - go round again and again, getting higher each time
RAD: Like building with Lego - multiple teams working on different pieces simultaneously

🧠 Memory Trick: Customer Involvement

Waterfall: W = We talk at start and end only (Low involvement)
Iterative: I = I see you every iteration (High involvement)
RAD: R = Really constant contact (Very High involvement)

💡 Choosing the Right Model

Fixed requirements + Small project → Waterfall
Changing requirements + Large project → Iterative
Rapid delivery + Complex project → RAD
When in doubt, match model flexibility to requirement uncertainty!

❌ Common Mistakes to Avoid

Don't confuse syntax errors (grammar) with logic errors (wrong output)
Don't say Waterfall has "no testing" - it tests, but only at the end
Don't confuse Iterative with RAD - Iterative repeats the whole cycle, RAD runs cycles in parallel
Remember: RAD needs modular systems and skilled teams
Testing can NEVER prove software is error-free - it can only find errors, not prove absence

13. Exam Success Tips (Continued)

💡 Answer Structure Tips

For "describe" questions: Give step-by-step details of how something works
For "explain" questions: Give reasons WHY something happens or differs
For "compare" questions: Mention BOTH items for each point, use tables
For "evaluate" or "discuss" questions: Give benefits AND drawbacks
Mark allocations tell you how many points to make: [4 marks] = 4 distinct points

🌟 Quick Reference Table

Topic	Key Point
Analysis Output	Requirements Specification
Design Tools	Flowcharts, Pseudocode, Structure Charts
Syntax Error	Grammar error, found during compilation
Logic Error	Wrong output, found during testing
Waterfall Testing	At end only
Iterative/RAD Testing	Continuous throughout
Maintenance Types	Corrective, Adaptive, Perfective, Preventive

⚠️ Must-Know Facts

Testing cannot guarantee finding all errors
Waterfall is NOT suitable for object-oriented projects
Iterative is NOT suitable for small projects
RAD requires modular systems and skilled developers
Maintenance accounts for 60-80% of total software cost

14. Key Takeaways

📌 Summary Points

Program Development Life Cycle

Five stages: Analysis → Design → Coding → Testing → Maintenance
Analysis: Investigate problem, define requirements, create specification
Design: Plan solution using flowcharts, pseudocode, identifier tables
Coding: Write program, debug syntax errors, implement design
Testing: Verify works under all conditions, can never find all errors
Maintenance: Corrective, adaptive, perfective, preventive

Development Models

Waterfall: Linear, low flexibility, low customer involvement, testing at end
Iterative: Cycles, high flexibility, high customer involvement, continuous testing
RAD: Parallel development, very high flexibility, prototyping, rapid delivery

Model Selection

Waterfall: Small projects, fixed requirements, well-defined goals
Iterative: Large projects, evolving requirements, high customer involvement
RAD: Rapid delivery needed, complex projects, component-based systems