ch4 software processes.ppt

7/24/2019 ch4 Software Processes.ppt

1/50

Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1

Software Processes


2/50


Objectives

To introduce software process models To describe three generic process models and

when they may be used

To describe outline process models forrequirements engineering, softwaredevelopment, testing and evolution

To explain the Rational nified Process model To introduce !"S# technology to support

software process activities


3/50


Topics covered

Software process models

Process iteration

Process activities

The Rational nified Process

!omputer$aided software engineering


4/50


The software process

" structured set of activities required to develop a

software system

% Specification&

% 'esign&

% (alidation&

% #volution)

" software process model is an abstract representation

of a process) *t presents a description of a process

from some particular perspective)


5/50


+eneric software process models

The waterfall model

% Separate and distinct phases of specification anddevelopment)

#volutionary development

% Specification, development and validation areinterleaved)

!omponent$based software engineering

% The system is assembled from existing components) There are many variants of these models e)g) formal

development where a waterfall$lie process is used butthe specification is a formal specification that is refinedthrough several stages to an implementable design)


6/50


-aterfall model

Requirements

defnition

System and

sotware design

Implementation

and unit testing

Integration and

system testing

Operation and

maintenance


7/50Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 7

-aterfall model phases

Requirements analysis and definition System and software design *mplementation and unit testing *ntegration and system testing Operation and maintenance The main drawbac of the waterfall model is

the difficulty of accommodating change afterthe process is underway) One phase has to becomplete before moving onto the next phase)



-aterfall model problems

*nflexible partitioning of the project into distinct stages

maes it difficult to respond to changing customer

requirements)

Therefore, this model is only appropriate when the

requirements are well$understood and changes will be

fairly limited during the design process)

.ew business systems have stable requirements)

The waterfall model is mostly used for large systems

engineering projects where a system is developed at

several sites)




#xploratory development

% Objective is to wor with customers and to evolve

a final system from an initial outline specification)

Should start with well$understood requirementsand add new features as proposed by the

customer)

Throw$away prototyping

% Objective is to understand the systemrequirements) Should start with poorly understood

requirements to clarify what is really needed)




Concurrentactivities

ValidationFinal

version

Development Intermediate

versions

Specifcation

Initial

version

Outlinedescription




Problems

% /ac of process visibility&

% Systems are often poorly structured&

% Special sills 0e)g) in languages for rapidprototyping1 may be required)

"pplicability

% .or small or medium$si2e interactive systems&

% .or parts of large systems 0e)g) the user interface1&

% .or short$lifetime systems)



!omponent$based software engineering

3ased on systematic reuse where systems areintegrated from existing components or !OTS0!ommercial$off$the$shelf1 systems)

Process stages% !omponent analysis&

% Requirements modification&

% System design with reuse&

% 'evelopment and integration) This approach is becoming increasingly used

as component standards have emerged)



Reuse$oriented development

Requirements

specifcation

Component

analysis

Development

and integration

System design

with reuse

Requirements

modifcation

System

validation



Process iteration

System requirements "/-"4S evolve in the

course of a project so process iteration where

earlier stages are rewored is always part of

the process for large systems) *teration can be applied to any of the generic

process models)

Two 0related1 approaches

% *ncremental delivery&

% Spiral development)



*ncremental delivery

Rather than deliver the system as a single delivery, the

development and delivery is broen down into

increments with each increment delivering part of the

required functionality)

ser requirements are prioritised and the highestpriority requirements are included in early increments)

Once the development of an increment is started, the

requirements are fro2en though requirements for later

increments can continue to evolve)



*ncremental development

Validate

increment

Develop system

increment

Design system

architecture

Integrate

increment

Validate

system

Defne outlinerequirements

ssign requirements to increments

System incomplete

Finalsyste


17/50


*ncremental development advantages

!ustomer value can be delivered with each

increment so system functionality is available

earlier)

#arly increments act as a prototype to helpelicit requirements for later increments)

/ower ris of overall project failure)

The highest priority system services tend toreceive the most testing)


18/50


#xtreme programming

"n approach to development based on the

development and delivery of very small

increments of functionality)

Relies on constant code improvement, userinvolvement in the development team and

pairwise programming)

!overed in !hapter 56


19/50


Spiral development

Process is represented as a spiral rather than

as a sequence of activities with bactracing)

#ach loop in the spiral represents a phase in

the process) 7o fixed phases such as specification or

design $ loops in the spiral are chosen

depending on what is required)

Riss are explicitly assessed and resolved

throughout the process)


20/50


Spiral model of the software process

Ris!

analysis

Ris!

analysis

Ris!

analysis

Ris!

analysis"roto#

type $

"rototype %

"rototype &Opera#

tional

protoype

Concept o

Operation

Simulations' models' (enchmar!s

S)*

requirements

Requirement

validation

Design

V+V

"roduct

design Detailed

design

Code

,nit test

Integration

testcceptance

testService Develop' veriy

ne-t# level product

.valuate alternatives'

identiy' resolve ris!s

Determine o(/ectives'

alternatives and

constraints

"lan ne-t phase

Integration

and test plan

Development

plan

Requirements plan

0ie#cycle plan

R.VI.*


21/50


Spiral model sectors

Objective setting

% Specific objectives for the phase are identified)

Ris assessment and reduction

% Riss are assessed and activities put in place to reducethe ey riss)

'evelopment and validation

% " development model for the system is chosen whichcan be any of the generic models)

Planning% The project is reviewed and the next phase of the spiral

is planned)


22/50


Process activities

Software specification

Software design and implementation

Software validation

Software evolution


23/50


Software specification

The process of establishing what services are

required and the constraints on the system8s

operation and development)

Requirements engineering process% .easibility study&

% Requirements elicitation and analysis&

% Requirements specification&

% Requirements validation)


24/50


The requirements engineering process

Feasi(ility

study

Requirements

elicitation and

analysis

Requirements

specifcation

Requirements

validationFeasi(ility

report

System

models

,ser and system

requirements

Requirements

document


25/50


Software design and implementation

The process of converting the systemspecification into an executable system)

Software design

% 'esign a software structure that realises thespecification&

*mplementation% Translate this structure into an executable

program&

The activities of design and implementationare closely related and may be inter$leaved)


26/50


'esign process activities

"rchitectural design

"bstract specification

*nterface design

!omponent design

'ata structure design

"lgorithm design


27/50


The software design process

rchitectural

design

(stract

specifcation

Interace

design

Component

design

Data

structure

design

lgorithm

design

Systemarchitecture

Sotwarespecifcation

Interacespecifcation

Componentspecifcation

Data

structure

specifcation

lgorithmspecifcation

Requirementsspecifcation

Design activities

Design products


28/50


Structured methods

Systematic approaches to developing asoftware design)

The design is usually documented as a set of

graphical models) Possible models

% Object model&

% Sequence model&

% State transition model&% Structural model&

% 'ata$flow model)


29/50


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 in the program and remove

these faults in the debugging process)


30/50


The debugging process

0ocate

error

Design

error repairRepair

error

Re#test

program


31/50


Software validation

(erification and validation 0( 9 (1 is intendedto show that a system conforms to itsspecification and meets the requirements ofthe system customer)

*nvolves checing and review processes andsystem testing)

System testing involves executing the system

with test cases that are derived from thespecification of the real data to be processedby the system)


32/50


The testing process

Componenttesting

Systemtesting

cceptanctesting


33/50


Testing stages

!omponent or unit testing% *ndividual components are tested independently&

% !omponents may be functions or objects orcoherent groupings of these entities)

System testing% Testing of the system as a whole) Testing of

emergent properties is particularly important)

"cceptance testing

% Testing with customer data to chec that thesystem meets the customer8s needs)


34/50


Testing phases

Requirements

specifcation

System

specifcation

System

design

Detailed

design

1odule and

unit codeand test

Su(#system

integrationtest plan

System

integrationtest plan

cceptance

test plan

Service cceptance

test

System

integration test

Su(#system

integration test


35/50


Software evolution

Software is inherently flexible and can change)

"s requirements change through changing

business circumstances, the software that

supports the business must also evolve andchange)

"lthough there has been a demarcation

between development and evolution

0maintenance1 this is increasingly irrelevant as

fewer and fewer systems are completely new)


36/50


System evolution

ssess e-istingsystems

Defne systemrequirements

"ropose systemchanges

1odiysystems

2ew

system

.-isting

systems


37/50


The Rational nified Process

" modern process model derived from the

wor on the :/ and associated process)

7ormally described from ; perspectives

% " dynamic perspective that shows phases overtime&

% " static perspective that shows process activities&

% " practive perspective that suggests good

practice)


38/50


RP phase model

Phase iteration

Inception Elaboration Construction Transition


39/50


RP phases

*nception

% #stablish the business case for the system)

#laboration

% 'evelop an understanding of the problem domainand the system architecture)

!onstruction

% System design, programming and testing)

Transition

% 'eploy the system in its operating environment)


40/50


RP good practice

'evelop software iteratively

:anage requirements

se component$based architectures

(isually model software

(erify software quality

!ontrol changes to software


41/50


Static worflows

Workflow Description

Business modelling The business processes are modelled using business use cases.

Requirements Actors who interact with the system are identified and use cases are

developed to model the system requirements.

Analysis and design A design model is created and documented using architectural

models, component models, object models and sequence models.

Implementation The components in the system are implemented and structured intoimplementation sub-systems. Automatic code generation from design

models helps accelerate this process.

Test Testing is an iterative process that is carried out in conjunction with

implementation. System testing follows the completion of the

implementation.

Deployment A product release is created, distributed to users and installed in their

workplace.

Configuration and

change management

This supporting workflow managed changes to the system (see

Chapter 29).

Project management This supporting workflow manages the system development (see

Chapter 5).

Environment This workflow is concerned with making appropriate software tools

available to the software development team.


42/50


!omputer$aided software engineering

!omputer$aided software engineering 0!"S#1 is

software to support software development and

evolution processes)

"ctivity automation

% +raphical editors for system model development&

% 'ata dictionary to manage design entities&

% +raphical * builder for user interface construction&

% 'ebuggers to support program fault finding&

% "utomated translators to generate new versions of a

program)


43/50


!ase technology

!ase technology has led to significant

improvements in the software process)


44/50


!"S# classification

!lassification helps us understand the different types

of !"S# tools and their support for process activities)

.unctional perspective

% Tools are classified according to their specific function)

Process perspective

% Tools are classified according to process activities that

are supported)

*ntegration perspective

% Tools are classified according to their organisation into

integrated units)


45/50


.unctional tool classification

Tool type Examples

Planning tools PERT tools, estimation tools, spreadsheets

Editing tools Text editors, diagram editors, word processors

Change management tools Requirements traceability tools, change control systems

Configuration management tools Version management systems, system building tools

Prototyping tools Very h ighle!el languages, user interface generators

"ethodsupport tools #esign editors, data dictionaries, code generators

$anguageprocessing tools Compilers, interpreters

Program analysis tools Cross reference generators, static analysers, dynamic analysers

Testing tools Test data generators, file comparators

#ebugging tools %nteracti!e debugging systems

#ocumentation tools Page layout programs, image editors

Reengineering tools Crossreference systems, program restructuring systems


46/50


"ctivity$based tool classification

Specifcation Design Implementation Verifcation

and

Validation

Re#engineering tools

3esting tools

De(ugging tools

"rogram analysis tools

0anguage#processing

tools

1ethod support tools

"rototyping tools

Confguration

management tools

Change management tools

Documentation tools

.diting tools

"lanning tools


47/50


!"S# integration

Tools% Support individual process tass such as design

consistency checing, text editing, etc)

-orbenches% Support a process phase such as specification or

design, 7ormally include a number of integratedtools)

#nvironments

% Support all or a substantial part of an entiresoftware process) 7ormally include severalintegrated worbenches)


48/50


Tools, worbenches, environments

Single#method

wor!(enches

4eneral#purpose

wor!(enches

1ulti#method

wor!(enches

0anguage#specifc

wor!(enches

"rogramming 3estingnalysis and

design

Integrated

environments

"rocess#centred

environments

File

comparatorsCompilers.ditors

.nvironments*or!(enches3ools

CS.

technology


49/50


=ey points

Software processes are the activities involved inproducing and evolving a software system)

Software process models are abstract representationsof these processes)

+eneral activities are specification, design andimplementation, validation and evolution)

+eneric process models describe the organisation ofsoftware processes) #xamples include the waterfallmodel, evolutionary development and component$based

software engineering) *terative process models describe the software process

as a cycle of activities)


50/50

=ey points

Requirements engineering is the process ofdeveloping a software specification)

'esign and implementation processes transform thespecification to an executable program)

(alidation involves checing that the system meets toits specification and user needs)

#volution is concerned with modifying the system afterit is in use)

The Rational nified Process is a generic processmodel that separates activities from phases) !"S# technology supports software process activities)

ch4 software processes.ppt

Documents