1. The Prototyping Paradigm
One of many approaches to Software Development
Copyright © Curt Hill

2. Introduction The basic idea is to create a prototype very quickly
The user tries it out and gives feedback
Particularly useful when the requirements are vague or the user just does not know what is needed
Copyright © Curt Hill

3. Starting The user has a general idea of what they want
These are not usually specific enough to be properly specified requirements
They do not rise the level that the waterfall model requires
This may be complicated by other facts
Is it even possible?
Will it be too slow/large to be practical?
No idea what the interface should look like
Copyright © Curt Hill

4. Prototyping
After gathering as much information as possible development starts
We make an implementation as speedily as possible
Quick and dirty
No concern for efficiency or many other things we often care about
We often use a language that we would not normally use, such as interpreted languages – anything that will make it quick to implement
We do not put in every feature
Copyright © Curt Hill

5. The Test Drive
After as little training as we can one of the users tries it out
The feedback from this determines what happens next
There are approximately three outcomes
Copyright © Curt Hill

6. User Responses Mostly satisfied – we can do one of a couple of things
Let this be what they end with
Throw that one away and do it right
Seems to be on right track
Revise the prototype and go through the cycle again
Need to guarantee that we get our requirements right
Completely off
Junk prototype and start over
Copyright © Curt Hill

7. Prototyping Cycle Interview Test Drive Prototype
Copyright © Curt Hill

8. Disposable Code? Yes! Definitely!
Once we have decent requirements we throw away the prototype
It was not built with any of the quality we would like
Now that we know what is needed we can do it right
Only in rare cases do we let them keep the prototype
What would these rare cases be?
Copyright © Curt Hill

9. Notes
Once the developers understand the true requirements they may choose any other development method
The user will often settle for the prototype with a few enhancements
This is almost always a bad idea
The prototype was not designed for efficiently or to be robust
Maintaining the prototype will be far more expensive than a properly designed system
They must know that the prototype is temporary
Copyright © Curt Hill

10. Incremental?
If the only goal of prototyping is the production of good requirements
Then we do not consider it evolutionary
The usual practice is to throw away the prototype and create the working system with another better system
Still, some would consider this incremental because of the cycle of prototypes
Copyright © Curt Hill

11. Finally The Prototyping method is best used when:
Considerable question on requirements
Feasability is also an issue
The main purpose of the prototype is to determine requirements and feasibility
In rare cases the user ends up with the prototype
Copyright © Curt Hill