SOFTWARE PROCESS MODELS
Study Notes — Definitions, Diagrams, Examples & Comparisons
Software Engineering — Unit Reference Material
1. Introduction to Software Process Models
1.1 What is a Software Process?
A software process is a structured, organized set of activities that are performed in a defined sequence to develop, deliver, and maintain software. It
describes WHO does WHAT, WHEN, and HOW, converting user needs into a working software product.
1.2 What is a Software Process Model?
A software process model (also called a Software Development Life Cycle or SDLC model) is an abstract representation of a software process. It provides a
standardized, repeatable framework of phases — such as requirement gathering, design, coding, testing, deployment, and maintenance — that guides a
development team from an initial idea to a delivered, maintained product.
1.3 Why Process Models Are Needed
• Provide a common framework so teams follow a disciplined, repeatable approach.
• Help in planning, scheduling, and estimating cost, effort, and resources.
• Improve quality by building in verification and validation at each stage.
• Reduce risk by identifying problems early rather than late in development.
• Aid communication among stakeholders (developers, clients, managers, testers).
1.4 Broad Classification
Process models are broadly classified as Prescriptive (Plan-driven) models — where phases are defined in advance and followed in a structured order (e.g.,
Waterfall, Incremental, RAD, Prototyping, Spiral, V-Model) — and Agile (Adaptive) models — which emphasize iterative delivery, flexibility, and
continuous customer collaboration (e.g., Scrum, XP, Kanban).
2. Waterfall Model
The Waterfall Model is the earliest and simplest software process model, in which development flows sequentially downward — like a waterfall — through
distinct phases. Each phase must be completed and signed off before the next phase begins, and there is little to no overlap between phases.
Source / Reference
Royce, W. W. (1970); as presented in Pressman, R.S., Software Engineering: A Practitioner's Approach; Sommerville, I., Software Engineering.
Phases / Working
• Requirement Analysis — gather and document all requirements
• System Design — define architecture, data structures, interfaces
• Implementation (Coding) — translate design into program code
• Testing — verify and validate the built system against requirements
• Deployment — release the system to the customer/production
• Maintenance — fix defects and handle change requests post-release
Diagram
+------------------+
| Requirements |
+--------+---------+
|
v
+------------------+
| Design |
+--------+---------+
|
v
+------------------+
| Implementation |
+--------+---------+
|
v
+------------------+
| Testing |
+--------+---------+
|
v
+------------------+
| Deployment |
+--------+---------+
|
v
+------------------+
| Maintenance |
+------------------+
Advantages
• Simple to understand, explain, and manage.
• Well-suited for projects with clear, stable, and well-understood requirements.
• Each phase has clear deliverables and a review process, easing tracking.
• Documentation-heavy approach helps in projects requiring formal audit trails.
Disadvantages
• No working software is produced until late in the life cycle.
• High risk and uncertainty — hard to accommodate changing requirements.
• Not suitable for complex, long-running, or object-oriented projects.
• Problems are often discovered only during the testing phase, when they are costly to fix.
When to Use
Use when requirements are well understood, fixed, and unlikely to change; for short, small-to-medium projects; and where the technology is well known to
the team.
Example Scenario
Developing a simple payroll processing system for a small organization where the rules (tax slabs, salary structure) are fixed and documented in advance.
3. Incremental Model
The Incremental Model divides the product into smaller builds (increments). Each increment is designed, coded, and tested through mini Waterfall-like
cycles, and delivers an additional working piece of functionality that is added to previously delivered increments.
Source / Reference
Pressman, R.S., Software Engineering: A Practitioner's Approach, Ch. on Process Models.
Phases / Working
• Divide requirements into groups (increments/builds)
• Design and develop the first increment (core functionality)
• Deliver, review, and get customer feedback
• Design and add the next increment on top of prior ones
• Repeat until the full system is built
Diagram
Increment 1: [Req]->[Design]->[Code]->[Test]->[Deliver-1]
Increment 2: [Req]->[Design]->[Code]->[Test]->[Deliver-2]
Increment 3: [Req]->[Design]->[Code]->[Test]->[Deliver-3]
|
v
Final Integrated System
Advantages
• Working software is delivered early and continually.
• Easier to test and debug smaller increments than an entire system.
• Customer sees progress and can give feedback throughout.
• Lower initial cost, and risk is spread across increments.
Disadvantages
• Requires good upfront planning and design to define increments cleanly.
• Total system cost may be higher than Waterfall due to repeated cycles.
• Overlap between increments can create integration issues if not managed well.
When to Use
Use when core requirements are clear but detailed requirements can evolve; when the customer wants early releases of key features; for medium-to-large
systems that can be logically divided.
Example Scenario
Building an e-commerce site: Increment 1 = product catalog & browsing, Increment 2 = shopping cart & checkout, Increment 3 = payment gateway & order
tracking.
4. Rapid Application Development (RAD) Model
RAD is a high-speed adaptation of the Waterfall Model that emphasizes very short development cycles using component-based construction, heavy reuse of
existing components, and extensive use of CASE tools/prototyping so that a fully functional system can be delivered in a very short time (typically 60–90
days).
Source / Reference
James Martin (1991); Pressman, R.S., Software Engineering: A Practitioner's Approach.
Phases / Working
• Business Modelling — identify the information flow among business functions
• Data Modelling — refine business information into data objects
• Process Modelling — define processing/transformation for data objects
• Application Generation — build the system using automated tools/reusable components
• Testing & Turnover — test new components and interfaces (reused parts are already tested)
Diagram
Business Data Process Application Testing &
Modelling -> Modelling -> Modelling -> Generation -> Turnover
Team A Team B Team C (parallel component teams)
(Each functional module is built by a separate team in parallel
and then integrated to form the complete system)
Advantages
• Very fast development due to reuse and parallel team-based construction.
• Reduced development time means faster time-to-market.
• Customer involvement continues throughout via prototypes.
Disadvantages
• Requires a modular system that can be decomposed into components.
• Needs highly skilled developers and heavy tool/technical resource investment.
• Not suitable when requirements cannot be modularized or risk is high.
• Poor fit for systems that cannot be adequately tested by module reuse.
When to Use
Use for systems that can be decomposed into independent modules, with skilled teams, well-defined business processes, and a need for very fast delivery.
Example Scenario
Building an internal HR self-service portal by reusing existing authentication, leave-management, and reporting components across parallel teams.
5. Prototyping Model
The Prototyping Model builds a working (but incomplete) version of the software — a prototype — early in development to help clarify unclear or evolving
requirements. The prototype is demonstrated to the customer, refined based on feedback, and either evolved into the final system (evolutionary) or discarded
once requirements are clear (throw-away).
Source / Reference
Sommerville, I., Software Engineering, Ch. on Software Process Models.
Phases / Working
• Requirements gathering (initial, often incomplete)
• Quick design focused on visible aspects (UI, key features)
• Build prototype
• Customer evaluation of prototype
• Refine prototype based on feedback (repeat as needed)
• Engineer the final product (from refined prototype or from scratch)
Diagram
+-------------------+
| Requirements |
| Gathering |
+----------+----------+
v
+-------------------+
| Quick Design |<------------+
+----------+----------+ |
v |
+-------------------+ |
| Build Prototype | |
+----------+----------+ |
v |
+-------------------+ |
| Customer Evaluates |------(refine)----+
+----------+----------+
v
+-------------------+
| Engineer Product |
+-------------------+
Advantages
• Helps clarify vague or incomplete requirements early.
• Active customer/user involvement improves the final product's usability.
• Reduces risk of building the wrong product.
• Missing features or misunderstandings can be found early.
Disadvantages
• Customer may mistake the prototype for the final system, expecting fast delivery.
• Can lead to poor design/shortcuts if the prototype is reused carelessly for the final build.
• Additional cost and time if the prototype is a throw-away.
When to Use
Use when requirements are unclear, the user interface is critical, or the customer is unsure of exactly what they want.
Example Scenario
Designing a new mobile banking app UI where the client wants to see and interact with several screen-flow options before finalizing requirements.
6. Spiral Model
The Spiral Model combines iterative development (like Prototyping) with the systematic, controlled aspects of the Waterfall Model, adding an explicit risk-
analysis phase. The software is developed through repeated cycles (spirals), each consisting of planning, risk analysis, engineering, and evaluation, with the
scope and detail of the product growing with each pass.
Source / Reference
Boehm, B. (1988), 'A Spiral Model of Software Development and Enhancement'; Pressman, R.S., Software Engineering.
Phases / Working
• Planning — determine objectives, alternatives, and constraints for the iteration
• Risk Analysis — identify and resolve risks; often build prototypes here
• Engineering — develop and test the next level of the product
• Evaluation — customer reviews the output and plans the next spiral
Diagram
Planning
/ \
Evaluation Risk Analysis
\ /
Engineering
(Each pass around the spiral moves outward, representing an
increasingly complete version of the software; radius = cost,
angle = progress through the four quadrants above)
Advantages
• Strong emphasis on risk analysis, reducing project risk for large systems.
• Suitable for large, complex, and mission-critical projects.
• Combines benefits of both iterative development and structured Waterfall control.
• Software is produced in early stages of the life cycle.
Disadvantages
• Complex to manage; requires risk-assessment expertise.
• Can be costly — not ideal for small projects.
• Excessive documentation and long development time possible if risks are numerous.
• Project success heavily depends on the risk-analysis phase being done well.
When to Use
Use for large, expensive, and complex projects with significant and changing risks, such as defense, aerospace, or large-scale enterprise systems.
Example Scenario
Developing a national-level e-governance platform where requirements evolve, budgets are large, and risks (security, scalability, legal compliance) must be
managed across multiple releases.
7. Agile Model
Agile is an iterative and incremental approach where software is developed in small, time-boxed cycles called sprints/iterations (typically 1–4 weeks). It
emphasizes individuals and interactions, working software, customer collaboration, and responding to change over rigid processes and documentation.
Popular Agile frameworks include Scrum, Extreme Programming (XP), and Kanban.
Source / Reference
Beck, K. et al., Manifesto for Agile Software Development (2001); Pressman, R.S., Software Engineering.
Phases / Working
• Product backlog creation — list of desired features/requirements
• Sprint planning — select backlog items for the current sprint
• Design, code, and test within the sprint (daily stand-up meetings track progress)
• Sprint review — demonstrate working increment to stakeholders
• Sprint retrospective — reflect and improve the process
• Repeat for subsequent sprints until product is complete
Diagram
Product Backlog
|
v
+---------------------------------------------+
| Sprint (1-4 weeks) |
| Plan -> Design -> Code -> Test -> Review | --> Working Increment
+---------------------------------------------+ delivered to customer
|
v (repeat sprint cycle)
Next Sprint ...
Advantages
• Delivers working software frequently and adapts quickly to change.
• Continuous customer/stakeholder collaboration improves product fit.
• Encourages team communication via daily stand-ups and retrospectives.
• Reduces risk by validating assumptions every sprint.
Disadvantages
• Less predictable overall project cost/timeline compared to plan-driven models.
• Requires highly disciplined, self-organizing, and experienced teams.
• Documentation may be minimal, which can hurt long-term maintenance.
• Difficult to scale for very large, distributed teams without extra frameworks (e.g., SAFe).
When to Use
Use when requirements are expected to evolve, fast and frequent delivery is valued, and the customer can stay actively engaged throughout development.
Example Scenario
Developing a social-media mobile app feature-by-feature, releasing a new set of features every two-week sprint based on live user feedback.
8. V-Model (Verification and Validation Model)
The V-Model is an extension of the Waterfall Model in which each development phase is directly associated with a corresponding testing phase, forming a
V-shape. Verification activities (left arm, going down) are matched to validation activities (right arm, going up), so test planning happens in parallel with
development, not after it.
Source / Reference
Sommerville, I., Software Engineering; Pressman, R.S., Software Engineering.
Phases / Working
• Requirement Analysis <--> Acceptance Testing
• System Design <--> System Testing
• Architectural Design <--> Integration Testing
• Module Design <--> Unit Testing
• Coding — at the bottom of the V, connecting both arms
Diagram
Requirements \ / Acceptance
Analysis \ / Testing
\ /
System \ / System
Design \ / Testing
\ /
Architectural \ / Integration
Design \ / Testing
\ /
Module \ / Unit
Design \/ Testing
Coding
Advantages
• Simple, disciplined, and easy to manage — each phase has clear entry/exit criteria.
• Testing is planned early (in parallel with the corresponding design phase), improving defect detection.
• Higher chance of success for well-understood, fixed-requirement projects than plain Waterfall.
Disadvantages
• Highly rigid — like Waterfall, difficult to accommodate changing requirements.
• No working software until late in the cycle.
• High risk if requirements are misunderstood, since correction is costly late in the V.
When to Use
Use for projects where reliability is critical and requirements are clear and fixed, such as medical device software or safety-critical embedded systems.
Example Scenario
Developing firmware for a medical infusion pump, where every requirement must be traceable to a specific test case for regulatory certification.
9. Comparison of Software Process Models
Flexibility to Customer
Model Risk Handling Cost Best Suited For
Change Involvement
Only at start & Low (if no
Waterfall Very Low Poor (late detection) Small, well-defined projects
end rework)
After each Medium projects, phased
Incremental Moderate Moderate Moderate
increment delivery
Continuous Moderate–
RAD Moderate Moderate Modular systems, fast delivery
(prototypes) High (tools)
Good (early Can increase
Prototyping High (early stage) Very high Unclear/evolving requirements
clarification) (rework)
Excellent (explicit Large, complex, high-risk
Spiral High At every spiral High
risk analysis) projects
Continuous Good (frequent Evolving requirements, fast
Agile Very High Variable
(every sprint) validation) delivery
Only at start & Good (test-early Safety-critical, fixed-
V-Model Very Low Low–Moderate
end planning) requirement systems
10. Model Selection Guide
Choosing a process model depends primarily on how well-defined the requirements are, project size and complexity, risk level, and the degree of customer
involvement available.
Are requirements clear and fixed?
|
YES -----> Is reliability/safety critical?
| |
| YES -----> V-MODEL
| |
| NO -----> WATERFALL
|
NO ------> Is the project large & high-risk?
|
YES -----> SPIRAL
|
NO -----> Can it be split into modules for fast build?
|
YES -----> RAD
|
NO -----> Is UI/requirement clarity the
main concern?
|
YES -----> PROTOTYPING
|
NO -----> INCREMENTAL or AGILE
(Agile if customer can
stay closely involved)
11. Sample Anna University Style Questions
Part A — 2 Mark Questions
1. Define software process model.
2. What is the Waterfall Model? List its phases.
3. Differentiate throw-away and evolutionary prototyping.
4. What is the main principle behind the Spiral Model?
5. List any two advantages of the Agile Model.
6. What does RAD stand for? Mention one key feature.
7. Draw the shape of the V-Model and label its two arms.
8. Mention two situations where the Waterfall Model is unsuitable.
9. What is meant by risk analysis in the Spiral Model?
10. State one difference between Incremental and Iterative development.
Part B / C — 16 Mark Questions
1. Explain the Waterfall Model in detail with a neat diagram. Discuss its advantages, disadvantages, and situations where it is applicable. (16)
2. Describe the Spiral Model with its four quadrants. Explain how it manages risk better than the Waterfall Model, with a suitable example. (16)
3. Compare and contrast the Incremental Model, RAD Model, and Agile Model in terms of process, flexibility, and customer involvement. (16)
4. Explain the Prototyping Model with a diagram. Distinguish between throw-away and evolutionary prototyping with examples. (16)
5. Illustrate the V-Model with a neat diagram. Explain how each development phase maps to a corresponding testing phase. (16)
References
T1: Pressman, R. S., & Maxim, B. R., Software Engineering: A Practitioner's Approach, 8th Edition, McGraw-Hill.
T2: Sommerville, I., Software Engineering, 10th Edition, Pearson.
R1: Boehm, B. (1988). A Spiral Model of Software Development and Enhancement. IEEE Computer.
R2: Beck, K. et al. (2001). Manifesto for Agile Software Development.
Note: For full-text access, use institutional access via INDEST-AICTE Consortium or NDLI rather than unauthorized copies.