MANAGI NGTHEDEVELOPMENTOFLARGESOFTWARESYSTEMS Dr.Winston W.
Rovce I NTRODUCTI ON lam going t odescribe mype,-.~onal views
aboutmanaging large softwaredevel opments.Ihave had various
assignments duri ngthepastnit,.:years,mostl yconcerned wi t
hthedevel opment ofsoftwarepackages forspacecraftmissionplanning,
commandi ngandpost-fl i ghtanalysis.IntheseassignmentsIhave
experienced di f f erent degrees of successwithrespecttoarri vi
ngatanoperati onalstate,on-ti me,and wi t hi ncosts.Ihave become
prejudicedbymyexperiences andIamgoing torelatesome of
theseprejudicesinthispresentation. COMPUTERPROGRAMDEVELOPMENTFUNCTI
ONS There are t woessential stepscommontoallcomput erprogramdevel
opments, regardless of sizeor compl exi t y. Thereis
firstananalysis step,f ol l owedsecondbya codi ngstepas depi
ctedinFigure1.Thissort ofverysimplei mpl ement at i on
conceptisinfactallthatisrequirediftheef f ort is suffi ci entl
ysmallandi fthe fi nal productis tobe operated bythose whobui l t
it-asis t ypi cal l ydone wi t hcomput erprogramsfori
nternaluse.Itis also theki ndofdevel opment ef f ort forwhi
chmostcustomersarehappytopay,sincebothsteps involve genui nel y
creative workwhi chdi rect l ycontri butestotheusefulness ofthefi
nal product.An i mpl ement at i onplantomanufacture13rger
softwaresystems,andkeyedonl ytothese steps,however,is doomed t of
ai l ur e. Manyaddi ti onaldevel opment stepsare required,none cont
ri but eas di rect l ytothefi nal productas analysis
andcoding,andalldriveupthe devel opment costs.Customerpersonnel t
ypi cal l ywoul drathernotpay forthem,anddevel opment personnel
woul drathernoti mpl ementthem.Thepri mef unct i onofmanagement is
toselltheseconceptstobot hgroupsandthenenforcecompl i ance
onthepartofdevel opment personnel. ANALYSI S CODI NG Figure1.I mpl
ement at i on stepstodel i ver a smallcomput erprogramf ori nternal
operati ons. Amore grandiose approachtosoftware devel opment isi l
l ustratedinFigure2.Theanalysis andcoding stepsare
stillinthepicture,buttheyareprecededbyt wolevels of requi
rementsanalysis, areseparated bya programdesignstep,andf ol l
owedbya testingstep.These addi ti onsaretreatedseparately f
romanalysis and codingbecause theyare di sti nctl ydi f f erent
inthewaytheyare executed.Theymustbeplanned andstaffed di f f erent
l yforbestut i l i zat i onofprogramresources.
Figure3portraystheiterativerel ati onshi p between successivedevel
opment phasesforthisscheme. The orderi ng of stepsis basedonthef ol
l owi ng concept:thatas each stepprogressesandthedesignis further
detai l ed, thereis ani terati on wi t hthepreceding andsucceeding
stepsbutrarely wi t hthemoreremotestepsin
thesequence.Thevirtueofall of thisis thatas thedesignproceeds
thechangeprocessisscopeddownto manageable l i mi ts.At anypoi nt
inthedesignprocess aftertherequi rements analysisiscompl
etedthereexists a f i rmandc~seup~movi ng baseline towhi(:hto~t ur
nintheevent of unforeseen design di ffi cul ti es.Whatwe have is
aneffecti vefallbackposi ti onthattendstomaxi mi ze theext ent of
earl y workthatis salvageable and preserved.
ReprintedfromProceedings, IEEE WESCON, August1970,pages1-9.
Co_pyright 1_9_70 by The Institute of Electrical and
ElectronicsEt)gineers,,.328 Inc.Originally publishedby TRW. ISYSTEM
IANALYSIS PROGRAM DESIGN I coo, . o TESTING IOPERATIONS Figure2.I
mpl ement at i on stepstodevel op alarge computerprogramf ordel i
very t oa customer. Ibelieve inthisconcept,butthei mpl ement at i
on describedaboveis riskyandinvites fai l ure.The probl emisi l l
ustratedinFigure4.Thetestingphase whi choccursattheend of thedevel
opment cycleis the firstevent f orwhi chti mi ng,storage,i nput /
out put transfers,etc.,are experienced as distinguishedf rom
analyzed.These phenomena arenotprecisely
analyzable.Theyarenotthesol uti ons tothestandardpartial di
fferenti al equati ons ofmathemati cal physics forinstance.Yeti
fthesephenomena failtosatisfythevarious externalconstraints,theni
nvari abl y amaj orredesignisrequired.Asimpleoctalpatchorredo of
someisolated code wi l l notf i xthese kindsof di ffi cul ti
es.Therequireddesignchanges arel i kel ytobe so di srupti vethatthe
softwarerequirements uponwhi chthedesignis basedand whi chprovides
therati onal e foreverythi ng are
violated.Eithertherequirementsmustbemodi f i ed,ora
substantialchangeinthedesignisrequired.Ineffect thedevel opment
processhas returnedtotheori gi nandone canexpectuptoal O0-percent
overruninschedule and/orcosts. Onemi ghtnote thattherehas been a
skipping-over of theanalysis andcodephases.Onecannot,of
course,producesoftware wi t hout thesesteps,butgenerally these
phasesaremanaged wi t hrelative ease and have l i ttl
eimpactonrequirements, design,andtesting.Inmyexperience thereare
whol e departments consumed wi t htheanalysis of orbi t mechanics,
spacecraftat t i t udedetermi nati on,mathemati calopt i mi zat i
on ofpayl oad acti vi tyandso f ort h, butwhenthese departments
have compl etedthei rdi f f i cul t andcompl ex
work,theresultantprogramstepsi nvol vea fewlines ofserial ari t
hmet i ccode.Ifintheexecut i on ofthei rdi f f i cul tandcompl ex
workthe analystshave made amistake,thecorrecti onisi nvari abl yi
mpl emented byami nor change inthecode wi t hnodi srupti
vefeedbacki ntotheother devel opment bases. However,Ibelieve thei l
l ustratedapproach tobef undament al l y sound.Theremainder ofthis
discussionpresents fiveaddi t i onalfeatures thatmustbe added
tothisbasic approach toel i mi nate mostof the devel opmentrisks.
329 ISYSTEM! REQUIREMENTSIBI~ ~"' i so,w.,~I ANALYSIS
~1111~IIpRI~OGRAM~l l l ICODINGIi TESTING OPERATIONS Figure
3.Hopefully, the ~terat=veinteract=onbetweenthe various phasesis
confined to successivesteps. ISYSTEM"1 .~oo,.~-,..Sl.,~ Iso,w..~!.
IANALYSIS PROGRAM DESIGN I coo,.G I, ~ ! TESTINGI I O.ATO.S! Figure
4.Unfortunately,for the processillustrated, the design
iterationsare neverconfined to the successivesteps. 330
STEP1:PROGRAMDESI GNCOMESFI RST The firststep towards a f i xisi l
l ustratedinFigure5.Aprel i mi naryprogramdesign phasehas been
inserted between thesoftwarerequirements generati on
phaseandtheanalysis phase.Thisprocedurecanbe cri ti ci
zedonthebasisthattheprogramdesigner is forcedtodesignintherelative
vacuumofi ni ti al software requirements wi t hout anyexi sti ng
anal ysi s..Asa result,hisprel i mi narydesignmaybe substanti al l
yinerroras compared tohis designi fhe weretowai t unti l
theanalysis was compl ete.Thiscriticismiscorrectbutitmisses thepoi
nt.Bythistechni que theprogramdesigner assures thatthesoftware wi l
l notfailbecauseofstorage, ti mi ng,anddataf l
uxreasons.Astheanalysis proceeds inthesucceeding
phasetheprogramdesignermust impose ontheanalystthestorage, ti mi
ng,andoperati onalconstraintsinsucha waythathe senses the
consequences.Whenhe j usti fi abl yrequiresmoreofthiski ndof
resourceinordertoi mpl ementhisequations itmustbesi mul taneousl y
snatchedf romhis analystcompatri ots.Inthiswayalltheanalysts
andallthe programdesigners wi l l cont ri but etoameani
ngfuldesignprocess whi chwi l l cul mi nateintheproperal l ocati on
ofexecuti on ti meandstorageresources.Ifthetotal resources tobeappl
i ed arei nsuffi ci entori ftheembryo operati onaldesignis
wrongitwi l l berecognized atthisearlier stageandthei terati on wi
t hrequhements and prel i mi nary designcanberedone beforefi nal
design,codingandtestcommences. Howis thisprocedurei mpl
emented?Thef ol l owi ng stepsare required. 1)Begin
thedesignprocess wi t hprogram designers,notanalysts orprogrammers.
2)Design, defi ne andal l ocate thedataprocessing modes even
attheriskof being wrong.Al l ocate processing, functi
ons,designthedatabase,defi ne database processing,allocate executi
on ti me,defi ne interfaces andprocessing modes wi t htheoperati ng
system,describei nputandout put processing,anddefi ne prel i mi
naryoperati ng procedures. 3)Writean overvi ew document
thatisunderstandable, i nformati veandcurrent.Eachandevery
workermusthave an el ementalunderstandi ng of thesystem.At least
onepersonmusthave a deepunderstand- ing of thesystemwhi
chcomesparti al l yf romhaving hadtowri t ean overvi ew document.
/ALLOCATE~ADESCRIBE /sO..oOO,,./c% I Figure 5.Step1 :Insurethata
prel i mi naryprogram designis compl etebefore analysis begins. 331
STEP2:DOCUMENTTHEDESIGN Atthispoi nt itis appropri ate
toraisetheissue of-" howmuchdocument at i on?"Myownviewis "qui t
eal ot ; "certai nl
ymorethanmostprogrammers,analysts,orprogramdesigners are wi l l i
ngtodoifl eftto thei rowndevices.Thefirstruleofmanaging
softwaredevel opment isruthlessenforcementofdocument at i on
requirements. OccasionallyIamcalledupontoreview theprogress
ofothersoftwaredesignefforts.Myfirststepis toinvestigate thestate
ofthedocument at i on, Ifthedocument at i onisinserious defaul
tmyfirst recommendati onis simple.Replace
projectmanagement.Stopallacti vi ti esnotrelated todocument at i
on.Bringthedocument at i onuptoacceptable standards.Management
ofsoftwareissi mpl yimpossible wi t hout a veryhighdegree
ofdocument at i on. Asanexampl e, letmeofferthef ol l owi
ngestimates forcompari son.In ordertoprocurea 5mi l l i ondol l
arhardwaredevice,I woul dexpect thata30page speci fi cati onwoul
dprovi de adequate detai l tocontrol theprocurement.Inordertopr
ocur e5mi l l i ondollarsofsoftwareI woul destimate ~1[,00pa~e
speci fi cati onis aboutrightinordertoachieve comparabl e control ,
Whysomuchdocument at i on? 1)Eachdesigner mustcommuni cate wi t hi
nterfaci ngdesigners, wi t hhismanagement andpossibly wi t
hthecustorner.Averbalrecordis t ooi ntangi bl e toprovi
deanadequate basisforaninterfaceormanage- ment deci si on.
Anacceptable wri t t endescri pti onforcesthedesigner
totakeanunequi vocal posi ti onand provide tangi bl e evidence of
compl et i on. Itprevents thedesignerfromhi di ngbehi ndt he- " l
am90-percentf i ni shed"-syndromemont haftermonth. 2)Duri
ngtheearlyphaseofsoftwaredevel opment thedocument at i oni . st
hespeci fi cati onand i._~.sthe design.Unt i l codingbegins these
threenouns(documentati on,speci fi cati on,design)denot easi ngt et
hi ng. If thedocument at i onis badthedesignis bad.Ifthedocument at
i on does notyetexistthereis as yetnodesign, onl ypeople t hi nki
ngandtal ki ngaboutthedesign whi chis ofsomevalue, butnotmuch.
3)Therealmonetaryvalue ofgooddocument at i onbegins
downstreaminthedevel opmentprocess duri ngthetestingphase andconti
nues throughoperati ons andredesign.Thevalue ofdocument at i
oncanbe describedintermsofthreeconcrete,tangi bl e si tuati ons
thateveryprogrammanager faces. a)Duri ngthetestingphase,wi t hgood
document at i onthemanager canconcentratepersonnel onthe
mistakesintheprogram.Wi t hout good document at i
oneverymistake,large orsmall,is anal yzed byoneman whoprobabl ymade
themistakeinthefirstplace because heis theonl ymanwhounderstands
theprogram area. b)Duri ngtheoperati onalphase, wi t hgood document
at i onthemanager canuse operat i on-ori ent ed personnel tooperate
theprogramandtodoa better job,cheaper.Wi t hout good document at i
onthesoftware mustbe operatedbythose whobui l t it.General l y
thesepeople arerel ati vel y disinterestedinoperati ons anddo
notdoas effectivea j obas operati ons-ori ented
personnel.Itshouldbepoi nt ed out inthisconnecti onthatin anoperati
onalsi tuati on,ifthereis somehangup thesoftwareis always bl
amedfirst.Inorderei thertoabsolve thesoftwareortof i
xtheblame,thesoftwaredocument at i onmustspeakclearly. c)Fol l owi
ng i ni ti al operati ons, whensystemi mprovementsareinorder,good
document at i onpermits effectiveredesign,updating,andret rof i t t
i nginthefield.Ifdocument at i ondoes not exist,general l y theenti
re existing f rameworkof operati ng softwaremustbe j unked,even
forrel ati vel y modestchanges. Figure6showsa document at i onplan
whi chis keyedtothestepsprevi ousl y shown.Notethatsix
documentsareproduced,andattheti meofdel i very of thefi nal
product,DocumentsNo,1,No.3,No.4, No.5,andNo.6areupdatedandcurrent.
332 / ,I0: wZ /ooi,~ g~ Irl. . oi 0 .i IIII ~,-,,*,1= .~ illl~$~m
z~_~u, E X E 8 " 0 IllN ~, .~- r" .2 /" z_,,,.~~E ~OLU a. . ~ N N I
Z ,~,- w i - ,