Prototyping Software

If you haven’t already, register a username for yourself so you can discuss this topic in our Development forum.

Selecting a program type almost automatically determines what features it will have. But there’s an additional element that needs to be considered when contemplating what the software program will offer: the end-user! Here’s what you need while building a software prototype.

Feature List

This list of features can be used to make initial decisions of what to include in your software program. This list is not protocol – it is one I refer to, and know to contain features that are build-able in the programming languages I use. You may discover others, however, every software program should have at the very least:

1. a basic window
2. a way to exit the software program
3. a help file

Beta Testers

After you’ve created a list of features you want in the software program, interview a set of potential end-users to find out what they want in the software program. Collect a group of users with different levels of computer experience, different machines, and operating systems, and then based on the results of the interviews, declare a group of people that will serve as your beta testers.

After a sufficient amount of time, compare each request from your beta testers against your Initial Feature List, Risk Management Plan, and Schedule Estimates, and then add requested features IF and ONLY IF they are possible, sensible, affordable, and able to complete by your deadline. Use a Change Control Document to weigh your choices. You may discover that some changes are just not worth it.

A Prototype of the Prototype

Based on the requested alterations, you can now build a simple Prototype. A prototype is an example, or demonstration, of what the actual software program will do. What you decide to leave out is up to you, however, if you find yourself actually *finishing* a part of the prototype as if it were the software program – you’ve done WAY too much! Some rules to follow and stick to when building the prototype are:

• Present any configuration options as a menu item – not as part of the opening screen.
• As one of the options, provide a small amount of sample data for the end user to work with.
• Make the software program automatically retrieve data, rather than have the end user remember file names and tell the software program where to find them.
• Trap errors and let the user decide how to handle them.
• Reserve the F1 key as a hotkey to present your help file.
• Describe in some type of dialog box what the software program is doing at silent times so the user knows the software program didn’t just stop working.
• Design the software program in such a way that if any key (other than the appropriate hotkey) is pressed, a help message is displayed.
• Make sure all of your hotkeys perform the same function. I.E. if the “T” key displays a text file, make sure the “T” key displays text files all through the software program.
• Provide an easy way for the end-user to return to the beginning of a section, or, even to the first screen of the program.

Feedback

Show the Prototype to the previous group of end-users for their feedback, and use this feedback to (1) revise the Prototype, (2) update the Risk Management Plan, and (3) change your Estimates until both you and the end-users are satisfied.

External Resources:

1. Effective Prototyping for Software Makers
2. Software Prototyping: Adoption, Practice, and Management
3. Object-Oriented Rapid Prototyping