The Prototyping Paradigm One of many approaches to Software Development Copyright © 2015-2017 Curt Hill

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 © 2015-2017 Curt Hill

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 © 2015-2017 Curt Hill

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 © 2015-2017 Curt Hill

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 © 2015-2017 Curt Hill

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 © 2015-2017 Curt Hill

Prototyping Cycle Interview Test Drive Prototype Copyright © 2015-2017 Curt Hill

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 © 2015-2017 Curt Hill

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 © 2015-2017 Curt Hill

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 © 2015-2017 Curt Hill

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 © 2015-2017 Curt Hill