Software Prototyping

Olivete, Marion Sean

Submitted to Mr. Wong

October 1, 2010
What is software prototyping?

Software prototyping, refers to the activity of creating prototypes of software applications, i.e.,

A prototype typically simulates only a few aspects of the features of the eventual program, and may be

Types of Prototyping

Throwaway prototyping

Also called close ended prototyping. Throwaway or 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.

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.

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 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 work 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. [8]

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 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.

Not exactly the same as Throwaway Prototyping, but certainly in the same family, is the usage
of storyboards, animatics or drawings. These are non-functional implementations but show how the
system will look.

Wireframes/Paper Prototypes
Wireframes and Paper Prototypes are useful early-stage techniques, though limited in as much as they
are non-interactive and usually very broad. If our project were to be painting a landscape, you might
think of wireframes and paper prototypes as the early sketches on a notepad, or some under-painting.
In other words, suggesting the basic shape but not saying much about the details. Though often
simplistic, this style of prototype is useful because they can be very quick to create and don't require so
much technical expertise to put together.

Visual Prototypes
These often come in the form of screen mock-ups, perhaps in a paper form or created using a graphics
tool such as Adobe Photoshop. They offer an opportunity to prototype the look and feel of a system
design, though not normally any functionality or operational flows. They are often visual mock-ups
rather than true prototypes, in as much as they represent a useful tool to demonstrate potential
appearances and layouts. These typically come from a designer's viewpoint rather than a business or
software expert.

Interactive Prototypes
These are far more useful, though require an increased investment in time to create. They aim to model
a system design more faithfully, and represent actual paths through that system. They generally will
combine the visual aspects of a static prototype with a certain degree of interactive functionality. This
might mean navigation, or the use of real web controls, or even mock data processing. As a platform for
demonstrating a system, these are the richest, most useful types of prototype, although the slowest to
create. We are advocates of Interactive Prototyping, especially in combination with business analysis
and user feedback sessions. However, there are times when the use of alternative approaches makes
more sense.

Advantages of Software Prototyping

There are many advantages to using prototyping in software development – some tangible, some
abstract.

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 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.  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 Software Prototyping

Using, or perhaps misusing, prototyping can also have disadvantages

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 too 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. (They are, for
example, often unaware of the effort needed to add error-checking and security features which a
prototype may not have.) 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 conflict.

Developer misunderstanding of user objectives: Developers may assume that users share their
objectives (e.g. to deliver core functionality on time and within budget), without understanding wider
commercial issues. For example, user representatives attending Enterprise software (e.g. PeopleSoft)
events may have seen demonstrations of "transaction auditing" (where changes are logged and displayed
in a difference grid view) without being told that this feature demands additional coding and often requires
more hardware to handle extra database accesses. Users might believe they can demand auditing on
every field, whereas developers might think this is feature creep because they have made assumptions
about the extent of user requirements. If the developer has committed delivery before the user
requirements were reviewed, developers are between a rock and a hard place, particularly if user
management derives some advantage from their failure to implement requirements.

Developer attachment to prototype: 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. (This may
suggest that throwaway prototyping, rather than evolutionary prototyping, should be used.)

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, holding up the
development team and delaying the final product.

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

Steps in Prototyping
The process of prototyping involves the following steps

1. Identify basic requirements

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

2. 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.

3. Revise and Enhance 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 and #4 may be needed.
Examples of Software Prototyping