Prototyping Development Process Model

Prototyping Development Process Model begins with communication and very useful in developing the Graphical User Interface (GUI) part of a system. The developer and customer meet and define the overall objectives for the software, identify whatever requirements are known, and outline areas where further definition is mandatory. A quick design then occurs. The quick design focuses on the representation of those aspects of the software that will be visible to the customer/user (e.g., input approaches and output formats). The quick design leads to the construction of a prototype.
The process model of the prototyping approach is shown in Figure pt.01.

Figure pt.01 Prototyping Development Process Model
The prototype is evaluated by the customer/user to refine requirements for the software to be developed. Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while at the same time enabling the developer to better understand what needs to be done.
Prototyping Develompment Process Model can be used when the technical solutions are unclear to the development team. Often, major design decisions depend on issues, such as the response time of a hardware controller or the efficiency of a sorting algorithm, etc. In such circumstances, a prototype may be the best or the only way to resolve the technical issues.


Controlling Changes During Prototyping
A major problem with prototyping is controlling changes to the prototype following suggestions by the users. One approach has been to categorize changes as belonging to one of three types:
1. Cosmetic (about 35% of changes).
These are simply changes to the layout of the screen. They are:

• Implemented.
• Recorded.

2. Local (about 60% of changes).
These involve changes to the way the screen is processed but do not affect other parts of the system. They are:

• Implemented.
• Recorded.
• Backed-up so that they can be removed at a later stage is necessary.
• Inspected retrospectively.

3. Global (about 5% of changes).
These are changes that affect more than one part of the processing. All changes here have to be the subject of a design review before they can be implemented.

Related Posts :
Software Development Life Cycle
Software Development Process
Waterfall Model
Agile Model
Iterative Model
Spiral Model