Atwater, Lantz, Hunter & Co.

submit 1099s  |  Prototyping | Implement Systems | Public Relations Support | systems Development Strategy | Workshops |  Humor

Site Under Construction






Two of the severest problems facing Information Systems

groups today are the increasing backlog of service requests and

the decline in user confidence. These problems, in turn, are

eroding the influence of Information Systems within their


The proper use of prototyping will alleviate these problems

and consequently enhance the influence of Information Systems.

Numerous articles about prototyping have appeared recently.

Most people think they know what it means. A lot of

organizations have tried it. But prototyping is not easy. If

you have attempted it, you know this is true. Most organizations

are not receiving the full benefits of it. Many Information

Systems managements are rightly leery of using it without a


The purpose of this book is to explain what prototyping is

and to provide a methodology for using it.

This book should help you whether you are a programmer,

analyst, project leader, manager, director, vice president,

consultant, or student of Information Systems methodologies.

This book should also help you if you are a user of Information

Systems services who wants to learn about prototyping.

If you are considering whether to prototype, this book is

for you.

If you have prototyped, or are prototyping, and want to

improve your approach, this book is for you.

If you want to learn how to prototype, this book is for you.

If you only want to learn about prototyping, this book is

for you, too.



What Prototyping Is

Although the word "prototyping" has not made it into the

dictionary yet, Webster has several definitions for the noun

"prototype." The last1 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 are not the first to use the word

"prototype," anymore than we are the first to prototype. As

Webster notes, our friends in aerospace build prototypes, and

they started long before we did.

The subject of this book is "software prototyping," not all

forms of prototyping. After applying words carefully in the

definition, this book will normally use the simple term

prototyping, as is commonly done in the Information Systems


The definition:

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


Table I-1 shows the important features of a methodology.

A Methodology Is Something You Should Be Able:

. to teach

. to schedule

. to measure

. to compare

. to modify

Table I - 1 Features of 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.

When you are using a methodology, you may estimate the time

and resources that you will need for each step in an application

of the methodology and for any project, as a whole, on which you

will use it. You may prepare a schedule from these estimates.

When you are managing projects on which a methodology is

used, you may measure progress against the schedule and the plan.

You may compare the use of a methodology on one project with

its use on other projects, and you may compare its use by one

group to its use by other groups. You may also compare one

methodology against other methodologies intended for similar


You may also modify one or more parts of a methodology based

on your experience with it and your measurements and comparisons

of its uses.

Prototyping is a methodology; it is a collection of methods.

It is done in a systematic way, and that way can be described

(the premise of this book).

Many in Information Systems management have viewed

prototyping as a "quick and dirty" approach talented people use

for urgent systems projects. These people often seem to be

"winging it," when they're prototyping, taking shortcuts that

eliminate necessary steps in the system development process. For

this reason, Information Systems managements are often cautious

about using it. Even if they used it once or twice on critical

projects, it was not systematic enough for them to use it

generally. They want a methodology, for all the advantages that

a methodology brings.

Prototyping Is Building a Model

"What do you really mean by prototyping?" people often ask.

"Do you actually mean doing such things as setting up the

database and the screens for updating it?" The answer must be an

emphatic "Yes." Prototyping is based on building a model of the

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.

If you want to design and build a model of something, you

must first learn about the thing you want to model. An

assumption of prototyping is that you don't need to know the full

requirements of a system in order to build the model. In fact,

an important product of prototyping is the completed

requirements. But you must know enough about the requirements to

build a useable initial model.


. Major Program Modules

. Database

. Screens

. Reports

. Inputs and Outputs for Interfacing Systems

Contents of Initial Prototype Model

Using the Model for Designing the System


Prototyping uses the model for designing the system. How

can the model be a means for designing the system? When the

designer designed the prototype, he designed the system, didn't

he? No, he only designed the prototype. Now that prototype will

become the vehicle for designing the full system.

The initial version of the prototype is not the 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.

Also, remember 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.

Using the Model for Implementing 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 (possibly a fourth generation language)

to move data back and forth between 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. For example, a program

that produces data for a report may generate the data from "hard

coding" instead of extracting it from the data base.

As the 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. Originally, you may write

most versions of the prototype's programs in fourth generation

languages; later you may rewrite at least some of them in the

language you have chosen for the production version of the


Using the Model for Testing the System


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 prototype 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.

Using the Model for Installing the System


Prototyping uses the model for installing the system. Those

who must learn how to work with the production system as part of

the installation process - normally, users - will learn how to

use it by working with the prototype. The prototype produces

material, such as sample screens and reports, which is useful for

the documentation done as part of the system installation. Also,

part of the prototyping of a system is the prototyping of any

conversion process required for installing the system.
       The Prototype Becomes the System.  We have not consistently used 

the concept of a prototype in Information Systems. Often, when

we use the word prototyping, we are really talking about building

and using mock-ups. A mock-up, according to Webster, is different

from a prototype. Webster defines a mock-up2 as follows:

mock-up: a full-sized structural model built

accurately to scale chiefly for study, testing,

or display

The mock-up of a system is a skeletal version of it; from the

outside the mock-up generally behaves like the system itself

eventually will. Inside it may be doing little more than moving

data from program stub to program stub. The aerospace and the

automobile industries use mock-ups for such things as wind-tunnel

testing. In Information Systems, we use mock-ups for such things

as testing the structure of a new system.

The definition of a mock-up, as it applies to developing

systems, follows.

A software mock-up is a system development

approach based on building and using a model of a

system for discovering the requirements of the


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.

Following this approach, you primarily use the model, often built

with fourth generation languages, to help the user visualize the

system better, and to verify and to expand on the basic

requirements. But instead of expanding the model into a full

prototype, you use more traditional means to document what the

full system should do, then build the production version of the


A prototype as a mock-up is valuable. Nonetheless, it does

not provide all the benefits of a full prototype, as discussed


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 system3.

| |

Prototyping Methodology


The first question to be answered for the Prototyping

Methodology or any other systems development methodology, such as

the currently popular "life cycle" methodologies, is what does

the methodology require that you do? Table I-4 lists those

things which must be a part of any systems development

methodology for it to be complete.


. Study Present System

. Determine Feasibility of New System

. Define Requirements

. Design

. Program

. Test

. Acceptance Test

. Train Users

. Convert from Old System

. Install

Table I - 4 Components of Systems Development Methodology

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, most systems also

contain some computerized processes.

The aim of any study of the present system should be to

discover the data that is processed, filed, and used in the

system, the volumes of data that are processed, the timing of the

system's processing, how it communicates with other systems, and

any problems with its operation.

Before the decision is made to begin a project for a new

system, Information Systems people, often working with people

from other components of the organization, may determine the

project's feasibility. This determination includes understanding

the business problem to be addressed by the proposed system,

doing a preliminary design of the new system, estimating the time

and other resources that would be required to implement it,
examining alternatives, and deciding whether and when to proceed.

Defining the requirements of a system is a process of

thinking through what a system must do and communicating the

results of that thinking to those who will design the system.

Designing a system is determining how to meet the system's

requirements. It may be done in steps: the first step is to

define the major system's processes and to identify the data to

be processed; the second step is to do the physical design of the

system's programs and database.

Programming a system includes determining in detail

(specifying) how the individual parts of the system will work,

translating the system into machine-readable programs, and

performing the unit testing of these programs.

Testing is the system testing of the communication between

the different parts of a system and between the system and the

other systems with which it communicates. The basis of system

testing should be a plan that describes what is to be tested and

how the testing will be done. System testing is first done with

relatively small amounts of test data. After the system has run

successfully with it, the system is tested with a full volume of


Those who will use a new system (the user) acceptance test

it to ascertain whether it meets their requirements. After a

successful acceptance test, the user usually "signs off" the

system, so that it may be "put into production."

Those who will use the new system must be taught how to use

it. If there is to be any user documentation, it should be

written ahead of time, so they may use it in their training.

A new system rarely starts from scratch. Even if the old

system is entirely manual, it probably contains data that must

somehow be converted for use in the new system. If the data is

in, or can be put into, machine-readable form, programs may be

written to convert the data to the new system's database.

Installing a system includes developing production copies of

all the programs in the system, writing and testing instructions

to the operating system, and documenting the system for the

computer operations staff and those who will be maintaining it.

Installing a system should also include establishing a permanent

test version of the system.

Classic Life Cycle versus Prototyping


The plan for a classic, non-prototyping, "life cycle" style

project should look something like that shown in Figure I-1.


|Det. |Study |Define |Design| | |Accep-|Train|
|Feasi-|Present|Require-|New |Program|Test|tance |Users|
| | |

(no time scale intended)
Figure I-1 Typical "Life Cycle" Project Plan

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. These methodologies may lead

us to view the Information Systems development process as a set

of rigorously distinct phases performed at separate times. Each

phase depends on the immediately preceding phase, and those doing

the work may not begin the next one before the previous one has

been completed. It is difficult for those who are used to the

"life cycle" methodologies to imagine beginning programming

before the system design has been completed. It is even more

difficult for them to think of beginning system testing before

the programming has been finished. Moreover, even if they could

imagine these things, they would never do them.

Those of us who have designed and implemented information

systems recall often feeling a strong impulse to iterate what we

were doing. Maybe we felt we should somehow repeat at least part

of the phase we were working on. Perhaps we thought we should

examine things again that had been determined in earlier phases.

Following the "life cycle" methodologies has helped4 us. But,

the "life cycle" methodology, especially the milestone dates that

we had promised to meet, kept us from succumbing to the

temptation to iterate. After all, if we ever started, HOW WOULD


The plan for a project following the Prototyping Methodology

should resemble figure I-2.

One thing that is different about the prototyping plan above

is 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.


|Det. |Study | Define |
|Feasi-|Present| Requirements |
| Design |
| New |
| |
| Program |
| |
| Test |
| Acceptance |
| Test |
| Train |
| Users |
| | |

(no time scale intended)
Figure I-2 Typical Prototyping Project Plan

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, and 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.

This does not mean that a feature of the system is designed

before there are requirements for it. Nor does it mean that

something is programmed before it has been designed. And how

could something be tested before it was programmed? What it does

mean is that things learned during acceptance testing

influence the requirements for additional parts of the system,

and subsequently the design, programming, testing, acceptance

testing, and training. Changes in the design certainly affect

the programming. The programming affects the testing.

Everything that goes before affects the user, who is learning the

system as he does the acceptance testing. So, in a sense, the

work of these phases continues until they all have been


Much of the work of defining requirements will be finished

before most of acceptance testing is done. Likewise, much of the

design will have been completed, before most of the system

testing is done. Yet, things discovered during system testing or

user training or acceptance testing can and should affect

requirements definition and design and programming.

Later chapters of this book will provide more detail on the

different phases of the Prototyping Methodology, but a few

additional comments here may preclude some misunderstandings.

Even though the two figures were not drawn to scale, if you

compare the "Prototyping Methodology" to "How It Is Usually Done"

you may conclude that using the Prototyping Methodology will

require less calendar time for a project than following a "life

cycle" methodology. That's an accurate conclusion.

If you compare the figures further you may notice that the

individual requirements, design, program, test, acceptance test,

and user training phases will take longer under the Prototyping

Methodology than under a "life cycle" methodology. That's also

an accurate conclusion. But you should also consider that

because they overlap each other, they will take less calendar

time together than they will in the "life cycle" methodology.

Because some of the phases are longer with the Prototyping

Methodology, you might conclude that the Prototyping Methodology

will require more manhours from Information Systems people.

Actually, the Prototyping Methodology should require less

manhours from Information Systems people. But, it will require

more manhours from the user than he is likely to expend with a

"life cycle" methodology.

Figure I-3 might imply that the Prototyping Methodology is

simplistic and does not include all the things that must be a

part of any systems development methodology. That is not true.

Prototyping is streamlined, but it is not simplistic. The figure

emphasizes the streamlined aspect of the Prototyping Methodology.


|Det. |Study | Define |
|Feasi-|Present| Prototype |
| Build |
| Prototype |
| Exercise |
| Prototype |
| | |

Figure I-3 New Way of Looking at Prototyping Project Approach

The streamlined phases are:

. Define Prototype

. Build Prototype

. Exercise Prototype.

Table I-5 relates the prototyping phases to the traditional


|Prototyping includes Traditional |
| |
|Determine Determine |
| |
|Study Present Study Present |
| |
|Define_Prototype______________________ Define_Requirements|
| |
|Build Prototype Design |
| |
|Exercise Prototype Test |
| Acceptance Test |
| |
| |

Table I-5 Prototyping versus Traditional Project Phases

Why Prototype


Table I-6 lists the principal advantages of prototyping.


. Pleases users

. Reduces development cost

. Decreases communication problems

. Lowers operations costs

. Slashes calendar time required

. Produces the right system the first time

. Cuts manpower needed

Table I-6 Advantages of Prototyping

Prototyping pleases users. Instead of only going to

requirements meetings and walkthroughs, reviewing screen and

report layouts, and signing off various documents, many of which

he may not fully understand, the user actively participates in

the design and development of the system on a day-to-day basis.

Prototyping makes him feel far more involved with the new system

than the "life cycle" methodology could ever make him feel. He can

exercise the system everyday. If the system doesn't meet his

needs, he can request modifications and see them quickly.

        Prototyping reduces the total cost of system development.  
        According to Gremillion and Pyburn5, "A number of companies report 

that total systems development costs by the prototype approach

are usually less than 25% of the costs with the traditional


Prototyping decreases communication problems, not only

between user and Information Systems people but also between

those working on the new system being prototyped and those

working on systems it must communicate with.

Since the user actively participates in the design and

development of the system, he does not have the severe

communication problems that sometimes occur when other

methodologies are used. Also, since the prototype itself, not

paper, is the main medium of communication of system functions

between the user and Information Systems people, they

misunderstand each other much less. People can tell you what

they don't like about an existing system more easily than they

can tell you what they want in a system you are designing on


Systems development plans usually leave the system testing

of a new system until the very end of the project. And the plan

never seems to allow enough time for correcting problems, if

system testing does not go well. Needless to say, problems

often do occur, and fixing them adds an embarrassing delay to

installing a new system. In contrast, the Prototyping

Methodology requires that, from the first, the prototype be

"brought up" in system test mode, so it may communicate with any

systems that feed it or any that it must feed. System interface

problems should be solved as soon as they are found, because the

prototype may not run properly until they are corrected. Also,

as prototyping progresses, if any modifications to the prototype

impair its communications with interfacing systems, they will be

detected and quickly corrected.

Prototyping lowers operations costs. Systems developed by

prototyping use less computer resources. This advantage is the

opposite of what many people expect; they think all systems

developed by prototyping contain at least some parts written in a

fourth generation language, making the systems computer resource

"hogs." But the use of fourth generation languages is not a

necessary part of prototyping, as is discussed later. Certainly,

if operational efficiency is a criterion for a system and if the

use of fourth generation languages would prevent it, a system

developed through prototyping would not contain programs written

in them. Remember, though, that fourth generation languages are

becoming more efficient day by day.

So, leaving the inappropriate use of fourth generation

languages aside, how are systems developed through prototyping

more efficient in the use of computer resources than systems

developed in other ways? They produce less reports and screens

programmed to meet the "I think I need a..." requirement. Users

often think they need a report or screen, which they never use

after the system is installed. Systems developed through

prototyping do not usually produce such reports and screens.

Also, systems developed through prototyping contain fewer

validations and unnecessary controls. Users realize what it will

cost and the time it will take to add validations that might be

nice, but which they do not feel are necessary, when they learn

how the system will operate. Also, Information Systems people do

not add controls that they might have otherwise added, because

they did not know how the user would work with the system.

Prototyping slashes the calendar time required to complete a

project. Since the work of several phases is done concurrently,

a project done with the Prototyping Methodology should always

take less time than one done with the "life cycle" methodology,

unless significantly less resources are used with the Prototyping

Methodology. For example, if a project that would require ten

people with a "life cycle" methodology is only staffed with two

with the Prototyping Methodology, it will probably require more

calendar time with prototyping, despite the overlapping of phases

that prototyping provides.

Prototyping produces the right system the first time. It

would be difficult for it to do otherwise, with the active

participation of the user in the system design and development

and the constant running of the prototype with interfacing

systems. Also, the requirements that are the basis of the sytem

are not theoretical; they are developed from actual experiences

with the prototype.

Prototyping cuts the manpower needed for a project compared

to what would be required using a "life cycle" methodology.

Table I-7 lists the factors that influence this.

Excessive documentation is not needed with the Prototyping

Methodology as it may be with a "life cycle" methodology.

Because communications are often not good between users and

Information Systems people, documenting the system in great

detail seems to be good business practice. Some view the reason

for such documentation as protection for Information Systems.

Although essential documentation is a part of the Prototyping

Methodology, the work required to produce such excessive

documentation does not need to be done.


. Doesn't require excessive documentation

. Good communication takes less time than poor


. No last-minute surprises requiring major


. Much of user training a by-product not

a separate phase

Table I-7 How Prototyping Methodology Cuts Manpower Needs

Good communication requires less time than poor

communication. Often "life cycle" review and status meetings

seem to get off the track. Documentation and correspondence

often seem to confuse the recipients. When people who are

supposed to be working together don't understand one another, it

seems to take extra time to communicate simple information. But

when people are working together effectively on a project they

all understand, much more is communicated in much less time.

The constant, incremental development and testing (both

system and acceptance), which are an important part of

prototyping, keep any one problem from becoming a major consumer

of time. Also, no surprises requiring major reworking occur

during testing. How many times, using traditional methodologies,

has a flaw been discovered that required major modifications

before a system could be installed? The likelihood of finding

such flaws is much less with the Prototyping Methodology.

Much of the training of key users occurs as a by-product of

the prototyping process, not as part of a separate phase.

Advantages of Full Prototype versus Mock-up


The differences in the advantages of a full prototype

compared to a prototype as a mock-up are important to consider.

Table I-8 shows some of the major differences. You should

remember that, since most of what are called "prototypes" in

current Information Systems literature are actually "mock-ups,"

many of the reasons given for prototyping in that literature

apply only to using mock-ups.



System meets user's needs X X

User participates in design X X

Early discovery of design X X

Requirements are developed X X
experientially not theoretically

User participates in development X

System interface problems must X
be solved from the start

Work of several phases concurrent X
with development

Excessive documentation not needed X X

Unexpected problems that consume X
major amounts of time don't occur

Much user training a by-product X
of development

Table I-8 Advantages of Full Prototype vs Mock-up

Possible Disadvantages


Table I-9 lists some possible disadvantages of using the

Prototyping Methodology.


. Visible use of computer resources

. Object system may be less efficient

. Requires cooperation between user and Information

. Some view prototyping as an art not a methodology

Table I-9 Possible Disadvantages of Prototyping Methodology

Using prototyping development tools may expend more computer

time than traditional development approaches. This may concern

Information Systems managements, since the use of computer

resources is the easiest to measure of all their uses of an

organization's resources. The tradeoff facing them is the use of

computer time versus the use of Information Systems


If the production version of the system performs much

processing with code from fourth generation languages, it may

require more computer time for running than if it were written in

a language like COBOL. (It's ironic that only a few years ago

many were lamenting that programs written in COBOL were less

efficient that ones written in assembly language.) Certainly, if

processing efficiency is an important design criterion, all of

the production system probably should not be written in a fourth

generation language. Nothing in the Prototyping Methodology

requires the use of fourth generation languages for the

production versions of systems. Also, other tradeoffs may affect

the relative efficiency of the production system, such as

development cost versus cost of computer resources and loss of

opportunity cost versus cost of computer resources.

Stating that the cooperation between user and Information

Systems that prototyping requires is a possible disadvantage may

seem sarcastic. Yet in some organizations the relationships

between Information Systems and users have deteriorated to the

point that any project requiring cooperation would be doomed from

its beginning. Prototyping offers a chance, but no guarantee, to

turn such situations around.

If clever Information Systems people prototype as a way of

expressing their artfulness in implementing systems, the

organization will benefit by however much work those talented

people can do. But their management may rightly worry about

using prototyping when it is an art not a methodology.

What's Wrong with Current Methodologies


Wetherbe describes the current state of Information Systems

well6, when he declares that the major problems with our current

approaches are that they take too long, and they don't produce

the right system the first time.

Why are we following approaches that serve us so poorly?

Until recently we have been mainly building batch systems. The

machine time we needed to build and test them was expensive,

compared to the costs for the people doing the building and

testing. Furthermore, we were not able to compile and test


Information Systems people need a lot of information to

design application systems. They know hardware and systems

design, but often they are not experts in the functions of their

organization. They want to do a complete job, covering all

possible situations that may ever occur in the systems; their

desire to be thorough may even lead them to over-design.

Nevertheless, when they have finished, users often view the

systems that they have produced as far from what was wanted.

On the other hand, no matter how well users understand the

functions of their areas of the organization, and no matter how

creative they may be, they often have difficulty defining what

they want a new system to do. So, Information Systems frequently

perceives them as not knowing what they wanted.

In far too many cases the situation between Information

Systems and the users has become a modern day "range war" between

the good guys and the bad guys.

In the opinion of many observers of the Information Systems

scene, the use of a "life cycle" methodology, establishing

information centers, and promoting the use of personal computers

have been the best solution, so far, to this war.

Many adherents of the "life cycle" methodology consider the

writing and formal signoff of detailed requirements as its

principal benefit. Also, these requirements protect Information

Systems, if the final system conforms to them. But regardless of

what the requirements describe and no matter who signed them off,

no user is happy when the system does not do what he had hoped it


You all know the story of far too many projects done using

current methodologies. If they are not cancelled, they are often

completed late and over budget. Usually they are "done in" by

one or more surprises discovered during system testing or

acceptance testing. Even though iteration was not planned, the

projects must be halted for modifications based on new

information. And how many times does a project leader discover

that the "new" project he has been assigned to is actually being

attempted again for the third or the fourth time, after having

been cancelled all the previous times?

So, the backlog, both visible and invisible, of requests for

Information Systems projects continues to grow despite, or

possibly in some sense, because of, current methodologies.

In many organizations, Information Systems is no longer

considered responsive to users' needs. Users may be beginning to

go around Information Systems to satisfy their information needs.

Methodologies that do not promote user confidence, have a slim

chance, at best, to help change the deteriorating situation.

Table I-10 lists some of the principal problems with current



. Are thorough BUT DON'T . please users

. Produce extensive BUT DON'T . decrease communication
documentation problems

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

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

. Delineate skills BUT DON'T . cut manpower needed

. Track project costs BUT DON'T . reduce them

Table I-10 Problems with Current Methodologies

Application of Prototyping

Where should prototyping be used? On what types of

projects? Some would limit the use of prototyping to the

development of systems that are poorly defined. Others7 would

limit it to ones that are relatively small. In fact, some8 claim

that the use of prototyping leads to a tendency to keep projects

smaller and thus more manageable. Others9 believe that

prototyping applies best to simulating human interaction with

systems; whereas using other methodologies, such as structured

programming, for the parts of the system with which people do not

communicate directly, will increase productivity. Certainly,

many will tell you, prototyping should not be used for installing

software packages.

In some cases where prototyping might otherwise be

recommended, its use might not be a good choice. If prototyping

violates important criteria for the project, it shouldn't be

used. If, for example, one criterion for implementing a minor

modification to a system is to complete it in two weeks, and just

getting a prototype of the unmodified system running would take

more than a week, then, all other things being equal, prototyping

would probably not be a good choice for the project. Chapter 2

describes when to prototype in more detail.

Nevertheless, prototyping has all those uses shown in table



. On-line systems

. Batch systems

. Packages

. Enhancements and modifications

Table I-11 Applications of Prototyping Methodology

Prototyping is useful in developing on-line systems. Most

people writing about using prototyping would agree with this.

Moreover, on-line systems are even 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. Many of them started prototyping when they realized

the screen mapper, that was a part of a fourth generation

language they had acquired, would help them. All of the

advantages of prototyping apply to its use for on-line systems.

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. But, how do we do them? If we're advanced, we use

some type of "life cycle" methodology.

Using the "life cycle" methodologies has the disadvantages

that were discussed earlier; using prototyping has the advantages

discussed earlier. But you still may not see how prototyping

applies to batch systems. After all, batch systems don't have

any screens. Nevertheless, the same problems arise in developing

batch and on-line systems:

. users have difficulty visualizing what they want a system

to do

. users have difficulty evaluating requirements


Users have trouble visualizing what should be on a report, but,

as you may have experienced many times, they know what they don't

like when they see a report. Information Systems people often

misunderstand the best sequence for data. Processing rules are

often based on incorrect information about the data to be used.

Users often realize, after working with a system, that reports

they felt were essential, are actually unnecessary. Outputs a

system produces for groups other than the primary user are often

not useful, at least, not without changes. 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


A package is either installed with or without modifications.

Package modifications include using 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. You may doubt that this approach will decrease

calendar time or cut project costs, but have you considered how

many times adjustments have had to be made to a system based on a

package, immediately after its supposedly smooth installation?

Even if no modifications are planned to a package, installing it

first as a prototype with test data will enable you to test it,

to ensure it meets the user's needs, to train key users, to

ensure that the user and Information Services people understand

it, and to determine whether it meshes well with interfacing


Prototyping also enhances the package selection process.

Usually, a package selection reduces to a choice between two or

three strong candidates. But, even if there is only one strong

candidate that appears to be a shoo-in, prototyping will help you

make a good choice. Most package vendors allow a trial use

before purchase or, at least, before a purchase is final. Use

it. Installing a prototype of the package and a model of any

modifications you plan to make, will help both the user and

Information Systems people to evaluate the package's strengths

and weaknesses and how it meets the requirements.

Prototyping is useful for enhancements and modifications to

existing systems. If a test system is already available for the

system to be changed, prototyping will be that much easier. Even

if a test system does not exist, you only need to prototype that

part of the system that you are planning to change. Of course,

you must determine whether prototyping would be practical,

particularly for relatively small projects, as described in the

first part of this section.

If an enhancement or modification is to be relatively minor,

bringing up a prototype of it should be relatively minor. After

all, you should intend to test the change before it becomes part

of the production system. Prototyping a small change is

essentially only system testing and acceptance testing it; you

should do these things in any case.

If a change is larger, the benefits of prototyping and its

applicability are the same as for new systems, including

eliminating communication problems, pleasing the user, and

helping you to install the right change the first time.

What Is Needed To Prototype


Sarvari lists10 such things as on-line technology, a

relational database, and a high level languages as required for

prototyping. Others mention11 the need for such things as a

database management system, data dictionary, query language and

report writer.

Do you really need fourth generation languages? Report

writers? DBMSs? Data Dictionaries? Prototyping is certainly

easier with them than it is without them. And, these aids have

generally been available to people when they began prototyping.

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. Also, giving too much attention

to these aids may cloud an important issue: what makes

prototyping work?

The essential response is that proper project management

and the use of a methodology make prototyping work. No matter

how good the tools available to Information Systems people are,

good project management is essential to their successful use of

the tools. Also, a methodology makes prototyping a tool and not

just an art.

But, in addition to these essential elements, what is it at

the nuts and bolts level that makes prototyping work? Table I-12

lists the four principal ingredients.


. Understanding the data

. Moving data through the system and to and

from connecting systems

. Exercising the prototype frequently

. Building and modifying the prototype quickly

Table I-12 What Is Needed To Prototype

You need to understand the data to design and build the

initial prototype model. That initial prototype model will

consist of:

. Major program modules

. Database

. Screens

. Reports

. Inputs and Outputs for Interfacing Systems

You don't want to produce screens and reports that don't show

data realistically. Also, prototyping will go more smoothly, if

you base the initial version of the database on a good

understanding of the data - for example, if it is within 75

percent of the content and structure of the production version.

Finally, the structure of the initial model itself depends

heavily on the database, screens, reports, inputs, and outputs;

and, they depend on an understanding of the data. Chapter 4 will

discuss ways to gain an understanding of the data.

Moving data through the system and to and from connecting

systems provides many of the principal benefits of prototyping.

It makes both systems and acceptance testing work by showing what

happens when you enter input data and when you modify its

processing. The feeling of realism it gives also promotes user


Since the core of prototyping is using the model, the user

and Information Systems people are performing its most essential

function as they work together exercising it. How often to

exercise the prototype is a matter of judgement. If too much

time elapses between prototyping sessions, your experience with

the prototype gets stale, you may need additional time to refresh

participants' memories, and you may begin documenting more

elaborately. These things may rob you of many of the advantages

of prototyping.

Being able to build and to modify the prototype quickly is

important for exercising it frequently. But the speed required

for modifications is relative to other factors. If, for example,

different things are being done in five successive exercise

sessions, no one may want to see modifications resulting from the

first session until after the end of the fifth session. Chapter

6 discusses exercising the prototype in more detail.

Tools To Enhance Prototyping


Tools that will help you prototype are tools that will help

you understand and move the data, and exercise and modify the

prototype. None of them may be essential, but using at least

some of them will help you to prototype.

No specific set of tools is best for prototyping. Using one

data dictionary may not be better than using another. Writing

programs with one fourth generation language may not be better

than writing them with another. But using a data dictionary may

be better than manually controlling information about the data.

And using a fourth generation language may be better than coding

everything in COBOL.



. Understanding the data . Data dictionary

. Moving the data . 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

. Relational DBMS

Table I-12 Tools To Enhance Prototyping

A data dictionary should help you to record and to organize

information about data. This should aid you in understanding the


An interactive testing system allows you to use a terminal

to change programs quickly, to submit frequent tests, and to

review the results of test sessions without having to wait for

batch outputs. Using interactive testing helps you to exercise

the prototype often, to modify it quickly, and thus to move data

between its components.

A test data generator produces test data for your use in

moving data through the system and exercising the prototype.

Although it may seem obvious, library control of program

modules aids in making quick changes to the prototype and in

moving data between system components by providing such things as

version control of programs and database definitions, and

multiple uses of the same program (may be a feature of the

operating system).

Quickly modifying those parts of a prototype that you have

written in a fourth generation language should be easy to do.

The features of the fourth generation language that are

particularly helpful are the report writer, screen painter and

query language. You may obtain some or all of these separately

without getting a fourth generation language. One consideration

I must add is that as you add more features to the prototype,

programming them in a fourth generation language may become more

complex than in a problem solution language. I will review this

question in more detail in chapter 5.

A relational data base management system, either alone or as

part of a fourth generation language, may help you in modifying

your database design, especially in the early stages of



. Definition of prototyping:

Software prototyping is an information system

development methodology based on building and

using a model of a system as the means of

designing, implementing, testing, and installing


. Prototyping

- Is a methodology

- Is building a model

- Uses the model for designing the system

- Uses the model for implementing the system

- Uses the model for testing the system

- Uses the Model for installing the system

. The prototype becomes the system.

. A prototype is the first fully developed version of a

system; a mock-up is a skeletal version of it.

. Prototyping is iterative; the "life cycle" methodologies

are serial.

. Advantages of prototyping:

- Pleases users

- Reduces development cost

- Decreases communication problems

- Slashes calendar time

- Produces the right system the first time

- Cuts manpower needs

. Possible disadvantages of prototyping:

- Its use of computer resources is easy to measure

- Object system it produces may be less efficient

- It requires cooperation between user and Information


- Some claim it is an art not a methodology

. Current methodologies:

- Take too long

- Don't produce the right system the first time

. Prototyping is useful for:

- On-line systems

- Batch systems

- Packages

- Enhancements and modifications

. Elements needed to make prototyping work:

- Good project management

- Use of methodology

- Understanding the data

- Moving data through the system and to and from

connecting systems

- Exercising the prototype frequently

- Building and modifying the prototype quickly

. Tools to enhance prototyping:

- Data dictionary

- Interactive testing

- Library control of program modules

- Fourth generation language (Report Writer, Screen

Painter, Query Language)

- Relational DBMS


1. "Websters New Collegiate Dictionary,"G. & C. Merriam

Co., Springfield, Massachusetts, 1977

2. Ibid

3. Chapin, Ned, "Prototyping- Quick, Not Dirty ...," Data

Management, vol. 21, no. 10, pp. 46-48, Oct 1983

4. Gilhooley, Ian ,"System Development Mythology,"

Datamation, vol.29, no. 6, pp. 272-276, June 1983

5. Gremillion, Lee L.; Pyburn, Philip, "Breaking the

Systems Development Bottleneck," Harvard Business

Review, vol. 61, no. 2, p. 133, Mar/Apr 1983

6. Wetherbe, James C., "Systems Development: Heuristic or

Prototyping?" Computerworld, vol. 16, no.17, pp. SR14-

15, April 26, 1982

7. Meyer, K.; Kovaco, A., "Model Systems," Datamation,

vol.29, no.9, pp. 248,250,252, September 1983

8. Ibid

9. Frank, Werner L., "Structured vs. Prototyping

Methodology," Computerworld, vol. 17, no. 33, pp. 51-52,

August 15, 1983

10. Sarvari, I.L., "The Case for Prototyping," Canadian

Datasystems, vol.15, no.10, Oct. 1983, pp. 100-104

11. Marett, W., "New Development Tool Project Based On `C',"

New Zealand Interface, pp. 16-17, July 1983

Home | Contact Us