With Throwaway Prototyping, code is developed to explore factors critical to the system's success, and then that code is thrown away. The prototyping implementation uses programming languages or development practices or both that are much faster than the target language and practices. The user interface is prototyped far more commonly than any other part of the system, but other parts of some systems can also benefit from being prototyped. When used as a requirements-specification aid, the Throwaway Prototyping practice can accelerate projects based on traditional lifecycle models, such as DoD projects. It can be initiated at either a management or technical level.
Efficacy
Potential reduction from nominal schedule: | Fair |
Improvement in progress visibility: | None |
Effect on schedule risk: | Decreased Risk |
Chance of first-time success: | Excellent |
Chance of long-term success: | Excellent |
Major Risks
Keeping a throwaway prototype
Inefficient use of prototyping time
Unrealistic schedule and budget expectations
Major Interactions and Trade-Offs
None
The Throwaway Prototyping practice derives its development-speed benefit from the fact that it is often possible to explore individual requirements, design, and implementation options using languages and practices that allow for more rapid development than the ultimate implementation language and practices do. Here are some examples:
You need to compare approximately how long it will take to store and retrieve 10,000 records using several different DBMSs, so you write throwaway code to exercise the DBMSs and to compare their performance.
Your end-users can't decide between two user-interface styles, so you mock up two user interfaces using interface-building tools and give the users a "live" demo without ever writing a line of code.
You want to check the feasibility of communicating with another application before basing your future design decisions on that ability, so you write test code to verify that such communication is possible. The test code contains no error checking and doesn't handle any exceptions, and you throw it away as soon as you've verified that you can communicate the way you need to.
You can employ Throwaway Prototyping at any time in a project—to clarify requirements, to decide an architectural issue, to compare design or implementation options, or to test a performance optimization.
Throwaway Prototyping can be used by any of the project's personnel. Individual project participants can realize some benefit by prototyping risky areas within their individual areas of responsibility. Here is a list of areas that can benefit from being prototyped and suggestions about how to develop prototypes in those areas cheaply:
CROSS-REFERENCE
For more on user-interface prototyping, see Chapter 42, User-Interface Prototyping."
User interface—Prototype using a prototyping tool or visual programming language, or build a Hollywood facade in the target programming language.
Report formats—Prototype using a word processor or report formatting tool.
Graph formats—Prototype using a drawing tool or graphics library.
Database organization—Prototype using a database design language, 4GL, or CASE tool.
Database performance—Prototype using a database design language, 4GL, or CASE tool.
Accuracy and implementation of complex calculations—Prototype using a spreadsheet or math-oriented language such as APL.
Time-critical parts of real-time systems—Prototype using a small test program in the target programming language.
Performance of interactive systems—Prototype using a small test program in the target programming language.
Feasibility of parts of the system that are pushing the state-of-the-art or with which the development staff has no experience—Prototype using a visual programming language, small test program in the target programming language, or math-oriented language—whatever is appropriate.
As you can see, it can be profitable to prototype many areas of a program. However, if you understand your program well, don't prototype just for the sake of prototyping.