Contents

Chapter 1 The Necessity of Systematic Software Development 1

1.1 The Nature of Software Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Programs versus Software Systems . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 Software as an Engineered Artifact . . . . . . . . . . . . . . . . . . . . . . 2
1.1.3 Software as a Socio-Technical System . . . . . . . . . . . . . . . . . . . . . 4
1.1.4 Scale, Users, and Time as Structural Dimensions . . . . . . . . . . . . . . . 5
1.2 Complexity and the Limits of Informal Construction . . . . . . . . . . . . . . . . . 6
1.2.1 Structural Complexity in Software . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 Coupling and Interdependence . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.3 Nonlinearity and Cascading Effects . . . . . . . . . . . . . . . . . . . . . . 7
1.2.4 Emergent Behavior in Large Systems . . . . . . . . . . . . . . . . . . . . . 8
1.3 Human Cognitive Constraints and the Need for Abstraction . . . . . . . . . . . . . . 9
1.3.1 Limits of Individual Comprehension . . . . . . . . . . . . . . . . . . . . . . 9
1.3.2 Decomposition and Modularity . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.3 Layered Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.4 Interfaces and Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Entropy and Structural Decay in Software Systems . . . . . . . . . . . . . . . . . . 11
1.4.1 Codebase Entropy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.2 Technical Debt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.3 Architectural Drift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.4 Refactoring as Structural Correction . . . . . . . . . . . . . . . . . . . . . . 13
1.5 Engineering Discipline and Predictability . . . . . . . . . . . . . . . . . . . . . . . 13
1.5.1 From Craft to Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5.2 Process Standardization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.3 Measurement and Quality Control . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.4 Verification and Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.6 Time, Evolution, and Software Longevity . . . . . . . . . . . . . . . . . . . . . . . 15
1.6.1 Maintenance as a Structural Reality . . . . . . . . . . . . . . . . . . . . . . 15
1.6.2 Backward Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.6.3 Scalability and Growth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.6.4 Architectural Foresight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.7 Risk, Failure, and Ethical Responsibility . . . . . . . . . . . . . . . . . . . . . . . . 17
1.7.1 Software in Safety-Critical Domains . . . . . . . . . . . . . . . . . . . . . . 17
1.7.2 Security and Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.7.3 Economic and Legal Consequences . . . . . . . . . . . . . . . . . . . . . . 18
1.7.4 Professional Accountability . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Contents ii

Chapter 2 Phases of the System Development Life Cycle (SDLC) 20

2.1 Introduction to Information Systems Development . . . . . . . . . . . . . . . . . . 20
2.1.1 Meaning of Information Systems . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.2 Importance of Information Systems in Organizations . . . . . . . . . . . . . 21
2.1.3 The Need for Structured System Development . . . . . . . . . . . . . . . . 22
2.1.4 Problems with Unstructured System Development . . . . . . . . . . . . . . 22
2.1.5 Overview of the System Development Life Cycle . . . . . . . . . . . . . . . 23
2.2 Understanding the System Development Life Cycle (SDLC) . . . . . . . . . . . . . 24
2.2.1 Definition of SDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.2 Objectives of the SDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.3 Characteristics of the SDLC . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.4 Benefits of Using SDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.5 Limitations of the SDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3 Overview of the Phases of SDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.1 Concept of Development Phases . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.2 Sequential Nature of the SDLC . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.3 Diagram of the SDLC Process . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.4 Relationship Between SDLC Phases . . . . . . . . . . . . . . . . . . . . . . 29
2.4 Phase 1: System Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4.1 Meaning of System Planning . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4.2 Objectives of the Planning Phase . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4.3 Identifying System Problems and Opportunities . . . . . . . . . . . . . . . . 30
2.4.4 Feasibility Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4.5 Types of Feasibility Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 31
[Link] Technical Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 31
[Link] Economic Feasibility . . . . . . . . . . . . . . . . . . . . . . . . 32
[Link] Operational Feasibility . . . . . . . . . . . . . . . . . . . . . . . 32
[Link] Legal Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
[Link] Schedule Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.6 Real-World Example: Planning a Hospital Management System . . . . . . . 33
2.5 Phase 2: Requirements Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.5.1 Meaning of Requirements Analysis . . . . . . . . . . . . . . . . . . . . . . 33
2.5.2 Importance of Requirements Gathering . . . . . . . . . . . . . . . . . . . . 34
2.5.3 Techniques for Collecting Requirements . . . . . . . . . . . . . . . . . . . . 34
[Link] Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
[Link] Questionnaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
[Link] Observation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
[Link] Document Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 35
[Link] Workshops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.5.4 Functional vs Non-Functional Requirements . . . . . . . . . . . . . . . . . 36

Makerere University - College of Computing and Information Sciences

Contents iii

2.5.5 Real-World Example: Banking ATM System Requirements . . . . . . . . . 36

2.6 Phase 3: System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.6.1 Meaning of System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.6.2 Objectives of System Design . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.6.3 Types of System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
[Link] Logical Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
[Link] Physical Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.6.4 Key Components of System Design . . . . . . . . . . . . . . . . . . . . . . 39
[Link] Database Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
[Link] Interface Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
[Link] Process Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
[Link] Security Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.6.5 Real-World Example: Designing an E-Learning System for a University . . . 40
2.7 Phase 4: System Development (Implementation) . . . . . . . . . . . . . . . . . . . 40
2.7.1 Meaning of System Development . . . . . . . . . . . . . . . . . . . . . . . 41
2.7.2 Programming and Coding Activities . . . . . . . . . . . . . . . . . . . . . . 41
2.7.3 Tools and Technologies Used in Development . . . . . . . . . . . . . . . . . 42
2.7.4 Role of Developers and Engineers . . . . . . . . . . . . . . . . . . . . . . . 42
2.7.5 Real-World Example: Development of an Online Banking Application . . . 42
2.8 Phase 5: System Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.8.1 Meaning of System Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.8.2 Importance of Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.8.3 Types of System Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
[Link] Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
[Link] Integration Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 44
[Link] System Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
[Link] User Acceptance Testing . . . . . . . . . . . . . . . . . . . . . . 45
2.8.4 Real-World Example: Testing a Medical Records System . . . . . . . . . . . 45
2.9 Phase 6: System Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.9.1 Meaning of System Deployment . . . . . . . . . . . . . . . . . . . . . . . . 46
2.9.2 Methods of System Deployment . . . . . . . . . . . . . . . . . . . . . . . . 46
[Link] Direct Changeover . . . . . . . . . . . . . . . . . . . . . . . . . . 47
[Link] Parallel Changeover . . . . . . . . . . . . . . . . . . . . . . . . . 47
[Link] Phased Changeover . . . . . . . . . . . . . . . . . . . . . . . . . 47
[Link] Pilot Changeover . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.9.3 User Training and Documentation . . . . . . . . . . . . . . . . . . . . . . . 47
2.9.4 Real-World Example: Deploying a School Management System . . . . . . . 48
2.10 Phase 7: System Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.10.1 Meaning of System Maintenance . . . . . . . . . . . . . . . . . . . . . . . . 49
2.10.2 Types of System Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . 49

Makerere University - College of Computing and Information Sciences

Contents iv

[Link] Corrective Maintenance . . . . . . . . . . . . . . . . . . . . . . . 49

[Link] Adaptive Maintenance . . . . . . . . . . . . . . . . . . . . . . . . 49
[Link] Perfective Maintenance . . . . . . . . . . . . . . . . . . . . . . . 49
[Link] Preventive Maintenance . . . . . . . . . . . . . . . . . . . . . . . 50
2.10.3 Importance of System Maintenance . . . . . . . . . . . . . . . . . . . . . . 50
2.10.4 Real-World Example: Maintenance of Mobile Banking Systems . . . . . . . 50
2.11 SDLC Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.11.1 Waterfall Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.11.2 Iterative Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.11.3 Agile Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.11.4 Spiral Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.12 Challenges in System Development . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.12.1 Changing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.12.2 Budget Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.12.3 Technical Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
2.12.4 Security Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Chapter 3 System Development Approaches 56

3.1 Introduction to System Development Approaches . . . . . . . . . . . . . . . . . . . 56
3.1.1 Meaning of a Development Approach . . . . . . . . . . . . . . . . . . . . . 56
3.1.2 Why Different Approaches Exist . . . . . . . . . . . . . . . . . . . . . . . . 57
3.1.3 The Role of Process in Software Development . . . . . . . . . . . . . . . . 58
3.2 Categories of System Development Approaches . . . . . . . . . . . . . . . . . . . . 58
3.2.1 Predictive (Plan-Driven) Approaches . . . . . . . . . . . . . . . . . . . . . 59
3.2.2 Iterative and Incremental Approaches . . . . . . . . . . . . . . . . . . . . . 59
3.2.3 Evolutionary Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.2.4 Key Differences Between Categories . . . . . . . . . . . . . . . . . . . . . 60
3.3 Waterfall Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.3.2 Phases of the Waterfall Model . . . . . . . . . . . . . . . . . . . . . . . . . 61
[Link] Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
[Link] Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
[Link] Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
[Link] Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
[Link] Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
[Link] Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.3.3 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.3.4 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.3.5 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.3.6 Suitable Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Makerere University - College of Computing and Information Sciences

Contents v

3.4 Iterative and Incremental Development . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.4.1 Concept of Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.4.2 Incremental Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.4.3 Benefits of Early Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.4.4 Comparison with Waterfall . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.5 Spiral Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.5.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.5.2 Concept of Risk in Development . . . . . . . . . . . . . . . . . . . . . . . . 67
3.5.3 Phases of the Spiral Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
[Link] Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
[Link] Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
[Link] Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
[Link] Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.5.4 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.5.5 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.5.6 Suitable Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.6 Comparison of Development Approaches . . . . . . . . . . . . . . . . . . . . . . . 69
3.6.1 Comparison Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.6.2 Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.6.3 Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.6.4 Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.6.5 User Involvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.7 Choosing a Suitable Development Approach . . . . . . . . . . . . . . . . . . . . . . 72
3.7.1 Nature of Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.7.2 Project Size and Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.7.3 Time and Budget Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.7.4 User Involvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.7.5 Team Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.8 Common Challenges in Development Approaches . . . . . . . . . . . . . . . . . . . 73
3.8.1 Changing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.8.2 Poor User Involvement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.8.3 Inappropriate Approach Selection . . . . . . . . . . . . . . . . . . . . . . . 74
3.8.4 Lack of Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.10 Review Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Makerere University - College of Computing and Information Sciences

Chapter 1

The Necessity of Systematic Software Devel-

opment

1.1 The Nature of Software Systems

1.1.1 Programs versus Software Systems

The study of systematic software development begins with a foundational distinction: the difference
between a program and a software system.

A program is a sequence of instructions designed to perform a specific computational task.

A software system is an organized collection of interacting programs, data, interfaces, and supporting
components operating within a technical and social environment.

The difference between them is not merely size. It is structural.

A small grading script written for a class assignment can be executed, tested, and discarded. Its behav-
ior is limited, and its failure has minimal consequences. By contrast, a national examination platform
processes thousands of student records, integrates with financial and administrative systems, supports
authentication and authorization, and must operate reliably under heavy load. Failure in such a system
affects institutions, careers, and public trust.

The distinction becomes clearer when we examine three structural dimensions that transform pro-
grams into systems:

1. Scale
Software systems involve numerous interacting components, multiple users, and large volumes
of data.
2. Time
They persist and evolve over extended periods. New features are added, defects are corrected,
and requirements change.
3. Consequence
Their failure produces real-world effects—financial loss, reputational damage, legal liability, or
Chapter 1 The Necessity of Systematic Software Development 2

safety risks.
When these three dimensions are present, informal construction becomes insufficient.

Software systems also exhibit structural properties that small programs typically do not. These in-
clude:

Interdependence among components

Shared data and communication interfaces
Concurrent execution
External integrations (databases, networks, APIs)
Because of these properties, local changes may produce non-local effects. A small modification in
authentication logic may influence payment processing. A database schema change may affect report-
ing modules. Behavior emerges from interaction, not from isolated lines of code.

Another crucial distinction concerns cognition. A small program can often be fully understood by a
single individual. A large software system exceeds the cognitive capacity of any one person. Under-
standing must therefore be distributed through:

Architectural design
Documentation
Coding standards
Team coordination mechanisms
At this point, development can no longer rely on memory or intuition alone. Structure becomes nec-
essary for stability and continuity.

The transition from programming to software engineering is therefore a structural shift. Programming
solves isolated problems. Software engineering constructs reliable systems within complex, evolving
environments.

Recognizing this distinction provides the conceptual foundation for understanding why systematic
software development is not optional but necessary.

1.1.2 Software as an Engineered Artifact

To understand why systematic software development is necessary, software must be understood as an
engineered artifact rather than merely as code.

An engineered artifact is something intentionally constructed to satisfy defined requirements under

constraints. Bridges are engineered to carry specific loads. Aircraft are engineered to operate safely
under physical stress. Medical devices are engineered to function reliably within biological environ-

Makerere University - College of Computing and Information Sciences

Chapter 1 The Necessity of Systematic Software Development 3

ments. In each case, construction follows analysis, design, testing, and evaluation.

Software systems share these characteristics. They are created to meet functional requirements, oper-
ate under constraints such as limited resources and regulatory standards, and must maintain reliability
over time. When software operates within banks, hospitals, airports, or universities, it becomes in-
frastructure. Its correctness and stability directly affect people and institutions.

The distinction between informal programming and engineering becomes clear when we examine the
structural commitments that define engineering practice.

Engineering requires:

1. Explicit requirements.
The system must be built to satisfy clearly defined needs rather than assumptions. Ambiguity
at the beginning leads to instability later. For example, if a university registration system does
not clearly specify how course enrollment limits are enforced, inconsistent behavior may occur
when demand increases. Requirements formalize expectations and reduce uncertainty.

2. Design before large-scale implementation.

Structural decisions must precede extensive coding. Choices about database models, authenti-
cation mechanisms, communication protocols, and architectural layers shape the system’s long-
term behavior. Without prior design, development becomes reactive. Later modifications grow
increasingly expensive and destabilizing because foundational decisions were never intention-
ally made.

3. Systematic verification and validation.

Testing is not an afterthought; it is an integral part of construction. Verification ensures that
the system conforms to its specifications. Validation ensures that it satisfies user needs. In fi-
nancial systems, even small computational inaccuracies can accumulate into substantial losses.
Systematic testing protects against hidden defects.

4. Acknowledged responsibility.
Engineered artifacts are constructed with awareness of consequences. When a payment gate-
way fails, customers lose trust. When medical software miscalculates dosage, patient safety is
endangered. Engineering practice recognizes that failures are not merely technical errors; they
have material and ethical implications.

These commitments distinguish engineering from improvisation.

A small personal script may function without explicit requirements, architectural planning, formal

Makerere University - College of Computing and Information Sciences

Chapter 1 The Necessity of Systematic Software Development 4

testing, or documented accountability. However, once software becomes embedded within social and
economic systems, such informality becomes inadequate.

Software is uniquely flexible; it can be modified rapidly and repeatedly. Yet this flexibility increases
the risk of instability. Each change introduces new interactions within the system. Without disci-
plined processes—structured design, version control, documentation, and testing—the system gradu-
ally loses coherence.

Systematic development is therefore not an administrative burden placed upon programmers. It is the
structural response to constructing artifacts whose reliability, safety, and longevity matter.

The transition from writing code to engineering software marks a change in mindset. Programming fo-
cuses on solving isolated problems. Engineering focuses on constructing systems that endure, evolve,
and sustain trust.

1.1.3 Software as a Socio-Technical System

Software systems do not operate in isolation. They exist within environments shaped by people, in-
stitutions, regulations, and organizational practices. For this reason, a software system is not purely
technical. It is socio-technical.

A technical system consists of hardware, code, data structures, and algorithms. A social system con-
sists of users, administrators, managers, customers, regulators, and stakeholders. In real-world set-
tings, these two dimensions are inseparable.

Consider an online banking platform. Technically, it includes servers, encryption protocols, databases,
and application logic. Socially, it involves customers performing transactions, employees monitor-
ing fraud, regulators enforcing compliance, and support staff responding to errors. A failure in the
technical layer disrupts the social layer. A misunderstanding in the social layer—such as unclear user
requirements—introduces defects into the technical layer.

This interdependence changes how software must be developed.

When software affects human activity, it must account for human behavior. Users make mistakes.
They forget passwords. They misunderstand interfaces. They enter unexpected inputs. Systems must
therefore be designed not only for correctness under ideal conditions, but for robustness under realistic
human use.

Socio-technical systems also introduce institutional constraints. Laws may require data protection.

Makerere University - College of Computing and Information Sciences

Chapter 1 The Necessity of Systematic Software Development 5

Financial systems must comply with auditing standards. Health systems must protect patient confi-
dentiality. These constraints are not optional features; they shape system architecture from the begin-
ning.

Because software interacts with human systems, its development cannot be purely technical improvi-
sation. Requirements gathering must involve stakeholders. Design decisions must consider usability
and regulation. Testing must simulate realistic scenarios, not merely ideal ones.

Thus, systematic software development is necessary not only because of technical complexity, but
because software participates in social structures. Stability, trust, and accountability extend beyond
code into society.

1.1.4 Scale, Users, and Time as Structural Dimensions

Three structural dimensions fundamentally transform software from small programs into engineered
systems: scale, users, and time.

Scale refers to the number of interacting components and the volume of data processed. As systems
grow, interactions multiply. A small application may consist of a few modules. A large enterprise
system may consist of hundreds of services communicating across networks. The number of possible
interaction paths increases dramatically with scale. Informal reasoning becomes insufficient to predict
behavior.

Users introduce unpredictability. A single developer using their own script behaves in expected ways.
Thousands of users interacting simultaneously produce diverse inputs, unexpected sequences of ac-
tions, and concurrent operations. Systems must handle overload, conflicting requests, and malicious
behavior. Security and concurrency become structural concerns, not optional features.

Time transforms software into a living artifact. Unlike physical structures that change slowly, software
evolves rapidly. Requirements shift. Technologies become obsolete. Hardware platforms change.
Teams change. Over time, new features are layered onto old designs. Without systematic structure,
this accumulation leads to instability and technical debt.

These dimensions interact. A system used by millions over many years accumulates complexity not
only from code, but from historical decisions. Early shortcuts become long-term constraints. Tempo-
rary fixes become permanent architecture.

For example, a startup may build an application quickly to meet market demand. At small scale, in-
formal practices may appear effective. As user numbers grow and investors demand reliability, the

Makerere University - College of Computing and Information Sciences

Chapter 1 The Necessity of Systematic Software Development 6

absence of structured design becomes visible. Performance declines, bugs multiply, and new features
become difficult to integrate. What once worked no longer scales.

Scale, users, and time therefore function as structural pressures. They expose weaknesses in informal
development and make systematic processes necessary.

Software development becomes systematic not because of bureaucracy, but because these dimensions
impose limits on intuition and improvisation.

1.2 Complexity and the Limits of Informal Construction

1.2.1 Structural Complexity in Software

Complexity is the primary reason systematic software development becomes necessary.

A system is complex when it contains many interacting components whose collective behavior cannot
be easily predicted by examining each component in isolation. Software systems exhibit this property
naturally.

At small scale, a program may contain a few functions operating on limited data. A developer can
understand the entire structure at once. Informal reasoning is sufficient.

As scale increases, structure becomes layered. Modules depend on other modules. Services commu-
nicate across networks. Databases store interconnected data. Interfaces connect independent systems.
The number of interactions grows faster than the number of components themselves.

This growth is not linear. If ten modules interact, there are far more than ten potential interaction paths.
Each additional component increases the possible combinations of behavior. Complexity therefore ex-
pands combinatorially rather than proportionally.

Consider an e-commerce platform. It includes inventory management, payment processing, authenti-

cation, recommendation engines, shipping integration, and customer support systems. Each subsystem
may function correctly on its own. Yet the overall behavior of the platform depends on how these parts
interact.

Structural complexity arises from this network of relationships.

When systems reach this level, informal construction becomes unstable. Decisions made locally affect
distant components. A change in database structure may break reporting modules. A modification in

Makerere University - College of Computing and Information Sciences

Chapter 1 The Necessity of Systematic Software Development 7

authentication logic may disable payment authorization. Understanding requires structure, documen-
tation, and architectural discipline.

Complexity forces systematic organization because human intuition alone cannot manage large inter-
action networks.

1.2.2 Coupling and Interdependence

Coupling refers to the degree to which components depend on one another. In tightly coupled systems,
a change in one component directly affects many others. In loosely coupled systems, components in-
teract through clearly defined boundaries.

High coupling increases fragility.

Suppose an online store’s pricing logic is embedded directly inside multiple modules—order process-
ing, discounts, reporting, and analytics. If pricing rules change, modifications must be made in many
places. The probability of inconsistency increases.

Interdependence means that components do not operate independently. They share data, assumptions,
and communication protocols. Hidden dependencies are particularly dangerous because they are not
immediately visible.

In small programs, coupling may go unnoticed. In large systems, unmanaged coupling makes devel-
opment unpredictable. A seemingly minor change produces unintended consequences elsewhere.

Systematic development introduces architectural principles—such as modularity, encapsulation, and

interface definition—to manage coupling deliberately rather than accidentally.

Without such structure, software becomes brittle. Maintenance becomes slow. Risk increases with
every modification.

1.2.3 Nonlinearity and Cascading Effects

In complex systems, effects are not always proportional to causes. A small change may produce large
consequences. This property is known as nonlinearity.

Consider a simple change to a password validation rule in a banking system. If implemented incor-
rectly, users may be locked out simultaneously. Support systems become overloaded. Transaction

Makerere University - College of Computing and Information Sciences

Chapter 1 The Necessity of Systematic Software Development 8

processing slows. Financial operations are delayed. A small logical modification triggers a chain re-
action.

This cascading behavior occurs because components are interconnected. Errors propagate through
dependency chains.

In distributed systems, nonlinearity becomes even more pronounced. A delayed response in one ser-
vice may cause timeouts in another. Retrying mechanisms may increase traffic. Network congestion
may follow. What began as a small performance issue becomes a system-wide slowdown.

Informal construction rarely anticipates such chains of interaction.

Systematic development attempts to manage nonlinearity through controlled design, testing under
stress conditions, logging, monitoring, and gradual deployment strategies. These practices are not
administrative overhead; they are structural safeguards against amplification effects.

1.2.4 Emergent Behavior in Large Systems

Emergence occurs when the collective behavior of a system cannot be fully understood by analyzing
individual components alone.

Each module in a social media platform may function correctly in isolation. Yet the interaction be-
tween recommendation algorithms, user behavior, content ranking, and network effects may produce
unintended societal outcomes. These outcomes are not explicitly programmed; they arise from inter-
action patterns.

In technical terms, emergent behavior appears when global properties arise from local rules.

For example, concurrency bugs often emerge only under high load. Individual functions may be
correct, but when executed simultaneously, race conditions appear. These errors cannot always be
detected through isolated unit tests.

Large systems therefore behave differently from small programs. Their behavior depends on interac-
tions over time, under varying conditions, and across many users.

Because emergence cannot be fully predicted by intuition, systematic analysis, modeling, testing, and
monitoring become essential.

Complexity, coupling, nonlinearity, and emergence together reveal the limits of informal construction.

Makerere University - College of Computing and Information Sciences

Chapter 1 The Necessity of Systematic Software Development 9

As software systems grow in size and importance, intuitive development practices fail. Structure
becomes necessary not because of preference, but because complexity exceeds human cognitive ca-
pacity.

1.3 Human Cognitive Constraints and the Need for Abstraction

1.3.1 Limits of Individual Comprehension

The necessity of systematic software development is not determined by technology alone. It is also
determined by the limits of human cognition.

Human working memory is limited. A developer can actively reason about only a small number of
interacting elements at a time. When a system contains hundreds or thousands of interacting compo-
nents, no individual can fully grasp its entire structure simultaneously.

In small programs, a developer may hold the entire control flow and data relationships in mind. In
large systems, this becomes impossible. The system exceeds individual comprehension.

When understanding exceeds cognitive capacity, errors increase. Assumptions go unchecked. De-
pendencies are overlooked. Informal reasoning becomes unreliable.

Systematic development emerges as a structural response to these cognitive limits. It distributes un-
derstanding across artifacts such as architectural diagrams, documentation, naming conventions, and
design standards.

1.3.2 Decomposition and Modularity

Decomposition is the process of breaking a large system into smaller, manageable parts. Modularity
refers to organizing those parts so that each performs a distinct and coherent function.

A complex hospital management system may be decomposed into modules for patient records, billing,
appointment scheduling, and reporting. Each module can be developed, tested, and reasoned about
separately.

Modularity reduces cognitive load by limiting the number of interactions that must be considered at
once. Instead of understanding the entire system, a developer focuses on one module and its defined

Makerere University - College of Computing and Information Sciences

Chapter 1 The Necessity of Systematic Software Development 10

connections.

Without deliberate decomposition, systems become entangled. Functions overlap. Responsibilities

blur. Changes in one area unexpectedly affect others.

Systematic software development formalizes decomposition through architectural planning, respon-

sibility assignment, and controlled module boundaries.

1.3.3 Layered Architectures

Layering introduces hierarchical structure into software systems. Responsibilities are organized into
distinct levels, each serving a specific purpose.

For example, a web application may include a presentation layer, an application logic layer, and a data
access layer. The presentation layer handles user interaction. The application layer processes business
rules. The data layer manages storage and retrieval.

Layering reduces complexity by limiting direct interaction between distant components. Each layer
communicates only with adjacent layers according to defined rules.

This structure improves clarity and maintainability. A change in user interface design does not require
rewriting database logic. Similarly, modifying storage mechanisms does not alter business rules.

Layered architectures therefore function as cognitive scaffolding. They organize complexity into un-
derstandable levels and prevent uncontrolled interaction.

1.3.4 Interfaces and Encapsulation

Interfaces define how components communicate. Encapsulation restricts access to internal details
while exposing only necessary functionality.

In object-oriented systems, a class may expose public methods while hiding internal data structures.
In distributed systems, services expose APIs while concealing implementation details.

Encapsulation reduces cognitive burden by separating what a component does from how it does it. A
developer using a payment service needs to understand its interface, not its internal algorithm.

This separation enables independent development and testing. Components can evolve internally
without affecting others, provided their interfaces remain stable.

Makerere University - College of Computing and Information Sciences

Chapter 1 The Necessity of Systematic Software Development 11

Without encapsulation, internal details leak across the system. Dependencies multiply. Understand-
ing becomes fragmented and unstable.

Abstraction through interfaces and encapsulation is therefore not stylistic preference. It is a structural
necessity imposed by human cognitive limits.

The need for abstraction demonstrates that systematic software development is grounded not only in
technical complexity, but in the biological constraints of human reasoning.

1.4 Entropy and Structural Decay in Software Systems

1.4.1 Codebase Entropy

Software systems do not remain structurally stable over time. Even when initially well designed, they
tend to drift toward disorder unless actively maintained. This tendency can be described as codebase
entropy.

Entropy, in a structural sense, refers to the gradual loss of organization. In software, this appears as
inconsistent naming, duplicated logic, unclear dependencies, and undocumented modifications.

When multiple developers modify a system over months or years, local optimizations accumulate.
Small shortcuts are introduced to meet deadlines. Temporary fixes remain in place. Over time, these
changes reduce clarity and coherence.

Consider a growing web application. Early design decisions may have been simple and clean. As
new features are added quickly, modules expand beyond their original responsibilities. Code that
once served a narrow purpose becomes overloaded with exceptions and special cases.

Without systematic oversight, the structure becomes increasingly difficult to understand. Maintenance
slows. New defects appear more frequently. The system becomes fragile.

Codebase entropy is not caused by incompetence. It is a natural consequence of continuous change in

complex systems.

Makerere University - College of Computing and Information Sciences

Chapter 1 The Necessity of Systematic Software Development 12

1.4.2 Technical Debt

Technical debt refers to the long-term cost incurred when short-term solutions are chosen over struc-
turally sound design.

A development team may postpone architectural improvement in order to release a feature quickly.
While the feature may function correctly, the underlying design may become more complicated and
less flexible.

Over time, such decisions accumulate. Future modifications require more effort because they must
work around earlier shortcuts. Development speed decreases, even though the codebase grows larger.

For example, hard-coded configuration values may initially simplify development. As the system
scales, those values must be replaced with flexible configuration mechanisms. The cost of correcting
earlier decisions becomes higher than if they had been designed properly from the beginning.

Technical debt illustrates that informal construction does not merely risk immediate failure; it creates
structural burdens that constrain future evolution.

1.4.3 Architectural Drift

Architectural drift occurs when a system gradually deviates from its original design principles.

A system may begin with a clear layered architecture. Over time, developers may bypass layers for
convenience, allowing direct database access from user interface components or embedding business
logic inside presentation code.

These deviations often appear harmless individually. However, as they accumulate, the overall archi-
tecture loses coherence. Boundaries blur. Responsibilities overlap.

When architectural integrity weakens, the system becomes difficult to modify. Changes require un-
derstanding unexpected dependencies. Testing becomes unreliable because structural assumptions no
longer hold.

Architectural drift demonstrates that structure must be continuously enforced. Initial design alone is
insufficient.

Makerere University - College of Computing and Information Sciences

Chapter 1 The Necessity of Systematic Software Development 13

1.4.4 Refactoring as Structural Correction

Refactoring is the deliberate restructuring of existing code without changing its external behavior.

Its purpose is to restore clarity, reduce duplication, improve modularity, and realign implementation
with architectural principles.

For example, duplicated validation logic across multiple modules may be extracted into a shared ser-
vice. A large function performing multiple responsibilities may be decomposed into smaller, focused
functions.

Refactoring is not cosmetic adjustment. It is structural correction. It counteracts entropy and prevents
technical debt from becoming unmanageable.

Without systematic refactoring practices, software systems gradually lose structural integrity. Main-
tenance effort increases. Innovation slows. Risk accumulates.

Entropy, technical debt, architectural drift, and the need for refactoring together reveal an important
principle: software systems naturally decay unless disciplined processes actively preserve their struc-
ture.

Systematic software development therefore extends beyond initial construction. It includes continu-
ous structural maintenance to ensure long-term stability and adaptability.

1.5 Engineering Discipline and Predictability

1.5.1 From Craft to Engineering

Software development historically began as a craft practiced by individuals who wrote programs to
solve specific problems. Early systems were relatively small, and success depended largely on the
skill and intuition of the programmer. In such environments, informal techniques were often suffi-
cient.

As software systems became larger and more critical to economic and social infrastructure, the lim-
itations of craft-based development became apparent. Systems required coordination among many
developers, predictable behavior under diverse conditions, and long-term maintainability. Informal
approaches proved unreliable in these contexts.

Engineering differs from craft in its reliance on systematic principles. Engineering disciplines empha-

Makerere University - College of Computing and Information Sciences

Chapter 1 The Necessity of Systematic Software Development 14

size planning, repeatability, documentation, and accountability. These practices reduce uncertainty
and allow complex artifacts to be constructed reliably by teams rather than individuals.

The transition from craft to engineering in software development reflects the growing scale and im-
portance of software systems. Systematic processes enable organizations to produce reliable systems
even when individual developers change over time.

1.5.2 Process Standardization

Standardization introduces consistent methods for carrying out development activities. Instead of re-
lying on individual preferences, teams follow agreed procedures for designing, implementing, testing,
and deploying software.

Standard processes improve communication and coordination within development teams. When de-
velopers share common conventions for version control, documentation, and code review, collabora-
tion becomes more efficient and misunderstandings are reduced.

For example, modern software teams typically follow structured workflows for managing code changes.
Developers submit proposed modifications through review mechanisms that allow others to examine
and approve the changes before integration. Such processes reduce the likelihood of introducing de-
fects into the system.

Process standardization therefore contributes to predictability. Systems developed under consistent

procedures are easier to maintain and extend because their structure follows recognizable patterns.

1.5.3 Measurement and Quality Control

Engineering disciplines rely on measurement to evaluate progress and maintain quality. Software
engineering similarly requires mechanisms for assessing system reliability, performance, and main-
tainability.

Measurement may involve tracking defect rates, system response times, code complexity, or test cov-
erage. These indicators provide objective insight into the health of a software system and help identify
areas requiring improvement.

Quality control ensures that the system meets predefined standards before it is released or updated.
Automated testing frameworks, continuous integration pipelines, and performance monitoring tools
allow teams to detect problems early in the development process.

Makerere University - College of Computing and Information Sciences

Chapter 1 The Necessity of Systematic Software Development 15

Without measurement, development relies on subjective judgment. Objective metrics allow organi-
zations to evaluate whether a system satisfies its intended requirements and operational constraints.

1.5.4 Verification and Validation

Verification and validation are central activities in engineering practice. Verification asks whether the
system has been built correctly according to its design specifications. Validation asks whether the
system fulfills the needs of its intended users.

Verification techniques include unit testing, integration testing, and code reviews. These activities
confirm that individual components and their interactions behave as expected.

Validation focuses on real-world use. User testing, acceptance testing, and operational trials ensure
that the system functions effectively within its intended environment.

Both verification and validation are necessary because a system may be technically correct yet still
fail to meet user expectations. Systematic testing therefore bridges the gap between design intentions
and actual usage.

Through disciplined processes, measurement, and rigorous testing, engineering practices transform
software development from uncertain experimentation into a predictable and controllable activity.

1.6 Time, Evolution, and Software Longevity

1.6.1 Maintenance as a Structural Reality

Software systems are rarely static. Once deployed, they continue to evolve as requirements change,
new features are introduced, and defects are discovered. This ongoing activity is known as software
maintenance.

In many real-world systems, maintenance occupies a larger portion of the software lifecycle than ini-
tial development. A university registration platform, for example, may operate for many years while
undergoing continuous updates to accommodate new academic policies, security standards, and tech-
nological environments.

Maintenance therefore is not an occasional activity but a structural reality of software systems. De-
velopment practices must anticipate that systems will be modified repeatedly over time.

Makerere University - College of Computing and Information Sciences

Chapter 1 The Necessity of Systematic Software Development 16

Systematic development helps ensure that these modifications can be performed safely. Clear docu-
mentation, modular design, and consistent coding standards allow new developers to understand the
system even when the original authors are no longer involved.

1.6.2 Backward Compatibility

As software evolves, new versions must often remain compatible with existing data, interfaces, and
user workflows. This requirement is known as backward compatibility.

For example, a mobile banking application may introduce new features in each release, but customers
must still be able to access their existing accounts and transaction histories. If an update breaks com-
patibility with earlier data formats or interfaces, users may lose access to critical information.

Maintaining compatibility requires careful planning. Changes to databases, communication protocols,

or file formats must be designed so that older components can continue functioning correctly.

Without systematic development practices, updates may unintentionally disrupt existing functionality.
Backward compatibility therefore encourages disciplined design and controlled evolution of systems.

1.6.3 Scalability and Growth

Software systems often experience growth in both usage and functionality. A service that initially
supports a small group of users may eventually need to handle thousands or millions of interactions.
This ability to handle increasing demand is known as scalability.

Scalability involves more than increasing computing resources. The internal structure of the system
must support efficient processing, distributed workloads, and reliable communication between com-
ponents.

For instance, an online learning platform that begins with a single server may later require distributed
services, load balancing, and cloud infrastructure to support thousands of simultaneous students.

Systems designed without attention to scalability often become difficult to expand. Performance de-
clines as usage grows, forcing costly redesign efforts. Systematic development encourages architec-
tures that can adapt to growth over time.

Makerere University - College of Computing and Information Sciences

Chapter 1 The Necessity of Systematic Software Development 17

1.6.4 Architectural Foresight

Architectural foresight refers to the practice of designing software structures with future evolution in
mind. While it is impossible to predict all future requirements, thoughtful architecture allows systems
to adapt without major disruption.

For example, separating user interface components from business logic allows the interface to evolve
independently from the underlying rules of the system. Similarly, well-defined service boundaries
enable new features to be added without rewriting existing modules.

Architectural foresight does not require anticipating every possible change. Rather, it focuses on cre-
ating flexible structures that can accommodate reasonable extensions.

Systems developed without such foresight often accumulate technical constraints that make future
changes expensive and risky. Systematic development therefore encourages architectural thinking
that balances current functionality with long-term adaptability.

1.7 Risk, Failure, and Ethical Responsibility

1.7.1 Software in Safety-Critical Domains

Many software systems operate in environments where failure can directly threaten human safety.
These systems are often described as safety-critical because errors may lead to injury, loss of life, or
severe environmental damage.

Examples include software used in aircraft navigation, medical devices, railway control systems, and
power grid management. In such domains, software must function reliably under demanding condi-
tions and must be carefully tested before deployment.

The consequences of failure in these systems illustrate why systematic development is essential. Infor-
mal programming practices cannot provide the level of assurance required when human safety depends
on correct system behavior.

Engineers in safety-critical domains therefore follow rigorous development processes, including de-
tailed requirements analysis, extensive verification procedures, and strict certification standards.

Makerere University - College of Computing and Information Sciences

Chapter 1 The Necessity of Systematic Software Development 18

1.7.2 Security and Vulnerability

Modern software systems are often connected to networks and accessible through the internet. This
connectivity introduces security risks because attackers may attempt to exploit weaknesses in the sys-
tem.

A vulnerability is a flaw that allows unauthorized access, data theft, or disruption of service. Vulnera-
bilities may arise from programming errors, weak authentication mechanisms, or insufficient valida-
tion of user input.

For example, a poorly designed web application may allow attackers to manipulate database queries
and retrieve confidential information. Such incidents have occurred in financial institutions, govern-
ment services, and online platforms.

Systematic development practices reduce these risks by incorporating security considerations through-
out the design and implementation process. Security reviews, threat modeling, and automated vulner-
ability testing help identify weaknesses before systems are deployed.

1.7.3 Economic and Legal Consequences

Software failures can produce significant economic consequences. A malfunction in an online pay-
ment platform may interrupt transactions and cause financial loss for both businesses and customers.

Organizations increasingly rely on software to manage logistics, communication, healthcare records,

and financial operations. When these systems fail, the resulting disruptions can affect entire industries.

Legal consequences may also arise when software defects lead to data breaches, service outages, or
regulatory violations. Companies responsible for such failures may face lawsuits, financial penalties,
or loss of public trust.

These risks highlight the importance of disciplined engineering practices. Systematic development
helps reduce the probability of failures that could generate widespread economic and legal conse-
quences.

1.7.4 Professional Accountability

Software engineers hold professional responsibility for the systems they design and maintain. Their
decisions influence how software behaves in real-world environments and how safely it interacts with

Makerere University - College of Computing and Information Sciences

Chapter 1 The Necessity of Systematic Software Development 19

users and organizations.

Professional accountability requires developers to consider not only technical correctness but also the
broader impact of their work. Ethical responsibility includes protecting user privacy, ensuring system
reliability, and preventing foreseeable harm.

For example, developers responsible for health information systems must ensure that patient data re-
mains confidential and accurate. Failure to safeguard such information can undermine both medical
care and public trust.

Recognizing this responsibility encourages careful design, thorough testing, and adherence to profes-
sional standards. Systematic software development therefore supports not only technical quality but
also ethical practice in the profession.

Makerere University - College of Computing and Information Sciences

Chapter 2

Phases of the System Development Life Cycle

(SDLC)

2.1 Introduction to Information Systems Development

Modern organizations rely heavily on information systems to perform daily activities, manage data,
and support decision making. Banks process millions of financial transactions every day, hospitals
store and access patient medical records, and universities manage student registration and academic
records through computerized systems.

An information system is a collection of components that work together to collect, process, store,
and distribute information. These components usually include hardware, software, data, people, and
procedures that interact with each other to achieve organizational goals.

Developing a reliable information system is not a simple task. Systems must be carefully planned, de-
signed, built, and tested before they can be used in real-world environments. If systems are developed
without a proper method, they may fail, become too expensive, or fail to meet the needs of users.

To manage this complexity, organizations follow a structured process known as the System Develop-
ment Life Cycle (SDLC). The SDLC provides a step-by-step framework that guides developers from
the initial idea of a system to its deployment and maintenance.

The SDLC ensures that several important goals are achieved during system development:
user requirements are properly understood
systems are designed correctly
errors are identified early
systems remain reliable over time

2.1.1 Meaning of Information Systems

An information system is a system that collects data, processes it, stores it, and produces useful
information for users. The goal of an information system is to transform raw data into meaningful
information that supports decision making and operational activities.
Chapter 2 Phases of the System Development Life Cycle (SDLC) 21

Data refers to raw facts, while information refers to processed data that has meaning and context. For
example, numbers recorded in a system may represent temperatures, patient ages, or bank balances.
When these numbers are analyzed and interpreted, they become useful information.

For example, consider a hospital system. Nurses record patient information such as temperature, blood
pressure, and symptoms. These values represent raw data. The hospital system analyzes this data and
assists doctors in diagnosing diseases and recommending treatments. The processed results represent
useful information.

Information systems help organizations operate efficiently and make informed decisions by organiz-
ing and managing large volumes of data.

Example: Banking System

When a customer withdraws money from an Automated Teller Machine (ATM), several processes
occur within the bank’s information system. The ATM collects the customer’s card information and
PIN, verifies the account balance, processes the withdrawal request, and updates the account balance
after the transaction.

Without information systems, managing such transactions manually would be extremely slow and
prone to errors.

2.1.2 Importance of Information Systems in Organizations

Information systems play a critical role in modern organizations because they help organizations man-
age data, automate processes, and support communication between departments.

Some major benefits of information systems include the following:

1. Improved Efficiency
Systems automate tasks that were previously performed manually. For example, payroll systems
automatically calculate employee salaries, deductions, and taxes.
2. Better Decision Making
Managers can analyze reports generated by information systems to make strategic decisions.
3. Data Storage and Retrieval
Information systems allow organizations to store large volumes of information and retrieve it
quickly when needed.
4. Improved Communication
Different departments in an organization can easily share information through interconnected
systems.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 22

5. Enhanced Customer Service

Organizations can provide faster and more convenient services to customers through online plat-
forms and automated systems.

Example: Education System

Universities use student management systems to handle many administrative tasks such as student reg-
istration, course enrollment, recording grades, generating academic transcripts, and managing gradu-
ation records. These systems simplify academic administration and improve efficiency within educa-
tional institutions.

2.1.3 The Need for Structured System Development

Developing information systems without a structured process can lead to serious problems in system
development projects. For example, developers may misunderstand what users actually need, result-
ing in systems that do not solve the intended problem.

A structured development approach helps ensure that each stage of development is carefully planned
and executed. It also helps project managers monitor progress and control risks during the develop-
ment process.

A structured development process ensures that:

each stage of system development is clearly defined
project progress can be monitored effectively
potential risks are identified early
users are involved throughout the development process

The System Development Life Cycle (SDLC) provides this structured framework for developing
reliable information systems.

2.1.4 Problems with Unstructured System Development

If systems are developed without following a structured methodology, several serious problems may
arise during development and after system deployment.

1. Unclear Requirements
Developers may create systems that do not meet the needs of users.
2. Cost Overruns
Projects may exceed the planned development budget.
3. Project Delays

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 23

Without proper planning, system development may take longer than expected.
4. Poor System Quality
Systems may contain software bugs, design flaws, or security vulnerabilities.
5. User Dissatisfaction
Users may refuse to use the system if it does not solve their operational problems.

Example: Hospital System Failure

Suppose a hospital introduces a new patient record system without studying how doctors and nurses
actually work in the hospital environment. Several problems may arise because the system does not
match real clinical workflows.

Possible problems could include:

slow patient data entry
incomplete medical records
confusion among hospital staff
incorrect patient information being recorded

Such failures can seriously affect hospital operations and may even put patient safety at risk.

2.1.5 Overview of the System Development Life Cycle

The System Development Life Cycle (SDLC) is a structured framework used to guide the devel-
opment, deployment, and maintenance of information systems. It divides system development into
several clearly defined phases.

Each phase focuses on specific tasks that must be completed before the next phase begins. The main
phases of the SDLC include:
1. System Planning
2. Requirements Analysis
3. System Design
4. System Development (Implementation)
5. System Testing
6. System Deployment
7. System Maintenance

These phases form a systematic process that ensures systems are developed carefully and correctly.
Each phase builds upon the results of the previous phase to ensure that the final system meets organi-
zational needs.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 24

For example, planning identifies the problem that needs to be solved, analysis determines user require-
ments, design defines how the system will operate, development builds the system, testing verifies that
the system works correctly, deployment introduces the system to users, and maintenance ensures that
the system continues to function effectively over time.

2.2 Understanding the System Development Life Cycle (SDLC)

The System Development Life Cycle (SDLC) is a structured framework used for developing informa-
tion systems in a systematic and organized manner. It provides a sequence of stages that guide system
analysts, designers, and developers from the initial identification of a problem to the final maintenance
of a completed system.

In modern organizations, information systems are complex and often involve large amounts of data,
multiple users, and integration with other systems. Because of this complexity, developing systems
without a clear process can lead to confusion, errors, and project failure. The SDLC helps avoid these
problems by providing a well-defined development process.

The SDLC ensures that system development follows logical steps where each stage produces outputs
that serve as inputs to the next stage. This structured approach allows organizations to carefully plan,
analyze, design, build, and maintain systems while minimizing risks and development costs.

2.2.1 Definition of SDLC

The System Development Life Cycle (SDLC) can be defined as a structured process used by organi-
zations to design, develop, test, and maintain information systems. It consists of a series of phases that
guide the development of a system from its initial concept to its eventual retirement or replacement.

The main purpose of the SDLC is to ensure that systems are developed efficiently, meet user require-
ments, and operate reliably once they are deployed. By following clearly defined stages, developers
can ensure that problems are identified early and corrected before the system is completed.

For example, when a bank wants to introduce a new mobile banking application, the system cannot
simply be programmed immediately. Instead, the bank must first determine what services the appli-
cation should provide, such as checking account balances, transferring funds, or paying bills. These
requirements must be carefully studied before development begins.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 25

2.2.2 Objectives of the SDLC

The SDLC is designed to achieve several important objectives that ensure the successful development
of information systems. These objectives help guide system developers and ensure that systems meet
organizational needs.

The main objectives of the SDLC include the following:

to ensure that systems meet the requirements of users
to provide a clear structure for managing system development projects
to reduce development risks and unexpected problems
to ensure high system quality and reliability
to control development costs and project timelines

When these objectives are achieved, organizations are more likely to develop systems that are useful,
efficient, and sustainable over time.

2.2.3 Characteristics of the SDLC

The System Development Life Cycle has several key characteristics that distinguish it from unstruc-
tured system development approaches. These characteristics help ensure that system development
remains organized and manageable.

One important characteristic of the SDLC is that it divides system development into separate phases.
Each phase focuses on a specific set of activities, such as planning, analysis, or testing. This division
allows developers to concentrate on one task at a time while ensuring that all aspects of system devel-
opment are addressed.

Another important characteristic is documentation. During each phase of the SDLC, developers create
documents that describe system requirements, designs, and testing procedures. These documents help
ensure that everyone involved in the project understands how the system works.

The main characteristics of the SDLC include:

development occurs in clearly defined stages
each phase produces specific outputs or deliverables
documentation is produced throughout the development process
users and stakeholders are involved during development
testing and evaluation occur before system deployment

These characteristics help ensure that systems are developed systematically and that errors are identi-
fied early in the development process.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 26

2.2.4 Benefits of Using SDLC

The use of the System Development Life Cycle offers many advantages to organizations that develop
information systems. By following a structured process, organizations can improve the quality and
reliability of their systems.

One of the major benefits of the SDLC is improved project management. Because each phase of de-
velopment is clearly defined, project managers can track progress and ensure that tasks are completed
on time.

Another benefit is improved system quality. Testing and verification activities occur before systems
are deployed, which reduces the likelihood of system failures once the system is in operation.

The main benefits of the SDLC include:

improved system quality and reliability
better understanding of user requirements
reduced development risks
improved communication among project team members
better control of development time and costs

These benefits make the SDLC an essential framework for developing large and complex information
systems.

2.2.5 Limitations of the SDLC

Although the SDLC provides many advantages, it also has certain limitations that organizations must
consider when applying it to system development projects.

One limitation is that traditional SDLC approaches can be time-consuming. Because each phase must
be completed before the next phase begins, development may take longer compared to more flexible
development approaches.

Another limitation is that changes in system requirements may be difficult to accommodate once de-
velopment has progressed to later phases. If user needs change during development, modifying the
system may require repeating earlier phases of the SDLC.

Some common limitations of the SDLC include:

system development may take a long time

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 27

changes in requirements may be difficult to incorporate

extensive documentation may increase project costs
rigid development structures may limit flexibility

Despite these limitations, the SDLC remains one of the most widely used approaches for developing
reliable information systems in organizations.

2.3 Overview of the Phases of SDLC

The System Development Life Cycle (SDLC) divides the development of an information system into
several organized phases. Each phase focuses on a specific set of tasks that must be completed before
moving to the next stage of development. By breaking the development process into phases, devel-
opers can manage complex projects more effectively and reduce the risk of errors.

In practice, building an information system involves many activities such as identifying problems,
collecting user requirements, designing solutions, writing code, testing software, and maintaining the
system after deployment. The SDLC organizes these activities into logical stages so that development
can proceed in a structured and systematic manner.

Each phase of the SDLC produces outputs that serve as inputs to the next phase. For example, the
planning phase identifies the problem that needs to be solved, the analysis phase determines the re-
quirements of the system, and the design phase determines how the system will be constructed. This
structured progression ensures that system development is organized and manageable.

2.3.1 Concept of Development Phases

A development phase refers to a stage in the system development process where specific activities
are performed to achieve particular objectives. Each phase focuses on a different aspect of system
development and produces results that guide the next stage.

Dividing system development into phases makes it easier for project teams to manage complex tasks.
Instead of attempting to build an entire system at once, developers complete one stage at a time, en-
suring that each step is carefully reviewed before moving forward.

The major phases of the System Development Life Cycle typically include the following:
1. System Planning
2. Requirements Analysis
3. System Design

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 28

4. System Development (Implementation)

5. System Testing
6. System Deployment
7. System Maintenance

Each phase focuses on a different part of the system development process, and together they form a
complete framework for building and maintaining information systems.

2.3.2 Sequential Nature of the SDLC

The phases of the SDLC are usually performed in a sequential order. This means that one phase is
completed before the next phase begins. The results produced in one phase provide the foundation for
the next phase of development.

For example, developers cannot design a system before they understand the requirements of users.
Similarly, developers cannot test a system before the system has been developed. Because of this
dependency between phases, the SDLC follows a logical progression of steps.

This sequential structure helps ensure that problems are identified early in the development process.
If errors are detected during earlier phases, they can be corrected before the system is fully developed.
This reduces the cost and complexity of fixing problems later.

However, in some modern development approaches, phases may overlap or repeat in cycles to allow
greater flexibility and faster development. Despite these variations, the fundamental idea of dividing
development into phases remains an important principle in system development.

2.3.3 Diagram of the SDLC Process

The SDLC process is often represented as a cycle to illustrate that system development is a continuous
process. After a system is deployed and used in an organization, it will eventually require updates,
improvements, or replacement. These changes may lead to the beginning of a new development cycle.

A simplified representation of the SDLC process can be shown as follows:

Planning → Analysis → Design → Development → Testing → Deployment → Maintenance

This diagram shows that system development moves through a series of connected stages that guide
the creation and maintenance of an information system.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 29

In many organizations, the maintenance phase may last much longer than the earlier phases because
systems often remain in operation for many years. During this time, developers may fix bugs, update
features, and improve system performance.

2.3.4 Relationship Between SDLC Phases

The phases of the System Development Life Cycle are closely connected to one another. Each phase
depends on the results produced by previous phases and contributes to the success of later stages in
the development process.

For example, if user requirements are poorly defined during the analysis phase, the system design may
not correctly address user needs. This could lead to problems during testing or deployment. Because
of this interdependence, each phase must be performed carefully and thoroughly.

The relationship between SDLC phases can be understood through the following sequence of activi-
ties:
planning identifies the problem and determines whether a system should be developed
analysis determines what the system must accomplish
design determines how the system will operate
development constructs the system through programming
testing verifies that the system functions correctly
deployment introduces the system into the organization
maintenance ensures that the system continues to operate effectively

When these phases are executed properly, organizations can develop reliable systems that meet user
needs and support business operations effectively.

2.4 Phase 1: System Planning

The first phase of the System Development Life Cycle is system planning. This phase focuses on
identifying a problem, determining whether a system should be developed, and defining the overall
scope of the project. System planning is extremely important because decisions made at this stage
influence the entire development process.

During the planning phase, organizations examine their current situation and determine whether a new
system is needed or whether an existing system should be improved. Managers, system analysts, and
stakeholders work together to identify the goals that the new system should achieve.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 30

Proper planning helps organizations avoid unnecessary development costs and ensures that system
development projects address real organizational needs. Without careful planning, organizations may
develop systems that do not solve important problems or provide meaningful benefits.

2.4.1 Meaning of System Planning

System planning refers to the process of identifying system needs, defining project objectives, and
determining whether a proposed system is feasible and worthwhile to develop. This phase establishes
the foundation for the entire system development process.

During system planning, project teams determine the scope of the system, identify stakeholders, esti-
mate resources required for development, and determine the timeline for the project. These activities
help ensure that the project is realistic and achievable.

In many organizations, system planning begins when managers recognize a problem that needs to be
solved or an opportunity to improve operations using information technology.

2.4.2 Objectives of the Planning Phase

The planning phase has several important objectives that guide the development of a system. These
objectives help ensure that development efforts are focused on solving real problems and delivering
valuable solutions.

The main objectives of the system planning phase include the following:
identifying problems or opportunities that require a new system
defining the goals and scope of the proposed system
determining the resources required for system development
estimating the cost and time required to complete the project
determining whether the project is feasible and worthwhile to pursue

Achieving these objectives ensures that organizations invest their resources in projects that are prac-
tical and beneficial.

2.4.3 Identifying System Problems and Opportunities

One of the first activities in system planning is identifying problems in existing systems or recogniz-
ing opportunities to improve organizational operations. These problems may arise from inefficient

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 31

processes, outdated technology, or increasing organizational needs.

For example, a hospital may discover that patient records are stored in paper files, making it difficult
for doctors to access patient histories quickly. This problem may create an opportunity to introduce
an electronic medical record system that improves efficiency and accuracy.

Similarly, a bank may observe that customers spend long periods waiting in queues for services. The
bank may decide to introduce an online banking platform or mobile banking application to provide
faster services.

Identifying such problems and opportunities helps organizations determine where new systems can
provide the greatest benefits.

2.4.4 Feasibility Study

After identifying a potential system project, organizations conduct a feasibility study. A feasibility
study evaluates whether the proposed system can be successfully developed and implemented within
the organization’s available resources and constraints.

The feasibility study examines several factors such as technology requirements, development costs,
legal considerations, and the ability of users to adopt the system. If the project is found to be feasible,
development can proceed to the next phase of the SDLC.

Conducting a feasibility study helps organizations avoid investing time and money in projects that are
unlikely to succeed.

2.4.5 Types of Feasibility Analysis

Feasibility analysis evaluates different aspects of a proposed system to determine whether it is prac-
tical and beneficial to develop. Several types of feasibility are commonly examined during system
planning.

[Link] Technical Feasibility

Technical feasibility evaluates whether the required technology, hardware, software, and technical
expertise are available to develop and operate the proposed system.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 32

For example, if a hospital plans to implement a cloud-based medical records system, the organiza-
tion must ensure that it has reliable internet connectivity, secure servers, and trained technical staff to
manage the system.

[Link] Economic Feasibility

Economic feasibility examines whether the financial benefits of developing the system outweigh the
costs involved in development and maintenance. This analysis often involves cost-benefit analysis.

For example, a university may evaluate whether the cost of developing an online learning platform is
justified by the expected benefits such as increased student enrollment and improved learning acces-
sibility.

[Link] Operational Feasibility

Operational feasibility determines whether the proposed system will function effectively within the
organization and whether users are willing to adopt the system.

For example, if a hospital introduces a new patient management system, doctors and nurses must be
able to use the system easily during their daily work. If the system is too complex, staff may resist
using it.

[Link] Legal Feasibility

Legal feasibility examines whether the proposed system complies with laws, regulations, and organi-
zational policies. Some systems must follow strict legal guidelines, particularly in industries such as
banking and healthcare.

For example, medical information systems must comply with laws that protect patient privacy and
confidentiality.

[Link] Schedule Feasibility

Schedule feasibility evaluates whether the system can be developed within the required timeframe.
Some projects must be completed within strict deadlines due to business or regulatory requirements.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 33

For example, a bank introducing a new payment system may need to deploy the system before a reg-
ulatory deadline set by financial authorities.

2.4.6 Real-World Example: Planning a Hospital Management System

Consider a hospital that currently manages patient records using paper files stored in filing cabi-
nets. Doctors often experience delays when searching for patient information, and sometimes patient
records are misplaced or incomplete.

During the planning phase, hospital administrators identify the need for a Hospital Management In-
formation System. The goal of the system would be to store patient records electronically, allowing
doctors and nurses to access patient information quickly and securely.

The hospital then conducts a feasibility study to determine whether the system can be successfully
developed. The hospital evaluates whether it has the required technical infrastructure, financial re-
sources, and trained staff to implement the system.

2.5 Phase 2: Requirements Analysis

The second phase of the System Development Life Cycle is requirements analysis. During this
phase, system analysts study the needs of users and determine what the system must do in order to
solve the identified problem. The goal of requirements analysis is to clearly understand the expecta-
tions of stakeholders before the system is designed or developed.

Requirements analysis is one of the most important phases of system development. If system require-
ments are misunderstood or incomplete, the system that is eventually developed may fail to meet the
needs of users. For this reason, system analysts spend significant time communicating with stake-
holders and carefully documenting system requirements.

During this phase, analysts identify the functions the system must perform, the data it must store, and
the constraints that must be considered during development. These requirements are documented and
later used as the foundation for system design.

2.5.1 Meaning of Requirements Analysis

Requirements analysis is the process of gathering, analyzing, and documenting the needs and expec-
tations of users for a proposed system. The objective is to understand exactly what the system must

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 34

accomplish before any design or programming work begins.

During this phase, system analysts communicate with different stakeholders such as managers, em-
ployees, customers, and technical staff. These stakeholders provide valuable insights about how the
system should operate and what features it should include.

The output of this phase is usually a document known as the System Requirements Specification
(SRS). This document clearly describes what the system must do and serves as a reference for design-
ers and developers during later stages of the SDLC.

2.5.2 Importance of Requirements Gathering

Gathering system requirements is essential because it helps ensure that the final system addresses real
user needs. If developers begin designing or coding without fully understanding the requirements,
they may build a system that does not solve the intended problem.

Proper requirements gathering helps organizations avoid costly mistakes during development. Identi-
fying requirements early allows developers to design systems correctly from the beginning rather than
making major changes later in the project.

Some important reasons why requirements gathering is necessary include:

ensuring that developers understand user needs
reducing misunderstandings between developers and stakeholders
identifying system constraints and limitations early
providing a clear guide for system design and development
improving the overall quality of the final system

When requirements are properly documented, developers can use them as a blueprint for designing
and building the system.

2.5.3 Techniques for Collecting Requirements

System analysts use several techniques to gather information about user needs and system require-
ments. These techniques help analysts obtain accurate information about how the system should func-
tion and how users interact with existing systems.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 35

[Link] Interviews
Interviews involve direct discussions between system analysts and stakeholders. During interviews,
analysts ask questions about current problems, user expectations, and desired system features.

Interviews allow analysts to gather detailed information and clarify complex requirements. They are
particularly useful when analysts need to understand specific operational procedures used by employ-
ees.

[Link] Questionnaires
Questionnaires are written surveys distributed to users to collect information about system require-
ments. They are useful when there are many users who need to provide input about the system.

Questionnaires allow analysts to collect standardized information from a large group of respondents
in a short period of time.

[Link] Observation
Observation involves watching users perform their daily tasks to understand how current systems op-
erate. By observing employees at work, analysts can identify inefficiencies and determine how a new
system can improve operations.

For example, an analyst observing hospital staff may notice delays in accessing patient files and may
recommend an electronic records system to improve efficiency.

[Link] Document Analysis

Document analysis involves reviewing existing documents such as reports, forms, manuals, and records
used in the current system. These documents help analysts understand how information flows through
the organization.

By examining existing documentation, analysts can identify important data elements and processes
that must be included in the new system.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 36

[Link] Workshops
Workshops involve group meetings where stakeholders and system analysts discuss system require-
ments collectively. Workshops allow participants to share ideas, identify problems, and agree on
system features.

These collaborative sessions often help organizations reach a shared understanding of system require-
ments more quickly than individual interviews.

2.5.4 Functional vs Non-Functional Requirements

System requirements are generally classified into two main categories: functional requirements and
non-functional requirements. Both types are essential for designing effective systems.

Functional requirements describe the specific tasks or functions that the system must perform. These
requirements focus on what the system should do.

Examples of functional requirements include:

a banking system must allow customers to check account balances
a hospital system must store patient medical records
a university system must allow students to register for courses

Non-functional requirements describe how the system should perform its tasks. These requirements
define system quality attributes such as performance, security, and reliability.

Examples of non-functional requirements include:

the system must respond to user requests within two seconds
the system must protect sensitive user data through encryption
the system must operate reliably without frequent failures

Both types of requirements are important because a system must not only perform the required tasks
but must also perform them efficiently and securely.

2.5.5 Real-World Example: Banking ATM System Requirements

Consider a bank planning to introduce a new Automated Teller Machine (ATM) system. During the
requirements analysis phase, system analysts gather information from bank managers, IT staff, and
customers to determine what services the ATM should provide.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 37

The analysts may identify several functional requirements such as allowing customers to withdraw
cash, check account balances, transfer funds between accounts, and print transaction receipts. These
requirements describe what the ATM system must be capable of doing.

The analysts also identify non-functional requirements such as ensuring that transactions are processed
securely, limiting response times so customers do not wait too long, and ensuring that the system op-
erates reliably throughout the day.

By carefully documenting these requirements, the bank ensures that developers understand exactly
what the ATM system must accomplish before moving to the system design phase.

2.6 Phase 3: System Design

After system requirements have been clearly identified and documented, the next phase of the System
Development Life Cycle is system design. During this phase, developers determine how the system
will be constructed in order to satisfy the requirements identified during the analysis phase. System
design acts as a blueprint that guides developers during the implementation phase.

In this stage, system architects and designers translate system requirements into detailed technical
specifications. These specifications describe how data will be stored, how users will interact with the
system, how system components will communicate, and how the system will maintain security and
reliability.

System design is extremely important because it determines how well the final system will perform.
A well-designed system is easier to implement, easier to maintain, and more reliable for users.

2.6.1 Meaning of System Design

System design refers to the process of defining the architecture, components, interfaces, and data
structures of a system so that it can meet the requirements identified during the analysis phase. It
transforms system requirements into a structured plan that developers can follow during implementa-
tion.

During system design, developers determine how different parts of the system will work together.
This includes deciding how information will flow through the system, how databases will store data,
and how users will interact with the system through interfaces.

The design phase ensures that developers clearly understand how the system will operate before cod-
ing begins. This helps prevent confusion during development and reduces the risk of major design

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 38

errors later in the project.

2.6.2 Objectives of System Design

The system design phase has several objectives that guide the creation of a well-structured system ar-
chitecture. These objectives ensure that the system will operate efficiently and meet user expectations.

The main objectives of the system design phase include the following:
defining the overall architecture of the system
determining how system components will interact
designing databases for storing system data
designing user interfaces for interacting with the system
ensuring system security and performance requirements are satisfied

Achieving these objectives ensures that developers have a clear technical plan to follow during the
implementation phase.

2.6.3 Types of System Design

System design is generally divided into two major levels: logical design and physical design. These
two levels help developers gradually transform system requirements into a complete technical solution.

[Link] Logical Design

Logical design describes the overall structure and functionality of the system without focusing on spe-
cific technologies or implementation details. It focuses on how information flows within the system
and how different processes interact.

Logical design often describes system processes, data structures, and relationships between system
components. It provides a high-level view of how the system will function from the user’s perspective.

For example, in a university student management system, logical design would describe processes
such as student registration, course enrollment, and grade recording without specifying the exact pro-
gramming language or database technology used.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 39

[Link] Physical Design

Physical design describes how the system will actually be implemented using specific technologies. It
includes details about hardware, software platforms, database structures, and network configurations.

In this stage, designers specify technical details such as database tables, programming languages, sys-
tem architecture, and hardware requirements. These decisions guide developers during the coding
phase.

For example, the physical design of a banking system may specify that the system will use a relational
database, a web-based interface, and secure servers to process financial transactions.

2.6.4 Key Components of System Design

System design includes several important components that determine how the system will operate.
These components ensure that the system can effectively process information and interact with users.

[Link] Database Design

Database design focuses on organizing and structuring the data that will be stored in the system. De-
signers determine what data must be stored, how the data is related, and how it will be retrieved when
needed.

A well-designed database ensures that data is stored efficiently and can be accessed quickly by the
system. Poor database design may lead to slow performance and data inconsistencies.

[Link] Interface Design

Interface design focuses on how users will interact with the system. Designers determine how screens,
forms, and menus will appear and how users will input and retrieve information from the system.

A good user interface should be simple, intuitive, and easy to use. If a system interface is confusing
or difficult to navigate, users may struggle to perform their tasks efficiently.

[Link] Process Design

Process design describes how system operations will be carried out. It defines how data will be pro-
cessed, how calculations will be performed, and how different system components will communicate

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 40

with each other.

Process design ensures that system operations are efficient and that tasks are performed in the correct
sequence.

[Link] Security Design

Security design focuses on protecting system data and ensuring that only authorized users can access
sensitive information. This includes implementing authentication mechanisms, access control poli-
cies, and data protection techniques.

Security is especially important in systems that handle sensitive information such as medical records,
financial transactions, or personal data.

2.6.5 Real-World Example: Designing an E-Learning System for a University

Consider a university that plans to introduce an online learning platform to support digital education.
During the design phase, system designers determine how the platform will operate and how students
and lecturers will interact with it.

Designers first determine the database structure required to store student information, course mate-
rials, assignments, and examination results. They also design user interfaces that allow students to
access course content, submit assignments, and communicate with instructors.

In addition, the designers ensure that the platform includes security mechanisms to protect student
data and restrict access to authorized users. They also determine how the system will handle large
numbers of students accessing learning materials simultaneously.

Once these design decisions are completed, developers can proceed to the next phase of the System
Development Life Cycle, which is system development and implementation.

2.7 Phase 4: System Development (Implementation)

After the system design has been completed, the next phase of the System Development Life Cycle
is system development, also known as the implementation phase. During this phase, developers be-
gin constructing the system based on the specifications created during the design phase. This stage
involves writing program code, configuring system components, and integrating different parts of the

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 41

system.

The implementation phase transforms system design documents into a working software system. Pro-
grammers use programming languages, development tools, and software frameworks to build the sys-
tem according to the requirements and design plans developed earlier.

This phase requires collaboration among programmers, system architects, database administrators,
and project managers. Each team member contributes to building different components of the system
while ensuring that all parts function together properly.

2.7.1 Meaning of System Development

System development refers to the process of creating the actual system by writing program code and
assembling all the components specified in the system design. This phase converts theoretical plans
into a functional system that users can interact with.

During development, programmers translate system designs into software programs using program-
ming languages such as Java, Python, C#, or PHP. These programs implement the features and pro-
cesses that were defined during earlier phases of the SDLC.

The development phase may involve building several different components, including databases, ap-
plication software, user interfaces, and communication modules that allow different parts of the system
to interact with each other.

2.7.2 Programming and Coding Activities

Programming is the core activity during system development. Programmers write code that instructs
computers on how to perform specific tasks such as processing data, validating user input, storing
information, and generating reports.

The coding process involves translating system design specifications into executable instructions. Pro-
grammers carefully implement algorithms and data structures that enable the system to perform its
intended functions.

During this phase, developers often divide the system into smaller modules so that different program-
mers can work on different parts of the system simultaneously. Once the modules are completed, they
are integrated to form the complete system.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 42

2.7.3 Tools and Technologies Used in Development

Modern system development relies on various tools and technologies that assist developers in building
reliable software systems. These tools help improve productivity, reduce errors, and simplify system
development tasks.

Some common tools and technologies used in system development include:

programming languages used to write system code
integrated development environments used for writing and debugging software
database management systems used for storing system data
version control systems used to manage changes in source code
testing tools used to identify and correct programming errors

These technologies enable development teams to build complex systems efficiently and ensure that
system components function correctly.

2.7.4 Role of Developers and Engineers

Several professionals contribute to the system development phase. Each member of the development
team performs specific tasks to ensure that the system is implemented successfully.

The roles involved in system development typically include the following:

software developers who write the system code
system architects who guide the overall technical structure of the system
database administrators who design and manage system databases
quality assurance engineers who ensure code quality and reliability
project managers who coordinate development activities and timelines

Effective collaboration among these professionals is essential for ensuring that the system is built cor-
rectly and delivered within the planned timeframe.

2.7.5 Real-World Example: Development of an Online Banking Application

Consider a bank that has designed an online banking platform that allows customers to manage their
accounts through the internet. During the development phase, programmers begin building the appli-
cation according to the system design specifications.

Developers write software that allows users to log into the system securely, view their account bal-
ances, transfer money between accounts, and pay bills electronically. The system also includes se-

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 43

curity mechanisms such as authentication procedures and encryption to protect sensitive financial
information.

Database developers create tables to store customer account information, transaction records, and ac-
count balances. At the same time, interface designers develop web pages that allow customers to
interact with the system easily.

Once the coding process is complete, the system is ready to move to the next phase of the System
Development Life Cycle, which is system testing.

2.8 Phase 5: System Testing

After the system has been developed, it must be carefully examined to ensure that it functions cor-
rectly. This stage of the System Development Life Cycle is known as system testing. During this
phase, developers verify that the system operates according to the requirements and design specifica-
tions established earlier.

System testing is essential because newly developed software may contain errors, known as bugs,
which can cause the system to malfunction. These errors must be detected and corrected before the
system is introduced to real users.

Testing helps ensure that the system performs its intended functions, handles unexpected situations
properly, and meets quality standards such as reliability, security, and performance.

2.8.1 Meaning of System Testing

System testing refers to the process of evaluating a system to determine whether it operates correctly
and meets the requirements defined during the analysis phase. It involves executing the system with
different types of input data and observing the system’s behavior.

The purpose of testing is to identify defects, verify system functionality, and ensure that the system
behaves as expected under various conditions. If errors are discovered during testing, developers cor-
rect them before the system is deployed.

Testing helps developers confirm that the system performs all required operations accurately and con-
sistently.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 44

2.8.2 Importance of Testing

System testing plays a critical role in ensuring the success of a software system. Without testing, soft-
ware errors may remain hidden until the system is already in use, which can cause serious operational
problems.

For example, if a banking system contains an error that incorrectly calculates account balances, cus-
tomers may lose confidence in the bank. Testing helps detect such issues before the system is deployed.

The importance of system testing includes the following:

identifying software errors before system deployment
verifying that system functions operate correctly
improving system reliability and performance
ensuring that the system satisfies user requirements
increasing user confidence in the system

Thorough testing helps ensure that the system performs correctly and can be trusted by users.

2.8.3 Types of System Testing

Several types of testing are performed during this phase to evaluate different aspects of the system.
Each type of testing focuses on a specific level of the system to ensure that all components operate
correctly.

[Link] Unit Testing

Unit testing focuses on testing individual components or modules of a system. Developers examine
each program unit separately to verify that it performs the intended function correctly.

For example, a function that calculates a customer’s account balance in a banking application may be
tested independently to ensure that it produces accurate results.

[Link] Integration Testing

Integration testing evaluates how different modules of the system interact with each other. Even if
individual components function correctly, problems may arise when these components are combined.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 45

Integration testing ensures that data flows correctly between system components and that modules
work together as expected.

[Link] System Testing

System testing evaluates the complete system as a whole. During this stage, testers examine whether
the entire system performs all required functions correctly.

System testing checks whether the system satisfies both functional and non-functional requirements
such as performance, reliability, and security.

[Link] User Acceptance Testing

User Acceptance Testing (UAT) is performed by actual users of the system to verify that the system
meets their needs and expectations. Users test the system in real-world scenarios to ensure that it
performs tasks correctly and supports their work processes.

If users confirm that the system operates as expected, the system can proceed to the deployment phase.

2.8.4 Real-World Example: Testing a Medical Records System

Consider a hospital that has developed an electronic medical records system. Before the system is
introduced into the hospital environment, developers conduct several types of testing to ensure that
the system operates correctly.

During unit testing, developers test individual components such as patient registration, record re-
trieval, and appointment scheduling. Each module is examined separately to verify that it performs
its intended task.

During integration testing, developers check whether different modules communicate properly. For
example, when a doctor updates a patient’s diagnosis, the updated information must appear correctly
in the patient history records.

Finally, doctors and nurses perform user acceptance testing by using the system in simulated hospital
scenarios. If the system performs reliably and supports clinical workflows effectively, the hospital can
proceed to the next phase of the System Development Life Cycle, which is system deployment.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 46

2.9 Phase 6: System Deployment

After a system has been successfully tested and verified to function correctly, it is introduced into
the real organizational environment. This stage of the System Development Life Cycle is known as
system deployment. During deployment, the system becomes available for actual use by its intended
users.

System deployment involves installing the system, configuring its components, training users, and
ensuring that the system operates properly within the organization. This phase marks the transition
from development to operational use.

Deployment must be carefully managed because introducing a new system may affect daily operations
within an organization. If the deployment process is poorly planned, it may disrupt normal activities
or create confusion among users.

2.9.1 Meaning of System Deployment

System deployment refers to the process of installing a newly developed system into the operational
environment where it will be used by end users. This process includes setting up hardware, installing
software, configuring databases, and ensuring that the system operates correctly within the organiza-
tion’s infrastructure.

During deployment, organizations also ensure that system users understand how to operate the system.
Training sessions and user documentation are often provided so that employees can learn how to use
the system effectively.

Once deployment is completed, the system begins performing real organizational tasks and supporting
operational activities.

2.9.2 Methods of System Deployment

Organizations may introduce new systems using different deployment strategies. The choice of strat-
egy depends on factors such as system complexity, risk tolerance, and the importance of maintaining
uninterrupted operations.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 47

[Link] Direct Changeover

Direct changeover occurs when the old system is immediately replaced by the new system. Once the
new system is installed, the old system is no longer used.

This approach is simple but risky because if the new system fails, there may be no backup system
available.

[Link] Parallel Changeover

Parallel changeover involves operating the old system and the new system simultaneously for a pe-
riod of time. This allows organizations to compare results from both systems and ensure that the new
system functions correctly.

If problems occur in the new system, the organization can continue using the old system until the
issues are resolved.

[Link] Phased Changeover

Phased changeover introduces the new system gradually. Instead of replacing the entire system at
once, different components or modules are implemented step by step.

This approach reduces risk because problems can be identified and corrected before the entire system
is deployed.

[Link] Pilot Changeover

Pilot changeover involves introducing the new system in a limited part of the organization before
deploying it across the entire organization. For example, a company may test a new system in one
department before expanding it to other departments.

This method allows organizations to identify potential issues in a controlled environment before full
deployment.

2.9.3 User Training and Documentation

Successful system deployment requires that users understand how to operate the new system. Organi-
zations therefore provide training programs to help employees learn how to use the system effectively.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 48

Training sessions may include demonstrations, workshops, and practice exercises that allow users to
become familiar with system features and functions.

In addition to training, organizations provide documentation that explains how the system operates.
Documentation may include user manuals, installation guides, and troubleshooting instructions.

2.9.4 Real-World Example: Deploying a School Management System

Consider a secondary school that has developed a digital school management system to manage stu-
dent records, attendance, and examination results. After the system has been tested, the school begins
the deployment process.

The school’s IT team installs the system on the school’s computers and configures the database that
stores student information. Teachers and administrative staff are then trained on how to enter student
grades, track attendance, and generate academic reports.

During the initial weeks of deployment, the school may operate both the new digital system and the
previous manual record system simultaneously to ensure that the new system functions correctly.

Once the system operates reliably and staff members become comfortable using it, the school fully
adopts the new system for managing academic records.

2.10 Phase 7: System Maintenance

After a system has been deployed and is actively used within an organization, the development process
does not end. Systems must continue to operate correctly, adapt to changes, and improve over time.
The phase of the System Development Life Cycle responsible for these activities is known as system
maintenance.

System maintenance involves monitoring the system, correcting errors, updating system features, and
adapting the system to changing organizational needs. Because organizations and technologies evolve
continuously, most systems require periodic updates and improvements.

In many cases, the maintenance phase lasts longer than all other phases of the SDLC combined. Sys-
tems may remain in operation for many years, and during this time developers regularly update and
improve them.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 49

2.10.1 Meaning of System Maintenance

System maintenance refers to the process of modifying and updating a system after it has been de-
ployed in order to correct problems, improve performance, or adapt the system to new requirements.

Maintenance activities ensure that the system continues to function properly and remains useful as
organizational needs change. For example, new regulations, technological advancements, or changes
in business processes may require updates to the system.

Without regular maintenance, systems may become outdated, inefficient, or vulnerable to security
threats.

2.10.2 Types of System Maintenance

System maintenance can be classified into several categories depending on the purpose of the modi-
fications made to the system. Each type of maintenance addresses different system needs.

[Link] Corrective Maintenance

Corrective maintenance involves fixing errors or defects that are discovered after the system has been
deployed. Even after extensive testing, some issues may only become visible when the system is used
in real operational environments.

Developers identify the source of the problem and modify the system to correct the error so that the
system functions properly.

[Link] Adaptive Maintenance

Adaptive maintenance occurs when the system must be modified to operate in a new environment or
accommodate changes in technology or organizational policies.

For example, a banking system may require updates to support new financial regulations or to operate
on updated hardware and operating systems.

[Link] Perfective Maintenance

Perfective maintenance focuses on improving system performance, usability, or functionality. These
improvements are often made in response to feedback from system users.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 50

For example, developers may improve a system interface to make it easier to use or add new features
that increase the system’s usefulness.

[Link] Preventive Maintenance

Preventive maintenance involves making changes to the system to prevent future problems. These
changes improve system reliability and reduce the likelihood of failures occurring later.

Examples include improving system documentation, restructuring program code, and enhancing se-
curity mechanisms to prevent potential vulnerabilities.

2.10.3 Importance of System Maintenance

System maintenance is essential for ensuring that information systems remain reliable and useful over
time. Without maintenance, systems may become inefficient or incompatible with new technologies
and organizational requirements.

The importance of system maintenance includes the following:

ensuring that the system continues to function correctly
improving system performance and usability
adapting the system to new technologies or regulations
protecting the system from security threats
extending the operational lifespan of the system

Regular maintenance allows organizations to maximize the value of their information systems and
maintain efficient operations.

2.10.4 Real-World Example: Maintenance of Mobile Banking Systems

Consider a bank that provides a mobile banking application used by thousands of customers. After
the system is deployed, the bank must continuously maintain and improve the application to ensure
that it operates reliably.

Developers regularly update the application to fix software bugs discovered by users. They may also
add new features such as biometric login, improved transaction notifications, or enhanced security
mechanisms.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 51

In addition, the bank must adapt the system to new financial regulations and update the application to
support newer mobile devices and operating systems.

Through continuous maintenance, the bank ensures that the mobile banking system remains secure,
reliable, and convenient for customers.

2.11 SDLC Models

Although the System Development Life Cycle describes the general phases of system development,
different organizations may follow different approaches when implementing these phases. These ap-
proaches are known as SDLC models. An SDLC model provides a structured method for organizing
the activities involved in planning, developing, testing, and maintaining information systems.

SDLC models help development teams manage complex projects by defining how the different phases
of the development life cycle are carried out and how they interact with one another. Some models
follow a strictly sequential approach, while others allow iterative development and continuous feed-
back from users.

The choice of an SDLC model depends on several factors such as the size of the project, the complex-
ity of the system, the level of risk involved, and the need for flexibility during development.

2.11.1 Waterfall Model

The Waterfall Model is one of the earliest and most traditional approaches to system development.
In this model, development progresses through the SDLC phases in a strictly sequential order. Each
phase must be completed before the next phase begins.

The waterfall model emphasizes careful planning and detailed documentation before moving forward
with development. Because each phase must be completed before proceeding, this model ensures that
requirements are clearly defined before design and implementation begin.

The waterfall model typically follows these stages:

1. system planning
2. requirements analysis
3. system design
4. system implementation
5. system testing
6. system deployment

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 52

7. system maintenance

The waterfall model works well for projects where requirements are clearly understood and unlikely
to change. However, it can be difficult to accommodate new requirements once development has pro-
gressed to later stages.

2.11.2 Iterative Model

The Iterative Model allows system development to occur through repeated cycles known as itera-
tions. Instead of developing the entire system at once, developers build a small portion of the system,
test it, evaluate it, and then improve it in subsequent iterations.

This model allows developers to gradually refine the system while incorporating feedback from users.
As each iteration is completed, additional features and improvements are added to the system.

The iterative approach is particularly useful for complex systems where requirements may evolve over
time. It allows development teams to detect problems early and improve the system continuously.

2.11.3 Agile Model

The Agile Model is a modern software development approach that emphasizes flexibility, collabora-
tion, and rapid delivery of functional system components. Agile development focuses on delivering
small portions of the system in short development cycles known as sprints.

Agile encourages frequent communication between developers and users so that requirements can
evolve during development. Instead of waiting until the system is fully completed, users can interact
with early versions of the system and provide feedback that guides further development.

Agile development is characterized by the following principles:

frequent delivery of working software
close collaboration between developers and stakeholders
flexibility in responding to changing requirements
continuous improvement through feedback and iteration

Because of its flexibility and responsiveness, agile development has become widely used in modern
software engineering projects.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 53

2.11.4 Spiral Model

The Spiral Model combines elements of both iterative development and risk management. In this
model, system development progresses through repeated cycles known as spirals. Each spiral repre-
sents a phase of planning, risk analysis, development, and evaluation.

The spiral model places strong emphasis on identifying and reducing risks throughout the development
process. Before proceeding to the next stage of development, potential risks are carefully analyzed
and addressed.

This model is particularly useful for large and complex projects where the consequences of system
failure could be severe. By continuously evaluating risks, organizations can ensure that development
proceeds safely and effectively.

Although the spiral model provides strong risk management capabilities, it can be complex to imple-
ment and may require experienced project managers to manage the development process effectively.

2.12 Challenges in System Development

Although the System Development Life Cycle provides a structured framework for developing infor-
mation systems, real-world system development projects often face various challenges. These chal-
lenges may arise from technical difficulties, organizational constraints, or changing user requirements.

Understanding these challenges is important for system analysts, developers, and project managers
because it allows them to anticipate potential problems and take appropriate actions to reduce risks
during development.

If these challenges are not managed properly, system development projects may experience delays,
increased costs, reduced system quality, or even complete project failure.

2.12.1 Changing Requirements

One of the most common challenges in system development is the problem of changing requirements.
During the early phases of the SDLC, users may not fully understand what they need from the system.
As development progresses, users may request new features or modifications to existing requirements.

When requirements change frequently, developers may need to redesign parts of the system, modify
existing code, or repeat earlier phases of the development process. This can increase the cost and time
required to complete the project.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 54

For example, a university developing an online student registration system may initially plan to in-
clude course enrollment and grade reporting features. Later, administrators may request additional
features such as automated timetable generation or integration with online payment systems.

2.12.2 Budget Constraints

Another major challenge in system development is limited financial resources. Developing informa-
tion systems requires significant investment in hardware, software, skilled personnel, and infrastruc-
ture.

If project costs exceed the available budget, organizations may be forced to reduce system features,
delay development activities, or cancel the project entirely.

Proper planning and cost estimation during the early phases of the SDLC help organizations manage
budget constraints and ensure that resources are used efficiently.

2.12.3 Technical Limitations

Technical limitations can also create challenges during system development. These limitations may
arise from outdated hardware, incompatible software systems, insufficient technical expertise, or lim-
ited access to required technologies.

For example, a hospital attempting to implement an advanced electronic medical records system may
face difficulties if the existing computer infrastructure cannot support the required software applica-
tions.

Addressing technical limitations often requires upgrading hardware, acquiring new software plat-
forms, or providing additional training for technical staff.

2.12.4 Security Risks

Information systems frequently handle sensitive data such as financial records, personal information,
or medical histories. As a result, system development projects must carefully address security risks to
protect data from unauthorized access or cyber attacks.

Security challenges may include protecting databases from hacking attempts, ensuring secure user
authentication, and preventing unauthorized data modification.

Makerere University - College of Computing and Information Sciences

Chapter 2 Phases of the System Development Life Cycle (SDLC) 55

For example, a banking system must implement strong encryption and authentication mechanisms to
protect customer account information from cyber criminals.

Addressing security risks requires careful system design, continuous monitoring, and regular updates
to protect systems from evolving security threats.

Makerere University - College of Computing and Information Sciences

Chapter 3

System Development Approaches

3.1 Introduction to System Development Approaches

Software systems are developed to solve real-world problems, and their development requires careful
planning and organization. Without a clear method, the development process can become disorga-
nized, leading to errors, delays, and systems that fail to meet user needs.

To address this challenge, developers use structured methods known as system development ap-
proaches. These approaches provide a systematic way of organizing all activities involved in building
a software system, from the initial idea to the final product.

A system development approach defines how work is carried out, how tasks are ordered, and how
progress is controlled throughout the project. It ensures that development is not left to guesswork, but
instead follows a clear and repeatable process.

Different approaches exist because software projects are not all the same. Some projects are simple
and well understood, while others are complex and subject to frequent changes. As a result, no single
approach can be suitable for all situations.

This chapter introduces the main system development approaches and explains how they differ in
structure, flexibility, and application. Understanding these approaches enables developers to choose
appropriate methods for different types of projects.

3.1.1 Meaning of a Development Approach

A system development approach is a structured method used to guide the process of creating a soft-
ware system. It defines how development activities are organized, how tasks are performed, and how
the system evolves from an idea into a working product.

In practical terms, a development approach answers an important question: how should the system
be built in an organized and effective way. Instead of working without direction, developers follow a
defined approach to ensure that each stage of development is properly planned and executed.
Chapter 3 System Development Approaches 57

A development approach typically specifies the sequence of activities such as requirement analysis,
design, implementation, and testing. It also determines how these activities are related to each other,
whether they are performed once or repeated multiple times.

In addition, a development approach defines how progress is monitored and how problems are han-
dled during development. This makes it easier to manage the project and ensure that the final system
meets the intended requirements.

The choice of development approach has a significant impact on the success of a project, as it influ-
ences how efficiently the system is built and how well it satisfies user needs.

3.1.2 Why Different Approaches Exist

There is no single development approach that can be used for all software projects. Different ap-
proaches exist because software systems vary in their characteristics, requirements, and constraints.

One important factor is the size of the project. Small systems can often be developed quickly with
simple methods, while large systems require more structured and carefully managed approaches.

Another factor is the stability of requirements. In some projects, requirements are clearly defined at
the beginning and remain unchanged. In other projects, requirements may evolve over time as users
gain a better understanding of their needs.

The level of uncertainty also plays a role. Projects that involve new technologies or innovative ideas
often require flexible approaches that allow experimentation and gradual improvement.

User involvement is another key consideration. Some systems require continuous interaction with
users to refine requirements, while others can be developed with limited user input after the initial
phase.

Time and resource constraints further influence the choice of approach. Projects with strict deadlines
may require faster and more adaptive methods of development.

Because of these differences, multiple development approaches have been designed, each suited to
specific types of projects. Understanding these approaches allows developers to select the most ap-
propriate method for a given situation.

Makerere University - College of Computing and Information Sciences

Chapter 3 System Development Approaches 58

3.1.3 The Role of Process in Software Development

A process is a set of organized activities that are carried out to achieve a specific goal. In software
development, the goal of the process is to produce a system that functions correctly and meets user
requirements.

The development process provides structure by defining the steps that must be followed during the
creation of a system. This reduces confusion and ensures that important activities are not overlooked.

A well-defined process also improves organization by clearly assigning tasks and responsibilities.
This is especially important in projects involving multiple developers, where coordination is neces-
sary for success.

In addition, the process contributes to system quality by encouraging systematic testing and valida-
tion. Errors can be detected earlier, reducing the cost and effort required to fix them.

The process also allows for better monitoring and control of the project. Progress can be measured,
delays can be identified, and corrective actions can be taken when necessary.

Without a clear process, software development can become unpredictable and difficult to manage. A
system development approach therefore provides a structured process that guides the entire develop-
ment effort from beginning to end.

3.2 Categories of System Development Approaches

System development approaches can be grouped into categories based on how they organize the de-
velopment process. These categories reflect different ways of planning work, handling changes, and
delivering a system to users.

Understanding these categories is important because it helps developers compare different approaches
and select the most suitable one for a given project. Instead of viewing each approach in isolation, it
is useful to see how they relate to broader development strategies.

The main categories of system development approaches are predictive (plan-driven), iterative and in-
cremental, and evolutionary approaches. Each category differs in how it handles requirements, feed-
back, and change during development.

Makerere University - College of Computing and Information Sciences

Chapter 3 System Development Approaches 59

3.2.1 Predictive (Plan-Driven) Approaches

Predictive approaches, also known as plan-driven approaches, are based on the idea that the system
can be fully planned before development begins. In this type of approach, requirements are carefully
analyzed and documented at the start of the project.

Once the requirements are defined, the development process follows a fixed sequence of steps. Each
phase is completed before the next one begins, and there is little or no overlap between phases.

The term “predictive” is used because the outcome of the project is largely predicted in advance. The
cost, schedule, and expected results are determined early and remain relatively stable throughout de-
velopment.

This approach works well when requirements are clear, complete, and unlikely to change. For exam-
ple, systems developed for regulatory or contractual purposes often use predictive approaches because
they require precise documentation and strict control.

However, predictive approaches are less suitable for projects where requirements are uncertain or
likely to evolve, because changes are difficult to accommodate once development has started.

3.2.2 Iterative and Incremental Approaches

Iterative and incremental approaches are based on developing a system gradually rather than all at
once. Instead of completing the entire system in a single sequence, development is divided into smaller
cycles called iterations.

In each iteration, a portion of the system is planned, designed, implemented, and tested. The system
is therefore built step by step, with each cycle adding new functionality or improving existing features.

The term “iterative” refers to the repetition of development activities, while “incremental” refers to
the gradual addition of system features. Together, these concepts allow the system to grow over time.

One of the key advantages of this approach is that it allows feedback to be incorporated during devel-
opment. After each iteration, users can review the system and suggest improvements, which are then
applied in subsequent iterations.

This makes iterative and incremental approaches more flexible than predictive approaches, as they
can adapt to changes in requirements without requiring the entire system to be redesigned.

Makerere University - College of Computing and Information Sciences

Chapter 3 System Development Approaches 60

3.2.3 Evolutionary Approaches

Evolutionary approaches take flexibility a step further by allowing the system to evolve continuously
based on feedback and changing requirements. In this type of approach, development does not follow
a fixed plan, but instead adapts as new information becomes available.

The system is developed in a way that allows frequent modification and refinement. Early versions
of the system may be incomplete or simplified, but they are gradually improved over time.

A key feature of evolutionary approaches is strong user involvement. Users interact with the system
throughout development, providing feedback that directly influences how the system evolves.

This approach is particularly useful when requirements are not well understood at the beginning of
the project. It allows developers to explore possible solutions and refine them based on real user needs.

However, because the process is less structured, it may be more difficult to predict the final cost,
schedule, or outcome of the project.

3.2.4 Key Differences Between Categories

The main differences between these categories can be understood in terms of planning, flexibility, and
response to change.

Predictive approaches emphasize detailed planning and a fixed sequence of steps. They aim to min-
imize uncertainty by defining all requirements in advance, but they offer limited flexibility once de-
velopment begins.

Iterative and incremental approaches reduce this limitation by allowing development to proceed in cy-
cles. They provide a balance between structure and flexibility, enabling changes to be made between
iterations.

Evolutionary approaches place the greatest emphasis on flexibility. They allow continuous adaptation
and rely heavily on user feedback to shape the system as it develops.

In summary, predictive approaches are most suitable for stable and well-defined projects, while iter-
ative and evolutionary approaches are better suited to projects where requirements are uncertain or
subject to change. Understanding these differences is essential for selecting an appropriate develop-
ment approach.

Makerere University - College of Computing and Information Sciences

Chapter 3 System Development Approaches 61

3.3 Waterfall Model

3.3.1 Definition
The Waterfall Model is one of the earliest and most fundamental system development approaches. It
is a predictive or plan-driven model in which development follows a fixed and sequential series of
phases.

In this model, each phase must be completed before the next phase begins, and there is little overlap
between phases. The output produced in one phase serves as the input for the next phase, creating a
clear and ordered flow of activities.

The model is called “waterfall” because the development process progresses in a downward direction,
similar to water flowing over a series of steps. Once the process moves to the next stage, it is generally
not expected to return to the previous one.

The Waterfall Model is based on the assumption that system requirements can be fully understood
and defined before development begins. This makes it suitable for projects where the problem is well
understood and unlikely to change.

3.3.2 Phases of the Waterfall Model

The Waterfall Model is organized into a sequence of distinct phases. Each phase has a specific purpose
and produces outputs that guide the next stage of development.

[Link] Requirements
The requirements phase involves identifying and documenting what the system is expected to do. This
includes understanding user needs, system functionality, and any constraints that must be considered.

The result of this phase is a detailed requirements specification that serves as the foundation for all
subsequent development activities. Because later stages depend on this document, it is important that
the requirements are complete and accurate.

[Link] Design
In the design phase, the system is planned based on the requirements. Developers determine how the
system will be structured and how its components will interact.

Makerere University - College of Computing and Information Sciences

Chapter 3 System Development Approaches 62

This phase may include the design of data structures, user interfaces, and system architecture. The
outcome is a blueprint that guides the implementation of the system.

[Link] Implementation
The implementation phase involves translating the design into actual program code. Developers write
and organize code according to the specifications defined in the design phase.

Each component of the system is developed and prepared for integration. At this stage, the focus is
on building the system rather than evaluating it.

[Link] Testing
In the testing phase, the system is examined to ensure that it works correctly and meets the specified
requirements. This involves identifying defects, correcting errors, and verifying system functionality.

Testing is essential for ensuring the reliability and correctness of the system before it is delivered to
users. However, because testing occurs after implementation, problems introduced earlier may only
be discovered at this stage.

[Link] Deployment
Deployment involves delivering the completed system to users and making it operational in its in-
tended environment. This may include installation, configuration, and user training.

At this stage, the system begins to be used in real-world conditions, and its performance can be ob-
served in practice.

[Link] Maintenance
Maintenance is the phase in which the system is updated and improved after deployment. This in-
cludes fixing errors, adapting the system to new requirements, and enhancing its performance.

Although maintenance occurs after delivery, it is an important part of the system’s life cycle, as most
systems require ongoing updates over time.

Makerere University - College of Computing and Information Sciences

Chapter 3 System Development Approaches 63

3.3.3 Characteristics
The Waterfall Model is characterized by its linear and sequential structure, where each phase is clearly
separated and completed before the next begins. This makes the development process easy to under-
stand and manage.

It places strong emphasis on planning and documentation, ensuring that each stage is well defined
before development proceeds.

Another key characteristic is its limited flexibility. Once development has moved beyond a phase,
returning to make changes is difficult and often costly.

3.3.4 Advantages
One of the main advantages of the Waterfall Model is its simplicity. The clear sequence of phases
makes it easy to understand, especially for beginners who are learning how software development is
organized.

The structured nature of the model also supports effective planning and management. Since each
phase has defined objectives and outputs, it is easier to estimate time, allocate resources, and monitor
progress.

Another advantage is the strong emphasis on documentation. Each stage produces detailed documents,
such as requirement specifications and design descriptions, which provide a clear record of the system
and support future maintenance.

The model is also suitable for projects with stable requirements, where the problem is well understood
and unlikely to change during development. In such cases, the sequential process reduces uncertainty
and supports a predictable outcome.

3.3.5 Disadvantages
A major disadvantage of the Waterfall Model is its lack of flexibility. Once a phase has been com-
pleted, it is difficult to return and make changes without affecting the entire development process.

The model assumes that all requirements can be identified in advance. In practice, this is often not
possible, as users may not fully understand their needs until they see the system in operation.

Makerere University - College of Computing and Information Sciences

Chapter 3 System Development Approaches 64

Another limitation is that testing occurs relatively late in the process. Errors introduced in earlier
phases may not be detected until the testing stage, making them more expensive and time-consuming
to correct.

In addition, user involvement is limited after the requirements phase. This increases the risk that the
final system may not fully meet user expectations, even if it follows the original specifications.

3.3.6 Suitable Applications

The Waterfall Model is most suitable for projects where requirements are clearly defined and unlikely
to change during development.

It is commonly used in environments that require detailed documentation and strict control, such as
government systems, financial systems, and large organizational projects.

It is less suitable for projects that involve uncertainty, rapid change, or a high need for user feedback,
where more flexible approaches may be more effective.

3.4 Iterative and Incremental Development

Iterative and incremental development is an approach in which a system is built gradually through
repeated cycles, rather than being developed in a single sequence of stages. This approach was intro-
duced to address the limitations of predictive models such as the Waterfall Model, particularly their
lack of flexibility.

Instead of attempting to complete the entire system at once, development is divided into smaller parts.
Each part is developed, tested, and reviewed before moving on to the next. This allows the system to
grow step by step, making it easier to manage complexity and respond to change.

This approach combines two important ideas: iteration, which involves repeating development activi-
ties, and increment, which involves adding new functionality to the system over time. Together, these
ideas provide a more flexible and adaptive way of building software systems.

3.4.1 Concept of Iteration

An iteration is a complete cycle of development activities, including planning, design, implementation,
and testing. Unlike the Waterfall Model, where each activity is performed once, iterative development
repeats these activities multiple times throughout the project.

Makerere University - College of Computing and Information Sciences

Chapter 3 System Development Approaches 65

In each iteration, a small portion of the system is developed and evaluated. The results of this eval-
uation are used to improve the system in the next iteration. This process continues until the system
meets the required objectives.

Iteration allows developers to refine the system progressively. Instead of expecting a perfect design
from the beginning, the system is improved through continuous learning and feedback.

This reduces the risk of major errors, as problems can be identified and corrected early in the devel-
opment process rather than at the end.

3.4.2 Incremental Delivery

Incremental delivery refers to the practice of building and delivering the system in small functional
units called increments. Each increment adds new features or enhances existing functionality.

The first increment typically provides basic functionality, allowing users to interact with a simple
version of the system. Subsequent increments extend this functionality, gradually building a more
complete system.

This approach allows users to start using the system earlier, even before all features are fully devel-
oped. As a result, the system begins to provide value at an earlier stage of the project.

Incremental delivery also makes development more manageable, as each increment focuses on a lim-
ited set of features rather than the entire system.

3.4.3 Benefits of Early Feedback

One of the most important advantages of iterative and incremental development is the ability to obtain
feedback early and continuously. After each iteration or increment, users and stakeholders can review
the system and provide comments on its functionality and usability.

This feedback allows developers to identify misunderstandings, missing requirements, or design prob-
lems at an early stage. As a result, corrections can be made before they become costly or difficult to
implement.

Early feedback also ensures that the system evolves in a way that better reflects user needs. Instead
of relying entirely on initial requirements, the system is shaped by ongoing interaction with users.

Makerere University - College of Computing and Information Sciences

Chapter 3 System Development Approaches 66

This leads to systems that are more aligned with real-world usage and expectations.

3.4.4 Comparison with Waterfall

Iterative and incremental development differs from the Waterfall Model in several fundamental ways.

In the Waterfall Model, development follows a fixed sequence of stages, and each stage is completed
once. In contrast, iterative development repeats these stages multiple times, allowing continuous re-
finement of the system.

In the Waterfall Model, the complete system is delivered at the end of the project. In incremental de-
velopment, parts of the system are delivered progressively, allowing users to benefit from the system
earlier.

The Waterfall Model assumes that requirements are fully known at the beginning, while iterative ap-
proaches accept that requirements may evolve over time and allow changes to be incorporated during
development.

As a result, iterative and incremental development is more flexible and better suited to projects where
uncertainty and change are present, while the Waterfall Model is more appropriate for stable and well-
defined projects.

3.5 Spiral Model

3.5.1 Definition
The Spiral Model is a system development approach that combines iterative development with a strong
emphasis on risk management. It organizes development into a series of cycles, where each cycle rep-
resents a stage in the system’s development.

Unlike simpler models, the Spiral Model does not follow a strictly linear sequence. Instead, it pro-
gresses in a spiral pattern, where each loop builds upon the results of the previous one.

The key idea behind this model is that development should not only focus on building the system, but
also on identifying and managing risks that may affect the success of the project.

Makerere University - College of Computing and Information Sciences

Chapter 3 System Development Approaches 67

3.5.2 Concept of Risk in Development

In software development, a risk is any factor that may cause the project to fail or produce unsatis-
factory results. Risks can arise from unclear requirements, technical challenges, limited resources, or
changes in user needs.

If risks are not identified and addressed early, they can lead to serious problems later in the project,
such as delays, increased costs, or system failure.

The Spiral Model addresses this issue by making risk analysis a central part of the development pro-
cess. At each stage, potential risks are identified, evaluated, and reduced before further development
continues.

This approach helps ensure that major problems are handled early, when they are easier and less costly
to resolve.

3.5.3 Phases of the Spiral Model

Each cycle of the Spiral Model consists of four main phases. These phases are repeated as the system
evolves.

[Link] Planning
In the planning phase, the objectives of the current cycle are defined. This includes identifying the
features to be developed and determining the approach to be used.

A plan is created that outlines the tasks, resources, and schedule for the current stage of development.

[Link] Risk Analysis

In this phase, potential risks associated with the planned activities are identified and evaluated.

Developers analyze possible problems and develop strategies to reduce or eliminate these risks before
proceeding further.

This phase is what distinguishes the Spiral Model from other development approaches, as it places
strong emphasis on risk management.

Makerere University - College of Computing and Information Sciences

Chapter 3 System Development Approaches 68

[Link] Engineering
The engineering phase involves the actual development of the system. This includes designing, im-
plementing, and testing the features defined in the planning phase.

A working version of the system is produced during this phase, which can be evaluated by users and
stakeholders.

[Link] Evaluation
In the evaluation phase, the system is reviewed by users and stakeholders to assess its performance
and suitability.

Feedback is collected and used to guide the next cycle of development. This ensures that the system
continues to improve over time.

3.5.4 Advantages
One of the main advantages of the Spiral Model is its strong focus on risk management. By identifying
and addressing risks early, the model reduces the likelihood of major problems later in the project.

Another advantage is its flexibility. Since development occurs in cycles, changes can be introduced
at each stage without disrupting the entire project.

The model also supports continuous improvement, as each cycle builds on the results of the previous
one. This allows the system to evolve in a controlled and systematic manner.

In addition, user feedback is incorporated at each stage, helping to ensure that the system meets user
needs.

3.5.5 Disadvantages
One limitation of the Spiral Model is its complexity. The process involves multiple cycles and re-
quires careful planning and risk analysis, which can make it difficult to manage, especially for smaller
projects.

Another disadvantage is the higher cost associated with repeated cycles and detailed risk evaluation.
This makes the model less suitable for projects with limited resources.

Makerere University - College of Computing and Information Sciences

Chapter 3 System Development Approaches 69

The model also depends heavily on the ability to identify and assess risks accurately. If risks are not
properly understood, the effectiveness of the approach is reduced.

In addition, the model may be difficult for beginners to apply, as it requires a deeper understanding of
both development processes and risk management.

3.5.6 Suitable Applications

The Spiral Model is most suitable for large and complex projects where risks are significant and must
be carefully managed.

It is particularly useful in systems that involve new technologies, high levels of uncertainty, or critical
requirements.

It is also appropriate for projects that require continuous evaluation and refinement, where user feed-
back plays an important role in shaping the system.

However, it is generally not recommended for small or simple projects, where simpler approaches
may be more efficient.

3.6 Comparison of Development Approaches

3.6.1 Comparison Table

Different system development approaches can be compared based on how they handle key aspects of
the development process. These aspects include flexibility, cost, risk management, and user involve-
ment.

Table 3.1 provides a summary comparison of the main approaches discussed in this chapter. The table
highlights general tendencies rather than exact values, as actual results may vary depending on the
project.

The table provides a simplified overview, but a deeper understanding requires examining each factor
in more detail.

Makerere University - College of Computing and Information Sciences

Chapter 3 System Development Approaches 70

Approach Flexibility Cost Predictability Risk Handling User Involvement

Waterfall Low High Low Low
Iterative/Incremental Medium Medium Medium Medium
Agile High Low Medium High
Prototyping High Medium Medium High
Spiral Medium Low High High
Table 3.1: Comparison of System Development Approaches

3.6.2 Flexibility
Flexibility refers to the ability of a development approach to accommodate changes in requirements
during the development process.

The Waterfall Model has low flexibility because it relies on fixed requirements defined at the begin-
ning. Once development progresses, making changes becomes difficult and costly.

Iterative and incremental approaches offer moderate flexibility, as changes can be introduced between
iterations without affecting the entire system.

Agile and prototyping approaches provide high flexibility. They are designed to adapt continuously,
allowing requirements to evolve as the system is developed.

The Spiral Model also allows flexibility, but within a controlled structure that emphasizes risk man-
agement rather than rapid change.

3.6.3 Cost
Cost refers not only to the total resources required, but also to how predictable those costs are during
the project.

The Waterfall Model generally allows for more predictable cost estimation because the entire project
is planned in advance. However, unexpected changes can significantly increase costs.

Iterative and incremental approaches provide moderate cost predictability, as development is divided
into manageable parts.

Agile and prototyping approaches often have less predictable costs, since requirements can change
and additional work may be introduced during development.

The Spiral Model may involve higher overall costs due to repeated cycles and detailed risk analysis,
but these costs are often justified in high-risk projects.

Makerere University - College of Computing and Information Sciences

Chapter 3 System Development Approaches 71

3.6.4 Risk
Risk refers to the possibility of failure, errors, or unexpected problems during development. Different
approaches manage risk in different ways.

The Waterfall Model has limited risk management, as problems may not be discovered until later
stages such as testing.

Iterative and incremental approaches reduce risk by allowing early testing and continuous improve-
ment. Problems can be identified and corrected in each cycle.

Agile and prototyping approaches also reduce risk by incorporating frequent feedback and early sys-
tem evaluation.

The Spiral Model provides the strongest support for risk management. It explicitly identifies and ad-
dresses risks at every stage of development, making it suitable for complex and high-risk projects.

3.6.5 User Involvement

User involvement refers to the extent to which users participate in the development process.

In the Waterfall Model, user involvement is typically limited to the early requirements phase, with
little interaction during later stages.

Iterative approaches involve users at regular intervals, particularly during reviews of each iteration.

Agile and prototyping approaches require high levels of user involvement. Users provide continuous
feedback, which directly influences system development.

The Spiral Model also involves users in evaluation phases, ensuring that feedback is incorporated into
each cycle.

In summary, no single development approach is best for all situations. Each approach has strengths
and limitations, and the choice depends on the specific needs and conditions of the project.

Makerere University - College of Computing and Information Sciences

Chapter 3 System Development Approaches 72

3.7 Choosing a Suitable Development Approach

Selecting an appropriate system development approach is an important decision that can significantly
influence the success of a software project. Different approaches are suited to different types of prob-
lems, and choosing the wrong approach can lead to delays, increased costs, or failure to meet user
needs.

There is no single approach that is best for all situations. Instead, the choice depends on several factors
related to the nature of the project, the development environment, and the needs of stakeholders.

Understanding these factors helps developers select an approach that provides the right balance be-
tween structure, flexibility, and efficiency.

3.7.1 Nature of Requirements

One of the most important factors in selecting a development approach is the stability of system re-
quirements.

If requirements are clearly defined and unlikely to change, a predictive approach such as the Waterfall
Model may be suitable. This is because the system can be planned in detail before development begins.

However, if requirements are unclear or expected to change over time, more flexible approaches such
as Agile or prototyping are more appropriate. These approaches allow requirements to evolve as the
system is developed.

3.7.2 Project Size and Complexity

The size and complexity of the project also influence the choice of development approach.

Large and complex systems often require structured approaches that provide clear organization and
control. In some cases, approaches such as the Spiral Model may be used to manage complexity and
risk.

Smaller or less complex projects may benefit from simpler and more flexible approaches, where rapid
development and adaptation are more important than strict structure.

Makerere University - College of Computing and Information Sciences

Chapter 3 System Development Approaches 73

3.7.3 Time and Budget Constraints

Time and budget limitations are important considerations in selecting a development approach.

Projects with strict deadlines may require approaches that support rapid development and early deliv-
ery of functionality, such as Agile or iterative methods.

In contrast, projects with fixed budgets and well-defined scope may benefit from predictive approaches,
where costs and schedules can be estimated more accurately.

3.7.4 User Involvement

The level of user involvement required in the project is another key factor.

If users are available to provide continuous feedback, approaches such as Agile and prototyping can
be very effective, as they rely on regular interaction with users.

If user involvement is limited, a more structured approach such as the Waterfall Model may be more
appropriate, as it requires less ongoing interaction after the requirements phase.

3.7.5 Team Experience

The experience and skills of the development team also affect the choice of approach.

Teams with strong experience and good communication skills are better able to manage flexible ap-
proaches such as Agile, which require continuous coordination and adaptation.

Less experienced teams may benefit from more structured approaches that provide clear guidance and
well-defined stages, reducing uncertainty during development.

In practice, the choice of development approach often involves balancing these factors. A careful
analysis of project conditions helps ensure that the selected approach supports both the development
process and the final system outcome.

3.8 Common Challenges in Development Approaches

Although system development approaches provide structure and guidance, they are not always applied
perfectly in practice. Various challenges can arise during development, often due to misunderstand-

Makerere University - College of Computing and Information Sciences

Chapter 3 System Development Approaches 74

ings, poor planning, or inappropriate use of an approach.

Understanding these challenges helps developers avoid common mistakes and apply development ap-
proaches more effectively.

3.8.1 Changing Requirements

One of the most common challenges in software development is dealing with changing requirements.

In many projects, users may not fully understand their needs at the beginning. As development pro-
gresses, new requirements may emerge, or existing requirements may need to be modified.

Approaches such as the Waterfall Model are not well suited to handling such changes, as they rely on
fixed requirements defined at the start.

If changes are not properly managed, they can lead to delays, increased costs, and inconsistencies in
the system.

Flexible approaches such as Agile and prototyping are better able to handle changing requirements,
but they still require careful control to prevent uncontrolled growth of the system.

3.8.2 Poor User Involvement

Another major challenge is insufficient user involvement during development.

When users are not actively engaged, developers may rely on assumptions about user needs, which
can result in systems that do not meet expectations.

Even in approaches that encourage user participation, such as Agile and prototyping, lack of consistent
feedback can reduce the effectiveness of the process.

Ensuring regular communication between developers and users is essential for producing systems that
are useful and relevant.

3.8.3 Inappropriate Approach Selection

Selecting an unsuitable development approach is a common source of project problems.

Makerere University - College of Computing and Information Sciences

Chapter 3 System Development Approaches 75

For example, using a rigid approach such as the Waterfall Model in a project with uncertain require-
ments can lead to frequent changes and rework.

Similarly, using a highly flexible approach such as Agile in a project that requires strict documentation
and control may create confusion and lack of structure.

Choosing the right approach requires careful consideration of project characteristics such as require-
ments, size, risk, and user involvement.

3.8.4 Lack of Planning

Even in flexible development approaches, proper planning is essential.

A common misconception is that approaches such as Agile do not require planning. In reality, plan-
ning still plays an important role, although it is done in smaller and more frequent cycles.

Without adequate planning, development activities may become disorganized, leading to inefficiency
and poor-quality systems.

Effective planning ensures that resources are used efficiently and that development progresses in a
controlled manner.

In summary, system development approaches are powerful tools, but their effectiveness depends on
how they are applied. By understanding and addressing these challenges, developers can improve the
success of software projects.

3.9 Summary

3.10 Review Questions

Makerere University - College of Computing and Information Sciences