A-B-C- D-E-F- G-H-I- J-K-L- M-N-O- P-Q-R- S-T-U- V-W-X- Y-Z




Reference /Scacchi, 2001/ Process Models in Software Engineering
Prototyping is a technique for providing a reduced functionality or a limited performance version of a software system early in its development /Balzer, 1984/, /Budde, 1984/, /Hekmatpour, 1987/. In contrast to the classic system life cycle, prototyping is an approach whereby more emphasis, activity, and processing are directed to the early stages of software development (requirements analysis and functional specification). In turn, prototyping can more directly accommodate early user participation in determining, shaping, or evaluating emerging system functionality. Therefore, these up-front concentrations of effort, together with the use of prototyping technologies, seeks trade-off or otherwise reduce downstream software design activities and iterations, as well as simplify the software implementation effort.

Software prototypes come in different forms including throwaway prototypes, mock-ups, demonstration systems, quick-and-dirty prototypes, and incremental evolutionary prototypes /Hekmatpour, 1987/. Increasing functionality and subsequent evolvability is what distinguishes the prototypes forms on this list.

Prototyping technologies usually take some form of software functional specifications as their starting point or input, which in turn is simulated, analysed, or directly executed. These technologies can allow developers to rapidly construct early or primitive versions of software systems that users can evaluate. Users evaluations can then be incorporated as feedback to refine the emerging system specifications and designs. Further, depending on the prototyping technology, the complete working system can be developed through a continual revising/refining the input specifications. This has the advantage of always providing a working version of the emerging system, while redefining software design and testing activities to input specification refinement and execution. Alternatively, other prototyping approaches are best suited for developing throwaway or demonstrations systems, or for building prototypes by reusing part/all of some existing software systems. Subsequently, it becomes clear why modern models of software development like the Spiral Model and the ISO 12207 expect that prototyping will be a common activity that facilitates the capture and refinement of software requirements, as well as overall software development.

Rationales The author classifies Prototyping as one of the Software Product Development Model
Reference /VM 1997/ V-Model 97, Lifecycle Process Model.
Procedure the steps of which are based on the development, evaluation and further development of prototypes.
Reference /Yeh, 1994/ Rapid Prototyping
An evolutionary software prototyping process is illustrated in the figure bellow. The initial prototype is produced based on a requirements analysis of the customer's problem. This analysis is needed to ensure that the initial version of the prototype is close enough to what the customer need to enable them to provide meaningful evaluations and criticisms. Each succeeding version of the prototype is produced based upon an analysis of the customer's reaction to demonstrations of the previous version., and should be a better approximation to the final system. Delivered products are derived from prototypes that are accepted by customers via an optimal optimization process. Maintenance activities are sparked by new customer requirements, which restart the prototyping process and extend the series of prototypes until a new stable point is reached and a new version of the product is produced by another instance of the optimization process. The spiral model is well known because it combines the common knowledge of waterfall model, incremental method and process model work into an attractive notation, even with less specific variation of this process

Sometimes generating several small partial prototypes to answer different kinds of questions, rather than creating one large prototype, can be useful. For example, one prototype can be used to explore user interface requirements, while others can be used to refine requirements on system behavior and system performance. In such a case, each prototype presents a faithful model of the proposed system only for the selected aspects of the system. For example, the user interface prototype may have a high fidelity model of the display, including menu entries, shapes and placement of buttons and windows, colors, printing styles, and so on, but the display system response may be randomly generated or drawn from a fixed data file.

Some advantages of this approach are that prototypes of different aspects of the system can be developed concurrently and independently, that each fragment is relatively small, simple, and easy to change, and that different tools and environments can be used for different aspects. The last property can be important in the short term, if tools are available for solving different parts of the problem, but these tools have not been integrated together into a comprehensive prototyping environment.

Other Languages

German: Prototyping

Publications on this area


GDPA Online Last Updated 23.May.2002 Updated by Webmaster Last Revised 23.May.2002 Revised by Webmaster