Software Engineering (phần 4) pps

Program ming-in-the-small refers to software development at the level of the code of a single m ule, whereas programm ing-in-the-large is software development at the module level DeRemer

, j two activities, an environm ent supports the complete software process or, at the very y

;!2 least,a large porti on of the software process (Fuggetta, 19931 Figure 5.8(c) depi cts s

1 ironm ent that supports a1l aspects of al1 phases of the life cycle

' ! example, suppose that specifications are produced m anually.A mem ber of the devel- g

y ; opment team has no way of telling w hether a particular specification document is the kd

k I current version or an older version There is no way of knowing if the handwritten ' %

'i !, : : c anges onh thatdocumentare partof the current specification or were m erely a sugges- oj

; ( ' , ti on later reject ed On the other hand, if the specifi cations of the product are produced p

i ': 5 , us gin a CASE tool.then at any time there is only one copy of the speciscations, the , tlr

'

i

1 online version accessed via the CA SE tool Then, if the specifications are changed, pl

i i mem bers of the developm ent team easily can access the docum ent and be sure that

ặ

! I k ! they are seeing the current version In addition, the consistency checker will flag any ff

1 design changes without corresponding changes to the speciscation docum ent

i

'

i

1 I program m ers also need online docum entation

.For example online help infor- ' d,

! m ation m ust be provided for the operating system , editor, program ming language, sti

: and so on.ln addition, program mers have to consult m anuals of m any kinds, such '

l

E:

1 as editor m anuals and program ming m anuals lt is highly desirable that, wherever at

1 ossi ble,these m anuals be available online. Apart from the convenience of having irl

, CASE also can assist with com m unication am ong team mem bers E-m ail is

i rapidly becom ing as m uch a part of an average office as a computer or a fax m

a-!

; chine.There are m any advantages to e-m ail. From the viewpoint of software pro- '

@ I j duct ion, if copi es of a1l e-mai l relevant to a specif ic project are st ored in a particular th ' 1!

i lbox, there wi ll be a written record of the decisi ons made duri ng the project , is

r'j l ( ' i This can be used to resolve conflicts that m ay arise later M any CASE environments m

.: : 7 j

:@ ' ,

ơ ! y

IlII

3tS !, The term coding tools refers to CA SE tools such as text editors, debuggers, and ' :

pretty printers designed to simplify the program m er s task, reduce the frustration'n- that many program mers experience in their w ork, and increase program m er produc-

tvity Before discussing such tools, three detinitions are required Program

ming-in-the-small refers to software development at the level of the code of a single m ule, whereas programm ing-in-the-large is software development at the module level( DeRemer and l fron, 19761 The l at ter incl udes aspects such as archi tectural de-

od :E sign and integration Program ming-in-the-m any refers to software production by a

: team At times, the team will work at the module Ievel', at times, at the code level

Thus program m ing-in-the-many incorporates aspects of both program m ing-in-the- !

7or ' A structure editor is a text editor that 'sunderstands'' the im plem entation lan- :

I

zl- guage That is, a structure editor can detect a syntax fault as soon as it has been

ë

he keyed in by the program mer

,speeding the implementation phase because time is not

;

en wasted on futile com pilations Structure editors exist for a wide variety of languages,

)s- : operating system s, and hardware Because a structure editor has knowledge of the ,

ed ' Programm ing language, i t is easy to incorporate a pret ty print er (or formatt er) i nto r.

he the editor to ensure that the code always has a good visual appearance For exam

-) d, pl e, a pretty printer for C++ wil l ensure that each l is indented t he same amount

1at as its corresponding f An early example of a structure editor t hat i ncorporates a 2

ny fonnatter is the M acintosh Pascal edit or lApple, l 9841 Reserved words are auto- r

matically put in boldface so that they stand out, and indentation has been carefully:)r- designed to aid readability ln fact, m any M acintosh editors are totally or partially

je, ' structured

l

ch : Now consider the problem of invoking a method w ithin the code, only to discover

rer at linkage time that either the method does not exist or it has been wrongly specilied

ng ' in some way.W hat is needed is for the st ructure edi tor to support onli ne int er face

L y checking That is, just as the structure edi tor has i nformation regarding the name of

)n, every variable declared by the program m er, so it m ust also know the name of every

py method detined within the product For exam ple, if the program mer enters a call

res but m ethod computeAverage has not yet been dehned, then the editor im m ediately '

responds with a message such asis

1a

i

: O- At this point, the programmer i s gi ven two choices, eit her t o correct t he name of l i 2

lar the method or to declare a new method nam ed com puteAverage.If the second option I E

!

Ct is chosen,the program mer also m ust specify the arguments of the new method.

Argu-XS ment types must be suppl ied when decl aring a new method because the major reason i

I

I

! k1

1

j i

se argum ents of method q, before attempting to code the call to q Better yet,

: I ' I the editor should generate a template for the call

,showing the type of each argum ent

@ j :

: The programm er m erely has to replace each form al argum ent by an actual argum ent

j '

1

, A major advantage of onli ne interface checking is thathard-t o-detectfaul ts caused

i ; by calling m ethods with the wrong number of argum ents or argum ents of the wrong

l l ' t e are imm ediately :agged.Online interface inform ation is im portant for the effi

: argument, then every component that cal ls vaporcheck must automati cally be di :

,g Cl earl y, there can be no compi lation faul ts, but the compi ler still has to be invoked

$ to perform code generation.Then the linker has to be called Again the program

; within the editor That is, a program m er should be able to give operating system

4 j ' com m ands from within the editor To cause the editor to invoke the com piler, linker,

! ) ' loader, and any other system software needed to cause the module to be executed

1 i , g can be achieved by using the make command (Secti on 5 9) or by invoking a shel l

i : ? ' I l script tsobell, 19951 Such front ends can be impl emented in other operati ng systems '

! ;

s.* 5:op: oF CA5E Am I'

; '

Face One of the m ost frustrating computing experiences is for a productto execute for iCall a second or so.then term inate abruptly printing a m essage such as 'vith

Overfl ow at 508

F our

n Of The program mer is working in a high-level language such as Java or C+ + , not a '

low-level Ianguage like assem bler or m achine code But when debugging support

i s of the Overfl ow ot 506 variety, the programmer is forced to examine machine. code core dum ps, assem bler listings, linker listings, and a variety of sim ilar low-level

. documentation, thereby destroying the whole advantage of program m ing in a

high-level language A sim ilar situation arises when the only information provided is theinfam ous UN IX m essage

ja jn sgure 5.9 is a great improvement i

In the event of a failure the message s own

.iover the earlier terse error messages

.The program mer im mediately can see that the jlsed f ttem pt to divide by 0

method failed because o an a

effi- f ila ure was detect ed, namely, line 6, together wi th t he precedi ng and foll owi ng four or ;

lced ja mer then probably can see what caused the failure and m ake

P tools, program mers had to insert appropriate print statements into their code by

onal hand that, at execution tim e, would indicate the line num ber and the va uesI of tjae

dis- relevant variables. This now can eb done by giving com m ands to a source-level

de-re of bugger that automatically causes trace output to be produced. Even better s anj in.

code W hen a breakpoint is reached, execution stops and debugging m ode is en- I

r am- tered.The program mer now asks the debugger to trace the variable escape e oc tyv I i ' :

!

l then has the option of entering further debugging com mands

,for exam ple, to

! I j execution mode The programmer similarly can interact with the debugger

when-' 1 ? ever the method comput eTrai ect ory is entered or exited.such an interactive

t ' 1 Capabilities,Operating System frontend, source-leveldebugger,and online docum

enta-1 I tion- -constitutes an adequate and effective program m ing workbench 1

l ) ; can be tentat ively produced Quit e the cont ral y the necessal ' y t echnology has been 4

è h ', . in place for over 20 years, and it is somewhat surprising that there are program m ers 1

j'2s.y SOF- ARE W RsloNs 12a :

DC- version intended to replace it The new version is termed a revision The presence j

ner Of multiple versions apparently is easy to solve any old versions should be thrown

re- : away, l eaving just the correct one But that would be most unwise Suppose t hat the I

ious version of the m odule was revision n, and that the new version is revision i L

nal n + 1 First, there is no guarantee that revision n + 1 will be any more correct 'en- than revision n Even though revision n + 1 m ay have been thoroughly tested by

ce- t he soft ware quali ty assurance (SQA) group, both in i solation and li nked to the rest

L m- of the product, there may be di sastrous consequences when the new version of the 1

.

SE product is run by the user on actual data Revisi on n must be kept for a second reason I

The product m ay have been distributed to a variety of sites, and not aIl of them may I

1

be have i nstalled revi sion n + 1.If a fault report is received from a site still using

zed revision n,then to analyze this new fault, it is necessary to conhgure the product in

exactly the sam e way it is conligured at the user's site, that is, incorporating revisioning n of the m odule It therefore is necessary to retain a copy of every revision of each

As described in Section l.3, perfective m aintenance is perform ed to extend the 1

d l es are writt en' , in other cases, ' 1 ere functi onali ty of a product.ln some instances, new mo u 1'ley existing m odules are changed to incorporate this additional functionality These new )

;tial versions also are revisions of existing m odules So are m odules changed when per- j

i hanges made to the product i n response to l

z en changes i n t he envi r onment i n whi ch t he product oper at es As wi t h cor rect i ve mai n- j

l ers tenance aIl previ ous versions must be retai ned because issues arise not just duri ng '.ike the maintenance phase but from t he impl ementation phase onward After all, once a I

printer The operating system therefore m ust contain two variations of the printer :ase driver, one for each type of printer Unlike revisions, each of which is written specif-

ically to replace its predecessor, variations are designed to coexist Another situationwhere variations are needed is w hen a product is to be ported to a variety of different ,operating system s or hardware A different variation of m any of the m odules m ay

' have to be produced for each operating system-hardw are combination. !

t

Versions are schematically depicted in Figure 5.10, which shows both revisions t

t is and variations To com plicate matters further, in general, there w ill be m ultiple revi- ' i:ave sions of each variation For a software organization to avoid drowning in a morass of

leW m ultiple versions, a CASE tool is needed ;

l

i i

! l I' j ylgu- sao schematic representotion of multple

ver si ons of modul es, showi ng ( c) r evi si ons and (

j I! i The code for every module exists in three form s First is the source code nowadays !, /

; : generally written in a high-level language like C+ + Java, or Ada Then there is the A

k : j compl et e product i s built is call ed the conhguration of that version of the product.

i I Suppose hat a pr ogr ammer gi ven a t es tepol ' fr om t he SQA gr oup, st at i ng t hat ( i

j

j a m odule failed on a specilic set of test data.O ne of the first things to do is attem ptto t

l ' , ! recreat e the fai lure But how can the programmer determi ne which revi si ons of which

!

, 1 iations went into the version of the product that crashed? U nless a conhguration- &

'

1 trol tool (described in the followi ng discussion) is used

,the only way to pinpoint ;

i ;

'

) : the source of error is to look at the executable load image, in octal or hexadecim al : i

b !' f orm a ,t and compare i t to the object code, also in octal or hexadeci mal.Specihcally, t;) è

.: ' 1 g that the correct version of each m odule is com piled and linked to the product Second, y

i S j ; :l there is the inverse problem : Given an executable load im age,determ ine which version . il

i 1 i i of each of i ts components went into it ë r)

I ,

I.I

1

m any do not, in which case a separate version-control tool is needed A com mon !

!technique used i n version control is for the name of each fi le t o consist of two pieces, jthe file name itself and the revision num ber.Thus, a m odule thatacknowledges receipt

I

of a message wi ll have revisions acknowl edgeMessage / 1 , acknowl edgeMessage 1

I

àys / 2, and so on, as depicted in Figure 5 l2(a) A programmer then can speci fy exactly

tch With regard to multiple variations (slightly changed versions that fulfill the same '

e rol e i n different si tuations), one useful notati on is t o have a basic fil e name, followed

g

;

of by a variati on name in parentheses (Babich, 19861 Thus two printer drivers are given

the t he names pri nt erDri ver (inuet) and printerDri ver (I oser) l

I

) Of course, there will be m ultiple revisions of each variation, such as printerDriver !

hat : (l oser) / 1 2, printerDri ver (I aser) / 1 3, and pri nterDri ver (I aser) / 1 : This is '

ich A version-control tool is the lirst step toward being able to m anage m ultiple

I

an- versions Once it is in place a detailed record (or derivation) of every version of the

yint product m ust be kept The derivation contains the name of each source code elem ent, I '

! i

nal including the variation and revision,the versions of the various compilers and linkers j

l y, us ed, he name of he per son who cons t nl ct ed t he pr oduct , and of cours e, he dat e and '

ect the tim e at w hich it w as constructed

A e Version control is a great help in m anaging multiple versions of m odules and the

àch product as a whol e But more thanjust version control is needed, because of addi tional

pth problems associated w ith maintaining m ultiple variations 1 ;

! ;

;

so Consi der the two vari ati ons pri nf erDri ver (i nklet) and prinf erDri ver (I aser) Sup- ! j

nd, pose that a fault is found in pri nterDri ver (inuet ) and suppose that the fault occurs ' :

ion in a part of the m odule that is com m on to both variations Then it is necessary to fix

not onl y print erDri ver (i nuet) , but also print erDri ver (I aser) In general, ithere are E

op- v variations of a m odule, all p of them have to be fixed N ot only that, but they have :

l

:

:i') i ' yI ure sa2 M ul@ tple revisions and variations.(a) Four revisions of module , p

) : ac knowl edgeMessage ( Two vari at i ons of modul e pri nt erDri ver, wi t h t hr ee revi si ons of vari at i on ,

1 l t ion to t his problem is t o store just one variation

,say printerDriver ' iF

î

l i (i nkl et) Then any other variation is st ored in terms of the list of changes that have b

i to be m ade to go from the original to that variation.The list of differences is term ed c

! l configuration control goes beyond m ultiple variations

.A conhguration-control tool Al

1 14: j I C uxes he s econd f aul t has he changes approved, and i ns t al l modul e mDual / 1 8 ft

i ' 1 Unfortunately, revisi on 1 Zcont ains the changes of only the f irstprogrammer, whereas b l

I

s a CoNFlouRv loN CONTROL 1xy '

: '

revision 1 8 contains those of only the second program mer Thus, al1 the changes of '

Although the idea of each program mer making individual copies of a m odule : 1

.j

is far better than both working together on the same piece of software, clearly that :

is inadequate for m aintenance by a team W hat is needed is som e m echanism thatallows only one user at a tim e to change a m odule

Once it has been decided which m odule has to be changed to fix the fault, the ; 1'

1

programmer/rct uc: t he current versi on of t he module that he or she is goingto alt er No '

'on other program mer m ay m ake changes to any frozen version A fter the maintenance 2

!programmer has made changes and they have been tested, the new versi on of t he i

I

module is installed, thereby m odifying the baseline.The previous version,now frozen,

is retained because itm ay be needed in the future, as explained previously,butitcannot ,

After t he changes have been tested, the resulting revi sion, mDual / 1 7, becomes the !

mer W hile a m odule is in the process of being coded, versions are changing too rapidly :

1 8 for conhguration control to be helpful However, once coding of the m odule has ,

reas been com pleted it should im mediately be tested inform ally by its programm er, as

, i group for methodical testing As soon as the modul e has been passed by the SQA l

roup, i t i s ready to be i ntegrated into t he product From then on, i t should be subject I

! : ! to the sam e configuration

control procedures as those of the m aintenance phase Any

l hange to an integrated m odule can have an im pact on the product as a whole in the

ê

.i j j The t hr ee maj or UNIX versi on- cont r ol t ool s m' e s ccs ( sour ce code cont r ol syst em)

.I ! ! ' ! ) ' (Rochkind, 19751 rcs (revisi on control system) g' ri chy, l 9851, and cvs (concurrent

.Anyi

: vers on-i control tool w ill assist users in distinguishing am ong different versions of

:.

1 modul es of sour ce code But keepi ng t rack of object code i more di fcul tbecaus e

-1 , g

1. j some version-control tools do not attach revisi on numbers t o object versions.

( I I To cope wi th this, some organizat ions automaticall y compi le the l atest version '

t 1 : l of each module every night, thereby ensuring that al l the object code always i s up to

i

# : ' 1 dat e Al t hough t hi s t echni que works, i t can be ext r emel y wast ef ul of comput er me

) p :

l t. ( because frequently a large number of unnecessary compilations will be perform ed.

1 1 , , ' ' r e h UNIX tool mcle can sol ve this problem (Feldman, 19791. For each executabl e

-) r ' ; to each file Suppose that the stamp on a source file is Friday, June 6, at 1 l:24 AM, ,

) i l h whereas the stamp on t he corresponding object hle i s Friday.June 6, at 1 140 AM '

, ïI j - i

1

I Then it is cl ear that the source fil e has not been changed since t he object file was

'

' ' 1 ' created yb the com piler.on the other hand, if the date and tim e stamp on the source

i I i i 1 hle is l at er than that on the object t il e.then muke calls the appropri at e compiler or

IA Next, t he date and time stamp on the executable l oad image are compared to those

ect On every object l ile in t hat conhguration If the execut abl e load i mage was created I '

I I

ny lat er than all the object fil es, then there is no need to relink But if an object file has a k

the later stamp than that of the load im age then the load im age does not incorporate the

i on latest version of t hat object l il e ln this case, make calls the linker and constnl cts an 1

I

t ln other words, mcle checks whet her t he load i mage incorporates t he current 1 en

1)on version of every m odule

.lf so, then nothing further is done and no CPU tim e is wasted j

on needl ess compilations or li nkage But, if not, then mole calls the rel evant system I

ar y s of t war I n addi e t o tion, cr eat male simplifies the task e an up- t o- dat e versi on of of he building an object fi product le. There is no need j '

ng.

: m) fOr t he user to Specify each time what modul es are to be used and how they are to be

t Cofmccted, bCCaL ISC this infol - mation al ready is i n the Makef il e Therefore, a singl e

rct- com panies in 10 industries Half the companies w ere in the held of information

sys-ue, tem s, 25 percent in scientilic areas, and 25 percent in real-tim e aerospace Average

kny annual productivi ty gai ns vari ed from 9 percent (real-ti me aerospace) to 12 percent ' 1

of (i nformation syst ems) If only producti vi ty gains are considered, then these fgures do g

. i use not justify t he cost of $ 125,000 per user of introducing CASE technology. However, j

the companies surveyed fel t that the justi hcati on for CASE is not merel y increased (

it but also shorter development tim e and im provem ent in software qual- lion Productiv y

i

) to ity ln other words, the introduction of CASE environments boosted productivity, j

me al though l ess than some proponent s of CASE technol ogy have claimed Nevert he- i

ed less, there were other, equally important reasons for introducing CASE technology !

i '

b1 e i nt o a soft ware organizati on, such as fast er devel opment, fewer faul ts, bet ter usabilit y, 1

i

lin Newer results on the effectiveness of CASE technology from over 100 develop- j

l so ment projects at 15 Fort une 500 companies re:ect the importance of trai ning and the

k vs software process gGuinan, Cooprider, and Sawyer, 19971 W hen teams using CASE

mp were given training in application development in general as well as tool-specihc I j

I

kM, training, user satisfaction increased and development schedules w ere m et H owever,

kM when training w as not provided, software was delivered late and users were less

sat-vas ished Also, perform ance increased by 50 percent when team s used CA SE tools in

rce conjunction wit h a structured methodol ogy These results suppol ' t t he assert ion in I

or Section 2 1 that CASE envi ronments should not be used by groups at maturit y levels : i

'

k : i

: l

j

i i

!

;

-i tools and CASE t ool s descri bed in this chapter, together with the section in which '

1 1 ( confi gur ati on- contr ol t ool ( Sect i on 5 8) ' : I

è . wor d processor ( Sect i on 5 6)

:1 ' : Worl d W i de Web br owser ( Sect i on 5 6)

1I 1.

A vari et y of computer-aided software engineeri ng (CASE) tools are described j

in Sections 5.4 through 5.6 W hen large products are constructed, version-control, (configuration-control, and build tools are essential', these are presented in Sections j

5.7 through 5.9 Productivity gains, as a consequence of the use of CASE technology, j

II

1 1

11

l FoR FURTHKR RKAPIN/

2

For further inform ation regarding M iller's law and for his theory of how the brainoperat es on chunks t he reader should consult (Tracz, 1979, and M oran, 198 11 as wel l as M ill er's original paper ( M ill er, 19561 An analysis of M i ller's law from the

vi ewpoint of cognit ive psychology and software sci ence is t o be found in (Coult er, : 19831.

W irth's paper on stepwise refinem ent is a classic of its kind and deserves careful ;

st udy ( W i rt h l 97 11 Equally si gnificant from the viewpoint of stepwise refinement ;!

are t he books by Di jkst ra (Di jkst ra, 19761 and W irth (W irt h, l 9751 M ills applies i

ise refinem entto box- structured design, atechnique forproducing a design from i lstepw

j

a speci ficati on (M ill s, Li nger, and Hevner, 1987 , M ills, 19881 Rajli ch has ext ended i I

st epwise rel inement to large-scal e products (Rajlich, l 9851 St epwise design of real- :

ti me syst ems is described in (Kurki-suoni o, l 9931 : i There are arti cl es on CASE i n the January 1995 issue of Communications ofthe 1 i

ACM , as well as in the M arch 1995 and September 1996 issues of IEEE Software l

tchmura and Crocket t, 19951 examine the role of CASE tools in software devel- I opment Case studies of tool evaluation are presented in (Ki tchenham, Pickard, and '

. In this book, CASE tools for t he separate phases of the software process are i

h hase For information on workbenches or CASE 1

1

described in the chapters on eac p

: 1 environments, consult the For Further Readi ng sect ion of Chapt er 14 j

l ( Whi t gi f, 1991 1 is a good introduction to conhgurati on management. The impact !

i '

of the choice of software life-cycl e model on conhguration management is descl ibed !

in gBersoff and Davis, 19911 The proceedings of the International W orkshops onSoftware Configuration M anagement are a useful source of inform ation :There are many excellent books on cost -benefi t anal ysis, i ncl uding ( Gramlich, i

l

19971.For inform ation on cost-benefit analysis as applied to information system s, :

lmportant books on metrics inelude (Sheppard, 1996, and Fenton and Pieeger,

19971 A parti cularl y clearl y writt en text is (Grady, 19921 ( Jones, 1994a1 highl ights

!i

(

, : j j literature Object-oriented metrics are described i n (Henderson-sel lers, l 9961 The

l ( : i M arcl z/April 1997 issue of IEEE Sohware contains a number of papers on metrics,

ï including (Ptleeger, Jef frey.curtis, and Ki tchenham , 19971, an assessmentof sof tware '

! ! m ay be perfectly valid; for exam ple, a subscriber can change address more than once 2

! ' i in a given month Now develop a flowchart for the third rehnement that incorporates ' S*1Q A

.

) ' E deletions, n > 2,allapplied to the sam e m aster file record If not m odify your answer

( (' r ' 1 . ' ' 5 5 The l as transact i on r ecor d does not have a successor Check whet her your lowchar t

j i! -'! for Problem 5 I takes this i nto account and processes the last t ransacti on record I

! l ' 5.f ln some appl icati ons an alt ernati ve to lookahead can be achieved by careful ordering of /

l ) ( . the transactions.For example, the original problem caused by a moditication followed : I

, j whether t here is an ordering of the transacti ons that can sol ve all of the di ff iculties ' (

j j j l st ed i n Probl ems 5 2, 5 3, and 5 4.

j: ' 5.7 A new form of castroih ntestinal disease is sweeoinr the countrv of Concordia.' Like !

r histoplasmosis, it is transmitted as an airborne fungus Although the disease is almost 1

fatal, an at tack is very painful and the sufferer is unable to work for about 2 I never

5.# Does a one-person software production organization need a conhguration-control i

1Q You r he ma nage r i har ge of he of t wa r ha t cont r ol s t he na vi ga t on ys t em j

l $ for a m idget subm arine. Three different user-reported faults have to be lixed, and 1

.

ï you assign one each to Paul,Quentin, and Rachel A day l at er you l earn that, t o i

1 implementeach of the three fixes,the same four modules must be changed H owever,

i your conhguration-control tool is inoperative,so you willhave to m anage the changes

f yotlrse lf How will you do it?

5.13 ( Term Project ) W hat types of CASE tools would be appropriat e for developi ng the !

- Broadlands Area Children s Hospital. product described in Appendix A ? lI

.14 (Readings in Software Engineering) Your instructor wil l distri bute copies of gWirth, ! j

l97 l 1 List the di fferences between W irth's approach and the approach to stepwise I I

! I '

: gAppl e 1 9841 Maci nt osh Pascal User' s Gui de, Appl e Computer, lnc , Cuperti no, CA, 1 984 '

gBabi ch, 19861 W A BABI CH, Softb var e Conhgurati on Management : Coordi nati onfor Team j

Productivity, Addison-W esley, Reading, M A, 1986 j

s 1991 E H BERSOFF ANo A M DAvls ttlmpacts of Life Cycle M odels 1(Bersoff and Dav ,

C1 Software Configuration M anagement

on

g (Chmura and Crockett, 19951 A CHMURA AND H D CROCKETT, tsW hat's the Proper Role for i

e CASE Tools?''IEEE Software 12 (March 1995), pp l8-20

is (Coulter, 19831 N S COIJLTER, t'Software Science and Cognitive Psychologys' IEEE

Transactions on sk/rpkwrc Ennineering SE-9 (March 1983), pp 166-7 l

.q

i '

-1 :

( i ; ! maintenance.Nothing could be m ore dangerous from the view point of trying to achieve high-quality software.

) ' i Tes t ng i an i nt egr al component of he s of t war e pr ocess and an act i vi t y t hat must be canied out hroughout he

' : life cycle Duri ng the requirements phase, the requirements must be checked' , duri ng the specifi cation phase,

i r

-i ;

/ j j ! the specihcations must be checked' , and the software production management pl an must undergo similar

l i ' scrutiny The design phase requires careful checking at every stage During the coding phase, each module

i

: ! j exam ple, consider the speciscation phase The mem bers of the specification team m ust consciously and

l

' conscientiously check the specifications w hile they develop them.lt is not much use for the team to develop

1

i the complete speciEcation docum ent only to find, weeks or months later that an error they m ade early in

the process necessitates rew riting alm ost al1 the speciscations Therefore, what is needed is continual testing

I j , , (but see the Just in Case You Want ed to Know box on page l 37 for a somewhat different defi nition) Even

i i hough both t hese terms are defined in t he IEEE software engineeri ng glossary (IEEE 610

.12, 19901 i n this :

) .

j ! ' way, and notwithstanding the common usage of the t erm k' t : t k' to denot e testing, t he words verncation and

! 41 ' validation are used as little as possible in this book.O ne reason is that, as explained in Section 6.5, the word

' t

Barry Boehm is the author of the following dehnitions Verification: Are we building the product right?

for verification and validation (Boehm, 1984a1: Validation: Are we building the right product?

11

!

?iEssentially

, there are two types of testing: execution-based testing and nonexe- j

cution-based testing For exam ple, it is impossible to execute a written specitication I

ocument; the only al ternatives are to revi ew it as careful ly as possible or subject ;

it to som e form of analysis However, once there is executable code, it becom es jpossible to run test cases, that is, to perform execution-based testing Nevertheless, !

!

the existence of code does not preclude nonexecution-based testing, because as will l

be explained, carefully reviewing code will uncover at least as m any faults as running

r testcases ln this chapter, principles of both execution-based and nonexecution-based !

to Know box in this book led to fatal consequences Fortunately, in most cases the

k result of delivering software w ith residual faults is considerably less catastrophic

Nevertheless, the importance of testing cannot be stressed too strongly 'L

g The term quality frequently is m isunderstood when used within the software context :

àt After all, quality implies excellence of some sort, but this unfortunately is not the (

meaning intended by software engineers To put it bluntly, the state of the art in l

!

is software developm ent is such that merely getting the software to function correctly

i

z ' is enough excellence is an order of m agnitude more than what is generally possible j

is with our current software technology The quality of softw are is the extent to which ! 1

. i , I the specifications for coca cola in every way There is production line adheres rigorously to the specifications

1 ' ( ! ' lI I no attempt to produce ''excellent' coca cola or ''ux- for thatcar: in com mon software engineering parlance, E

' 1 11 ) urious' ' Cocacol a',the sole aim is to be certain thateaeh the car mustbe 'bug free'' in every way. (

i i' 'ë : ; 1 the role of t h sQA group is t e o ensure the hi gh qual ity of the software process and (

' ! ' del iver it late No matter what, the cli ent probabl y will l ose confi dence in the software

small com pared to the resulting beneht, nam ely, higher-quality software W ithout an

: SQA group, every member of the software development organization would have to : ' be involved to som e extent with quality assurance activities Suppose an organization

Ihas 100 software professionals and each devotes about 30 percent of his or her tim e

:

to quality assurance activities lnstead, the 100 individuals should be divided intotwo groups, with 70 individuals perform ing softw are development and the other 30

people responsi ble for SQA The same amount of ti me is devoted t o SQA, the only !

ddi ti onal expense being a manager to l ead the SQA group Qual ity assurance now 1

E canbe performed by an independentgroup of specialists, leading to products of higher l

2

qual it y than when SQA activities are performed throughout the organization :

ln the case of a very small software company (four empl oyees or fewer), it may 1

si mply not be economi cally vi able to have a separate SQA group The best that can be j

done under such circumst ances is to ensure that the speci ficati on document be checked j

by som eone other than the person responsible for producing those specihcations and '

sim ilarly for the design, code and so on The reason for this is explained in the

'

.

;

faul ts to creep into the document, and those same bli nd spots prevent t he faults from I

being detected on review Therefore, the review task m ust be assigned to someone ! ' 1

1other than the origi nal author of the document ln additi on, having only one revi ewer I

may not be adequate', w e all have had the experience of reading through a document , 1

many tim es while failing to detect a blatant spelling error that a second reader picks C

nd up almost im mediately This is one of the principles underlying review techniques 1

(

' a l ike walkt hroughs or i nspections In both types of revi ew, a document (such as a 1

1

an specihcation document ordesign document)is carefully checked by a team of software

fessionals with a broad range of skills The advantage of a review by a team of 1

1I

ë.ry experts is that the different skills of the participants increase the chances of finding

he a fault In addition, a team of skilled individuals working together often generates a ; !

/0

!

I

to A walkthrough team should consist of four to six individuals A specilication

walk-Iy through team should include at least one representative from the team responsible for i

; '