Chapter Summary

profileaaarrrttt
chapter15.pdf

Chapter 15:

Risk Reduction Through Prototyping

© Karl E. Wiegers

1

15.1 Why do Prototyping?

2 Dialog Map Karl Wiegers

3

Lower the expectation Gap

15.2 Prototype Types

 Horizontal Prototypes  Behavioral mockup—most common type  Broad but not deep—functional but slow,

fragile, unreliable  Shows look and feel, flow of tasks

4

Vertical Prototypes

 Proof of concept  Narrow but deep—limited set of features,

but complete implementation of them  Works like real system, for evaluation of: ◦ Architecture approach ◦ Algorithm optimization

5

Throwaway Prototypes

 Decide early about “discard” or “deliver”  Throwaways are quick and dirty, poorly

engineered and constructed  Most useful for user interfaces ◦ Use case ◦ Dialog map ◦ Detailed user interface design

6

Evolutionary Prototypes

 Incremental product builds ◦ Trial versions ◦ Pilot releases

 Must be well-designed and carefully constructed.

 User feedback will come from operation in actual working environment

7

15.3 Combined Approach Throwaway Evolutionary

Horizontal - Clarify and refine use - Implement core use cases cases and functional - Implement additional use requirements cases based on priority

- Identify missing - Implement and refine Web functionality sites

- Explore user interface - Adapt system to rapidly approaches changing needs

Vertical - Demonstrate technical - Implement and grow core feasibilities client/server functionality

and communication layers - Implement and optimize

core algorithms - Test and tune performances

8

15.4 Prototyping: Suggestions

9

15.5 Evaluation of the prototype

 Ask the user specific questions (not just “what do you think?”) ◦ Is this what you expected? ◦ Is anything missing? ◦ Are there errors that weren't addressed? ◦ Is there anything unnecessary present? ◦ Is navigation logical, complete? ◦ Is anything too complex?

10

15.6 Success Factors

 Plan the effort  Have a clear purpose, draw boundaries  Be quick, not robust  Don’t prototype if you already

understand  Use plausible data  Don’t use prototype as requirements

specification

11

15.7 Risks

 Customer will ask for delivery of a throwaway ◦ Do it on paper ◦ Use nonproduction tools

 Customer will develop a poor opinion of the product's performance or reliability

12

END

13