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 Requirements
study elicitation and
analysis
Requir ements
specification
Feasibility Requirements
report 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 acti
vities

Architectur
al Interface Component Data Algorithm
Abstract
design design design structur
e design
specification
design

Software Data
System Interface Component Algorithm
specification structure
architectur
e specification specification specification
specification

Design pr
oducts

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 Integration testing User

testing testing
CMSC 345, Version 1/03
 V-Model of Test Planning

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

CMSC 345, Version 1/03

 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 Assign requirements Design system

requirements to increments architecture

Develop system Valida te Integrate Valida te

increment increment increment 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
Evaluate alternatives
alternatives and identify, resolve risks
constraints Risk
analysis
Risk
analysis
Risk
analysis Opera-
Prototype 3 tional
Prototype 2 protoype
Risk
REVIEW analy sis Proto-
type 1
Requirements plan Simulations, models, benchmarks
Life-cycle plan Concept of
Operation S/W
requirements Product
design Detailed
Requirement design
Development
plan validation Code
Design Unit test
Integration
and test plan V&V Integr ation
Plan next phase test
Acceptance
Service test Develop, verify
next-level product
CMSC 345, Version 1/03
 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