The Prototyping Process Model

Introduction

Sometimes, customers find it difficult to visualize the product that they want. Because of this, they are either unable to give the complete specifications or keep changing them.
Software engineers also have a problem in eliciting the requirements from customers in such a situation. If persuaded, the customers may give some specifications; however, they may refuse to accept the end product if they feel it is not quite what they wanted.
In this section, you will learn about the prototyping process model. This model is often used when eliciting requirements is a problem because customers cannot visualize the product they want.

Eliciting requirements

Customers often find it difficult to specify a complete set of requirements in the beginning of a project. Some of the reasons for this are:

• The customer may have an incomplete understanding of what is required.
• The customer may not understand computers and software well enough to think of the features needed from the system.
• The customer may assume that all requirements are known clearly, though this may not be true.
• There may be more than one user, and all of them may not be available during the analysis, resulting in an incomplete understanding of requirements.
• The business requirements may change after the project has started, resulting in changes in the software requirements.

Building a prototype

One of the ways to help a customer specify what is needed, is building a prototype of the software system.
A prototype enables the customer to visualize the system and specify clearly what is needed. The analysts use a prototype to explain their understanding of the requirements. The customer can provide feedback on the prototype and the developers can use this feedback to modify the prototype. This can be done iteratively until a satisfactory prototype is made. The use of prototyping therefore helps in reducing the communication gap between customers and software engineers.
Let us now understand what a prototype is.

What is a prototype?

A prototype is a model of the salient features of a product. It helps in gathering and refining the product requirements.
For a software product, a prototype may help the customer understand the user interface of the system and how data will be gathered and presented.
It is important to note that the prototype is not the actual product. It may be nothing more than a shell or an external layer containing very little computing capability.

Steps in the prototyping process model

The prototyping process model evolved in the 1980s. It has the following six steps.
Step 1: The customer and the developer meet to define the basic requirements. These requirements are assumed to be incomplete but sufficient to build a prototype.
Step 2: The developer builds a prototype of the actual software product to give the customer a feel of the functionality of the product.
Step 3: The customer evaluates the prototype to check which features and functionalities meet the requirements, which are incomplete or inappropriate, and which are missing.
Step 4: The customer provides feedback to the developer based on the evaluation of the prototype.
Step 5: The developer refines the prototype based on the customer feedback by incorporating the changes suggested by the customer.
Step 6: The actual product is built after the prototype is found to be satisfactory by either extending the prototype into an operational product or 'throwing away' the prototype and rebuilding the product.

Note: Steps 3 through 5 are applied iteratively until the customer approves of the prototype.

Eliciting the requirements using the prototyping process model

Building a prototype is helpful because it gives customers a 'feel' of the software product and helps the developers to interact with the customers to understand their requirements in greater detail.
In order to assess the completeness of the product specifications, it is easier for customers to evaluate a tangible entity like the prototype instead of an abstraction, such as a requirements document. Therefore, the prototyping process model can work exceptionally well in situations where the customer does not have a full understanding of what is required.
The prototype forms the basis for detailed discussions with the customer. The interactions help both the developer and the customer to mutually understand the requirements and reduce the risk of a communication gap.
Let us now look at the focus of the prototyping process model

Focus of the prototyping process model

The focus of the prototyping process model is on the:

• Aspects of the system that will be visible to the customer
• Areas where the customer is not able to specify the requirements clearly
• Critical areas of the system that need to be evaluated and approved by the customer
• Algorithms or functions that represent significant technical risk

Building a prototype

A prototype is based on a 'quick' design and is built using simple tools (painted screens, fixed outputs), just like a model of a house is built using cardboard and poster colors.
The prototype can be built at a low cost in a short period of time. It helps in getting customer feedback before the actual product is built. By focusing on areas in which customer feedback is important, the risk of building a product that will not suit the customer is greatly reduced.
The technical methods used to build the prototype focus on 'rapid' construction. These methods do not focus on robustness and solid architecture.
Let us look at a scenario to understand how a prototype helps in specifying the requirements clearly.

Specifying the requirements

Consider the following scenario.
Chris, a customer representative, was very keen to have an elaborate input form with all types of complex data entry. A prototype of this input form was built.
While evaluating the prototype, Chris realized that the form appeared to be confusing, and it might become time-consuming for the data entry operators to enter the data. He discussed the form with the developers and finally decided on a two-level data entry form for clarity. This new scheme had a simple form for typical data and a complex form for the 5% cases in which the data was atypical.
This scenario given above shows that customers may over-specify or under-specify the requirements for the software product they want and later find the product inconvenient to use. In such cases, prototyping is helpful because after viewing the prototype of the final product, the customers are able to understand which features are suitable for actual use. This enables them to be clearer about their requirements and specify them appropriately.

Building the actual product

After the prototype is finally accepted, the actual product is built. There are two valid approaches for building the actual product depending on the project characteristics. These are:

• The throwaway prototype approach
• The evolutionary prototype approach

In the throwaway prototype approach, once the prototype is accepted, the actual product is built from scratch. The accepted prototype is used only to understand and model the requirements that the actual product has to conform to. The prototype as such is 'thrown away' or discarded.

In the evolutionary prototype approach, the prototype is used as the starting point to build the actual product. The product is built by extending and refining the prototype. As a result, the prototype is evolved into the final product.

Choosing the right approach

It is important that the choice of approach is made before the prototype is constructed because it affects the way the prototype is built.
If the throwaway prototype approach is used, the prototype is built using a quick and 'dirty' design. In such a case, the prototype is not based on a proper architecture because it is not worthwhile investing time and effort on designing a throwaway model. This prototype is eventually discarded because the software engineering principles are compromised in order to build the prototype quickly. Therefore, it is risky to extend the prototype into an operational product and the actual product is built afresh.
On the other hand, if the evolutionary prototype approach is used, considerable effort is spent in designing a robust architecture, because the same prototype is eventually evolved into the final product.

Benefits of using the prototyping process model

The prototyping process model is quite popular with both customers and developers. This is because the customer gets to see something tangible within a short period of time, while the developer gets to build something early in the process.
Let us hear why the prototyping model is so popular.

The customer loves this. The customer loves it because they are seeing the dynamic model of the system very early, they are playing with it, the thing looks real. Even though, in actuality, it is only a shell, so the customer loves this. The developers love this. They love it because they are down and dirty on the second day of the project. They are cranking out code on day two, and given that, they are happy they are producing something, and everybody seems to be happy, and yet I will argue prototyping is also (or can also be) problematic. Why?

Problems in using prototyping process model

The prototyping process model is quite useful. However, a problem associated with it is that customers do not understand what they see is only a mock-up or a prototype and not the actual product. They think that the product is almost ready and can be delivered fast.
Another problem with the prototyping process model is that the developers may be tempted to make the actual product by just patching or refining the prototype instead of building the product afresh. They may ignore the fact that the prototype has been built without a robust architecture and by compromising on software engineering principles.
Planning for the prototyping process model
In the prototyping process model, there is no inherent limit to the number of iterations that a prototype undergoes. Therefore, a potential problem is that it might get into repeated refinements and the prototype may not be 'frozen' or accepted. For this reason, project planning should specify a limit for the number of iterations, in consultation with the customer.