Also called close-ended prototyping. Throwaway or Rapid Prototyping refers to the creation of a model that will eventually be discarded rather than becoming part of the final delivered software. After preliminary requirements gathering is accomplished, a simple working model of the system is constructed to visually show the users what their requirements may look like when they are implemented into a finished system.

The most obvious reason for using Throwaway Prototyping is that it can be done quickly. If the users can get quick feedback on their requirements, they may be able to refine them early in the development of the software. Making changes early in the development lifecycle is extremely cost effective since there is nothing at that point to redo. If a project is changed after a considerable work has been done then small changes could require large efforts to implement since software systems have many dependencies. Speed is crucial in implementing a throwaway prototype, since with a limited budget of time and money little can be expended on a prototype that will be discarded.Another strength of Throwaway Prototyping is its ability to construct interfaces that the users can test. The user interface is what the user sees as the system, and by seeing it in front of them, it is much easier to grasp how the system will work.

One disadvantage with throw-away prototyping is that developers may be pressurised by the users to deliver it as a final system! Another issue is that all the man-hours of putting together the throw away prototypes are lost unlike the evolutionary approach. But the benefits may outweigh the disadvantages.

One method of creating a low fidelity Throwaway Prototype is Paper Prototyping. The prototype is implemented using paper and pencil, and thus mimics the function of the actual product, but does not look at all like it. Another method to easily build high fidelity Throwaway Prototypes is to use aGUI Builder and create a click dummy, a prototype that looks like the goal system, but does not provide any functionality.

Steps:

1. A preliminary project plan is developed
2. An partial high-level paper model is created
3. The model is source for a partial requirements specification
4. A prototype is built with basic and critical attributes
5. The designer builds
   –the database
   –user interface
   –algorithmic functions
   –algorithmic functions
6. The designer demonstrates the prototype; the user evaluates for problems and suggests improve
7. This loop continues until the user is satisfied.

Evolutionary Prototyping (also known as breadboardprototyping) is quite different from Throwaway Prototyping. The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and constantly refine it. “The reason for this is that the Evolutionary prototype, when built, forms the heart of the new system, and the improvements and further requirements will be built.When developing a system using Evolutionary Prototyping, the system is continually refined and rebuilt.Evolutionary Prototypes have an advantage over Throwaway Prototypes in that they are functional systems. Although they may not have all the features the users have planned, they may be used on an interim basis until the final system is delivered.In Evolutionary Prototyping, developers can focus themselves to develop parts of the system that they understand instead of working on developing a whole system.Incremental prototyping

The final product is built as separate prototypes. At the end the separate prototypes are merged in an overall design.

Extreme prototyping

Extreme Prototyping is an architectural process for developing applications, especially web applications, in terms of increasingly functional prototypes. At a high level, it breaks down web development into three distinct phases. The first phase is the static prototype, consisting of HTML pages and possibly a logical data model supporting those pages. The second phase is a coding process in your chosen web framework whereby the screens are fully functional using a simulated services layer. The third phase is where the services are implemented. The process is called Extreme Prototyping to draw attention to the second phase of the process, where a fully-functional UI is developed with very little regard to the services other than their contract. This deliverable, much like the static HTML prototype, can be considered a prototype, albeit a dynamic one.

By using Extreme Prototyping, you will be able to substantially shorten the requirement cycle and also the development cycle. Extreme Prototyping will allow you to consistently estimate and deliver your projects faster, cheaper, and better. Extreme Prototyping achieves these results primarily by breaking down the dependencies between multiple teams and thereby allowing parallel development. Extreme Prototyping continues to put extra emphasis on executable deliverables.

The Three Bricks of Extreme Prototyping

If you imagine system development as a set of concrete deliverables, you can imagine an “Extreme Prototype” to consist of three bricks, as depicted in Figure

The first

brick is the Static Prototype. Based on this prototype, the UI brick and the Service brick can be developed fairly independently and brought together toward the end of the project for an integration alignment. The service contracts (or blades) should allow for a perfect alignment in any typed language.

Source:

• http://en.wikipedia.org/wiki/Software_prototyping
• http://www.teach-ict.com/as_a2_ict_new/ocr/A2_G063/331_systems_cycle/prototyping_RAD/miniweb/pg4.htm
• http://onjava.com/onjava/2006/11/15/reshaping-it-project-delivery-through-extreme-prototyping.html