Chapter 2 – Software Processes

1
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.
We need:
• A broad philosophy
• A set of tools which support the philosophy.
• A language which supports the philosophy.

Models are useful tools in learning science which can be

used to improve explanations, generate discussion, make
predictions, provide visual representations of abstract
concepts and generate mental models
The Software Process

4
 Process Model

A software process model is an abstract representation

of a process. It presents a description of a process
from some particular perspective.
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

• Design — how
▪ the internal structure of the product

• Architectural design
▪ decompose product into modules (e.g., objects)

• Detailed design
▪ design each module — data structures, algorithms

• Design testing
▪ traceability & review
Implementation Phase

 Implement detailed design in code

 Implementation testing
▪ Code reviews
• programmer guides review team through listings

▪ Test cases
• informal testing (desk checking)
• formal testing & regression by SQA group
 Integration Phase
• Combine modules & check product as a whole

• Integration testing
• product testing
• check against the spec (e.g., is the response time short enough)
• check for robustness (can it handle erroneous data)
• acceptance testing (by client with real data)

• Maintenance Phase
• Changes after release, Its costs exceed 67% of total cost of software
• Three main categories of maintenance
• Corrective, adaptive, perfective
The waterfall model

• Definition: The waterfall model is a classical model used in

system development life cycle to create a system with a linear
and sequential approach.
• It is termed as waterfall because the model develops
systematically from one phase to another in a downward fashion.

• This model is divided into different phases and the output of one
phase is used as the input of the next phase.

• Every phase has to be completed before the next phase starts

and there is no overlapping of the phases.

11
 The waterfall model
• Planning
In this phase we view the software
product as part of a larger system or
organization where the product is
required. This is basically a system
view where all the system elements
are created.
• Software Requirements
Analysis
The system’s services, constraints, and
goals are established by consultation
with system users. They are then
defined in detail and serve as a
system specification. 12
 Waterfall model phases

 System and software design:

This determines the data structures, the software architecture, the interface
representations and the procedural (algorithmic) detail that goes into the
software.
 Implementation
Here the actual programming is done to obtain the machine code; it is an
implementation of the design.
 Testing
The testing is a process that goes hand in hand with the production of the
machine code. There are a number of testing strategies. First unit testing
is done and then integration testing. Alpha testing is to see if the software
is as per the analysis model whereas beta testing is to see if the software is
what the customer wanted.
Waterfall model phases CONTINUED...

• Installation
The software is released to the customer.

• Maintenance
This is the largest phase of the software life cycle. Maintenance
can be of different types: to modify the software as the
requirements of the customer evolve, to remove the residual
bugs in the software etc.
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 test
• Testing period comes quite late in the
(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 cycle developers and testers

• Project is completely dependent on project • We cannot find any error till time testing of
team with minimum client intervention software not done.

• 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 16
 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
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
Introducing a Prototype
• A prototype is a way of showing our ideas in a tangible way
very early on.
• Prototype as a word comes from the Greek prototypes which
mean “first impression”.

• Prototyping is an experimental process where design teams implement

ideas into tangible forms from paper to digital.

• Teams build prototypes of varying degrees of fidelity to capture design

concepts and test on users.

• With prototypes, you can refine and validate your designs so your
brand can release the right products.

19
Introducing a Prototype
• A system prototype is an initial, ow-featured (in-complete) example system
• Developed for the purpose of gathering user’s feedbacks during system
development
• Types of feedback include:
▪ User Reactions
▪ How users feel while working with the prototype system?
▪ User Suggestions
▪ What features users want to change (remove/ modify)?
▪ Innovations
▪ What new features users want to add (not implemented in the prototype)?
▪ Revision Plans
▪ What system features should be included in the next prototype?

User’s feedbacks are collected through interviews, observation and

questionnaires after prototype delivery
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
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 between
Modeling 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
Application Automated tools are used for the construction of the
Generation software, to convert process and data models into prototypes
Testing and As prototypes are individually tested during every iteration,
Turnover the overall testing time is reduced in RAD.

29
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
30
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
It is adaptable and flexible to When technical risk is high, it is not
changes suitable
Due to code generators and code Reduced features due to time boxing,
reuse, there is a reduction of manual where features are pushed to a later
coding version to finish a release in short 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
31
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. 33
 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

 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

35
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

36
 Advantages and Disadvantages of
Incremental Model
Advantages Disadvantages
• The software will be generated • It requires a good planning
quickly during the software life cycle designing
• Problems might cause due to system
• It is flexible and less expensive to architecture as such not all
change requirements and scope requirements collected up front for
the entire software lifecycle
• Throughout the development stages • Each iteration phase is rigid and
changes can be done does not overlap each other
• Rectifying a problem in one unit
• This model is less costly compared to
requires correction in all the units
others
and consumes a lot of time
• A customer can respond to each
building
• Errors are easy to be identified
37
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.
40
 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.

41
 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

43
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