Concepts:
Prototypes
Topics
Prototypes are used in a directed way to reduce risk. Prototypes can reduce
uncertainty surrounding:
- The business viability of a product being developed
- The stability or performance of key technology
- Project commitment or funding: building a small proof-of-concept prototype
- The understanding of requirements
- The look and feel of the product, its usability.
A prototype can help to build support for the product by showing something
concrete and executable to users, customers and managers.
The nature and goal of the prototype must remain clear, however, throughout
its lifetime. If you don't intend to evolve the prototype into the real product,
don't suddenly assume that because the prototype works it should become the
final product. An exploratory, behavioral prototype, intended to very rapidly
try out some user-interface, rarely evolves into a strong, resilient product.
You can view prototypes in two ways: what they explore; and how they evolve
or what is their outcome.
In the context of the first view - what they explore - there are two main
kinds of prototypes:
- A behavioral prototype, which focuses on exploring
specific behavior of the system.
- A structural prototype, which explores some architectural
or technological concerns.
In the context of the second view - their outcome - there are also two kinds
of prototypes:
- An exploratory prototype, which is thrown away when done,
also called a throw-away prototype.
- An evolutionary prototype, which gradually evolves to
become the real system.
An exploratory prototype is designed to be like a small
"experiment" to test some key assumption about the project, either
functionality or technology or both. It might be something as small as a few
hundred lines of code, created to test the performance of a key software or
hardware component. Or it may be a way of clarifying requirements, a small
prototype developed to see if the developer understands a particular behavioral
or technical requirement.
Exploratory prototypes tend to be intentionally "throw-away", and
testing of them tends to be informal. The design of exploratory prototypes tends
to be very informal, and also tends to be the work of one or two developers at
most.
Evolutionary prototypes, as their name implies, evolve from one iteration to
the next. While not initially production quality, their code tends to be
reworked as the product evolves. In order to keep rework manageable, they tend
to be more formally designed and somewhat formally tested even in the early
stages. As the product evolves, testing becomes formalized, as usually does
design.
Behavioral prototypes tend to be exploratory prototypes; they do not try to
reproduce the architecture of the system to be developed but instead focus on
what the system will do as seen by the users (the "skin"). Frequently,
this kind of prototype is "quick and dirty," not
built to project standards. For example, Visual Basic may be used as the
prototyping language, while C++ is intended for the development project.
Exploratory prototypes are temporary, are done with minimal effort, and are
thrown away once they have served their purpose.
Structural prototypes tend to be evolutionary prototypes; they are more
likely to use the infrastructure of the ultimate system, (the
"bones"), and are more likely to evolve into becoming the real system.
If the prototype is done using the "production" language and tool set,
there is the added advantage of being able to test the development environment
and let some of the personnel get familiar with new tools and procedures.
Copyright
© 1987 - 2001 Rational Software Corporation
| 
Disciplines >
Project Management >
Concepts >
