business analyst's view of sdlcmodels

8/13/2019 Business Analyst's View of Sdlcmodels

1/21

Business analysts view of software development life cycle models

General Approach...................................................................................................1Linear or Phased Approaches................................................................................1

Waterfall..............................................................................................................1V Model...............................................................................................................!ncremental "evelopment...................................................................................#

!terative Approaches...............................................................................................$%piral ..................................................................................................................$Microsoft %olutions &ramewor' ........................................................................11(ationale )nified Process.................................................................................1*

A+ile Approaches..................................................................................................1,(apid Application "evelopment........................................................................1,"%"M................................................................................................................1,-treme Pro+rammin+......................................................................................1$

General Approach

(e+ardless of the time an activity ta'es whether they are done simultaneously orin lon+ planned phases frau+ht with documentation and approvals/ the %"L0must answer certain uestions a2out the product 2ein+ developed.

What is the 2usiness pro2lem 2ein+ solved3 0oncept phase.What is the solution to that pro2lem3 (euirements4ow are we +oin+ to affect the solution3 Lo+ical "esi+nWhat are the elements of that solution3 Physical desi+n and codin+4ow do we 'now our solution is ri+ht3 )nit/ inte+ration and system testin+4ow do we 'now we have the ri+ht solution3 Acceptance testin+Will it wor' in the environment with the actual users3 !mplementation

-ach of the life cycle models includes activities/ tas's/ or phases that answerthese uestions/ althou+h not necessarily in the direct format +iven a2ove.

Linear or Phased Approaches

Waterfall

While the Waterfall Model presents a strai+htforward view of the software lifecycle/ this view is only appropriate for certain classes of software development.%pecifically/ the Waterfall Model wor's well when the software reuirements are


2/21

well understood 5e.+./ software such as compilers or operatin+ systems6 and thenature of the software development involves contractual a+reements. 7heWaterfall Model is a natural fit for contract82ased software development sincethis model is document driven9 that is/ many of the products such as thereuirements specification and the desi+n are documents. 7hese documents

then 2ecome the 2asis for the software development contract.

7here have 2een many waterfall variations since the initial model was introduced2y Winston (oyce in 1:;< in a paper entitled= >mana+in+ the development oflar+e software systems= concepts and techniues?. Barry Boehm/ developer of

the spiral model 5see 2elow6 modified the waterfall model in his 2oo' Software

Engineering Economics (Prentice-Hall, 1987). 7he 2asic differences in thevarious models is in the namin+ and@or order of the phases.

7he 2asic waterfall approach loo's li'e the illustration 2elow. -ach phase isdone in a specific order with its own entry and eit criteria and provides the

maimum in separation of s'ills/ an important factor in +overnment contractin+.

-ample of a typical waterfall approach

While some variations on the waterfall theme allow for iterations 2ac' to theprevious phase/ >!n practice most waterfall proects are mana+ed with theassumption that once the phase is completed/ the result of that activity is cast inconcrete. &or eample/ at the end of the desi+n phase/ a desi+n document isdelivered. !t is epected that this document will not 2e updated throu+hout the


3/21

rest of the development. ou cannot clim2 up a waterfall.? 5Murray 0antor/C2ect8oriented proect mana+ement with )ML/ Dohn Wiley/ 1::$6

7he waterfall is the easiest of the approaches for a 2usiness analyst to

understand and wor' with and it is still/ in its various forms/ the operational %L0in the maority of )% !7 shops. 7he 2usiness analyst is directly involved in thereuirements definition and@or analysis phases and peripherally involved in thesucceedin+ phases until the end of the testin+ phase. 7he 2usiness analyst isheavily involved in the last sta+es of testin+ when the product is determined tosolve the 2usiness pro2lem. 7he solution is defined 2y the 2usiness analyst inthe 2usiness case and reuirements documents. 7he 2usiness analyst is alsoinvolved in the inte+ration or transition phase assistin+ the 2usiness communityto accept and incorporate the new system and processes.


4/21

V Model

7he EVE model 5sometimes 'nown as the E)E model6 reflects the approach tosystems development where in the definition side of the model is lin'ed directlyto the confirmation side. !t specifies early testin+ and preparation of testin+

scenarios and cases 2efore the 2uild sta+e to simultaneously validate thedefinitions and prepare for the test sta+es.

!t is the standard for German federal +overnment proects and is considered asmuch a proect mana+ement method as a software development approach.

>7he V Model/ while admittedly o2scure/ +ives eual wei+ht to testin+ rather thantreatin+ it as an afterthou+ht. !nitially defined 2y the late Paul (oo' in the late1:$7he&or+otten Phase?/ %oftware development/ Duly J


5/21

-ample of a typical V Model 5!---6

7he primary contri2ution the V Model ma'es is this ali+nment of testin+ andspecification. 7his is also an advanta+e to the 2usiness analyst who can use themodel and approach to enforce early consideration of later testin+. 7he V Model

emphasiKes that testin+ is done throu+hout the %"L0 rather than ust at the endof the cycle and reminds the 2usiness analyst to prepare the test cases andscenarios in advance while the solution is 2ein+ defined.

7he 2usiness analysts role in the V Model is essentially the same as thewaterfall. 7he 2usiness analyst is involved full time in the specification of the2usiness pro2lem and the confirmation and validation that the 2usiness pro2lemhas 2een solved which is done at acceptance test. 7he 2usiness analyst is alsoinvolved in the reuirements phases and advises the system test sta+e which istypically performed 2y independent testers the uality assurance +roup orsomeone other than the development team. 7he primary 2usiness analyst

involvement in the system test sta+e is 'eepin+ the reuirements updated aschan+es occur and providin+ >voice of the customer? to the testers anddevelopment team. 7he rest of the test sta+es on the ri+ht side of the model aredone 2y the development team to ensure they have developed the productcorrectly. !t is the 2usiness analysts o2 to ensure they have developed thecorrect product.

%ystemreuirements

%u2systemreuirements

%u2systemdesi+n

0ode

)nittest

!nte+rationtest

%u2systemtest

%ystemtest

Acceptancetest

0oncept ofoperations

)nitdesi+n

%ystem

%u2system

)nit


6/21

!ncremental "evelopment

7he !ncremental approach is a +eneric method of deliverin+ a wor'in+ part of a

total product or solution. !t is the 2asis of most a+ile and iterative methodsincludin+ (ational )nified Process 5()P6. 7he a+ile concept of >time2oin+?/adapted from !BM/ is an incremental delivery approach.

%imilar to the V model/ incremental development is as much a mana+ementapproach to software development as a development approach/ pro2a2ly moreso. >!ncremental development is a schedulin+ and sta+in+ techniue nicely suitedto proects usin+ technolo+y and techniues new to an or+aniKation... !t isN aschedulin+ and sta+in+ strate+y that allows pieces of the system to 2e developedat different times or rates and inte+rated as they are completed. %pecificallyintended is that 2etween increments/ additions could 2e made to the

reuirements/ process chan+es could 2e incorporated/ or the schedule could 2eimproved and revised. !ncremental is distin+uished from iterative development inthat the latter supports Epredicted rewor'E of parts of the system. A +ood +rasp ofincremental development helps in applyin+ iterative development...? 5Alistair0oc'2urn/ >)nravelin+ incremental development?6

%ta+ed "elivery

7he sta+ed delivery model initially advanced 2y 7om Gil2 and later championed2y %teve Mc0onnell applies the principles of incremental delivery to the waterfall

model. !t s a development approach that emphasiKes proect plannin+ and ris'reduction 2y usin+ multiple software releases.

"urin+ the first phases of the sta+ed delivery process/ the overall pro2lem isdefined and the solution specified. 7he second phase consists of creatin+ anarchitecture for the overall solution. After that the product is partitioned intointerim or successive deliveries and each delivery +oes throu+h its owndevelopment life cycle as shown in the dia+ram 2elow. 7he +oal of each sta+e isto advance toward a complete and ro2ust product on time and within 2ud+et.7ypically each sta+e has its own 2ud+et and delivera2le schedule that may 2erefined 2ased on previous delivera2les. 7he duration of each successive sta+e is

+enerally similar. 7he num2er of planned sta+es for achievin+ a final release isdependent upon the functionality/ application compleity/ and so forth.


7/21

-ample of the sta+ed approach 5&rom %teve Mc0onnell/ %oftware Proect%urvival Guide/ Microsoft Press6

At the core of successful sta+ed delivery is the customer review that occurs2etween sta+es and is typically 2ased on usin+ the software in the 2usinessenvironment. 7his is what Alistair 0oc'2urn calls the >2reathin+ space?. !t allows

for customer feed2ac' and adustments to the architect/ reuirements/ andprocess for successive sta+es.

7he sta+ed and any incremental delivery approach poses etra challen+es forthe 2usiness analyst. After the pro2lem has 2een defined and the productreuirements specified/ the 2usiness analyst then may 2e handlin+ reuirementschan+es for multiple sta+es/ or addressin+ the user or sta'eholder feed2ac' frompreviously installed software while assistin+ with the development and testin+ ofsucceedin+ sta+es. -specially when multiple development teams are involved/the 2usiness analyst activities in a sta+ed or incremental delivery life cycle are2est handled in a team effort with multiple 2usiness analysts assi+ned to different

sta+es and product delivera2les.

%oftware

concept

(euirements

analysis

Architectural

desi+n

%ta+e 1= "etailed desi+n/ code/ de2u+/ test/ anddelivery

%ta+e n= "etailed desi+n/ code/ de2u+/ test/ anddelivery

%ta+e J= "etailed desi+n/ code/ de2u+/ test/ anddelivery


8/21

Iterative Approaches

%piral

7he spiral model was defined 2y Barry Boehm/ now at the )niversity of %outhern0alifornia/ as an early eample of an iterative approach to software development.!t was not the first model to discuss iteration/ 2ut it was the first model to eplainwhy the iteration matters. As ori+inally envisioned/ the iterations were typically #months to J years lon+.

-ach phase of the spiral starts with a desi+n +oal 5such as a user interfaceprototype as an early phase6 and ends with the client 5which may 2e internal6reviewin+ the pro+ress and determinin+ if the net spiral will ta'e place.

7he primary difference 2etween the spiral model and the other life cycle models

is the emphasis of ris' assessment as evidenced 2y the illustration 2elow. -achcycle throu+h the phases ends with an evaluation 2y the customer and anassessment of the ris' of +oin+ ahead with the net iteration or stoppin+ andcompletin+ the delivery of the product.

Cnce the product is deemed ready for development 2ased on customer feed2ac'and ris' assessment/ the process 2ecomes a standard waterfall approach. 7hedifference is that the hi+h level desi+n and specifications have 2een completedand the construction phase has a prototype to follow. 7his ma'es theimplementation faster and of hi+her uality.

While the spiral model in its pure form is not used much outside the ).%. Military/it sets the pattern for most of the a+ile and iterative approaches that follow it.7here are also a multitude of >spiral? variations for all or parts of the solution lifecycle such that spiral has almost 2ecome synonymous with iterative.


9/21

-ample of the spiral model 5from Boehm/ B.W.A Spiral Model of Software

Development and Enhancement. !--- %oftware -n+ineer and ProectMana+ement/ 1:$;6

7he steps in the spiral model can 2e +eneraliKed as follows=

1. 7he new system reuirements are defined in as much detail as possi2le.7his usually involves interviewin+ a num2er of users representin+ all theeternal or internal users and other aspects of the eistin+ system.

J. A preliminary desi+n is created for the new system.*. A first prototype of the new system is constructed from the preliminary

desi+n. 7his is usually a scaled8down system/ and represents anapproimation of the characteristics of the final product.

. A second prototype is evolved 2y a fourfold procedure= 516 evaluatin+ thefirst prototype in terms of its stren+ths/ wea'nesses/ and ris's9 5J6 definin+the reuirements of the second prototype9 5*6 plannin+ and desi+nin+ thesecond prototype9 56 constructin+ and testin+ the second prototype.

(ts plan

Life8cycle

plan

0oncept of

operation

Pro+ress

throu+h

steps

(

A

"evelopmenttplan (e1uirements

validation

Proto

8type

!nte+rationandtestplan

"esi+n validation

and verification

%oftware

product

desi+n

Prototype Prototype

Cperational

prototype

(is' analysis

(is' analysis

(is' analysis

0umulative cost

0ommitment

Partition

(eview

Plan netphases

!mplemen8

tation

Acceptance

test

!nte+ration

and test

)nit

test

0ode

"etailed

desi+n

-valuatealternatives/identity/ resolve ris's"etermine

o2ectives/alternatives/constraints

"evelop/ verifynet8levelproduct

%imulations/models/2enchmar's

0om

Cps

%oftware

reuirements


10/21

,. At the customers option/ the entire proect can 2e a2orted if the ris' isdeemed too +reat. (is' factors mi+ht involve development cost overruns/operatin+8cost miscalculation/ or any other factor that could/ in thecustomers ud+ment/ result in a less8than8satisfactory final product.

#. 7he eistin+ prototype is evaluated in the same manner as was the

previous prototype/ and/ if necessary/ another prototype is developed fromit accordin+ to the fourfold procedure outlined a2ove.;. 7he precedin+ steps are iterated until the customer is satisfied that the

refined prototype represents the final product desired.$. 7he final system is constructed/ 2ased on the refined prototype.:. 7he final system is thorou+hly evaluated and tested. (outine maintenance

is carried out on a continuin+ 2asis to prevent lar+e8scale failures and tominimiKe downtime.

7he 2usiness analysts role in the spiral is further etended into the developmentlife cycle. !n addition to the reuirements definition and liaison activities/ the2usiness analyst is typically uite involved with the prototypin+ efforts and theris' assessment sta+es. 7he 2usiness analyst also wor's with the customerdurin+ the evaluations and sometimes represents the customer in evaluatin+ theapplica2ility of the product at that point.


11/21

Microsoft %olutions &ramewor'

>MicrosoftO %olutions &ramewor' 5M%&6 is a deli2erate and disciplined approachto technolo+y proects 2ased on a defined set of principles/ models/ disciplines/

concepts/ +uidelines/ and proven practices from Microsoft... 7he M%& is aniterative approach created 2y Microsoft for the development of its operatin+systems and productivity software pac'a+es. M%& helps teams directly addressthe most common causes of technolo+y proect failure in order to improvesuccess rates/ solution uality/ and 2usiness impactI 0reated to deal with thedynamic nature of technolo+y proects and environments/ M%& fosters the a2ilityto adapt to continual chan+e within the course of a proect.? 5Microsoft SolutionsFramework Version 3.0 Overview/ Microsoft 0orporation/ Dune J


12/21

M%& is similar to P 5see 2elow6 with similar principles and methods. 7helan+ua+e is different reflectin+ the difference in o2ectives 2etween the mar'et8oriented structure of M%& and the development oriented approach of P.

7he core M%& principles are

&oster open communications Wor' toward a shared vision

-mpower team mem2ers

-sta2lish clear accounta2ility and shared responsi2ility

&ocus on deliverin+ 2usiness value

%tay a+ile/ epect chan+e

!nvest in uality

Learn from all eperiences

7here is also a heavier emphasis on release mana+ement in the M%& than with

other a+ile approaches.

>7he M%& Process Model is 2ased on phases and milestones. At one level/phases can 2e viewed simply as periods of time with an emphasis on certainactivities aimed at producin+ the relevant delivera2les for that phase. 4owever/M%& phases are more than this9 each has its own distinct character and the endof each phase represents a chan+e in the pace and focus of the proect. 7hephases can 2e viewed successively as eploratory/ investi+atory/ creative/sin+le8minded/ and disciplined. Milestones are review and synchroniKation pointsfor determinin+ whether the o2ectives of the phase have 2een met. Milestonesprovide eplicit opportunities for the team to adust the scope of the proect to

reflect chan+in+ customer or 2usiness reuirements and to accommodate ris'sand issues that may materialiKe durin+ the course of the proect. >5MicrosoftSolutions Framework Version 3.0 Overview/ Microsoft 0orporation/ Dune J


13/21

(ationale )nified Process

7he (ational )nified Process 5()P6 was developed 2y !var Daco2son/ GradyBooch and Dim (um2au+h at (ational %oftware 0orporation after they had

defined the )nified Modelin+ Lan+ua+e 5)ML6. Both the )ML and the )nifiedProcess were handed over to the C2ect Mana+ement Group 5CMG6 to 2eesta2lished as o2ect8oriented development standards. 7he approach assumesthe development will 2e done usin+ o2ect8oriented analysis/ desi+n andpro+rammin+ as a 2asis.

>()P is a software en+ineerin+ process. !t provides a disciplined approach toassi+nin+ tas's and responsi2ilities within a development or+aniKation. !ts +oal isto ensure the production of hi+h8uality software that meets the needs of its endusers within a predicta2le schedule and 2ud+etI 7he (ational )nified Processis also a process framewor' that can 2e adapted and etended to suit the needs

of an adoptin+ or+aniKation.? 5Philiippe Frutchen/ !" an introduction# 3rd

edition/Addison8Wesley/ J


14/21

-ample of the (ational )nified Process 5&rom (ational %oftware6

7he ()P is a use8case driven/ )ML82ased iterative development approach thatdelivers software incrementally.

7he 2usiness analyst is usually deeply involved as the >voice of the customer?throu+hout all the iterations and phases/ more so/ of course/ in the inception andela2oration phases.


15/21

Agile Approaches

(apid Application "evelopment

(apid Application "evelopment 5(A"6 is also a +eneric term for a ran+e ofevolutionary prototypin+ approaches. Many of the approaches have 2eendeveloped over the years and are used within or+aniKations and 2y consultin+firms to produce software results on a more rapid 2asis than the structured linearmethods. (A" is now in vo+ue due to the increasin+ demand for we282asedsoftware to 2e developed at hi+h speed.

Most (A" approaches nowadays are o2ect8oriented 2ecause of the rapidityo2ect8oriented lan+ua+es and tools provide. 4owever/ (A" approaches have2een successfully applied to speed up structured analysis/ desi+n andpro+rammin+ efforts.

"%"M

7he "ynamic %ystems "evelopment Method is a framewor' of controls for thedevelopment of !7 systems to ti+ht timescales. !t is independent of any particularset of tools and techniues. !t can 2e used with o2ect8oriented and structuredanalysis and desi+n approaches in environments ran+in+ from the individual P0to +lo2al distri2uted systems. "%"M has 2een used successfully 2yor+aniKations in 2oth the pu2lic and private sectors.

"%"M provides a +eneric process which must 2e tailored for use in a particular

or+aniKation dependent on the 2usiness and technical constraints. "%"Moutlines a five phase process=

8 &easi2ility %tudy7he feasi2ility study assesses the suita2ility of the application for a (A"approach and chec's that certain technical and mana+erial conditions are li'elyto 2e met. 7he feasi2ility study typically lasts a matter of wee's

8 Business study7he 2usiness study scopes the overall activity of the proect and provides asound 2usiness and technical 2asis for all future wor'. 7he hi+h8level functional

and non8functional reuirements are 2aselined/ a hi+h8level model of the2usiness functionality and information reuirements is produced/ the systemarchitecture is outlined and the maintaina2ility o2ectives are a+reed

8 &unctional model iteration7he 2ul' of development wor' is in the two iteration phases where prototypes areincrementally 2uilt towards the tested system which is placed in the userenvironment durin+ the implementation phase


16/21

8 "esi+n and 2uild iteration"urin+ the desi+n and 2uild iteration/ the focus is on ensurin+ that the prototypesare sufficiently well en+ineered for use in the operational environment

8 !mplementation!mplementation consists of puttin+ the latest increment into the operationalenvironment and trainin+ the users. 7he final step in implementation is a reviewof what has 2een achieved

Principles of "%"M=8 Active user involvement is imperative8 "%"M teams must 2e empowered to ma'e decisions8 7he focus is on freuent delivery of products8 &itness for 2usiness purpose is the essential criterion for acceptance of

delivera2les!terative and incremental development is necessary to conver+e on an accurate2usiness solution

All chan+es durin+ development are reversi2le(euirements are 2aselined at a hi+h level7estin+ is inte+rated throu+hout the life8cycle

A colla2orative and co8operative approach 2etween all sta'eholders is essential

Businessstudy

&unctionalmodel

iteration "esi+n and2uild

iteration

!mplementation

"%"M=processoverview

&easi2ility


17/21

-ample of "%"M process 5from %tapleton/ Dennifer. DSDM$ %he Method in"ractice. Addison8Wesley6


18/21

-treme Pro+rammin+

-treme Pro+rammin+ 5P6 is the poster child for the a+ile approaches. 7heprocess was developed 2y Fent Bec'/ Ward 0unnin+ham and (on Deffries.

When people thin' of a+ile they usually thin' in terms of P. -tremePro+rammin+ 5P6 is a software development methodolo+y that represents athrow2ac' to the very earliest and purest days of software development whentechnicians ran the show. 7hen/ software en+ineers enoyed +reater autonomylar+ely 2ecause there were few in the mana+ement ran's who understood thetas' at hand.P is the hi+hest ris' approach and reuires the +reatest s'ill/ 'nowled+e andeperience to run it successfully. Accordin+ to the founders/ all the principles ofP must 2e adhered to in order to 2e successful9 adaptin+ several of theprinciples and tryin+ to do P will not wor'.

-ample P Process

7he P process as shown a2ove starts with a proects reuirements which arelaid out as individual stories typically written on *, cards. 7hese stories havetest cases which are written 2y the customer and developer wor'in+ as a team. Atest case includes the test and the desired results which/ if met/ indicate that thatstory is complete.


19/21


20/21

P Principles

7he followin+ principles from Fent Bec's 2oo' -treme Pro+rammin+ -plainedconstitute the essence of P. Many are the same as principles already

descri2ed for other a+ile processes or in +eneral. %ome were initiated 2y P andsome were adopted 2y P.

1. 7he Plannin+ Game= Business and development cooperate to produce themaimum 2usiness value as rapidly as possi2le. 7he plannin+ +ame happens atvarious scales/ 2ut the 2asic rules are the same=

Q Business comes up with a list of desired features for the system. -ach featureis written out as a )ser %tory/ which +ives the feature a name/ and descri2es in2road stro'es what is reuired. )ser stories are typically written on # cards.

Q "evelopment estimates how much effort each story will ta'e/ and how mucheffort the team can produce in a +iven time interval.Q Business then decides which stories to implement in what order/ as well aswhen and how often to produce a production release of the system

J. %mall (eleases= P teams practice small releases in two important ways=

&irst/ the team releases runnin+/ tested software/ deliverin+ 2usiness valuechosen 2y the 0ustomer/ every iteration. 7he 0ustomer can use this software forany purpose/ whether evaluation or even release to end users. 7he mostimportant aspect is that the software is visi2le/ and +iven to the customer/ at the

end of every iteration. %econd/ P teams release to their end users freuently aswell. P We2 proects release as often as daily/ in house proects monthly ormore freuently.

*. %imple "esi+n= P uses the simplest possi2le desi+n that +ets the o2 done.7he reuirements will chan+e tomorrow/ so only do whats needed to meettodays reuirements. "esi+n in P is not a one8time thin+ 2ut an all8the8timethin+. 7here are desi+n steps in release plannin+ and iteration plannin+/ plusteams en+a+e in uic' desi+n sessions and desi+n revisions throu+h refactorin+/throu+h the course of the entire proect.

. Metaphor= -treme Pro+rammin+ teams develop a common vision of how thepro+ram wor's/ which we call the EmetaphorE. At its 2est/ the metaphor is asimple evocative description of how the pro+ram wor's. P teams use acommon system of names to 2e sure that everyone understands how the systemwor's and where to loo' to find the functionality youre loo'in+ for/ or to find theri+ht place to put the functionality youre a2out to add.


21/21

,. 0ontinuous 7estin+= P teams focus on validation of the software at all times.Pro+rammers develop software 2y writin+ tests first/ and then code that fulfills thereuirements reflected in the tests. 0ustomers provide acceptance tests thatena2le them to 2e certain that the features they need are provided.

#. (efactorin+= P 7eam (efactor out any duplicate code +enerated in a codin+session. (efactorin+ is simplified due to etensive use of automated test cases.

;. Pair Pro+rammin+= All production code is written 2y two pro+rammers sittin+ atone machine. 7his practice ensures that all code is reviewed as it is written andresults in 2etter desi+n/testin+/ and code.%ome pro+rammers o2ect to pair pro+rammin+ without ever tryin+ it. !t does ta'esome practice to do well/ and you need to do it well for a few wee's to see theresults. Hinety percent of pro+rammers who learn pair pro+rammin+ prefer it/ soit is recommended to all teams. Pairin+/ in addition to providin+ 2etter code andtests/ also serves to communicate 'nowled+e throu+hout the team.

$. 0ollective 0ode Cwnership= Ho sin+le person EownsE a module. Any developeris epected to 2e a2le to wor' on any part of the code2ase at any time.

:. 0ontinuous !nte+ration= All chan+es are inte+rated into the code2ase at leastdaily. 7he unit tests have to run 1

business analyst's view of sdlcmodels

Documents