Prototypes help you gather requirements and demonstrate architecture long before you've locked into actual application code. They also ease clients' anxieties about large projects, and they can help some clients make decisions and commitments. Prototyping mentalities
As with everything, there are various schools of thought on prototyping. In some cases, lightweight programming or scripting languages can quickly demonstrate a project's architecture, functionality, and interfaces. This kind of pseudo-solution prototyping proves design viability for complicated, long-term projects, and it can be helpful as a "go/no go" indicator for clients. Framework prototyping uses mock-ups to represent functionality in the same technology as the project solution, with dialogue boxes and screens serving as holders for actual code. This kind of prototype is useful for nailing down requirements or getting a first look at an unfamiliar solution. Reiterative prototype development methodology is another common approach. The prototype is refined through various stages until it eventually evolves into the desired product. This can be a failsafe method for rapid development, or it can provide planned stopping points in a staged rollout. Each prototype represents vastly different goals and requires varying degrees of investment, and each affects the development methodology in different ways. It's up to the architect, business driver, project manager, and sometimes even the client to decide if a prototype is necessary and what kind will be used. Deciding on a prototype style
Prototyping is an exercise in risk management and development facilitation, and it minimises the chances of producing the wrong functionality or an illogical design. Several factors must be considered when deciding if you should propose a prototype, and if so, which route to follow. Has your team previously developed a similar solution?
If not, have your "A" team create a framework prototype to demonstrate the solution. Using this as the first phase in a project will uncover questions that would otherwise show up down the line. Does your client have a problem making decisions?
If so, you can use a framework prototype to show your client what decisions need to be made, or use a reiterative prototype methodology if you suspect frequent, sweeping changes will affect your development process. Do you have a large development team?
If so, use a pseudo-solution prototype or a framework prototype as a map for ongoing development. This facilitates development management by going beyond specifications to provide an actual model of the desired outcome. Do you have "too many cooks"?
Choosing one or two people to develop a prototype of any kind will create a focused definition of how the application should look upon completion. It provides an outline that should be followed during development, and it can help keep everyone on the same path. Is the client afraid to commit to a very large development effort?
Propose a pseudo-solution prototype. Using a scripting language allows you to quickly produce a lightweight solution that can represent the whole application, but without all the bells and whistles. Often a client will agree to pay for such a model before committing to the development of a large and expensive application. Do you need to show working functionality during development?
A reiterative development process creates stopping points that show progress. A variety of formal methodologies support this style of development. Reiterative prototype development focuses on creating an entire representation of the solution and adding layers of refinement for each release. Complete system testing is performed at each stopping point, so the system is fully functional at each stage. As you can see, many development situations warrant a prototype. However, once you've decided to move forward with a model, there are some "gotchas" to consider.