IS2201/IS2261 – Information Systems Development
1 Prototyping
This lecture will examine the role of prototyping in Systems Development. It will
describe what prototyping is, why it is used and how it may be applied in Systems
Development Projects. It will establish approaches to evaluating a Prototype and
finally it will discuss criteria for successful use of prototyping in a Systems
Development Project.
1.1 What is a Prototype – and why would we need one?
Prototype can be described as:
“A working model of (parts of) an information system, which emphasizes
specific aspects of that system.”
(Vonk, 1990)
A prototype is a model of a system.
It is a model with a specific purpose (ref). This may be:

To gain a better understanding of the user’s requirements

To gain a better understanding of development technologies

To allow the customer to explore possibilities

To investigate the feasibility of a development project
It does not necessarily model the whole system. It is a means of “learning by doing”.
Thus, according to Law and Longworth (1987), the main aims of a Prototype are to:

Resolve uncertainty through use

Learn and evaluate before committing large sums of money
Given its purpose, it becomes clear that, if we are going to build a prototype, then it
must be done quickly (hence the term “Rapid Prototyping”).
Therefore the key requirements of a prototyping approach are:

Speed of construction

Speed of acquisition of user feedback

Speed of modification
The growth in popularity of prototyping may be viewed as a response to problems of
conventional development, such as:
©

Success of development relying on a “final, complete, consistent and
correct set of requirements” (Boar, 1984)

In the development of large systems, the long gap between specification
and implementation. (Skidmore and Wroe, 1988)
K. Miller & M. Stanton
Page 1 of 7
IS2201/IS2261 – Information Systems Development
1.2 What Type of Prototype?
According to Milller, (2006) there are many ways of classifying prototypes. However
the most common is stated as being “how the prototype is used”.
Such a classification gives us two basic types:

Requirements Prototypes

Evolutionary Prototypes
1.2.1 Requirements Prototypes
Here the prototype is used to determine some aspect of the requirements of the
system, and it is then discarded. These are more commonly known as “throw-away”
prototypes.
1.2.2 Evolutionary Prototypes
Here the prototype is continually refined until it evolves into the operational system.
It may be that some parts of the system are re-designed and re-coded using a more
formal approach.
These are also known as Incremental Prototypes.
1.2.3 Other Classifications (refs)
Other ways of classifying prototypes include classification by aspect being modelled
(e.g. performance, usability) or by the phase in the development lifecycle in which
they are used (e.g. Feasibility, design, etc.).
1.3 The Prototyping Process
According to Miller, (2006), there have been many suggestions over the years as to
how prototyping should be carried out. However, the precise approach should be
determined by the purpose of the prototype as described in Section 1.1.
Miller (2006) describes a basic model
identified by Davis and Olson (1985) as
shown in Figure 1.
1
Identify users’ basic information
requirements
Step 3 must incorporate some evaluation
of the prototyping process and product and
will result in a decision on whether to carry
out further prototyping.
2
Develop the initial prototype
Steps 3 and 4 are iterative. The number of
iterations and what is done in them is
determined by the purpose of the
prototype.
Key Characteristics:
©

Iterative Process

Involvement of End Users

Communication and Learning

Incorporates evaluation
K. Miller & M. Stanton
3
Use prototype to refine users’
requirements
4
Revise and enhance prototype
Figure 1 - General Prototyping Process
(Davis and Olsen, 1985)
Page 2 of 7
IS2201/IS2261 – Information Systems Development
1.4 Prototyping and the SDLC
Section 1.1 established that prototyping can be used for a number of purposes.
Clearly the approach described by Davis and Olson (1985) stresses its use as a
requirements definition tool. This view is supported by Vonk (1987) and is shown in
Figure 2.
Design
Project
Initiation
Requirements
Definition
Construction
Conventional Development
Upgrade
Prototyping
Activity is
carried out here
Evolutionary Development
Figure 2 - Alternative courses of action after Prototyping, adapted from (Vonk, 1990)
When prototyping is used as an aid to Requirements Definition, there are two
possible courses of action open to the developer.

Requirements can be “recovered” from the prototype, and then
conventional design and construction can take place.

Upgrade the Prototype so that it becomes the final system (i.e.
Evolutionary Prototyping).
There are alternative approaches that incorporate more structure (e.g. RAD), more
design/testing (Pressman, 1987), or recovery of design from code (Structured Rapid
Prototyping).
1.5 Prototype Evaluation
The purpose of evaluation is to determine if the prototype has satisfied its intended
purpose. If the purpose was to help with requirements definition, then the evaluation
should determine whether or not the development can now proceed to the design
and construction phases (i.e. has the prototype given us a clear understanding of the
requirements of the system).
The outcome of this evaluation may be that:

The prototype is not sufficient to define requirements – so further
prototyping is necessary.

The requirements are now sufficiently understood – no further prototyping
is necessary and conventional development can now continue.
Vonk (1990) suggests that the prototyping phase should not require more than 5
iterations.
©
K. Miller & M. Stanton
Page 3 of 7
IS2201/IS2261 – Information Systems Development
1.5.1 Evaluation Activities
Evaluation may be broken down into 4 activities:
1. Preparation
Careful preparation of the demonstration and subsequent use of the prototype is
essential for evaluation to be successful. What are the goals of the demo? Draw
up a checklist of areas of uncertainty.
2. Demonstration of the Prototype
The demonstration will work through a scenario of the intended use of the
system. Criticisms of the system should be noted (not defended). A professional
well structured demonstration is required.
3. Using the Prototype
The users are given a chance to use the prototype and form a better opinion of it.
This will enable the users to concentrate more of the areas of special interest
generated by the demonstration.
4. Discussion of Comments
Discussion is carried out separately form demonstration and use. It concentrates
on the checklist of uncertainties. An outline of the next phase of prototyping is
developed, although it may also be decided that prototyping is finished.
The evaluation needs to:

Focus on key requirements issues.

Incorporate full user involvement.

Have clear exit criteria for the prototyping activity.
The evaluation process may be more, or less, formal, but its success requires that:

The roles of participants be clearly defined

The participants are all familiar with the criteria for evaluation

The Evaluation process is built into the project plan
1.6 Strengths and Weaknesses
1.6.1 Weaknesses
©

Prototyping introduces a certain amount of process uncertainty. Are we
going to prototype, and if so, what is its purpose.

It is not always easy to plan prototyping. How many iterations? How long
will each take?

Prototypes may look different to the final delivered system – especially if a
different development environment is used (which often requires
additional effort).
K. Miller & M. Stanton
Page 4 of 7
IS2201/IS2261 – Information Systems Development

Care needs to be taken with Evolutionary prototyping. Poor design and
unstable code are common problems. Also there may be a lack of
documentation.

An early prototype can raise user’s expectations of early delivery

There is a requirement for a large commitment from users. They may not
be prepared for this and may not be able to support it.
1.6.2 Strengths

Clear validation of user requirements

User involvement gives more sense of ownership.

Exploratory programming and learning help motivate the development
team

Early deliverables can help maintain a high level of motivation within the
development team and with the users.

Reduces the risks associated with inadequate understanding of
requirements
1.6.3 Critical Success Factors
Law and Longworth (1987) have identified the following as being critical to the
success of prototyping:

A receptive attitude to the process amongst users, developers and
managers

Software tools that allow fast and easy development and modification of
the prototypes

Use of a prototyping method
Additional success factors are strong project management and a high standard of
communication skills amongst both the users and the development team.
1.7 Related Methods
The success of prototyping over the years has led to a number of approaches for
which prototyping is central. These include Rapid Application Development (RAD)
(ref), DSDM (ref), and Extreme Programming (ref).
©
K. Miller & M. Stanton
Page 5 of 7
IS2201/IS2261 – Information Systems Development
2 Questions
1.
A prototyping approach is to be used as part of a software development
project. What are the strengths and weaknesses of the approach?
2. What might be the characteristics of a project for which you would consider
using a prototype?
3. You are about to embark on a systems development project. The system is
for a small Library lending books, DVD’s and Computer Games. The system
needs to be developed in a short space of time (around 10 weeks).
Considering the type of system, the technology you will use, and the
timescale, what criteria would you use to determine if prototype should be
included as part of the SDLC.
4. The evaluation cycle as discussed here refers to the use of prototyping as a
means of discovering requirements. How might it differ if prototyping is,
instead, being used to understand a new technology?
5. Reconsider the evaluation cycle again where prototyping is used to allow
customers to explore the possibilities of a development project? What
changes might be made to each stage?
6. Reconsider the evaluation cycle again where prototyping is used to
investigate the feasibility of a project? What changes might be made to each
stage?
7. Section 1.1 describes some of the more common development problems that
can be addressed by prototyping. Identify and describe some more.
8. Under what conditions would it not be necessary to use prototyping during
systems development?
9. Under what conditions will a prototyping approach almost certainly fail?
©
K. Miller & M. Stanton
Page 6 of 7
IS2201/IS2261 – Information Systems Development
3 References
Boar, B. H., Application Prototyping, Wiley, 1984.
Davis, G. B. and M. H. Olson, Management Information Systems: Conceptual
Foundations, Structure, and Development, McGraw-Hill, 1985.
Law, D. and G. Longworth, Systems Development Strategies, NCC Publications,
1987.
Miller, K., “Prototyping”, In: IS2201/IS2261 Lecture Notes, DOCM, 2006.
Pressman, R. S., Software Engineering: a Practitioner’s Approach (2nd Edition),
Prentice Hall, 1987
Skidmore, S. and B. Wroe, Introducing Systems Analysis, NCC Publications, 1988.
Vonk, R. Prototyping: The Effective use of CASE Technology, Prentice Hall, 1990.
©
K. Miller & M. Stanton
Page 7 of 7