Structured Evolutionary Prototyping Model...

Software prototyping refers to the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed. It is an activity that occurs during certain software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing.

Software developments that are relatively easy to prototype almost always involve human-machine interaction and/or heavy computer graphics. Other applications that are sometimes amenable to prototyping are certain classes of mathematical algorithms, subset of command driven systems and other applications where results can be easily examined without real time interaction. Applications that are difficult to prototype include control and process control systems.

Features

• Developers build a prototype during the requirements phase
• Prototype is evaluated by end users
• Users give corrective feedback
• Developers further refine the prototype
• When the user is satisfied, the prototype code is brought up to the standards needed for a final product.

Dimensions of prototypes

1.    Horizontal Prototype

A common term for a user interface prototype is the horizontal prototype. It provides a broad view of an entire system or subsystem, focusing on user interaction more than low-level system functionality, such as database access. Horizontal prototypes are useful for:

• Confirmation of user interface requirements and system scope
• Demonstration version of the system to obtain buy-in from the business
• Develop preliminary estimates of development time, cost and effort.

2. Vertical Prototype

A vertical prototype is a more complete elaboration of a single subsystem or function. It is useful for obtaining detailed requirements for a given function, with the following benefits:

• Refinement database design
• Obtain information on data volumes and system interface needs, for network sizing a performance engineering
• Clarifies complex requirements by drilling down to actual system functionality

Steps

• A preliminary project plan is developed
• An partial high-level paper model is created
• The model is source for a partial requirements specification
• A prototype is built with basic and critical attributes
• The designer builds

–the database

–user interface

–algorithmic functions

• The designer demonstrates the prototype; the user evaluates for problems and suggests improve
• This loop continues until the user is satisfied.

Strengths

• Customers can “see” the system requirements as they are being gathered
• Developers learn from customers
• A more accurate end product
• Unexpected requirements accommodated
• Steady, visible signs of progress produced
• Interaction with the prototype stimulates awareness of additional needed functionality.

Weaknesses

• Tendency to abandon structured program development for “code-and-fix” development
• Bad reputation for “quick-and-dirty” methods
• Overall maintainability may be overlooked
• The customer may want the prototype delivered
• Process may continue forever (scope creep)

When to use Structured Evolutionary Prototyping

• Requirements are unstable or have to be clarified
• As the requirements clarification stage of a waterfall model
• Develop user interfaces
• Short-lived demonstrations
• New, original development
• With the analysis and design portions of object-oriented development