Software prototyping is the process of creating an incomplete model of the
future full-featured software program, which can be used to let the users have a
first idea of the completed program or allow the clients to evaluate the
program.

Software prototyping is an
information system development methodology based on building and using a model
of a system for designing, implementing, testing, and installing the system.

Determine basic requirements
including the input and output information desired. Details, such as security,
can typically be ignored.

Develop Initial Prototype

The initial prototype is
developed that includes only user interfaces.

Review

The customers, including
end-users, examine the prototype and provide feedback on additions or changes.

Revise and Enhancing the Prototype

Using the feedback both the
specifications and the prototype can be improved. Negotiation about what is
within the scope of the contract/product may be necessary. If changes are
introduced then a repeat of steps #3 ands #4 may be needed.

Throwaway
prototyping

Throwaway or Rapid
Prototyping refers to the creation of a model that will eventually be discarded rather
than becoming part of the finally 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.

Rapid Prototyping involved
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 has been achieved, the prototype model is 'thrown away', and the system is
formally developed based on the identified requirements.[7]

A software rapid prototype is a dynamic visual
model providing a communication tool for customer and developer that is far
more effective than either narrative prose or static visual models for
portraying functionality. It has been described as:

Functional after a minimum amount of effort

A means for providing users of a proposed
application with a physical representation of key aspects of the system
before the system is implemented

Flexible: modifications require minimal effort

Not necessarily representative of a complete
system

Questions

1. Is the prototype simply the first version
of the final product?

2. Will a prototype module be as easy to
modify as a dataflow diagram?

3. Is the prototype to be used only to
experiment with various design alternatives?

4. Are we prototyping to test the
requirements specifications?

5. Will the prototype use actual data and
allow the user to test what-if scenarios during demonstrations?

6. Will there be any possibility of evolving
the prototype into the final product?

Rapid Software Prototyping - Critical Questions

Q. What critical objectives
of software development are most effectively achieved through rapid
prototyping?

A. Rapid prototyping is
basically an analysis technique.

discovery of the true and complete set of
functional requirements for a proposed system

In classical software development, the client
usually cannot view a physical representation of the final system until
the testing phase.

this is critical in projects with very long
development times results in a very low probability of delivering an
acceptable software system

Q. To what extent should end
users be involved in rapid prototyping?

A. About 50 percent of the
development effort is user contributions. The users will always be present.

Throwaway Prototypes

a product designed to be used only to help the
customer identify requirements for a new system

the product cannot be implemented or even
evolved into a deliverable system - only the derived requirements will be
maintained often a result of tools that are unsuitable for use in
production systems

Quick and Dirty Prototypes

the approach of quickly bringing up a version of
a system, then modifying it until the customer can grant minimal approval

care must be taken so that something intended to
be temporary does not actually become permanent

Detail Design-Driven Prototypes

derived from engineering disciplines where
``prototype'' means a preproduction model of a
system

the model is ``test-driven'' to uncover any
defects

Nonfunctioning Mock-ups

provides the customer with visual examples of
inputs to and outputs from system processes

no data are actually input, nor are results
computed and output

distinction between throwaways and mock-ups
based on the presence or absence of real data

not definitive in identifying functional
requirements because of the lack of interactive experimentation

Evolutionary Prototyping

an easily modifiable and extensible working
model of a proposed system, not necessarily representative of a complete
system, which provides users with a physical representation of key parts
of the system before implementation

an easily built, readily modifiable, ultimately
extensible, partially specified, working model of the primary aspects of a
proposed system

the goal is to evolve the prototype into the
final system

the primary objective is to provide a
cost-effective means of discovering the true and complete set of system
functional requirements that will optimally satisfy the legitimate
business needs of the user, given a level of funding acceptable to the
customer and software developer.

evolutionary prototyping techniques can be applied
effectively to all phases of the software development cycle.

detailed analysis and design do still take place.

the techniques of evolutionary prototyping are
applied concurrently with structured analysis at the beginning of the
project and with structured design during the tuning phase.

characteristics:

·real-world data
is used during prototyping

·must be
modifiable

·should, in most
cases, develop into the final system

Advantages of prototyping

There are many advantages to using prototyping in
software development, some tangible some abstract[11].

Reduced time and costs: Prototyping can improve the
quality of requirements and specifications provided to developers. Because
changes cost exponentially more to implement as they are detected later in
development, the early determination of what the user really wants can
result in faster and less expensive software.[8]

Improved and increased user involvement: Prototyping requires
user involvement and allows them to see and interact with a prototype allowing
them to provide better and more complete feedback and specifications.[7] The presence of the prototype being
examined by the user prevents many misunderstandings and miscommunications that
occur when each side believe the other understands what they said. Since users
know the problem domain better than anyone on the development
team does, increased interaction can result in final product that has greater
tangible and intangible quality. The final product is more likely to satisfy
the users desire for look, feel and performance.

Disadvantages of prototyping

Insufficient analysis: The focus on a limited
prototype can distract developers from properly analyzing the complete project.
This can lead to overlooking better solutions, preparation of incomplete
specifications or the conversion of limited prototypes into poorly engineered
final projects that are hard to maintain. Further, since a prototype is limited
in functionality it may not scale well if the prototype is used as the basis of
a final deliverable, which may not be noticed if developers are to focused on
building a prototype as a model.

User confusion of prototype and finished system: Users can begin to
think that a prototype, intended to be thrown away, is actually a final system
that merely needs to be finished or polished. This can lead them to expect the
prototype to accurately model the performance of the final system when this is
not the intent of the developers. Users can also become attached to features
that were included in a prototype for consideration and then removed from the
specification for a final system. If users are able to require all proposed
features be included in the final system this can lead to feature
creep. Developers can also become attached to prototypes they have spent a
great deal of effort producing; this can lead to problems like attempting to
convert a limited prototype into a final system when it does not have an
appropriate underlying architecture.

Excessive development time of the prototype: A key property to
prototyping is the fact that it is supposed to be done quickly. If the developers
lose sight of this fact, they very well may try to develop a prototype that is
too complex. When the prototype is thrown away the precisely developed
requirements that it provides may not yield a sufficient increase in
productivity to make up for the time spent developing the prototype. Users can
become stuck in debates over details of the prototype, delaying implementation
of the final product and holding up the development team.

Expense of implementing prototyping: the start up costs for
building a development team focused on prototyping may be high. Many companies
have development methodologies in place, and changing them can mean retraining,
retooling, or both. Many companies tend to just jump into the prototyping
without bothering to retrain their workers as much as they should.

A common problem with adopting
prototyping technology is high expectations for productivity with insufficient
effort behind the learning curve. In addition to training for the use of a
prototyping technique, there is an often overlooked need for developing
corporate and project specific underlying structure to support the technology.
When this underlying structure is omitted, lower productivity can often result.[13]

Building software systems requires communicating
system requirements to the developers of the system. In formal software
development methodologies, this task is accomplished through documentation.
Extreme Programming techniques can be viewed as methods for rapidly building
and disseminating institutional knowledge among members of a development team.
The goal is to give all developers a shared view of the system which matches
the view held by the users of the system. To this end, Extreme Programming
favors simple designs, common metaphors, collaboration of users and
programmers, frequent verbal communication, and feedback.

Extreme Programming encourages starting with
the simplest solution. Extra functionality can then be added later. The
difference between this approach and more conventional system development
methods is the focus on designing and coding for the needs of today instead of
those of tomorrow, next week, or next month. Proponents of XP acknowledge the
disadvantage that this can sometimes entail more effort tomorrow to change the
system; their claim is that this is more than compensated for by the advantage
of not investing in possible future requirements that might change before they
become relevant. Coding and designing for uncertain future requirements implies
the risk of spending resources on something that might not be needed. Related
to the "communication" value, simplicity in design and coding should
improve the (quality of) communication. A simple design with very simple code
could be easily understood by most programmers in the team.

Within Extreme Programming, feedback
relates to different dimensions of the system development:

Feedback from the system: by writing unit tests,
or running periodic integration tests, the programmers have direct
feedback from the state of the system after implementing changes.

Feedback from the customer: The functional tests (akaacceptance tests) are written by the customer
and the testers. They will get concrete feedback about the current state
of their system. This review is planned once in every two or three weeks
so the customer can easily steer the development.

Feedback from the team: When customers come up with new
requirements in the planning game the team directly gives an estimation of
the time that it will take to implement.

Feedback is closely related to communication
and simplicity. Flaws in the system are easily communicated by writing a unit
test that proves a certain piece of code will break. The direct feedback from
the system tells programmers to recode this part. A customer is able to test
the system periodically according to the functional requirements (akauser stories).

Several practices embody courage. One
is the commandment to always design and code for today and not for tomorrow.
This is an effort to avoid getting bogged down in design and requiring a lot of
effort to implement anything else. Courage enables developers to feel
comfortable with refactoring their code when
necessary. This means reviewing the existing system and modifying it so that
future changes can be implemented more easily. Another example of courage is knowing when to throw code away: courage to remove source
code that is obsolete, no matter how much effort was used to create that source
code. Also, courage means persistence: A programmer might be stuck on a complex
problem for an entire day, then solve the problem quickly the next day, if only
they are persistent.

The respect value manifests in
several ways. In Extreme Programming, team members respect each other because
programmers should never commit changes that break compilation, that make
existing unit-tests fail, or that otherwise delay the work of their peers.
Members respect their work by always striving for high quality and seeking for
the best design for the solution at hand through refactoring.

Adopting four earlier values led to respect
gained from others in team. Nobody on the team should feel unappreciated or
ignored. This ensures high level of motivation and encourages loyalty toward
the team, and the goal of the project. This value is very dependent upon the
other values, and is very much oriented toward people in a team.