Software applications 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.
Explain Structured Evolutionary Prototyping Model.
• 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.
Steps followed during Structured Evolutionary Prototyping Model.
• 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 improvements.
• This loop continues until the user is satisfied.
Explain strengths Structured Evolutionary Prototyping.
• Customers can "see" the system requirements as they are being gathered.
• Developers learn from customers.
• A more accurate end product.
• Unexpected requirements accommodated.
• Allows for flexible design and development.
• Steady, visible signs of progress produced.
• Interaction with the prototype stimulates awareness of additional needed functionality.
Explain weaknesses Structured Evolutionary Prototyping.
• 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 useStructured 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.
Compare Traditional SDLC with Prototyping
Document comparing Traditional SDLC with Prototyping.
Evolutionary vs Throwaway Prototyping
Difference between Evolutionary vs Throwaway Prototyping.
References:
http://www-users.cs.umn.edu/~heimdahl
http://www.docstoc.com/docs/7806897/SDLC-Models