Software Processes

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Objectives
• To introduce software process models
• To describe three generic process models and
when they may be used
• To describe outline process models for
requirements engineering, software
development, testing and evolution
• To explain the Rational Unified Process model
• To introduce CASE technology to support
software process activities
Dr. G. Magesh,Assistant Professor(Sr),SITE
 Topics covered
• Software process models
• Process iteration
• Process activities
• The Rational Unified Process
• Computer-aided software engineering

Dr. G. Magesh,Assistant Professor(Sr),SITE

 The software process
• A structured set of activities required to develop a software
system
– Specification;
– Design;
– Validation;
– Evolution.
• A software process model is an abstract representation of a
process. It presents a description of a process from some
particular perspective.

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Generic software process models
• The waterfall model
– Separate and distinct phases of specification and development.
• Evolutionary development
– Specification, development and validation are interleaved.
• Reuse-based software engineering
– The system is assembled from existing components.
• There are many variants of these models e.g. formal
development where a waterfall-like process is used but the
specification is a formal specification that is refined through
several stages to an implementable design.

Dr. G. Magesh,Assistant Professor(Sr),SITE

Dr. G. Magesh,Assistant Professor(Sr),SITE
Waterfall Model
• Requirements – defines needed
information, function, behavior,
performance and interfaces.
• Design – data structures, software
architecture, interface
representations, algorithmic
details.
• Implementation – source code,
database, user documentation,
testing.

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Waterfall model

Requir ements
definition

System and
software design

Implementa tion
and unit testing

Integ ration and

system testing

Oper ationand
maintenance

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Waterfall model phases
• Requirements analysis and definition
• System and software design
• Implementation and unit testing
• Integration and system testing
• Operation and maintenance
• The main drawback of the waterfall model is
the difficulty of accommodating change after
the process is underway. One phase has to be
complete before moving onto the next phase.

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Waterfall Strengths
• Easy to understand, easy to use
• Provides structure to inexperienced staff
• Milestones are well understood
• Sets requirements stability
• Good for management control (plan, staff, track)
• Works well when quality is more important than cost
or schedule

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Waterfall Deficiencies
• All requirements must be known upfront
• Inflexible partitioning of the project into distinct stages
• the requirements are well-understood and changes will be
fairly limited during the design process.
• The waterfall model is mostly used for large systems
engineering projects
• Little opportunity for customer to preview the system (until it
may be too late)

Dr. G. Magesh,Assistant Professor(Sr),SITE

 When to use the Waterfall Model
• Requirements are very well known
• Product definition is stable
• Technology is understood
• New version of an existing product
• Porting an existing product to a new platform.
• Large Project

Dr. G. Magesh,Assistant Professor(Sr),SITE

 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 and
add new features as proposed by the customer.
• Throw-away prototyping
– Objective is to understand the system requirements.
Should start with poorly understood requirements to
clarify what is really needed.

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Structured Evolutionary Prototyping
Model
• Developers build a prototype during the
requirements phase
• Prototype is evaluated by end users
• Users give corrective feedback
• Developers further refine the prototype
• When the user is satisfied, the prototype code
is brought up to the standards needed for a
final product.
Dr. G. Magesh,Assistant Professor(Sr),SITE
Requirements
Gathering
Design

Design

Implementation
Implementation

Testing
Testing

Maintenance

Dr. G. Magesh,Assistant Professor(Sr),SITE

Prototyping Paradigm

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Structured Evolutionary Prototyping
Steps
• A preliminary project plan is developed
• An partial high-level paper model is created
• The model is source for a partial requirements specification
• A prototype is built with basic and critical attributes
• The designer builds
– the database
– user interface
– algorithmic functions
• The designer demonstrates the prototype, the user evaluates
for problems and suggests improvements.
• This loop continues until the user is satisfied.

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Structured Evolutionary Prototyping
Strengths
• Customers can “see” the system requirements as
they are being gathered.
• Developers learn from customers.
• A more accurate end product.
• Unexpected requirements accommodated
• Allows for flexible design and development
• Steady, visible signs of progress produced
• Interaction with the prototype stimulates awareness
of additional needed functionality

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Structured Evolutionary Prototyping
Weaknesses
• Tendency to abandon structured program
development for “code-and-fix” development
• Overall maintainability may be overlooked
• The customer may want the prototype delivered.
• Process may continue forever (scope creep)

Dr. G. Magesh,Assistant Professor(Sr),SITE

 When to use
Structured Evolutionary Prototyping
• Requirements are unstable or have to be clarified
• Develop user interfaces
• Short-lived demonstrations
• New, original development
• With the analysis and design portions of object-
oriented development.

Dr. G. Magesh,Assistant Professor(Sr),SITE

Evolutionary development

Concurr ent
acti vities

Initial
Specifica tion version

Outline Inter media te

Development versions
description

Final
Valida tion version

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Evolutionary development
• Problems
– Lack of process visibility;
– Systems are often poorly structured;
– Special skills (e.g. in languages for rapid
prototyping) may be required.

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Reuse-oriented development
• Process stages: (following initial requirements specification)
– Reusable software analysis (what’s available?)
– Requirements modification – why?
– System design with reuse
– Development and integration
• This approach is becoming more important,
but experience is still limited.

“Software Repositories” research was a major DoD thrust in the late 80’s.

Dr. G. Magesh,Assistant Professor(Sr),SITE

(cont'd)
Reuse-oriented development

Requirements Component Requirements System design

specification analysis modification with reuse

Development System
and integ ration validation

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Process iteration
• System requirements ALWAYS evolve in the
course of a project so process iteration where
earlier stages are reworked is always part of
the process for large systems.
• Iteration can be applied to any of the generic
process models.
• Two (related) approaches
– Incremental delivery;
– Spiral development.

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Incremental delivery
• Rather than deliver the system as a single delivery, the
development and delivery is broken down into increments
with each increment delivering part of the required
functionality.
• user requirements are prioritised and the highest priority
requirements are included in early increments.
• once development of an increment is started, the
requirements are frozen though requirements for later
increments can continue to evolve.

Dr. G. Magesh,Assistant Professor(Sr),SITE

Incremental SDLC Model
• Construct a partial
implementation of a total
system
• Then slowly add increased
functionality
• The incremental model
prioritizes requirements of the
system and then implements
them in groups.
• Each subsequent release of the
system adds function to the
previous release, until all
designed functionality has been
implemented.

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Incremental development

Define outline Assign requirements Design system

requirements to increments ar chitectur e

Develop system Valida te Integ rate Validate

increment increment increment system
Final
system
System incomplete

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Incremental Model (INM)

Final System
1-1 1-2 1-3 1-4

Basic process
Req. S/w Solution
1 Increment process Coding
Codin
Analysis Design Tes
g t
Next Increment

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Incremental (staged) Delivery

Software Differs from

concept Evolutionary Prototyping
in that
Requirements requirements are
Analysis fully known at the start
Architectural
Design
Stage 1: Detailed design, code, debug, test
and delivery

Stage 2: Detailed design, code, debug, test

and delivery

Stage n: Detailed design, code, debug, test

and delivery
Dr. G. Magesh,Assistant Professor(Sr),SITE
 Design-to-Schedule
Software
concept

Note: Variation on
Requirements
Analysis Incremental Model
Architectural n
Design
High Priority: Detailed design, code, debug,
test

Stages prioritised
Medium-High Priority: Detailed design,
code, debug, test lower priority
last. Thus if
Release
Medium Priority: Detailed design, code, deadline or budget
debug, test
is reached before
run out of time/money product finished
Medium-Low Priority: Detailed design,
code, debug, test lowest priority
stages
Low Priority: Detailed design, code, debug, can be omitted.
test
Dr. G. Magesh,Assistant Professor(Sr),SITE
 Advantages
– requirements gathered in initial stages
– overall architectural design is determined
– requirements met in successive stages of the
project
– users get part of the functionality delivered at an
early stage (As in evolutionary prototyping)

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Disadvantage
– Needs careful planning - stages have
interdependencies
– If not planned well - extra effort in interfacing
stages
– Users may tire of constant changes
– funding may be difficult to obtain for a succession
of changes

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Extreme programming
• An approach to development based on the
development and delivery of very small
increments of functionality.
• Relies on constant code improvement, user
involvement in the development team and
pairwise programming.

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Spiral development
• Process is represented as a spiral rather than
as a sequence of activities with backtracking.
• Each loop in the spiral represents a phase in
the process.
• No fixed phases such as specification or design
- loops in the spiral are chosen depending on
what is required.
• Risks are explicitly assessed and resolved
throughout the process.
Dr. G. Magesh,Assistant Professor(Sr),SITE
Spiral model of the software process
Deter mineobjecti ves,
Evalua te alterna tives,
alterna tives and
identify , resolv e risks
constr aints Risk
anal ysis

Risk
anal ysis

Risk
Oper a-
anal ysis
Pr ototype 3 tional
Pr ototype 2 pr oto ype
Risk
REVIEW anal ysis Pr oto-
type 1
Requir ements plan Simula tions , models , benchmar ks
Life-cy cle plan Concept of
Oper a tion S/W
requir ements Product
design Detailed
Requir ement design
De velopment
plan valida tion Code
Unit test
Integ ra tion Design
V&V Integ ra tion
andtestplan
Plan ne xt phase test
Acceptance
Service test De velop , verify
ne xt-le vel pr oduct

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Spiral model sectors
• Objective setting
– Specific objectives for the phase are identified.
• Risk assessment and reduction
– Risks are assessed and activities put in place to reduce the key
risks.
• Development and validation
– A development model for the system is chosen which can be any
of the generic models.
• Planning
– The project is reviewed and the next phase of the spiral is planned.

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Spiral Model Strengths
• Provides early indication of insurmountable risks, without
much cost
• Users see the system early because of rapid prototyping tools
• Critical high-risk functions are developed first
• The design does not have to be perfect
• Users can be closely tied to all lifecycle steps
• Early and frequent feedback from users
• Cumulative costs assessed frequently

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Spiral Model Weaknesses
• Time spent for evaluating risks too large for small or low-risk
projects
• Time spent planning, resetting objectives, doing risk analysis
and prototyping may be excessive
• The model is complex
• Risk assessment expertise is required
• Spiral may continue indefinitely
• Developers must be reassigned during non-development
phase activities
• May be hard to define objective, verifiable milestones that
indicate readiness to proceed through the next iteration

Dr. G. Magesh,Assistant Professor(Sr),SITE

 When to use Spiral Model
• When creation of a prototype is appropriate
• When costs and risk evaluation is important
• For medium to high-risk projects
• Long-term project commitment unwise because of
potential changes to economic priorities
• Users are unsure of their needs
• Requirements are complex
• New product line
• Significant changes are expected (research and
exploration)

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Key points
• Software processes are the activities involved in producing and
evolving a software system.
• Software process models are abstract representations of these
processes.
• General activities are specification, design and implementation,
validation and evolution.
• Generic process models describe the organisation of software
processes. Examples include the waterfall model, evolutionary
development and component-based software engineering.
• Iterative process models describe the software process as a cycle
of activities.

Dr. G. Magesh,Assistant Professor(Sr),SITE

 Key points
• Requirements engineering is the process of developing a
software specification.
• Design and implementation processes transform the
specification to an executable program.
• Validation involves checking that the system meets to its
specification and user needs.
• Evolution is concerned with modifying the system after it is in
use.
• The Rational Unified Process is a generic process model that
separates activities from phases.
• CASE technology supports software process activities.

Dr. G. Magesh,Assistant Professor(Sr),SITE