Software Engineering (phần 8) pptx

ii The client and intended users of the product now experiment with the rapid pro- I lI r ine totype, while mem bers of the developm ent team watch and take notes.. Based on their I : h

. ' j !

@

2 '.I i

as ' can be considered a paper prot otype ( Rettig, 19941, that i s, a series of sheets of paper l

ly each depicting the relevant screens and the user's response But, whatever method is k jn- chosen, the scenario should depictthe starting state, the expected sequence of events, l ':

i k

lt and the hnishing state, together with the exceptions to the expected sequence 4

the requirements analysis phase is to elicit i.

the real needs of the cl ient, and t he only source of this informati on is the cli ent )

.l.a @THKR Requl kzMxxTs EU<I TATION W tHNl quEs ) ! (

' rt ' Yet another way of eli citi ng needs is t o send a questionnai re to the rel evant members i:r- of the client organization This technique is usefulwhen the opinions of, say hundreds I

of individuals need to be determ ined Furthermore, a carefully thought-out w ritten j

be more accurat e t han an i mmedi at e ver bal response t o a ques t on posed ' ' l answer may

by an interviewer However, an unstructured interview conducted by a m ethodical 1 1

l 1i

nterviewer w ho listens carefully and poses questions that expand on initial responses j i

J ' usually yields far better inform ation than a thoughtfully worded questionnaire.Be-

l i

er cause questionnaires are preplanned

, there is no way that a question can be posed in !

!

L at A di f er en t way of el i ci t ng equi r me nt s pa r c ul a l us i nes s en vi r onmen t ; t

t al i t xa mi ne he var i ous or ms us e d by he cl i ent

.For example, a form in a print shop j !

l mi ght et l ect pr ess number , paper rol l si ze, humi di t y, i nk t emper at ure, paper ensi on, ( g

1 ts and so on The various f ields in this form shed light on the fl ow of print jobs and j 1 1

ts, the relative im portance of the steps in the printing process Other docum ents, such I k

k

f ' , rs as operating procedures and job descri pti ons,also can be powerful tools for fi nding j

ny out exact l y what done and how Such compr ehensi ve i nt or mat i on r egar di ng how j ! j

t t c e i ent c i ' ent ne e ur ds r en Th t er does ef or e, bus ar i nes ef ul s ca pe n r us be a of xt r cl aor i ent di na doc r y ument hel pf a ul i on n det houl e mi d nev ni ng er he be :

. j '

k m overlooked as a source of information that can l ead to an accurate assessment of the : : 1

he A newer w ay of obtaining such inform ation is to set up videotape cameras w ithin E :

t he workplace to record (wi th the prior wri tten permission of those being observed) i i ! 1

!

he exactly whatis being done

.O ne difhculty of this technique is thatt can take a long time ! i :

ji

. team has to spend an hour playing back the tape forevery hourthat the cameras record.

l Thi s time is i n addi tion t o what is needed to assess what was observed.M ore seriously,

1

1 this t echni que has been known to backhre badly because employees may view the '

l h cameras as an unwarr ant ed i nvasi on of pr i vacy l t s i mport ant hat he r equi r ement s ' q l

2 analysis team have the full cooperation of a1l employees'

, i can be ext remel y di f cul t ,

) j i '' At hi s s age he pr oc es s t he e qui r men t t a m has pr el i mi na r et of qui r - p

k . me nt s Thes e r qui r ement s ar e of wo t ype s f unc t ona l nd nonf unc t ona l Fu nct i nal p

ll $ requi eme nt s r l t he un ct i onal i of he r get of t war e; o xa mpl e, Stoyal- u

1 ; It is essential that the software be traceable; that i it must be possible to trace

each statement in the requirem ents document through the specifications,design, and

i code In thi s way, the SQA group can check that every statement in the requi rement s

$

j

has been implemented and that this has been done correctly To achieve traceability,

l each statement in the requirements docum ent needs to be num bered

!

:

t A 1l the item s in the preliminary requirem ents document are given to the client t

p get thei r prioriti es The cli ent (or a client t eam) ranks each prelimi nary requi rement .

!

l using categories sueh as essential

,highly desirable, desirable, and so on During the

$ 1 i most accurate and powerful requi rements anal ysis t echni que i s rapid prot otyping, a

.' ! !' rapid prototype is built.

Thi s i s descr i bed i n t he next sect i on.

' I 1 ! q

'

j (

!

!I@.a RAplD PROTOTYPING Q@5 ' l

t

'rd : incoroorate an input screen thatallows the userto enterdetails ofa new tenantand print : '

ily an occupancy report for each month.These aspects are incorporated into the rapid j ':

the prototype However, error-checking capabilities, file-updating routines, and com plex I :

! !nts tx com putations probably are not included. The key point is that a rapid prototype .

lult renects the functionality that the client sees,such as input screens and reports, but 1

b1e Om its tthidden'' aspects such as file updating (For a diftkrent way of looking at rapid i :

ter, prototypes,see the Just in Case You W anted to Know ox e b b low ). ii

The client and intended users of the product now experiment with the rapid pro- I lI

r

ine totype, while mem bers of the developm ent team watch and take notes. Based on their I :

hands-on experience, users tell the developers how the rapid prototype satislies theirneeds and, more important, identify the areas that need im provem ent.The developers tchange the rapid prototype until both sides are convinced that the needs of the client i ;;

l encapsulated in the rapid prototype The rapid prototype then is used !.Eare accurate y

,

!

An im portant aspect ot the rapid prototyping model is embodied in the word i ,

naI ' product, and the sooner, the better It does not m atter if the rapid prototype hardly j ) 'j

l z..

r al- works, if it crashes every few mi nutes, or if t he screen Iayouts are l ess than perfect y : I

h Iient and the developers t o agree 1 l

WS The purpose of the rapi d prototype i s to enable t e c !

lch as quickly as possible on what the product is to do Therefore any im perfections li l

i

in the rapid prototype may be ignored provided they do not seriously im pair the l i i

r e

iï I

put ' L functionality of t* he rapid prototype and thereby give a m i* ' ' ' * * ' sleading impression of - ' how : i

j 'the product will behave

1 1

j j '

I !

'

: i:

he idea of const ructi ng model s to show key aspects of prototype t o determine t he cli ent's real needs Sec- ' i j '

l a product goes back a Iong time. For example, a 16 18 ond, in an age before architecturaldrawings, the model l

j

:

1rst, ' painting by Domenico Cresti(known as ''11Passignano'' showed the builder the structure of the building antt in- ) :

ous : because he was born i n the t own of Passignano in t he di cat ed t o the st one masons how t he bui l ding was to j jthe ' Chianti region of Italy)shows M ichelangelo presenting be decorated This is similar to the way we now build i ' '

) !

. a wooden model of his design for St Peter's (in Rome) a rapid prototype of the user interface, as described in ;

to Pope Paul IV Such architectural m odels could be Section 10.4 ) 'L

huge; a model of an ear l er desi gn pr opos al or St Pe- I i s not a good i dea, however , t dr aw t oo cl os e 1 j

' t er' s by t he ar chi t ect Br amant e s mor e han 20 f eet ong a par al l el bet ween such ar chi t ect ur al model s and s of t 1 j '

' on each side ware rapid prototypes Rapid prototypes are used dur-

,

'

I

Architectural models were used for a number of ing the requirements phase to elicit the client's needs '

First, as depicted in the Cresti Unlike architectural models, they are not used to rep- 1, different purposes.

I

i painting (now hanging in Casa Buonarroti in Flo- resenteitherthe architectural design or the detailed de- I I

' r ence) , mo del s wer e use d t o t r y t o i nt er est a cl i ent i n s i gn' , t he des i gn i s pr odt l ced t wo phas es I at eq t hat , l 1

A s ec ond ma j or s pe ct of he api d pr ot ot ypi ng model ha t he a pi d pr ot ot yp e

1 . m ust be built for change If the first version of the rapid prototype is not what the

I1 client needs,

t hen he pr ot ot ype mus t be r ns f or me d r pi dl y i nt o a s cond ve r i on

I j t hat , t s hope d, bet t er a i f es he cl i ent ' r qui r me nt s To c hi e ve a pi d d ev el o

p-: ment throughout the rapid prototyping process.fourth-generati on languages ( 4GLs) g I

q

! i ! and i nterpreted languages, such as Smal ltalk, Prol og, and Lisp, have been used

Pop-i

:I ular rapid prototyping languages of today include HTM L and Perl,as well as visual

! C++ and J+ + Concerns have been expressed about the maintainability of certain

1 interpreted Ianguages

,but from the viewpointof classic rapid prototyping, this is irrel

l

2 evant All t hat counts i s, Can a given language be used to produce a rapi d prot otype?

i And can the rapid prototype be changed quickly? lf the answer to both questions is

;

I yes.then that language probably is a good candidate for rapid prototyping

;

j Turni ng now to t he use Of rapid prototyping i n conjuncti on wi th the

object-i Orientod Paradigm.three very different Object -oriented projects canied Out by lBM 1

j j gcapper, Col gat e, Hunter andlames, 19941 Oneof therecommendati ons thatresult ed

I i. ! ' ( fr om t hese pr oject sshat mpor t ant o bui l d a r api d pr ot ot ype as ear l y as poss i bl e

I lt is im portant that both the client and the future users of the product interact with

the rapid prototype of the user interface Encouraging users to experiment with theI

human-computer interface (HCl)greatly reduces the risk thatthe finished productwill

; have to be altered ln particular, this experim entation helps achieve user-friendliness

,

1 a vital objective for all software products.

l

! The t erm user- fri endli nen' refers t o the ease with which human beings can

com-! m unicate w ith the software product lf users have difliculty learning how to use a

i roduct or tind the screens confusing or in-itating

,then they will ei ther not use t he p

j 2 , l n t hi s exampl e, he user ent er s 1 2, or 3 t o i nvoke t he corr es pondi ng command.

Nowadays, instead of sim ply displaying lines of text, HCIs employ graphics. '

W indow s, icons, and pull-down m enus are com ponents of a graphical user interface

2

J

I ,

i $

4*.* HUMAN FM TORS A*V

pe (GUI) Because of the plethora of windowing systems, standards such as X W indow

3e ' have evolved Also, ûlpointand click''selection is becom ing the norm The user m oves

m a mouse (that is, a handheld pointi ng devi ce) t o move t he screen cursor to the desi red l

é int'') and pushes a mouse button (diclick'' to select that response iP- response ( po

s) ' However, even when t he target product empl oys modern technol ogy, the design- q

p- ers m ust never forget that the product is to be used by human beings In other words, y

al t he HCl designers must consi der humanfactors such as size of l ett ers, capi tali zation, : ,

! ':- Another example of hum an factors applies to the preceding m enu If the user ' !

z? choos es opt i on 3 Sel ectvi ew t o be gr aphed, hen anot hermenu appears wi t h anot her l j i

is list of choices Unless a m enu-driven system is thoughtfully designed, there is the 1

danger that the users will encounter a lengthy sequence of m enus to achieve even a

2t- relatively sim ple operation This delay can anger users, sometim es causing them to

M) m ake inappropriate menu selections Also, the HCl must allow the user to change a ë

;

m previous selection without having to return to the top-level m enu and start again This

td problem can exist even when a G UI is used because many graphical user interfaces r j

le essentially are a series of menus displayed in an attractive screen format ' :T 2

t

Som etimes, a single user interface cannot cater to al1 users For exam ple, if a ,

ze product is to be used by both comput er professi onal s and hi gh-school dropouts with 1 t

no previous computer experience, then it is preferable that two different sets of HCIs i i

th the user becomes more fam iliar with the product,stream lined screens thatprovide less i

le inform ation are displayed, leading to speedier com pletion This automated approach ! C

i ll reduces userfrustration and leads to increased producti vity (Schach and W ood, 19861 : .

'S, M any benefits can accrue when human factors are taken into account during the : j

desi gn of an HCI i ncludi ng reduced Iearni ng time and I owererrorrat es Although hel p ' i

s, tOO, increases productivity Unllorm ity ol Htil appearance across a product or l 2 'j

le group of products can resul t in users intuiti vel y knowing how to use a screen they have lI ' I

ts never seen before because it is sim ilar to other screens w ith which they are familiar ' 1,

7- Designers of M acintosh software have taken this principle into account', this is one I j

le . of the many reasons that software for the M acintosh generally is so user-friendly I E: I.l

' a u e I - has i endl bee y n HCI s ugges Wh t d et t he hat r or i mpl not e c hi ommon s c har ge e ns s e t ue i al i t I i ha e t s s e nt n ee i al ded hat o des api i gn d ; , 1 i

'

pr ot ot ype Of t he HCI of every product be const ruct ed I nt ended user s of t he product l I

' im ent with the rapid prototype of the HCl and inform the designers whether ! 1

the target product indeed will be user-friendly that is, whether the designers have i

s ln the next two sections, superhcially attractive but dangerous variants of the i : j

r

:

'

j1

j 1

l l1 !:

q l

: :

: : '@.s RAplp PRoToa plNo As A 5p!c1FIEATIoN TEEHNIQUE 2@@

'

as a m eans to determine that the client's needs have been elicited accurately O nce

the client has signed off on the specihcations, the rapid prototype implementation is

E discarded (but the l essons l earned are retained and used in subsequent development ;,

phases) A second approach is to dispense wi th speci hcati ons as such and use the i

.

rapid prototype itself either as the specifications or a significant part of them This

d t pe of rapid prototyping m odel is show n in Figure 10.2 The approach

j

fers both speed and accuracy.No ti me is wast ed drawing up writt en specihcati ons, ;

iand the difficulties associated with specifications, such as am biguities, om issions, :and contradictions, cannot arise lnstead, because the rapid prototype constitutes the E lspecihcations, all that needs to be done is to state that the product will do w hat the

id rototype does and list any additional features the product must support, such j

as fi le updating, securi ty, and error handli ng 1

g 'i

phase ! I ji

: y 1t

: ' ;

. t

.2l

i I

i

) ( j

This version of t he rapid prototyping model can have a major drawback lf t here

is a disagreement as to whether the developers have satisfactorily discharged theirobligations, it is unlikely that a rapid prototype will stand as a legal statement of a

j cont r act bet ween devel oper and cl i ent For hi s reason, t he r api d pr ot ot ype s houl d

I never be used as the sole specihcation, not even if the software is developed inter- '

: nally (that i s, when the cl ient and devel opers are members of the same organizat ion).

L Although it is unlikely that the head of the investm ent m anagement division of a

f bank w ill take the data processing division to court

, disagreem ents betw een clientI

;

l and developers neverthel ess can arisejust as easil y wi thin an organi zation Therefore, '

'

f to protect themsel ves, sottware developers should not use the rapi d prototype as t he ,

l specihcations even when software is developed internally

.1

, A second reason why the rapid prototype should not take the plaee of written

l ) documents to reflect the new speci ficati ons because, in the absence of writ ten

speci-: ê l i the maintenance team have no clear statem ent of the current specilications

k ln b0th versi ons of the rapi d prototyping model discussed previousl y, thc rapi d

pro- is discarded early in the software proeess A n alternate, but generally unwise,

.( way of proceeding is to develop and rehnc the rapid prototype until it becomes the

1 product Thi sshown i n Fi gur e 10 3 n t heor y, hi s appr oach shoul d l ead t o fast sof t )

I ware developm ent',after all, instead of throwing away the code constituting the rapid

; j prototype, along with t he knowledge built i nto it, the rapid prototype is converted i nt o

l y the tinalproduct However, in practice the proeess is very sim ilar to the build-and-tix

i j ! ' procee , d as shown in Fi gure l.5 A second probl em is that a primary objective when

j constructing a rapi d prot otype is speed of buil ding A rapid prototype (correctly) is

I put together hurriedly,rather than carefull y specit ied, designed, and impl ement ed '

ù El i

@ !1

!

.*.* REUSING THE RAplp PROTOTYPE 3@% I

!i 2

- - '+ M aintenance Retiem ent

i I

d be short t erm and the I ong term to do t hi s ratherthan try to convert a rapi d prot otype into $ i

I

A nother reason for discarding the rapid prototype is the issue ot pertorm ance, 1

part icul arly of real-time systems To ensure that time constrai nts are met, it i s nec- , !

gessary to design the product carefully ln contrast, a rapid prototype is constructed (

to display key functionality to the client', performance issues are not handled As a ! :

: iresult

, if an attempt is m ade to refine a rapid prototype into a delivered product it is 'unlikely that response times and other timing constraints w ill be met :PrO- One way of ensuring that the rapid prototype is thrown away and the product !

! i Vise,

i pr oper l y desi gned and i mpl ement ed i s t o bui l d t he r api d pr ot ot ype i n a di f fer ent j

into refined until the client is satisfied that it does everything, or alm ost everything, the I

EI-EX target product is to do.Next, the product is designed, relying on the knowledge and 1 :

l

E! !thi

s skills acquired in constructing the rapid prototype Finally, the design is implem ented j '

;

pro- in Java, and the tested product handed over to the client in the usual way I i

t y t o Nevertheless, there is one instance when it is permissible to rel ine a rapi d proto- i j i

z hen t ype or mor e speci hcal l y, por t ons of t he r api d pr ot ot ype When por t ons ot :l

y) is prototype are computer generated

, then those portions m ay be used in the final prod-

lted uct.For example, user intert-aces often are a key aspect of a rapid prototype (Section

icult 10.3) W hen CASE tools such as screen generators and report generators (Section :

then 5.4) are utili zed to generate the user interfaces, those portions of the rapid prototype .j

t l

l.

of the rapid prototyping m odel being adopted by some organizations.Here, m

anage-I ment deci des be for e t he r api d pr ot ot ype i s bui l t hat por t ons may be ut ized i n t he

2

, This approach goes beyond rapid prototyping For example,com ponents of suffi

-i iently high quality to pass design and code inspections usually are not found in a !

, ' :

, l rapid prototype Furtherm ore,design documents are not part of classic rapid

I typing Nevertheless this hybrid approach is attractive to som e organizations hoping

l to recover som e of the tim e and money invested in the rapid prototype.However, to

! One difhculty with rapid prototyping is that the ease w ith which changes generally

k l I j can be made to a rapid prototype may encourage the cl ient to request all sorts of major

r! g r

: I l

j

changes to the del ivered operational-quali ty version of t he product Furthermore, t he

j client may expect the changes to be impl emented as rapidl y as changes to the rapi d

I prototype A related challenge is having to explain to the clientthat the rapid prototype

is not of operational quality and the client will have to wait tbr the operational-quality

2 version, even though the rapid prototype appears to do everything needed.Before

l rapid prototyping is used,i t i s essential that the managers responsibl e for devel oping

: j prototyping is strong, it has not yet been proven beyond al1 doubt.For exam ple, a

' ' ji frequently quoted experim ent is that of Boehm,Gray, and Seewaldt, who com pared

.

p ' j ! seven different versions of a product gBoehm, Gray, and Seewal dt, 19841 Four ver

-: ! ions were specihed and three were prototyped w ith the rapid prototype serving as the

1 :

I ! specifications The results were thatrapid prototyping and specifying yielded products

1 ' ' i with roughly equi valent performance, but the prototyped versions contai ned about 40

percent less code and required about 45 percent Iess effort The reason was that the

;

i

: specification teams had no com punctions about adding bells and whistles to the

spec-'

( it ication document.O n the other hand, the rapid prototypers realized that they would !

have to build every feature into the rapid prototype and,therefore, w ere reluctant toincorporate any functionality thatdid not seem essential.W ith, on average,40 percent

l Iess code, it is not surprising that the prototyped versions were rated somewhat lower

' One im portant point about this experiment was that it was conducted on seven t

' team s of graduate students, three two-m ember team s and four three-m ember team s

The project was only 10 weeks in durati on, and no maintenance of t he product was )

performed ln other words, the experim ent is not typical of real products w ith respect i

t o number of parti ci pants, team size, project size, or software process It t herefore i

r 1

perhaps is unw ise to accept Boehm 's results as a blanket endorsement for rapid pro- 1

t ot ypi ng l nst ead, t hey s houl d be t aken as i ndi cat i ons of he comparat i ve st r engt hs (

and weaknesses of rapid prototypi ng when compared to specifying ln addition t o t he ( !

hi s col l abor at ors f ound t hat prot o- i l

., weaknesses pointed out previously, Boehm and

typed products are harder to integrate than specihed products Ease of integration is

. ' important for large-scale products especially C4I (comm and control, comm unica- '

tions, computers, and intelligence) software This is a further reason to use the rapid

prototyping m odel depicted in Figure 10 1, where rapid prototyping is em ployed as j

a requirem ents analysis technique, and not use the model of Figure l0.2 where rapid l ë

T wo aspec ts of rapid prototyping must be taken into account by any m anager i l

!

Section 10 5 point ed out that i t is short si ghted to t urn a rapid prot otype i nto the l

.Ifinal product', the rapid prototype should be used solely as a m eans of accurately (

!determ ining the client's requirements A second im portant issue is that, under some , j

f circumstances, rapi d prototyping can take t he pl ace of the specificati ons phase' , i t $ $

! 1

r can never replace the desi gn phase A team certainly can use the i nformation and j

experience gained from the rapid prototype as a guide to t-ashioning a good design', ' l

,because t he r api d pr ot ot ype i t hrown t oget her r api dl y i unl i kel y t hat a 2 i I

( A more fundamental issue is that managing the rapid prototyping modelrequires l 1

z a major change in outlook for a manager accustomed to managing only the waterfal l !

é m odel The concept underlying the waterfall m odel is to do things correctly the lirst l

del incorporates a num ber of feedback loops if the ; i

s team does not aecomplish this goal (and the goal is sel dom, if ever, reached) However, r' !)

s the ideal for the waterfall model team i s to perform each phase of the devel opment i

E process one time only In contrast, a rapid prototype is built specihcally to be changed 'i i q

) 'i

R . frequently then thrown away This conceptis diam etrically opposed to the approach to !

: which the average m anager is accustomed The rapid prototyping approach of taking '

- several iterations to get it right probably is a more realistic approach than the first- , j

z time-right waterfall model expectation, and this logic may help convi nce a manager j !

) Anot her as pect of t he r api d pr ot ot ypi ng model hat requi r es a di f er ent approach ( 1 l

z on the part of the m anager is the increased interaction between the client and the 2 i

- developerss particularly the rapid prototyping team ln the watertall m odel,interaction l

E be t we en cl i ent an d de vel oper s s e nt i l es t c ed er i es of t er vi e ws et we en 1 )

i rements t eam and t he client and its employees W hen rapi d protot yping is ) i j

3 t he requ

t ' used there is almost continual interaction between the rapid prototyping team and :

r t he cli ent' s t eam until the rapid prototype has been aceept ed , l

; q

: 1ë

-1: i

'

g '

i 1

' ' Gordon and Biem an analyzed 39 published and unpublished case studies that use rapid

, prototyping (Gordon and Bi eman, 19951 Of these, 33 were considered successes, 3

' I 1 1 W ere considered fail ures, and 3 were not rat ed. Gordon and Bi eman have pointed out .

l rapi d prototyping was used wit h some success.

I Not all the case studi es, as published, reqected every issue of i nterest For

' ple, comm ents on ease of use appeared n on y

l of use of the delivered product as a consequence of rapid prototyping was reported in

a11 l7 instances', none of the other 22 case studies claimed that the productw as harder

; Il to use. Therefore, although the data are incom plete and specilic topics may not be '

) expl ici tly mentioned, it i s possible t o draw some conclusions.

t ' Al l t he case st udi es hat comment ed on us er part i ci pat i on r eport ed ent husi ast i

-.'1 j creased code si ze Many case st udi es menti oned that fewer unnecessary feat ures were

i l l implemented wit h rapi d prototyping, but tw o reported an inerease in such features.

l

I , choice of Ianguage for rapid prototyping does not appeart o be of critical i

mpor- ! ! I tance. A total of 26 different languages were used in the 39 case studies. The most

t ! should be disearded lt is diftieult to reac.h definite conclusions on this issue because

!I of the wide variety of software processes used. ln som e cases, the rapid prototype ,

'

j as a whole was successively refined until it became the final product In others, only l

'

' i1 part of the rap pid rototype was retained and the rest discarded In one instance, a

: ! design phase was required for each iteration of the rapid prototype For some of the

2

case studies, management speeified in advanee that the rapid prototype would be

' j ret ained and ref ined.Of the cases studied, 22 specihcally recom mended retaining

k l and refining all or part of the rapid prototype, and 8 insisted that it be discarded

' ' It has been suggested that retaining the rapid prototype is particularly important for

l

'

4 I arge products Of t he 39 case studies, 7 were considered large (over 100, 000 l ines of

' t@ i code), and all 7 recommended retaining all or part of the rapid prototype ln view of

k

: ' the generally held belief that rapid prototypes for all products should be discarded,

!

1 '. further research needs to be conducted in this area In particular,itis im portant to know

: whether the m odified rapid prototyping model described at the end of Section 10.5

h w ished to retain first had to pass design and code inspections

1 Some tentative conclusions can be draw n from this work The first is that rapid

' prototyping is a viable technique that can lead to successful softw are development At '

the same time, there are a num ber of possible risks If the rapid prototype is retained, .

2 t here is a danger that the resul ting product wil l be badly designed, hard to m aintain, .

. !t

g 2

'

j4 44 TEsTlNo DuRINo THE REQUIREMENTS PHASE a@5

' j

:

and perform poorly', these risks appear to grow in proportion to the size ofthe product E

However, the risks can be reduced One way is to use the m odihed version of rapid pprototyping described in Section 10.5 j ;

id

:There is a difference between reporting on case studies and conducting controlled ;

7e

'

The primary requirements eli ci tation techni que is intervi ewing (Section 10 1 1) To

ic illustrate this, suppose that the requirements analysis team decides at the start of the ! i

nt project to build a rapi d protot ype Before the f irst i teration of the rapid prot otype can : l

' be buil t, however the team must intervi ew the relevant client personnel The more q l

jzd

n- thoroughly these interviews are conducted, the greater is the probability that the hrst ) 1

re i er at i on accur at el y wi l r ef l ect he cl i ent s needs On t e o j

together a rapid prototype and then going through a Iengthy retinem ent process w ill 1,I

' il1 not be completely m et by the targetproduct i

br Perform ed and thatthe client s needs w

At essential to give the users the opportunity to experim ent with the rapid prototype i l

,

, d, ! and suggest changes that, when approved by the cli ent, wi ll be impl emented i n the r j

l

l: l '

E j

. Therefore the role of the softw are quality assurance group during the rapid

: prototyping phase is to ensure that the relevant individuals in the client organization

have the opportunity to interact with the rapid prototype and their suggestions actually reach the client orsperhaps, a com m ittee of client m anagers responsible for analyzing

! statements of the requirements need to be numbered t o enabl e the SQA to trace them

) i through the subsequent phases The numberi ng shoul d appear in the rapid protot ype

t

: i n t he f orm of comment s adj acent o t he group of st at ements hat i mpl ement s each

Interpreted languages generally serve as good media for rapid prototyping.Because .

) g interpreted languages need not be compiled or linked, the development of the rapid

; : 1 prototype i s faster Also, minor changes request ed by t he client often can be

imple-' ) t 1. ment ed whi l e t he rapi d prot ot ype i s bei ng demonst rat ed Int er pr et ed l anguages, i n

j Further efl iciency can be gai ned by using CASE t ool s associated wi th the rapid

j prot ot ypi ng l anguage For exampl e, Smal l al k has an envi r onment t hat assi s t he

I user w ith a variety of tools and speeds up the rapid prototyping process.The lnterlisp

r environmentis a similar productthat assists Lisp programmers.Java is afully portable

,

p i nt er pr et ed l anguage Many Java envi r onment s cur rent l y ar e on t he mar ket , and mor e

! are expected in the future As previously m entioned Perl is a popular programm ing

I

j language for constructing rapid prototypes HTM L is another important widely used

,t rapid prototyping l anguage If the rapid prototype will be discarded (as described i n

1 Secti on l 0 7) t hen HTML has a further advantage lt is almost i nconcei vable that t he '

; '

F delivered product will be w ritten i

n HTM L, so use of HTM L virtually guarantees that

!

!

! For some years now, fourth-generation languages sueh as Oracle, Pow erBuilder,

j : ' ù and DB2 have been used for rapi d prototypi ng (4GLs are discussed in Section 14.2).

,'! There are a number of reasons for this.First, a design goal of every 4GL is that fewer '

.

; statem ents are needed to achieve the sam e functionality than w ith a third-generation

i language Iike Java,A da, or C+ + Thus, the rapid prototype is likely to be delivered

l idly when a4G L is used.second, many 4GLs are interpreted.This speeds up

, the use ot a 4G L for rapid prototyping can have an inherent y

r qu ent l y doe s n ot ar e i t he of t wa r pr oc es s de gene r at e i nt o t he bui l d- a nd- f l

t he ê model.Unfortunately, the sole aim of m any 4GL suppliers is to ensure that develop- i

'

1 em ' ment or gani zat i ons purchas e i pr oduct a si ngl e CASE envi ronment hat can handl e : : j

software process It certainly is not easy to convince that m anager to spend still more i i

, money on a workbench tor a ditterent. language to be used tor rapi. d prototyping to s

ensure that rapid prototypes can be discarded The m anager may well retort that he or !1

she has purchased a perfectly good rapid prototyping tool as part of the new

A key feature of the requirem ents phase is how rapidly the requirem ents team de- 4

zpid '' termines the client's real needs.So a useful m etric during this phase is a measure of !

th

e requi rements volatili ty Keepi ng a record of how frequent ly the requirements change ; I

lisp J during the requirem ents phase gives m anagem ent a way of determ ining the rate at l r

j

tble

. which the requirem ents team converges on the actualrequirements of the product.This l i

Lore metric has the further advantage that it can be applied to any requirements elicitation : 'i

Sed Another measure of how well the requirements team i s doi ng itsjob is the number 1

E in of requirements that change during the rest of the software developm ent process.lf ' : 1

1th

e a large number of requirements have to be changed during t he specification, desi gn, ' I

E hat and subsequent phases

,then it is clear that the way that the team carries out the '

- l tric when rapid prototyping is used is the number oftimes each feature : t.2) i A usetu me

Ner Of the rapid prototype is tried when the client and users experiment with the rapid i

1

lon prototype. For exam ple, if every user selects Screen J from the m enu at least once but

'

j'red no one ever chooses Screen B, then the development team should ask the client about i

; UP those tw o screens Specitically, the developers need to know whether Screen J is so ; iare importantthat the design should minim ize execution time for that screen and whether

ICSS Screen B even needs to be included in the product If so, then at least one user should 1

E Iexperiment with Screen B', it is vital that alI screens should meet the users' needs !

1

t

1 :

othing in this chapter appertains to the object-oriented paradi gm It certai nly is

t p reasonabl e t o ask why t hi s is so After al l, the title of this book i s Object-orientedand

' ) Cl assi cal So ft ware Engi neeri ng, and l ack of mat eri al on object - or i ent ed r equi r ement s

1

' ;) The answer is that there is no such thing as obik ect-oriented requirements,1nor ' )

1 should there be such a thing.The aim of the requirements phase is to determ ine

$ t he el i ent ' needs' , t hat i s, what shoul d be t he f uneti onal i y of t he tar get syst em.

' I The requirem ents phase has nothing to do with how the system is to be built It is

1 meaningl ess to refer to the classical paradigm or the object-ori ent ed paradi gm wi thin

r by the user when running the software product and has nothing to do with how the

i product has been built In the same way, the requirem ents phase results in a statement

t he qui r ement s pha s or pe ci f

l 1 i nc l udes bui l di ng a pi d pr ot ot ype.A s a consequence of writing the code

for the rapid prototype, the development team will acquire insights into the problem

1 dom ain, including ideas as to what m ight constitute a class within the target software

i That is, even if the rapid prototype has been written in a classical language like C or

Lisp, the team will become aware of the fundamental building blocks of the

prod-l uct t o be const r uct ed Then, i n t he next phase, object - or i ent ed anal ysi s ( OOA) , hi s

l inform ation can be of assistance in the tirst step of OOA

, extract ing t he classes (see l

l ' ; ' M any airline passengers have di etary requirements, and the majori ty of airli nes

en-! ! 2 deavor to provide food t hat meets their needs.For example, given sufûcient notice,

h

I

j ; most airlines will serve vegetarian vegan, seafood, Kosher or Halaal m eals, as well

'

i as diabetic low-fat, low-cholesterol low-protein, low -calorie, or low -sodium meals

l A child's m eal alm ost always can be ordered.Some airlines will supply lactose-free

I

.

' ; meals Flight attendants are provided a Iist of the passengers who have requested

special meaI.% and their seat numbers', the special m eals then are served at the same

i

1

Li ke al mos t l bus i nes s de ci s ons , a de- of f s nvol ved pr ovi di ng t hes e pe - ' j

ial m eals. The benefits include increased passenger volume and passenger goodwill; 7 l

c

after all, if an airline does not provide special m eals it w ill Iose passengers to ai

r-S lines thatprovide them.On the other hand, signilicantcosts are involved in providing 1

d

jspecial meals:

iights, where its competitors currently provide at most q i 1

, the air, even on those shorter

been shrinking, and its executives are looking for ways to cut expenses The high cost 1, '

of providing special m eals com bined w ith anecdotal evidence suggesting that only I ! E

. a small fraction of special meals reach the passengers who ordered them, have made ! y ,

' special m eals a tem pting target for the Air G ourmet bean counters

' Gourmet food subject to quali ty control in the Ai r Gourmet ki tchens A passenger '

:

3 - satisfaction survey therefore m ust be conducted to determ ine the perceived quality of 1

l '!

e, special meals A lso,A ir Gourm et executives need to know what percentage of special ;

l e meals are t ransported to the relevant aircraft on time.Then, just after each takeoff, a

report for the qight attendants is pri nted onboard the aircraft This report contai ns the i i

L

'

! l I

j l

l

1

a%@ t H A p ' : R 1* * Requirem enfs Phose

i reservation identilier, nam e, and seat number of each passenger onboard that flight

: I has the information needed to print this report.)

i. 1 To obtain the information requested by m anagem ent regarding special m eals,

1 certain modifications have to be m ade to the Air Gourmet software First,each tim e a ,

'

j

:

' l special m eal is ordered,the follow ing inform ation m ust be recorded: the reservation

ï l identitier; tght number, date, and time; passenger nam e and address', and type Of i

l I speci al meal ordered This informat ion will be used by the new software to be wri tten .

; be scanned lf the square has been shaded and the passenger was onboard the aircraft,

' i a oostcar d beari ng the reservation identifi er will be mailed to the passenger aski ng

j him or her to rate the meal on a scale of l (unacceptable) through 5 (superlative)

l W hen t e postcar h d is returned,it too,, w ill be scanned and the reservation identifier '

1

!1 ' rhe r t hus a r hr e s epa r t e quen t al t ges or he s pec i al meal s a na l ys i

i : j software: the addi tional records generated 24 hours before departure, the scanned

' l lt s, and t he scanned pos t car ds The f ormat s of he r ecor ded dat a el ement s ar e as

f ol l ows opt i onal f i el ds ar e i n br acket sl : ' : l

1

I i ' Reservation i denti fier (6 uppercase letters)

.i Fl ight number (3 digi ts, right justi fied and zero f ill ed)

y Fl ight date (9 charact ers: z-digi t day, 3-uppercase letter month, 4-digi t year)

i seat number (3 digi ts

,ri ghtjustil ied and zero fi lled, foll owed by an uppercase (

ë j Special meal type (chil d, diabeti c, Hal aal, Kosher lact ose free, l ow calorie, low

i cholesterol , low fat, low protein, l ow sodium, sea food, vegan, veget arian)

l

o per cei ved meal qual i y (1 t hr ough 5) 1' ''

The new softw are must enter inform ation from the database and allow the us

! I

is more than once within the time period of the report, and the dates of occurrence '

td 3 The nam e and address of every passenger who felt that the quality of his or her

:

' : s peci al meal was l ess t han super l at i ve (5 on t he scal e), t he dat e of occurr ence, t' : ;2

and the m eal type

. For each low-sodium meal served, the flight number and date, and perceived meal ;

T

Air Gourmet management is greatly concerned about the risks of m odifying its j I

existing computer system to incorporate this addi tional functionality Also, manage- !ment is reluctant to purchase the various scanners until the new product is complete l

I

Accordingly, it would Iike a keyboard-driven, stand-alone product to be constnlcted that w ill enter reservations, check in passengers, scan lists of special meals printed ': l

'

on board (this is to be simul at ed by keyboard i nputl' , scan postcards (also keyboard , :

input), and produce t he vari ous reports As a further precaution against premature ' ichanges to the existing com puter system , Air Gourm et management decides to hire I j g

an outside software organization to build the stand-alone product ; )

1I ip i

: I

:

1* 15 AI R G@URMET CASE STUPY: pI p ' ) ! j

, 1

w Notwithstanding the care taken when interviewing A ir G ourm et management and :

2 l

s af f t o det er mi ne t hei r r equi r ement s accur at el y, the only way to be sure the final ) I

j danger hat he i mpl ement at i on t eam wi l conver t he Java api d pr ot ot ype nt o C++ '

, notw ithstanding the problem s of the resulting bui

; : better choice, because then the rapid prototype will have to be com pletely rewritten

. ! l i E in Java; i f c++ i s used, again, the impl ementation team might convert the rapi d

rototype (this time from C++ into Java) and modify it, instead of implementing the

!

1 production-quality version from scratch

! The C and Java rapid prototypes are available at w ww

.mhhe com/engcs/

1 1

. ; compsci /schach The code general ly i s st raightforward Nevertheless, three aspect s E

l !: product,a data structure that allows for a variable num ber of passengers is needed .

! For exam ple, a file or a dynam ic data structure could be used In the rapid prototype, :) however, an array is used because it is easy and quick to implement, and the rapid 1' ! 1 be tested wi th a small number of passenger records

.Analogously, up i.

I I pr ot ot ype can

l

! to 20 night records are stored in another array; this also is reflected in Figures 10.4

! j

'i The second im portant aspect of the rapid prototype is that it is unfinished.For

' 1 !

i exampl e only t wo of t he six reports have been i mplemented, t he report on

low-i sodium meals and the report on meals onboard the iight This is because the other

four reports are sim ilar to the two that are implemented.These four reports are coded

'

as stubs, that is, dummy routines consisting of an interface but wit h no body; theyjust )

display a message when invoked O ne instance of this is shown in Figures 10.4 and ;

I , 10 5 Omit ti ng the body of these routi nes speeds up development of a rapid prototype ;

'

I , Without signil icantl y detracting from its functi onali ty :

' i 11 the user interface of the rapid prototype is menu driven; this is im plicit

. : ' in the last line of Figures l

.4 and 10.5 A menu-driven interface certainly is notI

; sl r ud pas s enger -f ype poss enger -r ecor ds I NUM-PASSENGER-RECORDSl ;

! slrud fliqhtrecord-t ype fl i qht recordsg NuM FLI GHT RECORDSI;