systems analysis

MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS

Dr. Winston W. Rovce

INTRODUCTION l am going to describe my pe,-.~onal views about managing large software developments. I have had

various assignments during the past nit,.: years, mostly concerned with the development of software packages

for spacecraft mission planning, commanding and post-flight analysis. In these assignments I have experienced

different degrees of successwith respect to arriving at an operational state, on-time, and wi th in costs. I have

become prejudiced by my experiences and I am going to relate some of these prejudices in this presentation.

COMPUTER PROGRAM DEVELOPMENT FUNCTIONS There are two essential steps common to all computer program developments, regardless of size or

complexity. There is first an analysis step, fol lowed second by a coding step as depicted in Figure 1. This sort

of very simple implementation concept is in fact all that is required if the effort is suff iciently small and if the

final product is to be operated by those who built it - as is typical ly done with computer programs for internal

use. It is also the kind of development effort for which most customers are happy to pay, since both steps

involve genuinely creative work which directly contributes to the usefulness of the final product. An

implementation plan to manufacture 13rger software systems, and keyed only to these steps, however, is doomed

• tofa i lure. Many addit ional development steps are required, none contribute as directly to the final product as

analysis and coding, and all drive up the development costs. Customer personnel typical ly would rather not pay

for them, and development personnel would rather not implement them. The prime function of management

is to sell these concepts to both groups and then enforce compliance on the part of development personnel.

ANALYSIS

CODING

Figure 1. Implementat ion steps to deliver a small computer program for internal operations.

A more grandiose approach to software development is illustrated in Figure 2. The analysis and coding

steps are still in the picture, but they are preceded by two levels of requirements analysis, are separated by a

program design step, and fol lowed by a testing step. These additions are treated separately from analysis and

coding because they are distinctly dif ferent in the way they are executed. They must be planned and staffed

di f ferent ly for best ut i l izat ion of program resources.

Figure 3 portrays the iterative relationship between successive development phases for this scheme.

The ordering of steps is based on the fol lowing concept: that as each step progresses and the design is further

detailed, there is an iteration with the preceding and succeeding steps but rarely with the more remote steps in

the sequence. The virtue of all of this is that as the design proceeds the change process is scoped down to

manageable limits. At any point in the design process after the requirements analysis is completed there exists

a f irm and c~seup~ moving baseline to whi(:h to ~ tu rn in the event of unforeseen design diff icult ies. What we

have is an effective fallback position that tends to maximize the extent of early work that is salvageable and

preserved. Reprinted from Proceedings, IEEE WESCON, August 1970, pages 1-9. Co_pyright © 1_9_70 by The Institute of Electrical and Electronics Et)gineers,, .328 Inc. Originally published by TRW.

I SYSTE M

I ANALYSIS PROGRAM

DESIGN

I c o o , . o TESTING

I OPERATIONS

Figure 2. Implementation steps to develop a large computer program for delivery to a customer.

I believe in this concept, but the implementation described above is risky and invites failure. The

problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the

first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from

analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial

differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various

external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated

code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the

software requirements upon which the design is based and which provides the rationale for everything are

violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect

the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule

and/or costs.

One might note that there has been a skipping-over of the analysis and code phases. One cannot, of

course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and

have l i tt le impact on requirements, design, and testing. In my experience there are whole departments

consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion

of payload activity and so forth, but when these departments have completed their di f f icul t and complex work,

the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t

and complex work the analysts have made a mistake, the correction is invariably implemented by a minor

change in the code with no disruptive feedback into the other development bases.

However, I believe the illustrated approach to be fundamental ly sound. The remainder of this

discussion presents five addit ional features that must be added to this basic approach to eliminate most of the

development risks.

329

I SYSTEM ! REQUIREMENTSIBI~

~ " ' i so,w.,~ I

ANALYSIS

~1111~ I I pRI~OGRAM

~ l l l I CODING Ii

TESTING

OPERATIONS

Figure 3. Hopefully, the ~terat=ve interact=on between the various phases is confined to successive steps.

I SYSTEM "1 .~oo,.~-,..Sl.,~ I so,w..~ !.

I ANALYSIS

PROGRAM DESIGN

I coo,.G I ,~ ! TESTING I

I O .ATO.S ! Figure 4. Unfortunately, for the process illustrated, the design iterations are never confined to the successive steps.

330

STEP 1: PROGRAM DESIGN COMES FIRST

The first step towards a f ix is illustrated in Figure 5. A preliminary program design phase has been

inserted between the software requirements generation phase and the analysis phase. This procedure can be

criticized on the basis that the program designer is forced to design in the relative vacuum of initial software

requirements wi thout any existing analysis..As a result, his preliminary design may be substantially in error as

compared to his design if he were to wait until the analysis was complete. This criticism is correct but it misses

the point. By this technique the program designer assures that the software wi l l not fail because of storage,

timing, and data f lux reasons. As the analysis proceeds in the succeeding phase the program designer must

impose on the analyst the storage, timing, and operational constraints in such a way that he senses the

consequences. When he justif iably requires more of this kind of resource in order to implement his equations

it must be simultaneously snatched from his analyst compatriots. In this way all the analysts and all the

program designers wi l l contr ibute to a meaningful design process which wi l l culminate in the proper allocation

of execution time and storage resources. If the total resources to be applied are insufficient or if the embryo

operational design is wrong it wi l l be recognized at this earlier stage and the iteration with requhements and

preliminary design can be redone before final design, coding and test commences.

How is this procedure implemented? The fol lowing steps are required.

1) Begin the design process with program designers, not analysts or programmers.

2) Design, define and allocate the data processing modes even at the risk of being wrong. Allocate

processing, functions, design the data base, define data base processing, allocate execution time, define

interfaces and processing modes wi th the operating system, describe input and output processing, and define

preliminary operating procedures.

3) Write an overview document that is understandable, informative and current. Each and every

worker must have an elemental understanding of the system. At least one person must have a deep understand-

ing of the system which comes partial ly from having had to write an overview document.

/ ALLOCATE ~ A DESCRIBE / sO..oOO,,. / c %

I

Figure 5. Step 1 : Insure that a prel iminary program design is complete before analysis begins.

331

STEP2: DOCUMENT THE DESIGN

At this point it is appropriate to raise the issue of - "how much documentat ion?" My own view is

"quite a lot ;" certainly more than most programmers, analysts, or program designers are wi l l ing to do if left to

their own devices. The first rule of managing software development is ruthless enforcement of documentat ion

requirements.

Occasionally I am called upon to review the progress of other software design efforts. My first step is

to investigate the state of the documentation, If the documentat ion is in serious default my first

recommendation is simple. Replace project management. Stop all activities not related to documentat ion.

Bring the documentat ion up to acceptable standards. Management of software is simply impossible w i t h o u t a

very high degree of documentation. As an example, let me offer the fo l lowing estimates for comparison. In

order to procure a 5 mil l ion dollar hardware device, I would expect that a 30 page specification would provide

adequate detail to control the procurement. In order to procure5 mi l l ion dollars of software I w o u l d estimate

~ 1[,00 pa~e specification is about right in order to achieve comparable control,

Why so much documentation?

1) Each designer must communicate wi th interfacing designers, wi th his management and possibly

with thecustorner. A verbal record is too intangible to provide an adequate basis for an interface or manage-

mentdecision. An acceptable wri t ten description forces the designer to take an unequivocal posit ion and

provide tangible evidence of completion. It prevents the designer from hiding behind t h e - " l am90-percent

f inished" - syndrome month after month.

2) During the early phase of software development the documentat ion i .sthe specification and i._~.s the

design. Unti l coding begins these three nouns (documentation, specification, design) denoteas ingte th ing. If

the documentation is bad the design is bad. If the documentat ion does not yet exist there is as yet no design,

only people thinking and talking about the design which is of some value, but not much.

3) The real monetary value of good documentat ion begins downstream in the development process

during the testing phase and continues through operations and redesign. The value of documentat ion can be

described in terms of three concrete, tangible situations that every program manager faces.

a) During the testing phase, with good documentat ion the manager can concentrate personnel on the

mistakes in the program. Without good documentat ion every mistake, large or small, is analyzed by one man

who probably made the mistake in the first place because he is the only man who understands the program area.

b) During the operational phase, with good documentat ion the manager can use operation-oriented

personnel to operate the program and to do a better job, cheaper. Without good documentat ion the software

must be operated by those who bui l t it. Generally these people are relatively disinterested in operations and do

not do as effective a job as operations-oriented personnel. It should be pointed out in this connection that in

an operational situation, if there is some hangup the software is always blamed first. In order either to absolve

the software or to f ix the blame, the software documentat ion must speak clearly.

c) Fol lowing init ial operations, when system improvements are in order, good documentat ion permits

effective redesign, updating, and retrof i t t ing in the field. If documentat ion does not exist, generally the entire

existing framework of operating software must be junked, even for relatively modest changes.

Figure 6 shows a documentat ion plan which is keyed to the steps previously shown. Note that six

documents are produced, and at the time of delivery of the final product, Documents No, 1, No. 3, No. 4,

No. 5, and No. 6 are updated and current.

332

/ ,

I0: w Z /oo i ,~ g ~

Irl . . o i 0 . i IIII ~,- ,,*,1 =

• . ~

illl ~ $ ~ m z ~ _ ~ u,

E

X

E 8

" 0

Ill N ~ , .~- r" .2

/ " z_ ,,,. ~ ~ E ~OLU

a . . ~

N

N I Z ,~,- w i - , <~

t -

LL

333

STEP 3: DO IT TWICE After documentation, the second most important criterion for success revolves around whether the

product is total ly original. If the computer program in question is being developed for the first time, arrange

matters so that the version f inally delivered to the customer for operational deployment is actually the second

version insofar as critical design/operations areas are concerned. Figure 7 iltustrates how this might be carried

out by means of a simulation. Note that it is simply the entire process done in miniature, t o a t i m e scale that

is relatively small wi th respect to the overall effort. The nature of this effort can vary widely depending

primarily on the overall t ime scale and the nature of the critical problem areas to be modeled. If the effort runs

30 months then this early development o f a p i l o t model might be scheduled for 10 months. For this schedule,

fairly formal controls, documentation procedures, etc., can be util ized. If, however, the overall ef fort were

reduced to 12 months, then the pi lot effort could be compressed to three months perhaps, in order to gain

sufficient leverage on the mainline development. In this case a very special kind of broad competence is

required on the part of the personnel involved. They must have an intuit ive feel for analysis, coding, and

program design. They must quickly sense the trouble spots in the design, model them, model their alternatives,

forget the straightforward aspects of the design which aren't worth studying at this early point, and f inal ly

arrive at an error-free program. In either case the point of all this, as wi th a simulation, is that questions of

timing, storage, etc. which are otherwise matters of judgment, can now be studied with precision. Without

this simulation the project manager is at the mercy of human judgment. With the simulation he can at least

perform experimental tests of some key hypotheses and scope down what remains for human judgment, which

in the area of computer program design (as in the estimation of takeoff gross weight, costs to complete, or the

daily double) is invariably and seriously optimistic.

I I,,, 1 I ANALYSIS I

! PROGRAM I I DES,GN I

-U coo,.o I LI .,s.,.o

USAGE

PRELIMINARY I % PROGRAM DESIGN

ANALYSIS

i PROGRAM DESIGN

TESTING

[ OPERATIONS Figure 7. Step 3: At tempt to do the job twice - the first result provides an early simulation of the final product.

334

STEP 4: PLAN, CONTROL AND MONITOR TESTING

Without question the biggest user of project resources, whether it be manpower, computer time, or

management judgment, is the test phase. It is the phase of greatest risk in terms of dollars and schedule. It

occurs at the latest point in the schedule when backup alternatives are least available, if at all.

The previous three recommendations to design the program before beginning analysis and coding, to

document it completely, and to build a pi lot model are all aimed at uncovering and solving problems before

entering the test phase. However, even after doing these things there is s t i l la test phase and there are still

important things to be done. Figure 81ists some addit ional aspects to testing. In planning for testing, Iwou ld

suggest the fo l lowing for consideration.

1) Many parts of the test process are best handled by test specialists who did not necessarily

contribute to the original design. If it is argued that only the designer can perform a thorough test because

only he understands the area he built, this is a sure sign of a failure to document properly. With good

documentation it is feasible to use specialists in software product assurance who wil l , in my judgment, do a

better job of testing than the designer.

2) Most errors are of an obvious nature that carl be easily spotted by visual inspection. Every bit

of an analysis and every bit of code should be subjected to a simple visual scan by a second party who did not

do the original analysis or code but who would spot things like dropped minus signs, missing factors of two,

jumps to wrong addresses, etc., which are in the nature of proofrea0ing the analysis and code. Do not use the

computer to detect this kind of thing - it is too expensive.

3) Test every logic path in the computer program at least once with some kind of numerical check. If

Iwereacustomer , Iwou ld not accept delivery unti l this procedure was completed and certified. This step wil l

uncover the majority of coding errors.

While this test procedure sounds simple, for a large, complex computer program it is relatively di f f icul t

to plow through every logic path with controlled values of input. In fact there are those who wil l argue that it

is very nearly impossible. In spite of this Iwou ld persist in my recommendation that every logic path be

subjected to at least one authentic check.

4) After the simple errors (which are in the majority, and which obscure the big mistakes) are removed,

then it is time to turn over the software to the test area for checkout purposes. At the proper time during the

course of development and in the hands of the proper person the computer itself is the best device for

checkout. Key management decisions are: when is the time and who is the person to do final checkout?

STEP 5: INVOLVE THE CUSTOMER

For some reason what a software design is going to do is subject to wide interpretation even after

previous agreement. It is important to involve the customer ina formal way so that he has committed

himself at earlier points before final delivery. To give the contractor free rein between requirement

def ini t ion and operation is inviting trouble. Figure g indicates three points fol lowing requirementsdefini t ion

where the insight, judgment, and commitment of the customer carl bolster the development effort.

S U M M A R Y

Figure 10 summarizes the five steps that I feel necessary to transform a risky development process

into one that wi l l provide the desired product. I would emphasize that each item costs some addit ional sum

of money. If the relatively simpler process wi thout the five complexities described here would work

successfully, then of course the addit ional money is not well spent. Ii, my experience, however, the simpler

method has never worked on large software development efforts and the costs to recover far exceeded those

required to finance the five-step process listed.

335

l ~

~m~ I T _ ~ L_ ~.L

I w S i g I ~o_~E,

_ I " o ~ .~ O . . v a W

r

/ ,

336

r -

E

2

o

' 1

E 8

t - O

E " O E

o E

8 t -

e,.

Q..

, m L L

C

l Q. /

(/)

I-- z ~

i , , . u a ,~L r.n r r n

I n . J

i i1

,< z <

E

337

Z o_ I.- < r , - i l l Q .

o

/'L__J (.-

r -

0 (J

f -

t.-

0 .E ~n

E E

>o

+.~

I

E o

E 4..,

o r -

Q.

c~

i i

I |

I ' I I

: i ] . ~ ' l l e ~$ ~ ~ i

n | ~ ~ u 8 (

I I .. I s " "

O0 0@'

0 O° ~

d

p@@@@@@~S.

I w

R

I.L.

338