Information Systems Lecture 05

8/9/2019 Information Systems Lecture 05

http://slidepdf.com/reader/full/information-systems-lecture-05 1/28

Information Systems

Lecture 05

Julian Pereira

1



PROTOTYPING

2



The Prototyping Model• Before starting development of the actual

system, a prototype may be built.• A prototype is a ‘toy’ system (or part thereof):

– limited functionality;

– low reliability (often full of bugs); – inefficient performance;

– inaccurate results.

• Nevertheless, prototypes help in developinghigh-quality software products!



Prototyping: Why Bother • To demonstrate concepts to the customer:

– user interfaces, novel ideas, etc; – e.g. GUI-based prototypes are commonly used to

refine customer requirements.

• To explore difficult technical issues: – major design and implementation decisions often

depend on technical issues –

– e.g. hardware performance; – e.g. efficiency (in time & space) of software.



Prototyping: Why Bother

• Construction of a working prototypeinvolves additional cost; however...

– Overall development cost might be lower

for:• systems with unclear requirements;

• systems with unresolved technical issues.

– User requirements are clarified andtechnical difficulties are resolved:

• omitting the prototype would lead to change

requests, and hence redesign costs.



Prototyping :Method !Part "#

• It may be impossible to get a system right the

first time, so build one to throw away!

1 Carry out a quick requirements analysis.

2Carry out a quick design.

3 Build a prototype using short-cuts:

– e.g. use look-up tables rather than performing

difficult computations; – e.g. do not perform error checking or exception

handling.



Prototyping :Method !Part II#4 Submit the working prototype to the

customer for evaluation.5 Use customer feedback to refine therequirements, and hence the prototype.

• The cycle (phases 2-5) continues until thecustomer approves the prototype.

• The final system is then developed usingthe classical waterfall model.



The Prototyping Model

Build Prototype

Gather

requirements

Design

Prototype Evaluate Prototype

Refine requirements

CUSTOMER

APPROVAL

Implement

Test

Maintenance

FEEDBACK

Design



The Prototyping Model• The requirements phase is eliminated:

– the prototype (with customer feedback) serves as aspecification.

• The prototype must be thrown away:

– however, the experience gained from it is invaluablefor developing the final product.

• Never give in to management or customer

pressure to patch the prototype for release: – it will be a maintenance nightmare!



Types of Prototypes• Thro$a$ay

• %&olutionary

• Incremental

10



Thro$a$ay Prototyping• In this approach the prototype is constructed

$ith the idea that it $ill 'e discarded and thefinal system $ill 'e 'uilt from scratch( The

steps in this approach are:

– Write preliminary re)uirements

– *esign the prototype

– +ser e,periences-uses the prototype. specifiesne$ re)uirements

– /epeat if necessary

– Write the final re)uirements 11



Thro$a$ay Prototyping• prototype de&eloped as part of a thro$1

a$ay approach $ill not form part of the finalsolution( It is li2ely to inform the final solution.

'ut the prototype itself $ill not 'ecome part

of the final solution(

• Thro$1a$ay prototypes are a useful $ay of

e,ploring ideas. and gaining feed'ac2 fromthe client and-or end1user( They tend to 'e

used to ans$er )uestions( They are then

discarded(( 12



Thro$a$ay Prototyping• %,ample: $ould it 'e possi'le to read &alues from a te,t file

into a program• thro$1a$ay prototype could 'e produced &ery )uic2ly to

esta'lish if this is possi'le. and ho$(

• The outcome of the prototype might 'e: 3es. it is possi'le and

$ould 'e relati&ity easy to achie&e using a particular tool or

method !eg a comma delimited te,t file can read into a

application. program or script( The elements from the file

could 'e stored in one or more &aria'les or arrays#(• The prototype has ans$ered the )uestion. thus has ser&iced

its purpose and can no$ 'e discarded(

13



Thro$a$ay Prototyping

14



%&olutionary Prototyping• The e&olutionary approach aims to de&elop a

mature system through a series of prototypeiterations( The prototype will undergo a

series of refinements, and should

eventually become the solution( This can 'e

li2ened to the first draft. second draft. third

draft ((( final &ersion(

15



%&olutionary Prototyping• This approach is particularly useful $hen the

e,act re)uirements of the solution cannot 'eset out in ad&ance. or are considered to 'e

&ague( The client and-or end1users can

'ecome closely in&ol&ed the de&elopment.

playing a 2ey role as each iteration mo&es

further from prototype and closer to a usea'lesolution that does $hat it is needed to do. and

does it $ell(

16



%&olutionary Prototyping• The pro'lem $ith a &ague specification is that

it can 'e difficult to &erify and control(+ncertainty can cause frustration through lac2

of direction and $asted time. effort and

money(

17



%&olutionary Prototyping

18



Incremental Prototyping• The incremental approach can 'e li2ened to

4'uilding 'loc2s4 incrementing each time ane$ component is added or integrated. 'ased

on an o&erall design solution( When all of the

components are in place. the solution is

complete(

19



Incremental Prototyping• n ad&antage of this method is that the client

and-or end1users ha&e the opportunity to testthe de&eloped components and their

functionality( They also ha&e opportunities to

pro&ide feed'ac2 $hile other components are

still in de&elopment. and can thus influence

the outcome of further de&elopment(

20



Incremental Prototyping• %,ample: in a ne$ $ord processing application

a user may 'e a'le to $or2 $ith the interfaceto open and sa&e documents. 'ut may not 'e

a'le to print those documents or ma2e

changes fonts or styles 'ecause these

components ha&e yet to 'e deli&ered( The

client and-or end1users are a'le to pro&idefeed'ac2 on the components de&eloped so

far( This may influence also ho$ further

components are implemented( 21



Incremental Prototyping

22



Prototyping: Pros• /educed time and costs

• Impro&ed and increased user in&ol&ement

23



Prototyping: 6ons• +ser confusion of prototype and finished

system• *e&eloper attachment to prototype

• %,cessi&e de&elopment time of the prototype

24



/*• /* !rapid application de&elopment# is a concept

that products can 'e de&eloped faster and of higher)uality through:

– 7athering re)uirements using $or2shops or focus groups

– Prototyping and early. reiterati&e user testing of designs – The re1use of soft$are components

– rigidly paced schedule that defers design impro&ements

to the ne,t product &ersion

– Less formality in re&ie$s and other team communication

25



/*

26



/* 1 Pros• Better 8uality( By ha&ing users interact $ith e&ol&ing

prototypes the 'usiness functionality from a /* pro9ect can

often 'e much higher than that achie&ed &ia a $aterfall

model(

/is2 6ontrol( /* approach can focus in early on the 2ey ris2

factors and ad9ust to them 'ased on e&idence collected in theearly part of the process( %(g(. the comple,ity of prototyping

some of the most comple, parts of the system(

• /* reduces the de&elopment time and reusa'ility of

components help to speed up de&elopment(

• 8uic2er deli&ery

• ll functions are modularied so it is easy to $or2 $ith(

27



/* 1 6ons• ;or large pro9ects. /* requires sufficient human resources

to create the right no( of /* teams(

• /* re)uires developers and customers who are committed

to the rapid fire acti&ities necessary to get a system complete

in a much reduced time frame (If commitments lac2ing from

either mem'er. /* pro9ect $ill fail(• /* is not appropriate when technical ris is high( This

occurs $hen a ne$ application ma2es hea&y use of ne$

technology or $hen the ne$ surface re)uires high degree ofinteroperation $ith e,isting computer programs

28

Information Systems Lecture 05

Documents

Transcript of Information Systems Lecture 05