Database Reference
In-Depth Information
The following are some basic guidelines for developing a prototype:
•
Work in manageable modules.
•
Build prototype rapidly.
•
Modify prototype in successive iterations.
•
Emphasize the user interface—it should be friendly and meeting
user requirements.
Kinds of Prototypes
There are various types of prototypes that you will find in software engineering. Among
the various categories are the following:
Patched-up Prototype or Production Model:
This prototype is functional the first
time, albeit inefficiently constructed. Further enhancements can be made with time.
Non-operational or Interactive Prototype:
This is a prototype that is intended
to be tested, in order to obtain user feedback about the requirements of the system
represented. A good example is where screens of the proposed system are designed;
the user is allowed to pass through these screens, but no actual processing is done. This
approach is particularly useful in user interface design (see Chapter 6).
First of Series Prototype:
This is an operational prototype. Subsequent releases are
intended to have identical features, but without glitches that the users may identify. This
prototype is typically used as a marketing experiment: it is distributed free of charge, or
for a nominal fee; users are encouraged to use it and submit their comments about the
product. These comments are then used to refine the product before subsequent release.
Selected Features Prototype or Working Model:
In this prototype, not all intended
features of the (represented) software are included. Subsequent releases are intended to
be enhancements with additional features. For this reason, it is sometimes referred to as
evolutionary prototype
. The initial prototype is progressively refined until an acceptable
system is obtained.
Throw-away Prototype:
An initial model is proposed for the sole purpose of eliciting
criticism. The criticisms are then used to develop a more acceptable model, and the
initial prototype is abandoned.
A3.7 Brainstorming and Mathematical Proof
The methodologies discussed so far all assume that there is readily available information
which when analyzed, will lead to accurate capture of the requirements of the desired
software. However, this is not always the case. There are many situations in which
software systems are required, but there is no readily available information that would
