The Prototyping Methodology
By
Tad Nelson
Prepared for:
Dr. Rob Mohammad
ISAM5635
Tuesday Night
Spring 2003
Prototyping Methodology
In general prototyping is the rapid development, structuring and testing of a
working model. This working model is called a prototype. The prototype is based on
new applications in the interactive and iterative process.
Prototyping makes the
development process faster and easier. Prototyping is sometimes referred to as rapid
application design (RAD). One major benefit of prototyping is that is has brought the end
user into the application. Prototyping is much like a rough draft of a document. It still
needs to be polished, but allows you to begin solidifying ideas, correcting major errors,
and even start over without a lot of lost time. In this brief I will try to dispel some of the
myths about the problems with prototyping while articulating some of some benefits.
The one certainty that I must begin is the bottom line that prototyping has become a
mainstay in system development.
Prototyping and iterative design have a reputation for being difficult to manage.
The keys to managing a prototyping effort are becoming clear, however; they include
knowing what you want to learn from the prototype, access to rapid prototyping
techniques, and end-user involvement in development of the prototype. The prototype
will be the vehicle for developing the full requirements for the system, and its definition
will be the preliminary requirements for the system. Just as you do not need to develop
the full requirements before you build the prototype, you also should not attempt to build
the prototype without some kind of a definition of it. Defining the prototype before
building it helps users and Information Systems people think through the basic functions
of the system. It is a valuable thing to do, even if the prototype may change considerably
when the user actually begins to see its outputs. One criticism that is often made of
prototyping is that the requirements phase of a project using prototyping is too expensive,
and keeping the requirements and design phases from running into each other is too hard.
If those who are prototyping do not know what is needed for the prototype nor when they
may begin building it, they may waste time and resources.
With all that said I remain a staunch supporter of prototyping. Before I begin
explaining the benefits of prototyping I think it wise to discuss some of the pitfalls of
2
prototyping.
One of
the first
problems
with
prototypes
is
standardization.
Standardization results when the prototype is shaped by tools available rather than the
user’s needs.
Another problem is distraction, which means the prototype can be
problematic because it takes attention away from the problem to be solved. A third is
seduction; the developers getting so involved in the romance of the prototype system.
This can cause the system to come in way over budget or way behind schedule.
Rejection is another major problem. As problems present early in the development cycle
and costs associated with ideas sky rocket the project can be scraped.
These problems can be avoided if the prototyping team focuses on a few logical
questions: What are you prototyping, and why? What do you expect to learn? When do
you need it in order to affect the product? How will you know when to stop? The answers
to these questions come from users, and from nowhere else. You are prototyping a
solution to users' problems. You learn what those problems are, and you stop when you
have a proven solution.
With all the problems understood, they are quite easy to avoid. The main thing to
remember is to always keep in mind the end user. If the prototyping experience is to
remain positive it is imperative that every issue, every question, and every development
idea be examined from the perspective of the end user.
A rough summary of the steps in a developing a prototype are as follows:
1)
Investigation – having the end user identify the needs and evaluate the
feasibility of several alternatives.
2.
Analysis – to end user assists the developer with the use of the interactive
design and then tests prototypes of the system components that meet the
users needs.
3.
Design – includes extensive testing, evaluation, and modification of the
system until the end user is totally satisfied and the system is acceptable.
3
4.
Implementation – the accepted system is agreed upon and the system
documentation is prepared and the system is ready for full release.
As the steps indicate, prototyping is an iterative, interactive process that combines steps
of the traditional system development cycle (SDLC). The system is designed in a series
of interactive sessions between the end user and the system analyst. The prototype is
usually reworked several times until the end user finds it acceptable and signs off. Once
that is completed the system is turned over to the end user for operational use.
How Prototyping Works
The prototyping process starts when an idea for improving a product, whether in
terms of requirements, understanding the users, or designing an ultimate solution begins.
Proper use of prototyping can help keep the development effort focused until the solution
is well defined. The prototyping process is full of goals. The whole purpose is based on
the desire to plan, implement, measure and learn about the as-is system relative to the tobe system. The entire process is based on the desire to fill a need with a system that
brings about a solution to what ever problem.
In the plan phase, you are trying to understand your users and their needs, as well
as how you want to address those needs. Then you build. Once built the focus changes to
measuring the results of the new system against the desired results of the system. It is the
use of measuring that is the essence of evaluating the effectiveness of the prototype in
this particular system.
There can be many reasons that a prototype does not achieve its goals. Sometimes
these will be implementation issues, but more often the problem will be an incorrect or
insufficient understanding of the users or the work they need to accomplish. Again, it is
this understanding that will eventually bring us back full circle to an evaluation of how
much effort was put into understanding the needs Users bring their own preconceptions
and perceptual abilities to the new system. They use only as much of the system as they
need to, and learn only from what they use. What they learn, they learn through trial and
error. Unpredictable or inconsistent behavior in your product will distort or even destroy
4
a user's desire for product integration. And remember, this user model begins to form
before the user begins using the system built for the user.
You want to deliver the essence of the system to your users. Minimalism is a
virtue in interface design- this is the ultimate less is more category. If it doesn't
communicate currently available function or the current state of the user's data, get rid of
it. Anticipate errors, and prevent them if at all possible. The user's every thought and
gesture should be spent on the task, and never on housekeeping. And the user decides
what to do next, not the product. The user is always right.
Conclusion on Effective Prototyping
If the project team does not understand the system and define it well, the
prototyping will certainly flounder, if it does not fail. The results of the screen, report,
and function definitions should prompt the information definition, even though they can
proceed at the same time. The team members who are responsible for the definition of the
information should be persistent, thorough, and able to judge the completeness of their
results. Estimating the work to be done, planning it, scheduling it, publishing the
schedule, and adhering to it or crucial to a final successful system. After the team
conferences are finished, you may define the screens, reports, functions, and information
simultaneously, if enough persons are available. Since the number of reports and screens
and the complexity of the information may not be known until after the talkthroughs, you
may want to prepare a preliminary plan and schedule for this phase before the team
conferences begin, then modify them after they are completed.
All of this is important as we enter the implementation stage. Implementation
will involve the major question of conversion. Conversion is the process of bringing the
system on line.
The end users’ concerns about the new sydtem really need to be
respected when it comes to bringing the system in. Conversion methods can really soften
the impact the new system has on the organization.
At the end of the day prototyping is a highly successful way to implement a new
system. I do believe I have stressed the one major issue that is relevant to all analysts
5
when bringing a new system to the organization and that is “include the end-user from
the beginning to the end and it will effect the ability to have a successful crossover
exponentially.”
Resources:
1.
Norman, Donald A., The Design of Everyday Things. New York: Doubleday
Currency, 1990.
2.
Diane Wilson, Prototyping in the Software Development Cycle, 1998.
3.
Senge, Peter, The Fifth Discipline: The Art and Practice of the Learning
Organization, New York: Currency Doubleday, 1994.
4.
Lantz, Kenneth, The Prototyping Methodology, 1987.
6