1. 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

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
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