information systems lecture 05
TRANSCRIPT
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
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 2/28
PROTOTYPING
2
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 3/28
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!
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 4/28
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.
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 5/28
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.
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 6/28
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.
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 7/28
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.
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 8/28
The Prototyping Model
Build Prototype
Gather
requirements
Design
Prototype Evaluate Prototype
Refine requirements
CUSTOMER
APPROVAL
Implement
Test
Maintenance
FEEDBACK
Design
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 9/28
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!
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 10/28
Types of Prototypes• Thro$a$ay
• %&olutionary
• Incremental
10
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 11/28
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
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 12/28
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
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 13/28
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
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 14/28
Thro$a$ay Prototyping
14
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 15/28
%&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
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 16/28
%&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
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 17/28
%&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
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 18/28
%&olutionary Prototyping
18
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 19/28
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
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 20/28
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
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 21/28
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
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 22/28
Incremental Prototyping
22
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 23/28
Prototyping: Pros• /educed time and costs
• Impro&ed and increased user in&ol&ement
23
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 24/28
Prototyping: 6ons• +ser confusion of prototype and finished
system• *e&eloper attachment to prototype
• %,cessi&e de&elopment time of the prototype
24
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 25/28
/*• /* !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
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 26/28
/*
26
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 27/28
/* 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
8/9/2019 Information Systems Lecture 05
http://slidepdf.com/reader/full/information-systems-lecture-05 28/28
/* 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