VP Model(V Model with Prototype)
; Adding prototype to the V model enables the projects to handle minor
uncertainties and risks. These include feasibility issues at the requirement stage,
performance issues at the design stage or the situation that a new tool or system is
outsourced whose features/performance is unknown.
The prototyping phase could be to
a) Explore a space of possible solutions. This is a suitable approach if there is risk
and uncertainty about the problem, e.g. human interface (with new device/first
time users), system performance, error and fault management.
A generic work breakdown structure in such cases is:
; define the uncertainty
; define a means to explore a solution
; carry out exploration/experiment(might need to iterate here)
; train/answer uncertainty
b) List alternative solutions and evaluate them against some redefined criteria.
This is suitable if there is risk and uncertainty about the solution, e.g. precise
functionality about a “middleware” (OS, database, communication protocol,
window system, and etc.), performance of a vendor supplied middleware,
performance of one of the tools, performance of a particular design under various
A generic work breakdown structure in such case is:
; define the uncertainty
; identify alternatives and criteria for choice
; Evaluate against those criteria
; Choose best fitting alternative (See Figure 6)
Prototype phase yields information
about some characteristics which is
then fed back into the development
process. Only Rapid prototypes are
addressed here and not prototyping
for later reuse in the product.
figure 1: VP Model
; In cases when the course of the project can be significantly determined by the
outcome of the prototype phase, project schedules can be committed only after the
results of the prototype phase are evaluated.
; In user interface prototype, control of the prototyping activity is difficult when it
involves a high degree of user participation. How many iterations to go? When to
One solution for effective control during prototyping is to categorize the changes
and have appropriate ways to deal with them.
One categorization could be: cosmetic, Local and Global. Cosmetic changes are
cheap and risk free and can be made without any change to the design. Local
changes have a relatively small impact on the design and represent small technical
risk and cost. Global changes impact other parts of the system and would involve
substantial effort and cost.
Cosmetic changes can be implemented by the developer(without approval). Local
changes can also be directly implemented(with some form of design review), but
the last version of the prototype should be archived against the possibility that the
resulting prototype is worse! Global changes cannot be incorporated without a
design review looking at all ramifications and without approvals.