Editing Software prototyping (section)

==Applicability==
It has been argued that prototyping, in some form or another, should be used all the time. However, prototyping is most beneficial in systems that will have many interactions with the users.

:It has been found that prototyping is very effective in the analysis and design of [[on-line systems]], especially for [[transaction processing]], where the use of screen dialogs is much more in evidence. The greater the interaction between the computer and the user, the greater the benefit is that can be obtained from building a quick system and letting the user play with it.<ref name=Crinnion1991p18/>

Systems with little user interaction, such as [[batch processing]] or systems that mostly do calculations, benefit little from prototyping. Sometimes, the coding needed to perform the system functions may be too intensive and the potential gains that prototyping could provide are too small.<ref name=Crinnion1991p18/>

Prototyping is especially good for designing good [[human–computer interface]]s. "One of the most productive uses of rapid prototyping to date has been as a tool for iterative user requirements engineering and human–computer interface design."<ref name=Overmyer/>

===Dynamic systems development method===
[[Dynamic Systems Development Method]] (DSDM)<ref>Dynamic Systems Development Method Consortium. https://web.archive.org/web/20060209072841/http://na.dsdm.org/</ref> is a framework for delivering business solutions that relies heavily upon prototyping as a core technique, and is itself [[ISO 9001]] approved.  It expands upon most understood definitions of a prototype.  According to DSDM the prototype may be a diagram, a business process, or even a system placed into production. DSDM prototypes are intended to be incremental, evolving from simple forms into more comprehensive ones.

DSDM prototypes can sometimes be ''throwaway'' or ''evolutionary''.  Evolutionary prototypes may be evolved horizontally (breadth then depth) or vertically (each section is built in detail with additional iterations detailing subsequent sections).  Evolutionary prototypes can eventually evolve into final systems.

The four categories of prototypes as recommended by DSDM are:
* '''Business prototypes''' – used to design and demonstrates the business processes being automated.
* '''Usability prototypes''' – used to define, refine, and demonstrate user interface design usability, accessibility, look and feel.
* '''Performance and capacity prototypes''' –  used to define, demonstrate, and predict how systems will perform under peak loads as well as to demonstrate and evaluate other non-functional aspects of  the system (transaction rates, data storage volume, response time, etc.)
* '''Capability/technique prototypes''' – used to develop, demonstrate, and evaluate a design approach or concept.

The [[Dynamic systems development method|DSDM]] lifecycle of a prototype is to:
# Identify prototype
# Agree to a plan
# Create the prototype
# Review the prototype

===Operational prototyping===
Operational prototyping was proposed by Alan Davis as a way to integrate throwaway and evolutionary prototyping with conventional system development. "It offers the best of both the quick-and-dirty and conventional-development worlds in a sensible manner. Designers develop only well-understood features in building the evolutionary baseline, while using throwaway prototyping to experiment with the poorly understood features."<ref name=Davis1992p71/>

Davis' belief is that to try to "retrofit quality onto a rapid prototype" is not the correct method when trying to combine the two approaches. His idea is to engage in an evolutionary prototyping methodology and rapidly prototype the features of the system after each evolution.

The specific methodology follows these steps:<ref name=Davis1992p71/>

*An evolutionary prototype is constructed and made into a baseline using conventional development strategies, specifying and implementing only the requirements that are well understood.
*Copies of the baseline are sent to multiple customer sites along with a trained prototyper.
*At each site, the prototyper watches the user at the system.
*Whenever the user encounters a problem or thinks of a new feature or requirement, the prototyper logs it. This frees the user from having to record the problem, and allows him to continue working.
*After the user session is over, the prototyper constructs a throwaway prototype on top of the baseline system.
*The user now uses the new system and evaluates. If the new changes aren't effective, the prototyper removes them.
*If the user likes the changes, the prototyper writes feature-enhancement requests and forwards them to the development team.
*The development team, with the change requests in hand from all the sites, then produce a new evolutionary prototype using conventional methods.

Obviously, a key to this method is to have well trained prototypers available to go to the user sites. The operational prototyping methodology has many benefits in systems that are complex and have few known requirements in advance.

===Evolutionary systems development===
[[Evolutionary Systems]] Development is a class of methodologies that attempt to formally implement evolutionary prototyping. One particular type, called [[Systemscraft]] is described by John Crinnion in his book ''Evolutionary Systems Development''.

Systemscraft was designed as a 'prototype' methodology that should be modified and adapted to fit the specific environment in which it was implemented.

:Systemscraft was not designed as a rigid 'cookbook' approach to the development process. It is now generally recognised[sic] that a good methodology should be flexible enough to be adjustable to suit all kinds of environment and situation...<ref name=Crinnion1991p18/>

The basis of Systemscraft, not unlike evolutionary prototyping, is to create a working system from the initial requirements and build upon it in a series of revisions. Systemscraft places heavy emphasis on traditional analysis being used throughout the development of the system.

===Evolutionary rapid development===
[[Evolutionary Rapid Development]] (ERD)<ref>Adapted from Software Productivity Consortium. PPS 10–13.</ref> was developed by the Software Productivity Consortium, a technology development and integration agent for the Information Technology Office of the [[Defense Advanced Research Projects Agency]] (DARPA).

:Fundamental to ERD is the concept of composing software systems based on the reuse of components, the use of software templates and on an architectural template. Continuous evolution of system capabilities in rapid response to changing user needs and technology is highlighted by the evolvable architecture, representing a class of solutions. The process focuses on the use of small artisan-based teams integrating software and systems engineering disciplines working multiple, often parallel short-duration timeboxes with frequent customer interaction.

:Key to the success of the ERD-based projects is parallel exploratory analysis and development of features, infrastructures, and components with and adoption of leading edge technologies enabling the quick reaction to changes in technologies, the marketplace, or customer requirements.<ref name=SoftwareProductivityConsortium1997p6/>

To elicit customer/user input, frequent scheduled and ad hoc/impromptu meetings with the stakeholders are held. Demonstrations of system capabilities are held to solicit feedback before design/implementation decisions are solidified. Frequent releases (e.g., [[Development stage#Beta|betas]]) are made available for use to provide insight into how the system could better support user and customer needs. This assures that the system evolves to satisfy existing user needs.

The design framework for the system is based on using existing published or de facto standards. The system is organized to allow for evolving a set of capabilities that includes considerations for performance, capacities, and functionality. The architecture is defined in terms of abstract interfaces that encapsulate the services and their implementation (e.g., COTS applications). The architecture serves as a template to be used for guiding development of more than a single instance of the system. It allows for multiple application components to be used to implement the services. A core set of functionality not likely to change is also identified and established.

The ERD process is structured to use demonstrated functionality rather than paper products as a way for [[Project stakeholder|stakeholders]] to communicate their needs and expectations. Central to this goal of rapid delivery is the use of the "[[timeboxing|timebox]]" method. Timeboxes are fixed periods of time in which specific tasks (e.g., developing a set of functionality) must be performed. Rather than allowing time to expand to satisfy some vague set of goals, the time is fixed (both in terms of calendar weeks and person-hours) and a set of goals is defined that realistically can be achieved within these constraints.  To keep development from degenerating into a "[[random walk]]," long-range plans are defined to guide the iterations. These plans provide a vision for the overall system and set boundaries (e.g., constraints) for the project. Each iteration within the process is conducted in the context of these long-range plans.

Once an architecture is established, software is integrated and tested on a daily basis. This allows the team to assess progress objectively and identify potential problems quickly. Since small amounts of the system are integrated at one time, diagnosing and removing the defect is rapid. User demonstrations can be held at short notice since the system is generally ready to exercise at all times.