Prototype model and when to use it

Prototype model

A prototype is an early, working but incomplete version of a software system, built quickly and cheaply to demonstrate concepts, try out design options and find out more about the requirements. The prototyping model is a process model in which such a prototype is built, evaluated by the customer and refined repeatedly until the requirements are clear.

      +------------------------+
      | Gather basic           |
      | requirements           |
      +-----------+------------+
                  v
      +------------------------+
      | Quick design           |
      +-----------+------------+
                  v
      +------------------------+
      | Build prototype        |<------+
      +-----------+------------+       |
                  v                    |
      +------------------------+       |
      | Customer evaluation    |       |
      +-----------+------------+       |
                  v                    |
      +------------------------+  no   |
      | Requirements clear?    |-------+
      +-----------+------------+  refine
                  | yes
                  v
      Engineer / build final product

Steps:

1. Requirements gathering: developer and customer define overall objectives and known requirements; unclear areas are noted.
2. Quick design: focuses on visible aspects such as user interface and input/output formats.
3. Build prototype: using fast tools (UI builders, scripting languages, reusable components), ignoring efficiency and full error handling.
4. Customer evaluation: users try the prototype and give feedback.
5. Refinement: the prototype is changed and evaluated again until requirements are understood.
6. Engineer the product: the final system is designed and built with proper quality.

Two types:

• Throwaway prototyping: the prototype is used only to understand requirements and is then discarded; the real system is built properly (often with waterfall).
• Evolutionary prototyping: the prototype is refined step by step until it becomes the final system.

Circumstances in which a prototype is beneficial

1. Requirements are unclear or incomplete. The customer defines general objectives but cannot state detailed inputs, processing or outputs. Seeing a prototype helps users discover what they really want.
2. User interface is important. For interactive systems (web portals, mobile apps, ATMs), the look and flow are best decided by letting users try screens rather than reading text.
3. New or innovative systems where neither user nor developer has prior experience, so a model is needed to explore the problem.
4. Developer is unsure about technical issues, such as the efficiency of an algorithm, the response time of a database, compatibility with an operating system or a new technology. A prototype tests feasibility before full commitment.
5. High risk of building the wrong system, where the cost of a misunderstanding is large; a prototype reduces this risk early.
6. Users can be closely involved and are available to evaluate versions and give quick feedback.
7. Demonstrating feasibility or selling an idea to management or a client before funding the full project.
8. Requirements validation: a prototype shows errors and omissions in the proposed requirements, and can also be used for early user training and as a basis for test cases.

Example: a hospital wants an online appointment system but staff cannot explain how booking, cancellation and doctor schedules should look. A quick clickable prototype of the booking screens is built in a week. Doctors and receptionists try it, ask for changes (show free slots by department, add SMS reminder), and after two or three rounds the requirements are clear enough to build the real system.

When not to use it: when requirements are already well known and stable, for very large systems where a prototype is too costly, or when users cannot spend time evaluating it. There is also a danger that customers treat a weak prototype as the finished product, or that developers keep poor quick-fix code in the final system.