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
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.