Chapter 2

Software process models

Topics covered
▪ Software process models

▪ Waterfall

▪ Rapid prototyping

▪ Incremental

▪ Synchronize-and-stabilize

▪ Spiral
Why have a model?
• Software is developed using a life cycle model
• Just a life cycle model is insufficient for development.
• In Software Engineering (SE), we use models because
they help us understand, design, and manage complex
systems more effectively.

We need:
• A broad philosophy

• A set of tools which support the philosophy.

• A language which supports the philosophy.

The Software Process

4
Process Model
▪ A software process model is a framework that defines the
steps, activities, and tasks involved in developing a software
product.
▪ It shows how the work is organized and how each stage of
development connects to the next.

▪ Main Purposes:
▪ To guide the development process in an organized way.
▪ To improve planning and control of software projects.
▪ To ensure product quality and reduce risks.
▪ To manage time, cost, and resources effectively.
Examples of Software Process Models

▪ The three general software process models include:

▪ Waterfall Model: A linear and sequential

approach with defined stages.
▪ Agile Model: An iterative and collaborative method
with a focus on flexibility.
▪ Iterative Model: Similar to Agile but with emphasis
on revisiting and refining phases.
Phases of Software life Cycle

▪ The seven phases of SW Life Cycle

▪ Requirements phase
▪ Specification phase
▪ Design phase
▪ Implementation phase
▪ Integration phase
▪ Maintenance phase
▪ Retirement
Requirements Phase
• Concept exploration
• determine what client needs not what client wants
• determine the constraints, e.g., ?
• Cost, deadline, reliability, size, performance

• Specifications Phase
• Specification describes the functionality, what the products
is supposed to do & any constraints.
• it is a legal document – a contract
• It must not be ambiguous, incomplete, or contradictory
Design Phase
Key Activities

1. System Design
– Define overall system architecture (modules, components,
data flow).
2. Database Design
– Plan how data will be organized, stored, and accessed.
3. Interface Design
– Design user interfaces and system interactions.
4. Algorithm Design
– Define logic and processing steps for each function.
5. Design Evaluation
– Review and validate the design for correctness and efficiency.
Implementation Phase
▪ To convert the software design into a working program by
writing, compiling, and integrating code components.
• Key Activities:
1) Coding – Developers write code using suitable programming
languages and tools.
2) Unit Testing – Each module or component is tested individually to ensure
it works correctly.
3) Integration – Combine modules and verify they function together
properly.
4) Debugging – Identify and fix errors or defects found during testing.

5) Documentation – Prepare user manuals, technical guides, and code

documentation.
Integration Phase
▪ The integration phase is the stage where individual modules or
components of a system are combined and tested as a group.
This often follows unit testing and precedes system testing.
▪ Key activities:
▪ Assembling components/modules into a complete system
▪ Integration testing (checking interfaces between modules)
▪ Identifying and resolving bugs or mismatches between
components
▪ Continuous Integration (CI) practices, possibly using CI/CD
tools
Maintenance Phase
▪ The maintenance phase occurs after the software has been deployed and
delivered to users. It involves making updates, corrections, and improvements
to the software to ensure it continues to perform well over time.

▪ Key Activities in the Maintenance Phase:

[Link] Maintenance
Fixing bugs and errors discovered after deployment.
[Link] Maintenance
Modifying the software to work in a changed environment, like new
operating systems, hardware, or third-party software updates.
[Link] Maintenance
Enhancing features and improving performance based on user feedback
and changing requirements.
[Link] Maintenance
Making changes to prevent future problems, such as refactoring code or
improving documentation.
The waterfall model
▪ The Waterfall Model is a linear application development
model that uses rigid phases: When one phase ends, the next
begins.
▪ Steps occur in sequence, and, if unmodified, the model does
not allow developers to go back to previous steps (hence
“waterfall”: Once water falls down, it cannot go back up).

▪ The waterfall model is a breakdown of development

activities into linear sequential phases, meaning they are
passed down onto each other, where each phase depends
on the deliverables of the previous one and corresponds to
a specialization of tasks.
The waterfall model

Chapter 2 Software Processes 14

The waterfall model
▪ The Waterfall methodology was once the dominant approach
that informed the project life cycle and processes software
development teams followed.

▪ A linear development model that unfolds in strict sequence,

each phase of the Waterfall methodology’s life cycle begins
when the previous ends.
1. Analysis
2. Design
3. Implementation
4. Testing
5. Maintenance
Requirements analysis
▪ The linear nature of the Waterfall methodology gives
additional significance to this first stage in its life cycle.

▪ All requirements of the final software product’s utility and

features have to be gathered here.

▪ Once the requirements analysis stage is completed the

software development team should have all the information
needed to complete the project without any, or minimal,
further involvement from whoever has contracted or
otherwise. initiated the project.
Design
▪ The design phase is often divided into two subphases – logical
(or preliminary) design and physical (or detailed) design.

▪ The logical or preliminary design phase involves putting all

possible solutions on the table and analysing their strengths
and weaknesses within the context.

▪ Once theoretical ideas have been assessed and decisions

taken on which to go with, the physical or detailed design
phase is when they are documented and detailed as concrete
specifications.
 Implementation/Coding
• The rump of the project – when software developers write and
assemble the actual code that turns the specifications detailed
in the design phase into a functioning software system.

Testing
• When the implantation phase has been fully completed, manual
software have to make sure every component of the software
system works as intended, both autonomously and across any
dependencies.
• Testers will use documentation created at the design phase, user
personas and user journey scenarios to run as many test cases as
possible in the attempt to uncover any bugs that need to be
fixed before deployment. 18
Deployment
• When the software system has been tested and approved for
release, a copy must be transferred from the software
development environment and released in the live staging
environment from which users will be able to access and use it.
This stage is called deployment.

• Team members responsible for deployment should be aware of

any differences between the software development and live
server environments and make any adjustments needed for the
software to run the same way in both.

19
Maintenance
• In the maintenance phase, the software is in use and the
primary job is now to keep it available and running
smoothly as well as fixing any bugs reported by users that
may have been missed during the testing phase.
When to use Waterfall Model?
Waterfall Methodology can be used when:
• Requirements are not changing frequently
• Application is not complicated and big
• Project is short
• Requirement is clear
• Environment is stable
• Resources are available and trained
 Advantages and Disadvantages of
Waterfall Model

Advantages Dis-Advantages
• Before the next phase of development,
• Error can be fixed only during the phase
each phase must be completed
• Suited for smaller projects where • It is not desirable for complex project
requirements are well defined where requirement changes frequently
• They should perform quality assurance
• Testing period comes quite late in the
test (Verification and Validation) before
developmental process
completing each stage
• Elaborate documentation is done at every
• Documentation occupies a lot of time of
phase of the software’s development
developers and testers
cycle
• Project is completely dependent on
• We cannot find any error till time testing
project team with minimum client of software not done.
intervention
• Small changes or errors that arise in the
• Any changes in software is made during
completed software may cause a lot of
the process of the development
problems 22
Rapid Prototyping
• Rapid prototyping as a requirements tool
▪ allow users to “see” & use proposed solutions
▪ develop specification from the prototype and proceed with rest of stages
in waterfall model.
• Prototype must be constructed & changed quickly

Rapid prototyping in 3 easy steps

• Build. Create mock-ups of a design concept or flow, keeping your users' needs
and company's goals in mind.
• Review. Test your prototype with target users and key stakeholders to learn
whether it meets expectations.

• Refine. Adjust the prototype based on the feedback you receive.

Introducing a Prototype
• A system prototype is an initial, low-featured (in-complete) example system
• Developed for the purpose of gathering users feedbacks during system
development
▪ Introducing a Prototype means creating and presenting an early version of a
system or product to demonstrate how it will work before the final version is built.

▪ This prototype acts as a model or sample that helps users and developers:

▪ Visualize the system early in development.

▪ Identify missing or unclear requirements.
▪ Test design ideas and system functionality.
▪ Gather feedback from users to make improvements.

Users feedbacks are collected through interviews, observation and

questionnaires after prototype delivery
Introducing a Prototype
• Purpose of Introducing a Prototype

• To reduce misunderstanding between users and developers.

• To validate requirements before heavy investment.
• To save time and cost by fixing issues early.

• Example:
• Before building a full banking app, developers create a clickable
prototype showing how users will log in, transfer money, and view
transactions.
•
This prototype is introduced to clients to get their approval and
suggestions before final development.
Prototype Conceptions
• Generally speaking, a prototype is an incomplete
sample of the corresponding system
• Four different conceptions for incomplete system:

▪ Patched-Up Prototype

▪ Non-operational Prototype
▪ First-of-a-Series Prototype
▪ Selected Features Prototype
….Prototype Conceptions
Patched-up Prototype
• A working (complete) system with the features not fully
matured
• Features need to be matured in the future versions
(patched with more code)
• Example:

▪ An information system with inefficient retrieval and

storage of information [Average Query time =
100s of seconds)

▪ Needs code refinements in order to make an efficient

retrieval (10s of seconds)
 ….Prototype Conceptions
Non-operational Prototype
• A non-working model (no feature is completely
implemented) showing only desired system aspects
• Example:
▪ An information system with no real processing
done (only input screens and output layouts can
be seen)
….Prototype Conceptions
First-of-series Prototype
• A fully functional system (newly developed)

• Launched on limited basis (smaller set of users)

• Minimizes the costs of overcoming any existing bug

• Examples:
– A banking system (electronic funds transfer) fully
functional prototype installed in one branch only
– If successful, will be installed at other locations.
….Prototype Conceptions
Selected Features Prototype
• An operational system model with some features implemented.
• The prototype is evaluated for the success of the implemented
features. The features will then be incorporated into the larger
final system.

• Example:
• A system with only selected menu items working.
• A modular system development approach is
needed.
• Every module implements a different feature
& can be integrated easily into the larger system.
Assessment of RP Model
• Advantages ?
▪ process proceeds linearly (less need for feedback loops)
▪ easier to take technology risks with the prototype
• Disadvantages
▪ expectation management
▪ delivering “everything” properly takes time

• turning prototypes into production code

▪ quite controversial...
▪ will turn into build-and-fix
Rapid Prototyping
Build and discard Changed
simple prototype requirements
Verify Verify

Specification
phase
Verify

Design
phase
Verify

Implementation
phase
Test

Integration
Development phase
Maintenance Test

Operations mode

Retirement
THE RAD MODEL
THE RAD MODEL

• Rapid Application Development (RAD) is an

incremental software process model that emphasizes a
short development cycle.
• RAD is a “high-speed” adaptation of the waterfall
model, in which rapid development is achieved by using
a component-based construction approach.
• If requirements are well understood and project scope
is constrained, the RAD process enables a development
team to create a fully functional system within a short
period of time.
Different Phases of RAD Model
RAD Model
Activities performed in RAD Modeling
Phases
Business On basis of the flow of information and distribution
Modeling between various business channels, the product is designed
The information collected from business modeling is refined
Data Modeling into a set of data objects that are significant for the
business
The data object that is declared in the data modeling phase
Process
is transformed to achieve the information flow necessary to
Modeling
implement a business function
Automated tools are used for the construction of the
Application
software, to convert process and data models into
Generation
prototypes
Testing and As prototypes are individually tested during every iteration,
Turnover the overall testing time is reduced in RAD. 35
When to use RAD Methodology?
• When a system needs to be produced in a short
span of time (2-3 months)
• When the requirements are known
• When the user will be involved all through the life
cycle
• When technical risk is less
• When a budget is high enough to afford designers
for modeling along with the cost of automated tools
for code generation
RAD Advantages and Disadvantages

Advantages of RAD Model Disadvantages of RAD Model

Flexible and adaptable to changes It can’t be used for smaller projects
It is useful when you have to reduce Not all application is compatible with
the overall project risk RAD
When technical risk is high, it is not
It is adaptable and flexible to changes
suitable
Reduced features due to time boxing,
Due to code generators and code
where features are pushed to a later
reuse, there is a reduction of manual
version to finish a release in short
coding
period
Progress and problems accustomed are
Due to prototyping in nature, there is hard to track as such there is no
a possibility of lesser defects documentation to demonstrate what
has been done
With less people, productivity can be Requires highly skilled designers or
increased in short time developers
37
Evolutionary development
The evolutionary development is based on the idea of developing an
initial implementation, exposing this to the user comment and refining
this through many versions until an adequate system has been
developed.
There are two types of evolutionary development,
▪ Exploratory development
Objective is to work with customers and to evolve a final system
from an initial outline specification. Should start with well-
understood requirements .
▪ Throw-away prototyping
Objective is to understand the system requirements. Should start
with poorly understood requirements.
Evolutionary development
Concurrent
activities

Initial
Specification
version

Outline Intermediate
Development
description versions

Final
Validation
version
Problems
-- Lack of process visibility.
-- Systems are often poorly structured.
-- Special skills (e.g. in languages for rapid
prototyping) may be required.
Applicability
-- For small or medium-size interactive systems.
-- For parts of large systems (e.g. the user interface).
-- For short-lifetime systems.
Incremental Model
• A process model where requirements are broken
down into multiple standalone modules of software
development cycle.
• Each linear sequence produces deliverable “increments”
of the software.
• For Example: a Word Processor delivers basic file
mgmt., editing, in the first increment; more sophisticated
editing, document production capabilities in the 2nd
increment; spelling and grammar checking in the 3rd
increment.
• When an increment model is used, the 1st increment is often a
core product. The core product is used by the customer.
• As a result of use and / or evaluation, a plan is developed for the
next increment.
• The plan addresses the modification of the core product to better
meet the needs of the customer and the delivery of additional
features and functionality.
• The process is repeated following the delivery of each increment,
until the complete product is produced. 42
 Synchronize-and-Stabilize

Specifications Design Implementation, Deliver to

Integration client (version 1)

Specifications Design Implementation, Deliver to

Integration client (version 2)

Specifications Design Implementation, Deliver to

Integration client (version 3)

.. .. ..
. . .

Specifications Design Implementation, Deliver to

Integration client (version n)

Specification team Design team Implementation/integration team

 Synchronize-and-Stabilize

• Definition:
• The Synchronize-and-Stabilize Model is a software development
approach where multiple teams work in parallel on different parts
(modules) of a system, and then regularly synchronize (combine) their
work and stabilize (test and fix bugs) before moving to the next phase.
• This model was famously used by Microsoft for large projects like Windows
and Office.
• Key Concepts
• Parallel development: Different teams develop components at the same
time.
• Synchronization: Teams regularly integrate their code (e.g., daily or
weekly).
• Stabilization: After synchronization, testing and debugging are done to
ensure everything works together.
• Iterative cycles: Development continues in multiple cycles until the product is
complete.
 Incremental Phases

Incremental
Activities performed in incremental phases
Phases
Requirement • Requirement and specification of the software are
Analysis collected
Design • Some high-end function are designed during this stage
Code • Coding of software is done during this stage
• Once the system is deployed, it goes through the
Test
testing phase

45
When to use Incremental models?
• Requirements of the system are clearly understood
• When demand for an early release of a product arises
• When software engineering team are not very well
skilled or trained
• When high-risk features and goals are involved
• Such methodology is more in use for web application
and product based companies
 Advantages and Disadvantages of
Incremental Model
Advantages Disadvantages
• The software will be generated
• It requires a good planning
quickly during the software life
designing
cycle
• Problems might cause due to
• It is flexible and less expensive to system architecture as such not all
change requirements and scope requirements collected up front for
the entire software lifecycle
• Throughout the development • Each iteration phase is rigid and
stages changes can be done does not overlap each other
• Rectifying a problem in one unit
• This model is less costly compared
requires correction in all the units
to others
and consumes a lot of time
• A customer can respond to each
building
47
• Errors are easy to be identified
Boehm’s spiral model
(Risk-driven software process framework)
• Process is represented as a spiral rather than as a
sequence of activities with backtracking
• Each loop of the spiral represents a phase of the
software process.
• For example, the innermost loop might be concerned
with feasibility study, the next loop with requirements
specification, the next one with design, and so on.
• Each phase in this model is split into four sectors
(or quadrants)
• Risks are explicitly assessed and resolved throughout the
process
 Spiral Model [Boehm, IEEE 1998]

Evaluate alternatives,
Objective setting Cumulative Progress
identify, resolve risks

Risk Analysis
cost through steps

Determine
objectives, Risk
alternatives, Risk
Analysis

constraints Risk
Analysis
Analysis

Risk
Commitment Analysis Operational
Prototype 1 Prototype 2 Prototype 3 Prototype
Review
Partition Simulations, models, benchmarks
Requirement plan Concept of

Development
life-cycle plan Operation
Detailed
Software Design
Development Plan Requirement Requirements
Software Code
Validation
Plan next phase Product
Design Unit
Integration and Test Design validation Test
Plan and verification
Integration
Acceptance Test
Implementation Test

Planning Develop, verify

next-level product
 Spiral Model [Boehm, IEEE 1998]
First quadrant (Objective Setting)
• During the first quadrant, it is needed to identify the objectives of
the phase.
• Examine the risks associated with these objectives.
Second Quadrant (Risk Assessment and Reduction)
• A detailed analysis is carried out for each identified project risk.
• Steps are taken to reduce the risks. For example, if there is a risk
that the requirements are inappropriate, a prototype system may
be developed.
Third Quadrant (Development and Validation)
• Develop and validate the next level of the product after resolving
the identified risks. 50
Spiral Model [Boehm, IEEE 1998]
Fourth Quadrant (Review and Planning)
• Review the results achieved so far with the
customer and plan the next iteration around
the spiral.
• Progressively more complete version of the
software gets built with each iteration around
the spiral.

51
When to use Spiral Model?
• A Spiral model in software engineering is used when project is
large
• When releases are required to be frequent, spiral
methodology is used
• When creation of a prototype is applicable
• When risk and costs evaluation is important
• Spiral methodology is useful for medium to high-risk projects
• When requirements are unclear and complex, Spiral model in
SDLC is useful
• When changes may require at any time
 Spiral Model
Advantages and Disadvantages

Advantages Disadvantages
• Additional functionality or changes • Risk of not meeting the schedule or
can be done at a later stage budget
• Cost estimation becomes easy as the • Spiral development works best for
prototype building is done in small large projects only also demands risk
fragments assessment expertise
• Continuous or repeated development • For its smooth operation spiral model
helps in risk management protocol needs to be followed strictly
• Development is fast and features are
• Documentation is more as it has
added in a systematic way in Spiral
intermediate phases
development
• Spiral software development is not
• There is always a space for customer
advisable for smaller project, it might
feedback
cost them a lot

53
A Comparison of Life Cycle Models

Model Strengths Weaknesses

Waterfall Disciplined approach Delivered product may not meet
Document driven client’s needs
Rapid Ensures that delivered product A need to build twice
Prototyping meets client’s needs Cannot always be used
Incremental Maximizes early return on Requires open architecture
investment May degenerate into build-and-fix
Promotes maintainability
Synchronize- Future user’s needs are met Has not been widely used other
and-stabilize Ensures components can be than in Microsoft
successfully integrated
Spiral Incorporates features of all the Can be used only for large-scale
above models products
Developers have to be competent
at risk-analysis
Summary
❑ There is no ideal process model

❑ For large systems, hybrid process models are usually

appropriate
❑ The manager should define the process model used for

the project at the start of the project

❑ Risk analysis and risk resolution are significant process

drivers