An Overview of
Software Processes
Reference: Software Engineering, by
Ian Sommerville, 6th edition, Chapter 3
CMSC 345, Version 1/03
Objectives


To introduce the general phases of the
software (development) life cycle
To describe various generic software
process models and their pros and cons
CMSC 345, Version 1/03
Software Life Cycle

The phases necessary to develop and
maintain a software system. These phases
include:
•
•
•
•
•

Requirements (Specification)
Design
Implementation (Coding)
Testing (Validation)
Maintenance (Evolution)
A software process model is an abstract
representation of how these phases can be
addressed.
CMSC 345, Version 1/03
Requirements


The process of establishing
• what services are required of the
system
• the constraints on the system’s
operation and development
The “what” of the software life cycle
CMSC 345, Version 1/03
A Generic Requirements Process
Feasibility
study
Requirements
elicitation and
analysis
Requir ements
specification
Feasibility
report
Requirements
validation
System
models
User and system
requirements
Requirements
document
CMSC 345, Version 1/03
Design


The process of converting the system
specification (requirements) into a software
structure that realizes that specification
The “how” of the software life cycle
CMSC 345, Version 1/03
A Generic Software Design
Process
Requirements
specification
Design activities
Architectural
design
Abstract
specification
Interface
design
Component
design
Data
structure
design
Algorithm
design
Sy stem
architecture
Software
specification
Interface
specification
Component
specification
Data
structure
specification
Algorithm
specification
Design products
CMSC 345, Version 1/03
Implementation




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.
The activities of design and implementation
are closely related and may be interleaved.
CMSC 345, Version 1/03
Testing



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.
CMSC 345, Version 1/03
A Generic Testing Process
Unit
testing
Module
testing
Sub-system
testing
System
testing
Acceptance
testing
Component
testing
CMSC 345, Version 1/03
Integration testing
User
testing
V-Model of Test Planning
Requir ements
specification
System
specification
System
integration
test plan
Acceptance
test plan
Service
System
design
Acceptance
test
CMSC 345, Version 1/03
Detailed
design
Sub-system
integration
test plan
System
integration test
Sub-system
integration test
Module and
unit code
and tess
System Maintenance



Software is inherently flexible and can change
(as opposed to hardware).
In the past, there has been a demarcation
between development and evolution
(maintenance). This is increasingly irrelevant
as fewer and fewer systems are completely
new.
Software engineering should be thought of as
an evolutionary process where software is
continually changed over its lifetime in
response to customer needs.
CMSC 345, Version 1/03
Software Process Models




Waterfall model (Royce, 1970)
Prototyping
• Throwaway
• Evolutionary
Incremental development
Spiral model (Boehm, 1988)
CMSC 345, Version 1/03
Waterfall Model
Requirements
Design
Implementation
Testing
Maintenance
CMSC 345, Version 1/03
Observations


The following phase should not start until the
previous phase has finished.
In practice,
•
•

Phases overlap
May return to a previous phase
Still widely used, especially on very large
projects
CMSC 345, Version 1/03
Waterfall Model Pros and Cons
Pros
Cons
CMSC 345, Version 1/03
Prototyping
Requirements
Design
Design
Implementation
Implementation
Testing
Testing
Maintenance
CMSC 345, Version 1/03
Observations




Used for requirements elicitation and
validation
A “working” model (prototype) of the final
system is developed during requirements
Is an iterative process
Prototype can be thrown away or evolved
into the final system (evolutionary
prototyping)
CMSC 345, Version 1/03
Prototyping Pros and Cons
Pros
Cons
CMSC 345, Version 1/03
Throwaway vs. Evolutionary
Throwaway pros
Evolutionary pros
CMSC 345, Version 1/03
Incremental Development
Define outline
requirements
Assign requirements
to increments
Develop system
increment
Valida te
increment
Design system
architecture
Integrate
increment
Valida te
system
Final
system
System incomplete
CMSC 345, Version 1/03
Observations



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.
Is an iterative process
CMSC 345, Version 1/03
Incremental Pros and Cons
Pros
Cons
CMSC 345, Version 1/03
Spiral Model
Determine objectives
alternatives and
constraints
Risk
analysis
Evaluate alternatives
identify, resolve risks
Risk
analysis
Risk
analysis
REVIEW
Requirements plan
Life-cycle plan
Development
plan
Plan next phase
CMSC 345, Version 1/03
Integration
and test plan
Prototype 3
Prototype 2
Operational
protoype
Risk
analysis Prototype 1
Simulations, models, benchmarks
Concept of
Operation
S/W
requirements
Requirement
validation
Product
design
Detailed
design
Code
Unit test
Design
V&V
Integr ation
test
Acceptance
test
Develop, verify
Service
next-level product
Observations





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.
Uses prototyping
CMSC 345, Version 1/03
Things to Think About


What about modifying existing software?
What about using existing software?
•
•
In-house modules
COTS (Commercial Off-The-Shelf)
CMSC 345, Version 1/03