adv disadv

30
1 CS 425/625 Software Engineering Software Processes Based on Chapter 4 of the textbook [SE-8] Ian Sommerville, Software Engineering, 8 th Ed., Addison-Wesley, 2006 and on Ch4 PPT presentation from http://www.software-engin.com / September 10, 2007

Post on 20-Oct-2014

4.192 views

Category:

Technology


0 download

DESCRIPTION

 

TRANSCRIPT

Page 1: Adv Disadv

1

CS 425/625 Software Engineering

Software Processes

Based on Chapter 4 of the textbook [SE-8] Ian Sommerville, Software Engineering, 8th Ed., Addison-

Wesley, 2006 and on Ch4 PPT presentation from http://www.software-engin.com/

September 10, 2007

Page 2: Adv Disadv

2

Outline• Software Process Models

– Waterfall model– Evolutionary development– Component-based software engineering– Incremental model– Spiral model

• Software Process Activities– Specification– Design and implementation– Validation– Evolution

• The Rational Unified Process• Computer-Aided Software Engineering

Page 3: Adv Disadv

3

Software Process Models

• Software process = organized set of activities aimed at building a software system

• Software process model = an abstract representation of a software process

• Fundamental software process activities:– Software specification– Software design – Software implementation– Software validation– Software evolution

Page 4: Adv Disadv

4

Software Process Models: Waterfall..

• The Waterfall model [SE-8, Fig 4.1]

Requirementsdefinition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation andmaintenance

Page 5: Adv Disadv

5

Software Process Models: .Waterfall.

• Main characteristics:– Also called classic software life cycle or

sequential model– Process activities (phases/stages) are

clearly separated – After a number of iterations, phases of the

life cycle (such as specification and design) are “frozen”

Page 6: Adv Disadv

6

Software Process Models: ..Waterfall

• Advantages: – Organized approach, provides robust separation of

phases– Reflects common engineering practice

• Disadvantages:– Doesn’t cope well with changes required by the client – Development teams might wait for each other– A working version of the product is available only late

• Applicability:– When requirements are well known and few changes

are likely to be needed– Can be used also for parts of larger software systems

Page 7: Adv Disadv

7

Software Process Models: Evolutionary Development…

• Evolutionary Development model [SE-8, Fig 4.2]

ValidationFinal

version

DevelopmentIntermediate

versions

SpecificationInitial

version

Outlinedescription

Concurrentactivities

Page 8: Adv Disadv

8

Software Process Models: .Evolutionary Development..

• Main characteristics:– The phases of the software construction are

interleaved

– Feedback from the user is used throughout the entire process

– The software product is refined through many versions

• Types of evolutionary development:– Exploratory development

– Throw-away prototyping

Page 9: Adv Disadv

9

Software Process Models: ..Evolutionary Development.

• Advantages:– Deals constantly with changes– Provides quickly an initial version of the system– Involves all development teams

• Disadvantages:– Quick fixes may be involved– “Invisible” process, not well-supported by

documentation– The system’s structure can be corrupted by

continuous change

Page 10: Adv Disadv

10

Software Process Models: …Evolutionary Development

• Disadvantages [cont’d]:– Special tools and techniques may be necessary– The client may have the impression the first version

is very close to the final product and thus be less patient

• Applicability:– When requirements are not well understood– When the client and the developer agree on a “rapid

prototype” that will be thrown away– Good for small and medium-sized software systems

Page 11: Adv Disadv

11

Software Process Models: Component-based Software Engineering…

• CBSE process model [SE-8, Fig 4.3]

Requirementsspecification

Componentanalysis

Developmentand integration

System designwith reuse

Requirementsmodification

Systemvalidation

Page 12: Adv Disadv

12

Software Process Models: .Component-based Software Engineering..

• Main characteristics:– Makes intensive use of existing reusable

components– The focus is on integrating the components rather

than on creating them from the scratch

Page 13: Adv Disadv

13

Software Process Models: ..Component-based Software Engineering.

• Advantages:– Reduces considerably the software to be developed

“in-house”– Allows faster delivery– In principle, more reliable systems, due to using

previously tested components

Page 14: Adv Disadv

14

Software Process Models: …Component-based Software Engineering

• Disadvantages:– Compromises in requirements are needed– Less control over the system’s evolution

• Applicability:– When there is a pool of existing components that

could satisfy the requirements of the new product – Emerging trend: integration of web services from a

range of suppliers

Page 15: Adv Disadv

15

Software Process Models: Incremental Development…• The Incremental model [SE-8, Fig 4.4]

Valida teincrement

Develop systemincrement

Design systemarchitecture

Integrateincrement

Valida tesystem

Define outline requirements

Assign requirements to increments

System incomplete

Finalsystem

Page 16: Adv Disadv

16

Software Process Models: .Incremental..

• Main characteristics:– Hybrid model that combines elements of the

waterfall and evolutionary paradigms– The specification, design, and implementation

phases are broken in smaller increments

Page 17: Adv Disadv

17

Software Process Models: ..Incremental.

• Advantages:– Provides better support for process iteration– Reduces rework in the software construction process– Some decisions on requirements may be delayed– Allows early delivery of parts of the system– Supports easier integration of sub-systems– Lower risk of project failure – Delivery priorities can be more easily set

Page 18: Adv Disadv

18

Software Process Models: ...Incremental

• Disadvantages:– Increments need be relatively small– Mapping requirements to increments may not be

easy– Common software facilities may be difficult to

identify

• Applicability:– When it is possible to deliver the system “part-

by-part”

Page 19: Adv Disadv

19

Software Process Models: Spiral Model..

• Boehm’s Spiral Model [SE-8, Fig 4.5]

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2Prototype 3

Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

CodeUnit 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

Page 20: Adv Disadv

20

.Software Process Models: Spiral Model.

• Main characteristics:– Also a hybrid model that support process iteration– The process is represented as a spiral, each loop in

the spiral representing a process phase– Four sectors per loop: objective setting, risk

assessment and reduction, development and validation, planning

– Risk is explicitly taken into consideration

Page 21: Adv Disadv

21

Software Process Models: ..Spiral Model

• Advantages:– Risk reduction mechanisms are in place– Supports iteration and reflects real-world practices– Systematic approach

• Disadvantages:– Requires expertise in risk evaluation and reduction– Complex, relatively difficult to follow strictly – Applicable only to large systems

• Applicability:– Internal development of large systems

Page 22: Adv Disadv

22

Process Activities: Specification

• Requirements engineering [SE-8, Fig. 4.6]

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument

Page 23: Adv Disadv

23

Process Activities: Design & Implementation

• A general model for design [SE-8, Fig 4.7]

Architecturaldesign

Abstractspecification

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specification

Algorithmspecification

Requirementsspecification

Design activities

Design products

Page 24: Adv Disadv

24

Process Activities: Testing..

• The debugging process [SE-8, Fig 4.8]

Locateerror

Designerror repair

Repairerror

Re-testprogram

Page 25: Adv Disadv

25

Process Activities: .Testing.

• The testing process [SE-8, Fig 4.9]

Componenttesting

Systemtesting

Acceptancetesting

Page 26: Adv Disadv

26

Process Activities: ..Testing

• Testing phases in the SE process [SE-8, Fig. 4.10]

Requirementsspecification

Systemspecification

Systemdesign

Detaileddesign

Module andunit codeand test

Sub-systemintegrationtest plan

Systemintegrationtest plan

Acceptancetest plan

ServiceAcceptance

testSystem

integration testSub-system

integration test

Page 27: Adv Disadv

27

Process Activities: Evolution

• System evolution [SE-8, Fig 4.11]

Assess existingsystems

Define systemrequirements

Propose systemchanges

Modifysystems

Newsystem

Existingsystems

Page 28: Adv Disadv

28

The Rational Unified Process.

• RUP phases [SE-8, Fig 4.12]

Phase iteration

Inception Elaboration Construction Transition

Page 29: Adv Disadv

29

.The Rational Unified Process• RUP workflows [SE-8, Fig 4.13]

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 aredeveloped to model the system requirements.

Analysis and design A design model is created and documented using architecturalmodels, component models, object models and sequence models.

Implementation The components in the system are implemented and structured intoimplementation sub-systems. Automatic code generation from designmodels helps accelerate this process.

Test Testing is an iterative process that is carried out in conjunction withimplementation. System testing follows the completion of theimplementation.

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

Configuration andchange management

This supporting workflow managed changes to the system (seeChapter 29).

Project management This supporting workflow manages the system development (seeChapter 5).

Environment This workflow is concerned with making appropriate software toolsavailable to the software development team.

Page 30: Adv Disadv

30

CASE• Classification of CASE technology [SE-7, Fig 4.14]

Single-methodworkbenches

General-purposeworkbenches

Multi-methodworkbenches

Language-specificworkbenches

Programming TestingAnalysis and

design

Integratedenvironments

Process-centredenvironments

Filecomparators

CompilersEditors

EnvironmentsWorkbenchesTools

CASEtechnology