The Prototyping Methodology

Tad Nelson

Prepared for:

Dr. Rob Mohammad

ISAM5635

Tuesday Night

Spring 2003

Prototyping Methodology

In general prototyping is the rapid development, structuring and testing of a working model. This working model is called a prototype. The prototype is based on new applications in the interactive and iterative process. Prototyping makes the development process faster and easier. Prototyping is sometimes referred to as rapid application design (RAD). One major benefit of prototyping is that is has brought the end user into the application.Prototyping is much like a rough draft of a document. It still needs to be polished, but allows you to begin solidifying ideas, correcting major errors, and even start over without a lot of lost time. In this brief I will try to dispel some of the myths about the problems with prototyping while articulating some of some benefits. The one certainty that I must begin is the bottom line that prototyping has become a mainstay in system development.

Prototyping and iterative design have a reputation for being difficult to manage. The keys to managing a prototyping effort are becoming clear, however; they include knowing what you want to learn from the prototype, access to rapid prototyping techniques, and end-user involvement in development of the prototype. The prototype will be the vehicle for developing the full requirements for the system, and its definition will be the preliminary requirements for the system. Just as you do not need to develop the full requirements before you build the prototype, you also should not attempt to build the prototype without some kind of a definition of it. Defining the prototype before building it helps users and Information Systems people think through the basic functions of the system. It is a valuable thing to do, even if the prototype may change considerably when the user actually begins to see its outputs. One criticism that is often made of prototyping is that the requirements phase of a project using prototyping is too expensive, and keeping the requirements and design phases from running into each other is too hard. If those who are prototyping do not know what is needed for the prototype nor when they may begin building it, they may waste time and resources.

With all that said I remain a staunch supporter of prototyping. Before I begin explaining the benefits of prototyping I think it wise to discuss some of the pitfalls of prototyping. One of the first problems with prototypes is standardization. Standardization results when the prototype is shaped by tools available rather than the user’s needs. Another problem is distraction, which means the prototype can be problematic because it takes attention away from the problem to be solved. A third is seduction; the developers getting so involved in the romance of the prototype system. This can cause the system to come in way over budget or way behind schedule. Rejection is another major problem. As problems present early in the development cycle and costs associated with ideas sky rocket the project can be scraped.

These problems can be avoidedif the prototyping team focuses on a few logical questions: What are you prototyping, and why? What do you expect to learn? When do you need it in order to affect the product? How will you know when to stop? The answers to these questions come from users, and from nowhere else. You are prototyping a solution to users' problems. You learn what those problems are, and you stop when you have a proven solution.

With all the problems understood, they are quite easy to avoid. The main thing to remember is to always keep in mind the end user. If the prototyping experience is to remain positive it is imperative that every issue, every question, and every development idea be examined from the perspective of the end user.

A rough summary of the steps in a developing a prototype are as follows:

1)Investigation – having the end user identify the needs and evaluate the feasibility of several alternatives.

2.Analysis – to end user assists the developer with the use of the interactive design and then tests prototypes of the system components that meet the users needs.

3.Design – includes extensive testing, evaluation, and modification of the system until the end user is totally satisfied and the system is acceptable.

4.Implementation – the accepted system is agreed upon and the system documentation is prepared and the system is ready for full release.

As the steps indicate, prototyping is an iterative, interactive processthat combines steps of the traditional system development cycle (SDLC). The system is designed in a series of interactive sessions between the end user and the system analyst. The prototype is usually reworked several times until the end user finds it acceptable and signs off. Once that is completed the system is turned over to the end user for operational use.

How Prototyping Works

The prototyping process starts when an idea for improving a product, whether in terms of requirements, understanding the users, or designing an ultimate solution begins. Proper use of prototyping can help keep the development effort focused until the solution is well defined. The prototyping process is full of goals. The whole purpose is based on the desire to plan, implement, measure and learn about the as-is system relative to the to-be system. The entire process is based on the desire to fill a need with a system that brings about a solution to what ever problem.

In the plan phase, you are trying to understand your users and their needs, as well as how you want to address those needs. Then you build. Once built the focus changes to measuring the results of the new system against the desired results of the system. It is the use of measuring that is the essence of evaluating the effectiveness of the prototype in this particular system.

There can be many reasons that a prototype does not achieve its goals. Sometimes these will be implementation issues, but more often the problem will be an incorrect or insufficient understanding of the users or the work they need to accomplish. Again, it is this understanding that will eventually bring us back full circle to an evaluation of how much effort was put into understanding the needs Users bring their own preconceptions and perceptual abilities to the new system. They use only as much of the system as they need to, and learn only from what they use. What they learn, they learn through trial and error. Unpredictable or inconsistent behavior in your product will distort or even destroy a user's desire for product integration. And remember, this user model begins to form before the user begins using the system built for the user.

You want to deliver the essence of the system to your users. Minimalism is a virtue in interface design- this is the ultimate less is more category. If it doesn't communicate currently available function or the current state of the user's data, get rid of it. Anticipate errors, and prevent them if at all possible. The user's every thought and gesture should be spent on the task, and never on housekeeping. And the user decides what to do next, not the product. The user is always right.

Conclusion on Effective Prototyping

If the project team does not understand the system and define it well, the prototyping will certainly flounder, if it does not fail. The results of the screen, report, and function definitions should prompt the information definition, even though they can proceed at the same time. The team members who are responsible for the definition of the information should be persistent, thorough, and able to judge the completeness of their results. Estimating the work to be done, planning it, scheduling it, publishing the schedule, and adhering to it or crucial to a final successful system. After the team conferences are finished, you may define the screens, reports, functions, and information simultaneously, if enough persons are available. Since the number of reports and screens and the complexity of the information may not be known until after the talkthroughs, you may want to prepare a preliminary plan and schedule for this phase before the team conferences begin, then modify them after they are completed.

All of this is important as we enter the implementation stage. Implementation will involve the major question of conversion. Conversion is the process of bringing the system on line. The end users’ concerns about the new sydtem really need to be respected when it comes to bringing the systemin. Conversion methods can really soften the impact the new system has on the organization.

At the end of the day prototyping is a highly successful way to implement a new system. I do believe I have stressed the one major issue that is relevant to all analysts when bringing a new system to the organization and that is “include the end-user from the beginning to the end and it will effect the ability to have a successful crossover exponentially.”

Resources:

Norman, Donald A., The Design of Everyday Things.New York: Doubleday Currency, 1990.
Diane Wilson, Prototyping in the Software Development Cycle, 1998.
Senge, Peter, The Fifth Discipline: The Art and Practice of the Learning Organization, New York: Currency Doubleday, 1994.
Lantz, Kenneth, The Prototyping Methodology, 1987.