A. Description of the topic

Although the word "prototyping" has not made it into the dictionary yet, Webster has several definitions for the noun "prototype." The last applies best.

prototype: a first full-scale and usually functional form of a new type or design of a construction (as an airplane).

We in Information Systems (IS) are not the first to use the word "prototype," anymore than we are first to prototype. As Webster notes, our friends in aerospace build prototypes, and they started long before we did.

In particular, "software prototyping," may be defined as follows:

Software prototyping is an information system development methodology based on building and using a model of a system for designing, implementing, testing, and installing the system.

Prototyping is a methodology. Since a methodology is a collection of methods, you may organize the methods into steps. You may write them down in the order in which they should be executed. You may teach both the steps and the order in which they should be done. Prototyping is done in a systematic way, and that way can be described, i.e., can be taught, scheduled, measured, compared, and modified - which are the components of any methodology.

B. Importance of the topic

Prototyping, as a methodology is important in building fast, better, more reliable, better quality systems. Here is why and how that can be achieved.

Prototyping is based on building a model of a system to be developed. Moreover, the initial model should include the major program modules, the database, screens, reports, and the inputs and outputs that the system will use for communicating with other (interfacing) systems.

Prototyping uses the model for designing the system. The initial version of the prototype is not full system, but it does contain its designer's understanding of the database, screens, and reports. As the user and Information Systems people begin to work with the prototype, it will change. The initial version of the prototype is a skeletal version of the system; it does not contain all the processing and validation rules that the system will ultimately have. As those working with the prototype modify it and add to it, they will be completing the design of the system. So, the prototype will be a vehicle for designing the final version of the system.

Prototyping uses the model to implement the system. In today's average organization, you write programs in some problem solution language, such as COBOL, to implement a system. The initial version of the prototype will consist of programs written in some language (possible a fourth generation language) to move data back and forth between the screens, the database, reports, and the inputs and outputs used to communicate with interfacing systems. At first, these programs may do little processing; they may actually dummy it. As prototyping process continues, newer versions of programs, that perform more closely to those of the ultimate system, will replace the original versions. For example, a program that actually extracts data for a report from a database may replace one that dummied out data.

Prototyping uses the model to perform both the system and the acceptance testing of the system. The initial version of the prototype, as well as all subsequent versions, will communicate with system test versions of feeding systems and systems to be fed. So, the prototyping will always run in "system test" mode. And, since the user will be working with the prototype from the beginning, the user will be performing "acceptance testing" of the prototype from the beginning.

Prototyping does not go beyond a mock-up if, after building and experimenting with the initial model of the system, and possibly making a few modifications to it, you abandon it when you have gained a good understanding of the requirements. A prototype as a mock-up is valuable. With the Prototyping Methodology, even though a prototype may be little more than a mock-up when it is first built, it becomes the first one of its kind by the time it is finished. So, when the prototyping process ends, the prototype has become the system.

C. Background

The prototyping as a methodology evolved from the engineering discipline. Even more, a classical life cycle had been a prerequisite to prototyping. If the present system is to be studied, Information Systems professionals usually do it. The present system may be manual or a combination of manual and office machine processes. In most of today's medium to large size organizations, systems also contain some computerized processes.

The components of Systems Development Methodology are: Study Present System, Determine Feasibility of New System, Define Requirements, Design, Program, Test, Acceptance Test, Train Users, Convert from Old System, Install. The plan for a classical, non-prototyping "life cycle" style project should look something like the process just previously described: linear, perhaps containing couple of iterations. In a "life cycle" methodology, the various project phases usually follow each other serially. About the only overlapping that is done is training the users at the same time as converting to the new system.

The "life cycle" methodologies emphasize scheduling and meeting milestones, producing documentation at the milestones and getting signoffs on it, no signoff being more important than the user's signoff of the requirements or the final acceptance of the product.

The steps described above for the "life cycle" methodologies, are still being followed by the prototyping methodology. The only difference is the overlapping. One thing that is different about the prototyping is therefore the overlapping of most of the project phases with each other. This implies that prototyping provides the iteration which is often sought in developing Information Systems. Actually, prototyping provides more than an iteration of phases; it provides a continuation of phases.

The requirements definition begins after the present system has been studied. Before the requirements definition is completed, the design begins. Soon after it has begun, the programming begins. Shortly after that the testing, acceptance testing, the user training begin. The milestone dates for completing the requirements definition, design, programming, testing, and acceptance testing are usually the same date. The completion of user training is probably the same date as the completion of conversion. Installation begins after that.

The prototyping methodology emphasizes the streamlined aspect. The streamlined phases are: Define Prototype, Build Prototype, Exercise Prototype.

D. Current state of the art

Currently Prototyping Methodology is having a larger and larger use in more and more organization. Part of the reason is the creation of software tools that allow the implementation of such methodology or approach to develop software.

Also, because the above described Prototyping Methodology presents the following principal advantages:

• Please users

• Reduces development cost

• Decreases communication problems

• Lowers operations costs

• Slashes calendar time required

• Produces the right system the first time

• Cuts manpower needed.

However, Prototyping Methodology has also disadvantages. Her are some of the possible ones:

• Visible use of computer resources

• Object system may be less efficient

• Requires cooperation between user and Information Systems

• Some view prototyping as an art not a methodology.

The current methodologies, as said, have a series of problems. Here is a partial list:

• Are thorough BUT DON'T please users

• Produce extensive documentation BUT DON'T decrease communication problems

• Identify project steps BUT DON'T decrease calendar time needed

• Describe system thoroughly BUT DON'T guarantee it's the right system

• Delineate skills needed BUT DON'T cut manpower needed

• Track project costs BUT DON'T reduce them.

E. Applications

Despite all the good, positive review of advantages of Prototyping Methodology, this is not a panacea. There are situations, projects where the Prototyping Methodology are recommended. But there are many others where it is not.

For instance, prototyping is useful in developing on-line systems. Most people writing about using prototyping would agree with this. Moreover, on-line systems are very difficult for systems designers to visualize if they are only working on paper. Using some kind of prototyping, at least for the flow of information to and from screens, is a natural solution to this problem for many designers.

Prototyping uses a model to design and develop a batch system the same as it does for an on-line system. But its usefulness for batch systems is difficult for many people to understand. As was said above, it's a "natural" for on-line systems; they're a part of the new technology, as is prototyping. They go together. batch systems are different. After all, we've been doing batch systems for years; by now we certainly know how to do them. After all, batch systems don't have any screens. Users have trouble visualizing what should be on a report, but, as you each of us may have experienced many times, they know what they don't like when they see a report. Prototyping solves these problems and provides all its other advantages.

Prototyping is useful for systems based on software packages. It also provides extra value, if it is used in the package selection process. Nevertheless, it is still valuable, even when it is not introduced until the installation of the package. A package is either installed or without modifications. Package modifications include options or exits provided by the package and adding pre-processors and post-processors to the package. Building a prototype that consists of the package with its modifications should provide all the advantages of prototyping.

Also, generally, large, complex Information Systems requires a more pragmatic "life cycle" type of methodology; in some cases with small islands of prototyping, here and there. Smaller, less mission critical applications are much better suited for a prototyping methodology. Also, today's supporting software tools, just proves this idea.

Just having fourth generation languages does not guarantee that you can prototype. And using them does not necessarily mean that you are prototyping. Many organizations that have all those aids do not prototype or, if they do, they do not feel that their prototyping is productive. Here is a list of what is needed to prototype:

• Understanding the data

• Moving data through the system and to and from connecting systems

• Exercising the prototype frequently

• Building and modeling the prototype quickly.

The most important is perhaps the first requirement. You need to understand the data to design and build the initial prototype model. And, this initial prototype model will consist of:

• Major program modules

• Database

• Screens

• Reports

• Inputs and outputs for interfacing systems.

Tools that will help you prototype are tools that will help you understand and move the data, and exercise and modify the prototype. None if them may be essential, but using at least some of them will help you to prototype. Following is a list of such tools:

•• Understanding the data:

•• Data Dictionary

•• Interactive testing

•• Test data generator

•• Library control of program modules

• Exercising the prototype:

•• Interactive Testing

•• Test Data generator

• Modifying the prototype:

•• Interactive Testing

•• Library control of program modules

•• Fourth generation language (Report Writer, Screen Painter, Query Language)

•• Relational DBMS.

F. Future directions

The future directions of Prototyping Methodology are, as above mentioned, strongly dependent of the fully and correct understanding of this process, its methods and techniques. Also, an understanding of both advantages and disadvantages of this methodology as compared to classical "life cycle" methodologies.

A great contribution, lately, to the popularization of Prototyping Methodology, was the changes in economics condition of the late eighties and particularly the nineties. Building Information Systems faster, cheaper, and with better quality requires a different approach than the classical "life cycle" like methodology.

Also, the creation of an entire new set of tools that supports the concept of rapidly building an application, screens, forms, reports, etc., galvanized the transition from the classical to the more modern approach to software application development: prototyping. Also any major software manufacturer today offers a variety of such prototyping tools. Even their traditional products, changes their face or added interfaces to tools that will provide for prototyping approach to software development. Graphical User Interfaces (GUI), empowerment of user community, more and more computer literate, as well as the groupware approach to computing added to the support for a prototyping methodology.

G. Conclusions

Prototyping, as a new and continuously emerging methodology to software development, is one of the most interesting development in the computer industry of the '90s. If couple of years ago, it was regarded to some skepticism, or employed in isolated situations, it become a recognizable alternative approach to the classical "life cycle" methodology. It's use will continue to grow, due to both new and more restrictive economics conditions, that require better productivity, and increase in sophistication and availability of supporting software tools.

And not to neglect, the more and more computer literate user community, that will less and less rely on the classical MIS department to have access to data and extract the business needed information.