8/17/2019 sdlc.pptx

1/48

Software DevelopmentLife Cycle (SDLC)byKhushbu Varshney

8/17/2019 sdlc.pptx

2/48

SDLC Model

A framewor that describes the activitiesperformed at each sta!e of a softwaredevelopment pro"ect#

8/17/2019 sdlc.pptx

3/48

Capability Maturity Model (CMM)

• A bench$mar for measurin! the maturityof an or!ani%ation&s software process

•CMM defines ' levels of process maturitybased on certain Key rocess Areas (K A)

8/17/2019 sdlc.pptx

4/48

CMM LevelsLevel 5 – Optimizing (< 1%)$$ process chan!e mana!ement

$$ technolo!y chan!e mana!ement$$ defect prevention

Level 4 – Managed (< 5%)$$ software uality mana!ement$$ uantitative process mana!ement

Level 3 – Defined (< 10%)$$ peer reviews$$ inter!roup coordination$$ software product en!ineerin!$$ inte!rated software mana!ement$$ trainin! pro!ram$$ or!ani%ation process definition$$ or!ani%ation process focus

Level 2 – Repeatable ( 15%)$$ software confi!uration mana!ement$$ software uality assurance$$ software pro"ect trac in! and oversi!ht$$ software pro"ect plannin!$$ re uirements mana!ement

Level 1 – !nitial ( "0%)

8/17/2019 sdlc.pptx

5/48

Life Cycle Model!t p#$vide a fi&ed gene#i' f#ame $# t*at 'an be tail$#ed t$ a

pe'ifi' p#$+e't,

-#$+e't pe'ifi' pa#amete# ill in'l.de/

ize (pe# $n ea# )

.dgetD.#ati$n

p#$+e't plan life' 'le m$del 6 p#$+e't pa#amete#

8/17/2019 sdlc.pptx

6/48

• *y chan!in! the lifecycle model+ we can• !mp#$ve

• , Devel$pment peed (time t$ ma# et)• , -#$d.'t 7.alit• , -#$+e't vi ibilit• , 8dmini t#ative $ve#*ead• , Ri e&p$ .#e• , 9. t$me# #elati$n et' et',

8/17/2019 sdlc.pptx

7/48

The Waterfall Model

•The waterfall model is the classic lifecycle model

–it is widely known, understood and (commonly?) used.

In some respect, waterfall is the ”commonsense” approach.

Introduced by Royce in !"#.

8/17/2019 sdlc.pptx

8/48

-aterfall Model• Requirements – defines needed

information, function, beha$ior,performance and interfaces.

• Design – data structures, softwarearchitecture, interfacerepresentations, al%orithmic details.

• Implementation – source code,

database, user documentation,testin%.

8/17/2019 sdlc.pptx

9/48

8/17/2019 sdlc.pptx

10/48

-aterfall Stren!ths• .asy to understand+ easy to use

• rovides structure to ine/perienced staff

• Milestones are well understood

• Sets re uirements stability

• 0ood for mana!ement control (plan+ staff+ trac )

• -or s well when uality is more important than cost or schedule

8/17/2019 sdlc.pptx

11/48

-aterfall Deficiencies

1# 2dealised+ does not match reality well#

3# Doesn&t reflect iterative nature of e/ploratory development#

4# 5nrealistic to e/pect accurate re uirements so early in pro"ect

6# Software is delivered late in pro"ect+ delays discovery of serious errors#'# Difficult to inte!rate ris mana!ement7# Difficult and e/pensive to ma e chan!esto documents+ 8swimmin! upstream8#

9# Si!nificant administrative overhead+costly for small teams and pro"ects#

8/17/2019 sdlc.pptx

12/48

-hen to use the -aterfall Model

• :e uirements are very well nown

• roduct definition is stable

• ;echnolo!y is understood

•

8/17/2019 sdlc.pptx

13/48

V$Shaped SDLC Model• & $ariant of the 'aterfall that

emphasi es the $erificationand $alidation of the product.

• Testin% of the product isplanned in parallel with acorrespondin% phase ofde$elopment

8/17/2019 sdlc.pptx

14/48

V$Shaped Steps• ro"ect and :e uirements

lannin! = allocate resources

• roduct :e uirements andSpecification Analysis = completespecification of the softwaresystem

• Architecture or >i!h$Level Desi!n= defines how software functionsfulfill the desi!n

• Detailed Desi!n = developal!orithms for each architecturalcomponent

• roduction+ operation andmaintenance = provide forenhancement and corrections

• System and acceptance testin! =chec the entire software systemin its environment

• 2nte!ration and ;estin! = checthat modules interconnectcorrectly

• 5nit testin! = chec that eachmodule acts as e/pected

• Codin! = transform al!orithmsinto software

8/17/2019 sdlc.pptx

15/48

V$Shaped Stren!ths

• .mphasi%e plannin! for verification andvalidation of the product in early sta!esof product development

• .ach deliverable must be testable• ro"ect mana!ement can trac pro!ress

by milestones• .asy to use

8/17/2019 sdlc.pptx

16/48

V$Shaped -ea nesses

• Does not easily handle concurrent events

• Does not handle iterations or phases

• Does not easily handle dynamic chan!es inre uirements

• Does not contain ris analysis activities

8/17/2019 sdlc.pptx

17/48

-hen to use the V$Shaped Model

• ./cellent choice for systems re uirin! hi!h reliability =hospital patient control applications

• All re uirements are nown up$front

• Solution and technolo!y are nown

8/17/2019 sdlc.pptx

18/48

Structured .volutionaryrototypin! Model

• Developers build a prototype durin! the re uirementsphase

• rototype is evaluated by end users

• 5sers !ive corrective feedbac

• Developers further refine the prototype

• -hen the user is satisfied+ the prototype code is

brou!ht up to the standards needed for a final product#

8/17/2019 sdlc.pptx

19/48

8/17/2019 sdlc.pptx

20/48

Structured .volutionaryrototypin! Steps

• A preliminary pro"ect plan is developed• An partial hi!h$level paper model is created• ;he model is source for a partial re uirements

specification

• A prototype is built with basic and critical attributes• ;he desi!ner builds

– the database – user interface – al!orithmic functions

• ;he desi!ner demonstrates the prototype+ the userevaluates for problems and su!!ests improvements#

• ;his loop continues until the user is satisfied

8/17/2019 sdlc.pptx

21/48

Structured .volutionary rototypin!Stren!ths• Customers can ?see8 the system re uirements as they are bein! !athered

• Developers learn from customers

• A more accurate end product

• 5ne/pected re uirements accommodated

• Allows for fle/ible desi!n and development

• Steady+ visible si!ns of pro!ress produced

• 2nteraction with the prototype stimulates awareness of additional neededfunctionality

8/17/2019 sdlc.pptx

22/48

Structured .volutionaryrototypin! -ea nesses

• ;endency to abandon structured pro!ram developmentfor ?code$and$fi/8 development

• *ad reputation for ? uic $and$dirty8 methods

• @verall maintainability may be overloo ed

• ;he customer may want the prototype delivered#

• rocess may continue forever (scope creep)

8/17/2019 sdlc.pptx

23/48

-hen to useStructured .volutionary rototypin!

• :e uirements are unstable or have to be clarified

• As the re uirements clarification sta!e of a waterfall model

• Develop user interfaces

• Short$lived demonstrations

•

8/17/2019 sdlc.pptx

24/48

:apid Application Model (:AD)• :e uirements plannin! phase (a wor shop utili%in! structured

discussion of business problems)

• 5ser description phase = automated tools capture information fromusers

• Construction phase = productivity tools+ such as code !enerators+screen !enerators+ etc# inside a time$bo/# (?Do until done8)

• Cut over phase $$ installation of the system+ user acceptancetestin! and user trainin!

8/17/2019 sdlc.pptx

25/48

:AD Stren!ths• :educed cycle time and improved productivity with fewer people

means lower costs

• Customer involved throu!hout the complete cycle minimi%es risof not achievin! customer satisfaction and business needs

• ocus moves from documentation to code (-BS2-B0)#

• 5ses modelin! concepts to capture information about business+data+ and processes#

8/17/2019 sdlc.pptx

26/48

:AD -ea nesses• Accelerated development process must !ive uic responses to the

user

• :is of never achievin! closure

• >ard to use with le!acy systems

• Developers and customers must be committed to rapid$fireactivities in an abbreviated time frame#

8/17/2019 sdlc.pptx

27/48

-hen to use :AD

• 5ser involved throu!hout the life cycle

• ro"ect can be time$bo/ed

• unctionality delivered in increments

8/17/2019 sdlc.pptx

28/48

Timebo in% is a *lannin% techni+ue common in plannin% pro ects (typically forsoftware de$elopment), where the schedule is di$ided into a number ofseparate time periods (timebo es, normally two to si weeks lon%), with eachpart ha$in% its own deli$erables, deadline and bud%et. Timebo in% is a coreaspect of rapid application de$elopment (-& ) software de$elopmentprocesses such as dynamic systems de$elopment method ( / 0) and a%ilesoftware de$elopment.

Timebo es are used as a form of risk mana%ement, especially for tasks thatmay easily e tend past their deadlines. The end date (deadline) is one of theprimary dri$ers in the plannin% and should not be chan%ed as it is usually linkedto a deli$ery date of the product. If the team e ceeds the deadline, the teamfailed in proper plannin% and 1 or effecti$e e ecution of the plan. This can be theresult of2 the wron% people on the wron% ob (lack of communication betweenteams, lack of e perience, lack of commitment 1 dri$e 1 moti$ation, lack of

speed) or underestimation of the (comple ity of the) re+uirements

8/17/2019 sdlc.pptx

29/48

2ncremental SDLC Model• 3onstruct a partial

implementation of a totalsystem

• Then slowly add increasedfunctionality

• The incremental modelprioriti es re+uirements of thesystem and then implementsthem in %roups.

• 4ach subse+uent release ofthe system adds function tothe pre$ious release, until alldesi%ned functionality hasbeen implemented.

8/17/2019 sdlc.pptx

30/48

2ncremental Model Stren!ths

• Develop hi!h$ris or ma"or functions first• .ach release delivers an operational product

• Customer can respond to each build• 5ses ?divide and con uer8 brea down of tas s• Lowers initial delivery cost

• 2nitial product delivery is faster• Customers !et important functionality early• :is of chan!in! re uirements is reduced

8/17/2019 sdlc.pptx

31/48

2ncremental Model -ea nesses

• :e uires !ood plannin! and desi!n

• :e uires early definition of a complete and fullyfunctional system to allow for the definition ofincrements

• -ell$defined module interfaces are re uired (some willbe developed lon! before others)

• ;otal cost of the complete system is not lower

8/17/2019 sdlc.pptx

32/48

-hen to use the 2ncrementalModel• Most of the re uirements are nown up$front but are e/pected to

evolve over time

• A need to !et basic functionality to the mar et early

• @n pro"ects which have len!thy development schedules

• @n a pro"ect with new technolo!y

8/17/2019 sdlc.pptx

33/48

Spiral SDLC Model

• &dds risk analysis,and -& prototypin%to the waterfall model

• 4ach cycle in$ol$esthe same se+uence ofsteps as the waterfallprocess model

8/17/2019 sdlc.pptx

34/48

Spiral uadrantDetermine ob"ectives+ alternatives andconstraints

• @b"ectives functionality+ performance+hardwareEsoftware interface+ critical success factors+etc#

• Alternatives build+ reuse+ buy+ sub$contract+ etc#• Constraints cost+ schedule+ interface+ etc#

8/17/2019 sdlc.pptx

35/48

Spiral uadrant.valuate alternatives+ identify and resolve ris s

• Study alternatives relative to ob"ectives and constraints• 2dentify ris s (lac of e/perience+ new technolo!y+ ti!ht

schedules+ poor process+ etc#

• :esolve ris s (evaluate if money could be lost bycontinuin! system development

8/17/2019 sdlc.pptx

36/48

8/17/2019 sdlc.pptx

37/48

Spiral uadrantlan ne/t phase

• ;ypical activities – Develop pro"ect plan – Develop confi!uration mana!ement plan – Develop a test plan – Develop an installation plan

8/17/2019 sdlc.pptx

38/48

Spiral Model Stren!ths• rovides early indication of insurmountable ris s+ without much cost

• 5sers see the system early because of rapid prototypin! tools

• Critical hi!h$ris functions are developed first

• ;he desi!n does not have to be perfect

• 5sers can be closely tied to all lifecycle steps

• .arly and fre uent feedbac from users

• Cumulative costs assessed fre uently

8/17/2019 sdlc.pptx

39/48

Spiral Model -ea nesses• ;ime spent for evaluatin! ris s too lar!e for small or low$ris pro"ects

• ;ime spent plannin!+ resettin! ob"ectives+ doin! ris analysis andprototypin! may be e/cessive

• ;he model is comple/

• :is assessment e/pertise is re uired

• Spiral may continue indefinitely

• Developers must be reassi!ned durin! non$development phase activities

• May be hard to define ob"ective+ verifiable milestones that indicatereadiness to proceed throu!h the ne/t iteration

8/17/2019 sdlc.pptx

40/48

8/17/2019 sdlc.pptx

41/48

A!ile SDLC&s

• Speed up or bypass one or more life cycle phases• 5sually less formal and reduced scope• 5sed for time$critical applications• 5sed in or!ani%ations that employ disciplined methods

8/17/2019 sdlc.pptx

42/48

Some A!ile Methods

• Adaptive Software Development (ASD)• eature Driven Development ( DD)• Crystal Clear

• Dynamic Software Development Method (DSDM)• :apid Application Development (:AD)• Scrum•

./treme ro!rammin! (F )• :ational 5nify rocess (:5 )

8/17/2019 sdlc.pptx

43/48

Dynamic Systems Development Method(DSDM)

Applies a framewor for :AD and short time frames

aradi!m is the GHE3H rule

= ma"ority of the re uirements can be delivered in arelatively short amount of time#

8/17/2019 sdlc.pptx

44/48

DSDM rinciples1# Active user involvement imperative (Ambassador users)

3# DSDM teams empowered to ma e decisions

4# ocus on fre uent product delivery

6# roduct acceptance is fitness for business purpose

'# 2terative and incremental development $ to conver!e on a solution

7# :e uirements initially a!reed at a hi!h level

9# All chan!es made durin! development are reversible

G# ;estin! is inte!rated throu!hout the life cycle

I# Collaborative and co$operative approach amon! all sta eholders essential

8/17/2019 sdlc.pptx

45/48

DSDM Lifecycle

• easibility study• *usiness study = prioriti%ed re uirements•

unctional model iteration – ris analysis – ;ime$bo/ plan

• Desi!n and build iteration• 2mplementation

8/17/2019 sdlc.pptx

46/48

Adaptive Steps1# ro"ect initiali%ation = determine intent of pro"ect

3# Determine the pro"ect time$bo/ (estimation duration of the pro"ect)

4# Determine the optimal number of cycles and the time$bo/ for each

6# -rite an ob"ective statement for each cycle

'# Assi!n primary components to each cycle

7# Develop a pro"ect tas list

9# :eview the success of a cycle

G# lan the ne/t cycle

8/17/2019 sdlc.pptx

47/48

;ailored SDLC Models• Any one model does not fit all pro"ects

• 2f there is nothin! that fits a particular pro"ect+ pic a model thatcomes close and modify it for your needs#

• ro"ect should consider ris but complete spiral too much = startwith spiral J pare it done

• ro"ect delivered in increments but there are serious reliabilityissues = combine incremental model with the V$shaped model

• .ach team must pic or customi%e a SDLC model to fit its pro"ect

8/17/2019 sdlc.pptx

48/48