ManageKnowledge.com
Atwater, Lantz, Hunter & Co.
Site Under Construction
THE PROTOTYPING METHODOLOGY
PREFACE
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
organizations.
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
methodology.
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.
CHAPTER I: WHAT PROTOTYPING IS AND WHY IT IS VALUABLE
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
literature.
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
purposes.
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.
CONTENTS OF INITIAL PROTOTYPE 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
system.
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
system.
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
system.
A prototype as a mock-up is valuable. Nonetheless, it does
not provide all the benefits of a full prototype, as discussed
below.
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.
____________________________________
| |
| THE PROTOTYPE BECOMES THE SYSTEM |
|____________________________________|
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.
WHAT MUST BE DONE?
. 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
data.
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.
HOW IT IS USUALLY DONE
________________________________________________________
|Det. |Study |Define |Design| | |Accep-|Train|
|Feasi-|Present|Require-|New |Program|Test|tance |Users|
|bility|System_|ments___|System|_______|____|Test__|_____|______
| | |
|Convert|Inst|
|_______|____|
(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
WE KNOW WHEN TO STOP ITERATING?
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.
PROTOTYPING METHODOLOGY
___________________________________________
|Det. |Study | Define |
|Feasi-|Present| Requirements |
|bility|System_|____________________________|
| Design |
| New |
|________System_______|
| |
| Program |
|____________________|
| |
| Test |
|___________________|
| Acceptance |
| Test |
|___________________|__
| Train |
| Users |
|______________________|____
| | |
|Convert|Inst|
|_______|____|
(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
completed.
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.
NEW LOOK OF THE PROTOTYPING METHODOLOGY
___________________________________________
|Det. |Study | Define |
|Feasi-|Present| Prototype |
|bility|System_|____________________________|
| Build |
| Prototype |
|_____________________|__
| Exercise |
| Prototype |
|______________________|____
| | |
|Convert|Inst|
|_______|____|
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
phases.
PROTOTYPING VERSUS TRADITIONAL PHASES
__________________________________________________________
|Prototyping includes Traditional |
|___Phase__________________________________Phase___________|
| |
|Determine Determine |
|Feasibility____________________________Feasibility________|
| |
|Study Present Study Present |
|___System_________________________________System__________|
| |
|Define_Prototype______________________ Define_Requirements|
| |
|Build Prototype Design |
|_______________________________________Program____________|
| |
|Exercise Prototype Test |
| Acceptance Test |
|_______________________________________Train_Users________|
| |
|Convert________________________________Convert____________|
| |
|Install________________________________Install____________|
Table I-5 Prototyping versus Traditional Project Phases
Why Prototype
Table I-6 lists the principal advantages of prototyping.
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
approach."
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
paper.
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.
HOW PROTOTYPING CUTS PROJECT MANPOWER
. Doesn't require excessive documentation
. Good communication takes less time than poor
communication
. No last-minute surprises requiring major
modifications
. 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.
PROTOTYPE VS MOCK-UP
ADVANTAGE FULL PROTOTYPE AS
PROTOTYPE MOCK-UP
System meets user's needs X X
User participates in design X X
Early discovery of design X X
problems
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.
POSSIBLE DISADVANTAGES OF PROTOTYPING
. 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
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
professionals.
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
frequently.
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
would.
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
methodologies.
CURRENT METHODOLOGIES
. 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
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
I-11.
USES OF PROTOTYPING
. 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
documentation
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
package.
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
systems.
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.
NECESSARY FOR PROTOTYPING
. 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
training.
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.
TOOLS TO ENHANCE PROTOTYPING
NEEDED TO PROTOTYPE TOOLS TO HELP
. 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
Language)
. 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
data.
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
prototyping.
Summary
. 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
it.
. 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
Systems
- 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
Footnotes
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