Software Engineering (phần 4) pps

-
I
! 1 1 .1
.
:I
l I . i
l I na < u A p T : . s . The Tools of ghe TrodeI I Eè
2 j
'
j i . .j
I Continuing the progression of CASE technology from tools to workbenches
,
the 1 a1 i
'
: ! ! next item is the CASE environment. Unlike the workbench, which supports one or ti
j '
, j . two activities, an environm ent supports the complete software process or, at the very y
;
! least
, a large portion of the software process (Fuggetta, 19931. Figure 5.8(c) depicts s2
1 ironment that supports a1l aspects of al1 phases of the life cycle
.
Environments )1 j an enVl
1 are discussed in greater detail in Chapter 14.l i p
1 1 . Having set up a CASE taxonomy (namely, tools, workbenches. and environ- ' tl
li ! '
.
l . ments), the scope of CASE now is considered. tjk
,
l .'
I 1 tê

! ' i ;ë! 1 u
i ; ! g)
' I .
.j.
' ' j
y Si
.
! ; 5.4 Stop: OF QA SK tk
ê $
j ! . , rf
'
@ ! i As mentioned previously
,
the need to have accurate and up-to-date documentation ' h
'
l k I 'l
; ! . available at al1 times is a primal'y reason for implementing CASE technology. For
,
'
' '
j' ! example, suppose that specifications are produced manually
. A mem ber of the devel- g
y . ; opment team has no way of telling whether a particular specification document is the kd
.
' - '''
'
'' J'
.
k I current version or an older version. There is no way of knowing if the handwritten ' %
'

i ! : h that document are part of the current specification or were merely a sugges
-
oj, : c anges on
; ( ' , tion later rejected. On the other hand, if the specifications of the product are produced p
i ' 5 . in a CASE tool
.
then at any time there is only one copy of the speciscations, the , tlr: , us g
. '
i
.
.
1 . online version accessed via the CASE tool. Then, if the specifications are changed
,
pl
i i members of the development team easily can access the document and be sure that
aë
! 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 document
. rri ' .
i .1 I programmers also need online documentation
. For example. online help infor- ' d,
! mation must be provided for the operating system, editor, programming language, st
i : and so on
. ln addition, programmers have to consult manuals of many kinds, such 'l
E
'
:1 as editor manuals and programming manuals. lt is highly desirable that
,
wherever at
1 ossible

,
these m anuals be available online. Apart from the convenience of having irlE P
j everything at one's fingertips, it generally is quicker to query by computer than to try a
I !l
; to find the appropriate manual and plow through it to find the needed item. In addition
,
e!l
,! I it usually is much easier to update an online m anual than to try to tind all hard-copy lx
'
:
(q
. j , ! versions of a manual within an organization and make the necessary page changes. st
'
,
: As a result, online documentation is likely to be more accurate than hard-copy ver-
'
! '
: . . '
:
sions of the same material- another reason for providing online docum entation to
1 '
.
j : . programmers. An example of such online documentation is the UNIX manual pages bl
! , . jsobell 19951
.1 ' . Fe
,
CASE also can assist with communication among team members. E-mail is
i rapidly becoming as m uch a part of an average office as a computer or a fax ma-
! ; chine
. There are m any advantages to e-m ail. From the viewpoint of software pro- '

@ I j duction, if copies of a1l e-mail relevant to a specific project are stored in a particular th' 1!
ilbox, there will be a written record of the decisions made during the project. ,' isj ma
r
' l This can be used to resolve conflicts that may arise later
.
M any CASE environments mj ( ' i
.
: : 7 j
'
! ! ; '
:
'
@ ' ,
.
'
j :
ô ! y
Please purchase Image To PDF Converter on to remove this message, thank you.
.
I
:
j
I
li
I
I i
5.* R opE oF CASE M@ j ;
.
;
he and some CASE workbenches now incorporate e-mail systems

. In other organiza- !
: : 1Or tions the e
-
mail system is implemented via a W orld W ide W eb browser such as :
:ry Netscape. Other tools that are equally essential are spreadsheets and word proces- I '
- .
i
Dts sors
.
j
3tS !
,
The term coding tools refers to CA SE tools such as text editors, debuggers, and ' :
pretty printers designed to simplify the programmer s task, reduce the frustration
'n- that many program mers experience in their w ork, and increase program m er produc-
tivity. Before discussing such tools, three detinitions are required. Programming-in-
the-small refers to software development at the level of the code of a single m od-
ule, whereas programming-in-the-large is software development at the module level
(DeRemer and lfron, 19761. The latter includes aspects such as architectural de-
-
: sign and integration. Programming-in-the-many refers to software production by aE
:
team. At times, the team will work at the module Ievel', at times, at the code level.
Thus programming-in-the-many incorporates aspects of both programming-in-the- !,
on large and programming-in-the-sm all.2 I
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 programmer
,

speeding the implementation phase because time is not
.
;
en wasted on futile compilations. Structure editors exist for a wide variety of languages,
)s- : operating systems, and hardware. Because a structure editor has knowledge of the
,
ed ' rogramm ing language
, it is easy to incorporate a pretty printer (or formatter) into rP
.
he the editor to ensure that the code always has a good visual appearance. For exam-
)d, ple, a pretty printer for C++ will ensure that each l is indented the same amount
1at as its corresponding f. An early example of a structure editor that incorporates a 2
ny fonnatter is the Macintosh Pascal editor 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 within 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 structure editor to support online interface
Ll'y . checking. That is, just as the structure editor has information regarding the name of
)n, every variable declared by the program mer, so it must also know the name of every
py method detined within the product. For example, if the program mer enters a call
such as l .CS
. I j
Cr- I .
average = dataArray.computeAverage (numberofvaluesl;t
o

res but method computeAverage has not yet been dehned, then the editor immediately '
responds with a message such as
is
Method computeAverage not known : 11a
-
-
i
:O- At this point, the programmer is given two choices, either to correct the name of l i2
lar the method or to declare a new method named computeAverage
.
If the second option I E
!
Ct. is chosen, the programmer also must specify the arguments of the new method
. Argu-
XS ment types must be supplied when declaring a new method because the major reason i
I .
I
! k
1è
.
q
1
Please purchase Image To PDF Converter on to remove this message, thank you.
ji 1
l i ' .
'
! 1 ; :; ë ':
p ! 1Q@ < x A p T z p s * The Tools of 9he Trode 5
: ' ( t
'

' 1 ! ! .l f
or having online interface checking is precisely to be able to check full interfacei I '
'
:
1 information, not just the names of methods. A common fault is for method p to callë t
'
è I j , method q passing, say, four arguments, whereas method q has been specified with '
( ; ! five arguments
. It is more difticult to detect the fault when the call correctly uses four
j '
j ; I arguments, but two of the arguments are transposed. For exam ple, the declaration of
'
j t method q might be
j i 'l
void q dloo' floatvar, in@ intvar, siring sl , siring s2) .I . jp
! lI
t :
'
l i ! whereas the call is :j
'
.
) 1 '
'
.
; ! I q (i nfva r
,
f Ioatva r, s 1 , s2) ; i
.
l
.

j i j . The first two arguments have been transposed in the call statement. Java compilers
C k and linkers detect this fault, but only when they are invoked later
.
ln contrast, an '
.
g :
( y : online interface checker immediately detects this and similar faults. ln addition
, ift
'
I' j ; the editor has a help facility, the programmer can request online information as to thei i
se arguments of method q, before attempting to code the call to q. Better yet,è 1 Prec
: I ' I the editor should generate a template for the call
,
showing the type of each argum ent.
.
j :@
:
The programmer merely has to replace each form al argum ent by an actual argument
.
( : : of the correct type.
j . '1
,
A major advantage of online interface checking is thathard-to-detectfaults caused
i ; by calling methods with the wrong number of arguments or arguments of the wrong
l l ' t e are immediately :agged
. Online interface inform ation is important for the effi-; i . yp
i ; ient production of high
-
quality software, particularly when the software is produced, c
; E by a team (programming-in-the-many). It is essential that online interface information:

1 :
,
regarding all modules be available to a1l programm ing team members at a1l tim es
.i
j
1
.
j Furthermore. if one programmer changes the interface of method vuporcheck, per-
! lj haps by changing the type of one argument from in@ to flooù or by adding an additional
rl
: argument, then every component that calls vaporcheck must automatically be dis-: '
t , t abled until the relevant call statements have been altered to reqect the new state of .1
,
! affairs.
j ' I
.
1 : Even with a syntax-directed editor incorporating an online interface checker,
j , j , the programmer still has to exit from the editor and invoke the compiler and linker.: '
,
g Clearly, there can be no compilation faults, but the compiler still has to be invoked
$ to perform code generation
. Then the linker has to be called. Again. the program-q ! '
! t ' : t mer can be sure that all external references will be satished as a consequence of
; ;
?
j the presence of the online interface checker, but the linker still is needed to link
.
! , :i
, .
the product. The solution to this is to incorporate an operating system front endj l

.
. ; within the editor. That is, a program mer should be able to give operating system
4 j ' commands from within the editor. To cause the editor to invoke the compiler
,
linker,
! ) ' l
oader, and any other system software needed to cause the module to be executed
,ë 4 . - -
'
' $ i the programmer should be able to type a single command, named GO or RUN,, . I
1 I h hoose the appropriate icon or menu selection
. ln UN IX, this! or use t e mouse to c!
E ; ,:
'
1 i , . g can be achieved by using the make command (Section 5.9) or by invoking a shell
i : ' I l script tsobell, 19951. Such front ends can be implemented in other operating systems '?
y ' J as well. .! 1 j .j '
! !1
! )
'
j . , .j
'
r '
: ' ! j ' .
.
j ' y
: !i ' l
Please purchase Image To PDF Converter on to remove this message, thank you.
l
:

! ;
s.* 5:op: oF CA5E Am I
'
; '
Face One of the most frustrating computing experiences is for a product to execute for i
Call a second or so
.
then terminate abruptly. printing a message such as '
vith
Overflow at 508Four
n Of The program mer is working in a high
-
level language such as Java or C++, not a '
low-level Ianguage like assembler or m achine code. But when debugging support
is of the Overflow ot 506 variety, the programmer is forced to examine machine
.
code core dum ps, assembler listings, linker listings, and a variety of similar low-level
.
documentation, thereby destroying the whole advantage of program ming in a high-
level language. A sim ilar situation arises when the only information provided is the
infam ous UN IX m essage
Elers
Core dumped
,
an
n, if or the equally uninformative
, the ;
Segmentation faultyet
, ,
j

ïellt' h is forced to examine low
-
level information. jHere again, t e usernent
ja jn sgure 5.9 is a great improvement iIn the event of a failure. the message s own
.
iover the earlier terse error messages
.
The program mer immediately can see that the j
lsed f ttempt to divide by 0
.
Even more useful is for the Imethod failed because o an a
'ong Iaieh tjae joperating system to enter edit mode and automatically display the line at w
effi- f il
ure was detected, namely, line 6, together with the preceding and following four or ;a
lced j
a mer then probably can see what caused the failure and make
,
1five lines
.
T e program j
k
tion th
e necessary changes. I
nes. j sefore the advent of CASE 'Another type of source-level debugging is trac ng
.
er- :P t
ools, programmers had to insert appropriate print statements into their code by
onal I f tjaeh
and that, at execution time, would indicate the line number and the va ues o
dis- b done by giving com mands to a s

ource-level de-relevant variables. This now can e
re of j i
n.bugger that automatically causes trace output to be produced. Even better s an
Iocity iteractive source
-
level debujser. Suppose that the value of variable escapeve ! j
'ker' b
e incorrect and that method computeTraiectory seems to be faulty. Us- 'seems to
lkef. 'i
ng the interactive source-level debugger, the programmer can set breakpoints in the I
Rked :
code. W hen a breakpoint is reached, execution stops and debugging mode is en- I
ram- v I i ' :tered
. The programmer now asks the debugger to trace the variable escape e oc ty
re of l
k ilink
den
OW RFLOW ERROR E
lker,
,
Closs: cyclotronEnergy
.lted, j
iUN Method: performcomputation I I
!thi
s Line ö: newvalue = (oldvalue + tempvaluel/tempvalue; : j
shell oldvalue = 3.9583 tempvalue = 0.000 ! !
tem s
;Flgure 5
.
* Output from source-level debugger. ;

:
i !
!
E
Please purchase Image To PDF Converter on to remove this message, thank you.
j
'
'
1l $
ip
'
!
.
'
( $ i
I j jj y j f jjje yrodep 12Q t H A p T : * 5 * T e oo s ot I
.
) j '
' i , and the metnod Eompute Irujedory. That is, every time the value of escopeveloc-i
'
y ) i ) ity subsequently is either used or changed, execution again halts. The programmer
l :l then has the option of entering further debugging commands
,
for exam ple, to re-
! ! ! h t the value
of a specific variable be displayed. Alternatively, the program- 'l quest t a
7 ; j j mer may choose to continue execution in debugging mode or to return to normal ';
'
! I j execution mode. The programmer similarly can interact with the debugger when-
' 1 ? ever the method computeTraiectory is entered or exited

.
such an interactive source-1 q
'
1 : ffers almost every conceivable type of assistance to th
e program-I level debugger ol
i 1 i t mer when a produet fails
. The Uxlx debugger dbx is an example of such a CASE: j '
i f ' I tool.
l ' i ? As pointed out many times, it is essential that documentation of all kinds be' y
'
I
I 1 available online
. ln the case of programmers, all documentation they might need
@ . ' should be accessible from within the editor
.
( I ;
'
,' W hat has now been described- a structure editor with online interface checking ;
i ! - ; 7
. t ' 1 Capabilities, Operating System front end, source-level debugger, and online documenta-
1 I tion
- -
constitutes an adequate and effective programming workbench. 1t ;
k 1 . j )
'
;
l . This sort of workbench is by no means new. All the preceding features were
:
: ! q supported by the FLOW software development workbench as farback as 1980 (Dooley ' dJ
.

,
j i l and schach
. 19851. Therefore, what has been put forward as a minimal but essential
1 i ' : ') programm ing workbench does not require many years of research before a prototype
:E
:
l ) ; can be tentatively produced. Quite the contraly the necessal'y technology has been 4
è h ', .
in place for over 20 years, and it is somewhat surprising that there are program mers 1
'
i i '' h
e old-fashioned way,'' instead of using a workbench like 1. r . : who still implement code t
i , j sun w orkshop. j1
I ! A ssential tool especially when softw are is developed by a team
.
is a version- 1i n e ,
s t
.
j control tool. . j1
l 1 '! 1
J j . t
l ' 1j
1 ' '@ ; ! i
' j1 II
! j j s.V soF AR: V KRsloxs
i '
j
g - ;
'
E : 'j 1 W henever a product is maintained, there will be at least two versions of the product:j

;
! . I ( the oId version and the new version. Because a product is composed of modules, there 4
)
! 1l i ;
,
will also be two or more versions of each of the component m odules that have been j
!
'
i .
T
i changed. j
( . 2 .i
, ,
version control is described first w ithin the context of the maintenance phase (@
.
.! then broadened to include earlier phases of the process
. :
j'
'
1
. k
'
'i
l ; !
! .I
j , . . a (
' 5.K1 Rxvlsloxs l
s
'
j ri :

'
t .
'
i i s a roduct has been installed at a number of different sites
. If a fault is I. . . j uppose p
' j : ' found in a module, then that module has to be hxed. After appropriate changes have j;
-
(i t
! been made, there will be two versions of the module, the old version and the new ji
.
)1 .
5
J j .,
5
! : . )
.
2 l -
Please purchase Image To PDF Converter on to remove this message, thank you.
'
:
4
j
'
2
s.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, leaving just the correct one. But that would be most unwise. Suppose that the I
ious version of the module was revision n, and that the new version is revision i L
.
m- prev j
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 may have been thoroughly tested by
ce- the software quality assurance (SQA) group, both in isolation and linked to the rest
Lm- of the product, there may be disastrous consequences when the new version of the 1
.
SE product is run by the user on actual data. Revision 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 installed revision 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 revision
ing n of the module. It therefore is necessary to retain a copy of every revision of each
ata- module. i
As described in Section l .3, perfective maintenance is perform ed to extend the 1
d les are written', in other cases, ' 1ere functionality of a product
. ln some instances, new mo u 1
'
ley existing modules are changed to incorporate this additional functionality. These new )
;
tial versions also are revisions of existing m odules. So are modules changed when per- j
i hanges made to the product in response to lfPe : forming adaptive maintenance, that s, c
,
zen changes in the environment in which the product operates. As with corrective main- j
lers tenance. aIl previous versions must be retained because issues arise not just during 'rl

.
ike the maintenance phase but from the implementation phase onward. After all, once a I
f faults 1module has been coded
,
it continually undergoes changes as a consequence o ;
On- being detected and corrected. As a result, there will be num erous versions of every ',
dule, and it is vital to have some sort of control to ensure that every member of i Imo
!
' the developm ent team knows which version is the current version of a given module. I
!Before we can present a solution to this problem
,
a further complication must be taken :
into account. ''
E
5.K2 V ARIATIONS
Jct :
Lere Consider the following exam ple. Most computers support m ore than one type of
I I
een printer. For example, a personal computer may support an ink-jet printer and a laser 1
printer. The operating system therefore must 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 situation
where variations are needed is when a product is to be ported to a variety of different ,
operating system s or hardware. A different variation of many of the modules may
' !have to be produced for each operating system-hardware combination
.
t' 1
Versions are schematically depicted in Figure 5.10, which shows both revisions .1 t
t is and variations. To com plicate matters further, in general, there will 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
i
Please purchase Image To PDF Converter on to remove this message, thank you.
j . ' .k :
l ! '
I 1 : .
l '
'
( '
1. 4a* < x A p v z * s . The Tools of 'he Trode
t ' I
.
'
.
'
j
'
l
1
*
.
'
j ! :I
I -
.

: '
1. . .
'
: I
j '
è
'
1 . '
: ! : i
I
i k i'
'
;
'
j :2
i j . .I
1 (a) .E
'
1 1 q
.
! ' (i
1 $
'
2
'
i i I .
; j : '
I : ;'
j
! j ', '' )

'
'
. j; ! .
' (
'
! 1 I '
, j i j (yj
t f ; I
@ ! l I ylgu- sao s
chematic representotion of multiple' j
. . versions of modules, showing (c) revisions and (i
: -
i' '
, ! .
(b) variations. l
( ; j J '
i
'
! .
'
: ? . F
! i : .
. '
)
t1 : Ei
) ' s.a toxylouRv lox touTpok t
.
l ) . . jj
'
j

'
I The code for every module exists in three forms. First is the source code. nowadays !
, /! i
; : generally written in a high-level language like C++ . Java, or Ada. Then there is the A
1 ë l
, object code, produced by compiling the source code. Finally, the object code for eachl
! i ' module is combined with run-time routines to produce an executable load image
. ,
r1 (
'
.
This is shown in Figure 5. 1 l . The programmer can use various different versions of t
I j ', each module.
The specific version of each module from which a given version of the ti ! )
k : j complete product is built is called the conhguration of that version of the product.
i I Suppose that a programmer is given a test repol't from the SQA group, stating that (i
jj a module failed on a specilic set of test data
.
One of the first things to do is attempt to t
l ', ! 1 recreate the failure. But how can the programmer determine which revisions of which!
,
1l iations went into the version of the prod
uct that crashed? Unless a conhguration- &1 1 ; var
' 1 1 trol tool (described in the following discussion) is used
,
the only way to pinpoint ;(1 coné l I
i
;
.
'

) :
the source of error is to look at the executable load image, in octal or hexadecim al : i
b ' ' f t and compare it to the object code, also in octal or hexadecimal
.
Specihcally, t;. ! orma ,) è
'
q : ! the various versions of the source code have to be compiled and compared to the object t#
'
- .
.
) ) code that went into the executable load image. Although this can be done, it can take ,
' )
,
a long time, particularly if the product has dozens (if not hundreds) of modules, each j y: !
.
'
' , E with multiple versions. Therefore, two problem s must be solved when dealing with '
. ;
.
.
Ii
r multiple versions. First, it is necessary to be able to distinguish between versions so k
:
I I ê
'
.
: ' 1 g that the correct version of each module is compiled and linked to the product
. Second, y
.
i S j ; : there is the inverse problem: Given an executable load image

,
determine which version . ill
i 1 i i of each of its components went into it. ë r)
! ! I1 I Th
e first item needed to solve this problem is a version-control tool. M any op- , p:
, i
1 i 1 ting systems
.
particularly for m ainframe computers, support version control. But t b: . era
1 - 1 ',
' j k j
.
1 :
.
,j ' .
Please purchase Image To PDF Converter on to remove this message, thank you.
7
I ,
'
I
.
I
l
I i>
.a CONFIGURATION CoNTRot 1Q5 '
:Run-time
I
routines
!
I

I
Executable Ioad image i
)
Object Object Object Object@**
file 1 file 2 file 3 file n
Source Source Source Source '
@ @@
filll 1 filtl :? filtl :3 filip r) .
!
Flgvre 5.1% Components of executable Ioad image.
1
many do not, in which case a separate version-control tool is needed. A common !
!
technique used in version control is for the name of each file to consist of two pieces, j
the file name itself and the revision number. Thus, a module that acknowledges receipt .1
I
of a message will have revisions acknowledgeMessage / 1 , acknowledgeMessage 1
I
àys / 2, and so on, as depicted in Figure 5. l2(a). A programmer then can specify exactly .
the which revision is needed for a given task. j
tch With regard to multiple variations (slightly changed versions that fulfill the same '
e. role in different situations), one useful notation is to have a basic file name, followedg
; of by a variation name in parentheses (Babich, 19861. Thus two printer drivers are given
the the names printerDriver (inuet) and printerDriver (Ioser). l
I
). Of course, there will be multiple revisions of each variation, such as printerDriver !
hat (loser) / 1 2, printerDriver (Iaser) / 1 3, and printerDriver (Iaser) / 1 :. This is '
:
depicted in Figure 5. l 2(b). it to
,!

ich A version-control tool is the lirst step toward being able to manage m ultiple
I .
an- versions. Once it is in place. a detailed record (or derivation) of every version of the
yint product must be kept. The derivation contains the name of each source code element, I '
! i
'
nal including the variation and revision, the versions of the various compilers and linkers . j
lly, used, the name of the person who constnlcted the product, and of course, the date and 'I;
ect the time at which it was constructed.
Ae Version control is a great help in managing multiple versions of modules and the
àch product as a whole. But more thanjust version control is needed, because of additional
pith problems associated with maintaining m ultiple variations. 1 ;
! ;
; so Consider the two variations prinferDriver (inklet) and prinferDriver (Iaser). Sup- ! j
nd, pose that a fault is found in printerDriver (inuet) and suppose that the fault occurs ' :
ion in a part of the module that is comm on to both variations. Then it is necessary to fix
not only printerDriver (inuet), but also printerDriver (Iaser). In general, if there are E
op- v variations of a module, all p of them have to be fixed. Not only that, but they have :I
But to be hxed in exactly the same way. ' i
. l
: 1. 1
Please purchase Image To PDF Converter on to remove this message, thank you.
: '
j '
'
'
i 2 .!
'
.
1 I ! :!!

.
i : I !xl < u a p y : R s . Th
e Tools of 'he Trodei ! !
1 j ' .E
'
r I :i
'
;I ! sl I E
.
'
q 1 acknowledgeMessage / 1 - - ' tl:
'
: E 1 .;
t ( !! . acknowledgeMessage / 2 - -t 1
p knowledgeMessage / 3 - - : jji ; ac
1 acknowledgeMessage / 4 -
l ir
I .
l : a
l i (a) @
l ' ( i
,
'
i 1
i
'
i
.
l 1 ! l
l 1 i :.

1 I ;
.
! , I 1;
i ' rinteroriver (inkaets - printeroriver (Iaserl/lz - - a: P
.
( j printerDriver ( Iaser) / 1 3 - -'
' i 1 l rinterDriver ( laser) / 1 4 - 0
'
: i p
è ) ; ' '' V
%
'
I ; ' '
: a
j I . .
@ l ; (b) Pl l
J : :
: i ' yI ure sa2 Multiple revisions and variations
.
(a) Four revisions of module ,) . . @ pi
'
) : knowledgeMessage. (b) Two variations of module printerDriver, with three revisions of variation ,.ac
'
t ' ' i terDriver (Ioser). ' 0
.
. . . pr n
h ! p
: ?
'
r

j ! r j,y
j
'
.1 l tion to this problem is to store just one variation
,
say printerDriver ' iF
,
! One so u
î l (inklet). Then any other variation is stored in terms of the list of changes that have bi
i c.to be made to go from the original to that variation
.
The list of differences is termedi
bj a delta
. Thus, what is stored is one variation and p - 1 deltas. Variation printer-
'
'
i D iver (Iaser) is retrieved by accessing printerDriver (inDet) and applying the delta. n! : r .
! '
, A change madejust to printerDriver (Iaser) is implemented by changing the appropri-i
! ate delta. However, any change made to printerDriver (inuet), the original variation, P
l : : automatically will apply to all the other variations
.
tl
l ' ! '.C A
eonfiguration-eontrol tool ean automatically manage multiple variations. But 11i I ) .
! l configuration control goes beyond multiple variations
.
A conhguration-control tool Al
I bi ! also can handle problems caused by development and maintenance by teams
,

as
l l ' ! ! d
escribed in the next section. br '
'
l Ii 1 1 b
i ; ' j '
l 4 . ! j 1 /(
'
h
.
1
'
1 s.a.1 toxFlououlox toxn ok puwlxo pwoput. M AlxrzxAxt: a1
l v
i i : , . j
j. , All sorts ot difficulties can arise when more than one programmer is simultaneously
9 ' i taining a product
.
For example, suppose each of two programmers is assigned a bl ma n
1 @
j , : different fault report on a Monday monzing. By coincidence, both localize the faulti
y .! I l
.
they are to fix to different parts of the same module mDual. Each programmer makes a'
j t 1 ' ( . j j 6 tj tjjey start to work C' I!
,
j copy ol the current version of the module, namely, mDua / , ani 2
.
l I . i on the faults
. The first programmer tixes the first fault, has the changes approved. and .

lj
d
:
'
.
'
) replaces the module. now called mDual / 1 Z. A day later the second programmer 9! . .
.
1 !
1 1: j IC uxes the second fault, has the changes approved, and installs module mDual / 1 8. ft
4
i' ' 1 Unfortunately
,
revision 1 Zcontains the changes of only the firstprogrammer, whereas bl
i j . j !; ;
i ij E 'b
'
:
1 . 1
.
I 1i
j .
Please purchase Image To PDF Converter on to remove this message, thank you.
I .
. .
)
'
s a CoNFlouRv loN CONTROL 1xy '
: '.
revision 1 8 contains those of only the second programmer. Thus, al1 the changes of '

the first programmer have been lost. I
Although the idea of each program mer making individual copies of a m odule : 1
.
ji
s 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 some mechanism that
allows only one user at a time to change a m odule.
l
I
s-a-a sasutlx.s I
I
The maintenance manager must set up a baseline, a conhguration (set of versions) of il
all the modules in the product. W hen trying to lind a fault, a maintenance programmer
puts copies of any needed modules into his or her private workspace. ln this private
workspace, the programmer can change anything at al1 without having an impact on
any other programmer in any way, because al1 changes are made to the programmer's
private copy; the baseline version is left untouched. i
Once it has been decided which module has to be changed to fix the fault, the ; 1
'
1
programmer/rctuc: the current version of the module that he or she is goingto alter. No '
'ion ther program mer m ay m ake changes to any frozen version
. A fter the maintenance 2o
!
programmer has made changes and they have been tested, the new version of the i
I
module is installed, thereby modifying the baseline. The previous version, now frozen,
is retained because it m ay be needed in the future, as explained previously, but itcannot
,
iver I

be altered. Once a new version has been installed, any other maintenance programm er 1
Lave
can freeze the new version and make changes to it. The resulting module, in turn, will i
ned i
become the next baseline version. A similar procedure is followed if two or more !ter-
modules have to be changed sim ultaneously.rlta
. :Tbis scheme solves the problem with module mDual. Both programmers makepri
-
rivate copies of mDual / 1 8 and use those copies to analyze the respective faults !ion, P
that they have been assigned to fix. The first programmer decides what changes to j
make, freezes mDual / 1 6, and makes the changes to it to repair the hrst fault. iBut
After the changes have been tested, the resulting revision, mDual / 1 7, becomes the !tool
baseline version. ln the meantime, the second programmer has found the second fault I
,
a.S
imenting with a private copy of mDuol / 1 6. However, changes cannot now ' 1by exper
be made to mDual / 1 8 because it was frozen by the first programmer. Once mDual
/ 1 7 becomes the baseline, it is frozen by the second programmer whose changes ,
are made to mDual / 1 7. The resulting module now is installed as mDual / 1 8, a I I4t:
ion that will incorporate the changes of both programmers. Revisions mDuol / : lvers
.
k
ly 1 8 and mDual / 1 7 are retained for possible future reference, but they can never
.ls
.
d a be altered.z
àult '
i izCS a
.
j p

k 5 @ a ZONFI/URATI/N Z/NTR/L PURIN/ PklputT D EVEL@PMENT ! '1
nda
mer W hile a module 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 module has ,
reas been com pleted. it should immediately be tested informally by its programm er, as
i!
:'
j
I l
I !
Please purchase Image To PDF Converter on to remove this message, thank you.
' 1
.
l ( j i; ,.:
1 1
:
l
'
y
j j '- j
g 1 '
l 1 : I2a < u A p T : R s @ The Tools of fhe Trodei
.
.
:. t t t
l 1 l .)
' 1 1 ! ë described in Section 6.6. During this informal testing
,
the module again passesthrough
.

I ' j :.
i I ! numerous versions. W hen the programmer is satished, it is handed over to the SQA
.
y
'
)( i
, i group for methodical testing. As soon as the module has been passed by the SQAl
roup, it is ready to be integrated into the product. From then on, it should be subjectI , g
r
1 .! : ! to the same configuration
control procedures as those of the maintenance phase. Any
l hange to an integrated module can have an impact on the product as a whole in the
! l d , c
'
i l 1 p same way as a change made during the maintenance phase. Therefore, conliguration' !
'
'
control is needed not only during maintenance but also during the implementation '
.
(
! i 1 i and integration phases. yurthermore, management cannot monitor the development '! : j
j 1 process adequately unless every module is subject to conéguration control as soon1 l
t
'
,
i 1 '
,
i as is reasonable', that is, after it has been passed by the SQA group. When con-
.
'

!
'
'
. .
'
:
I
figuration control is properly applied, management is aware of the status of every
i 1 module and can take early corrective action if project deadlines seem to be slipping
.: t 1 ë j !
ê
.
i j j ; The three major UNIX version-control tools m'e sccs (source code control system)
.
I ! '! ) (Rochkind, 19751. rcs (revision control system) g'richy, l 9851
, and cvs (concurrent! '
i l i ! i
ons system) gt-oukides and oram, 19971. PVCS is apopularcommercially avail-( l ! VCI-SI ' 1
i t . able confguration-control tool. M icrosoft Sourcesafe is a configuration-control tool
i j i j ters; ;
.
for persona compu .i E
'
! .
: ! . ! '
) 1 i -
t t ; :
?
'
i !

.
j ! : '
t : . ' . - j1
: . .
, $ ï ! s.@ Bultp Too ks!
.
.
q '
.
.
' j
1 If a software organization does not wish to purchase a complete configuration-control
j ' '!
,
tool, then at the very least, a build tool must be used in conjunction with a version-l .
1 control tool, that is, a tool that assists in selecting the correct version of each object-1 I
j code module to be linked to form a specilic version of the product. At any time,!
,
'
:( ! t ! multiple vmiations and revisions of each module will be in the product library
. Anyi
: i control tool will assist users in distinguishing among different versions ofvers on-:
.
1 modules of source code. But keeping track of object code is more difficult, because
-
1 , g
1
.
j some version-control tools do not attach revision numbers to object versions.
( I I To cope with this, some organizations automatically compile the latest version '

t 1 : l of each module every night
,
thereby ensuring that all the object code always is up toi
# : ' 1 t date. Although this technique works, it can be extremely wasteful of computer time) è p .
:
l t
.
( because frequently a large number of unnecessary compilations will be perform ed.
1 1 ' h UNIX tool mcle can solve this problem (Feldman
, 19791. For each executable, . , ; 'r e! !
t :1
.
! ! . load image, the programmer sets up a Mckefile speeifying the hierarchy of source)
l (
j r and object files that go into that particular configuration; such a hierarchy is shown in1
;
'
Fi ure 5.l l . M ore complex dependencies, such as included liles in C or C++, alsoI
. Vl
i ! ) can be handled by male. W hen invoked by a programmer, the tool works as follows.1
! ' !i
t k j UNIX, Iike virtually every other operating system, attaches a date and time stamp .k
. i -
) 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 the corresponding object hle is Friday
.
June 6, at 1 1 :40 AM. '
, ï
'
j - iI

1. I Then it is clear that the source file has not been changed since the object file was
'
' ' 1 ' ' b the compiler
. on the other hand, if the date and tim e stamp on the sourcecreated y
i I i i 1. hle is later than that on the object tile
.
then muke calls the appropriate compiler or!
: 1
; ( 5
1
, !
; '!
Please purchase Image To PDF Converter on to remove this message, thank you.
:
y
'
.
'
y
'
'
5.4* PRODUCTIVITY GAINS W ITH CASE TKHNQLOGY lQ@ .
.
E .
lgh assembler to create a version of the object file that corresponds to the current version ; '
IA Of the source lile. :
IA Next, the date and time stamp on the executable load image are compared to those
ect On every object lile in that conhguration. If the executable load image was created I '
I I
ny later than all the object files, then there is no need to relink. But if an object file has a .k

the later stamp than that of the load image. then the load im age does not incorporate the
ion latest version of that object lile. ln this case, make calls the linker and constnlcts an 1
Ii
on updated load image. ;
t ln other words, mcle checks whether the load image incorporates the current 1en
1)on version of every module
. lf so, then nothing further is done and no CPU time is wasted j
on needless compilations or linkage. But, if not, then mole calls the relevant system I:)n- !
ary software to create an up-to-date version of the product. jI
n addition, male simplifies the task of building an object file. There is no need '.ng
.
:m) fOr the user to Specify each time what modules are to be used and how they are to be
t Cofmccted, bCCaLISC this infol-mation already is in the Makefile. Therefore, a singleCn
)0 Command iS al1 that is needed to build a product with hundreds of modules and Càil
-
1D0 I
ool ensure that the complete product is put together correctly.
2
l
5.1* pRoputTlvla G AINS !
w lTu tA SK TztuNokooy 1.
!
Trol Reifer (as reported in ëMyers, 19921) conducted an investigation into productivity '
an- gains as a consequence of introducing CASE technology. He collected data from 45 I
rct- com panies in 10 industries. Half the companies w ere in the held of information sys-
ue, tems, 25 percent in scientilic areas, and 25 percent in real-time aerospace. Average
kny annual productivity gains varied from 9 percent (real-time aerospace) to 12 percent 'i 1
of (information systems). If only productivity gains are considered, then these fgures do g
.
iuse not justify the cost of $ 125

,
000 per user of introducing CASE technology. However, j
the companies surveyed felt that the justihcation for CASE is not merely increased (
it but also shorter development time and improvem ent in software qual- lion Productiv y
i
) to ity. ln other words, the introduction of CASE environments boosted productivity, j
me although less than some proponents of CASE technology have claimed. Neverthe- ii
ed. less, there were other, equally important reasons for introducing CASE technology !
i '
b1e into a software organization, such as faster development, fewer faults, better usability, . 1
rce easier maintenance, and improved morale. 1
i
l in Newer results on the effectiveness of CASE technology from over 100 develop- j
lso ment projects at 15 Fortune 500 companies re:ect the importance of training and the
kvs. 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 were met. H owever,
kM. when training was not provided, software was delivered late and users were less sat-
vas ished. Also, performance increased by 50 percent when team s used CASE tools in
rce conjunction with a structured methodology. These results suppol't the assertion in I
or Section 2. l 1 that CASE environments should not be used by groups at maturity levels : i
'
k
.
: i
: l
Please purchase Image To PDF Converter on to remove this message, thank you.
: jk - l '
ii

k ! E
'
) j '
I ! j !ao e u A p T : p s . The Tools of 'he Trade
: ' g 1 i h
. I î .
1 ' i l or 2
.
To put it bluntly, a fool with a tool is still a fool gGuinan, Cooprider, and1 I l .
'
t 'h : Sawyer, 1997) .1
.
i ! The final hgure in this chaptec Figure 5
.
13, is an alphabetical list of the theoretical j! ; -
i tools and CASE tools described in this chapter, together with the section in which '
l i! 1 each is described
.
!
- r i i .
! I
.
r
'
1 . .
l t
I i
i . ( yheo
revuol Iools1l k
-

-
1 :
'
I
l '. ' Cost-benefit analysis (Section 5.2)I t
I Metrics (Section 5.3) .
'
i I , i )
) ' Stepwise refinement (Section 5. 1) .
j ; ' .
.
j . ' ; ''
! CASE Toxonomy '' l !
.
i t : .
i ' 5 t1
j Environment (section 5.5) .
.
ï LowercAsE tool (Section 5.5) .' j
: j k
.
'
UppercAsE tool tsection 5.5)
:
1
, k ' . . workbench (section 5.5)
.
1
; z .
; tasz yools

( . . :
'
.
C ' ' Bukjd tool (Section 5.9) yq I
.
ë '' ! ë Coding tool (section 5.6) )
1 1 ( c
onfiguration-control tool (Section 5.8) '.: I
! l consistency checker (section 5
,
5) '
.
.
1
i
'
l ) .,1
j . Data dictionary (Section 5.5) :!
,
'
1 : E-mail (Section 5.6)1 l
ti '
nterfoce checker (section 5.6) .
! 12
: online documentation (section 5.6)
r
'
I
j : Operating system front end (Section 5,6)
'

,
I
.
I Pretty printer (Section 5.6)! '
'
1
; j ) zeport generator (Section 5.5)
: 1) l . ' Screen generator (Section 5.5)
: .
. .
'
! source-level debugger (section 5.6);
5 .
! . ' spreodsheet (section 5
.
6)j
r
'
r
l
è . ( '
.
structure editor (section 5.8);
'
'
I ;. version-control tool (Section 5.7)1
.
è
.
.

word processor (Section 5.6)
:
1 ' : World Wide Web browser (Section 5.6)
'
'
1
*
i
'
1
*
.
! '
'
'
'
7 j Flgure 5aa Summary of the
-
J j j
,; , I theoretical tools and sohware (CASE) -i l
) ' tools presented in this chapter and the ); : ! ë
î l ' l t sections in which each is described.I 1 )
.
) ' ' ''
.
i ' :
! I . : .
t ') ;
. I '
.

: I ' -
Please purchase Image To PDF Converter on to remove this message, thank you.
.
, :
.
!
'
EE ; 1
i
lFoR FURTHER READINO lal ;
1I 1
.
!1
QHAH ER RevlKw '
First, a number of theoretical tools are presented. Stepwise refinement, based on
' law is described and illustrated in Section 5. 1 . Another analytical tool, ! :Miller s
, !
cost-beneit analysis, is presented in Section 5.2. Software metrics are introduced in
Section 5.3. 1
.
A variety of computer-aided software engineering (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
are described in Section 5. 10. '
I
I
1
1
1

1
lFoR FURTHKR RKAPIN/
2
For further information regarding M iller's law and for his theory of how the brain
operates on chunks. the reader should consult (Tracz, 1979, and Moran, 198 11. as .
well as M iller's original paper (Miller, 19561. An analysis of M iller's law from the
viewpoint of cognitive psychology and software science is to be found in (Coulter, :
19831.
W irth's paper on stepwise refinement is a classic of its kind and deserves careful ;
study (W irth. l 97 11. Equally significant from the viewpoint of stepwise refinement ;!
are the books by Dijkstra (Dijkstra, 19761 and Wirth (Wirth, l 9751. Mills applies i
ise refinementto box- structured design, atechnique forproducing a design from i lstepw
j
a specification (Mills, Linger, and Hevner, 1987., Mills, 19881. Rajlich has extended i I
stepwise relinement to large-scale products (Rajlich, l 9851. Stepwise design of real- :I
time systems is described in (Kurki-suonio, l 9931. : i
There are articles on CASE in the January 1995 issue of Communications ofthe 1 i
ACM, as well as in the March 1995 and September 1996 issues of IEEE Software. l!
tchmura and Crockett, 19951 examine the role of CASE tools in software devel- I
opment. Case studies of tool evaluation are presented in (Kitchenham, Pickard, and '!
Pfleeger, 19951. j
.
In this book, CASE tools for the 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
: 1environments, consult the For Further Reading section of Chapter 14. j
l(Whitgift
, 1991 1 is a good introduction to conhguration management. The impact !
i 'of the choice of software life-cycle model on conhguration management is desclibed !

in gBersoff and Davis, 19911. The proceedings of the International W orkshops on
Software Configuration M anagement are a useful source of information. :
There are many excellent books on cost-benefit analysis, including (Gramlich, i
l19971
. For information on cost-benefit analysis as applied to information systems, :
consult tKing and Schrems, 19781. :
lmportant books on metrics inelude (Sheppard, 1996, and Fenton and Pieeger,
19971. A particularly clearly written text is (Grady, 19921. (Jones, 1994a1 highlights
!i
.
)
(
Please purchase Image To PDF Converter on to remove this message, thank you.
. . ! .
i i E
'
: ! 1 . ! .
)
'
! .
'
(
'
!
t l l i Ia2 t H A p T : R s * The Tools of 'he Trode
l '; I ' 5 j:
'
2 1 1 '
,
'

j 1 I unworkable and invalid metrics that nevertheless continue to be mentioned in the 5.V
1 t j
, : . j j literature. Object-oriented metrics are described in (Henderson-sellers, l 9961. The
l . ( : i Marclz/April 1997 issue of IEEE Sohware contains a number of papers on metrics,
ï including (Ptleeger, Jeffrey.curtis, and Kitchenham, 19971, an assessmentof software 'i
1 i j t Metrics for small projects are discussed in the March/April 1999 issuej : p measuremen
.
l f IEEE Sojtware. '. o
'
j
'
' i I 1 A number of articles on metrics appear in the September 1994 issue of IEEE
'
i j I
; l : ! i Computer and the March/April 1 997 issue of IEEE Software. .'
.
I , y t
! . I ;
'
.
j j , 'E
.
I !
,
j ! : 5.gl :
,
' ' j
'
j I :1
,

2 PROBLKM S! 1 5
.9p
i ' ' 'i
k l j r : 1
J 'j ; ' I 5.1 Consider the effect of introducing Iookahead to the design of the corrected third , jo '
j . 1 .' *j ( refinement of the sequential master hle update problem. That is, before processing a .l
.
.
.
' 1 ; transaction the next transaction m ust be read. If both transactions apply to the same ,
J ( E . . .
,
j i ! , master lile record, then the decision regarding the processing ol the current transaction j'
T ! i11 depend on the type of the next transaction
. Draw up a 3 x 3 table with the rows ,. l w
i
j J ' .labeled by the type of the current transaction and the columns labeled by the type of
,
1 :
'
! ;
! : . . the next transaction and fill in the action to be taken in each instance. Forexamples two ':
.1 1 :i l
successive insertions of the same record clearly are an error. But two modilications '1 1 t
4
! ! . 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
1 lookahead

.
4
.
1
1 5.13 ('
; 5.2 Check whether your answer to Problem 5.1 can correctly handle a modification trans- j
j j ! action followed by a deletion transaction, both transactions being applied to the same r j. j
' file record. lf nota modify your answer. S*l !
. m aster
j p '
2
: 5.3 Check whether your answer to Problem 5. l also can handle correctly an insertion j
r t t t followed by a modihcation followed by a deletion, all applied to the same master fileI
1 7 I i record. If not, modify your answer.I
! l 5.4 Check whether your answer can also correctly handle n insertions
.
modihcations, or) l
'
.
) ' E deletions, n > 2, all applied to the sam e master file record. If not. m odify your answer.
q ai
.
i
,
,
,
1 I
( ( ' ' ' 5.5 The last transaction record does not have a successor. Check whether your llowchart
'
r 1 . '

j ' for Problem 5. I takes this into account and processes the last transaction record Ii
-
!!
tl If not modify your answer. '. (! ) ; : .
.
correc y. ,
) ' i
'
.
'
! l ' 5.f ln some applications an alternative to lookahead can be achieved by careful ordering of /
l .) ( . : I
.
the transactions. For example, the original problem caused by a moditication followedi '
T
t
i b a deletion of the same master lile record could have been solved by processing!
j j y
J t i 1 ! a deletion before a modification. This would have resulted in the master file being (
p 1 l ,
, 1 : j ( written correctly and an error message appearing in the exception report. Investigate
l ) 1 1 !
: , j whether there is an ordering of the transactions that can solve all of the difficulties ' (
j lJ1 j j listed in Problems 5.2, 5.3, and 5.4.
$
'
-
.
!
i :

'.
.
'
'
'
:
'
j
'
i
'
l ' :S
t 1 (
$ .
.
i j 2 ! '
'
; ! l . '
Please purchase Image To PDF Converter on to remove this message, thank you.
I
' (
i I
1
l
REFERENtES 1aa i!
(
'
'
j
: 5.7 A new form of castrointestinal disease is sweeoinr the countrv of Concordia. Like !

' h'''''
d
'
'' *.''' *'' I
r histoplasmosis, it is transmitted as an airborne fungus. Although the disease is almost 1
fatal, an attack is very painful and the sufferer is unable to work for about 2 Inever
$ j
: weeks. The government of Concordia wishes to determine how much money, if any, 'j
, to spend on attempting to eradicate the disease. The committee charged with advising j
the Department of Public Health is considering four aspects of the problem : health '
: care costs (Concordia provides free health care to all its citizens), loss of earnings j
d hence loss of taxes), pain and discomfort, and gratitude toward the government. 1(an j
Explain how cost-benetit analysis can assist the committee. For each benetit or cost, 1
1suggest how a dollar estimate for that benefit or cost could be obtained
.
j
d a version-control tool, and i5
.
8 Does a one-person software production organization nee 1
.
-
if so, why? j
5.# Does a one-person software production organization need a conhguration-control i1
tool, and if so, why? I
1 5
.
1Q You are the manager in charge of the software that controls the navigation system jl
$ for a m idget submarine. Three different user-reported faults have to be lixed, and 1
.
ï you assign one each to Paul

,
Quentin, and Rachel. A day later you learn that, to i
1 implement each of the three fixes
,
the same four modules must be changed. H owever,
i your conhguration-control tool is inoperative, so you will have to manage the changes
f lf How will you do it?yotlrse
.
)
'
) 5
.
1 1 Section 2. 1 1 stated that it makes little sense to introduce CA SE environments within
5 .
organizations at maturity levels 1 or 2. Explain why this is so.
z .
5.1Q What is the effect of introducing CASE tools (as opposed to environments) within ,j; '
izations with Iow maturity level? iorgan
.
1
5.13 (Term Project) What types of CASE tools would be appropriate for developing the !
- .)
lBroadlands Area Children s Hospital product described in Appendix A ? I
z 5
.
14 (Readings in Software Engineering) Your instructor will distribute copies of gWirth, j!
l97 l 1. List the differences between W irth's approach and the approach to stepwise I I
rl finement presented in this chapter. ! ire
!
I 'C

. )
r : i ù
'' R'FERENZ'S C
.
1
4 II
:1 gApple. 1 9841 Macintosh Pascal User's Guide, Apple Computer, lnc., Cupertino, CA, 1 984. ' 1:
gBabich, 19861 W. A. BABICH, Softbvare Conhguration Management: Coordinationfor Team j li
Productivity, Addison-Wesley, Reading, MA, 1986. j .
'
f i
s 1991 1 E. H. BERSOFF ANo A. M. DAvls. ttlmpacts of Life Cycle Models 1(Bersoff and Dav ,
C1 Software Configuration M anagement
,'' Communications of the ACM 34 .on
g . (August l 99 I ), pp. l 04-18. . .
g (Chmura and Crockett, 19951 A. CHMURA AND H. D. CROCKETT, tsWhat's the Proper Role for i
e CASE Tools?'' IEEE Software 12 (March 1 995), pp. l 8-20.
is (Coulter, 19831 N. S. COIJLTER, t'Software Science and Cognitive Psychologys'' IEEE
Transactions on sk/rpkwrc Ennineering SE-9 (March 1983), pp. 1 66-7 l .
.
q
i
.
'
- 1 :
'
Please purchase Image To PDF Converter on to remove this message, thank you.
. ! !
l l ; ' ::
'

! 1'
i E : '
.
!
'
! i '1 ' .i
'
! E1 i
1 ,l
l !! !
ii r l
. , k( y ' )
'
-
i t . ! g e n - > *- <
i I
l E I 1
! . i
i
.
I j
; 1 :
.
j :
1
. :
!
'
; '
p ! KSTI1

,
!l
1 ' ' l
' i ! 1 j -5
!
j'
: 1 jt '
j .
1 -l .
,
i l I .
' i
.
I !i
'
1 l I 'i
l I i1
i qi
,
'
! I -
ï
'
.
;
;
'
i!
.
8 ' l :oftware life-cycle models all too frequently include a separate testing phase

,
after integration and befored ! . :
: :
'
.
(j i ; ! maintenance. Nothing could be more dangerous from the viewpoint of trying to achieve high-quality software.
) jj i Testing is an integral component of the software process and an activity that must be canied out throughout the'
' : life cycle
. During the requirements phase, the requirements must be checked', during the specification phase,i . j r
-i . ;
/ j . the specihcations must be checked', and the software production management plan must undergo similar.
j
!
l i ' scrutiny. The design phase requires careful checking at every stage. During the coding phase, each module
! l ë k
j i certainly must be tested, and the product as a whole needs testing at the integration phase. After passing the
'
i ; l tance test
,
the product is installed and the maintenance phase begins. And hand in hand with maintenance, ! j , accep
j ' ';
.
goes repeated checking of modihed versions of the product.'
, t
i . In other words, it is not sufficient to test the product of a phase merely at the end of that phase. Forl
i .
: ! j example, consider the speciscation phase. The members of the specification team must consciously and
l ' conscientiously check the specifications while they develop them
. lt is not much use for the team to develop1
i the complete speciEcation document only to find, weeks or months later. that an error they made early in

the process necessitates rew riting almost al1 the speciscations. Therefore, what is needed is continual testing
i ;' i carried out by the development team while it pedbrms each phase, in addition to more methodical testing at
: l h d of each phase
. .
i 2 i t e en
ë The terms ver/cation and validation were introduced in Chapter 2. Ver/cation refers to the process 'i
.
.
ë :i i '
' f determining whether a phase has been correctly carried out; this takes place at the end of each phase.L !
.
l oi
l .1 ! ' 7 On the other hand, validation is the intensive evaluation process that takes place just before the product isI
.
; : '
'
@ rj 1 , delivered to the client. Its purpose is to determine whether the product as a whole satishes its specihcations!
,
I j , . , (but see the Just in Case You Wanted to Know box on page l 37 for a somewhat different definition). Even
i i . hough both these terms are defined in the IEEE software engineering glossary (IEEE 610
.
12, 19901 in this :
21 é ' . t g) . .
j ! ' way, and notwithstanding the common usage of the term k' t:t k' to denote testing, the words verncation and
! 41 ' validation are used as little as possible in this book
.
One reason is that, as explained in Section 6.5, the word
.
i l ' i .
i ! j I I ver#cation has another meaning within the context of testing. A second reason is that the phrase vermcationi 6

I d validation (or k' t:t U) implies that the process of checking a phase can wait until the end of that phase.r l
, &Nl
1 j ; i ! On the contrary
,
it is essential that this checking be canied out in parallel with al1 software development andI
j I j .
l I : j maintenance activities. Therefore, to avoid the undesirable implications of the phrase k' t:t k; the term testingI h . I
l 1 ! is used.I
' ! : , .
i E ;
! '. ' j ji y )36
! 1. - !
j . '
: i :
Please purchase Image To PDF Converter on to remove this message, thank you.
' t
'
l
I
I
I
la QUAKITY IssuEs la7 :
t
Jus: IN G sz You W ANTKP To KNow i
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?
1
1
!
?

'
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
' jd
ocument; the only alternatives are to review it as carefully as possible or subject ;
it to some form of analysis. However, once there is executable code, it becomes j
possible to run test cases, that is, to perform execution-based testing. Nevertheless, !
!th
e existence of code does not preclude nonexecution-based testing, because as will l
be explained, carefully reviewing code will uncover at least as many faults as running
r test cases. ln this chapter, principles of both execution-based and nonexecution-based !
.
testing are described. These principles are applied in Chapters 10 through 16, where '5
.
a description is given of each phase of the process model and the specific testingLe
practices applicable to it. The faults described in the lirst Just in Case You W anted 'D
,
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. 'Lkl
!
l() rl
l
lr 11
d' ;
'p l.I Q UALITT IssuKs I 1
n .1 i
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 development is such that merely getting the software to function correctly
i
z. ' is enough excellence is an order of magnitude more than what is generally possible j
is with our current software technology. The quality of software is the extent to which ! 1
I
ls the product satishes its specifications (see Just in Case You W anted to Know box on : 1
'
!n page 138). .
2 Ii
is The task of every software professional is to ensure high-quality software at a1l 1.
I
d times. Notwithstanding this, the software quality assurance (SQA) group has addi- ' '
'
d tional responsibilities with regard to software quality.
n
) . I .
d êaa Soyvwu : Q uAua Assua-xt:
g :
One aspect of the iob of the SQA group is to ensure that the product is correct. More
precisely, once the developers have completed a phase, members of the SQA group
!
I
Please purchase Image To PDF Converter on to remove this message, thank you.
.
y
'
! '
i ) I ' E '

' '
)
'
1 1 ' E
'
'
' '
j!
.
1'
;
2 ! Aa@ < H A p T E R l * Tesding
! I ) il j
! E
'
I ji
( ;
! 1
'
! 1 JusT IN G sz You W ANTEP To Kxow 1i !
1
1 I i li ' I j
' ! I !
.1@ ;
' p The use of the term quality to denote ''adheres to spec-
bottle or can of coca cola stringently adheres to the 'j -
l . ifications'' (as opposed to Gtexcellent'' or Stluxurious'') company's formula (specifications) for that carbonated l
( @ ! ' t tI
I I ) j is the practice in tields such as engineering and manu- beverage.;
1 1 ! 1 facturing

. Consider, for example, the Quality Control The word quality is used identically in the automo- ' li
r ! ' r
; y I Manager at a Coca Cola bottling plant. The job of that bile industry. Quality ls Job One is a former slogan of 1( .
' 1 ' . Quality Control Manager is to ensure that every single the Ford Motor Company. In other words, the aim of (
.
.
l!
.
j y bottle or can that Ieaves the production line satislies Ford is to ensure that every car that comes off a Ford (1 i
.
.
i , I the specifications for coca cola in every way. There is production line adheres rigorously to the specifications
1 ' ( ! ' l no attempt to produce ''excellent'' coca cola or ''Iux
-
for that car: in common software engineering parlance, E.
I I
'
1 1 ious'' Cocacola'
,
the sole aim is to be certain that eaeh the car must be ''bug free'' in every way. (1 ) ur) !
.! ; J !
.
ji j !
.
.
;! i ;I
! . E2 j : j .
I . t ' 1 , 1
'
iI 11 '

'
j
'
1
*
.
'
1 l i ' 1 have to check that that phase has been canied out correctly
. Also, when the product is1 i
; : ;
( I , . i j complete, the SQA group has to check that the product as a whole is correct. However,' :
l ' ftware quality assuranee goes further than just testing (or V & V) at the end of a ': ) SO; I
- : I .
i ( 1 phase or at the end of the development process', SQA applies to the software process -)
- ! : :
l i t itself. For example, the responsibilities of the SQA group include the development of 4j
.
ll
' he various standards to which the software must conform as well as the establishment
.
p l . tl Ii I
of the monitoring procedures for assuring compliance with those standards. ln brief,2 ' j
l i i ' ; h sQA group is to ensure the high quality of the software process and (. 1 the role of t e
'
ë :
1 thereby ensure the high quality of the product. f
t t lj
'
:I (
l

T 1 *.1.2 M ANA- RIAK Ixpzpzxpzxt:
,
l
I I , ;
t $ t t j . 1q! It is important to have managerial indep
endence between the development team and ' t
j
'
'
.
2 I ; the SQA group. That is, development should be under one manager, SQA under a . l!
! I I differentmanager, and neithermanagershould be able tooverruletheother
.
The reason El l t ; l
.
I p r is that, al1 too frequently, serious faults are tound in a product as the delivery deadline I
'
l jI
; j approaches. The software organization must now choose betw een two unsatisfactory k
i 1 ! 1 options
.
Either the product can be released on time but full of faults, leaving the zj j ' 1
.) t t : j client to struggle with laulty software, or the developers can hx the software but E' l E
' ! ' deliver it late. No matter what, the client probably will lose confidence in the software) . # 2 . ! j j
i ' ' ! i ization
.
The decision to deliver faulty software on time should not be made by vt ;( . . organiI
I t ' j the manager responsible for development
s
nor should the SQA manager be able to i1 t

E : : j . .l I
,
make the decision to pertorm turther testing and deliver the product late. lnstead, both
i ! . ' 1 rI
managers should report to a more senior manager who can decide which of the two) p
'
!' i I I ''
choices would be in the best interest of both the software development organization 4i 1 (
l ' ' and the client
.
I
- lp ji
1 At hrst sight, having a separate SQA group would appear to add considerably to $l 1 1
1 2 i f ftware development
. But this is not so. The additional cost is relatively t: the cost o soE
.
t
'
; '! 5! l
; i ;'
,
,
I .
f l ! .
.
'
(
'
; .
i ij .

Please purchase Image To PDF Converter on to remove this message, thank you.
i
i
i
l.a N oNexztunox-BAsep TssnNo 1a* I
'
small compared 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 time
:
to quality assurance activities. lnstead, the 100 individuals should be divided into
two groups, with 70 individuals performing softw are development and the other 30
people responsible for SQA. The same amount of time is devoted to SQA, the only !
dditional expense being a manager to lead the SQA group. Quality assurance now 1a i
E canbe performed by an independent group of specialists
, leading to products of higher l
2
quality than when SQA activities are performed throughout the organization. :
ln the case of a very small software company (four employees or fewer), it may 1i
simply not be economically viable to have a separate SQA group. The best that can be j
done under such circumstances is to ensure that the specification 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
next section. i
'
.
; .
)is ,

Cr: '
r a ! '
CS S
ê.Q N /NKXKtUTI@N-BA:EP TE/TIN/of
' :
:nt
f lt is not a good idea for the person responsible for draw ing up a document to be the ,C
,
d only one responsible for reviewing it. A lm ost everyone has blind spots that allow !n
faults to creep into the document, and those same blind spots prevent the faults from . I
being detected on review. Therefore, the review task must be assigned to someone ! ' 1
1
other than the original author of the document. ln addition, having only one reviewer Ii
may not be adequate', w e all have had the experience of reading through a document
,
1
many times while failing to detect a blatant spelling error that a second reader picks C
nd up almost immediately. This is one of the principles underlying review techniques 1
(
' a like walkthroughs or inspections. In both types of review, a document (such as a 1
1an 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 1ne pro
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 ; !
istic effect. I 1
1put synerg ;
jre Walkthroughs and inspections are two types of reviews. The fundamental differ- I
q
'

ny ence between them is that walkthroughs have fewer steps and are less formal than !
to inspections. ! i
:
.
th
/0
!Jn l
.Qa W AtxvuRouous r
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
; '
Please purchase Image To PDF Converter on to remove this message, thank you.
' I i ' 'l
: q k i 1. .'
'
!
'
1 i tl
'
1 ji
'
i 1 l! 1 ' p ! wo
e u A p v : . . . Tesfing) : 1 ;
-
1 .t ! !
, , .
I .1 i !
drawing up the specifications, the manager responsible fbr the specifications, a client :' )
'

1 -1
,
i i j representative, a representative of the team that will pertorm the next phase of the
! g
'
l ' '! E ) development (in this instance the design team)
,
and a representative of the softwarel - 1 j E ' :
.
i I j quality assurance group. For reasons that will be explained in the next section, the
i 2 ; SQA group member should chair the walkthrough
.$ 1l
I l The members of the walkthrough team
,
as far as possible, should be experienced )' I
; ji I ( senior technical staff members because they tend to lind the important faults
. That is, .
.
l : l ; :.
! j j they detect the faults that would have a major negative impact on the project (New,1
'
l 2 1 j 19921. .! I !
j 7 : ' .
. .
1 j The material for the walkthrough must be distributed to the participants well in
l 1 - !'j
j q I advance to allow for careful preparation. Each review er should study the material and!
'
l ' -i 1 develop two lists: a list of items the reviewer does not understand and a list of items
; ) : : (

1 'j 1 the reviewer believes are incorrect.
! ! Ii I j 1 i
! . j I ' .
.
' l '1 ' .1 M
axaolxo w akxvupouous 'i o a
-
ai ! : ' ! .
1 '1 ! ' !
; ) i ' The walkthrough should be chaired by the SQA representative because the SQA rep-
!( E @ ' l (l 1 :
, resentative has the m ost to Iose if the walkthrough is pedbrmed poorly and faults! .I
( .l :! l tIy slip through
. In contrast, the representative responsible for the specin consequen! i @ :
,t l ' I i
.
2 cation phase may be eager to have the specihcation document approved as cluicklv as
) j ï . l ' *' .j ' possible to start some other task
.
The client representative may decide that any de-l j
.
:
: ' : l fects not detected at the review probably will show up during acceptance testing andI l ;'
i E ; l h fo
re be fixed at no cost to the clientorganization. But the sQA representative hast . t ere! i
'
! I
. 1 ë : the m ost at stake: The quality of the product is a direct reqection of the professional

! ,

: 1 j competence of the SQA group.
.
1
.
I t ; The person leading the walkthrough guides the other members of the walkthrough
E !l team through the document to uncoverany faults
. It is not the task of the team to correct1
'
faults, merely to record them for later correction. There are four reasons for this:l
: .l !
1 1 j l . A eorrection produced by a committee (that is, the walkthrough team) withinl
;
1 j I! : i
j the time constraints of the walkthrough is likely to be inferior in quality to al
:
1 (
! j l correction produced by an individual trained in the necessary techniques.
I -' ' l I
l : k @ 1 '! 2. A eorrection produced by a walkthrough team of five individuals will take at leastp
:
)
'
1
j q 1 j k as much time as a correction produced by one person and, therefore, costs five1 ! : ' ' ' l ti
mes as much when the salaries of the five participants are considered i i j
: j ! : .) .t : j 3. Not al1 items tlagged as faults actually are incorrect. In aecordance with the .
d ! : ! ! i dictum çklf it ain't broke
, don't fix it,'' it is better for faults to be analyzed carefullyj q :
.
,I I

. ;
j ! j and then corrected only if there really is a problem, rather than have a team attempt
I :; : : to tttix'' something that is completely correct
.
'
i l ; r
I ,: h j 4. There simply is not enough time in a walkthrough to both detect and correct ,
t ( i l '1 faults
. No walkthrough should last longer than 2 hours. The time should be spentI
.
j j .I
.
' detecting and recording faults, not con-ecting them.j .
,
I
r - . : q
E , ; ; There are two ways of conducting a walkthrough. The first is participant driven.' 1
i 2 j ! I Participants present their lists of unclear items and items they think are incorrect. The
t
.
1
1 '. .
'
r
'
t
'
; j
i Ij
.

I i : jI
.
; -
Please purchase Image To PDF Converter on to remove this message, thank you.
I
'
.
j
.
1
.
i
'
1
x e NoNExKm loN-BAsep nsTlNo 1*1 !
I
. l
nt , representative of the specifications team must respond to each quely clarifying what l
'
is unclear to the reviewer and either agreeing that indeed there is a fault or explaining 1le
hy the reviewer is mistaken. 1re w
i
le . The second way of conducting a review is document driven. A person responsible
'
for the document, either individually or as part of a team , walks the participants
ld through that document, with the reviewers interrupting either with their prepared 1
'
i ered by the presentation. This second approach is likely i
jq comm ents or comments tr gg
w, to be more thorough. ln addition, it generally leads to the detection of more faults l

!b
ecause the majority of faults at a document-driven walkthrough are spontaneously j
Iin
:
detected by the presenter. Time after time, the presenter will pause in the middle of a ;
ld sentence, his or her face will light up, and a fault, one that has lain dormant through ;
ns many readings of the document, suddenly will becom e obvious. A fruitful field for I
research by a psychologist would be to determine why verbalization so often leads to :
faultdetection during walkthroughs of all kinds, including specification walkthroughs, i
ld
esign walkthroughs, plan walkthroughs, and code walkthroughs. Not surprisingly, i
lthe more thorough document
-
dliven review is the technique prescribed in the IEEE ;
Standard for Software Reviews and Audits IIEEE 1028, 19971. '!
The prim ary role of the walkthrough leader is to elicit questions and facilitate 'p
-
lts discussion. A walkthrough is an interactive process', it is not supposed to be one-sided
ji- instruction by the presenter. lt also is essential that the walkthrough not be used as
a means of evaluating the participants. lf that happens, the walkthrough degenerates .as
into a point-scoring session and does not detect faults, no m atter how well the sessione
-
d leadertries to run it. The manager who is responsible for the document being reviewedR
.
should be a mem ber of the walkthrough team , it has been suggested. If this manager .as 1
j also is responsible for the annual evaluations of the members of the walkthrough team ; jïlt
I
he fault detection capabilities of the team will i 1(and particularly of the presenter)
, t j
be compromised. because the primary motive of the presenter will be to minimize ' (

rh :
' the number of faults that show up. To prevent this conoict of interests, the person l
)ct :
responsible for a given phase should not also be directly responsible for evaluating i
any member of the walkthrouxh team for that phase. I
.
'- ''''''''' ''* 1li 11
:
'a E
.i
I
*.Q.a IxspztTloxs i
lst I
1ve Inspections were first proposed by Fagan for testing designs and code gFagan
, 19761. $
An inspection goes far beyond a walkthrough and has five formal steps. First, an : l
' jhe t/pprpfé'w of the document to be inspected (specilication, design, code, or plan) is I
;)
.
1jy given by one of the individuals responsible for producing that document. At the end 1
/
'
:
t of the overview session, the document is distributed to the participants. In the second (IP
step, preparation, the participants try to understand the document in detail. Lists of
fault types found in recent inspections, with the fault types ranked by frequency, are ;
zct ( !
excellent aids. These lists help team members concentrate on the areas where the . :
lnt '
most faults have occurred. The third step is the inspection. To begin, one pm icipant

walks through the document w ith the inspection team, ensuring that every item is
zn. covered and that every branch is taken at least once. Then fault finding com mences. ;
'he As with walkthroughs, the purpose is to lind and document the faults, not to correct
' I
l
Please purchase Image To PDF Converter on to remove this message, thank you.
1 1 1 'l i 1 !
2 l I lI k
i ! .j 1l 1
, I j .i ;
i i j I t w a t u A p v : . l . Tes#ing
.
l i : i
,
t
.
1 t ô - $ .t
j! t . 1 : j them. Within one day the leader of the inspection team (the moderator) must produce . 4
'
!
'
' $l k ' ! a written report of the inspection to ensure meticulous follow-through. The fourth
j E ; i !
1 i 1 ' ' ij stage is the rework, in which the individual responsible for that document resolves al1
' ' 1 ' .1 faults and problems noted in the written report. The final stage is ttwfollow-up. The
C ; i, )
) ; moderator must ensure that every single issue raised has been resolved satisfactorily, , jyi
1 ; i by either fixing the documentorclarifying items incorrectly qagged as faults
. Al1 fixes ri
j ! ! 1 P''

ë I 1 I ! must be checked to ensure that no new faults have been introduced (Fagan, 19861. If ;: i I P1
! j i more than 5 percent of the material inspected has been reworked, then the team must pi
,
. I 1ë
;
) ! l j reconvene for a I00 percent reinspection. jk
! ' l ! ! l The inspection should be eonducted by a team of four
.
For example, in the caseI ' ; , 1
.
rv) j ) I 1
,
! of a design inspection, the team will consist of a moderator, designer, implementer, '
! è i q p and tester
.
The moderator is both manager and leader of the inspection team . There : (ê
: i i p1 i j 1 i must be a representative of the team responsible for the current phase as well as a
:l ! gi
j I representative of the team responsible for the next phase. The designer is a member . rcj j !
' ,
;
i ( h of the team that produced the design
, whereas the implementer is responsible, either im1
- . : .l : ' ' 1 individually or as part of a team
,
for translating the design into code. Fagan suggested jj D
i that the tester be any programmer responsible for setting up test cases; it is
,
of course, *j
n! ' ! .

@ l i h t th
e tester should be a member of the sQA group. The IEEE standard j.a, : , : p preferable t a6 l
'
' ; f between three and six participants (IEEE 1028
, 1997J. Special6 .1 , recommends a team oj
: I g ' :
6 : roles are played by the moderator; the readeti who leads the team through the design', bt( . j
i ' ! d the recorde6 who is responsible for producing a written report of the detected d1 , an
tl t : : :
) j . , faults. . jj
i ! ' . An essential component of an inspection is the checklist of potential faults. For ' sy
; i ' l l the checklist for a design inspection should include items such as these:
,
'
. ( 1 l i examp e, r
l : l P
i
ls each item of the specification document adequately and correctly addressed? For y (j.:
E
'
I
,
1 '. each interface, do the actual and formal arguments correspond? Have error-handling ' js
- ; j 7 !
, ' i mechanisms been adequately identified? Is the design compatible with the hardware $:1 l (
! . resources or does it require more hardware than actually is available? Is the design th;i
.1 i l compatible with the software resources', for example, does the operating system stip- . wi
l i t
i ' j ulated in the specitication document have the functionality required by the design? jjv
1 k 1 : 1 An important component of the inspection procedure is the record of fault statis-

j i I i tics. Faults must be recorded by severity (major or minor, an example of a major fault sl ' '
.
p . : . is one that causes premature termination or damages a database) and fault type. ln , tic1
'
1 i 1 the case of a design inspection, typical fault types include interface faults and logic : sui : 1 E
'
!
'
:- .j j : ( faults. This information can be used in a number of useful ways. , jng! !
; l ; ' j
.,,
1 ! ' . 1 The number of faults in a given product can be compared with averages of faults th11
' è ' ' : a at the same stage of development in comparable products
,
giving man- ' Pr'#' ! ; ,
, detecte
è;1 , ' ; agement an early warning that something is amiss and allowing timely corrective
.
(j
m
j
l
jl . :l , aetion to be taken
.j t) ! - I
.
l i 1 E : l 2. If inspecting the design of two or three modules results in the discovery of a
i ! : t k@ 1 i disproportionate number of faults of a particular type
,
management can begin ll i ' l I checking other modules and take corrective action
.

'
t I ,l
.I l j
, , . su! i 3. lf the inspection ot the design of a particular module reveals far more faults than
i 1 found in any other module in the product
,
then there usually is a strong case inEwereë
. !
i ' é for redesigning that module from scratch. diï
j
'
7
.
.
j! i 1'
k !l ;
.
j
'
i .
.
'
j :
'' l . . l
Please purchase Image To PDF Converter on to remove this message, thank you.
! '
: ' jI
j
NONEXECUTION-BM ED TESTING 1*3 ! l4.2
1

1
4. lnformation regarding the number and types of faults detected at a design inspec- j'le
lh . tion will aid the team performing the code inspection of the same module at a 1
7 later stage. l11
ie
,
Fagan's first experiment was pedbrmed on a systems product (Fagan, 19761. One 1
8, hundred person-hours were devoted to inspections, at a rate of two z-hour inspections i J'S
per day by a four-person team. Of all the faults found during the development of the i
lf roduct
,
67 percent were located by inspections before module testing was started. 1P
!
St
. Furthermore, during the hrst 7 months after the product was installed, 38 percent !
fewer faults were detected in the inspected product than in a comparable product
;e reviewed using informal walkthroughs. '
T Fagan conducted anotherexperimenton an applications product and found that 82 l9
1CC
percent of all detected faults were discovered during design and code inspections LFa- i1
a gan, 19761. A useful side effect of the inspections was that programmer productivity 4
Dr rose because less time had to be spent on module testing. Using an automated estim at-
Zr ing model, Fagan detennined that, as a result of the inspection process, the savings on :
td rogrammer resources were 25 percent despite the time that had to be devoted to the !P
e, inspections. In a different experiment. Jones found that over 70 percent of detected ë
rd faults could be detected by conducting design and code inspections glones
, l 9781.
al dies have produced equally impressive results
. ln a 6000-line iSubsequent stu
n', business data processing application, 93 percent of all detected faults were found

Z during inspections (Fagan, 19861. As reported in LAckerman, Buchwald, and Lewski,
19891, the use of inspections ratherthan testing during the development of an operating
3r system decreased the cost of detecting a fault by 85 percent', in a switching system
e: product, the decrease was 90 percent gFowler, 19861. At the Jet Propulsion Laboratory i
3r (JPL), on average, each z-hour inspection exposed 4 major faults and 14 minor faults (
lg (Bush, 19901. Translated into dollar terms, this meant a saving of approximately I ! 1: 1
re $25,000 per inspection. Another JPL study rKelly, Sherif, and Hops, 19921 showed jIn
that the number of faults detected decreased exponentially by phase. ln other words, i à
P- with the aid of inspections, faults can be detected early in the software process. The i i
importance of this early detection is reiected in Figure 1.5. '
S- A risk of the inspection process is that, like the walkthrough, it might be used l
l'1t for performance appraisal
. The danger is particularly acute in the case of inspec- i
ln tions because of the detailed fault inform ation available
. Fagan dism isses this fear by 1
'
ic ing that
,
over a period of 3 years, he knew of no lBM manager who used such i i
.
stat : j
information against a programmer, or as he put it, no manager tried to 'Aill the goose i j
that lays the golden eggs'' (Fagan, 19761. However, if inspections are not conducted ë'tS
properly, they may not be as wildly successful as they have been at IBM . Unless top j
j
(n- management is aware of the potential problem
,
misuse of inspection information is a r
ve pdistinct possibility
.

'
a :i
.
in l 2.* to-pu lsox o, IxspztTloxs Axp W AkxTuRouous ,*
.
Superscially, the difference between an inspection and a walkthrough is that thezn
inspection team uses a checklist of queries to aid it in finding the faults. But the Ise
difference goes deeper than that. A w alkthrough is a two-step process: preparation
' j
1
!
Please purchase Image To PDF Converter on to remove this message, thank you.
. j '( i .
i l t ' 1 j'j !
I , :
.
p ( ( f (t i
j :! i ! g 4** t u A p T : w l * Tes#lng
l ' ' ! (
'
.
1 I
,
!
l l i i followed by team analysis of the document
.
An inspection is a hve-step process:l k 1 ;
: : ël
j t i ! overview, preparation, inspection, rework, and follow-up; and the procedure to be
; 5 (j I 1 ; followed in each of those steps is formalized. Examples of such formalization are the' I

;
l f l categorization of faults and the use of that information in inspections of the! (
j j care u
i : l ! l 1 documents of the succeeding phases as well as in inspections of future products. -
q I $ ; I
j 1 dj 1 The inspection process takes much longerthan a walkthrough. Is inspection worth
l 1 1 the additional time and effort? The data of the previous section clearly indicate thatk :
I
; .
' 1
, I
i ? ' ! inspections are a powerful
,
cost-effective tool for fault detection.i
1 1 l ,1l
! . 1j E
.
j :1 -
j d@ l
'
k : l 2.5 Sn zxovus Aup w u xxzsszs oy Rxvluws :! 1 ! y
.
1 *)
.
' ! . ,. :( j j
;
There are two major strengths of a review (walkthrough or inspection). First, a review :
t ' ; ' ' is an effective way of deteeting a fault, and second, faults are detected early in the 4! i
1 r j i software process, that is, before they become expensive to fix
. For exam ple, design ' 4i

: ! ij ! i faults are detected before implementation commences and coding faults are found :
,
@ i i b f
ore the module is integrated into the product.! , r e
! ! .
.f , , H owever, the effectiveness of a review can be reduced if the software process is 'i
.
4 , ! j! !
: , inadequate. First, large-scale software is extrem ely hard to review unless it consists of . -
1 l t ' smaller
,
largely independent components. one of the strengths of the object-oriented 4! i
.
'
j ù , paradigm is that, if correctly carried out, the resulting product indeed w ill consist
) ' I : è . ,.1
,
: . of largely independent pieces. Second, a design review team sometimes has to referl
1 E ; r ; to the specification documents; a code review team often needs access to the design Il
! .t
' ; l documents
. Unless the documentation of the previous phases is complete, updated Ii l ' . 1!
t 1
.
)
, j , to renect the current version of the project. and available online, the effectiveness of i'
: i I i 1 review teams is severely hampered. il
: ; !l
.
i

.
i l .
1
.
j j (l j
' ! . *.2.* M eTplts FoR Ixspetvloxs c!
s Ii . t'
l : l To determine the eftkctiveness of inspections
,
a number of different metrics can be tl j - : , !
! E
: j 1 ' used. The first is ttwfaultdensity. When speeihcations and designs are inspected, faults t1
; . ( I / ; per page inspected can be measured; for code inspections, an appropriate metric is (El i
; ; j . i faults per 1000 lines of code (KLOC) inspected
.
These metrics can be broken into ll
.
j .
jj ':j i 1, j major faults per unit of material and minor faults per unit of material. Another useful
:( ; è ! 1! metric is bîjefault detection rate, that is, the number of major and minor faults detected ?:
71 ! 1 ' ' hour
.
A third metric is tbefault detection efficiency, that is, the number of major li , i pert '
,
j J ! and minor faults detected per person-hour. rl
.
.l l ' $ Although the purpose of these metrics is to measure the effectiveness of the rq
;
; . I
k , inspection process, the results instead may retlect deficiencies of the development t!1

l 1 : For example
.
if the fault detection rate suddenly rises from 20 defects per sI ' @ team'
- i !
) 1 ! : thousand lines of code to 30, this does not necessarily mean that the inspection team1 I ; ' i 1 has suddenly become 50 p
ercent more efficient. Another explanation could be that :1( ! :
.
1 : j the quality of code has decreased and there simply are more faults to be detected. ()
I :
,
1 . Having discussed nonexecution-based testing, the next topic is execution-based h
i ( I : testing. t4$
'
:
'
y 1 j
i ! .
'
I ! .p
i (
'
!
'
( (
'
t ! ( : 1
.' $4 . '
Please purchase Image To PDF Converter on to remove this message, thank you.