CSE403 Software Engineering Autumn 2000 Prototyping CSE 403 Autumn 2000 CSE403 Software Engineering Autumn 2000 Prototyping Gary Kimura Lecture #5 October 4, 2000 October 4, 2000

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

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

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

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)

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

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

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

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

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

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

Project prototypes & next time Do you need to do a prototype What type of prototype Is the demo code that you’re getting Thursday a prototype Next time (Friday) Need to turn in your project requirements Then next Friday need project plans or design specs including one for each sub-group, and a timetable More definition of what each sub-group needs to be doing