Prototypes come in a number of different types, each with its own set of strengths and weaknesses. Hoffer (2007) identifies two types of prototyping: evolutionary and throwaway. McConnell (1993) points out that evolutionary prototyping is not the same as evolutionary delivery, though. Further, he states that they are differentiated based upon their goals. With evolutionary prototyping, the goals are more exploratory. With evolutionary delivery, the goal less exploratory. That is, its goal is to deliver an acceptable, functional system.
With the evolutionary form, a prototype is developed in small increments. With each increment, the prototype is developed further. As the prototype is developed, the prototype may be moved into production, either as a full system or as a component of a larger one. Rapid application development (RAD) uses the evolutionary development process as one of its core components (McConnell, 1996).
Another hallmark of evolutionary prototyping is that the customer is a key player in the development of the prototype, throughout the process. That is the customer is continuously engaged in the prototype development process, which provides an ever-present feedback loop. This feedback loop assists the developer in the creation of an accurate model. Moreover, the customer's continuous involvement helps increase the customer satisfaction with the final product.
In terms of analysis, the feedback loop ensures the business requirements are identified earlier rather than later. This early identification of important business requirements translates into greater project cost savings. Why is this so? It is more costly to make changes in a project in later phases then it is to do so in earlier phases. It is helpful to think of an example beyond the software world. If the project team is building a house and determines (after the construction is complete) that the house has been built 5 feet too far into the neighbor's yard, then the costs to fix this problem will be much higher than had they fixed the problem at the time of surveying the land. The same concept holds true in information systems development. Therefore, it is of the utmost importance to identify business requirements clearly during the analysis phase.
The other type of prototype that is identified by Hoffer (2007) is the throwaway prototype. In throwaway prototyping, the prototype is not used in production. The prototype is merely used to identify requirements or to identify how a prototype will function in environment. After the prototype has been used, it will be discarded. Even tell the prototype will be discarded, it can still provide great value and analysis. That is, it is still a valuable tool that is used to identify business requirements. Certainly, some grass-roots business requirements need to be identified up front; however, the process in creating this prototype can be used to confirm those early requirements while still unearthing new ones later on. Additionally, the customer is closely involved in the development of the throwaway prototype, just as in the case of the evolutionary development process. Furthermore, the customer is aware that the throwaway prototype will be discarded after use.
Sauter (2008) identifies types as exploratory, experimental, or evolutionary. For the exploratory type, the prototyping process is used to identify business requirements early on. That is, the prototyping process is used as a tool to help clarify business requirements. The experimental type is as a trial product. That is, the prototype is developed and used to determine if the venture is feasible. Finally, the evolutionary type is used to develop incremental changes that adjust according to changing business requirements.