Chapter 2
Software Processes
Chapter 2 Software Processes
Slide 1
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
Chapter 2 Software Processes
Slide 2
Topics covered







Software process models
Process iteration
Software specification
Software design and implementation
Software verification & validation
Software evolution
Automated process support
Chapter 2 Software Processes
Slide 3
[struhk-cherd] –adjective; having a
clearly defined structure or organization.
The software process


A process is a structured set of activities required to
develop a software system.
Many different software processes, but all involve:
•
•
•
•


Specification – defining what the system should do;
Design & implementation;
Validation – checking that it does what the customer wants;
Evolution – changing the system in response to changing
customer needs.
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
Chapter 2 Software Processes
Slide 4
[struhk-cherd] –adjective; having a
clearly defined structure or organization.
The software process


A process is a structured set of activities required to
develop a software system.
Many different software processes, but all involve:
•
•
•
•


Specification – defining what the system should do;
Design & implementation;
Validation – checking that it does what the customer wants;
Evolution – changing the system in response to changing
customer needs.
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
Chapter 2 Software Processes
Slide 5
Plan-driven and agile processes




Plan-driven processes: all of the process activities are
planned in advance and progress is measured against
this plan.
Agile processes: planning is incremental and it is easier
to change the process to reflect changing customer
requirements.
In practice, most practical processes include elements of
both plan-driven and agile approaches.
There are no right or wrong software processes.
Chapter 2 Software Processes
Slide 6
Generic software process models

The Waterfall Model – plan-driven model; separate and distinct
phases of specification and development.

Traditionally: not iterative.
Incremental Development – specification, development, &
validation are interleaved; may be plan-driven or agile.

Reuse-Based Development – e.g., component-based: the
system is assembled from existing components; may be plandriven or agile.

In practice, most large systems are developed using a
process that incorporates elements from all of these
models.
(And, at no additional cost: Boehm’s Spiral Model.)
Chapter 2 Software Processes
Slide 7
Waterfall model (W. Royce)
Requirements
definition
System and
software design
Implementation
and unit testing
Integr ation and
system testing
Operation and
maintenance
Chapter 2 Software Processes
Slide 8
Waterfall model phases

There are separate phases in the waterfall model:
•
•
•
•
•


Requirements analysis and definition
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
The waterfall model is mostly used for large systems
engineering projects where a system is developed at
several sites.
In those circumstances, the plan-driven nature of the
waterfall model helps coordinate the work.
Chapter 2 Software Processes
Slide 9
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).
Few business systems have stable requirements.
--------------------------------------------In general, the drawback of the waterfall model is the
difficulty of accommodating change after the process is
underway.
Chapter 2 Software Processes
Slide 10
Incremental development
Concurr ent
activities
Outline
description
Specification
Initial
version
Development
Intermediate
versions
Validation
Final
version
(cont'd)
Chapter 2 Software Processes
Slide 11
Incremental development benefits

The cost of accommodating changing customer
requirements is reduced - amount of analysis and
documentation that has to be redone is much less than is
required with the waterfall model.

It is easier to get customer feedback - customers can
comment on demonstrations of the software and see how much
has been implemented.

More rapid delivery and deployment of useful
software to the customer is possible - customers are
able to use and gain value from the software earlier than is
possible with a waterfall process.
Chapter 2 Software Processes
Slide 12
Incremental development problems

Lack of process visibility - managers need regular
deliverables to measure progress. If systems are
developed quickly, it is not cost-effective to produce
documents that reflect every version of the system.

System structure tends to degrade as new
increments are added - unless time and money is spent
on refactoring to improve the software, regular change
tends to corrupt its structure. Incorporating further
software changes becomes increasingly difficult and
costly.
Chapter 2 Software Processes
Slide 13
Reuse-oriented software engineering

Based on systematic (as opposed to serendipitous)
reuse - systems are integrated from existing components or COTS
(Commercial-off-the-shelf) systems.

Process stages
•
•
•
•

Component analysis (what’s available?)
Requirements modification (why?)
System design with reuse
Development and integration
Reuse is now the standard approach for building many
types of business systems.
(cont'd)
Chapter 2 Software Processes
Slide 14
Reuse-oriented software engineering
(what’s available?)
Requirements
specification
Component
analysis
Requirements
modification
System design
with reuse
Development
and integration
System
validation
(cont'd)
Chapter 2 Software Processes
Slide 15
Types of reusable software components



Web services that are developed according to service
standards and which are available for remote invocation.
Collections of objects that are developed as a
package to be integrated with a component framework
such as .NET or J2EE.
Stand-alone software systems (COTS) that are
configured for use in a particular environment.
Chapter 2 Software Processes
Slide 16
Process activities


Real software processes are interleaved sequences of
technical, collaborative and managerial activities with
the overall goal of specifying, designing, implementing
and testing a software system.
The four basic process activities of specification,
development, validation and evolution are organized
differently in different development processes. In the
waterfall model, they are organized in sequence; in
incremental development they are interleaved.
Chapter 2 Software Processes
Slide 17
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)
Chapter 2 Software Processes
Slide 18
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
Chapter 2 Software Processes
Slide 19
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.
Chapter 2 Software Processes
Slide 20
Design activities




Architectural design: identify overall structure of system,
principal components (sometimes called sub-systems or
modules), their relationships, and how they are
distributed.
Interface design: define the interfaces between system
components.
Component design: design how each system component
will operate.
Database design: design the system data structures and
how these are to be represented in a database.
Chapter 2 Software Processes
Slide 21
Software verification & validation



Verification and validation (V&V) determines whether or
not a system (1) conforms to its specification and (2)
meets the requirements of the customer.
Involves checking processes (e.g., inspections/reviews
and program (machine-based) testing.
Testing is the most commonly used V&V activity and
involves executing program elements with test cases
that are derived from specifications and/or program
logic.
Chapter 2 Software Processes
Slide 22
Testing stages


Development or component testing
•
Individual components are tested independently;
•
Components may be functions or objects or coherent
groupings of these entities.
System testing
•

Testing of the system as a whole. Testing of emergent
properties is particularly important.
Acceptance testing
•
Testing with customer data to check that the system
meets the customer’.s needs
Chapter 2 Software Processes
Slide 23
Software evolution (maintenance)



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)
Chapter 2 Software Processes
Slide 24
Software evolution (maintenance)
Define system
requirements
e.g., change
requests
Assess existing
systems
Propose system
changes
Existing
systems
Modify
systems
New
system
Chapter 2 Software Processes
Slide 25
Coping with change


Change is inevitable in all large software projects.
•
Business changes lead to new and changed system
requirements.
•
New technologies open up new possibilities for improving
implementations.
•
Changing platforms require application changes.
Change costs include both rework (e.g. re-analyzing
requirements) and the cost of implementing new
functionality.
Chapter 2 Software Processes
Slide 26
Reducing the costs of rework

Change avoidance: process includes activities that can
anticipate possible changes before significant rework is
required.
•

For example, a prototype system may be developed to
stimulate user/stakeholder abticipation.
Change tolerance: process is designed so that changes
can be accommodated at relatively low cost.
•
•
Proposed changes may be implemented in increments that
have not yet been developed.
Information hiding techniques may be employed.
Chapter 2 Software Processes
Slide 27
Software prototyping
Chapter 2 Software Processes
Slide 28
What is prototyping?

An iterative process emphasizing:
•
Rapid development
•
Concreteness and Evaluative use (a “real system” is
developed and presented to real users for
evaluation)
•
Consideration of alternatives
•
Feedback
•
Modification
Chapter 2 Software Processes
Slide 29
General Prototyping process
What to include & what
NOT to include.
Establish
prototype
objectives
Define
prototype
functionality
Develop
prototype
Evaluate
prototype
Prototyping
plan
Outline
definition
Executable
prototype
Evaluation
report
Chapter 2 Software Processes
Slide 30
Uses of prototypes

Principal use is to help customers and
developers better understand system
requirements.
•
•
Experimentation stimulates anticipation of how
a system could be used.
Attempting to use functions together to
accomplish some task can easily reveal
requirements problems.
(Cont’d)
Chapter 2 Software Processes
Slide 31
Uses of prototypes (cont’d)

Other potential uses:
1. Evaluating proposed solutions for feasibility
(Experimental Prototyping)
2. Develop and evaluate UI designs
3. “Back-to-back” testing
4. Training users before system delivery

Prototyping is most often undertaken as a
risk reduction activity.
Chapter 2 Software Processes
Slide 32
Classifying prototypes




By purpose:
• Throw-away prototyping – to elicit and validate
requirements
• Experimental prototyping – to evaluate proposed
solutions for feasibility, performance, etc.
horizontal vs. vertical (breadth vs. depth)
mockups vs. breadboards (form vs. function)
“Wizard of Oz” prototyping (Turing test reversed)
Chapter 2 Software Processes
Slide 33
Throw-away prototyping
Elicit/validate REQMTS
Outline
requirements
Develop
prototype
Evaluate
prototype
Specify
system
Reusable
components
Develop
software
Validate
system
Chapter 2 Software Processes
Delivered
software
system
Slide 34
Classifying prototypes




By purpose:
• Throw-away prototyping – to elicit and validate
requirements
• Experimental prototyping – to evaluate proposed
solutions for feasibility, performance, etc.
horizontal vs. vertical (breadth vs. depth)
mockups vs. breadboards (form vs. function)
“Wizard of Oz” prototyping (Turing test reversed)
Chapter 2 Software Processes
Slide 35
Classifying prototypes




By purpose:
• Throw-away prototyping – to elicit and validate
requirements
• Experimental prototyping – to evaluate proposed
solutions for feasibility, performance, etc.
horizontal vs. vertical (breadth vs. depth)
mockups vs. breadboards (form vs. function)
“Wizard of Oz” prototyping (Turing test reversed)
Chapter 2 Software Processes
Slide 36
Vertical prototype
high
F
I
d
e
l
I
t
y
points of
comparable effort
Horizontal prototype
low
few
Number of features
many
Classifying prototypes




By purpose:
• Throw-away prototyping – to elicit and validate
requirements
• Experimental prototyping – to evaluate proposed
solutions for feasibility, performance, etc.
horizontal vs. vertical (breadth vs. depth)
mockups vs. breadboards (form vs. function)
“Wizard of Oz” prototyping (Turing test reversed)
Chapter 2 Software Processes
Slide 40
Quin Tech “Self-service check-in and
baggage drop-off design”
“The design was tested through a full-scale mock-up.”
Chapter 2 Software Processes
Slide 41
Electronic circuit on a breadboard (REUK.co.uk)
“There is no need to solder anything, and the components can be moved
around and the circuit modified thousands of times without damaging parts.”
Chapter 2 Software Processes
Slide 42
Classifying prototypes




By purpose:
• Throw-away prototyping – to elicit and validate
requirements
• Experimental prototyping – to evaluate proposed
solutions for feasibility, performance, etc.
horizontal vs. vertical (breadth vs. depth)
mockups vs. breadboards (form vs. function)
“Wizard of Oz” prototyping (Turing test reversed)
Chapter 2 Software Processes
Slide 43
The Wizard of Oz exposed…
“The truth is the Wizard was an illusion created by a man hidden behind a curtain.”
Chapter 2 Software Processes
Slide 44
Prototyping versus simulation

What’s the difference between prototyping and
simulation?
Chapter 2 Software Processes
Slide 45
Throw-away prototype delivery
?


Developers may be pressurized to deliver a throwaway prototype as the final system.
This is problematic...
• It may be impossible to meet non-functional
requirements.
• The prototype is almost certainly undocumented.
• The system may be poorly structured and
therefore difficult to maintain.
• Normal organizational quality standards may not
have been applied.
Chapter 2 Software Processes
Slide 46
No, no, no! I won’t
deliver the prototype to
you!
User Mgmt
Developer
Air Tank
Pressurizing the
Developer
Implementation techniques

Various techniques may be used for developing
prototypes:
•
•
•


Dynamic high-level languages
Database programming (RAD)
Component and application assembly
These are not mutually exclusive – they are
often used together.
Visual programming is also an inherent part of
most prototype development systems.
Chapter 2 Software Processes
Slide 48
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)
Chapter 2 Software Processes
Slide 49
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)
Chapter 2 Software Processes
Slide 50
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)
Chapter 2 Software Processes
Slide 51
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.)
Chapter 2 Software Processes
Slide 52
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
Chapter 2 Software Processes
Slide 53
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)
Chapter 2 Software Processes
Slide 54
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
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
Chapter 2 Software Processes
Slide 55
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.
Chapter 2 Software Processes
Slide 56
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)
Chapter 2 Software Processes
Slide 57
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)
Chapter 2 Software Processes
Slide 58
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)
Chapter 2 Software Processes
Slide 59
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
(cont'd)
Chapter 2 Software Processes
Slide 60
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.
Chapter 2 Software Processes
Slide 61
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)
Chapter 2 Software Processes
Slide 62
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.
Chapter 2 Software Processes
Slide 63
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.
Chapter 2 Software Processes
Slide 64
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
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
Chapter 2 Software Processes
Slide 65
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
Activity-based classification
Implementation
Verification
and
Validation
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.
Chapter 2 Software Processes
Slide 67
Tools, workbenches,
environments
CASE
technology
Tools
Editors
Compilers
Workbenches
File
comparators
Analysis and
design
Multi-method
workbenches
Integrated
environments
Programming
Single-method
workbenches
Environments
Testing
General-purpose
workbenches
Chapter 2 Software Processes
Process-centred
environments
Language-specific
workbenches
Slide 68
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.
Chapter 2 Software Processes
Slide 69
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.
Chapter 2 Software Processes
Slide 70