U_I_C_3_Page 1 of 19

Software process models

Topic – 3
Module -I
Software Processes

• Coherent sets of activities for specifying, designing, implementing and testing

software systems
Prescriptive Process Models
• Developed to bring order and structure to the software development process.
• To get away from the chaos of most development processes.
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
Generic software process models
• The waterfall model
 Separate and distinct phases of specification and development
• Evolutionary development
 Specification and development are interleaved
• Formal systems development
 A mathematical system model is formally transformed to an implementation
• Reuse-based development
 The system is assembled from existing components
 U_I_C_3_Page 2 of 19
The Waterfall Model
Communicat ion
project init iat ion Planning
requirement gat hering estimating Modeling
scheduling
analysis Const ruct ion
tracking
design Deployment
code
t est delivery
support
f eedback

Waterfall model problems

• Inflexible partitioning of the project into distinct stages
• Difficult to respond to changing customer requirements
• Therefore, this model is only appropriate when the requirements are well-understood
Incremental development
• 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 the development of an increment is started, the requirements are frozen.

The Incremental Model

increment # n
Co m m u n i c a t i o n
Pl a n n i ng
M o d e l i n g
analy s is Co n s t ru c t i o n
des ign
c ode De p l o y m e n t
t es t d e l i v e ry
fe e d b a c k

deliv ery of
increment # 2 nt h increment

Co m m u n i c a t i o n
Pl a n n i ng
M o de l i n g
analy s is Co n s t ru c t i o n
des ign c ode De p l o y m e n t
t es t d e l i v e ry
fe e d b a c k
deliv ery of
increment # 1 2nd increment

Co m m u n i c a t i o n
Pl a n n i n g
M o d e l i ng
analy s is Co n s t ru c t i o n
des ign c ode De p l o y m e n t
t es t d e l i v e ry deliv ery of
fe e db a c k
1st increment

project calendar t ime

 U_I_C_3_Page 3 of 19
Incremental development advantages
• Customer value can be delivered with each increment so system functionality is
available earlier

• Early increments act as a prototype to help elicit requirements for later increments

• Lower risk of overall project failure

• The highest priority system services tend to receive the most testing
Disadvantage – Incremental Model
• First step gets a quick version that does part of project.

• Successive increments get better and more complete software.

Rapid Application Development

• Rapid Application Development – an incremental model that emphasizes a short
development cycle.

The RAD Model

Team # n
M o d e lin g
bus iness m odeling
dat a m odeling
proc ess m odeling

C o n s t r u c t io n
c om ponent reus e
Team # 2 aut om at ic code
Com m unicat ion generat ion
t est ing
Mo d eling
b u si n e ss m o d e l i n g
dat a m odeling
p ro ce ss m o d e l i n g

Planning
Co nst r uct io n De ploym e nt
Team # 1 co m p o n e n t re u se int egrat ion
a u t o m a t i c co d e
g e n e ra t i o n deliv ery
Mode ling t e st i n g feedback
business modeling
dat a modeling
process modeling

Const r uct ion

component reuse
aut omat ic code
generat ion
t est ing

6 0 - 9 0 days
 U_I_C_3_Page 4 of 19
Disadvantage - RAD
• Does not work for all projects -particularly large projects or when project is high risk.
Evolutionary Process Models
• Software evolves over time (web pages are a prime example)
• Limited version is needed to meet business pressures.
• Time does not allow a full and complete system to be developed.
• Evolutionary models are iterative as software engineers develop increasingly more
complete and complex systems
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
Concurr ent
activities

Initial
Specification
version

Outline Intermediate
Development
description versions

Final
Validation
version
 U_I_C_3_Page 5 of 19
Evolutionary development
• 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
Prototyping
• Prototypes are built when goals are general and not specific.
• Prototyping can be used as a standalone process or by one of the processes presented.
• The prototype serves as the first system. Users get a feel for the actual system and
developers get something built quickly.
• A prototype is intended for short term use but too often they are used much longer.
Prototyping

Qu i ck p l an

Co m m u n icat io n

Mo d e l i n g
Qu i ck d e si g n

Deployment
De live r y
& Fe e d b ack Co n st r u ct io n
of
p r o t o t yp e
 U_I_C_3_Page 6 of 19
The Spiral Model
• An evolutionary model that couples the iterative nature of prototyping
with the controlled, systematic aspects of waterfall model.
• Spiral model is often developed in a series of releases or versions.
• Better for large projects.
Spiral
Model
planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery cod e
feedback test

Concurrent Development Model

• All activities exist concurrently but are in different states.
• Some activities are in full production while others are awaiting changes.
• As events occur, then the flow works forward into the system.
 U_I_C_3_Page 7 of 19
Evolutionary Models: Concurrent
none

Modeling act ivit y

rep resent s t he st at e
Under o f a so f t ware eng ineering
act ivit y o r t ask
development

A wait ing
changes

Under review

Under
revision

Baselined

Done

Life Cycle Model Selection

 Based on Requirement Characteristics
 Based on development Team
 Based on Users Participation
 Based on Type of risk
Based on Requirement Characteristics
Requirements Waterfall Prototype Iterative Evolutionary Spiral RAD
Easily Yes No No No No Yes
Understandable
and defined
Change Quite No Yes No No Yes No
often
Defined in Yes No Yes Yes No Yes
Early Cycle
Indicating No Yes Yes Yes Yes No
Complexity of
system
 U_I_C_3_Page 8 of 19

Team Waterfall Prototype Iterative Evolutionary Spiral RAD

Less No Yes No No Yes No
Experience
on similar
Projects
Less Yes No Yes Yes Yes No
domain
Knowledge
Less Yes No No No Yes No
experience
on tools
Availability No No Yes Yes No Yes
of training

User’s Waterfall Prototype Iterative Evolutionary Spiral RAD

Participation
In All Phases No Yes No No No Yes
Limited Yes Yes Yes Yes
No Previous No Yes Yes Yes Yes No
experience of
participation
Experts of No Yes Yes Yes No No
problem
domain

Type of risk Waterfall Prototype Iterative Evolutionary Spiral RAD

Enhancement No No Yes Yes No Yes
of existing
system
Funding is Yes Yes No No No Yes
stable for
project
High No No Yes Yes Yes No
Reliability
Requirements
Tight Project No Yes Yes Yes Yes Yes
schedule
Use of No Yes No No Yes Yes
reusable
components
Resource No Yes No No Yes No
[Time, Cost,
People)scarcity
 U_I_C_3_Page 9 of 19
Other Process Models
• Component based development
When reuse is a development objective
• Formal methods
Emphasizes the mathematical specification of requirements
• AOSD
Provides a process and methodological approach for defining, specifying,
designing, and constructing aspects
• Unified Process
 “use-case driven, architecture-centric, iterative and incremental” software process
closely aligned with the Unified Modeling Language (UML)
Component Based Development
• COTS or Commercial Off-The-Shelf components are becoming more available.
• Most (not all) COTS components have targeted functionality with good interfaces that
enable the component to be integrated.
• This approach incorporates many of the aspects of the spiral model.
Reuse-oriented development
• Based on systematic reuse where systems are integrated from existing components or
COTS (Commercial-off-the-shelf) systems
• Process stages
 Component analysis
 Requirements modification
 System design with reuse
 Development and integration
• This approach is becoming more important but still limited experience with it.
 U_I_C_3_Page 10 of 19
Reuse-oriented development

Requirements Component Requirements System design

specification analysis modification with reuse

Development System
and integration validation

Formal Methods Development Model

• Formal mathematical specification of the software.
• Specify, develop and verify by rigorous math notation.
• Eliminates ambiguity, incompleteness, and inconsistency.
• Used more where safety-critical software is developed, e.g., aircraft avionics, medical
devices, etc.
Formal systems development
• Based on the transformation of a mathematical specification through different
representations to an executable program

• Transformations are ‘correctness-preserving’ so it is straightforward to show that the

program conforms to its specification

• Embodied in the ‘Clean room’ approach to software development

Formal systems development

Requirements Formal Formal Integration and

definition specification transformation system testing
 U_I_C_3_Page 11 of 19
Formal transformations
T1 T2 T3 T4

Formal R1 Executable
R2 R3
specification program

P1 P2 P3 P4

Proofs of transformation correctness

Formal systems development

• Problems
 Need for specialised skills and training to apply the technique
 Difficult to formally specify some aspects of the system such as the user
interface

• Applicability
 Critical systems especially those where a safety or security case must be made
before the system is put into operation
Aspect-Oriented S/W Development
• Nearly all SW has localized features, functions and information content.
• User or customer concerns or needs must be included. These can be high-level
concerns like security or lower-level such as marketing business rules or systemic such
as memory management.
• Aspect-Oriented process is new and still developing.
 U_I_C_3_Page 12 of 19
The Unified Process (UP)
Ela b o r a t io n

Inc e p t io n

c o nst r uc t io n
Release
t r a nsit io n
soft ware increment

p r o d uc t io n
UP Phases
Incept ion Elaborat ion Const ruct ion Transit ion Product ion

Workflows

Requirements

Analys is

Design

Implementation

Test

Support

Iterations #1 #2 #n-1 #n
 U_I_C_3_Page 13 of 19
UP Work Products
Incept ion phase

Elaborat ion phase

Vision document
Init ial use-case model
Init ial project glossary Construction phase
Use-case model
Init ial business case Supplement ary requirement s
Init ial risk assessment . including non-funct ional Design model
Transit ion phase
Project plan, Analy sis model Soft ware component s
phases and it erat ions. Soft ware archit ect ure Deliv ered soft ware increment
Int egrat ed soft ware
Business model, Descript ion. increment Bet a t est report s
if necessary . Execut able archit ect ural General user feedback
Test plan and procedure
One or more prot ot y pes prot ot y pe.
I nc e pt i o
Test cases
n Preliminary design model Support document at ion
Rev ised risk list user manuals
Project plan including inst allat ion manuals
it erat ion plan descript ion of current
adapt ed workflows increment
milest ones
t echnical work product s
Preliminary user manual

Software specification
• The process of establishing what services are required and the constraints on the
system’s operation and development

• Requirements engineering process

 Feasibility study
 Requirements elicitation and analysis
 Requirements specification
 Requirements validation
 U_I_C_3_Page 14 of 19
The Requirements Engineering Process

Feasibility Requirements
study elicitation and
analysis
Requir ements
specification
Feasibility Requirements
report validation
System
models
User and system
requirements

Requirements
document

Software design and implementation

• The process of converting the system specification into an executable system
• Software design
 Design a software structure that realises the specification
• Implementation
 Translate this structure into an executable program
• The activities of design and implementation are closely related and may be inter-
leaved
Analysis Model -> Design Model

Co m p o n e n t -
sc e na r i o- ba se d f l ow- or i e nt e d L e v e l D e sig n
e l e me nt s e l e me nt s
use-cases - text data flow diagrams
use-case diagrams control-flow diagrams
activity diagrams processing narratives
swim lane diagrams
In t e r f a c e D e sig n
Analysis Model

A r c h it e c t u r a l D e sig n
c l a ss- ba se d be ha v i or a l
e l e me nt s e l e me nt s
class diagrams state diagrams
analysis packages sequence diagrams
CRC models D a t a / Cla ss D e sig n
collaboration diagrams

Design Model
 U_I_C_3_Page 15 of 19
Design process activities
• Architectural design
• Abstract specification
• Interface design
• Component design
• Data structure design
• Algorithm design
The Software Design Process
Requirements
specificatio n

Design activities

Architectural Interface Component Data Algorithm

Abstract
design design design structure design
specificatio n
design

Software Data
System Interface Component Algorithm
specificatio n structure
architecture specificatio n specificatio n specificatio n
specificatio n

Design products

Design methods
• Systematic approaches to developing a software design

• The design is usually documented as a set of graphical models

• Possible models
 Data-flow model
 Entity-relation-attribute model
 Structural model
 Object models
Programming and debugging
• Translating a design into a program and removing errors from that program
• Programming is a personal activity - there is no generic programming process
• Programmers carry out some program testing to discover faults in the program
and remove these faults in the debugging process
 U_I_C_3_Page 16 of 19
The debugging process

Locate Design Repair Re-test

error error repair error program

Software validation
• Verification and validation is intended to show that a system conforms to its
specification and meets the requirements of the system customer
• Involves checking and review processes and system testing
• System testing involves executing the system with test cases that are derived from the
specification of the real data to be processed by the system

The Testing Process

Unit
testing
Module
testing
Sub-system
testing
System
testing
Acceptance
testing

Component Integration testing User

testing testing
Testing stages
• Unit testing
 Individual components are tested
• Module testing
 Related collections of dependent components are tested
• Sub-system testing
 Modules are integrated into sub-systems and tested. The focus here should be on
interface testing
 U_I_C_3_Page 17 of 19

• System testing
 Testing of the system as a whole.
 Testing of emergent properties
• Acceptance testing
 Testing with customer data to check that it is acceptable
Testing phases

Requir ements System System Detailed

specification specification design design

System Sub-system Module and

Acceptance
integration integration unit code
test plan
test plan test plan and tess

Acceptance System Sub-system

Service
test integration test integration test

Software evolution
• Software is inherently flexible and can change.

• As requirements change through changing business circumstances,

the software that supports the business must also evolve and change.
System Evolution

Define system Assess existing Propose system Modify

requirements systems changes systems

Existing New
systems system
 U_I_C_3_Page 18 of 19
Automated process support (CASE)
• Computer-aided software engineering (CASE) is software to support software
development and evolution processes

• Activity automation
 Graphical editors for system model development
 Data dictionary to manage design entities
 Graphical UI builder for user interface construction
 Debuggers to support program fault finding
 Automated translators to generate new versions of a program
Case technology

• Case technology has led to significant improvements in the software process

though not the order of magnitude improvements that were once predicted

 Software engineering requires creative thought - this is not readily automatable

 Software engineering is a team activity and, for large projects, much time is
spent in team interactions. CASE technology does not really support these

CASE classification
• Classification helps us understand the different types of CASE tools and
their support for process activities
• Functional perspective
 Tools are classified according to their specific function
• Process perspective
 Tools are classified according to process activities that are supported
• Integration perspective
 Tools are classified according to their organisation into integrated units
 U_I_C_3_Page 19 of 19
CASE integration
• Tools
 Support individual process tasks such as design consistency checking, text
editing, etc.
• Workbenches
 Support a process phase such as specification or design, Normally include a
number of integrated tools
• Environments
 Support all or a substantial part of an entire software process. Normally include
several integrated workbenches
Tools, workbenches, environments

CASE
technology

Tools Workbenches Environments

File Integrated Process-centred

Editors Compilers
comparators environments environments

Analysis and
Programming Testing
design

Multi-method Single-method General-purpose Language-specific

workbenches workbenches workbenches workbenches