Software Process Models – A Quick Look

This blog is targeted at the audience that has some knowledge on software process models.

What is a Software Process Model?

A software process model is a standardized format for planning, organizing, and running a project. It is a description of the sequence of activities carried out in a project, and the relative order of these activities. It provides a fixed generic framework that can be tailored to a specific project.

Consider the equation, Project Plan = Process Model + Project Parameters

Project Parameters shall include Size of the Project in Man-Days, Budget and Duration (targeting RTM).

There are different models exist and are used – Waterfall, Prototyping, Spiral, Rational Unified Process (RUP), Code-And-Fix, Agile Methods – Extreme Programming (XP), etc.

By changing the process model, we can improve and /or trade-off the development speed, product quality, project visibility, overheads, risk exposure, stakeholder relations, etc.

The process model covers the entire lifetime of a product including inception of the business idea, design, build and maintain till the final decommissioning.

The process models can be combined or evolved with product maturity.

Since software project does not produce anything physical unlike other engineering verticals, software engineering must produce artifacts (that are applicable as per their company standards) like Business Requirement Document (BRD), User Stories, Use Cases, Functional Requirement / Specification Document (FRD / FSD), Design Documents (high-Level and Detailed), Prototypes, Project Plan, Reports, Status Meetings and its Minutes, Source Code Documentation, Unit Test Scripts and Results, Integration Test Scripts and Results, Test Plan, Test Scenarios, Test Cases, Test Results, Defect Logging, Tracking and Closure Report, Customer Satisfaction Survey Reports, etc.

Now I shall survey the important models and you can consider how to choose between them.

The Waterfall Model

The waterfall model is the classic process model that is widely known, understood and used.



Easy to understand and implement 

Doesn’t reflect iterative nature of exploratory


Widely used and known 

Sometimes unrealistic to expect accurate requirements early in a project 

Fits other engineering process models: civil, mech etc

Software is delivered late, delays discovery of serious errors 

Reinforces good habits: define-before- design, design-before-code 

No inherent risk management 

Identifies deliverables and milestones 

Difficult and expensive to change decisions, “swimming upstream”

Document driven 

Significant administrative overhead, costly for small teams and projects 

Works well on large/mature products and weak teams 



The Spiral Model

This model extends waterfall model by adding iteration to explore or manage risk. The core idea behind this model is to identify and solve the sub-problems with the highest risk in each iteration. It progresses a project cyclically in four steps or phases:

  1. Consider alternative scenarios and constraints
  2. Identify and resolve risks
  3. Execute the phase
  4. Plan next phase and then go to step 1



the model accurately reflects the iterative nature of software development on projects with unclear requirements 

Model is poorly understood by nontechnical management, hence not so widely used

incorporates the advantages of the waterfall and evolutionary methods 

Complicated model, needs competent

professional management 

Comprehensive model decreases risk 

Needs technical expertise in risk analysis

and risk management to work well

Good project visibility 

High administrative overhead 


The Prototyping

This model emphasizes requirements analysis and validation. The core idea behind this model is “Customers are non-technical and usually don’t know what they want.”




Reduces risk of incorrect user requirements 

An unstable/badly implemented prototype

often becomes the final product 

Good where requirements are changing/


Requires extensive customer collaboration 

Regular visible progress aids management

Difficult to know how long project will


Supports early product marketing 

Easy to fall back into code-and-fix without proper requirements analysis, design, customer evaluation and feedback 


Agile Methodology

This is an adaptive process model suited to changes in user requirements, customer business models, technology and in-house environment. This model de-emphasizes documentation and emphasizes on change management. The agile principles are as follows:

  1. Incremental delivery of software – Small Releases incrementally planned – Continuous Integration
  2. Continuous collaboration with customer – Onsite Customer
  3. Embrace change – Software Refactoring
  4. Value participants and their interaction – Egoless programming in pairs – Collective Ownership
  5. Simplicity in code – Simple Design
  6. Test-Driven Development



Lightweight methods suit small-medium

size projects 

Difficult to scale up to large projects where

documentation is essential 

Produces good team cohesion 

Needs experience and skill if not to

degenerate into code-and-fix 

Iterative & Emphasises final product 

Programming pairs is costly 

Test-based approach to requirements and

quality assurance 

Test case construction is a difficult and

specialized skill 


Rational Unified Process

This is a hybrid model inspired by UML and Unified Software Development Process. This identifies the product maturity stages like birth, childhood, adulthood, old-age and death. Here each project iteration cycle is a phase culminating in new releases (Spiral Model).

This is a generic component-based process with

  1. Dynamic (Phases) View
  2. Static (Activities) View and
  3. Practice (Best-Practices) View

The phases (dynamic view) of this model are goal directed and yield deliverables:

  • Inception – Establish Business Case, Identify external entities and Estimate ROI.
  • Elaboration – Understand the problem domain, establish architecture, consider design trade-offs, identify risks, estimate and schedule project, and decide on build or buy.
  • Construction – Design, code and test with the components bought and integrated.
  • Transition – Release a mature version and deploy in real world.

RUP Activities (static view) separates Phases and Workflows as

  • “When modeled by Phases”
  • “What modeled by Workflows” and
  • Any workflows can be active in any phase.

RUP Practices (practice view) to

  • Develop software iteratively
  • Manage requirements
  • Use component-based architectures
  • Visually model software
  • Verify software quality
  • Control software changes




Popular Language (UML) 

Pitched as “All-or-Nothing”

Good Tool Support 

Tries to cook for all 

Core Workflow Definitions 

Suitable only for Medium to large scale projects 

Incorporation of Business Process 

Developers may be confused and might not be able to use the RUP tools when customized or tailored to fit organization.

Recognition of Deployment Activities 


Architecture-Centric and Component-based 


Progressive Integration 



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at

Up ↑

%d bloggers like this: