Chapter 4
Software Processes
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 1
Software Processes

Coherent sets of activities for specifying,
designing, implementing and testing
software systems.
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 2
Objectives




To introduce software process models.
To describe a number of generic process models and
when they may be used.
To outline lower-level process models for (1)
requirements engineering, (2) software development,
(3) testing, and (4) evolution.
To introduce CASE technology to support software
process activities
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 3
Topics covered







Software process models
Process iteration
Software specification
Software design and implementation
Software verification & validation
Software evolution
Automated process support
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 4
The software process

A process is a structured set of activities
required to develop a software system, e.g.
•
•
•
•


Specification
Design
Validation / Verification
Evolution
A process model is an abstract representation
of a process. It presents a description of a
process from some particular perspective
Models should be as simple as possible, but no
simpler. – A. Einstein
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 5
The software process

A process is a structured set of activities
required to develop a software system, e.g.
•
•
•
•


Specification
Design
Validation / Verification
Evolution
[struhk-cherd] –adjective; having and
manifesting a clearly defined structure
or organization.
A process model is an abstract representation
of a process. It presents a description of a
process from some particular perspective
Models should be as simple as possible, but no
simpler. – A. Einstein
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 6
Generic software process models

The Waterfall Model – separate and distinct phases of
specification and development.

Traditionally: not iterative.
Evolutionary Development – specification and development
are interleaved.

Reuse-Based Development – e.g., component-based: the
system is assembled from existing components.
(And, at no additional cost: Incremental, eXtreme, and Spiral.)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 7
Waterfall model (W. Royce)
Requirements
definition
System and
software design
Implementation
and unit testing
Integr ation and
system testing
Operation and
maintenance
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 8
Waterfall model problems



Inflexible partitioning of the project into distinct stages
makes it difficult to respond to changing customer
requirements.
Thus, this model is only appropriate when the
requirements are well-understood (to begin with).
--------------------------------------------In general, the drawback of the waterfall model is the
difficulty of accommodating change after the process is
underway.
Can we say anything good about the Waterfall model?
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 9
Evolutionary development

Exploratory Development *– objective is to work with
customers and to evolve a final system from an initial outline
specification. (Development starts with well-understood parts of
system.) important theme in Agile Development

Throw-Away Prototyping – objective is to understand the
system requirements. (Prototyping focuses on poorly understood
requirements.)
* also known as exploratory programming, or evolutionary prototyping
(cont'd)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 10
Evolutionary development
Concurr ent
activities
Outline
description
Specification
Initial
version
Development
Intermediate
versions
Validation
Final
version
trash
(cont'd)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 11
customer
Evolutionary development

Potential problems
•
•
•

Lack of process visibility. (via documents: c.f. Waterfall model)
Final version/prototype is often poorly structured.
Special skills (e.g., in languages for rapid prototyping) may
be required. – working effectively with people
Applicability
•
•
•
For small or medium-size interactive systems.
For parts of large systems (e.g., the user interface).
For short-lifetime systems. (In the case of exploratory
development – why?)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 12
Reuse-oriented development


Based on systematic (as opposed to serendipitous)
reuse of existing software units.
Units may be:
•
•
•
•

Procedures or functions (common for past 40 years)
Components (“component-based development”)
Core elements of an application (“application family”)
Entire applications -- COTS (Commercial-off-the-shelf)
systems
May also be based on use of design patterns.
(cont'd)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 13
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.
(cont'd)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 14
Reuse-oriented development
(what’s available?)
Requirements
specification
Component
analysis
Requirements
modification
System design
with reuse
Development
and integration
©Ian Sommerville 2000
Software Engineering, Chapter 4
System
validation
Slide 15
Process iteration




For large systems, requirements ALWAYS evolve in the
course of a project.
Thus, process iteration is ALWAYS part of the process.
Iteration can be incorporated in any of the generic
process models. (but not in keeping with spirit of Waterfall…)
Two other approaches that explicitly incorporate
iteration:
•
•
Incremental delivery
Spiral development (Boehm)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 16
Incremental delivery



Rather than deliver the system as a single unit, the
development and delivery is broken down into
increments, each of which incorporates part of the
required functionality.
User requirements are prioritized and the highest
priority requirements are included in early
increments.
Once the development of an increment is started, its
requirements are “frozen” while requirements for
later increments can continue to evolve.
(Compromise between Waterfall & Evolutionary development)
(cont'd)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 17
Incremental delivery
Define outline
requirements
Develop system
increment
Design system
architecture
Assign requirements
to increments
Integrate
increment
Valida te
increment
Valida te
system
Final
system
System incomplete
(cont'd)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 18
Incremental delivery advantages




Useful functionality is delivered with each increment,
so customers derive value early.
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. (they're subject to more “validation” steps)
(cont'd)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 19
Potential problem with incremental
delivery

Requirements may NOT be partitionable into standalone increments. (e.g., a compiler)
(A generalization of incremental delivery,
known as Incremental Software Development,
is discussed in Chap. 17, Rapid Software
Development.)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 20
Extreme programming (Beck ’99)

Recent evolution of incremental approach based on
•
•
•
•



Development and delivery of very small increments of
functionality
Significant customer involvement in process
Constant code improvement
Egoless, pair-wise programming
NOT document-oriented
Gaining acceptance in some small (and now medium sized)
organizations.
Representative of the “Agile” development paradigm.
www.agilealliance.org
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 21
Boehm’s spiral development




Process is represented as a spiral rather than a
sequence of activities.
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.
Explicitly incorporates risk assessment and resolution
throughout the process.
(cont'd)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 22
Spiral model of the software
process
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
©Ian Sommerville 2000
Integration
and test plan
Prototype 3
Prototype 2
Risk
analysis Prototype 1
Operational
protoype
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
Software Engineering, Chapter 4
Slide 23
Spiral model quadrants

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.
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 24
Models for (lower level) fundamental
process activities




Software specification/requirements engineering (RE)
Software development (design and implementation)
Software verification and validation
Software evolution
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 25
Software specification / RE


The process of establishing what services are required
and the constraints on the system’s operation and
development.
Requirements Engineering (RE) process:
•
•
•
•
Feasibility (technical and otherwise) study
Requirements elicitation and analysis
Requirements specification (documentation)
Requirements validation
(cont'd)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 26
The requirements engineering
process
Feasibility
study
Requirements
elicitation and
analysis
Requir ements
specification
Feasibility
report
Requirements
validation
System
models
User and system
requirements
Requirements
document
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 27
Software design and
implementation

The process of producing an executable system
based on the specification
•
Software design – design a software structure that realizes
the specification.
•
Implementation – translate this structure into an executable
program.

The activities of specification, design, and
implementation are closely related and may be
interleaved.
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 28
Design process activities

“High-Level” design activities
•
•
•

Architectural design – subsystems and their relationships are
identified
Abstract specification – of each sub-system’s services
Interface design – among sub-systems
“Low-Level” design activities
•
•
•
Component design – services allocated to different
components and their interfaces are designed
Data structure design
Algorithm design
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 29
The 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
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 30
Design methods



Systematic (canned) approaches to developing a
software design. the cookbook approach…
The design is usually documented as a set of graphical
models.
Possible models:
•
•
•
•
Data-flow model
Entity-relation-attribute model
Structural model
Object models
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 31
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 (“unit testing”), and remove faults in the
debugging process.
(Compare this model with Cleanroom SE.)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 32
The debugging process
Locate
error
©Ian Sommerville 2000
Design
error repair
Software Engineering, Chapter 4
Repair
error
Re-test
program
Slide 33
Software verification & validation



Verification and validation (V&V) determines whether
or not a system (1) conforms to its specification and
(2) meets the needs of the customer.
Involves inspection / review processes and (machinebased) testing.
Testing involves executing system elements with test
cases that are derived from specifications and/or
program logic.
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 34
Testing stages (topic 14)



Unit/Module testing - individual function/procedures are tested
(unit/module) Integration testing
Component testing - functionally related units/modules are
tested together


(component) Integration testing
Sub-system/product testing - sub-systems or products are
tested


(product/sub-system) Integration testing
System testing - testing of the system as a whole, including user
acceptance test
cf “traditional” (i.e., waterfall) model of testing…
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 35
Waterfall model (W. Royce)
Requirements
definition
System and
software design
Implementation
and unit testing
Integr ation and
system testing
Operation and
maintenance
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 36
Software evolution



Software is inherently flexible and subject to change.
As requirements change through changing business
circumstances, the software that supports the business
must also evolve and change.
The distinction between development and evolution is
increasingly irrelevant as fewer and fewer systems are
completely new.
(cont'd)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 37
System evolution
Define system
requirements
e.g., change
requests
Assess existing
systems
Propose system
changes
Existing
systems
Modify
systems
New
system
(cont'd)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 38
The Rational Unified Process


A modern process model derived from the work on the
UML and associated process.
Normally described from 3 perspectives
•
•
•
A dynamic perspective that shows phases over time;
A static perspective that shows process activities;
A practice perspective that suggests good practice.
A hybrid process model that brings together elements from
all of the generic process models…represents a new
generation of generic processes
(cont'd)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 39
The Rational Unified Process


A modern process model derived from the work on the
UML and associated process.
Normally described from 3 perspectives
•
•
•
A dynamic perspective that shows phases over time;
A static perspective that shows process activities;
A practice perspective that suggests good practice.
A hybrid process model that brings together elements from
all of the generic process models…represents a new
generation of generic processes
(cont'd)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 40
RUP phase model
Phase iteration
Inception
Elaboration
Cons truction
Transition
cf Waterfall Model: RUP phases are more closely
related to business rather than technical concerns.
(cont'd)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 41
RUP phases

Inception
•

Elaboration
•

Develop an understanding of the problem domain and the
system architecture.
Construction
•

Establish the business case for the system.
System design, programming and testing.
Transition
•
Deploy the system in its operating environment.
(cont'd)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 42
The Rational Unified Process


A modern process model derived from the work on the
UML and associated process.
Normally described from 3 perspectives
•
•
•
A dynamic perspective that shows phases over time;
A static perspective that shows process activities;
A practice perspective that suggests good practice.
A hybrid process model that brings together elements from
all of the generic process models…represents a new
generation of generic processes
(cont'd)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 43
Static workflows (process
activities)
Wor kflow
Description
Busines s modelli ng
The bu sines s processes are modell ed using bu sines s use cases.
Requi rements
Actors who interact wit h the system are identified and use cases are
deve loped to model t he system requirements.
Ana lysis and de sign
A design model is created and do cumented using a rchit ectural
models, componen t models , object models and sequence mod els.
Implementation
The co mponents in the system are im plemented and structured into
im plementation sub- systems . Automatic code gen eration from design
models helps accelerate this process.
Test
Testing is an it erative p rocess that is carried out in con junc tion wit h
im plementation. System testing foll ows the completion of the
im plementation.
Dep loyment
A produc t release is created, dist ributed to us ers and install ed in their
workplace.
Confi guration and
chang e manag ement
This supporting workflow managed change s to the system (see
Chapter 29).
Project manag ement
This supporting workflow manage s the system deve lopment (see
Chapter 5).
Envi ronment
This workfl ow is concerned wit h ma king appropria te software tools
ava il able to the soft ware deve lopment team.
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 44
The Rational Unified Process


A modern process model derived from the work on the
UML and associated process.
Normally described from 3 perspectives
•
•
•
A dynamic perspective that shows phases over time;
A static perspective that shows process activities;
A practice perspective that suggests good practice.
A hybrid process model that brings together elements from
all of the generic process models…represents a new
generation of generic processes
(cont'd)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 45
RUP good practice




Develop software iteratively
Manage requirements
Use component-based architectures
Visually model software (e.g., UML packages, sequence
models, state machine models)


Verify software quality
Control changes to software
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 46
Automated process support
(CASE)


Computer-aided software engineering (CASE) is
software to support software development and evolution
processes.
Activity automation (examples):
•
•
•
•
•
Graphical editors for system model development
Data dictionaries for name management
GUI builders for user interface construction
Debuggers to support program fault finding
Automated translators to generate new versions of a program
(e.g., restructuring tools)
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 47
CASE technology

CASE technology has led to significant improvements
in the software process, but not the order of
magnitude improvements that were once predicted.
•
•
Software engineering involves design activity requiring
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 support this well.
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 48
CASE classification




Classification helps us understand the different types of
CASE tools / systems 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 – CASE systems are classified
according to their breadth of support for the software
process.
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 49
Functional tool classification
TOOL TYPES:
Planning tools
Editing tools
Change mgmt tools
Configuration mgmt tools
Prototyping tools
Method-support tools
Language-processing tools
Program analysis tools
Testing tools
Debugging tools
Documentation tools
Reengineering tools
©Ian Sommerville 2000
EXAMPLES:
PERT tools, estimation tools, spreadsheets
Text editors, diagram editors, word processors
Rqmts traceability tools, change control sys
Version mgmt systems, system building tools
V. high-level langs, user interface generators
Design editors, data dicts, code generators
Compilers, interpreters
Cross ref generators, static/dynamic analyzers
Test data generators, file comparators
Interactive debugging systems
Page layout programs, image editors
Cross-ref systems, program restructuring systems
Software Engineering, Chapter 4
Slide 50
Reengineering tools
Testing tools
Debugging tools
Program analysis tools
Language-processing
tools
Method support tools
Prototyping tools
Configuration
management tools
Change management tools
Documentation tools
Editing tools
Planning tools
Specification
Design
Implementation
Verification
and
Validation
Activity-based classification
Actually far more lower CASE tools than upper CASE
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.
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 52
Tools, workbenches,
environments
CASE
technology
Tools
Editors
Compilers
Workbenches
File
comparators
Analysis and
design
Multi-method
workbenches
©Ian Sommerville 2000
Integrated
environments
Programming
Single-method
workbenches
Environments
Testing
General-purpose
workbenches
Software Engineering, Chapter 4
Process-centred
environments
Language-specific
workbenches
Slide 53
Key points




Software processes are the activities involved in
producing and evolving a software system. They are
represented in a software process model.
Fundamental (lower level) activities are specification,
design and implementation, validation & verification,
and evolution.
Generic models are very general process models
representing different approaches to development.
Iterative process models describe the software
process as a cycle of activities.
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 54
Key points (cont’d)





Requirements engineering is the process of
establishing what services are required and the
constraints on the system’s operation and
development.
Design and implementation processes produce an
executable system based on the specification.
V&V involves checking that the system meets its
specification and satisfies user needs.
Evolution is concerned with modifying the system
after it is placed in use.
CASE technology supports software process
activities.
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 55
Chapter 4
Software Processes
©Ian Sommerville 2000
Software Engineering, Chapter 4
Slide 56