Software Engineering (phần 3) pot

W ith the concurrent incremental model of Figure 3.5, unless the process is y moni tored carefully, t he entire project risks falling apart!. ' l There are restrictions on the applicabil

a.5 XTREME PROGRAMMING 75

'falling apart ln fact, the incremental m odel does not distinguish between developing ',

a product and enhancing (maintaining) i t; each enhancement is merely an addit ional

. All too frequently, the requirements change w hile development is in progress',

this problem is discussed in greater detail in Section 16.4.4 The llexibility of the

i ncremental model gives i t a major advantage over t he wat erfall and rapid prototyping

models i n t his regard On t he negative side the incremental model too easi ly can I

degenerate into the build-and-lix approach Control of the process as a whole can be

d becomes a maintai ner's l

; nightmare In a sense, the incremental m odel is a contradiction in term s, requiring @

, t he devel oper t o vi ew t he product as a whol e i n or der t o begi n wi t h a desi gn t hat 1

will support the enti re product, including future enhancements, and simultaneously i 1

f

t o vi ew that product as a sequence of bui lds, each essentially independent of the next j

Unless the developer is skilled enough to be able to handle this apparent contradiction,

the incremental m odel may lead to an unsatisfactory product i

ln the incremental model of Figure 3 4, t he requi rements, specil ications, and 1

.A mor e r sky concur r ent ver si on of he i ncr ement al model depi ct ed i n j

; Figure 3.5 Once the client's requirem ents have been elicited,the specifications of the t

.f

lirst build are draw n up W hen this has been com pleted, the specification team tunzs r

, to the specihcations of the second build while the design team designs the hrst build !

,the various builds are constructed in paralle , w I

1 This approach incurs the real risk that the resulting builds will not fit together !

c W ith the increm ental model of Figure 3.4, the need for the specihcation and

architec-e tural design to be com pleted before starting the hrst build means an overall design at

a the start W ith the concurrent incremental model of Figure 3.5, unless the process is

y moni tored carefully, t he entire project risks falling apart Nevert heless, this concur- ,

rent model has had some successes For example, i t was used by Fujitsu to devel op a '

v l arge-scal e communieati on system (Aoyama, 19931.

e Extreme programming (Beck l 9991 i s a somewhat controversial new approach to i

n s f wa r de ve l opme nt ba s d on he nc r ement a model The hr s s e p i t hat he of t j

r s ware development team det ermines the vari ous features (stori es) that the cl ient would '

lt like the product to support For each such feature, the team inform s the client how !

e l ong i t will take to implement that feature and how much it will cost This t irst step i

d corresponds to the requirem ents and specification phases of the incremental m odel r

I

' e (see Figure 3 4)

Ff The client selects the features to be included in the each successive build

us-1- ing cost-beneht analysis (Section 5.2), that is, on the basis of the time and the cost

lt estimates provided by the development team as well as the potential benetits of the I

i

t )

.p

mplem entation, Deliver

Build 3: Specifications Design i

ntegration to client

N

N NN.

N N

- - .- specification team

- - - nesign team pn.la ,a qrxm lfioo.ixrx ra : lm plementation, Deliver

Im plem entation/integration team -u'' -' ''%''''WM* '= 'hd'' integration to client

Flgure 3.5 More risky concurrent incrementul model

termed tasks A program m er first draws up test cases for a task Then, working with '

a part ner on one screen Qmi r programming) (W il liams, Kessler, Cunni ngham, and ' Jeffri ess 20001 the programmer impl ements the task, ensuring that al l the t est cases 'work correctly The task then is integrated into the current version of the product

ldeally,im plementing and integrating a task should take no more than a few hours Ingeneral, a num ber of pairs im plement tasks in parallel, so integration can take placecontinuously The test cases used for the task are retained and utilized in all further jintegration testing

A number of features of extreme programming (XP) are somewhat unusual:

1 The computers of the XP team are set up in the center of a large room lined w ithsmall cubicles

2 A elient representative works with the XP team at al1 times

;3

. No individual can work overtime for two successive weeks :

.k4

. There is no specialization Instead, all m em bers of the XP team work on specih- t

'

J

5 As in the m ore risky incremental model depicted in Figure 3.5,there is no overall l

:

design phase before the various builds are constructed lnstead, the design is :

modised whil e the produet is being built This procedure is termed refact oring '

W henever atestcase willnotrun, the code is reorganized until the team is satisfied gdesign is simple, straightfom ard, and runs allthe test cases satisfactorily 1.thatthe

XP has been used successful ly on a number of smal l- and medium-size projects .

These range from a 9 person-m onth shipping tariff calculation system to a l00 year cost analysi s system gBeck, 19991 The strengt h of XP is that it i s useful whenthe client's requirements are vague or changing H owever, XP has not yet been used

person-widely enough to determ ine whether this version of the incremental m odel will fulfill i

.A specihcation doeum ent is drawn up Next,the work is divided into three

or four builds The tirst build consists of the m ost critical features, the second build :consists of the next m ost critical features, and so on Each build is carried out by ,

a num ber of small team s working in parallel A t the end of each day a11 the team s

Ili

t

q l

and debug the resulting product Stabilization is performed at the end of each build.

Any remaini ng faults that have been detected are f ixed and the bui ld isfrozen; that is,

no tkrther changes w ill be made to the specitications

( The repeated synchronization step ensures that the various com ponents always

1 i work together.A nother advantage of this regularexecution of the partially constructed

i i

j ; pr oduct hat he devel oper s obt ai n an earl y i nsi ght nt o t he operat i on of t he pr oduct

! ë and can modify the requirements, if necessary, during the course of a build The

Alm ost alw ays,an element of risk is involved in the developm ent of software For ex-

; ample, key personnel can resign betbre the product has been adequately docum ented

. ' The manutacturer of hardware on which the product is critically dependent can go

. bankrupt Too much, or too little, can be invested in testing and quality assurance AF p'

ter spendi ng hundreds of thousands of doll ars on devel opi ng a major software product.

k technological breakthroughs can render the entire productworthless An organization

i m ay research and develop a database management system

,butbefore the product can

1 l risks wherever possible.

1 One way ol mi nimizing certain types ot ri sk is t o construct a prototype As

1 I descri bed i n Section 3.3, an excellent way of reducing the risk that the delivered

product w ill not satisfy the client's real needs is to construct a rapid prototype during :' the requirements phase During subsequent phases, other sorts of prototypes m ay be

i appropriate.For example, a telephone company m ay devise a new, apparently highly

! effective algorithm for routing calls through a long-distance network If the productis

, im plem ented but does not w ork as expected, the telephone com pany will have w asted ,

the cost of developing the product ln additions angry or inconvenienced custom ers'

may take their business elsewhere This scenario can be avoided by constructing aprototype to handle only the routing of calls and testing it on a sim ulator In this way,:1 the aetual system is not disturbed, and for the cost of implementi ng just the routi ng

'

, algorithm , the telephone com pany can determine whether its w orthwhile to develop

an entire network controller incorporating the new algorithm

i The idea of m inim izing risk via the use of prototypes and other m eans is the

i concept underlying the spiral model (Boehm 19881 A si mpli stic way of looki ng at

t ,

Prototypes can be used effectively to provide inform ation about certain classes

of risk For exam ple,tim ing constraints generally can be tested by constructing a

pro-rays

ted totype and measuring whether the prototype can achieve the necessal'y perform ance

c

juct lf the prototype is an accurate functional representation of the relevant features of

The the product, then measurements made on the prot otype should give t he developers a j

ize- good idea as to whether the tim ing constraints can be achieved

the key personnel may resign before t he project is complete Anot herpotenti al risk i s t hat

Ri sk anal ysi s U iik w - - - - - - ana-j i s s j i ,

j between small-scale and large-scale software, and prototypi ng is of lit tle use This risk '

I tbe resol ved by testing team performance on a much small er prototype in whi ch

5 is a certain predictor of future perform ance

.A penalty clause in the delivery contract C is one way of trying to ensure that essential hardware will be delivered on tim e, but

what ithe supplier refuses to sign an agreement that includes such a clause? Even ''

w ith a penalty clause, late delivery m ay occur and eventually lead to leaal action 3

j other areas it is a partial answer at best, and in yet other areas it is no answer at all .

The full spiral model is shown in Figure 3.8 The radial dim ension represents '' )

cumulative cost to date, the angular dimension represents progress through the spi- , ral Each cycle of the spiral corresponds to a phase A phase begins (in the top Ieft '

, j quadrant) by determini ng objectives of that phase, alternati ves for achi evi ng those '

I

i 1

ymuj at j ons, mo el s, benchm rks l

-partition Requirem ents plan

Life-cycle plan l concept of - - - - - - - - :

operation software oetailed '

require- Software design '

lntegration oesign validation I test I

Im plementation t' est

Develop, ver

Fl gur a.@ Ful l spi ral model ( Boehm, 1 988) ( @1 988, I EEE ) 1

L st rat egy for achieving those objecti ves Next, that strategy is analyzed from the vi

ew-point of lisk Attem pts are made to resolve every potential risk, in som e cases bys

t buildi ng a prototype lf certain risks cannot be resolved, t he project may be

In one set of 25 projects in whi ch the spiral model was used i n conjuncti on wi th other

means of increasing producti vity, the productivi ty of every project i ncreased by at S

least 50 percent over previous productivity levels and by 100 percent in most of the

r projects gBoehm, 19881 To be abl e t o decide whether t he spi ral model shoul d be used

for a gi ven project, i ts advantages and disadvantages now are assessed.

e

(

; '

i The spiral m odel has a number of strengths The em phasis on alternatives and con-

1 st raints supports the reuse of existing software (Section 8 1) and the i ncorporati on of ' 1

, l software quality as a specifi c objective In addi tion, a common probl em in software

1

! developm ent is determ ining when the products of a specific phase have been ade

I

i risks that would be incurred by not doing enough testing or by doing too much

test-1 ing.perhaps most import ant, wi thi n the st ructure of the spiral model maintenance is

I j

. simply another cycle of the spiral; essentially, no distinction is made betw een m ai

nte-nance and development Thus, the problem that maintenance sometim es is maligned 'i

1 by ignorant software professionals does not arise, because maintenance is treated the

!

' l There are restrictions on the applicability of the spiral m odel

.Specifically, in its:

' '

present form , the model is intended exclusively for internal development of l

arge-scale software (Boehm, 19881 Consi der an int ernal project, that i s, one where the

1 developers and client are mem bers of the same organization.lf risk analysi s leads t o

1

the conclusi on that the project should be t erminated, t hen i n-house software personnel ' (

can be si mply reassigned to a di fferent project However, once a contract has been

! signed between a developmentorganization and an externalclient, an attem ptby either

side to terminate that contract can lead to a breach-of-contract lawsuit Therefore, in t

k

: the case of contract software, all risk analysis m ust be performed by both client and

1 developers before the contract is signed and not as in the spiral m odel.

( i perform risk anal ysis if the cost of performing t he risk analysis is comparable to the

j cost of the project as a whole or i f performing the risk analysis woul d signif icantl y

j affect the prot it pot enti al Inst ead, t he developers shoul d decide how much is at risk

E

'

and then decide how m uch risk analysis, if any, to perform

A major strength of the spi ral model is that it is risk driven but this also can be a ;

: weakness Unless the softw are developers are skilled at pinpointing the possible risks

and analyzing the risks accurately, there is a real danger that the team m ay believe '

that al l is well at a ti me when the project, i n fact, is headed for disaster Onl y if the :

m em bers of the developm ent team are competent risk analysts should m anagem ent ', decide to use the spiral m odel

' Exper i ence wi t h t he obj ect - ori ent ed paradi gm has shown t hat he need f or i t er at i on

! 1

J ( j between phases or port ions of phases of the process appears to be more common wi th

: ' the object-oriented paradigm than wit h the structured paradigm Object-ori ented life- ' 1

.

,

i

a.a O BJK T-O RIENTED LIFE-CYCLE M ODELS ea

i

cycle models have been proposed that expli cit ly reflect t he need for iterati on One 1

h model is the fountain model gl- lenderson-sel lers and Edwards, 19901 shown in 1 suc

1Fi

gure 3.9 The circles representing the vari ous phases overlap, expli citl y reiecting an j

overlap between activities The arrow s within a phase represent iteration within that 1

!

phase The mai nt enance ci r cl e i s smal l er , o symbol i ze r educed mai nt enance ef for t l

when t he object-ori ent ed paradi gm is used.

!

In addition to the fountain m odel, other object -oriented l ife-cycl e models have

been put forward, incl uding recursi ve/paral lel l ife cycl e gBerard, 19931, round-tri p 1 gestalt design gBooch, l 9941, and the model underlying the uni fi ed sof tware develop-

r

ment process (Jacobson, Booch, and Rumbaugh, l 9991 Al 1 these models are i terati ve, I incorporate some form of parallelism (overl ap of acti vi ties), and support incremental

devel opment (Section 3 4) The danger of such li fe-cycl e models is that t hey may i

be misinterpreted as simply attem pts to make a virtue out of necessity, and thereby i

1

lead to a totally undisciplined form of software development in which team mem bers ;

move almost randomly between phases, t irst desi gning one piece of t he product, next I

analyzing another pi ece, and t hen impl ementing a thi rd piece that has been neither l

analyzed nor designed; the Just in Case You W anted to Know box on page 84 gives. more on this ulzdesirable approach A better way to proceed is to have as an overall ; '. obiective a linear orocess (such as the rapid Drototvpinc model of Section 3.3 or the

Object-oriented

design phase

!

Object-oriented

l w hen the members of the development team move in object -ori ented paradi gm However , just as the word

essent ial ly haphazard fashi on from one task to another, hacker now has a pejorati ve context i n addi t ion t o it s l

1 this is sometimes referred to as CABTAB (code a bits original meaning so CABTAB now is also used in aj

: test a bit).The acronym initially was used in a positive derogatory sense to refer to this undisciplined approach

E 1 It m ight be suggested that this problem is sim ply a consequence of the relative

, newness of t he object -oriented paradigm As software professionals acquire more

ex-peri ence wit h object-ori ented anal ysi s and object-oriented design, the argument goes,

è and as the w hole discipline matures,the need for repeated review and revision will de- '

L crease To see that this argument is fallacious consider the various life-cycle models

1 previ ously described in thi s chapter First came the waterfall model (Secti on 3 2) wit h

1

. its expli cit f eedback l oops The next major dcvel opment was the rapid prototyping

' model (Secti on 3 3) , one of it s major ai ms was to reduce t he need for iterati on

How-l ever, this was t'ollowed by the spiral model (Section 3.7) which explicitly reflects an

iterative approach to softw are developm ent and m aintenance In addition, it has been

! shown Il - loniden, Kotaka, and Ki shimoto, l 9931 t hat backtracking i s an intrinsic

! a.@ QOM PARIS@N OF LIFE-W tLK o pEk:

w atedall m odel, and the rapid prototyping model m ay have som e problem s of its

One alternative is to combine the strengths of both

a.@ CoMpAmsoN oF LIFE-CYCLE M ODELS *5

i synchronize-and-stabilize model (Section 3 6) has been used wi th great success by

M icrosoft, but as yet there is no evidence of comparable successes in other corporatecul tures Yet another alternative is to use the spiral model (Section 3.7) but onl y i fthe developers are adequately trained in risk analysis and risk resolution A further

junder devel opment Such a model will incorporate appropriate aspects of the various 1

life-cycle m odels, utilizing their strengths and m inimizing their weaknesses 1

-ldels Bui l d- and- f x mo e d I ( secti on 3 1 Fine f or short pr ogr ams t hat wi l not Tot al l y unsat i sf cctory for .'

low- Wat er f ol l model ( Secti on 3 2) Di sci pl i ned appr oach Del i ver ed pr oduct may not

meetclientzs needs '

:

been

zapid prototyping model Ensures that delivered product Notyet proven beyond u11 doubt '

c as- (Section 3.3) meets cjentz needs

rdon,

t lysis l ncr ement cl model ( Secti on 3 :) Maxi mi zes ear l y r et ur n on Requi res open orchi t ect ur e

1 Promot es maint ai nubi l y and- fi x I

l Ext reme pr ogr amming ( Sect i on 3 5) Moxi mi zes eari y r et urn on Hos not yet been wi del y used

investment

W orks well when client'

requirements ore vague

Synchronize-ond-stabilze model Future users' needs are met Hcs not been widely used other( Sect i on 3 6) Ensures components can be t hon at Mi crosof t

i A number of different life-cycle m odels are described, including the build-and-fix *

l model (Section 3 ), waterfall model (Secti on 3 2), rapid prototyping model (Sec- '

' For an introduction to rapid prototyping, two suggest ed books are gconnell and

ï Shafer,198% and gGane, 19891 The role of computer-ai ded prot ot yping i s assessed

, in g Luqi and Royce, 19921 The February 1995 issue of IEEE Computer cont ains

several articles on rapid prototyping

; A description of the evolutionary delivery model, one version of the incremental z.;

model can be found in (Gilb, 19881 The concurrent incremental model is descri bed

!

.

'

in gAoyama, 19931 The synchronize-and-stabil ize model is outlined in gcusumano z o

l i and Selby, 1 9971 and described i n detai l i n gcusumano and Sel by, 19951 Insights * i

, 19991 and LBeck, 20001; refactori ng is the subject of gFowler 3.@ 1

1 1 Ri s k anal ysi s i s des cr i bed i n L Boehm l99 l Jones, l 994c) Karol ak, 1996; and a.1@

! Keil,Cule,Lyytinen, and Schmidt, 19981 The M ay/lune 1997 i ssue of lEkx software

! ' Object-oriented li fe-cycle models are descri bed in (Henderson-sell ers and Ed- g

.! 1( :

! ' wards, 1990; Rajli ch, 1994) and Jacobson, Booch, and Rumbaugh, l 9991.

f M any other Iife-cycle models have been put forward For example a life-cycle

'

model that emphasizes human faetors is present ed in gMant ei and Teorey 19881, and

'

. gRajlich and Bennett, 20001 deseri bes a mai ntenance-ori ent ed l ife-cycl e model A

life-cycle m odel recom m ended by the Software Engineering Laboratory is described

away W hich life-cycle m odel would you use? Give reasons for your answer i

3.2 You are a software engineering consultant and have been called in by the vice-

I ife-cycle model for the project?

involved in developing the software of Problem 3.2 How would you l

3.4 Your development of the stock control product for Deplorably Decadent D esserts is l

I l

highly successful As a result, Deplorably Decadent Desserts wants the product to

be rewritten as a COTS package to be sold to a variety of different organizations

;

that prepare and sell food to restaurants as well as to retail organizations The newproduct therefore m ust be portable and easily adapted to new hardw are and operating t

s yst ems How do t he cri t er i a you woul d use i n sel ect i ng a l e- cycl e model f or hi s t

project differ from those in your answer to Probl em 3 2? $

3 5 Des cr i be t he s or t of pr oduct t hat woul d be an i deal appl i cat i on f or he i ncr ement al j

3.: Now describe the type of situation w here the increm ental model m ight lead to 1

1difh

I

3.7 Descl ibe t he sort of product that would be an i deal appl ication for the spi ral model j

3.8 Now describe the type of situation where the spiral m odel is inappropriate !

3.9 W hat do waterfalls and fountains have in com mon? W hat do the waterfall m odel and ;

t

3.lQ (Term Projeet) Which software life-cycle model woul d you use for the Broadlands ;

Area Chi ldren's Hospit al project described in Appendix A? Gi ve reasons for your

ansW er.

3.1 1 (Readings i n Software Engineering) Your inst ructor will di stribut e copies of (Beck,

19991 W ould you li ke to work in an organizat ion t hat uses extreme programmi ng? 1

l ithout com petent

,well-trained software engi neers, a software project i s doomed to failure However,

1 k! M ost products are too large to be com pleted by a single software professional w ithin 1

l the given tim e constraints.As a result, the product must be assigned to a group of '

f

(

I professionals organized as a team For example, consider the specihcation phase d

) To specify the target product within 2 m onths, it may be necessary to assign the '

è task to three specification specialists organized as a team under the direction of the

specification m anager Sim ilarly, the design task m ay be shared between m em bers of

I 1 person-year of coding is involved (a person-year is the amount of work that can be

: !. d one y o pb ne erson in l year).The solution is apparently sim ple: lf one program mer '

è can code the product in 1 year, four program mers can do it in 3 m onths

!

, j This of course, does not work ln practice, the four program mers m ay take '

: nearly a year, and the quality of the resulting product w ell may be lower than if

!! one programm er had coded the entire product The reason is that som e tasks can be

shared but others m ust be done individually For instance, if one farm hand can pick a

l : strawberry held in 10 days, the same strawberry field can be picked by 10 farmhands

J 1 ln other words, tasks like strawberry pi cking can be ful ly shared' , ot hers, l ike

' baby production, cannot be shared Unlike baby production, it is possible to share

the team members However, team program m ing also is unlike straw berry picking in

that team m em bers have to interact with one another in a meaningful and effective

way For example, suppose Jane and Ned have to code two m odules m 1 and m 2 3

A number of things can go wrong For instance, both Jane and Ned may code ml 2

land ignore m2 O r Jane m ay code m 1 , and N ed m ay code m 2. But when m l calls .m2 it passes four arguments', Ned has coded m 2 in such a way that it requires five

argum ents Or the order of the arguments in m 1 and m2 m ay be different Or the

order may be the sam e, but the data types m ay be slightly different Such problems ï

us ual l r e ca us ed by de ci s on mad e dur i ng he des i gn pha s ha t s not pr opaga t d :

tlzroughout the development organization The issue has nothing whatsoever to do l

j

i n det ai l what has been accompl i hed t o dat e and what i s s tl i ncompl et e ln other

.

words, addi ng personnel to a late software project makes i t even l ater This principle '

i known as Br ooks ' s f' t w, af t er Fr ed Br ooks who obs er ved i t whi l e managi ng t he j

ln a large organization, team s are used in every phase of software production, :

ke

-'

between three computer professionols (soli

ke Ines) and when a fourth professioncl ioins

them ( dashed l ines).

t re

(

. and design' after which the im plementation is done by a team of two or three

pro-. gram mers Because team s are used m ost heavily during the im plementation phase,

l the problem s of team organization are felt most acutely during implementation.ln

j p other ways of or ganizing a programming team t hat i ncorporate the best features of

I

as an extension of them selves The difficulty w ith this is that a program mer who sees

a m odule as an extension of his or her ego certainly is not going to try to find all the

f aul t i hi s ode or her ' c ode An d i t he r aul t i i t er me d a bug, ke ome

1 : 1 i ns e ct ha t has r pt una s ed i nt o t he co de and coul d ha ve be en pr ev ent ed i onl y

! ;

i

the code had been guarded m ore zealously against invasion Som e years ago, wheni

! j software was still input on punched cards, that attitude was am usingly lampooned

1 by the marketing of an aerosol spray named Shoo-Bug The instructions on the label

j no bugs coul d poss i bl y i nf est he codc.

l W einbern's solution to the oroblem of Droeram mers beinc too closelv attached

not be considered something bad but rather a norm al and accepted event; the attitude

of the review er should be appreciation at being asked for advice, rather than ridicule

of the program m er for m aking coding errors The team as a whole develops an ethos,' a group identity, and m odules belong to the team as a whole rather than any one

individual

' i1 ': A group of up to 10 egoless program m ers constitutes a dem ocratic team W

ein-i 2 ! berg w arns that managem ent m ay have difticulty working with such a team.A fter

I

l

ea Cm sslcAk CHIEF PROORAMMKR n AM APPROM H @a

trvinc to cet promoted to the next level W hat is important is team identitv and m utual !

he was angl ing for more money and that the team (and especially its nominal man- 1.

ager) had some rather unorthodox ideas M anagement forced the nominal manager t

he m oney, which he then divided equally am ong the team Next, the entire l

to accept t

t t eam r esi gned and joi ned anot her company as a t eam 1

f The advantages and disadvantages of dem ocratic team s now are presented

hndi ng f aul t s The mor e f aul t f ound, he happi er ar e t he member s of a democr at i c j

team This posit ive atti tude l eads to more rapid det ection of faults and hence to high- '

quali ty code But there are some major problems As poi nted out previously, managers l

' may have difhcul ty accepting egoless programmi ng In additi on, a programmer with, ;

'

' say, 15 ears of experiy ence is likely to resent having his or her code appraised by !

einberg feels thategoless team s spring up spontaneously and cannot be im posed j

S from outside.Littl e exoeri mental research has been done on democratic oroerammi nz 1

team s, but the experience of W einberg is that dem ocratic teams are enorm ously pro- :

e ductive.M antei analyzed the democratic team organization using argum ents based on :I

Y theories of and experim ents on group organization in general rather than speciscally j

also works well in an industrial setting when there is a hard problem to solve O n a !

number of occasi ons, have been a member of democrat i c t eams hat have sprung up I d

spontaneousl y among computer professionals wi th research experi ence But once t he 1

task has been reduced to the implementation of a hard-won solution, the team must

l be reorzanized in a m ore hierarchical fashion

,such as the chief oroeramm er team

six-person team structured as in Figure 4.2 is unlikely to be able to perform 36

person-1 months of work in 6 mont hs; many hours are wasted i n meetings i nvolvi ng two or

é j a variety of nurses In addition, when necessary, the team uses experts in other areas,

' ! such as cardiologists or nephrologists This analogy highlights two key aspects of a:

l a CmssxAL CHI E F PROGRAMMER TE AM APPROACH *5 l

l

2

in Figure 4.3 It consisted of the chief programm er, who was assisted by the back-up 'program mer, the programm ing secretary, and from one to three programm ers W hen

necessary, the team was assist ed by speci ali sts in other areas such as l egal or fi nancial i

matters, or the job control language (JCL) statements used to gi ve operating system commands to the mai nframe computers of that era The chi efprogrammer was both a l

successful m anager and a highly skilled programm er who did the architectural design Iand any critical or com plex sections of the code The other team m em bers worked :

on the detailed design and the coding, under the direction of the chief programm er '

As shown in Figure 4.3, there w ere no lines of comm unication between the pro- Igramm ers; al1 interfacing issues w ere handled by the chief programm er Finally, the

chi ef pr ogrammer evi ewed t he work of he ot her eam member s, because t he chi ef 1

programm er was personally responsible for every line of code i1The position of back-up programm er was necessary only because the chief pro-

grammer was human and therefore coul d become ill , fall under a bus, or changejobs :Therefore, the back-up programm er had to be as com petent as the chief programm er I

in every respect and had to know as much about the project as t he c :

In addition, to free the chief program mer to concentrate on the architectural design,the back-up programmer di d bl ack-box test case planning (Section 14 7) and other

The word secretat y has a number of meanings On the one hand, a secretary as- '

sists a busy executive by answering the telephone, typing correspondence, and so on :

lk about the American Secretary of State or the Briti sh Foreign Sec- i But when we ta

l

r et ar y, we r ef er t o one of t he most seni or members of he Cabi net The pr ogrammi ng j

secretary was not a part-time clerical assistant but a highly skilled, well-paid, central I

l member of a chief programmer t eam The program ming secretary was responsible for !

mai ntaining t he project producti on li brary, the documentati on of the project This in- J

cluded source code listings,JCL, and test data The program mers handed their sourcecode to the secretary, who was responsible for its conversion to m achine-readable 1

I

form , compilation, linking loading, execution, and running test cases Programmers ' '

ltherefore did nothing but program A1l other aspects of their work were handled by the I

cli ppi ng hl e (' s morgue'' ) of the New Ft pr/ c Ti mes The cl ipping t ile cont ains abst racts

x and full articles from the Ncw York Times and other publications Reporters and other

members of the editorial staff use this inform ation bank as a reference source

vn

( of the code was written in the last 6 m onths

.Onl y 21 faul ts were detected in the ûrst St j

. 1 5 weeks ot acceptance testing', only 25 turther taults w ere detected in the first year W

i f o eration.Principal program mers averaged one detected fault and 10,000 LOC

q : was the New For/ c Iil nes project such a success, and why have simi lar results not been la

obtained on other projects?

:

One possible explanati on is that thi s was a prestige project for IBM lt was the :

, first real trial for PL/I, a language developed by IBM An organization known for its

I superb software experts, IBM set up a team comprising w hat can only be described as

-4 : t heir crème de la crème from one divi sion.Second, technical back-up was extrem ely

. , 1 strong PL/I com piler writers were on hand to assist the programm ers in every way

(

; t hey could, and JCL experts assisted wi th t he job control language A thi rd possible

explanation was the expertise of the chief program mer, F Terry Baker He is what is D

l :1 now called a superprogralnme6 a program m er whose output is four or hve tim es that ol

i 1 of an average good program m er.In addition, Baker is a superb manager and leader, wl

;

) j and it could be thathis skills.enthusiasm , and personality werethe reasons underlying pt

,then the chief program m er team organi- il

I .

@ ' ski lled programmers as wel l as a shortage of successt kl managers, and thejob descrip- ' e:

i 1 1 tion of a chief program mer requires both abilities.It also has been suggested that the al