Prototyping model of software

Prototyping model

The prototyping model builds a working sample (prototype) of the system early, with limited functions, so that users can see and evaluate it. Their feedback is used to refine the requirements, and the prototype is revised until the user is satisfied; then the final system is developed (or the prototype evolved into it). It is useful when the requirements are unclear or unstable (e.g. new user interface or an instrumentation display).

 Requirements gathering
        |
 Quick design
        |
 Build prototype <----------+
        |                    |
 Customer evaluation --(refine)
        | (accepted)
 Final design -> Implement -> Test -> Maintain

Components (phases)

1. Requirements gathering: initial, rough requirements from the users.
2. Quick design: a simple design of the visible parts (inputs, outputs, screens).
3. Prototype building: quick implementation of a partial system (throw-away or evolutionary).
4. User evaluation: customer tests and gives feedback.
5. Refinement: the requirements and prototype are revised; the cycle repeats.
6. Final product: engineering of the full system, testing, deployment and maintenance.

Merits

• Misunderstandings in requirements are found early, so the final system suits users better.
• Users participate actively; higher satisfaction.
• Reduces the risk and cost of late changes; missing functionality is detected early.
• Useful for unclear requirements and for demonstrating feasibility.

Demerits

• Customers may take the prototype as the final product and expect fast delivery; the quick-and-dirty prototype code may be kept, with a poor structure.
• Time and cost may increase through repeated cycles; scope creep.
• Documentation is often poor; hard to plan and estimate.
• Developers may make poor design choices to build the prototype fast.
• Not suitable for large, well-defined, safety-critical systems.