Concepts: Prototypes

Topics

How to Use

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.

Types of Prototypes

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.

Exploratory Prototypes

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

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

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

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.

Rational Unified Process 5.1 (build 43)