2-life cycle models (1)

8/18/2019 2-Life Cycle Models (1)

1/40

1

Life Cycle Models


2/40

2

Relative Effort for Phases

• Phases betweenfeasibility study andtesting− known as development

phases.

• Among all life cycleAmong all life cycle

phasesphases− maintenance phasemaintenance phase

consumes maximumconsumes maximumeort.eort.

• Among developmentphases,− testing phase consumes

the maximum eort.

0

10

0

!0"0

#0

$0

% e & .

' p

( e s i g n

) o d i n g

* e s t

+ a i n t n c

e

Relative Effort


3/40

3

Classical Waterfall Model

• )lassical waterfall modeldivides life cycle into phases

− feasibility study,

− re&uirements analysis andspeci-cation,

− design,

−coding and unit testing,

− integration and system testing,

− maintenance.


4/40

4

Classical Waterfall Model

Feasibility Study

Req. Analysis

Design

Coding

Testing

Maintenance


5/40

5

Classical Waterfall Model(CONT.)

• +ost organiations usually de-ne− standards on the outputs (deliverables)

produced at the end of every phase

− entry and exit criteria for every phase.

• *hey also prescribe speci-cmethodologies for

− specication,

− design,

− testing,

− project management, etc.


6/40

6

Classical Waterfall Model(CONT.)

• *he guidelines and methodologies ofan organiation

− called the organization's softwaresoftware

development methodologydevelo

pment methodology..


7/40

7

Feasibility Stdy

• +ain aim of feasibility study determinewhether developing the product

− -nancially worthwhile

− technically feasible

− /perationally feasible

− *imely feasible


8/40

8

!ctivities dri"# Feasibility

Stdy• ork out an overall

understanding of the problem.

•

ormulate dierent solutionstrategies.

• 2xamine alternate solution

strategies in terms of∗ resources re&uired,

∗ cost of development, and

∗ development time.


9/40

9

!ctivities dri"# Feasibility

Stdy• Perform a cost3bene-t analysis

− to determine which solution is thebest.

−you may determine that none ofthe solutions is feasible due to∗ high cost,

∗resource constraints,

∗ technical reasons.


10/40

10

Re$ire%e"ts !"alysis a"d

S&ecificatio"

• Aim of this phase−understand the exact

re&uirements of the customer,

−document them properly.

• )onsists of two distinctactivities

− re&uirements gathering andanalysis

− re&uirements speci-cation.


11/40

11

'oals of Re$ire%e"ts

!"alysis

• )ollect all related data fromthe customer−analye the collected data to

clearly understand what thecustomer wants,

−-nd out any inconsistencies

and incompleteness in there&uirements,

−resolve all inconsistencies and

incompleteness.


12/40

12

esi#"

• (esign phase transformsre&uirements

speci-cation− into a form suitable forimplementation in some

programming language.


13/40

13

esi#"

• 4n technical terms−during design phase, softwarearchitecture is derived from

the '%' document.

• *wo design approaches

− traditional approach,

−ob5ect oriented approach.


14/40

14

%&le%e"tatio"

• Purpose ofimplementation phase

6coding and unit testing phase7

−translate software design

into source code.


15/40

15

Mai"te"a"ce

•+aintenance of anysoftware product

−

requires much more eortthan the eort to develop theproduct itself.

−

development eort tomaintenance eort is typically!"#$".


16/40

16

Mai"te"a"ce (CONT.)

• )orrective maintenance − )orrect errors which were not discovered

during the product development phases.

•

Perfective maintenance− 4mprove implementation of the system

− enhance functionalities of the system.

• Adaptive maintenance

− Port software to a new environment,∗ e.g. to a new computer or to a new operating

system.


17/40

17

terative Waterfall Model

• )lassical waterfall model isidealistic

−assumes that no defect is

introduced during anydevelopment activity.

− in practice

∗

defects do get introduced in almostevery phase of the life cycle.


18/40

18

terative Waterfall Model(CONT.)

• (efects usually getdetected much later in the

life cycle−%or example, a design defectmight go unnoticed till thecoding or testing phase.


19/40

19


• /nce a defect is detected

− we need to go back to the phasewhere it was introduced

− redo some of the work done duringthat and all subse&uent phases.

• *herefore we need feedback

paths in the classical waterfallmodel.


20/40

20


Feasibility Study

Req. Analysis

Design

Coding

Testing

Maintenance


21/40

21


• 2rrors should be detected• in the same phase in &hich they are

introduced.• or example

• if a design problem is detected inthe design phase itself,• the problem can be taen care of much

more easily•

than say if it is identied at the end of theintegration and system testing phase.


22/40

22

Prototy&i"# Model

• 8efore starting actualdevelopment,

− a working prototype of the systemshould -rst be built.

• A prototype is a toyimplementation of a system

− limited functional capabilities,

− low reliability,

− ine9cient performance.


23/40

23

Reaso"s for develo&i"# a

&rototy&e

• llustrate to the customer#− input data formats, messages, reports,

or interactive dialogs.

•

xamine technical issues associated&ith product development#−*ften major design decisions depend

on issues lie#

∗ response time of a hard&are controller,∗e+ciency of an algorithm, etc.


24/40

24

Prototy&i"# Model (CONT.)

• *he third reason fordeveloping a prototype is

− 4n many systems, it isimpossible to :get it right; the-rst time, or it would be

impractical to do so in realtime


25/40


26/40

26


• *he developed prototype is submittedto the customer for his evaluation− ased on the user feedbac, requirements are

rened.

− -his cycle continues until the user approvesthe prototype.

• *he actual system is developed usingthe classical waterfall approach, later.


27/40

27


Requirements

Gathering Quick Design

RefineRequirements

Build Prototype

CustomerEvaluation ofPrototype

Design

Implement

Test

Maintain

Customersatisfied


28/40

28


• %e&uirements analysis andspeci-cation phase becomesredundant

• (esign and code for the prototype isusually thrown away− =owever, the experience gathered from

developing the prototype helps a greatdeal while developing the actual product.


29/40

29


• 2ven though construction of a workingprototype model involves additionalcost >>> overall development costmight be lower for− systems &ith unclear user requirements,

− systems &ith unresolved technical issues.

•+any user re&uirements get properlyde-ned and technical issues getresolved.


30/40

30

Evoltio"ary Model

("cre%e"tal Model)• 2volutionary model 6aka successive

versions or incremental model7− *he system is broken down into several

modules which can be incrementally

implemented and delivered.

• irst develop the core modules of thesystem.

• *he initial product skeleton is re-nedinto increasing levels of capability

− by adding new functionalities insuccessive versions.


31/40

31

Evoltio"ary Model (CONT.)

AB

C

A AB


32/40

32

!dva"ta#es of Evoltio"ary

Model

• ?sers get a chance to experiment witha partially developed system− much before the full working version is

released,• =elps -nding exact user re&uirements

− much before fully working system isdeveloped.

•

)ore modules get tested thoroughly− reduces chances of errors in -nal product.


33/40

33

isadva"ta#es of

Evoltio"ary Model

• /ften, di9cult to subdivideproblems into functional units

which can be incrementallyimplemented and delivered.• evolutionary model is useful

for very large problems whereit is easier to -nd modules forincremental implementation.


34/40

34

Evoltio"ary Model *ithteratio"• +any organiations use a

combination of iterative and

incremental development−a new release may include

new functionality

−

existing functionality from thecurrent release may also havebeen modi-ed.


35/40

35

S&iral Model• Proposed by 8oehm in 1@.

• 2ach loop of the spiral represents a phaseof the software process− the innermost loop might be concerned with

system feasibility,

− the next loop with system re&uirementsde-nition,

− the next one with system design, and so on.

• piral model is an evolutionary soft&are

process model &hich is a combination of aniterative nature of prototyping and controlledand systematic aspects of traditional &aterfallmodel.


36/40

36

communication

planning

modelin

constructiondeployment

delivery

feedbac'

start

analysis

design

code

test

estimation

schedulingris' analysis


37/40

37

S&iral Model (CONT.)

• *he team must decide− how to structure the pro5ect into

phases.

• 'tart work using some genericmodel− add extra phases

∗ for speci-c pro5ects or when problems are

identi-ed during a pro5ect.

• 2ach loop in the spiral is split intosectors 6&uadrants7.


38/40


39/40

39

Co%&ariso" of iffere"t Life Cycle

Models

• 4terative waterfall model− most &idely used model.

− ut, suitable only for &ell/understood

problems.• Prototype model is suitable for

pro5ects not well understood

− user re&uirements− technical aspects


40/40

40

Co%&ariso" of iffere"t Life Cycle

Models (CONT.)

• 2volutionary model is suitable forlarge problems− can be decomposed into a set of modules

that can be incrementally implemented,− incremental delivery of the system is

acceptable to the customer.

• *he spiral model− suitable for development of technically

challenging soft&are products that aresubject to several inds of riss.

2-life cycle models (1)

Documents