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.
- A preliminary project plan is developed
- An partial high-level paper model is created
- The model is source for a partial requirements specification
- A prototype is built with basic and critical attributes
- The designer builds
- The designer demonstrates the prototype; the user evaluates for problems and suggests improve
- This loop continues until the user is satisfied.
The final product is built as separate prototypes. At the end the separate prototypes are merged in an overall design.
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
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.