Evolutionary Prototyping is a lifecycle model in which the system is developed in increments so that it can readily be modified in response to end-user and customer feedback. Most evolutionary-prototyping efforts begin by prototyping the user interface and then evolving the completed system from that, but prototyping can start with any high-risk area. Evolutionary Prototyping is not the same as Throwaway Prototyping, and making the right choice about whether to develop an evolutionary prototype or a throwaway prototype is one key to success. Other keys to success include using experienced developers, managing schedule and budget expectations, and managing the prototyping activity itself.
Efficacy
Potential reduction from nominal schedule: | Excellent |
Improvement in progress visibility: | Excellent |
Effect on schedule risk: | Increased Risk |
Chance of first-time success: | Very Good |
Chance of long-term success: | Excellent |
Major Risks
Unrealistic schedule and budget expectations
Inefficient use of prototyping time
Unrealistic performance expectations
Poor design
Poor maintainability
Major Interactions and Trade-Offs
Evolutionary Prototyping is a development approach in which you develop selected parts of a system first and then evolve the rest of the system from those parts. Unlike other kinds of prototyping, in Evolutionary Prototyping you don't discard the prototyping code; you evolve it into the code that you ultimately deliver. Figure 21-1 shows how this works.
Figure 21-1. Evolutionary Prototyping model. With Evolutionary Prototyping, you start by designing and implementing the most prominent parts of the program in a prototype. You then continue adding to and refining the prototype until you're done. The prototype eventually evolves into the software that you release.
Evolutionary Prototyping supports rapid development by addressing risks early. You start development with the riskiest areas of your system. If you can overcome the obstacles, you can evolve the rest of the system from the prototype. If you can't, you can cancel the project without having spent any more money than necessary to discover that the obstacles were insurmountable.
Evolutionary Prototyping is an exploratory activity that you use when you don't know at the outset exactly what you need to build. Because the areas of uncertainty in a development effort vary from one project to another, your first step is to identify the part of the system to use as a starting point. The two main options are to start with the most visible parts or the riskiest parts. The user interface is often both the most visible and the riskiest part, so it is often the obvious place to start.
After you've built the first part of the system, you demonstrate it and then continue to develop the prototype based on the feedback you receive. If your prototyping effort is customer-oriented, you'll continue to solicit feedback from the customer and to refine the user interface until everyone agrees that the prototype is good enough. Then you develop the rest of the system using the prototype's design and code as a foundation.
If your prototyping effort is technically oriented, you might develop some other part of the system first, such as the database. The feedback you'll look for in that case won't necessarily come from the customer. Your mission might be to benchmark database size or performance with a realistic number of end-users. But the general prototyping pattern is the same. You continue to look for feedback and to refine your prototype until everyone agrees that the prototype is good enough, and then you complete the system. The same principle applies to prototyping of user interfaces, complex calculations, interactive performance, real-time timing constraints, data sizing, and proof-of-concept aspects of leading-edge systems.
You can use Evolutionary Prototyping to greater or lesser degrees on most kinds of projects. It is probably best suited to business systems in which developers can have frequent, informal interactions with end-users. But it is also well suited to commercial, shrink-wrap, and systems projects as long as you can get end-users involved. The user interaction for these kinds of projects will generally need to be more structured and formal.