The Prototyping Approach
The first step in the waterfall model is the gathering and analysis of customers' requirements. When the requirements are defined, the design and development work begins. The model assumes that requirements are known, and that once requirements are defined, they will not change or any change will be insignificant. This may well be the case for system development in which the system's purpose and architecture are thoroughly investigated. However, if requirements change significantly between the time the system's specifications are finalized and when the product's development is complete, the waterfall may not be the best model to deal with the resulting problems. Sometimes the requirements are not even known. In the past, various software process models have been proposed to deal with customer feedback on the product to ensure that it satisfied the requirements. Each of these models provides some form of prototyping, of either a part or all of the system. Some of them build prototypes to be thrown away; others evolve the prototype over time, based on customer needs.
A prototype is a partial implementation of the product expressed either logically or physically with all external interfaces presented. The potential customers use the prototype and provide feedback to the development team before full-scale development begins. Seeing is believing , and that is really what prototyping intends to achieve. By using this approach, the customers and the development team can clarify requirements and their interpretation.
As Figure 2.2 shows, the prototyping approach usually involves the following steps:
- Gather and analyze requirements.
- Do a quick design.
- Build a prototype.
- Customers evaluate the prototype.
- Refine the design and prototype.
- If customers are not satisfied with the prototype, loop back to step 5.
- If customers are satisfied, begin full-scale product development.
Figure 2.2. The Prototyping Approach
The critical factor for success of the prototyping approach is quick turnaround in designing and building the prototypes. Several technologies can be used to achieve such an objective. Reusable software parts could make the design and implementation of prototypes easier. Formal specification languages could facilitate the generation of executable code (e.g., the Z notation and the Input/Output Requirements Language (IORL) (Smith and Wood, 1989; Wing, 1990)). Fourth-generation lan-guages and technologies could be extremely useful for prototyping in the graphical user interface (GUI) domain. These technologies are still emerging, however, and are used in varying degrees depending on the specific characteristics of the projects.
The prototyping approach is most applicable to small tasks or at the subsystem level. Prototyping a complete system is difficult. Another difficulty with this approach is knowing when to stop iterating. In practice, the method of time boxing is being used. This method involves setting arbitrary time limits (e.g., three weeks) for each activity in the iteration cycle and for the entire iteration and then assessing progress at these checkpoints.
Rapid Throwaway Prototyping
The rapid throwaway prototyping approach of software development, made popular by Gomaa and Scott (1981), is now used widely in the industry, especially in application development. It is usually used with high-risk items or with parts of the system that the development team does not understand thoroughly. In this approach, "quick and dirty" prototypes are built, verified with customers, and thrown away until a satisfactory prototype is reached, at which time full-scale development begins.
Evolutionary Prototyping
In the evolutionary prototyping approach, a prototype is built based on some known requirements and understanding. The prototype is then refined and evolved instead of thrown away. Whereas throwaway prototypes are usually used with the aspects of the system that are poorly understood, evolutionary prototypes are likely to be used with aspects of the system that are well understood and thus build on the development team's strengths. These prototypes are also based on prioritized requirements, sometimes referred to as " chunking " in application development (Hough, 1993). For complex applications, it is not reasonable or economical to expect the prototypes to be developed and thrown away rapidly .