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 customers and end-users usually find it very difficult to express their real requirements.  

         It is almost impossible to predict

         how a system will affect working practices,

         how it will interact with other systems, and

         what user operations should be automated.

         Careful requirement analysis along with systematic reviews of the requirements help to reduce the uncertainty about what the system should do.  This possible if prototyping of the system to be developed is available.

         A function described in a specification may seem to be useful and well-defined.  However, when the function is used with others, users often find that their initial view was incorrect or incomplete. 

         System prototypes allow users to experiment with requirements and see how the system supports their work.

         Prototyping is therefore a means of requirements validation (building the right product).

         Users discover requirements error or omissions early in the software process.

         The principal purpose of prototyping is to validate software requirements. 


The benefits of developing a prototype early in the software process are: 

  1. Misunderstandings between software developers and users may be identified as the system functions are demonstrated.

  2. Missing user services may be detected.

  3. Difficult-to-use or confusing user services may be identified and refined.

  4. Software development staff may find incomplete and/or inconsistent requirements as the prototype is developed.

  5. A working, although limited, system is available quickly to demonstrate the feasibility and usefulness of the application to management.

  6. The prototype serves as a basis for writing the specification for a production quality system.

  7. Reduced time and costs:

Prototyping can improve the quality of requirements and specifications provided to developers. When changes to made to system are detected later in the software process, cost become exponentially more.  Therefore, the early determination of what the user really wants can result in faster and less expensive software.

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

  2. User training

A prototype system can be used for training users before the final system has been delivered.

  1. System Testing

Prototypes can run ‘back-to-back’ tests.  This reduces the need for tedious manual checking of test runs.  The same test cases are submitted to both the prototype and the system under test.  If both systems give the same result, the test case has not detected a fault.  If the results are different, this implies that the tester should look in more detail at the reasons for the difference. 

Prototyping – risk reduction technique 

A significant risk in software development is requirements errors and omissions.  The costs of fixing requirements errors at later stages in the process can be very high.  Prototyping reduces the number of problems with the requirements specification and the overall development costs may be lower if the prototype is developed. 



         The objectives of prototyping should be made explicit from the start of the process.

         The objectives may be to develop a system:

1.      to prototype the user interface;

2.      to validate functional system requirements;

3.      to demonstrate feasibility of the application of management.

         The same prototype cannot meet al objectives.

         If objectives are left understood, then management and end-users may misunderstand the function of the  system, and they may not get the benefits expected. 


         This stage determine what to put into and what to not put into the system.

         Software prototyping is expensive if the prototype is implemented using the same tools and to the same standard of the final system.  Therefore, it may be decided to prototype all system functions but at a reduced level. 

         On the other hand, a subset of the system functions may be included in the prototype. 


Just develop the prototype, make an executable program!!! 


         The final stage is the most important stage of the process.

         Provisions must be made for user training and the prototype objectives should be used to develop a plan for evaluation.

         Users need time to become comfortable with a new system and to settle into a normal pattern of usage.  Once they are using the system normally, they then discover requirements errors and omissions. 


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

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

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

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


         It is difficult for end-users to anticipate how they will use new software systems to support their everyday work.  If these systems are large and complex, it is probably impossible to make this assessment before the system is built and put into use. 

         One way of tackling this difficulty is to use the EVOLUTIONARY APPROACH  to system development.  This means giving the user a system which is incomplete and then modifying and enlarging it as the user requirements become clear. 

         Alternatively, a deliberate decision might be made to build a ‘throw-away’ prototype to help requirements analysis and validation.  After evaluation, the prototype is discarded and a production-quality system is built. 


Evolutionary Prototyping starts out with a limited understanding of the system requirements and the system is augmented and changed as new requirements are discovered.   

         There may never be a system specification. 

Systems developed by this approach may be un-specifiable because we do not understand the process which they are trying to automate. 

The objective of evolutionary prototyping is to deliver a working system to end-users. 

The first priority is to incorporate well-understood requirements as prototype, then move on to those requirements which are unclear.


   The throw-away prototyping approach is intended to discover the system specification so that the output of the prototype development phase is that specification.

   The objective of throw-away prototyping is to validate or derive the system requirements.

   The priority is to understand requirements that are not clear.  You therefore, start with those requirements that are not well understood. Requirements which are straight forward may never be prototyped.

Make a Free Website with Yola.