waterfall managing the development of large software systems royce

8/3/2019 Waterfall Managing the Development of Large Software Systems Royce

1/11

M A N A G I N G T H E D E V E L O P M E N T O F L A R G E S O F T W A R E S Y S T E M SDr. Winston W. Rovce

I N T R O D U C T I O Nl am going to d escr ibe my pe,- .~onal v iews abou t man aging large softwa re de velop men ts. I have had

var ious assignments dur in g the past nit , .: years, mo st ly co ncerned wi th the de velo pm ent of softwa re packagesfor spacecraft mission plann ing, comm and ing and post- f l ig ht analysis. In these assignments I have exper ie nceddi f fe ren t degrees of success with respect to arr iv ing at an ope rat io nal state, on-t im e, and wi th in costs. I havebecom e prejudiced by my expe r iences and I am going to relate some of these prejudices in this presentat io n.C O M P U T E R P R O G R A M D E V E L O P M E N T F U N C T I O N S

There are two essent ial s teps com mo n to al l comp ute r pro gram d evelo pme nts, regardless of s ize orcom ple xi ty . There is f i rs t an analysis step, fol low ed second by a codin g step as dep icted in Figu re 1. This sortof very s imple imple men tat ion concep t i s in fac t a ll that i s requi red i f the ef fo r t is suf f i c ient ly smal l and i f thef inal produ c t i s to be operated by those wh o b ui l t i t - as is typic al l y done wi th com pute r programs for internaluse. I t i s a lso the k ind of dev elopm ent ef for t for wh ich most cus tomers are happ y to pay , s ince both s tepsinvolve genuine ly c reat ive work which d i rec t ly co nt r ibutes to the usefulness of the f inal prod uc t . Animple men tat ion p lan to manu fac ture 13rger sof tware systems, and keyed o nly to these steps, h owever , i s doo med

tofa i lur e. Many ad di t iona l deve lopme nt s teps are requi red, none cont r ibute as d i rec t ly to the f inal produ c t asanalys is and coding, and all dr ive up the deve lopm ent cos ts . Cus tomer p ersonnel typic al l y wou ld rather not payfo r t hem, and dev e lopment per sonne l wou ld r a ther no t imp leme nt t hem. The p r ime f unc t i on o f managementis to sel l these concepts to bo th groups and then enforce comp l iance on the par t of d evelop men t personnel .

A N A L Y S I S

C O D I N G

Figure 1. Imp leme ntat ion steps to del iver a smal l com pute r program fo r internal operat ions .

A more grandiose approach to sof tware de velopm ent i s i l lus t rated in Figure 2. The analys is and codingsteps are st i l l in the p icture, but they are preceded by tw o levels of require men ts analysis, are separated by aprogram design step, and fol lo we d by a test ing step. These add i t ion s are treated separately f rom analysis andcoding because they are d is t inc t ly d i f feren t in the way they are executed. They must be p lanned and s taf feddi f ferent ly for bes t ut i l i zat ion of program resources .

Figure 3 portrays the i terat ive relat ionship between successive development phases for this scheme.The ord er ing o f steps is based on the fo l lo wi ng co ncep t: that as each step progresses and the design is fur th erdetai led, there is an i terat ion w i th the preceding and succeeding steps but rare ly wi th the m ore rem ote s teps inthe sequence. The v ir tue o f al l of this is that as the design proceeds the change process is scoped dow n tomanageable l imi ts. At any po int in the design process af ter the requ ireme nts analysis is com plete d there existsa f i rm and c~seup~ mov ing basel ine to whi ( :h to ~ tu rn in the event of unforeseen des ign di f f i cu l t ies . What wehave is an ef fec t ive fa l lback pos i t ion that tends to max im ize the ex te nt of ear ly work that i s salvageable andpreserved.

Reprinted from Proceedings, IEEE WESCON, August 19 70, pages 1-9.Co_pyright 1_9_70 by The Institute of Electrical and Electronics Et)gineers,, .3 28Inc. Originally published by TRW.


2/11

I S Y S T E

I A N A L Y S I SP R O G R A MD E S I G N

I c o o , . oT E S T I N G

I O P E R A T I O N SFigure 2. Imple me ntat io n s teps to deve lop a large comp uter program for de l ivery to a cus tomer .

I believe in th is concept , b ut the im plem enta t ion described above is ri sky and inv i tes fa i lure. Theprob lem is i l lustrate d in Figure 4. The test ing phase wh ich occurs at the end of the devel opm ent cycle is thef i rs t event for w hich t iming, s torage, inp ut / ou tpu t t rans fers , etc. , are exper ienced as d is t inguished f romanalyzed. These pheno mena are not prec isely analyzable. They are not the solut ions to the s tandard par t ia ld i f feren t ia l equat ions of m athema t ical phys ics for ins tance. Yet i f these phenome na fa il to sat is fy the var iousextern al constraints, then invar iably a majo r redesign is required. A s imple octal patch or red o of some isolatedcode wi l l not f i x these k inds of d i f f i cu l t ies . The requi red des ign changes are l ike ly to be so d is rupt ive that thesof tware requi rements upo n wh ich the des ign is based and which prov ides the rat ionale for every th ing areviolated . Ei th er the requireme nts must be mo dif ie d, or a substant ial change in the design is require d. In ef fectthe developm ent process has returned to the or ig in and one can expec t up to a lO0-percen t over run in scheduleand /or costs.

One m ight note tha t there has been a skipping-o ver of the analysis and code phases. One ca nno t, ofcourse, produ ce softw are w ith ou t these steps, bu t g eneral ly these phases are managed wi th relat ive ease andhave l i t t le impa c t on requi rements , des ign, and tes t ing. In my exper ience there are who le depar tm entsconsumed wi th the analys is of orb i t mechanics , spacecraf t at t i tude determinat ion, mathemat ical opt imizat ionof pay load ac t iv i ty and so for th, but when these depar tments have completed thei r d i f f i cu l t and complex work ,the resul tant program s teps invo lvea few l ines of ser ia l ar i thm et ic code. I f in the execut ion of th ei r d i f f i c u l tand comp lex work the analys ts have made a mis take, the cor rec t ion is invar iably im pleme nted by a min orchange in the code wi th no dis rupt ive feedback into the o ther dev elopm ent bases .

Howe ver , I bel ieve the i l lus t rated approach to be fundam enta l ly sound. The remainde r of th isdiscuss ion presents f ive add i t ional features that must be added to th is bas ic approach to e l iminate most of thedevelopment r isks.

329


3/11

I S Y S T E M !R E Q U I R E M E N T S I B I ~~ " ' i s o , w . , ~ I

A N A L Y S I S~ 1 1 1 1 ~ p R I~O G R A M~ l l l I C O D I N G I i

T E S T I N G

O P E R A T I O N SF i g u r e 3 . H o p e f u l ly , h e ~ te ra t= v en t e r a c t = o nb e t w e e n h e v a r io u s p h a s e s s c o n f in e d to s u c c e ss iv e te p s .

I S Y S T E M "1. ~ o o , . ~ - , . . S l . , ~I s o , w . . ~ ! .

I A N A L Y S I SPROGRAMDESIGN

I c o o ,.G I , ~! T E S T I N G II O A T O . S

F i g u r e 4 . U n f o r t u n a t e l y , o r th e p r o c e s s l lu s t r a t e d , h e d e s i g n te r a t i o n s a r e n e v e rc o n f i n e d t o t h e s u c c e ss iv e te p s .3 3 0


4/11

STEP 1: P ROGRA M DESIGN COMES FIRSTThe f i rs t s tep toward s a f ix is i l lustrate d in Figu re 5. A p rel im ina ry progra m design phase has been

inserted between the so ftware re quirem ents gener at ion phase and the analysis phase. This proce dure can becr i t ic ized on the basis that the program designer is forced to design in the relat ive vacuum of ini t ial sof twarerequi rements wi th ou t any ex is t ing analys is . .As a resul t, h is pre l iminary des ign may be subs tant ia l l y in er ror ascompa red to his design i f he were to wa i t u nt i l the analysis was com plete . This cr i t ic ism is correct b ut i t missesthe po int . By this techn ique the prog ram designer assures that the software wi l l n ot fai l because of storage,t iming, and data f lu x reasons. As the analysis proceeds in the succeeding phase the prog ram designer mustimpose on the a nalyst the storage, t imin g, and ope rat io nal constraints in such a wa y tha t he senses theconsequences . When he jus t i f iably requi res more of th is k ind of resource in order to implem ent h is equat ionsi t must be s imu ltane ously snatched from his analyst comp atr iot s. In this way al l the analysts and al l theprogram des igners wi l l cont r ib ute to a meaningful des ign process which wi l l cu lminate in the proper a l locat ionof ex ecu t ion t ime and storage resources. I f the total resources to be appl ied are insu ff ic ien t or i f the emb ryoopera t ional design is wron g i t wi l l be recognized at th is ear l ier s tage and the i terat ion wi t h requhem ents andprel iminary design can be redone before f inal design, coding and test commences.

How is th is procedure implemen ted? The fo l lo win g s teps are requi red.1) Begin the design process wit h program designers, not a nalysts or program mers.2) Design, def i ne and al locate the data processing modes even at the r isk of being wrong. Al lo cate

processing, funct ions, design the data base, def ine data base processing, al locate execut ion t ime, def ineinterfaces and processing modes wi th the ope rat ing system, describe inpu t and ou tpu t processing, and def ineprel iminary operat ing procedures .

3) Wr i te an overv iew doc ume nt that is unders tandable, in form at ive and current . Each and everywor ker must have an elemental unders tanding of the system. At leas t one person must have a deep unders tand-ing of the system which comes par t ia l l y f rom hav ing had to wr i te an overv iew docum ent .

/ ALLOCATE ~ A DESCRIBE/ s O ..o O O ,,./ c %

IFigure 5. Step 1 : Insure that a prel imin ary p rogram des ign is comp lete before analys is begins .

331


5/11

STEP2: DOCU MENT THE DESI GNAt th is point i t is approp r iate to raise the issue of - "h ow much do cum ent at io n? " My ow n v iew is

"qu i te a lo t ; " cer ta in ly m ore than most programmers , analys ts, or program des igners are wi l l in g to do i f le f t tothei r own dev ices . The f i rs t ru le of managing sof tware developm ent is ruth less enforce men t of docu me ntat io nrequi rements .

O ccasion al ly I am cal led upon to review the progress of oth er softwa re design ef for ts. My f i rs t s tep isto inves t igate the s tate of the docu men tat ion , I f the docum enta t ion is in ser ious defau l t my f i rs trecom men dat ion is s imple. Replace projec t management . Stop al l ac t iv i t ies not re lated to docu me ntat i on.Br ing the doc ume ntat io n up to acceptable s tandards. Manage ment of sof tware is s imply impo ss ib le w i th o ut avery h igh degree of docum enta t ion. As an example, le t me of fer the fo l low ing es t imates for comp ar ison. Inorder to procure a 5 mi l l io n dol lar hardware dev ice, I wo uld expec t that a 30 page spec i f i cat ion wou ld prov ideadequate de ta i l t o c on t r o l t he p roc urement . I n o rder t o p roc ure 5 m i l l i on do l l a rs o f s o ftware Iw ou ld es t imate~ 1[ ,00 pa~e spec i f i cat ion is about r ight in order to achieve comparable co nt ro l ,

Why s o much doc um enta t i on?1) Each des igner must com mun icate wi th inter fac ing designers , wi th h is manage ment and poss ib ly

wi th thecus to rner . A verbal record is too intangib le to prov ide an adequate basis for an inter face or manage-men tdec is ion. An acceptable wr i t te n de scr ipt ion forces the des igner to take an unequ ivocal pos i t ion andprov ide t ang ib le ev idenc e o f c omple t i on . I t p rev en ts t he des igner f r om h id i ng beh ind t he - " l am90 -perc en tf i n i s hed" - s y ndrome month a f t e r month .

2) Dur ing the ear ly phase of sof tware d evelo pme nt the do cum ent at io n .s the spec i f i cat ion and ._~.s hedesign. Unt i l coding begins these three nouns (docu men tat ion, spec i f i cat ion, des ign) de no tea s in gte th i ng . I fthe docu men tat ion is bad the design is bad. I f the docu men tat io n does not yet ex is t there is as yet no des ign,only people th ink ing and ta lk ing about the des ign which is of some value, but not much.

3) The real mon etary value of good doc ume ntat io n begins down st ream in the deve lopm ent processdur ing the tes t ing phase and cont inues through operat ions and redes ign. The value of docu me nta t ion can bedescr ibed in terms of three concrete, tangible s i tuat ions that every program manager faces.

a) Dur ing the tes t ing phase, wi th good docum ent at ion the manager can concent rate personnel on themis takes in the program. Wi tho ut good doc um enta t ion every mis take, large or smal l , is analyzed by one manwh o prob ably made the mis take in the f i rs t p lace because he is the on ly man wh o unders tands the p rogram area.

b) Dur ing the operat ion al phase, wi th good docu me ntat i on the manager can use ope rat ion -or ien tedpersonnel to operate the program and to do a bet ter job, cheaper. Wi th out good doc um enta t ion the sof twa remust be operated by those who b ui l t i t . Gene ral ly these people are re lat ively d is interes ted in operat ion s and donot do as ef fec t ive a job as operat ions-o r iented personnel . I t should be pointed o ut in th is con nec t io n that inan operat iona l s i tuat ion, i f there is some hangup the sof tware is a lways blamed f i rs t. In order e i ther to absolvethe sof tware or to f i x the b lame, the sof tware documentat ion must speak c lear ly .

c ) Fol low ing in i t ia l operat ions , when sys tem improvemen ts are in order , good do cum ent at io n permi tsef fec t ive redesign, updat ing, and ret rof i t t in g in the f ie ld. I f docum enta t ion does not ex is t , general ly the ent i reex is t ing f rame work of ope rat ing sof tware must be junked, even for re lat ively modes t changes .

Figure 6 shows a doc ume ntat io n p lan which is keyed to the s teps prev ious ly shown. Note th at s ixdocuments are produced, and at the t ime of del ivery of the f inal produc t , Documents No, 1, No. 3, No. 4,No. 5, and No. 6 are updated and current.

332


6/11

/ ,I0:Z/oo i ,~g ~

Irl . i 0 . iIII I ~,- ,,*,1 =

. ~illl ~$~ mz~_~ u,

EX

E8"0Ill N, .~-r".2/ "

z_ ,,,. ~ ~ E~OLUa . .~

NNI Z~ wi - ,


7/11

S T E P 3 : D O I T T W I C EAf te r do cum enta t ion, the second most impo r tant c r i ter ion for success revolves around wh ether the

produc t is tota l l y or ig inal . I f the compu ter program in ques t ion is being developed for the f i rs t t ime, ar rangemat ters so that the vers ion f inal l y d el ivered to the cus tomer for o perat ion al deplo yme nt i s ac tual ly the secondversion insofar as cr i t ical d esign/ ope rat ions areas are concerned . Figure 7 i l tustrates how this mig ht be carr iedout by means of a s imulat ion. Note that i t is s imply the ent i re process done in miniature, to at im e scale thatis re lat ively smal l wi th respec t to the overal l ef for t . The nature of th is ef fo r t can vary wide ly depe ndingpr ima r i l y on the overal l t ime scale and the nature of the c r i t i ca l problem areas to be mo deled. I f the ef fo r t runs30 months then th is ear ly develo pme nt of ap i l ot model might be scheduled for 10 months . For th is schedule,fa i r l y form al cont ro ls , docu men tat ion procedures , etc. , can be ut i li zed. I f , however , the overal l ef fo r t werereduced to 12 months , then the p i lot ef fo r t cou ld be compressed to three months perhaps, in order to gainsuf f i c ient leverage on the mainl ine develop ment . In th is case a very specia l k ind of broad competence isrequi red on the par t of the personnel involved. The y must have an intu i t i ve feel for analys is, coding, andprogram des ign. The y must q uick ly sense the t roub le spots in the des ign, model them, model the i r a l ternat ives ,forget the s t ra ight forward aspec ts of the des ign which aren' t w or th s tudy ing at th is ear ly point , and f inal l yarr ive at an error- f ree prog ram. In ei ther case the p oin t of al l this, as wi th a s imu lat io n, is that q uest ion s oft iming, s torage, etc. which are otherwise mat ters of judgme nt , can now be s tudied wi th prec is ion. Wi tho utth is s imulat ion the projec t manager is at the mercy of human judgme nt . Wi th the s im ulat ion he can at leastper form exper im ental tes ts of some key hypotheses and scope down w hat remains for human judg ment , whichin the area of com put er p rogram design (as in the est imat ion of ta keo ff gross we ight, costs to c omp lete, or thedai ly doub le) is invar iably and ser ious ly opt imis t ic .

I I , , ,1 IA N A L Y S I S I

! P R O G R A M II D E S , G N I- U coo,.o IL I . , s . , . o

U S A G E

P R E L I M I N A R Y %P R O G R A MD E S I G N

A N A L Y S I S

i P R O G R A MD E S I G N

T E S T I N G [ P E R A T I O N SFigure 7. Step 3: At t em pt to do the job twice - the f irs t resul t prov ides an ear ly s imulat ion of the f inal prod uc t .

334


8/11

STEP 4 : PLAN, CONTROL AND MONI T OR TESTI NGWithou t ques t ion the b iggest user of pro jec t resources, wheth er i t be manpowe r , compu ter t ime , or

mana geme nt judg men t, is the test phase. I t is the phase of greatest r isk in terms of dol lars and schedule. I toccurs at the latest poin t in the schedule when backu p al te rnat ives are least avai lable, i f at al l .

The prev ious three recomm enda t ions to des ign the program before b eginning analys is and coding, todocument i t complete ly , and to bui ld a p i lot model are a l l a imed at uncover ing and solv ing problems beforeenter ing the test phase. Ho weve r, even after doing these things there is st i l l at es t phase and there are sti l limpo r tant th ings to be done. Figure 81ists some addi t io nal aspects to tes ting. In p lanning for tes t ing, Iw ou ldsuggest the fo l lo win g for cons iderat ion.

1) Man y parts of the test process are best handled by test special is ts wh o d id not necessar i lycon tr ibu te to the or igin al design. I f i t is argued that o nly the designer can perf orm a thorou gh test becauseon ly he understands the area he bui l t , this is a sure s ign of a fai lure to do cum ent pro per ly . With gooddo cum en tat i on i t is feasible to use specialis ts in software pro duc t assurance who w i l l , in my judgm ent, d o abet ter job of tes t ing than the des igner .

2) Most errors ar e of an obvious nature that carl be easi ly spotted b y v isual inspect ion . Eve ry bi tof an analysis and every bi t of code should be subjected to a s imple v isual scan by a second party who did notdo the or ig inal analys is or code but w ho wo uld spot th ings l ike droppe d minus s igns , miss ing fac tors of two ,jumps to w ron g addresses, etc. , wh ich are in the nature of p roo frea 0in g the analysis and code. Do n ot use thecomp uter to detec t th is k ind of th ing - i t is too expens ive.

3) Tes t every logic path in the compute r program at leas t once wi th some k ind o f num er ical check . I fIwe rea c us tom er , Iwo u ld no t ac c ept de li v e r y un t il t h is p roc edure was c omple ted and cer t if i ed . Th i s st ep w i l luncover the m ajor i ty of cod ing errors.

Whi le th is test procedure sounds s imple, for a large, comp lex com puter program i t i s re lat ively d i f f i cu l tto p low through every logic path wi th cont ro l led values of input . In fac t there are those who wi l l argue that i tis very near ly imposs ib le. In spite of th is I wo ul d persist in my reco mme ndat io n that every logic path besubjected to at least one authent ic check.

4) Aft er the s imple errors (which are in the major i ty , and whic h obscure the big mistakes) are removed ,then i t i s t ime to turn over the sof tware to the test area for checko ut purposes. At the proper t ime dur ing thecourse of de velo pm ent and in the hands of the prop er person the comp uter i tsel f is the best device forcheckout . Key m anagement dec isions are: when is the t ime and who is the person to do f inal checkout?STEP 5 : I NVO LVE THE CUSTOMER

For some reason what a software design is going to do is subject to wide interpretat ion even afterprev ious agreement. I t is impo r tant to involve the cus tomer in a formal wa y so that he has com mi t te dhimsel f at ear lier points before f inal del ivery . To give the cont ra c tor f ree re in between requi rem entdef in i t ion and ope rat ion is inv i t ing t rouble. F igure g indicates three points fo l lowin g requi re me ntsd ef in i t ionwhere the ins ight , judgme nt , and com mi tm ent of the cus tomer carl bols ter the develop men t ef for t .S U M M A R Y

Figure 10 summarizes the f ive steps that I feel necessary to t ra nsfo rm a r isky de velo pm ent processinto one that wi l l prov ide the desi red produc t . I wo uld emphas ize that each i tem cos ts some addi t iona l sumof mo ney . I f the re lat ively s impler process wi tho ut the f i ve comple x i t ies descr ibed here wou ld wo rksuccessful ly , then of course the addi t ion al mon ey is not wel l spent. I i , my exp er ience, however, the s implermetho d has never work ed on large sof tware developm ent ef for ts and the cos ts to recover far exceeded thoserequired to f inance the f ive-step process l is ted.

335


9/11

l ~

~m~ I T_~ L_ ~.L

I wS igI ~ o _ ~ E ,_ I " o ~ .~

O . . v a W

r

/ ,

336

r-

E2o

'1E8t-OE

"OE

oE8t-

e,.

Q..

,mLL


10/11

C

lQ./

(/ )I--z~i , , . u a , ~ Lr .n rr nIn .J

ii 1

,


11/11

I |

I 'I I: i ] . ~ 'l le ~$ ~ ~ in | ~ ~ u

8 (

I I . . I s " "

O00@'

0 O ~d

p@@@@@@~S.

I w

R

I.L.

338