Editing Software prototyping (section)

==Types==
Software prototyping has many variants. However, all of the methods are in some way based on two major forms of prototyping: throwaway prototyping and evolutionary prototyping.

===Throwaway prototyping===
Also called close-ended prototyping. Throwaway or [[Rapid application development|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.
It is also a form of rapid prototyping. 
:Rapid prototyping involves creating a working model of various parts of the system at a very early stage, after a relatively short investigation. The method used in building it is usually quite informal, the most important factor being the speed with which the model is provided. The model then becomes the starting point from which users can re-examine their expectations and clarify their requirements. When this goal has been achieved, the prototype model is 'thrown away', and the system is formally developed based on the identified requirements.<ref name=Crinnion1991p18>John Crinnion: Evolutionary Systems Development, a practical guide to the use of prototyping within a structured systems methodology. Plenum Press, New York, 1991. Page 18.</ref>

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 amount of 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 function.

:…it is asserted that revolutionary rapid prototyping is a more effective manner in which to deal with user requirements-related issues, and therefore a greater enhancement to software productivity overall. Requirements can be identified, simulated, and tested far more quickly and cheaply when issues of evolvability, maintainability, and software structure are ignored. This, in turn, leads to the accurate specification of requirements, and the subsequent construction of a valid and usable system from the user's perspective, via conventional software development models.<ref name=Overmyer>S. P. Overmyer: Revolutionary vs. Evolutionary Rapid Prototyping: Balancing Software Productivity and HCI Design Concerns. Center of Excellence in Command, Control, Communications and Intelligence (C3I), George Mason University, 4400 University Drive, Fairfax, Virginia.</ref>

Prototypes can be classified according to the fidelity with which they resemble the actual product in terms of appearance, interaction and timing. One method of creating a low fidelity throwaway prototype is [[Paper prototypes|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 a [[GUI Builder]] and create a ''click dummy'', a prototype that looks like the goal system, but does not provide any functionality.

The usage of [[storyboard]]s, animatics or drawings is not exactly the same as throwaway prototyping, but certainly falls within the same family.  These are non-functional implementations but show how the system will look.

Summary: In this approach the prototype is constructed with the idea that it will be discarded and the final system will be built from scratch. The steps in this approach are:
#Write preliminary requirements
#Design the prototype
#User experiences/uses the prototype, specifies new requirements
#Repeat if necessary
#Write the final requirements

===Evolutionary prototyping===

Evolutionary prototyping (also known as [[breadboard]] prototyping) is quite different from [[Software_prototyping#Throwaway_prototyping|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 approach is that the evolutionary prototype, when built, forms the heart of the new system, and the improvements and further requirements will then be built.

When developing a system using evolutionary prototyping, the system is continually refined and rebuilt. 
:"…evolutionary prototyping acknowledges that we do not understand all the requirements and builds only those that are well understood."<ref name=Davis1992p71>Alan M. Davis: Operational Prototyping: A new Development Approach. IEEE Software, September 1992. Page 71.</ref>
This technique allows the development team to add features, or make changes that couldn't be conceived during the requirements and design phase.

:For a system to be useful, it must evolve through use in its intended operational environment. A product is never "done;" it is always maturing as the usage environment changes…we often try to define a system using our most familiar frame of reference—where we are now. We make assumptions about the way business will be conducted and the technology base on which the business will be implemented. A plan is enacted to develop the capability, and, sooner or later, something resembling the envisioned system is delivered.<ref name=SoftwareProductivityConsortium1997p6>Software Productivity Consortium: Evolutionary Rapid Development. SPC document SPC-97057-CMC, version 01.00.04, June 1997. Herndon, Va. Page 6.</ref>

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.

:"It is not unusual within a prototyping environment for the user to put an initial prototype to practical use while waiting for a more developed version…The user may decide that a 'flawed' system is better than no system at all."<ref name=Crinnion1991p18/>

In evolutionary prototyping, developers can focus themselves to develop parts of the system that they understand instead of working on developing a whole system.

:To minimize risk, the developer does not implement poorly understood features. The partial system is sent to customer sites. As users work with the system, they detect opportunities for new features and give requests for these features to developers. Developers then take these enhancement requests along with their own and use sound configuration-management practices to change the software-requirements specification, update the design, recode and retest.<ref>Davis. Page 72-73. Citing: E. Bersoff and A. Davis, Impacts of Life Cycle Models of Software Configuration Management. Comm. ACM, Aug. 1991, pp.&nbsp;104–118</ref>

===Incremental prototyping===
The final product is built as separate prototypes. At the end, the separate prototypes are merged in an overall design. By the help of incremental prototyping the time gap between user and software developer is reduced.

===Extreme prototyping===
Extreme prototyping as a development process is used especially for developing web applications. Basically, it breaks down web development into three phases, each one based on the preceding one. The first phase is a static prototype that consists mainly of HTML pages. In the second phase, the screens are programmed and fully functional using a simulated services layer. In the third phase, 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."<ref>{{cite web | url=http://www.onjava.com/pub/a/onjava/2006/11/15/reshaping-it-project-delivery-through-extreme-prototyping.html?page=1 |title=Reshaping IT Project Delivery Through Extreme Prototyping |last=Komatineni |first= Satya|archive-url=https://web.archive.org/web/20161206150207/http://www.onjava.com/pub/a/onjava/2006/11/15/reshaping-it-project-delivery-through-extreme-prototyping.html?page=1 |archive-date=2016-12-06 }}</ref>