Software Development Process Models — Overview
Software development process models describe how software is planned, designed, coded,
tested, and delivered.
Each model defines the order of activities, work products, and quality control methods.
Different models are suitable for different kinds of projects.
🧱 2.3.1 Waterfall Model
🔹 Concept
The earliest and simplest process model (proposed by Royce).
Activities are arranged in a linear, sequential order.
Each phase must be completed before the next begins.
🔹 Phases
1. Feasibility Study – Check if the project is possible and practical.
2. Requirements Analysis & Project Planning – Define what the system must do and plan
resources.
3. System Design – Create architecture and detailed design.
4. Coding – Implement the design.
5. Testing & Integration – Verify that the system works as intended.
6. Installation & Maintenance – Deliver and maintain the system.
🔹 Outputs (Work Products)
Requirements document
Project plan
Design documents (architecture, detailed design)
Test plan and test reports
Final code
Software manuals
🔹 Advantages
Simple, structured, and easy to manage.
Suitable for contractual and well-understood projects.
Clear documentation and review after each phase.
🔹 Limitations
1. Rigid requirement freezing – assumes requirements never change.
2. Early hardware selection – may become outdated.
3. “Big Bang” delivery – user sees final system only at the end.
4. Document-driven – heavy focus on paperwork.
✅ Best for: Projects with well-defined, stable requirements (e.g., routine business systems).
🧩 2.3.2 Prototyping Model
🔹 Concept
Used to understand unclear requirements through experimentation.
A throwaway prototype (quick mock system) is built to gather feedback.
Final system is developed after requirements are stabilized.
🔹 Steps
1. Build an initial prototype from known requirements.
2. User interacts with it and provides feedback.
3. Modify prototype → gather feedback again.
4. Once requirements are clear → build the final system.
🔹 Advantages
Clarifies ambiguous or changing requirements.
Reduces project risk and rework.
Gives early visibility to users.
🔹 Limitations
Can increase development cost if not controlled.
Prototype may be mistaken for the final product.
Not suitable when requirements are already clear.
✅ Best for: Projects where requirements are unclear or evolving.
🔁 2.3.3 Iterative Development Model
🔹 Concept
Combines the strengths of Waterfall and Prototyping.
Software is developed in increments (iterations), each delivering part of the system.
Each iteration adds functionality and refines the design.
🔹 Steps
1. Develop a small initial version.
2. Test and evaluate.
3. Add more features in successive iterations.
4. Continue until the full system is complete.
🔹 Types
1. Iterative Enhancement Model – Adds features step by step using a project control list.
2. Spiral Model (Boehm) – Each iteration is a cycle including:
o Define objectives, alternatives, and constraints
o Analyze and resolve risks
o Develop and test the next-level product
o Plan the next iteration
🔹 Advantages
Early delivery of working software.
Easier testing (each part is small).
Incorporates user feedback continuously.
Handles changing requirements well.
🔹 Limitations
Requires good planning and risk management.
May be hard to manage many iterations.
✅ Best for: Large or evolving projects, Agile, RUP, XP—all use iterative approaches.
2.3.4 Timeboxing Model
🔹 Concept
Focuses on fixed-time iterations (called time boxes) instead of fixed functionality.
Each time box delivers a usable product version within a strict deadline.
Parallel (pipelined) execution of stages speeds up delivery.
🔹 Structure
Each time box has stages (e.g., Requirements → Build → Deployment),
and each stage has a dedicated team working in parallel.
🔹 Example
Time box = 9 weeks, 3 stages (3 weeks each):
o 1st delivery → 9 weeks
o Then every 3 weeks → new delivery
o (due to parallel teams working like a production pipeline)
🔹 Advantages
Fast, regular deliveries of working software.
Useful when many features must be delivered quickly.
Efficient use of manpower through parallelism.
🔹 Limitations
Needs more total manpower.
Requires stable architecture and well-partitioned features.
Not suitable for projects with unequal or unpredictable stages.
✅ Best for: Large projects with many features and tight deadlines.
2.3.5 Comparison of Models
Model Key Idea Strengths Weaknesses Suitable For
Simple, well-
Linear, sequential Rigid, poor for Stable, well-defined
Waterfall structured, easy to
phases changing needs projects
manage
Build temporary Clarifies unclear Extra cost, may be New or unclear
Prototyping
prototype requirements misused requirements
Early feedback, Complex to Large, evolving
Iterative Incremental builds
flexible manage systems
Fixed-time
Fast delivery, Needs large team, Feature-rich systems
Timeboxing iterations,
predictable schedule stable tech with deadlines
pipelined
Function oriented design:
Object-Oriented Design (OOD) in Software Engineering
🔹 Definition
In object-oriented design, a system is viewed as a collection of interacting objects.
Each object represents a real-world entity and contains:
Data (attributes or properties)
Functions (methods or operations)
An object manages its own data and operations, promoting data encapsulation and modularity.
🔹 Key Characteristics of OOD
1. Encapsulation (Data Hiding)
o Each object contains its own data.
o Other objects cannot access this data directly; they can interact only through
methods (functions).
o Example: In a Library Management System, each Member object manages its own
details and book list.
2. No Global Data
o Unlike function-oriented systems, OOD avoids centralized data.
oThe system state is distributed among objects.
3. Abstraction and Decomposition
o The system is broken down into independent objects that model real-world
entities.
o Each object hides the internal details of how it stores and manipulates its data.
🧠 Core Concepts Behind OOD
1. Abstract Data Type (ADT)
An ADT is a user-defined data type that specifies:
What operations can be performed,
But not how they are implemented.
In OOD, classes represent ADTs.
2. Three Concepts Associated with ADT
Concept Meaning Example
Data Hiding details of data storage and Stack data stored using array or linked list
Abstraction showing only what’s necessary. — user only uses push() and pop()
Data Organized collection of primitive
Arrays, linked lists, trees
Structure data items.
Defines the kind of values a variable int, float, char (basic types) or user-defined
Data Type
can hold. (class Stack)
🧱 Advantages of Using ADTs (and OOD)
1. Encapsulation / Data Hiding
o Data can be changed only via object methods.
o Easier to trace and fix errors.
2. High Cohesion and Low Coupling
o Each object performs a single well-defined role (high cohesion).
o Objects interact through messages, not shared data (low coupling).
3. Abstraction Simplifies Understanding
o Hides complex internal logic and reduces system complexity.
Classes and Objects
A class is a blueprint defining attributes and methods.
An object is an instance of a class.
Objects may inherit properties and methods from parent (super) classes.
Objects communicate through message passing (one object sending a request to
another).
Objects can have different states (depending on their data values) and can behave differently in
each state.