Software Engineering (phần 2) pdf

For all these reasons, the docum entation for each phase of the software devel- 'opm ent process m ust be completed by the team responsible for that phase- before the next phase starts..

ax t u A p T : p a The so- ore protess

1 3. A product is constantly changing during developm ent.For examples the design

1

.

j usually has to be modif ied during the impl ementation phase to take into account

1 new informati on about t he product Unless the desi gn has been full y documented

, m odihcations to it will be extrem ely difhcult to achieve.

4 The original designers will have difhculty documenting the design after it has

:

been m oditied

For all these reasons, the docum entation for each phase of the software devel- 'opm ent process m ust be completed by the team responsible for that phase- before

the next phase starts Furthermore, the docum entation must be updated continually

to repect the current version of the product

ln this chapter,the phases through which a product passes are described,togetherwith potential difficulties that m ay arise during each phase.ln addition,testing proce-dures appropriate to each phase are described Solutions to the difficulties associatedwith the production of software usually are nontrivial,and the rest of this book is

t devot ed t o descri bi ng s ui t abl e t echni ques n t he f st pal 4 of hi s chapt er , onl y t he di f

j fi cult ies are highli ghted, but the reader is guided t o the relevant sections or chapters

j process but a guide to much of the rest of this book.

l After this description of problems appertaining to each phase,inherent difficulties

1

j of softw are production as a whole are presented The chapter concludes with national

;

.

and international initiatives to im prove the sottware process.

Q.l CkIKNT, p EvKkopER, ANp U sER

Som e prelim inary definitions are needed here The client is the individual or zation that wants a product to be developed The developers are the members of theorganization responsible for building that product.The developers m ay be responsiblefor every aspect of the process, from the requirements phase onward, or they may

organi-j be responsible for onl y the impl ementatkon of an al ready designed product The t erm

j so ft ware devel opment covers al l aspect s of sof t war e pr oduct i on bef or e t he product

1 enters the m aintenance phase A ny task that is a step toward building a piece of soft

i software development.And, after it has been developed

,the softw are is maintained

I

I Both t hecli entand developers may be part of the same organi zation Forexampl e,

l the client m ay be the head actuary of an insurance company and the devel

opers a team

!

headed by the vice-president for management information systems of that insurance

company This is t ermed internal sojtware development On t he other hand, with

c ont r aa x / wt z t t he cl i en t a nd de vel ope r ar e t ot a l y i nde pe ndent or gani za t ons

1 For ns t nc e, he l ent ma y be he De par t ment of Def ens e an d t he dev el op er s ma j or

defense contractor specializing in software for weapons system s.On a m uch smaller

!

'

scale, the client m ay be an accountant in a one-person practice and the developer astudent who earns incom e by writing software on a part-time basis

The third party involved in software production is the user The user is the person

or persons on w hose behalf the client has comm issioned the product and who willutilize the software ln the insurance company exam ple, the users m ay be insuranceagents, who will use the software to select the most appropriate policy ln som e

instances, the client and the user willbe the same person (for example, the accountantdiscussed previ ously).

As opposed to expensive custom software written for one client,m ultiple copies

of software, such as word processors or spreadsheets, are sold at m uch low er prices

to a large number of buyers That is, the manufacturers of such software (such asMicrosoftor Borland)recoverthe cost of developing aproductby volume selling This

type of software usually is called commercial t?.#'lt ç/ lc( /' (or COTS) software The earli er term for thi s type of software was shri nk-wrapped software, because t he box

containing the CD or diskettes, the m anuals, and the license agreem ent almost alwayswas shrink-wrapped Nowadays, COTS softw are often is downloaded over the W orld

W ide W eb there is no box to shrink w rap For this reason, COTS software nowadays

someti mes is referred to as cli ck-wrapped software COTS software is devel oped for

dhe m arket'' that is, there is no specihc client or users until the software has beendeveloped and is available for purchase

ln the next part of this chapter w e present the seven phases of the softw are lifecycle and carefully analyze the role played by testing in each phase The first phase

is the requirem ents phase

Q 2 R Eq UIRKM ENT: P HA S:

Software development is an expensive process The development process usually

be-i ns when t he cl i ent appr oaches devel opment or gani zat i on wi t h r egar d t o a s oft war e 1 g

product that,in the opinion of the client,is either essential to the profitability of his or

her enterprise or somehow can bejusti fied eeonomicall y At any stage of the process,

if the client stops believing that the software will be cost effective, development will i

terminate imm ediately.Throughoutthis chapter the assum ption is m ade thatthe client '

feels that the cost is justi fi ed (ln fact, the k ç cost' ' is not al ways purel y financi al For

exam ple, military software often is built for strategic or tactical reasons Here, thecost of the software is the potential dam age that could be suffered in the absence of

t he weapon being devel oped )

Atan initial m eeting between clientand developers the clientoutlines the product

as he or she conceptualizes it From the view point of the developers, the client'sdescription of the desired product may be vague, unreasonable, contradictory, or

simply impossible to achieve The task of the developers at this stage is to determ ineexactly what the client needs and to lind out from the client what constraints exist

A typical constraint is the deadline For exam ple, the client m ay stipulate that the fhnished product m ust be com pleted within l4 m onths A variety of other constraints ,

j (I

g The m ost im portant constraint usually is the cost However, the client rarely

tells the developers how much m oney is available to build the product Instead,a '

com m on practice is that, once the specitications have been linalized, the client asks

the devel opers to name their price for completing t he project Clients follow this

( bidding procedure in the hope that the amount of the developer's bid will be lower '

than the amount the client has budgeted for the project.

q This prelim inary investigation of the client's needs sometim es is called concept

) explorati on.ln subsequent meetings between m em bers of the development team and '

l

1 t he cli ent team, the functi onali ty of the proposed product is successively refined and

anal yzed for echni cal easi bi l y and ûnanci al just i hcat i on.

1

j Up to now, everything seem s to be straightforward Unfortunately, the

require-( ments phase frequently is performed inadequately W hen the product linally is deli

v-j er ed t o t he user , per haps a year or wo af t er he s peci hcat i ons have been si gned of f

j by the client, the client m ay say to the developers, t'l know that this is w hat l asked

$ for,but it isn't really w hat I w anted.' W hat the client asked for and, therefore, what

i

the developers thought the client wanted, was not what the client actually needed.There can be a num ber of reasons for this predicam ent First, the client may nottruly understand what is going on in his or her own organization For exam ple, it is

no use asking the software developers for a faster operating system if the cause of

; the current slow turnaround is a badly designed database Or if the client operates

'

an unprofitable chain of retail stores, the client m ay ask for a hnancial m anagem entinform ation system that reflects such item s as sales, salaries, accounts payable, andaecounts receivable Sueh a produet will be of little use if the real reason for the

losses is shrinkage (shopli fti ng, and theft by employees) lf that i s the case, then a )

! stock control product rather than a financial control product is required

of software and its functionality, the problem is far w orse for a client who is barely

i com puter literate.There are a number of ways of coping with this; one of them is

j much of the functionality of the target product but om its those aspects generally

l invisible to the client, such as file updating or error handling.The client and users

;

, then experim ent with the prototype to determ ine whether it indeed meets their needs.

The rapid prototype can be changed until the client and users are satisfied that it

responsibility is to ensure thatthe delivered productis what the client ordered and that

i h duct has been built correctly in every way

.This group is called the software

t e pro

quality assurance (SQA) group The quality of software is t he ext ent to which i t meets

2.a SPK IFICATION PHASE as

it s specifi cat ions Qualit y and software quali ty assurance are descri bed in more detail'

in Chapt er 6 as is the role of SQA in sett ing up and enforci ng standards.

! The SQA group must pl ay a rol e right from t he start of the development process.

In particular, it is vital that the product satisfy the client's needs.The SQA group,

therefore, m ust verify with the client that the tinal version of the rapid prototype istotally satisfactory

lt is essential that the rapid prototype be carefully checked by both client andusers to be certain that it reqects their current needs Nevertheless, no m atter howmeticulously this is done there always is the possibility that forces beyond the con-

trol of the developm ent team w ill necessitate changes in the requirem ents while the

product is being developed Further development then has to be put on hold until thenecessary m odihcations have been m ade to the partially com pleted product.

A major issue in software development is t he so-call ed moving target probl em.

'lnhat is, the client changes the requirem ents during developm ent One reason this curs is an unforeseeable change in circum stances For exam ple,if com pany expandsits operations, or is taken over by another com pany, then m any products have to be

oc-modihed, including those still under development However, the major cause of the

moving target problem is a client who keeps changing his or her m ind.As explained

in Section 16.4.4, nothing can be done about it if the client has sufticient clout.

2.2.2 RzqulR- zxTs PuAs: p o<uMKNTATIoN

The documentation produced during the requirem ents phase usually includes therapidprototype together with the records of the discussions w ith the client and users on thebasis of which the rapid prototype was built and m odified.lf the team decides not

, to build a rapid prototype, a requirements docum ent is draw n up that describes the

needs of the client This docum ent needs to be checked by the client,selected users,

and the devel opment t eam before t he SQA group scrutinizes it meticulously.

2.a SPK<IFItATI@ N PHA:E

Once the client agrees that the developers understand the requirements,the

spec/-cation docum ent is drawn up by the specification team As opposed to the inform al

requi rements phase, the specihcation document (oçspect jications) expli ci tldescri bes

the functionality of the product that is, precisely what the produet is supposed todo- and lists any constraints that the product must satisfy.The specitication docu-ment includes the inputs to the product and the required outputs.For exam ple, if theclientneeds a payroll product, then the inputs include the pay scales of each employee.data from a time clock, as well as inform ation from personnel files so that taxes can

be com puted correetly The outputs are paychecks and reports such as Social

. product m ust be able to handle correctly a wide range of deductions, such as m edical

insurance payments, union dues, and pension fund contributions

l The specitication document of the product constitutes a contract.The software

7 developers willbe deemed to have completed the contract when they deliver a product ,

j that satislies the acceptance criteria of the specification docum ent.For this reason, the

! ilication document should not include im precise term s like suitable

' i the case of internal softw are development, the specification

1 document always should be writ ten as if i t will be used as evidence in a trial.

M ore important the specihcation docum ent is essential forboth testing and m

ain-!

j tenance Unless the speciécation docum ent is precise, we cannot determ ine whether

' the specihcations are correct, let alone w hether the im plem entation satishes the

spec-ifications And it is hard to change the specihcations during the m aintenance phase1

F unless we have a document that tells us exactly what the specifications currently are

'

A variety of difficulties can arise during the specification phase One possiblemistake that can be made by the specification team is that the specifications are

tpnlhïglgouy -certain sentences or seetions m ay have m ore than one valid i

nterpreta-tion Consider the specihcation ''A part record and a plant record are read from the

database lf it contains the I ett er A di rectl y fol lowed by t he letter Q, then compute'

the cost of transporting that part to that plant.' To what does the it in the precedingsentence refer' the part record or the plant record? In fact, the it conceivably evencould refer to the database

The specifications also m ay be incomplete; that is, som e relevant fact or requiment may be om itted For instance, the specihcations may not state what actionsI

re-i are to be taken if the input data contain errors M oreover, the specilications m ay be

1

j colltradictory For exam ple, in one place in the specihcation docum ent for a product

! th t a controls a ferment ation process,i is stated that if the pressure exceeds 35 psi, '

, then valve M 17 imm ediately m ust be shut However, in another place, it is stated

i

) that if the pressure exceeds 35 psi, then the operator im mediately m ust be alerted;

only if the operator takes no remedial action w ithin 30 seconds should valve M 17 be

i shut automaticall y.Software developm ent cannot proceed until such problem s in the

specihcations have been corrected

E Once the specifcations are com plete, detailed planning and estim ating

com-!

, mences No cl ient wil l aut horize a soft ware project without knowi ng in advance how

long the project wi ll t ake and how much it wil l cost From t he viewpoint of t he velopers, these two i tems are just as important If the developers underestimate the cost of a project then t he client will pay the agreed fee, which may be signi hcantl y

de-less than the actual cost to the developers Conversely, if the developers overestim ate

what the project wil l cost, then the client may t urn down the project or have the job

' done by other developers whose estim ate is m ore reasonable Similar issues arise with

regard to duration estimation lf the developers underestimate how long it w ill take to

complete a project, then t he resulting late delivery of the product, at best, will result

a.a SPK IFItATION PHASE ay

in a loss of contidence on the part of the client At worst, Iateness penalty clauses inthe contract w ill be invoked, causing the developers to suffer financially Again, ifthe developers overestim ate how long it w ill take for the product to be delivered, the

cl ient may wel l award the job to devel opers who promi se faster delivery.

For the developers, merely estim ating the duration and total eost is not enough

The developers need to assign the appropriate personnel to the various stages of thedevelopm ent process For exam ple, the coding team cannot start until the design

documents have been approved by t he SQA group, and the desi gn team is not needed

untilthe specification team has completed its task In other words, the developers have

to plan ahead A software project management plan (SPM P) must be drawn up that

reiects the separate phases of the developm ent process and shows which m embers of

the developm ent organization are involved in each task, as well as the deadlines forcompleting each task

'I'he earliest that such a detailed plan can be draw n up is w hen the specihcations

have been hnalized Before that time, the project is too amorphous to undertake compl ete pl anni ng Some aspects of the project certainly must be pl anned right from

the start, but until the developers know exactly what is to be built,hey cannot specify

all aspects of the plan for building it

Therefore.once the specification docum enthas been finished and checked,

prepa-rati on of t he software project management plan commences M ajor components of the pl an are the deli verables (what the cli ent is going to get), the mi lestones (when the cl ient get s them), and t he budget (how much i t i s goi ng to cost).

The plan describes the software process in fullest detail lt includes aspects such

as the life-cycle model to be used, the organizational structure of the developm ent

organization, project responsibili ties, managerial objectives and priori ties, t he t

ech-niques and CASE tools to be used, and detailed schedules, budgets, and resourceallocations Underlying the entire plan are the duration and cost estim ates', techniques

lfor obtaining such estim ates are described in Section 9

2.a.1 spetlntATlow PHAS: W sTlxo

As pointed out i n Chapter l a major source of faul tsn deli vered software is faul ts in

the specihcation docum ent that are not detected until the softw are has been installed

on the client's computer and is being used by the client's organization for its intended

purpose The SQA group therefore must check t he specil icati ons carefully, l ooking forcontradi cti ons, ambi guities, and any signs of i ncompl et eness In additi on, the SQA

group m ust ensure that the specitications are feasible', for exam ple, that any specihed :hardware com ponent is fast enough or that the client's current online disk storage gcapacity is adequate for handling the new product If a specification docum ent is to

!

be testable,then one of the properties it must have is traceability It m ust be possible I

i

client team during the requirem ents phase lf the requirements have been presented

. methodicall y, properly numbered, cross-referenced and indexed, then the SQA group

should have little difficulty tracing through the specilication docum ent and ensuring .

; that it is indeed a true reflection of the client's requirem ents If rapid prototyping has

i been used in the requirem ents phase

,then the rel evant statements of the specifi cation i

document should be traceable to the rapid prototype

An excellent way of checking the specification document is by review tatives of the specification team and of the client are present The m eeting usually is

Represen-'

chai red by a member of the SQA group The aim of the review is to determi ne whether !

the specihcations are correct The reviewers go through the specification docum ent,

l ensuri ng that there are no misunderstandings about the document W alkthroughs and

?

inspections are two types of review s, and they are described in Section 6.2

1, Consider now the checking of the detailed planning and estimating that takes

place once the client has signed off the specitications W hereas it is essential that

every aspect of the SPM P be meti cul ousl y checked by the SQA group, parti cular

attention m ust be paid to the plan's duration and cost estimates O ne way to do this is

' for management t o obtain two (or more) i ndependent estimat es of both duration and

' cost at the start of the planning phase, then to reconcile any signilicant differences

W ith regard to the SPM P document, an excellent way to verify it is by a reviewsimilar to the review of the specification docum ent If the duration and cost estim ates

are sati sfactory, then the cli ent will give permissi on for the project t o proceed.

Q.a.2 SpztlyleATlox PuAsz lotu-zxn Tlox

i The specihcation phase has tw o prim ary outputs.The tirst is the specification

docu-ment (speci hcat ions) Chapt ers 1 1 and 12 describe how the specil icati ons are drawn'

up The second out put is t he software project management plan An explanati on of

i

, how to draw up the SPM P is given in Sections 9.3 though 9.5

The next stage is to design the product

the rest of the product (An object is a specihc type of modul e ) The interface of each

module, that is, the arguments passed to the module and the argum ents returned bythe m odule, must be specified in detail For exam ple, a m odule m ight measure the

w ater level in a nuclear reactor and cause an alarm to sound if the level is too low A

method i n an object of an avi oni cs product might take as input two or more sets of

2.* DESIGN PHASE a*

coordi nates of an i ncoming enemy missil e, compute its traject ory, and send a message

to another object to advise the pil ot as to possi ble evasive action.

Once the team has compl et ed the decompositi on i nto modules (the archit ecturaldesign), the detailed design is pedbrmed For each module, algorithms are selected

and data structures chosen

W hile the decom position into modules is being performed, the design team m ustkeep a careful record of the design decisions that are m ade This inform ation isessential for two reasons First, while the product is being designed, there will betimes when a dead end is reached and the design team feels the need to backtrack andredesign certain pieces Having a written record of why specific decisions were madeassists the team when this occurs and helps it get back on track

The second reason for keeping the design decisions concerns maintenance ally, the design of the product should be open-ended m eaning future enhancem entscan be done by adding new m odules or replacing existing modules without affect-ing the design as a whole Of course, in practice, this ideal is difficult to achieve

Ide-Deadline constraints in the real w orld are such that designers struggle against theclock to com plete a design that satislies the original specilication document, w ithout

worrying about any later enhancements lf future enhancements (to be added after theproduct has been deli vered t o the client) are included in the speci fi cati on document,

then these m ust be allowed for in the design, but this situation is extremely rare Ingeneral, the specilication docum ent, and hence the design, deals with only presentrequirem ents ln addition, there is no way to determ ine,while the product is still in thedesign phase, all possible future enhancements A nd finally, if the design has to take

all future possibilities into account, at best it will be unw ieldy', at worst, it w ill be socomplicated that im plem entation is impossible So the designers have to compromise,putting together a design that can be extended in m any reasonable ways without the

need for t otal redesign But, in a product that undergoes major enhancement the time

will com e when the design simply cannot handle further changes W hen this stage isreached, the product must be redesigned as a w hole A redesign team with a record

of the reasons for all the original design decisi ons has an easi erjob.

2.*.1 pzsllx PHAS: n sTlw.

As mentioned in Section 2.3 a critical aspect of testability is traceability ln the case

of the design, this means that every part of the design can be linked to a statement in

the specihcation document A suitably cross-referenced design gi ves the SQA group a

powerful tool for checking whether the design agrees w ith the specihcation documentand whether every statem ent of the specilication document is reiected in som e pal'

of the design

Design review s are sim ilar to the review s that the specihcations undergo How- iever,in view of the technical nature of most design docum ents, the client usually is not I

I

present M embers of the design team and the SQA group work through the design as l

a whole as well as through each separate m odule, ensuring that the design is correct @The types of faults to look for include logic faults, interface faults, lack of exception !

1

i

l

' *@ t H A v T : m a The softw ore protess

specihcations In addition, the review team always should be aware of the possibilitythat som e specihcation faults were not detected during the previous phase A detaileddescription of the review process is given in Section 6.2

Q *.2 l xslox PHAS: D OtUMKNTATION i

; the program m ers for implem entation Chapter 7 is devoted to the theory of design in

j' general and the design of objects in part icular Design t echniques, i ncl udi ng

object-oriented design, are described in Chapter 13, together with ways of describing thei

design, such as graphics and pseudocode

!

i

D uring the im plementation phase, the various com ponent modules of the design arecoded lmplem entation is discussed in detail in Chapters l4 and 15

:

I

The modules should be tested while they are being implemented (desk checkingq, and

afterthey have been implemented,they are run againsttest cases This inform altesting

1 is done by the program mer Thereafter the quality assurance group tests the m odules

l

1 methodi cally A vari et y of module testing techniques are described in Chapter 14.

1 In addition to running testcases,a code review is a powerful, successfultechnique

j for detecting program m ing faults Here, the program m er guides the members of the

, review team through the listing of the module The review team m ust include an

SQA representat ive The procedure is simi lar to reviews of speciEcations and designs ' descri bed previousl y As in a1 l t he other phases, a record of the act ivi ties of the SQA

group are kept

2.5.2 IMPk:MKNTATION Puhse potum xn Tlox

The major document ation associ at ed with impl ementation is the source code of each

,with suitable com ments But the program mers should provide additional

! docum entation to assist in m aintenance, including a1l test cases against which the

code was tested, the expected results, and the actual output These docum ents areused in regression testing, as explained in Section 2.7.1

1

2.* INTZGRATION PHASE *1

2.* INTE/RATION PHASK

The next stage is to combine the m odules and determ ine whether the product as a

whole functions correctly The way in which the modules are integrated (all atonce orone at a me) and the specihc order (from top t o bottom in the module i nterconnection diagram or bot tom to t op) can have a criti cal inl luence on t he quali ty of the resulting product For example, suppose the product is i ntegrated bottom up A major design :

fault, if present, will show up late, necessitating an expensive rewrite Conversely, '

if the modules are integrated top down, then the lower-level modules usually will

l

not receive as thorough a testing as w ould be the case if the product were integrated 'bottom up These and other problem s are discussed in detail in Chapter 15 A careful

explanation is given in that chapter as to why im plem entation and integration must :

be performed in parallel

Q.*.I INTKORATION P HAS: T.STING

The purpose of integration testing is to check that the modules com bine together rectly to achieve a product that satisfies its specihcations During integration testing,particular care m ust be paid to testing the m odule interfaces It is im portant that thenumber, order, and types of formal arguments match the num ber, order, and types of

cor-act ual arguments This strong type checki ng (van W i jngaarden et a1., 19751 is best

per-form ed by the com piler and linker However m any languages are not strongly typed

W hen such a language is used, checking the interfaces must be done by m embers of

W hen the integrati on testi ng has been compl eted, t he SQA group performs

prod-uct testing The functionality of the product as a whole is checked against the

spec-iications In particulars the constraints listed in the specitication docum ent m ust betested A typical example is whether the response tim e is short enough Because

the aim of product testing is to determ ine whether the specifications have been im plemented correctly, m any of the test cases can be drawn up once the specihcation

Not only must the correctness of the product be tested but also its robustness

That i intentionally erroneous input data are subm itted to determ ine w hether theproduct will crash or whether its error-handling capabilities are adcquate for dealing ;with bad data lf the product is to be run together w ith the client's currently installed

software, then tests also m ust be performed to check thatthe new product willhave noadverse effect on the client's existing com puter operations Finally, a check must be 'made as to w hether the source code and allother types of docum entation are com plete

and internally consistent Product testing is discussed in Section l5.4

The tinal aspect of integration testing is acceptance testing The software is !del ivered t o the cl ient, who tests i t on the actual hardware, using actual data as opposed r

;

to test data No matter how careful the development team or the SQA group might

be, there is a signilicant difference between test cases, which by their very nature 'are artificial, and actual data A software product cannot be considered to satisfy its :

i

l

(

!

: *Q t H A p T z R Q @ The Softw ore Protess

i specincations until the product has passed its acceptance tests.M ore details about

acceptance testing are given in Section 15.5

ln t he case of COTS software (Section 2 ), as soon as product t esti ng is compl ete,

1 versions of the com plete product are supplied to selected possible future clients for

testing on site.The first sueh version is termed the alpha version The corrected alpha

version is ealled the beta version; in general, the beta version is intended to be close

o the final version

l Faults in COTS software usually result in poor sales of the product and huge

1 losses tbr the developm ent company For as m any faults as possible to com e to light as

early as possible, developers of COTS software frequently give alpha or beta versions1

' to selected com panies, in the expectation that on-site tests w ill uncover any latent

its competitors A problem occurs sometimes when software organizations use alpha

, t esti ng by potenti al cli ents i n place of thorough product t esti ng by the SQA group.

i Although alpha testing at a number of different sites usually brings to light a large

variety of faults t here is no subst itut e for the met hodi cal testing that the SQA group

can provide

;

Q.*.% INT.* -TIoN PHAS: potu-zxTv low i

l The docum entation produced during this pbase consists of the com mented source

i code for the project as a whole, the t est cases for t he project as a whole, and the user

! m anual, operator m anual, database manual, and other m anuals

t

1 Once the product has been accepted by the client, any changes constitute m

ainte-nance M aintenance is not an activity grudgingly carried out after the product hasbeen installed on the client's com puter O n the contrary, it is an integral part of thesoftware process that must be planned forfrom the beginning As explained in Section

2.4, the design, as far as is feasible, should take future enhancements into account

Coding m ustbe perform ed w ith future maintenance kept in mind After all, as pointed

. out in Section I3, more m oney is spent on m aintenance than on all other softw are

r activities eom bined lt therefore is a vital aspect of software produetion M aintenance

m ust never be treated as an afterthought Instead, the entire software development @effort m ust be carried out in such a way as to m inimize the impact of the inevitable

f uture ma ni tenance

A common problem with maintenance is documentation, or rather a lack of it ln '

the course of developing software against a time deadline, the original specihcation land design docum ents frequently are not updated and, consequently, are almost use- lless to the maintenance team O therdocumentation such as the database manual or the

operating m anual may never be written, because management decided that delivering i

he roduct to the client on tim e was m ore im portant than developing the

documen-t ptation in parallel with the software ln many instances the source code is the onlydocum entation available to the maintainer The high rate of personnel turnover in thesoftware industry exacerbates the maintenance situation in that none of the originaldevelopers m ay w ork for the organization at the tim e when m aintenance is perform ed

M aintenance frequently is the m ostchallenging phase of software production for

the reasons stated previously and for the additional reasons given in Chapter l6

2.X 1 M AINTXNANe: P HA/: W STIN?

There are two aspects to testing changes to a produet during the m aintenance phase

The first is checking that the required changes have been im plem ented eorrectly Thesecond aspect is ensuring that, in the course of m aking the required changes to theproduct, no other inadvertent changes were m ade Therefore once the program m erhas determined thatthe desired changes have been implemented, the product m ust be

tested against previous test cases to m ake certain that the functionality of the rest of

the product has not been com prom ised This procedure is called regression testing

To assist in regression testing, it is necessary that all previous test cases be retained,together w ith the results of running those test cases Testing during the m aintenancephase is discussed in greater detail in Chapter l6

2.K2 M AINTKNANKK PuAse P/tUMENTATION

A major aspect of the maintenance phase is a record of al l the changes made, t ogether

with the reason for each change W hen software is changed, it has to be regressiontested Therefore, the regression test cases are a central form of docum entation forthis phase

Q e R ETIRKM ENTThe linal phase in the softw are life cycle is retirement After m any years of service,

a stage is reached w hen further m aintenance no longer is cost effective

l Sometimes, the proposed changes are so drastic that the design as a w hole wouldhave to be changed In such a case, it is less expensive to redesign and recode theentire product

; 2 So m any changes m ay have been m ade to the original design that interdependen- :

cies inadvertently have been built into the product, and even a sm all change to

7

one m inor module might have a drastic effect on the functionality of the product

as a whole

i

3 The documentation may not have been adequately m aintained, thus increasing

i the risk of a regression fault to the extent that it would be safer to recode than to

i

maintain

i 4 The hardware (and operating system) on which the product runs i s to be repl aced;

i m ay be m ore econom ical to rewrite from scratch than to modify

True retirem ent, on the other hand, is a som ewhat rare event that occurs when a

1 product has outgrown i ts useful ness.The client organization no longer requires the 'J

functionality provided by the product, and it finally is removed from the com puter

A fter this review of the com plete software process, together with som e ot the

difhculties attendant on each phase, it is time to consider difhculties associated with

Q.@ PRoekzM s w ITH SoF ARE PROPUtTI@N:

today's desktop personal com puter selling for under $ l000 It would seem that this

i trend is inexorable and that com puters w ill continue to becom e sm aller faster and

j Unfortunately, this is not the case A num ber of physical constraints m ust

even-; tually im pose lim its on the possible future size and speed of hardware The first ol

these constraints is the speed of Iight Electrons, or m ore precisely electrom agnetic

1 waves,sim ply cannot travel faster than l86,300 miles per second. One way to speed

up a computer therefore is to m iniaturize its com ponents In that way, the electronshave shorter distances to travel However, there also are lower lim its on the size of( com ponents An electron travels along a path that can be as nan-ow as three atom s

in width But if the path along which the electron is to travel is any narrower than !

t hat, then the electron can stray ont o an adjacent pat h For the same reason, parall el

paths must not be Iocated too close to one another Thus, the speed of light and the 7

j nonzero w idth of an atom impose physical lim its on hardware size and speed.W e '

i are nowhere near these lim its yet com puters easily can becom e at least two orders

of magnitude faster and sm aller without reaching these physical lim its But intrinsic

laws of nature eventually will preventelectronic com puters from becom ing arbitrarily

(

2

2.@ PROBLEMS W ITH SOFTW ARE PRODUCTION: E55ENCE AND ACCIDEN'S *5Now what about software? Softw are essentially is conceptual, and therefore non-

physical, although of course it always is stored on som e physical m edium such aspaper or m agnetic disk Superhcially, it might appear that w ith softwm'e anything is

possible But Fred Brooks, in a landmark arti cl e ent itled d ' No Sil ver Bull et' ' rBrooks,

19861, exploded t hi s beli ef He argued that, anal ogous to hardware speed and si ze

limits that cannot be exceeded physically, there are inherent problem s with currenttechniques of software production that never can be solved To quote Brooks, 'ubuild-

i ng software wi ll always be hard There is inherentl y no sil ver bullet '' (An explanat ion

of the term silver bull et is i n the Just i n Case You W anted to Know box belom ) Recall that the t itle of Brooks's arti cl e is '' No Silver Bullet' ' (aut hor's i tal icsl.

Brooks's them e is that the very nature of software m akes it highly unlikely that a

silver bullet w ill be discovered that magically w ill solve a1l the problem s of softwareproduction, let alone help achieve software breakthroughs com parable to those thathave occurred with unfailing regularity in the hardware field.He divides the difhculties

of software into two Aristotelian categories' essence, the difhculties inherent in theintrinsic nature of softwarei and accidents the difficulties encountered today thatare not inherent in software production That is, essence constitutes those aspects ofsoftware production thatprobably cannotbe changed, whereas accidents are amenable

to research breakthroughs, or silver bullets

W hat aspects of software production are inherently difhcult? Brooks lists four,which he terms complexity, ctprl-/èrvlï/ y, changeabilit y, and invi si bilit y Brooks's use

of the word complexity is somew hat unfortunate in that the term has m any differentmeanings in com puter science in general and in softw are engineering in particular Inthe context of his article, Brooks uses the word complex in the sense of Ekomplicated''

or dfintricate.' In fact, the nam es of allfour aspects are used in their nontechnical sense

Each of the four aspects is now exam ined

JusT IN ZAS: Y ou W ANTKP To Kxow

The t6silver bullet' in the tie of Brooks's articlrefers appears to be innocent and straightforward But, like a

to the recom m ended way of slaying w erewolves other- werew olf, softw are can be transformed into som ethingwise perfectly normalhuman beings who suddenly turn honifying,n the shape of late deadlines,exceeded bud-into wolves Brooks's Iine of inquiry is to determ ine gets and residual specification and design faults notwhether a sim ilar silver bullet can be used to solve detected during testing

the problem s of software A fter all, softw are usuall

** e s A p 4 z a a The sopw ore po cess

two words, w j and w 2 , each 16 bits in length, then the num ber of possible states of

w ords w ? and w , together is 2l6 times 2l6 or 232 In general,if a system consists of

a number of independent pieces, then the num ber of possible states of that system isthe product of the numbers of possible states of each com ponent

Suppose the computer is to be used to run a software product p and the l6-bit

word w is to be used to store the value of an integer x If the value of x is read in

by a statement such as read (x), t hen, because the integer x can take on 21 6 different

values, at Erst sight im ight seem thatthe number of states in which the product could

be is the sam e as the num ber of states in which the word could be lf the produet pconsists only of the single stat ement read (x), then the number of st ates of p i ndeed

would be 216.But in a realistic, nontrivial software product,the value of a variable that

is input is later used elscwhere in the product There is an interdependence between

the read (x) statement and any statement t hat uses the value of x The situation is L

m ore com plex if the flow of control within the productdepends on the value of x For

example, x may be the control variable in a sw i kh statement, or there may be a for

l oop or whi l e l oop whose termi nati on depends on the val ue of x Thus the number of

states in any nontrivialproduct is greater,because of this interaction, than the product

of the number of states of each variable As a consequence of this com binatorialexplosion in the number of states complexity does not grow linearly w ith the size of

the product but much faster

Com plexity is an inherent property of software Irrespective of how a nontrivialpieee of software is designed, the pieces of the product interact For exam ple, thestates of a module depend on the states of its argum ents, and the states of global

variables (variables t hat can be accessed by more than one module) also affect the

state of the productas a wholc Certainly, com plexity can be reduced; for exam ple, by

using the object-ori ent ed paradi gm Nevert hel ess, i t never can be el iminated totall y.

In other words, com plexity is an essential property of softw are not an accidental one

Brooks points out that com plex phenom ena can be described and explained indisciplines such as m athematics and physics M athematicians and physicists havelearned how to abstract the essential features of a com plex system , to build a sim ple

m odel that re:ects only those essential features, to validate the simple m odel, and to

m ake predictions from it ln contrast, isoftw are is sim plitied, the whole exercise isuseless', the sim plifying techniques of mathem atics and physics work only because the

:

ë complexities of those systems are accidents, not essence, as is the case with software

products

The consequence of this essential complexity of softw are is that a product

be-! com es difficult to understand In fact, often no one really understands a large product

: in its entirety This leads to imperfect comm unication between team mem bers that,

in turn, results in the tim e and cost overruns that characterize the developm ent of

large-scale software products ln addition, errors in specifications are m ade simply

1

t because of a lack of understanding of a11 aspects of the product

! This essential complexity affects not only the software process itself but also '

E the m anagem ent of the process Unless a manager can obtain accurate information

' regarding the process he or she is managing, it is difhcult to determ ine personnel

needs for the succeedi ng stages of the project and to budget accuratel y Report s to

senior management regarding both progress to date and future deadlines are likely to

l

2.@ PROBLEMS W ITH SOFTWARE PRODUCTION: EH ENCE AND ACGIDENTS 47 j

be inaccurate Draw ing up a testing schedule is difficult when neither the m anagernor anyone reporting to the manager knows what loose ends still have to be tied And

if a project staff member leaves t ryi ng to trai n a repl acement can be a nightmare.

A further consequence of the complexity of software is that it com plicates the imaintenance process A s show n in Figure l2, about two-thirds of the total softw are Ieffort is devoted to m aintenance Unless the maintainer really understands the prod-

that further m aintenance is required to repair the damage caused by the original m ain- '

tenance The possibility of this sort ofdamage being caused by carelessness alw ays is

.

present, even when the original author makes the change, but it is exacerbated when '

E

the m aintenance program mer effectively is working in the dark Poor docum entation', :

or worse, no documentati on' , or stil l worse i ncorrect documentation often is a major i

caus e of ncor r ect l y per for med mai nt enance But , no mat t er how good t he document a- j

' ftware transeends all attem pts to cope with 'tion m ay be, the inherent complexity ot so

it; and this com plexity has an unfavorable im pact on m aintenance.Again the oriented paradi gm can hel p reduce complexity (and hence improve maintenance), but

object-it cannot eliminate it com pletely

The task of the software developm entteam is to construct a productthat w ill interface

with the existing plant That is, the software m ust conform to the plant not the plant

to the software This is the lirst type of conform ity identihed by Brooks where ware acquires an unnecessary degree of complexity because it has to interface with

ogether in a natural and straightforwal'd m anner.In practice, however,there generally i

is a perception that it is easier to m ake the software interface contbrm to the othercomponents than to change the way the other com ponents have been conhgured in 1

t he past As a result, even in a new gol d ref inery, t he other engineers will i nsist on idesigning the m achinery as before, and the software w ill be forced to conform to the ihardware interfaces.This is the second type of confbrmity identihed by Brooks, where @

the software, because the com plcxity is not due to the structure of the softw are itself.

'

lnstead, it is due to the structure of software caused by the interfaces, to humans or

to hardware, imposed on the software designer (but see the Just in Case You W anted

to Know box on page 48 for details of how this may change in the future) 4

I

i J us: lu tws You w Axn p vo Kxow

! According to Section 14,pages l5-l7 ot the Technical and Okuda, 199 lJ l hope that, in this respect at least,

Manual for the Star Trek starship U.S.S Enterprise Star Trek turnsout to be science factrather than science

j NCC-I701-Ds much of the software development was fiction

l started before the hardware development (Sternbach

1 As poi nt ed out in Secti on l l it i s consi dered unreasonable to ask a ci vil engineer

to move a bridge 300 m iles or rotate it 900, but it is perfectly acceptable to tell a

l software engineer to rewrite half an operating system over a s-year pcriod.Civil

engineers know that redesigning half a bridge is expensive and dangerous', it is bothcheaper and safer to rebuild it from scratch Softw are engineers are equally w ellawarethat, in the long run, extensive maintenance is unw ise and rewriting the product from

. scratch som etim es willprove less expensive Nevertheless,clients frequently demand

major changes t o software.

l Brooks points out that there always w ill be pressures to change software After

all, it is easier to change software than, say, the hardware on which it runs; that is the

reason behind the terms Ncffware and hardware In additi on, the functionality of a

system is em bodied in its software, and changes in functionality are achieved through1

j changi ng t he s oft war e.t has been suggest ed t hat t he pr obl ems caused by f r equent

!

, and drastic maintenance are m erely problem s eaused by ignoranee, and if the publie

, at large were better educated with regard to the nature of software, then demands for

major changes woul d not occur But Brooks poi nts out that changeabili ty is a property

j of t he ess ence ot sof t war e, an i nher ent pr obl em t hat cannot be surmount ed That s,

r the very nature of software is such that, no m atter how the public is educated, there

i alw ays w ill be pressures for changes in software, and often these changes will be

of the original design

, 3 O ne of the greatest strengths of software is that it is so much easier to ehange

than hardware

1

: 4 Successful software survives well beyond the lifetime of the hardware for which

i was written In part, this is because, after 4 or 5 years, hardware often does notl

2.@ PROBLEM: W ITH SOFTWARE PRODUW ION: E55ENC: AND ACCIDENTS *@function as w ellas itdid.Butm ore significant is the factthattechnologicalchange

is so rapid thatm ore appropriate hardware com ponents,such as larger disks. fasterCPUS, or more powerful m onitors, become available w hile the software still is I

Iviable ln general, the software has to be modihed to some extent to run on the Inew hardware

For all these reasons, part of the essence of software is that it has to be changed, '

and this inexorable and continual change has a deleterious effect on the quality of

2.*.* Ixvlslelkla

A majorproblem wi th the essence of software is that itis ts invisibl e and unvisuali zable'' !

E Brooks, 19861 Anyone who has been handed a 200-page listing and tol d to modify '

the software in som e way knows exactly what Brooks is saying.Unfortunately, there

is no acceptable way to represent either a complete product or some sol4 of overview

of the product In contrast, architects, for exam ple, can provide 3-dim ensional m odels

that give an idea of the overall design, as w ell as z-dim ensional blueprints and otherdetailed diagram s that, to the trained eye, will renect every detail of the structure

to be built Chem ists ean build models of m olecules,engineers can construct scalemodels, and plastic surgeons can use the com puter to show potential clients exactlyhow their faces w ill look after surgery D iagram s can be draw n to reoect the structure

of silicon chips andotherelectronic components; the components of a computercan berepresentC ed by m eans of various sorts of schematics, at various levels of abstraction. jertainly, there are w ays in which software engineers can represent specilic

views of their product For example,a software engineer can draw one directed graph l

;depicting flow of control, another showing flow of data,a third with patterns of

dependency, and a fourth depicting time sequences Also,UM L diagrams (Chapters

12 and l 3) have proven to be a powed' ul tool for depkting vi ews of large-scal e

software The problem is that few of these graphs are planar,let alone hierarchical.

The many crossovers in these graphs are a distinct obstacle to understanding.Parnas

Isuggests cutti ng the arcs of t he graphs until one or more becomes hi erarchical Lparnas, '

19791 The problem is that the resulti ng graph, though comprehensi bl e makes only

a subset of the software visualizable and the arcs that have been cut may be criticalfrom the viewpoint of comprehending the interrelationships am ong the components $

of the software

The result of this inability to represent software visually not only makes

soft-ware difhcult to comprehend, italso severely hinders comm unication among software I

pprofessionals there seem s to be no alternative to handing a colleague a 200-page r

listing together with a list of modihcations to be m ade

aspects of the product Visualrepresentations are an excellent m eans of com

municat-ing with the client as well as with other software engineers.The problem is that such

E

I

1

2

5* t H A p T E k 2 The SoWw ore Protess

diagram s cannot em body every aspect of the product, nor is there a way to determ ine 1

not essential, difhculties He evaluates various technical developm ents currently

ad-vanced as potential sil ver bullets, including proofs of correctness (Sect ion 6 5), ori ented design (Secti on 13 6), Ada, and artifi cial i ntel ligence and expert systems Al-

object-though som e of these approaches m ay solve rem aining accidental difficulties, Brooksfeels they are irrelevant to the essential difhculties

To achieve comparable future breakthroughs, Brooks suggests thatw e change theway software is produced For exam ple, whenever possible, software products should

be bought off the shelf (that is, COTS software) rather than custom built For Brooks,

the hard part of building software lies in the requirem ents, specilication, and design

phases- notin the implementation phase.The use of rapid prototyping (Section 10.3)for hi m is a major potential source of an order-of-magni tude improvement Another suggest ion that, in Brooks' s opini on, may lead t o a major i mprovement in productivi ty

is greater use of the principle of incremental developm ent, where instead of trying tobuild the product as a whole, it is constructed stepwise This concept is described inSection 5

For Brooks, the greatest hope of a major breakthrough in improvi ng software

production lies in training and encouraging great designers A s stated previously, inBrooks's opinion,one of the hardestaspects of software production is the design phase,and to get great designs, w e need great designers Brooks cites U NIX , A PL, Pascal,

M odula-z, Sm alltalk, and FORTRA N as exciting products of the past He points outthat they all have been the products of one or a very few, great m inds On the otherhand, m ore prosaic but useful products like COBOL, PL/l ALG OL, M VS/360, and

M S-DO S have been products of com m ittees N urturing great designers for Brooks is

the most important objecti ve if we wish to i mprove software production.

Parts of Brooks's paper m ake depressing reading After all, from the title

on-ward, he states t hat t he inherent nature (or essence) of current soft ware product ion

m akes finding a silver bullet a dubious possibility Nevertheless, he concludes on anote of hope, suggesting that, if we change our software production strategies by buy-ing ready-m ade software wherever possible using rapid prototyping and incrementalbuilding techniques, and attempting to nurture great designers, we m ay increase soft-ware productivity However,an order-of-m agnitude breakthrough, the ''silver bullet,''

is m ost unlikely

Brooks's pessim ism m ust be put into perspective Over the past 20 years, thesoftware industry has shown a steady increase in productivity of roughly 6 percentper year This productivity increase is comparable to w hat has been observed in m any

! 2

.44 CAPABILITY M ATURITY M QDELS 51

:

' i l ver bul l et ' a 1 manuf act uri ng i ndust r es what Br ooks i s ooki ng for, t hough i s a s

way of rapidly obtaining an order-of-m agnitude increase in productivity lt is difhcult i

to disagree w ith his view that we cannot hope to double productivity overnight At the sam e time, the com pound growth rate of 6 percent means thatproductivity is doubling :

I

every 12 years This improvem ent may not be as rapid and spectacular as w e would ;

like, but the software engineering process is improving steadily from year to year

The rem ainder of this chapter is devoted to national and international initiatives :

L

2

Our global economy is cri ti cally dependent on computers and hence on software i

For this reason, the governments of many countri es are concerned about t he software i

I process For exampl e, in I 987 a task force of the U. S. Department of Defense (DoD) j

r por t d: s Af t r t wo de e ades of ar ge l unf ul f l ed pr omi s es bout r oduc t vi t y a nd '

qua l y ga i ns om a ppl yi ng ne w s of t wa r me t hodol ogi e nd t ec hnol ogi e, industry

r

and governm ent organizations are realizing that their fundam ental problem is the

In response to this and related concerns, DoD founded the Softw are Engineering !

; Institute (SEl) and set it up at Carnegie M ellon Universi ty in Pittsburgh on the basis k

of a competi tive procurement process One major success of the SEl has been the ' capabili ty maturity model (CM M ) initiative Related software process i mprovement !fforts include the ISO gooo-series standards of the lnternational Standards Organiza- 'e

tion, and ISO/IEC 15504, an international software im provem ent initiative involving

m ore than 40 countries W e begin by deseribing CM M

i

;

The capability maturity models of the SEl are a related group of strategies for

improv-ing the software process, irrespecti ve of the actual life-cycl e model used (The term '

!maturity is a measure of the goodness of the process itself.) The SEl has devel oped : CMM S for software (SW -CM M ), for management of human resources (P-CMM ; the !

# stands for ' K peopl e' ' ), for systems engi neeri ng (SE-CM M ), for i ntegrated product ' development (lPD- CM M ), and for software acquisi tion (SA-CM M ) There are some i

iinconsistencies betw een the m odels and a inevitable levelof redundancy.Accordingly,

i

in 1997

,it was decided to develop a single integrated framework for maturity models,

capabi lit y maturit y model integration (CM M I) Four of these five existi ng capabil - '

ity m aturity m odels have been integrated into CM M I, and SA-CM M is due to be '

incorporated later Addi tional di sci plines may be added in the future ( SEI, 20001 '

l

!