Software Processes: ©ian Sommerville 2000 Software Engineering, 6th Edition. Chapter 3 Slide 1

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.

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

Topics covered
 Software process models
 Process iteration
 Software specification
 Software design and implementation
 Software verification & validation
 Software evolution
 Automated process support

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

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.)

Waterfall model (W. Royce)
Requirements
definition
System and
software design
Implementation
and unit testing
Integr ation and

system testing
Operation and
maintenance

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.
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

Concurr ent
activities
Initial
Specification
version
Outline Intermediate
Development
description versions
Final customer
Validation
version
trash

 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)
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.

Code Generator?
Requirements Formal Formal Integration and

definition specification transformation system testing
Not realistic, unless “Formal specification” is

source code…

Formal transformations
Formal transformations
T1 T2 T3 T4
Formal R1 Executable
R2 R3
specification program
P1 P2 P3 P4
Proofs of transformation correctness

(futuristic…)

 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)
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.

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.

Reuse-oriented development
Requirements Component Requirements System design

specification analysis modification with reuse
Development System
and integration validation

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)

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)

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

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)

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

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
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.

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

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.

Models for (lower level) fundamental
process activities
 Software specification/requirements engineering (RE)
 Software development (design and implementation)
 Software verification and validation
 Software evolution

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

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

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.

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

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

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

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.)

The debugging process
Locate Design Repair Re-test

error error repair error program

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.

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

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.

System evolution
Define system Assess existing Propose system Modify

requirements systems changes systems
e.g., change Existing New

requests systems system

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)

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.

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.

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
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.

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

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.

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.

Software Processes: ©ian Sommerville 2000 Software Engineering, 6th Edition. Chapter 3 Slide 1

Uploaded by

Copyright:

Available Formats

Software Processes: ©ian Sommerville 2000 Software Engineering, 6th Edition. Chapter 3 Slide 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Processes: ©ian Sommerville 2000 Software Engineering, 6th Edition. Chapter 3 Slide 1

Uploaded by

Copyright:

Available Formats

Chapter 3

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

 Coherent sets of activities for specifying,

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

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

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

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

 Evolutionary Development – specification and development

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

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

Integr ation and

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

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

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

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

Requirements Formal Formal Integration and

Not realistic, unless “Formal specification” is

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

Proofs of transformation correctness

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

 Based on systematic (as opposed to serendipitous)

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

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

Requirements Component Requirements System design

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

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

(Compromise between Waterfall & Evolutionary development)

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

Define outline Assign requirements Design system

Develop system Valida te Integrate Valida te

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

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

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

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

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

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

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

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

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

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

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

Architectural Interface Comp onent Data Algorithm

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

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

(Compare this model with Cleanroom SE.)

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

Locate Design Repair Re-test

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

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

cf “traditional” (i.e., waterfall) model of testing

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

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

Define system Assess existing Propose system Modify

e.g., change Existing New

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

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

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

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

Program analysis tools