of 40
8/18/2019 2-Life Cycle Models (1)
1/40
1
Life Cycle Models
8/18/2019 2-Life Cycle Models (1)
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
8/18/2019 2-Life Cycle Models (1)
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.
8/18/2019 2-Life Cycle Models (1)
4/40
4
Classical Waterfall Model
Feasibility Study
Req. Analysis
Design
Coding
Testing
Maintenance
8/18/2019 2-Life Cycle Models (1)
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.
8/18/2019 2-Life Cycle Models (1)
6/40
6
Classical Waterfall Model(CONT.)
• *he guidelines and methodologies ofan organiation
− called the organization's softwaresoftware
development methodologydevelo
pment methodology..
8/18/2019 2-Life Cycle Models (1)
7/40
7
Feasibility Stdy
• +ain aim of feasibility study determinewhether developing the product
− -nancially worthwhile
− technically feasible
− /perationally feasible
− *imely feasible
8/18/2019 2-Life Cycle Models (1)
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.
8/18/2019 2-Life Cycle Models (1)
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.
8/18/2019 2-Life Cycle Models (1)
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.
8/18/2019 2-Life Cycle Models (1)
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.
8/18/2019 2-Life Cycle Models (1)
12/40
12
esi#"
• (esign phase transformsre&uirements
speci-cation− into a form suitable forimplementation in some
programming language.
8/18/2019 2-Life Cycle Models (1)
13/40
13
esi#"
• 4n technical terms−during design phase, softwarearchitecture is derived from
the '%' document.
• *wo design approaches
− traditional approach,
−ob5ect oriented approach.
8/18/2019 2-Life Cycle Models (1)
14/40
14
%&le%e"tatio"
• Purpose ofimplementation phase
6coding and unit testing phase7
−translate software design
into source code.
8/18/2019 2-Life Cycle Models (1)
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!"#$".
8/18/2019 2-Life Cycle Models (1)
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.
8/18/2019 2-Life Cycle Models (1)
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.
8/18/2019 2-Life Cycle Models (1)
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.
8/18/2019 2-Life Cycle Models (1)
19/40
19
terative Waterfall Model(CONT.)
• /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.
8/18/2019 2-Life Cycle Models (1)
20/40
20
terative Waterfall Model(CONT.)
Feasibility Study
Req. Analysis
Design
Coding
Testing
Maintenance
8/18/2019 2-Life Cycle Models (1)
21/40
21
terative Waterfall Model(CONT.)
• 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.
8/18/2019 2-Life Cycle Models (1)
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.
8/18/2019 2-Life Cycle Models (1)
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.
8/18/2019 2-Life Cycle Models (1)
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
8/18/2019 2-Life Cycle Models (1)
25/40
8/18/2019 2-Life Cycle Models (1)
26/40
26
Prototy&i"# Model (CONT.)
• *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.
8/18/2019 2-Life Cycle Models (1)
27/40
27
Prototy&i"# Model (CONT.)
Requirements
Gathering Quick Design
RefineRequirements
Build Prototype
CustomerEvaluation ofPrototype
Design
Implement
Test
Maintain
Customersatisfied
8/18/2019 2-Life Cycle Models (1)
28/40
28
Prototy&i"# Model (CONT.)
• %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.
8/18/2019 2-Life Cycle Models (1)
29/40
29
Prototy&i"# Model (CONT.)
• 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.
8/18/2019 2-Life Cycle Models (1)
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.
8/18/2019 2-Life Cycle Models (1)
31/40
31
Evoltio"ary Model (CONT.)
AB
C
A AB
8/18/2019 2-Life Cycle Models (1)
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.
8/18/2019 2-Life Cycle Models (1)
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.
8/18/2019 2-Life Cycle Models (1)
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.
8/18/2019 2-Life Cycle Models (1)
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.
8/18/2019 2-Life Cycle Models (1)
36/40
36
communication
planning
modelin
constructiondeployment
delivery
feedbac'
start
analysis
design
code
test
estimation
schedulingris' analysis
8/18/2019 2-Life Cycle Models (1)
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.
8/18/2019 2-Life Cycle Models (1)
38/40
8/18/2019 2-Life Cycle Models (1)
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
8/18/2019 2-Life Cycle Models (1)
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.