Chapter 3

Software Processes

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 1

Software Processes

 Coherent sets of activities for specifying,

designing, implementing and testing
software systems.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 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, 6th edition. Chapter 3 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, 6th edition. Chapter 3 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, 6th edition. Chapter 3 Slide 5

Generic software process models
 The Waterfall Model – separate and distinct phases of
specification and development. Traditionally: not iterative.(memisahkan dan
membedakan fase spesifikasi dan devolopment)

 Evolutionary Development – specification and development

are interleaved. (antara spesifikasi dan devolopment akan saling
bergantian)
 Formal Systems Development – a mathematical system
model is formally (or informally) transformed to an implementation.
 Reuse-Based Development – the system is assembled from
existing components. (sistem yg dibangun menyertakan berbagai
komponen yg sudah ada)

(And, at no additional cost: Incremental, eXtreme, and Spiral.)

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 6

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, 6th edition. Chapter 3 Slide 7

Waterfall model problems
 Inflexible partitioning of the project into distinct stages
makes it difficult to respond to changing customer
requirements. (pembagiannya kaku sehingga sistem
sulit merespon kebutuhan dari pengguna)
 Thus, this model is only appropriate when the
requirements are well-understood (to begin with).(perubahan
kebutuhan sistem harus di ajukan setelah software selesai)
---------------------------------------------
 In general, the drawback of the waterfall model is the
difficulty of accommodating change after the process is
underway. (akibat model ini hanya cocok untuk sistem
yg kebutuhannya sudah jelas.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 8
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 (prototipe yg tujuannya
melibatkan dengan custumer utk menghasilkan sistem akhir. Hal ini dibuat
berdasarkan bagian sistem yg diketahui dgn baik.
 Throw-Away Prototyping – objective is to understand the
system requirements. (Prototyping focuses on poorly understood
requirements.)
• (Berfokus pada kebutuhan yg tidak ddiketahui dengan jelas)
* also known as exploratory programming, or evolutionary prototyping

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 9

Evolutionary development
Concurr ent
activities

Initial
Specification
version

Outline Intermediate
Development
description versions

Final customer
Validation
version

trash

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 10

Evolutionary development
 Potential problems
• Lack of process visibility. (via documents: c.f. Waterfall
model)(tidak bisa dipastikan difase mana)
• Final version/prototype is often poorly structured.(prototipe
yg dihasilkan kurang tertruktur)
• Special skills (e.g., in languages for rapid prototyping) may
be required. -- working effectively with people (membutuhkan
skill khusus)
 Applicability
• For small or medium-size interactive systems.(sistem yg
kecil atau medium)
• For parts of large systems (e.g., the user interface).
• For short-lifetime systems. (In the case of exploratory
development – why?) (sistem penggunaan jangka pendek)
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 11
Formal systems development
 Based on the transformation of a mathematical
specification (through possibly several different representations) to
an executable program. (membangun sistem bermula
dari matematika )
 Transformations are “correctness-preserving” so it is
possible to show that the program conforms to its
specification.(sulit menentukan spesifikasi sistem)
 Embodied in Mills’ “Cleanroom” approach to software
development.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 12

Formal systems development

Code Generator?

Requirements Formal Formal Integration and

definition specification transformation system testing

Not realistic, unless “Formal specification” is

source code…

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 13

Formal transformations
Formal transformations
T1 T2 T3 T4

Formal R1 Executable
R2 R3
specification program

P1 P2 P3 P4

Proofs of transformation correctness

(futuristic…)

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 14

Formal systems development
 Problems
• Need for specialized skills and training to apply the
technique.(memerlukan skill khusus)
• Difficult to formally specify some aspects of the system
such as the user interface (thus, focus is usually limited
to functional requirements).(sulit menentukan
spesifikasi sistem untuk aspek tertentu)
 Applicability
• Critical systems, especially those where a safety or
security case must be made before the system is put
into operation.( sistem kritis: sistem khusus
keamanannya jadi prioritas utama)
• Critical parts of large systems.(membagun sistem kritis
yg besar)
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 15
Reuse-oriented developmen
(pembangunan sistem berbasis daur ulang)

 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( seluruh aplikasi) -- COTS (Commercial-off-
the-shelf) systems
 May also be based on use of design patterns.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 16

Reuse-oriented development
• Process stages: (tahapan proses)
• Reusable software analysis ( analisa software ) (what’s
available?)
• Requirements modification (memodifikasi persyaratan– why?
• System design with reuse (design sistem yg baru)
• Development and integration (dibangun dan diintegrasikan)
 This approach is becoming more important, but
experience is still limited.

“Software Repositories” research was a major DoD thrust in the late 80’s.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 17

Reuse-oriented development

Requirements Component Requirements System design

specification analysis modification with reuse

Development System
and integration validation

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 18

Process iteration
 For large systems, requirements ALWAYS evolve in the
course of a project.(intensitas perubahannya tinggi)
 Thus, process iteration is ALWAYS part of the process.
 Iteration can be incorporated in any of the generic
process models. (memerlukan juga model yg lebih
sesuai ) (but not in spirit of Waterfall…)
 Two other approaches that explicitly incorporate
iteration: (dikombinasikan dgn model generic)
• Incremental development (Mills)
• Spiral development (Boehm)

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 19

Mill’s Incremental development
 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.( penyerahan aplikasi software secara bertahap dan mewakili
fungsi tertentu)
 User requirements are prioritised and the highest priority requirements are
included in early increments.(kebutuhan user dirangking sesuai dengan
perioritas)
 Once the development of an increment is started, its requirements are “frozen”
while requirements for later increments can continue to evolve.( siste

(Compromise between Waterfall & Evolutionary development)

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 20

Mill’s 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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 21

Incremental development 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. (subject to more “validation” steps)

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 22

Potential problem with
incremental development
 Requirements may NOT be partitionable into stand-
alone increments. (e.g., a compiler)

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 23

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, 6th edition. Chapter 3 Slide 24
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.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 25

Spiral model of the software
process
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 analysis 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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 26

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, 6th edition. Chapter 3 Slide 27

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, 6th edition. Chapter 3 Slide 28

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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 29

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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 30

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, 6th edition. Chapter 3 Slide 31

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, 6th edition. Chapter 3 Slide 32

The software design process

Requirements
specification

Design activities

Architectural Interface Comp onent Data Algorithm

Abstract
design design design structur
e design
specification
design

Software Data
System Interface Comp onent Algorithm
specification structure
architecture specification specification specification
specification

Design products

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 33

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, 6th edition. Chapter 3 Slide 34

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, 6th edition. Chapter 3 Slide 35

The debugging process

Locate Design Repair Re-test

error error repair error program

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 36

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 (machine-
based) testing.
 Testing involves executing system elements with test
cases that are derived from specifications and/or
program logic.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 37

Testing stages (topic 15)
 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, 6th edition. Chapter 3 Slide 38

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.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 39

 System evolution

Define system Assess existing Propose system Modify

requirements systems changes systems

e.g., change Existing New

requests systems system

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 40

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, 6th edition. Chapter 3 Slide 41

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, 6th edition. Chapter 3 Slide 42

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, 6th edition. Chapter 3 Slide 43

Functional tool classification
Tool type Examples
Pl anning tools PE R Ttools, estima ion t tools,
spreadshee st MS Project
Edi itng tools T ext ed tors,
i diagram editors, word
proc es sors
Chang ema n agement tools Requireme nts tra cea bil tiy too s, l cha nge
control syst ems
Configuration manageme nt tools Ve sr ion mana gement systems, syst em
bu lding
i tools RCS, Make
Prototyping tools Ve yr high-l eve ll angua ges, LISP, 4GL’s
user iterfac
n ege ner ators
Method-support tools Design ed tors,
i data di cti onari es , c ode
ge n rators
e
L angua ge-proc es sing tools Compil ers, inte pr re t rse
Program an alysis tools Cross ref erenc egene ar t ors, st ati c
ana ysers,
l dynami can alysers
T es ti ng tools T es t dat agene ar tors, fil ec omp a ar tors coverage tools
De bugging tools Inte ar c iv
t ed be ugging systems
Do cu me nta iont tools Page ayou l tprograms, ma i g eedit ors
Re- engin ering tools Cross-refe er n ce systems, program re-
struc uring
t systems
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 44
 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, 6th edition. Chapter 3 Slide 46

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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 3 Slide 47

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, 6th edition. Chapter 3 Slide 48

Key points
 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, 6th edition. Chapter 3 Slide 49