Why do we use software prototypes?
As software engineers it is possible to use prototypes in order to be able to investigate concepts, visualize design options and help research alternative solutions for the problem on hand. A software prototype helps in many ways:

1. Having a prototype helps the elicitation of further system requirements. When customer stakeholders actually see a prototype, from experience, most of the times say that something is missing. This process is very helpful in validating system requirements.
2. User interface design is a key factor for the success of the software under developement. Presenting and collaborationg wirth end users using a UI prototype is a very nice way of producing widley accepted interfaces.
3. A prototype can be used in the testing process comparing it with the system to be delivered to the customer. That means, entering in both systems (prototype and application) the same data and compare the output results. If the results are identical then there is no fault detected. (Sommerville, 2006, p.409-410)

Although prototypes have great benefits for the software project, they hide some dangers. One major danger is to use a prototype and develop it further to a product. The prototype is for experiments and proof of concept. It has no “depth” or quality build in it.

Using a prototype can be viewed as a risk reduction process. This process may introduce new risks to the project if not handle carefully. Except the risk mentioned above there are also other risks involving the software prototype. The risks are:

1. The customer gets a wrong impression on the stage of development. Seeing a working prototype is confusing to him and thinks that the software is almost ready. It is of paramount importance not to let stakeholders to think of the prototype as an early version of the software system.
2. Users may confuse the hows of the user interface and not focus on what’s of the prototype. The prototype will be used to validate the requirements of the system and not how the system will look and how it will operate.
3. Users may believe that the prototype performance will be the end software product performance. It must made clear to customers that in the prototype are not any security features or optimized algorithms. A good habit is to use a delay timer to simulate the actual system response time.
   (Wiegers, 2003)

From personal experience I know that stakeholders confuse the prototype as an early version of the system. I was building hotel management software to handle the front office jobs of a hotel. I delivered a prototype to the customer soon after we had finalized the description of the software requirements. The prototype was to test what the menu navigation would be, what critical functions (reservations) the software will perform. After the demonstration of the prototype the customer refused to believe that it will take several months of development to finish the product. It took me several meetings with the customer to convince her that it was a prototype and not an early version of the software. Sometimes managing customer expectations can be very difficult.

As a conclusion software prototyping can reduce the ambiguity of functional requirements and shorten development schedules. We must include time in the project schedules for building several prototypes and state why we want to build them. (Wiegers, 2003)

From my experience even early prototyping screen mock-up on paper can help describe the requirements of a software project.

What software can be used to create prototypes?
I have used pencil sketching for Mozilla Firefox, I know that Adobe’s Dreamweaver can be used for fast prototyping. An idea is also to use Iron Speed designer. There are many more tools listed in Cunningham & Cunningham wiki.

References

Sommerville, I (2006). Software Engineering. Addison Wesley / Pearson 8th Edition. ISBN: 0321313798

Wiegers, Karl E. (2003). Software Requirements, Second Edition. Microsoft Press. ISBN: 9780735618794