Ch03 - To Be Reported by Group1 and Group 2

7/21/2019 Ch03 - To Be Reported by Group1 and Group 2

1/49

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

Chapter 3

Software Processes


2/49


Software Processes

Coherent sets of activities for specifying,

designing, implementing and testing

software systems


3/49


Objectives

To introduce software process models

To describe a number of different process models and

when they may be used

To describe outline process models for requirementsengineering, software development, testing and

evolution

To introduce CASE technology to support software

process activities


4/49


Topics covered

Software process models

Process iteration

Software specification

Software design and implementation Software validation

Software evolution

Automated process support


5/49


The software process

A structured set of activities required to develop a

software system

Specification

esign

!alidation

Evolution

A software process model is an abstract representation

of a process" #t presents a description of a process from

some particular perspective


6/49


Generic software process models

The waterfall model

Separate and distinct phases of specification and development

Evolutionary development

Specification and development are interleaved $ormal systems development

A mathematical system model is formally transformed to an

implementation

%euse&based development The system is assembled from e'isting components


7/49Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 1 Slide 7

Waterfall model

Requirementsdefinition

System andsoftware design

Implementationand unit testing

Integration and

system testing

Operation andmaintenance



Waterfall model phases

%equirements analysis and definition

System and software design

#mplementation and unit testing

#ntegration and system testing (peration and maintenance

The drawbac) of the waterfall model is the difficulty of

accommodating change after the process is underway



Waterfall model problems

#nfle'ible partitioning of the pro*ect into distinct stages

This ma)es it difficult to respond to changing customer

requirements

Therefore, this model is only appropriate when therequirements are well&understood




E'ploratory development

(b*ective is to wor) with customers and to evolve a final

system from an initial outline specification" Should start with

well&understood requirements

Throw&away prototyping

(b*ective is to understand the system requirements" Should

start with poorly understood requirements




Validation Final

version

Development Intermediate

versions

Specification Initial

version

Outline

description

Concurrentactivities




Problems

+ac) of process visibility

Systems are often poorly structured

Special s)ills e"g" in languages for rapid prototyping- may be

required

Applicability

$or small or medium&si.e interactive systems

$or parts of large systems e"g" the user interface-

$or short&lifetime systems



ormal systems development

/ased on the transformation of a mathematical

specification through different representations to an

e'ecutable program

Transformations are 0correctness&preserving1 so it isstraightforward to show that the program conforms to its

specification

Embodied in the 0Cleanroom1 approach to software

development




Requirementsdefinition

Formalspecification

Formaltransformation

Integration andsystem testing



ormal transformations

R2Formal

specification R3

Executableprogram

P2 P3 P4

T1 T2 T3 T4

Proofs of transformation correctness

Formal transformations

R1

P1




Problems

2eed for specialised s)ills and training to apply the technique

ifficult to formally specify some aspects of the system such

as the user interface

Applicability

Critical systems especially those where a safety or security

case must be made before the system is put into operation


17/49


!euse"oriented development

/ased on systematic reuse where systems are

integrated from e'isting components or C(TS

Commercial&off&the&shelf- systems

Process stages Component analysis %equirements modification

System design with reuse

evelopment and integration

This approach is becoming more important but still

limited e'perience with it


18/49


!euse"oriented development

Requirements

specification

Component

analysis

Developmentand integration

System design

with reuse

Requirements

modification

Systemvalidation


19/49


Process iteration

System requirements A+3A4S evolve in the course of a

pro*ect so process iteration where earlier stages are

rewor)ed is always part of the process for large systems

#teration can be applied to any of the generic processmodels

Two related- approaches

#ncremental development

Spiral development


20/49



%ather than deliver the system as a single delivery,

the development and delivery is bro)en down into

increments with each increment delivering part of

the required functionality

5ser requirements are prioritised and the highest

priority requirements are included in early

increments

(nce the development of an increment is started,

the requirements are fro.en though requirements forlater increments can continue to evolve


21/49



Validate

increment

Develop systemincrement

Design systemarchitecture

Integrateincrement

Validate

system

Define outlinerequirements

Assign requirements to increments

System incomplete

Finalsystem


22/49


#ncremental development advanta$es

Customer value can be delivered with each increment

so system functionality is available earlier

Early increments act as a prototype to help elicit

requirements for later increments +ower ris) of overall pro*ect failure

The highest priority system services tend to receive the

most testing


23/49


E%treme pro$rammin$

2ew approach to development based on the

development and delivery of very small increments of

functionality

%elies on constant code improvement, user involvementin the development team and pairwise programming


24/49


Spiral development

Process is represented as a spiral rather than as a

sequence of activities with bac)trac)ing

Each loop in the spiral represents a phase in the

process" 2o fi'ed phases such as specification or design & loops

in the spiral are chosen depending on what is required

%is)s are e'plicitly assessed and resolved throughout

the process


25/49


Spiral model of the software

process

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2Prototype 3

Opera-

tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Product

design Detailed

design

Code

Unit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW


26/49


Spiral model sectors

(b*ective setting Specific ob*ectives for the phase are identified

%is) assessment and reduction %is)s are assessed and activities put in place to reduce the

)ey ris)s evelopment and validation

A development model for the system is chosen which can beany of the generic models

Planning The pro*ect is reviewed and the ne't phase of the spiral isplanned


27/49


Software specification

The process of establishing what services are required

and the constraints on the system1s operation and

development

%equirements engineering process $easibility study %equirements elicitation and analysis

%equirements specification

%equirements validation


28/49


The re&uirements en$ineerin$

process

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirements

document


29/49


Software desi$n and

implementation

The process of converting the system specification into

an e'ecutable system

Software design

esign a software structure that realises the specification #mplementation

Translate this structure into an e'ecutable program

The activities of design and implementation are closely

related and may be inter&leaved


30/49


'esi$n process activities

Architectural design

Abstract specification

#nterface design

Component design ata structure design

Algorithm design


31/49


The software desi$n process

Architecturaldesign

Abstractspecification

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

System

architecture

Software

specification

Interface

specification

Component

specification

Datastructure

specification

Algorithm

specification

Requirementsspecification

Design activities

Design products


32/49


'esi$n methods

Systematic approaches to developing a software design

The design is usually documented as a set of graphical

models

Possible models ata&flow model

Entity&relation&attribute model

Structural model

(b*ect models


33/49


Pro$rammin$ and debu$$in$

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


34/49


The debu$$in$ process

Locateerror

Designerror repair

Repairerror

Re-testprogram


35/49


Software validation

!erification and validation is intended to show that a

system conforms to its specification and meets the

requirements of the system customer

#nvolves chec)ing and review processes and system

testing

System testing involves e'ecuting the system with test

cases that are derived from the specification of the real

data to be processed by the system


36/49


The testin$ process

Sub-systemtesting

Moduletesting

Unittesting

Systemtesting

Acceptance

testing

Componenttesting

Integration testing Usertesting


37/49


Testin$ sta$es 5nit testing

#ndividual components are tested

6odule testing

%elated collections of dependent components are tested

Sub&system testing 6odules are integrated into sub&systems and tested" The focushere should be on interface testing

System testing

Testing of the system as a whole" Testing of emergent properties

Acceptance testing Testing with customer data to chec) that it is acceptable


38/49


Testin$ phases

Requirementsspecification

Systemspecification

Systemdesign

Detaileddesign

Module andunit codeand tess

Sub-systemintegrationtest plan

Systemintegrationtest plan

Acceptancetest plan

Service Acceptancetest Systemintegration test Sub-systemintegrat ion test


39/49


Software evolution

Software is inherently fle'ible and can change"

As requirements change through changing business

circumstances, the software that supports the business

must also evolve and change

Although there has been a demarcation between

development and evolution maintenance- this is

increasingly irrelevant as fewer and fewer systems are

completely new


40/49


System evolution

Assess existingsystems

Define systemrequirements

Propose systemchanges

Modifysystems

Newsystem

Existing

systems


41/49


(utomated process support

)C(SE*

Computer&aided software engineering CASE- is

software to support software development and evolution

processes

Activity automation

7raphical editors for system model development

ata dictionary to manage design entities

7raphical 5# builder for user interface construction

ebuggers to support program fault finding

Automated translators to generate new versions of a program


42/49


Case technolo$y

Case technology has led to significant improvements in

the software process though not the order of magnitude

improvements that were once predicted

Software engineering requires creative thought & this is not

readily automatable

Software engineering is a team activity and, for large pro*ects,

much time is spent in team interactions" CASE technology

does not really support these


43/49


C(SE classification

Classification helps us understand the different types of

CASE 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


44/49


unctional tool classification


45/49

(ctivity"based classification

Reengineering tools

Testing tools

Debugging tools

Program analysis tools

Language-processingtools

Method support tools

Prototyping tools

Configurationmanagement tools

Change management tools

Documentation tools

Editing tools

Planning tools

Specification Design Implementation Verificationand

Validation


46/49


C(SE inte$ration

Tools

Support individual process tas)s such as design consistency

chec)ing, te't editing, etc"

3or)benches

Support a process phase such as specification or design,

2ormally include a number of integrated tools

Environments

Support all or a substantial part of an entire software process"

2ormally include several integrated wor)benches


47/49


Tools+ wor,benches+

environments

Single-methodworkbenches

General-purposeworkbenches

Multi-methodworkbenches

Language-specificworkbenches

Programming TestingAnalysis anddesign

Integratedenvironments

Process-centredenvironments

Filecomparators

CompilersEditors

EnvironmentsWorkbenchesTools

CASEtechnology


48/49


-ey points

Software processes are the activities involved in

producing and evolving a software system" They are

represented in a software process model

7eneral activities are specification, design and

implementation, validation and evolution

7eneric process models describe the organisation of

software processes

#terative process models describe the software process

as a cycle of activities


49/49

-ey points

%equirements engineering is the process of developing

a software specification

esign and implementation processes transform the

specification to an e'ecutable program

!alidation involves chec)ing that the system meets to its

specification and user needs

Evolution is concerned with modifying the system after it

is in use

CASE technology supports software process activities

Documents

Ch03 - To Be Reported by Group1 and Group 2