CSE403 Software Engineering Autumn 2001 Prototyping

1. CSE403 Software Engineering Autumn 2001Prototyping Gary Kimura Lecture #5 October 10, 2001

2. Today • Today we’ll look at how to build and use software prototypes • The purpose of prototyping • Some examples of prototyping • The upside and downside of prototyping

3. What is prototyping • Building the throw away model • Building models that demonstrate properties of the real product • Building something faster and cheaper than the real product

4. Why prototype • To reduce risk • To learn while you have the luxury • How people will use and interact with the product • How to build the real product • To tweak the design before it is too late • Change requirements • Change interface • Change architecture • The goal is to convey enough information to judge the design and the process necessary to build the product

5. Examples of prototyping • The wooden Palm Pilot • Model cars • Storyboards • Mock-ups (space station, airplanes, kitchens, etc.) • A subset of an API set can be a prototype • A non-fully featured app can be a prototype (then it can act as a sales tool) • There is really a wide spectrum from paper design notes to full featured prototypes (for example a building architects sketches to stick models) • Building construction sometimes erects a sample wall (to learn how to build the real product and ensuring it meets its requirements)

6. What is in a software prototype • Isn’t the previous version a prototype • It can often be used as a basis for prototyping • What to do in the absence of a previous version • Screenshots and storyboards • Languages and tools for prototyping • Not everything is easy to prototype • UI’s are easier • API sets are hard

7. What is missing from a software prototype • The code is missing • Typically most of the error handling is missing • May not be extensible, maintainable or just well designed • Typically not fully featured • It maybe of limited size and scope • It maybe slow • The documentation, testing, performance, and support considerations are missing

8. When do we do a prototype and when to start and stop prototyping • When potential payoff outweighs the cost of doing a prototype • Finish the prototype when you’ve learned what you wanted to know • Also move on when other risks become more pressing • Slipping your schedule and spending too much money on development • But resist jumping into the coding phase before you’re really ready

9. Who builds, sees and uses the prototype • The program manager • The customer to test usage scenarios • The developer to see what to build • Testing, product support, et cetera

10. Risks of prototyping • Slows the process • A longer time to market often translates to decreased revenue • Software Design Engineers don’t like to wait for Program Management to say what to build • Software Design Engineers don’t listen to Program Management • Program Management believes their prototype should be the product • Program Management convinces upper management that the product is possible because the prototype works • Sad but true, this occurs more often than it should

11. My own experience doing prototypes • At DEC we prototyped a new system compiler • It was a derivative of a shipping PASCAL compiler • Enhanced the front end to accept a PASCAL variant • Redid the code generator for a new target architecture • Bootstrapped the system and optimizing compiler through the prototype • At Microsoft I prototyped the file system • Temporary scaffolding served to help prototype the system (e.g., basic file system operations was first provided via scaffolding) • Some of the API set really wasn’t prototyped very well • Underlying Time is messed up

12. Project prototypes & next time • Project prototypes • Do you need to do a prototype • What type of prototype • Next time (Friday) • Design • Quiz #1 • Need to turn in your project requirements draft