SDLC – Prototyping Model

Before starting the actual development, a working prototype of the system was first built in the prototyping model. A prototype is a toy implementation of a system with limited functional capabilities, low reliability, and inefficient performance.

Prototyping Model – SDLC

Why does the prototyping SLDC model need to be constructed?

  1. Sometimes the customer does not know what exactly they want to resolve their confusion and understand their desires.
  2. Sometimes even the developers do not know how to design and implement certain requirements.

While constructing the prototype, developers can figure out whether they can meet customer requirements or not. By prototyping, the customer feels that system and suggests modification as well, if any. And in this way, the developers can experiment with the technique to decide and select a better approach.

Reasons for Prototyping Model

  1. Learning by doing -: useful when requirements are partially known.
  2. Improved communication.
  3. Improved user involvement.
  4. Reduced need for documentation.
  5. Reduced maintenance costs.

Reasons for developing a Prototyping Model

  1. Illustrate to the customer, input data formats, messages, reports, or interactive dialogs.
  2. Examine technical issues associated with product development; often, major design decisions depend on a hardware controller’s response time, etc.
  3. It is impossible to get it right the first time. We must plan to throw away the first version if we want to develop good software.

Prototyping Model

  1. Start with approximate requirements, carry out a quick design, and build using several shortcuts.
  2. It might be inefficient, inaccurate, and dummy functionalities or table look rather than performing the actual computation.
  3. The developed prototype is submitted to the customer for his/her evaluation.
    • Based on the user feedback, the prototype is refined.
    • This cycle continues until the user approves the prototype.
  4. The actual system is developed using the waterfall model.
  5. The requirements analysis and specification phase becomes redundant. The final working prototype incorporates all the user feedbacks and servers as an animated requirement specification.
  6. The design and code for the prototype are always or usually thrown away. However, the experience gathered for developing the prototype helps a great deal while developing the actual software.
  7. Even though the construction of a working prototype model involves additional cost, overall development usually costs lower than the waterfall or v model.
  8. Many user requirements get properly defined, and technical issues get resolved. These would have appeared later as change requests and resulted in incurring massive redesign costs and time.
Prototyping Model

Prototyping Model advantages

  1. The resulting software is usually more useful.
  2. User needs are better accommodated.
  3. The design is of higher quality.
  4. The resulting software is a carrier to maintain.
  5. Overall, the development incurs fewer costs.

Prototyping Model disadvantages

  1. For some projects, it is expensive.
  2. Susceptible to over-engineering
  3. Designers start to incorporate sophistication that they could not incorporate in the prototype.

A detailed description of the Prototyping Model

If we look at the diagrammatic representation of the prototyping model, the initial phase is prototype construction, and after that, the design, coding, testing, and so on are carried out. Like the waterfall model, the activities are organized, but a working prototype must be built before starting the actual development.

What is a prototype? A prototype is a toy implementation of the system which has limited functionalities and low reliability.

But the question is that why do we need to develop a prototype before we start to develop a system? what are the advantages of developing the prototype?

There is a need for user involvement because, unlike the classical or iterative waterfall model, the only thing that the customer sees the delivered software after the requirements are given. In contrast, in this model, the prototype is constructed and given to the customer for his comments, and also, since a prototype exists, it reduces the documentation, reduces maintenance costs. And also if there are technical risks that the development team anticipates.

The reason for developing the prototype is to illustrate to the customer what the software will look like, what will be the input data formats, messages, reports, interactive dialogues. With the technical issues associated with product development, the developers can experiment and find out the best way to handle technical issues. The major decisions depend on issues like the response time of the hardware controller.

Example: By developing the prototype, the designers can have their solution based on the hardware, the response time of the hardware controller at the upfront rather than proceeding throughout all the development activities, and finding out that the hardware controller response time is slow need to change everything. So, developing a prototype helps get customer feedback, and also, many technical issues are clarified, and the development can proceed correctly.

Prototyping Model

In the prototyping model, the approximate requirements are obtained, a quick design is constructed, and then the prototype is constructed using various shortcuts. The shortcuts can be inefficient, inaccurate, or dummy functions; a table lookup rather than writing the code for the actual computation.

Once a quick design is done based on the requirements that have been gathered, the prototype is built and submitted to the customer for evaluation. Further, based on customer feedback, refine the requirements again and have a quick design change, the prototype. So on until the customer is satisfied with the prototype, then a waterfall model is used for developing the software. The prototype model is a small variation of the waterfall model, only the initial prototype construction.

The prototype is a requirement specification; a formal requirement specification document may not be required, but one thing that we must be clear is that in the prototyping model, once the prototype has been used to demonstrate to the customer and address the technical issues, the prototype is thrown away and then the fresh development starts.

Does the prototype construction add to the cost, and the development becomes more costly? No, not really, because for systems with unclear user requirements with unresolved technical issues, prototyping is actually a cost-effective way of developing the software because without a prototype, we might have to change the software many times, and that would make it much more expensive would incur massive redesigned costs. And even though there is a small upfront cost of developing the prototype, but that will be more effective cost-effective than not using the prototype and finally, finding out that the customer has a lot of dissatisfaction and suggests many changes and also the technical issues are unresolved as a result many changes occur.

Reference

  1. Fundamentals of Software Engineering Book & NPTEL Video Lectures by Rajib Mall.

 1,287 total views,  1 views today

Scroll to Top
Scroll to Top
%d bloggers like this: