Working with Prototypes

Prototypes are best undertaken as self-contained units of work with clearly defined objectives. Team sizes should be small, typically numbering no more than two or three people.

As prototypes are not destined for a formal release, many of the necessary standards and procedures that cradle production-level software are not applicable, much to the delight of the development team. This level of freedom makes for an intense development environment that many teams appreciate. Productivity tends to be high as engineers are able to focus on a discrete piece of work without the burden of the usual checks and controls endemic to larger projects.

Tip

Always volunteer for work on prototypes and proof-of-concepts.

Despite the benefits, the development of a prototype can sometimes appear as an unnecessary diversion when the pressure is on to deliver the real thing. For projects where time is at a premium, management often prefers to have staff focus on production code rather than diverting resources into the construction of prototypes. However, although the prototype requires upfront effort at the start of the project, its ability to drive out risk, clarify requirements, and validate the architecture enables significant time savings to be made throughout the project. Thus, by using prototyping to identify potential problems at the start of the project, these problems can be addressed early in the process before they snowball into major issues at later stages of the development.

Prototyping therefore offers a diverse range of benefits. Consequently, different types of prototype have evolved depending on their intended use.

Prototyping Approaches and Types

Prototyping is an important concept of the IBM Rational Unified Process, which makes extensive use of the technique. The Rational Process defines several factors to consider when making use of prototyping as part of a development project [Kruchten, 2003]. The first of these factors is how prototypes fit into the overall project lifecycle. Here, there are two options:

• Throwaway, where the prototype is discarded once its objectives have been met

• Evolutionary, where the prototype is continually evolved into a production-level system

The second factor is the intended purpose of the prototype, which gives the type of the prototype. Again, there are two available options:

• Behavioral, which demonstrates system behavior and helps capture user requirements

• Structural, which validates areas of the system's architecture

Over the next sections, we look at the purposes and needs of each of the different types of prototype as well as the tools and environment necessary to support their development.

Throwaway Prototyping

As the name implies, the throwaway prototype, also known as an exploratory prototype, does not have long for this world. Its primary objectives are to validate a solution or to clarify a problem domain. Validation could be the performance of a part of the architecture and clarification could be of the look-and-feel of the user-interface.

Regardless of the purpose of the throwaway, it will be discarded once its objectives have been realized. Because the code from which it is built is not intended to be production level, the throwaway prototype can be assembled at great speed, using whatever tools, languages, and methods prove most expedient.

Evolutionary Prototyping

The evolutionary prototype has far loftier aspirations than does its throwaway counterpart. Here the prototype evolves throughout the life of the project, either gradually or rapidly, into the final system. In this case, the prototype is an integral part of the project lifecycle whereby the prototype is modified incrementally in response to customer feedback through a process of ongoing refactoring. This approach is closely associated with the practice of timebox development.

Since the evolutionary prototype will transform into the eventual system, greater discipline and control is necessary during its development. Unlike the throwaway, essential disciplines such as code style, code reviews, testing, and design documentation must all feature prominently in the prototype's construction.

Behavioral Prototypes

Behavioral prototypes, as the name implies, are concerned with what the system does, not how it does it. Typically, behavioral prototypes are built as throwaways.

The behavioral prototype usually targets the user interface and provides a mechanism for discussing ideas and requirements with the customer. Feedback captured from the customer needs to be quickly reflected in the prototype, thereby providing for the rapid transformation of ideas into solid requirements. In achieving this aim, the prototype needs to be constructed using suitable high-level tools and languages in order that the customer can see a fast turnaround of ideas into demonstrable functionality.

Structural Prototypes

The structural prototype's primary concern is proving the architecture of the system during the early stages of the project. Areas of the architecture that are identified as high risk can be proven using a small prototype before a full-scale development effort is commenced against the architecture.

Unlike behavioral prototypes, structural prototypes tend to be evolutionary instead of throwaway. Having proven a slice of the architecture, the code, rather than being discarded, is more likely to be evolved through refactoring until it is of a production level.

Choosing Between Throwaway and Evolutionary

Throwaway and evolutionary prototypes are not incompatible on a project, as they each target different aspects of the project. You could therefore expect to use a behavioral prototype for establishing the system requirements by modeling the user interface and an evolutionary prototype to incrementally advance the architecture. Often, the question is not which prototyping approach to adopt but how best to combine the two.

Many factors impact the decision as to which approach is right for your project. The overheads of the throwaway may not be economically viable for a small project. If the project requirements are well defined, then an evolutionary prototype is probably the best option. If they are likely to be subject to constant change, then a throwaway prototype is the preferred choice in support of a requirements gathering exercise.

It is important that the type of approach be selected prior to commencing work on the final system. Starting with a throwaway and then attempting to convert to an evolutionary approach is unlikely to be successful. Likewise, the converse will result in expensive disposable code. The approach to the prototype governs the way in which the prototype is developed. Tighter quality control is required for evolutionary prototypes. Moreover, evolutionary prototypes have to be written in the language in which the final system will be implemented. In our case, this is Java. However, for the purposes of a throwaway prototype, a scripting language such as Perl, Python, or Tcl may be more applicable.

Warning

Ensure the final system is capable of delivering the same functionality as the prototype.

Finally, if you are going to make use of a specialized prototyping language or toolkit to help build the prototype at high speed, be careful to ensure you are able to reproduce the full functionality demonstrated to the customer in the final system. Even slight differences in the look and feel of the user interface can result in an unhappy customer.