Atwater, Lantz, Hunter & Co.

Site Under Construction



This chapter describes exercising the prototype, the

different stages of exercising it, what you need to exercise it,

and how to do it. The chapter also discusses expanding the

project team, planning, and progress monitoring.

Chapter IV describes defining the prototype and Chapter V

describes building the initial model of the prototype from the

definition. This chapter describes exercising the initial model

built according to the guidelines in Chapter V.

Exercising a prototype is testing it, training with it,

modifying it, and expanding it until it becomes the system. You

begin the exercising process with the initial model; you finish

the process by producing the system.

Expanding the Project Team


Exercising the prototype requires modifying and expanding

the same components of the prototype that were built as part of

the initial model. The same skills are needed to exercise as

were needed to build, depending also on whether a fourth

generation language is used. Table V-4 summarizes the components

and who should work on each. Insofar as possible, the same team

members who worked on building the initial model should stay with

the project to exercise the prototype.

Exercising the prototype requires two additional tasks:

. Maintaining version control

. Developing draft user guide.

Maintaining version control must be the primary

responsibility of one member of the team from Information

Systems, designated as the exercising coordinator. If the

project is large enough, Information Systems may assign one or

more additional persons to help. Those chosen for this task

should be junior programmers with clerical skills or

documentation specialists. The exercising coordinator should be

responsible for version control and integration, possibly along

with some programming or documenting. If the project's size does

not justify adding another person to the team, one of the

programmer-analysts must assume this responsibility.

Developing the draft user guide should be the primary

responsibility of one or more technical writers or documentation

specialists. If the project is small, the same person from

Information Systems may develop the draft user guide and act as

the exercising coordinator.

Stages of Discovery


The prototype exercising sessions, which may be called

simply the "prototyping sessions," work best if they are done in

three stages. Table VI-1 lists the focus of each stage of


The focus of the prototyping in the first stage of discovery

is the data. How do the reports and screens look to the users? Is

the database adequate? Are the interfaces with other systems

right? Individual sessions should concentrate on using screens.

Other sessions should be for reviewing reports. The prototype

should be run to ensure it can read the input from feeding

systems. Also, the test versions of systems that use data from

the prototype should be run to make sure the prototype provides

useable data. The team should make all necessary modifications

to the screens, reports, and interfacing files. They should also

make any changes required to the database and program-to-program




1. Data

2. Processes

3. Edits, Validations, and Controls

Table VI-1 Stages of Discovery

After reports, screens, database, and interfaces settle

down, the team should focus next on the prototype's logical and

mathematical processes. This is when the team should replace any

languages temporarily used for processing with the language to be

used in the final version of the system. Where processing logic

has been dummied or done in broad outlines only, the team must

gradually flesh out the full logic of the system. Similarly, the

team members must build the full mathematical processes needed

for calculations. Building these processes may also require the

team to make changes to the database and program-to-program


The last stage of discovery for prototyping is validations,

edits, and controls. By the time this stage begins, the

prototype should be relatively stable. The users should have

gained considerable experience in using the system. This

experience is important for determining what validations, edits,

and controls to build into the system. Gaining this experience

first is important, because the cost of developing validations,

edits, and controls may constitute more than fifty percent of the

total development cost of a project. With a feeling for how the

prototype works and how much additional work and cost excessive

validations, edits, and controls may necessitate, users often

trim back what they would have otherwise asked.

Results of Exercising


Defining the prototype produces a definition. Building the

prototype produces an initial model. Exercising the prototype

produces the four main results listed in Table VI-2.


. The System

. Test System

. User Documentation

. Requirements Agreement

. Cadre of Trained Users

Table VI-2 Results of Exercising the Prototype

The System


Prototyping is the means the team uses to design the system.

Furthermore, since the prototype becomes the system, prototyping

is the means the team uses to develop the fully operational


When prototyping is completed the conversion process has

been tested; the screens, reports, program-to-program files, and

the database are finished; the processes are all working; the

validations, edits, and controls have been set in place; and,

materials have been prepared in draft form for the user guide and

help screens. The system is ready to be installed.

Test System


A test system consists of test data sets, tools, and

controls for the controlled and comprehensive testing of an

information system or a prototype of it. Comprehensive testing

of a system is testing of all its features. Controlled testing

is planned testing done without unnecessary duplication of


Testing, when done as a part of a non-prototyping project,

is often divided into three categories:

. unit testing

. system testing

. acceptance testing

Unit testing is testing an individual component of the

system to verify that it functions according to specifications.

The person, often a programmer, who produces or modifies a

component usually does the unit testing of it.

System testing is testing all parts of the system together

and testing the system's communication with other systems.

Information Systems usually does system testing to verify that

the system operates as it was intended to do.

Users do acceptance testing to determine whether the system

meets their requirements and is acceptable to them. This is

usually a final stage before a system is placed in production.

Prototyping allows the team members to perform all three

types of testing as they exercise the prototype.

You should develop the test system to help you exercise the

prototype. When this phase is completed, you should keep the

test system to help you implement the system and test later

changes to the system.

You can do good testing without special tools, but you

cannot do good testing without a plan, thorough test data sets,

and adequate controls.

Reasons for Testing


Testing satisfies a variety of needs. Some are more

important when a system is first developed. Others apply

especially when modifying and maintaining a system. Table VI-3

lists the principal reasons for testing.



Making sure features function correctly

Ensuring nothing was changed inadvertantly

Determining whether system will fail

Training users and operators

Determining resources required

Researching problems

Table VI-3 Reasons for Testing

When you are prototyping, testing is a means of designing a

system. Testing gives the project team experience with the

system enabling them to make informed changes to the design.

The project team continues testing and modifying until they

produce a satisfactory design.

A basic purpose for testing is to ensure that running a

system or modifications made to it produce predictable results.

If a feature of a payroll system is the automatic recalculation

of an employee's base pay after notice of a pay increase is

received, testing discloses whether the feature works as


Another valuable use of testing, which is sometimes

overlooked, is ensuring that adding or changing a system feature

does not inadvertantly change something else in the system that

was not supposed to have been changed.

Testing may also disclose whether a system may be made to

fail. The design criteria for the system should include

allowable tolerances for bad data or bad operating procedures.

Can bad data make the system fail? Can an operator's loading the

wrong version of a file go unnoticed? Testing should provide the

answers to these questions.

The testing done as a part of prototyping also trains at

least those users on the project team in using the system. As

they complete the system they learn how it works.

Testing may determine the computer time required to operate

a system and the response time for system functions. Testing may

also verify that sufficient storage has been allocated for the


Another use for testing, when a system is failing, is

researching what may be causing the failure. With testing, you

may, for example, isolate the area within the system where the

failure is occurring.

Test Data Sets


The heart of any test system is the test data sets it

contains. Table VI-4 lists the contents of a test data set.

Basically a test data set consists of a description of what the

set will test, database contents, inputs to process against the

database, command language statements to run the test, and the

expected results. All components of each test data set should

have the same version identifier to link them together and to

distinguish them from the components of other test data sets.

For example, all the parts of one test data set may be labelled

as version "A" and the parts of another for the same system may

be labelled as version "B." The records kept on test data sets

should contain such information as is listed in Table VI-5.


. Description

. Database contents

. Inputs

. Benchmark outputs

. Expected results

. Command language statements

Table VI-4 Test Data Set Contents

The database contents for a test data set consist of the

records the database should contain before a test is run with it.

The database contents may be one of four different types. Table

VI-6 lists the types of data sets.


. Version number

. Description

. Date prepared/modified

Table VI-5 Test Data Set Log

Volume data sets contain a large number of records. They

are often copies of production databases. A copy of the payroll-

personnel database is an example.


. Volume

. Selected

. Special

. Production

Table VI-6 Data Set Types

Selected data sets contain a relatively small number of

records which represent a wide spectrum of data conditions.

The ideal selected data set allows full testing of a system's

features with a small amount of data. Selected payroll input

transactions containing a few samples of each different

transaction type and containing data to test all the different

combinations of conditions that the payroll system should handle

are an example.

Special data sets contain records for testing a particular

feature of or modification to a system. After the feature or

modification is incorporated into the system, the team should add

the special data set to the selected data set for the system. If

a new pay type code is added to the payroll system, a special

data set to test the combinations of conditions that may occur in

processing transactions with the new code would be a special data


Production data sets are produced or maintained by an

operational information system. The computer operations

organization often controls them. The actual payroll-personnel

database is an example of a production data set.

If a system operates differently during different processing

cycles, producing different outputs for example, you probably

need a different selected test data set for each processing

cycle. Examples of processing cycles are daily, weekly, monthly,

and quarterly. You may also want separate volume test data sets

for at least some of the different processing cycles.

Processing cycle test data sets may not all contain inputs, or

database contents, or outputs. As an example, the test data set

for the monthly processing cycle may consist of monthly benchmark

reports and the command language statements to run the system to

produce them.

The inputs for a test data set consist of input transactions

to be run through the system. Inputs will be one of the four

types of data sets listed in Table VI-6. Insofar as possible,

they will be machine-readable. If they are transactions for on-

line entry and a data entry simulator is available, they will be

on a file. Otherwise, they may be on paper for use by the

persons who will key them into the system.

The expected results for a test data set consist of database

results and benchmark outputs.

The expected results for the database may include machine-

readable expected contents. They would depict what the database

should contain after a test is run using the test data set. If

you have a file comparison utility, you may use it to compare the

test results with the contents of the test data set database.

Otherwise, the expected results for the database may be a listing

of the expected differences in the contents of the database after

the test has been run, which you may manually compare to the

database contents.

The database contents may be one of the four different types

listed in Table VI-6. If the database contents are a special

data set, before the test may be run, you may have to use a

utility to add them to the database. It may contain a selected

data set.

The benchmark outputs for the machine-readable files,

reports, and screens depict what they should contain after the

inputs are run against the database for the test data set. They

should be on paper or in machine-readable form depending on

whether you will use a file comparison utility to review them.

The command language statements for a data set consist of

the statements required for utilities to load and unload data

sets and the database, statements to use data entry simulators

and file comparison utilities, and the statements to run the


Tools for Testing


Depending on the characteristics of a system and the manner

in which you test it, testing tools may significantly increase

the effectiveness and efficiency of your testing. But, no matter

how helpful they are, no tool can make up for a lack of planning,

having good test data sets, or using sufficient controls. Table

VI-7 lists the principal types of testing tools.


. Interactive testing

. Data entry simulator

. File loading utility

. File comparison utility

Table VI-7 Tools for Testing

Interactive testing enables you to submit tests immediately

in a computer use environment where they will be run without much

delay. Interactive testing allows you to test on-line features

as the test is running and to sample batch results on-line

without waiting for paper copies to be printed.

A file loading utility loads a test system's database and

input files from the test data set to be used for the test. You

may also use it after a test has been run to copy the contents of

the database and output files to other media or even to print


A file comparison utility compares two files, highlighting

any differences between them.

A data entry simulator allows you to test the prototype with

a file containing transactions you would have entered from a

terminal. It processes the transactions in batch mode or

simulated on-line fashion, and it produces the results for any

output screens as a file, a report, or a screen.

Testing Controls


The principal tools for controlling testing, as shown in

Table VI-8, are test logs and version controls of programs and

data. The purpose of controlling tests is to keep the prototype

running, to avoid unnecessary effort, to make repeating tests

possible, and to keep a record of what was tested.

                  TESTING CONTROLS
. Version control


Test data sets

.Test logs

Table VI-8 Testing Controls

Adding data to a database or lines to a program sometimes

causes the system to fail. When this occurs, rolling the status

of the database and the program back to their condition before

the failure will allow prototyping to continue. You may later

reenter the changes to the data or the program to help isolate

and correct the problem.

Maintaining a centralized record of what has been tested

helps team members avoid duplicating tests done by others. Since

they are often not inclined to maintain tight control and keep

good records of even their own tests, because of the work

involved, this control may even help them avoid duplicating their

own tests. Centralized record keeping and control also make it

easier to repeat tests that were made earlier. When an earlier

test revealed a problem which has been corrected, the test should

be repeated to ensure that the correction works.

The record of what tests were run and when they were run is

also valuable for determining that the prototype was adequately

exercised and tested.

Duties of Exercising Coordinator


The responsibility for controlling tests and determining

which versions of the prototype's components will be used should

be the specific assignment of one of the team members, designated

as the exercising coordinator. Table VI-9 summarizes this

person's duties. If the work warrants it, one or more additional

team members may assist the exercising coordinator. Maintaining

this control should not be left to individual team members to do

incidentally to their exercising the prototype.

No changes should be made to a module, screen, report,

database, or test data set without the exercising coordinator's

knowledge and not before the exercising coordinator has copied

the existing version of the component to be changed. This will

ensure that the previous version, which probably worked, may be

used if the new version does not work.


. Responsible for control

. Copy before changing

. Back out changes that fail

. Record tests

. Maintain sufficient versions

. Maintain test data sets

. Test for inadvertant errors

Table VI-9 Duties of Exercising Coordinator

Before changing to a new version of a module, the exercising

coordinator should test the system with the current selected test

data set to ensure that nothing was changed that should not have

been changed. If he discovers an inadvertant change, he should

refer it to the project leader and suspend changing to the new

version of the module that caused the problem.

The exercising coordinator should maintain test data sets.

If a member of the project team asks that data be added to a test

data set, the exercising coordinator should run it through the

system to produce all the new outputs. Whenever data is added to

a database the exercising coordinator should run the prototype

with the database to ensure that it does not cause any component

of the system to fail. When data is only temporarily added to a

database, he should determine whether equivalent data will be

added to the database for a final test of the prototype.

If a change of any kind fails, the exercising coordinator

should be able to back out the version of the prototype's

components that caused the failure and replace them with the

prior version that worked. Not only may changing a program,

screen, or database cause the prototype to fail, but also

processing new data sometimes causes it to fail. This is

especially difficult to control when the data is entered through

screens into an on-line system. If such a failure does occur,

the exercising coordinator should return the prototype to its

status before the data that caused the failure began to be

entered. Eliminate the data which caused the problem from the

prototype's input until you learn why it causes the system to


The exercising coordinator should keep an accurate record of

which version of the prototype's components and test data sets

were used for each test.

The exercising coordinator should also maintain sufficient

versions of the prototype's components so that the project team

may keep the prototype running and repeat any tests the members

wish to repeat. If a lack of storage necessitates eliminating

older versions, the exercising coordinator should make sure,

before deleting a previous version, that a later version of a

system component does not cause the system to fail.

Version Control


The basis for version control of the prototype's components

is a version control log. Each active version of a component

should appear on this log. Table VI-10 lists the contents of a

version control log. Each individual component should contain

its unique identification and its version identification. For

example, if a component is a database it should have the

identifier given to the database, an indication whether it is the

initial or resulting contents, and the version identifier that

distinguishes it from other versions of the database contents.

If the component is a program module, it should have the module

identifier and the version identifier.


. Component identification

. Version identification

. Library identification

. Date and time stored in library

. Description

. Who prepared it

Table VI-10 Version Control Log

The component identification on the version control log

tells what the component is (for example a program or a test

input), the identifier given to the component, and the version

identification to be used for this version of it. Related

components that each have their own unique identifications may

have the same version number. For example, all the parts of each

test data set should contain the same version identification.

The library identification tells what library the version of

the component has been stored on. The date and time records when

it was stored on the library.

The description briefly tells what makes this version of the

component different from other versions of it. Who prepared the

version identifies the person responsible for it.

Test Logs


The exercising coordinator should maintain a record of each

test on a test log whose principal contents are listed in Table



. When test began

. When test was completed

. Test data set used

. Purpose of test

. Versions of components used

Table VI-11 Test Log Contents

The log should contain the date and time each test began and

when it was completed. It should also contain the identification

of the test data set used.

The log does not have to contain the specific version of all

components when the last versions that were stored in the library

before the test began are the same ones used in a test. But if

any version of a component, other than the last one store in the

library, is used, then the exercising coordinator should list the

specific identification of that version.

A brief description of the test should accompany the other

log entries.

User Documentation


User documentation for a system consists of a description of

what the system does, how to enter input into it, and how to

make it produce results, such as reports.

The prototype logical definition should be a good basis for

this user documentation. But, as the prototyping progresses, the

team adds or changes system features and functions, moving the

prototype away from the definition. If the team members do not

document this in some way, it is practically lost, to be

reclaimed only from the team members memories and the system


Developing user documentation in draft form is an essential

part of exercising the prototype. Developing the final version

of the user documentation while exercising the prototype would be

premature and consequently wasteful. But developing draft

documentation from information that is produced as the exercising

progresses should be done so the information is not lost.

If they have sufficient time, the team members responsible

for developing the draft user documentation may also change the

focus of the logical definition into part of the user

documentation. They may then modify and add to this as they


Requirements Agreement


The requirements agreement for an information system is a

statement, to which both the user and Information Systems agree,

of what the system will do. Table VI-12 lists the subjects that

a requirements agreement should include.





Processing rules

Validations and Controls

Service Constraints

Table VI-12 Elements of a Requirements Agreement

The prototype definition (see Chapter IV) is a first draft

of the requirements agreement. Building the prototype as

described in Chapter V makes the definition concrete. Exercising

the prototype enables you to complete the design of the system

with the user and thus to determine the system requirements.

When exercising the prototype has been successfully

completed, Information Systems and the user will have reached a

common understanding of the requirements of the system. Some

even view this agreement on the system requirements as the

principal value of prototyping.

Even though the requirements will not have been neatly

documented when the exercising is finished, Information Systems

and the user should formally give notice that they agree on them.

In the absence of thorough written requirements, they may point

to the prototype itself, the data dictionary descriptions of the

information in the system, and the draft user documentation as

the record of the system requirements.

When the team finishes the documentation of the system in

the implementation phase, that documentation (primarily the user

guide) will enhance the documentation of this requirements

agreement. But not having that documentation in this phase

should in no way lessen the fact that the agreement was made when

exercising the prototype was completed.

Cadre of Trained Users


To exercise the prototype the team members run it. At first

they work with the initial model. As they gain experience with

the system they change the prototype, then work with the changed

version. When exercising the prototype is finished, the team

members who have been working with it will have learned how to use the

prototype. The prototype becomes the system. Those users on the

team constitute a cadre trained in the system who can help in the

implementation phase that follows.

Requirements for Exercising Successfully


Several factors are necessary to make exercising the

prototype successful. Table VI-13 lists them. First and

foremost is securing the involvement of the users in exercising

the prototype. The users on the team do not have to produce

anything: they don't have to write reports or paint screens. But

they do have to participate in the prototyping sessions and in

the team reviews of what happens in sessions they do not

personally engage in: they have to work with the prototype and to

say what they want and don't want. Also, users who are not

actively working on the team, especially managers, should

participate in the team reviews. Although user involvement does

not guarantee the project will succeed, lack of it may cause the

project to fail.


. User involvement

. Version control

. Test system

. Exercising frequently

. Changing quickly

. Stabilizing architecture

. Project management

Table VI-13 Factors To Make Exercising Successful

Version control, described earlier, enables the team to

change the prototype often and quickly without creating


A test system, also described earlier, allows the team to

test the prototype frequently, expanding what is tested, while

minimizing the work required to run the tests and to review their


Exercising the prototype frequently develops and maintains

the team members' familiarity with the system. This enables them

to learn the system and to modify it without having to have

extensive documentation. If too much time elapses between

exercising sessions, the participants may forget how the system

works. This may only harm the project. Team members should take

part in an exercising session every working day, or at the most

every two days.

Changing the prototype quickly helps you to exercise it

frequently. Different prototyping sessions may focus on

different features of the system, so any particular session may

not depend on what happened in the last one. But you should

exercise a modification soon after the team decided to make it.

Using tools like fourth generation languages often makes changing

the system quicker and easier than not using them. If the tools

being used or the scope of what is to be changed requires

excessive time for making changes, break the changes up. Instead

of taking two weeks to make one large change, take three days

each to make four small ones.

You should attempt to keep the prototype architecture

stable. Where you were communicating with one module today, you

do not want to communicate with three modules tomorrow.

Good project management is essential to keep the exercising

work focused. The project leader should ensure a schedule and

plan are prepared for exercising the prototype and that the

schedule is adhered to.

How To Exercise the Prototype


Exercising the prototype proceeds according to the stages of

development listed earlier in Table VI-1. First you will

concentrate on the data, then you will move on to the processes,

and, finally, you will cover the validations, edits, and


The materials produced so far in the project affect the

perspective you have of the prototype. Available are the problem

statement and the study of the present system both of which

describe the functions, the prototype definition and the data

dictionary, which describe the components. Each is a departure

point for exercising, and each affects your approach to


Functions discovered when the existing payroll system was

studied may include preparing the pay for a group of employees.

The prototype definition may include a description of the

paycheck and the check stub. The data dictionary may include the

formula for calculating the amount net pay. If you only

concentrate on the components identified in the prototype

definition, such as the check and check stub, you may not fully

experience how the prototype performs the functions it is to

perform, such as preparing the pay for the weekly paid employees.

If you only concentrate on the functions, you may miss trying

some of the components of the system.

Table VI-14 lists the approach that is recommended for

exercising the prototype. Basically you should plan what you

will do and develop a test system to aid in doing it. Then you

should exercise and modify the prototype until you complete the

prototype and those things, such as the requirements agreement

and the test system, that go with it.

Before beginning to exercise the prototype the team members,

under the direction of the project leader, will develop a plan

and a schedule for exercising. The plan and schedule will detail

the features of the prototype that should be exercised, who will

exercise it, what materials they will use, and when they will do

it. Definite milestones are important to this phase as they are

to the other prototyping phases.


. Develop initial plan

. Develop initial test system

. Conduct sessions

. Modify prototype

. Complete test system

. Agree on requirements

. Complete system

Table VI-14 Approach for Exercising the Prototype

Develop Plan and Schedule


Table VI-15 lists the primary tasks to be scheduled for the

exercising phase.


. Develop initial test system

. Unstructured familiarization

. Exercising sessions for each stage of discovery

. Complete system

. Complete test system

. Agree on requirements

Table VI-15 Exercising Tasks To Be Scheduled

Developing the initial test system is producing an initial

test data set and any utility runs or procedures required for

testing the prototype.

A short period of unstructured familiarization allows the

team members to experiment with the prototype. Limit the total

time dedicated to this unstructured familiarization to no more

than one or two weeks. Also, allow time in the schedule to make

any modifications that the team members decide on during this


The exercising sessions will focus first on the data, then

the processes, and finally the edits, validations, and controls.

The approach for planning these sessions is rather similar. For

the data phase and the validations, edits, and controls phase use

the prototype definition as a source. For the processes phase

also add the study of the present system as a source. From these

sources list the system components or features that you will

exercise. Then, for each component or feature list the elements

of an exercising session shown in Table VI-16. Base the schedule

on completing these things. Add to it the materials the team

members will need, especially which test data sets they should



. Develop test data

. Exercise the component or feature

. Review results

. Modify the prototype

. Test the modification

Table VI-16 Elements of an Exercising Session

Completing the system is removing all temporary changes that

were made to the prototype, such as the temporary use of a

relational DBMS instead of the final hierarchical DBMS.

Completing the test system is determining what different

selected and volume test data sets will be needed during

exercising, consolidating the various test data developed for the

exercising sessions into these test data sets, and labelling and

logging the materials so they will be useable.

Scheduling the agreement on the requirements and the

completion of the system is primarily scheduling milestone dates

by which they must be accomplished.

Because the material in this chapter must concentrate one by

one on a succession of topics, it may give the impression that

the prototype and the system that evolves from it change little

from the prototype definition. It may seem as though the

definition process identifies and specifies all the data sets and

processes that will comprise the system. Actually, exercising

may lead the team to change some parts of the system, to

eliminate others, and to add still others. Inputs may require

additional information elements, the sequence of reports may

change, one database record may combine with another, the need

for a new feature may arise, and some reports may become


While planning and scheduling the exercising, the team

members must especially estimate how many additional components

they will discover a need for as they prototype and plan for

them, as if they were already known. They should also estimate

how many of the known components will be eliminated without being

exercised, since estimates for them may be subtracted from the

total estimates.

Conversion Process


If a conversion process has been defined for the system, the

team members should prototype it the same as they prototype the

features that will be permanent parts of the system. The

exercising sessions for it should focus on the same three

aspects: data, processes, and edits, validations, and controls.

Nonetheless, the conversion process itself may not use

significant edits, validations, and controls.

Develop Test System


When the team builds the prototype, as described in Chapter

V, they develop some initial test data for the database and for

the inputs to the prototype. This data should be adequate for an

initial test data set. It should primarily be data for the

database and for inputs from other feeding systems. The project

team will use it for the unstructured familiarization with the

prototype. If it constitutes a good selected test data set, that

may help the familiarization. But, it is not essential that it

be so, and the team should not expend any significant amount of

time to make it a good selected test data set. But, if the test

data set that is available will not allow you to move data

through all parts of the system, you should augment it so that

you can do so.

More important is preparing any utility operations or

procedures that may be required to operate the test system.

Because of the installation's procedures for leaving data on the

media that will be used to exercise the prototype, the team may

have to use file loading utilities to load at least some of the

data sets before any prototype exercising may be done. For

example, they may have to load disk work files from tape files on

which the data sets for testing are kept. Utility operations may

also be needed to unload the test data sets back onto another

medium, such as tape, at the end of an exercising session. The

complexity of the prototype, the tools to be used for testing, or

the organization's requirements for running a test may also

necessitate writing some procedures to help it run smoothly.

In any particular exercising session, especially for an on-

line system, the team members may enter some new data from

terminals. But, they may also need to put some new data

temporarily on the database or into the inputs from outside

systems. Another part of the test system to be developed is any

utility operations or procedures that allow such additional data

to be added to a test data set. The exercising coordinator

should also have procedures for maintaining a record of the use

of this data. You should not have to add these utility

operations and procedures before beginning the familiarization

with the system, since it should not depend on their


The team may also want to set up utility operations and

procedures for displaying or printing the results of exercising

sessions. Doing this should also not delay beginning the

familiarization with the system.



A relatively informal period of exercising the prototype

should quickly give the team members a feeling of familiarity

with the prototype. This should enhance their ability to

exercise it and should increase their identification with the


To do this familiarization you need a test data set

containing data for the database and system inputs and any

file load utility operations necessary for loading data sets (see

above). The team should run the input through the system and

produce all the outputs, reports, and screens that are ready.

The team should review these for usefulness.

The team members may then experiment with entering input

into the system, whether it is on-line or batch.

This familiarization may disclose inconsistencies between

inputs and the database or between the database and outputs.

Glaring problems with outputs, such as an unuseable sequence for

a report, may become obvious. The manner in which data is to be

entered may be awkward or updating the database from certain

inputs may not work.

The team members may modify the plan for exercising the

prototype, because of what they learn during this familiarization

period. If they have time, they may also fix obvious problems.

As they experiment with they system they may produce some test

data which they want to keep.

The exercising coordinator must control any changes the team

members want to have made to components of the prototype or to

its test data sets.



The users whose work associates them with a feature of the

prototype should usually be responsible for exercising the

feature. As they exercise it, possibly modifying and exercising

it again, they are training themselves to use it. They and the

Information Systems people working with them will later become

the trainers for the other users of the system.

As they notice different ways to use the features they are

exercising, they should ask the persons responsible for

documentation to make notes about them for the documentation.

They should also make notes for later use when they are training

other persons.

Including additional users and Information Systems persons

in the direct work of exercising, even though they may not

develop the test data, review the results, or modify the system,

increases the training the team members will receive. The

additional team members should actually work with the prototype,

whenever possible. Besides the increased familiarity with the

system this will promote, it encourages them to give their

valuable reactions to the feature that is being prototyped.

Prototyping Sessions


In the prototype exercising sessions the team members test

the prototype, train with it, modify it, and expand it until it

becomes the system. The sessions focus first on the data, next

on the processes, and finally on the edits, validations, and

controls. Table VI-16 lists the elements of an exercising


Develop Test Data


The team may have to prepare test data before beginning an

exercising session. If test data is needed, the project leader

should assign one or more team members to develop it. If the

data is for on-line entry, those developing it may only need to

gather source documents from which the data may be entered during

the prototyping session. If the testing to be done during the

session requires that additional data already be on the database

or system inputs, they must put it in machine-readable form and

request the exercising coordinator to add it to the test data

sets. If it should be made a permanent part of a test data set,

they should also notify the exercising coordinator of this.

Data Exercising


The prototype exercising sessions which focus on the data

concentrate on how the reports and screens look to the users,

whether the database is adequate, and whether the interfaces with

other systems work. Individual sessions should concentrate on

using screens, reviewing reports, and running the prototype to

ensure it can communicate with other systems. The team should

make all modifications decided on during the exercising to the

database, program-to-program files, screens, reports, and

interfacing files.

Data Exercising On-line System


As an example, a user and a programmer-analyst will exercise

an input screen for a new automobile insurance claims system.

The user records information about a new claim using the screen.

The contents of the screen are listed in Table V-13 in Chapter V.

Before the exercising session, the user collects five samples of

new claims to use. Also, before the session the exercising

coordinator copies the database and the program that presents the

screen and updates the database from it

The screen was already painted when the prototype was built.

It produces a notice of verification of an insurance policy

covering the loss, but this is dummied out. Checking whether

adequate coverage exists has not been programmed yet.

The user does not like the way he has to enter claimant name

and address on the screen. The user also notices that the screen

should contain a claim type element. He and the programmer-

analyst discover that claim type also does not appear on the

database. They interrupt their exercising session to discuss

this with the project leader. He approves their modifying the

screen and the database.

The programmer-analyst updates the data dictionary. The

user and the programmer-analyst modify the screen layout. They

inform the exercising coordinator of the change to the database

structure. He copies it, then the programmer-analyst adds the

claim type element to the data dictionary and to the database

structure. The user then enters data for five more claims. He

is satisfied with the new screen and the new element.

The user and the programmer-analyst print copies of the new

screen with data for later review with the whole team. The user

makes a note to pass on to those who will exercise the

verification of coverage process that claim amount should be

checked against coverage amount based on claim type. They notify

the exercising coordinator of the change to the screen. They

also request that the data entered onto the database be kept,

because it is to be used later to exercise a screen for assigning

claims to claim supervisors. The exercising coordinator assigns

identifications to the new version of the screen program and the

modified database. He first tests the new version of the screen,

using the prior test data set, to ascertain that it changes

nothing inadvertantly.

Data Exercising Package Modification


As another example, a user and a programmer analyst exercise

an input screen used for manual journal entries to a financial

system package. The screen was painted with a map editor when

the prototype was built. The information elements to appear on

the screen were mostly predetermined by the package designers,

but their size and characteristics were decided when the data

dictionary for the package was established. The team also added

a non-standard project code to the input screen for budget and

expense entries.

The user collects several journal entries from recent

journals to use as test data. Before the session begins the

exercising coordinator copies the database and the program that

updates the screen.

In entering the data the user discovers that account number

does not include division code, which appears on all entries

other than home office entries. This was not noticed before,

because only home office entries were used during the

familiarization period.

At the end of the exercising session the user and the

programmer-analyst tell the exercising coordinator not to save

the updated database. They must discuss the lack of provision

for division code with the entire group.

After this discussion, the user adds division code to the

data dictionary for the package as a subelement of account

number, whose size is expanded. The structure of the database

and all inputs, outputs, screens, and reports that use account

number are automatically updated by the package's data


The original user and programmer-analyst then exercise the

journal entry input screen again, after the exercising

coordinator has first saved the database contents and the screen

processing program. The user and the programmer-analyst are

satisfied with the screen this time. At the end of the session,

they keep a print-out of the input screens to review with the

entire team. With the prior approval of the project leader, they

ask the exercising coordinator to save the augmented database

contents because they include records with division code as well

as some project codes.

Data Exercising Batch System


An additional example is a new batch payroll system. A user

and a programmer analyst exercise the printing of the paycheck

and the check stub. The source for printing them is a program-

to-program file that is being dummied out by the fourth

generation language skeleton of the module that will do the

payroll calculation. The data that is being dummied out is not

rich enough for their exercising session. So, the user has

developed another test data set that tests all the elements and

features of the paycheck and check stub. The programmer sets up

a utility run to load a temporary internal file used by the pay

calculation module to produce the program-to-program file with

they data they have developed. The exercising coordinator copies

the program before they make this change.

They run the paycheck and check stub, but problems with the

data they have created keep them from being satisfied with the

run. They have to modify the data they put in the calculation

module twice before it produces output that give them a

satisfactory run.

They copy these results to review with the team. They ask

the exercising coordinator to save the new version of the

calculation module and to keep the new version of the paycheck

and check stub as partial benchmark outputs. The exercising

coordinator tests the modules that use data from the new module,

using the current selected test data set, to ensure that the new

module does not inadvertantly change anything. The user and the

programmer-analyst also provide him a copy of the data and a

description of the payroll processing that produced it. The

exercising coordinator will label this with the same version

number as the data and the output before filing it.

Data Exercising System Enhancement

Another example is a user exercising a screen for making an

airline reservation. Figure VI-1 is a sample screen. It is part

of a modification to what used to be an airline passenger profile

system. The team is changing it into a reservations system.

They are using a relational DBMS language to write the

modification that will run on a microcomputer.

Before the exercising session begins, the exercising

coordinator saves the program that reads the screen. The program

that reads the screen does not update the database. Instead, it

simply erases whatever data was last on the screen, before it

allows the entry of a new reservation.

The user is a supervisor of reservations agents. He has

collected several recent reservations containing many different

combinations of conditions. He has another reservations agent,

acting alternately as a travel agent or a passenger, call him and

give him the information over the telephone. As the user enters

the reservations, he finds the order in which the screen calls

for data to be awkward. It also does not give him the ability to

check on seat availability.

BOOKED BY: Psgr (1), Sec'y (2), or Tr Agnt (3):1: SALES OFFICE: :
HOME STREET:22458 Ventura Blvd. Ste E :
CITY AND STATE:Woodland Hills, CA :ZIP:91364 :PHONE:(818)555-5555:
COMPANY:Atwater Lantz Hunter & Co. :CORPORATE ACCOUNT NO: :
OFFICE STREET:22458 Ventura Blvd. Ste E :
OFFICE CITY AND STATE:Woodland Hills, CA :ZIP:91364 :
PHONE:(818)704-1470: SECRETARY: LAST:Milkbucket :FIRST:Helen :
PASSENGER COMMENTS:Works while travelling; likes good lighting
AMT: 850.80:TYPE: :LIMO: 50.00:PAY FORM:AC :
CARD/CHECK NUMBER:88888888888888888:EXP DATE:12/86:

Fihure VI-1 Sample Passenger Input Screen

At the end of the session the exercising coordinator does

not have to save any data and the user has not modified any


After the session, the user reviews the results with the

other team members and asks for a programmer-analyst to modify

the way the screen asks for data. He also requests that a

programmer-analyst make the seat availability operation

accessible from the screen. The seat availability operation is

not new. Only making it accessible from this screen is new. A

programmer-analyst makes these changes, still not updating the

database. He dummies out the seat availability output. The

writer working on the project drafts a description of the use of

the seat availability option for a help screen and the user


The user then exercises the screen again. This time he is

satisfied with how it works. At the end of the session, he gives

a list of the reservations to the exercising coordinator to

maintain as an input test data set for later use when the

database will be updated. The programmer-analyst also gives the

modifications to the exercising coordinator to be made the latest

version of the prototype.

Aspects of Data Exercising


Table VI-17 lists the important aspects of prototype

exercising focused on the data. All the data identified in the

prototype definition provides the basis for the exercising tasks.


. Exercise everything containing data

. Test data prepared beforehand

. Test data for a session may be incorporated into test data


. Exercising coordinator controls all changes to system

components and test data

. Many different sessions a day are possible

. Often a user and a programmer-analyst exercise together

. Problems with database sometimes discovered

. Changes affecting other components must be coordinated

. Update documentation

. Results are reviewed frequently with entire team

Table VI-17 Aspects of Data Exercising

Any special test data required for a particular exercising

session is prepared before the session. The user often leads the

test data preparation. The team members performing an exercising

session may ask the exercising coordinator to incorporate the

test data they used into a permanent test data set.

The role of the exercising coordinator in controlling the

versions of the prototype's components and ensuring no change

inadvertantly affects other parts of the prototype is critical to

smooth prototyping.

If a project is large and many persons are on the project

team, many different prototyping sessions are possible every day.

The most important limit is how many sessions the exercising

coordinator can control.

Often at least one user and one programmer-analyst should be

on a team for a prototyping session.

Data exercising, especially since it is the first

prototyping done, may disclose problems with the database.

A person with documentation responsibility should record any

changes or additions that affect such things as help screens, the

user guide, or the data dictionary.

If the team members exercising a particular component

discover problems with another component, such as the database,

they must review these problems with the project leader or the

entire team before making any modifications to the other


Team members exercising different components of the

prototype should frequently review what they have done with the

entire team. These reviews should be at least daily for large

projects. No more than two or three working days should elapse

between reviews for smaller projects.

Exercising Sessions for Processes


In the second stage of discovery, the team should focus on

the prototype's logical and mathematical processes. The team may

plan the prototyping sessions for processes from the modules in

the physical definition of the system and the processes

identified in the logical definition and in the study of the

present system. During these sessions, the team should replace

any languages temporarily used for processing with the language

to be used in the final version of the system. They should

gradually expand logical processing that initially has been

dummied or done in broad outlines only, and they must build the

full mathematical processes needed for calculations.

Process Exercising On-line System


As an example, a user and a programmer-analyst exercise the

notification of reinsurers process in a new automobile insurance

claims system. This process will determine whether there are

reinsurers providing coverage on a policy for which the company

has received notice of a claim. If the reinsurer's liability is

significant, the process will prepare and print a notice to be

sent to them.

The system will be implemented in COBOL on a mainframe, but

the prototype has been done in COBOL on a microcomputer. The

database will be implemented with a hierarchical DBMS, but it is

being simulated on an indexed file access method available with

the microcomputer COBOL processor.

The reinsurance notices were originally dummied out. A user

enters a request on a screen to print all new notices, since the

last time they were prepared. The user, who is a claims

department supervisor, guides the programmer-analyst in expanding

on the processing described in the logical definition of the

prototype and in the study of the present system. The

programmer-analyst spends about two full days developing coding

for the process. He uses modules developed previously to access

the insurance database containing both claims and policy

information. He does not need the user to help on the format of

the notices, since they were previously dummied out.

While the programmer-analyst is developing the modules, the

user reviews the contents of the selected test data set. He

develops some additional data to cover fully the conditions that

may occur in this processing. He adds this data to the database

through the claims notification process and the supervisor

assignment process, after first notifying the exercising

coordinator. The coordinator saves the database contents.

The user lists the notices that the process should produce.

When the programmer-analyst has finished the module, he and the

user exercise it. It does not completely produce the results the

user expected, partly because of errors in the expected results

and partly because the module does not function as the user had

hoped. He modifies the expected results and the programmer-

analyst modifies the module. This takes another day, before they

are ready to exercise the process again. This time the results

are as the user had hoped.

They ask the exercising coordinator to replace the database

contents for the selected data set they were using with the new

version they have created. They also ask him to replace the

program module for producing the notice with the new module. He

will check for inadvertant changes before changing modules. They

keep copies of the reinsurer notices to review with the entire


Process Exercising Package Modification


An example of process prototyping for a package modification

is exercising the trial balance produced by a financial package.

A user who is a supervisor from the corporate accounting

department will do the prototyping. The account table the system

uses to define what the accounts are and how entries for them are

to be processed has been partially completed and some

corresponding journal entries made as part of a test data set.

The user will add enough data for two accounts to ensure that

more than a page will be printed for each on the account activity

report. The exercising coordinator will save the database

contents first.

The user will run the trial balance and check the results.

If he is satisfied, he will add additional accounts to the

account table and to the journal entries and run it again. He

will continue this process, working with the exercising

coordinator, until he has made an entry in the account table for

all the accounts. When he is finished, he will ask the

exercising coordinator to save the journal entries as a new test

data set.

Process Exercising Batch System


An example of exercising a process is exercising the net pay

calculation module in a new batch payroll system. The team

members will have already reviewed the preparation of the inputs

to the module and the printing of the check and check stub from

its results (see Data Exercising for New Batch System above),

when they performed the prototyping sessions for the data.

A user, who is a supervisor from the payroll department, and

a programmer-analyst, will do the prototyping. First, they must

develop the process which, until now, they have only been

dummying out. The data dictionary contains processing rules for

some elements, such as amount net pay, and the function

description portion of the prototype definition contains a brief

description of the processing. The study notes on the present

system contain a further description of the processing. The user

and the programmer-analyst will develop the full processing.

They will describe it to the person with documentation

responsibility, so he may draft it for the user guide.

The module, which until this point is written in a fourth

generation language, already contains the outline of the

processing. It contains statements for reading the inputs and

producing the outputs. The ultimate language the team chose for

this module is COBOL. Since temporarily used languages are to be

replaced during process exercising, the programmer-analyst, in

his first expansion of the module, will redo what was written in

the fourth generation language and add the logic but not the

mathematical processes.

While the programmer-analyst is doing this, the user gathers

test data to add to the selected test data set they will use.

One source he will draw from is the data that was used for

exercising the check and check stub, as described above. He also

lists what he expects the contents of the resulting paychecks and

check stubs will be.

Before modifying the selected test data set for them, the

exercising coordinator saves the old version. He also saves the

existing version of the net pay calculation module.

When they are ready, the user and the programmer-analyst

exercise the module. This exercising demonstrates whether the

module chooses the proper input records, even though it does not

yet actually calculate the amounts.

After they produce satisfactory results with the incomplete

module, the programmer-analyst adds the mathematical calculations

to the program. Then they perform additional prototyping

sessions and make any necessary modifications until the module

produces satisfactory results.

The user and programmer-analyst save the results of the

successful exercising sessions to review with the entire team.

They ask the exercising coordinator to change to the new module,

test data set, and benchmark outputs for the check and check

stub. Before doing this the exercising coordinator must run the

prototype using the old test data set and the new module to check

whether anything was inadvertantly changed. If not, he makes the

requested changes.

Process Exercising System Enhancement


A final example of process exercising is a user and a

programmer-analyst exercising the reservations entry process of

an airline reservations system (discussed under Data Exercising

for System Enhancement above).

The same user has previously exercised the screen, including

a dummied version of the seat availability check. The user

may use the test data developed for the prior exercising for this

process exercising.

The programming language being used is the one provided with

the relational DBMS used for this microcomputer-based system.

Although the program must access and update five different

relational databases, the programming to be done is straight-

forward. The programmer-analyst asks the exercising coordinator

to save the current program that reads the screen before he

begins working on the new version.

After the programmer-analyst has completed writing the

program, he and the user exercise the new module. They discover

a few size discrepancies between elements on the database and on

the screen. The database agrees with the data dictionary, but

the screen does not. They modify the screen and exercise again

until they are satisfied with the results. They save copies of

the screen input and selected database output to review with the

entire team. They ask the exercising coordinator to make the new

version of the screen program the current version. He does after

first running the rest of the prototype with the database

containing the data temporarily added to it to ensure it does not

cause another part of the system to fail.

Additional Aspects of Process Exercising

The aspects of data exercising described above also apply to

exercising the processes. Table VI-18 lists a few additional

aspects that apply to process exercising.


. Change to final programming language now

. First full development of processing requirements

. One exercising assignment may require several


Table VI-18 Additional Aspects of Process Exercising

If another programming language has been temporarily used

for a module, the team should change to the ultimate language as

the process exercising begins. For example, if a fourth

generation language was used for a module, but COBOL will be the

language for the final version of it, the team should rewrite it

in COBOL as they begin the process exercising of it.

The team may never have developed the full requirements for

a module before the process exercising of it. They may have

studied the processing when studying the present system and they

may have identified it in the definition of the prototype, but

they may not have developed the full requirements for it.

Because developing the requirements for a process, preparing

test data for it, changing programming languages, and exercising

it until it is correct may require considerable effort, several

mandays may be required to exercise some modules.

Exercising for Edits


In the third stage of discovery the project team should

focus on the edits, validations, and controls for the system.

The prototype definition and the data dictionary are the

principal sources for doing them.

Edit is changing the value of one or more

information elements.

Validation is inspecting data to determine whether

it is acceptable.

Controls are procedures and data used to ensure

that only correct data is processed.

Often more than half the expense of developing and

programming a new system is for its edits, validations, and

controls. Many times elaborate ones are developed to prevent

something, that is logically possible but that might only rarely

happen, from happening. An important reason for not focusing on

them until the third stage of discovery is to give the users

experience with the system they have been helping to prototype,

before they decide whether to implement them. This experience

often leads the users to simplify or to view as unnecessary

edits, validations, and controls which they might have otherwise

requested. The time that will be required to add them to a

system the users are familiar with and enthusiastic to begin

using also may influence them to be sparing in their requests.

The team members do not define the edits, validations, and

controls when they originally complete the Information Element

Descriptions as part of defining the prototype. As they add

edits, validations, and controls in this phase, they should

update the data dictionary with descriptions of them.

Edit Exercising On-line System


Exercising an automobile insurance claims system to verify

coverage is an example of exercising edits, validations, and

controls. Part of the information entered on a new claim, as

described under Data Exercising for New On-line System above,

are estimated claim amount and policy number for the insurance

policy against which the claim is made. If there is not adequate

coverage for that large a claim under the policy, the system

should notify the clerk who is entering the claim.

A user, who is a supervisor from the claims department, and

a programmer analyst exercise this verification. The current

version of the program checks the policy coverage record on the

database and dummies out the notice on coverage. The user and

the programmer-analyst develop the procedure for checking claim

type against coverage type for a policy and determining whether

the policy is still in force. The supervisor adds a reference to

this procedure to the validation description of the claim amount

element in the data dictionary. The programmer-analyst adds this

processing to the module, after the exercising coordinator first

saves the old version of the module and the database. The user

develops some test data to test the various conditions that may


When the modified module is ready, the user enters the test

data he has developed. The program produces the results that the

user expected. They save a copy of the results to review with

the other members of the team.

The programmer-analyst asks the exercising coordinator to

make the modified module the new version and to make the input

data part of the selected test data set. After ensuring that the

new module does not cause an inadvertant failure when a test data

set is run against it, the exercising coordinator makes it the

current version for the prototype.

Edit Exercising Package Modification


Adding edits, validations, and controls to the journal entry

processing of a new financial package is an example of such work

with a package modification.

The team wants to add edits to change the value of some

obsolete account numbers on entries from feeding systems to the

account numbers that are currently used.

They also want to activate the batch control processing

which is part of the package, but which they have not yet used.

The batch control processing suspends action until corrections

are made on out-of-balance batches or on batches whose input

batch totals disagree with the batch totals the system computes.

In earlier exercising sessions team members finished making

entries in the account table for all the accounts. They now want

to activate the option to reject any entries not containing these

account numbers. In addition, they want to use options in the

account table to reject the entry of any accounts for a

department except those specified as valid.

A supervisor from corporate accounting and another

accountant along with a programmer-analyst form the team to do

this exercising. The users make all the changes to the account

table, after first notifiying the exercising coordinator so he

may save the current versions of the database and the test data

set that they want to augment.

The first entries they make should be the edits for obsolete

account numbers. While they are doing that the programmer-

analyst should extract test files from the test systems of the

feeding systems. When he has this data, he may exercise with it.

One of the users should review the results.

As the users make the other account table changes, they

should add data to the test data set to check that both valid and

invalid entries are properly processed. They should also prepare

batches that exercise all the batch control options.

When they have successfully completed the exercising, they

should identify for the exercising coordinator the test data set,

account table, and database that should become the new versions.

They should also save printouts of the results of the exercising

session to review with the other members of the team.

Edit Exercising System Enhancement


Exercising edits and validations for the reservations input

screen in an airline passenger profile system that is being

enhanced to become a reservations system is another example.

Figure VI-1 shows a sample screen. The team members are using the

microcomputer DBMS language that the profile system was written

in to make the changes.

A user who is a reservations department supervisor and a

programmer-analyst are doing the exercising. The user wants some

simple edits including the automatic capitalization of the first

character of each name field and the removal of all commas from

certain fields, such as name and address fields. The user wants

all fields that should be numeric validated that they are and

amount fields validated for maximum amounts. In addition, the

user wants the booked by element validated for one of three valid

values and the company name validated against the corporate

account number assigned to it. The user adds the specification

of these validations to the data dictionary.

Before beginning work on the changes, the programmer-analyst

asks the exercising coordinator to save the current version of

the screen input program and the current version of the database.

While the programmer-analyst adds the edits and validations the

user prepares test data and expected results with which to

exercise the screen.

The user and the programmer-analyst exercise the screen

until they are satisfied with the results. They save a copy of

them for review with the other members of the team. They ask

the exercising coordinator to add the test input to a selected

test data set and to use the new screen program as the latest

version. Before he does this, the exercising coordinator runs

the prior test data sets with the new version of the program to

ensure that no inadvertant changes were made.

Aspects of Edit Exercising


The aspects of data exercising described in Table VI-17

above also apply to exercising edits, validations, and controls.

Exercising edits, validations, and controls is similar to

exercising processes in that one exercising assignment may

require several mandays of work to complete.

Team Reviews


Team reviews are reviews, by all the members of the

prototyping project team and other responsible users, of the

results of individual exercising sessions done by smaller teams.

They are the heart of exercising, because they enable users who

do not actually participate in a session, as well as the

Information Systems members of the team, to review and to comment

on the results of the session. This promotes the user

involvement which is an essential factor for success in

exercising the prototype. It also secures better participation

by the Information Systems members.

Team reviews should occur at least every two to three days.

They should last for one to two hours. If the group cannot

review all the exercising done in the prior two to three day

period with such a schedule, then the team reviews should occur

more frequently. Having several reviews, each lasting no longer

than two hours, is better for group enthusiasm and interest, than

having fewer reviews that last longer than two hours.

Each participant should carefully review the results of the

exercising sessions. The project leader should emphasize that

the success of the prototyping is the responsibility of the

entire team, not just those members who did the work of any

particular exercising session.

One new thing that should be done in team reviews for each

subject of an exercising sessions is deciding whether service

constraints should be established for the reports, screens, and

other outputs produced by that part of the prototype being

exercised. If they are needed, the team should develop them and

update the allowable response times in the record descriptions

with them.

Complete System


If the computer, devices, data set media, command language,

or DBMS for the prototype is different from what was planned for

the final version of the system, the team members must change to

what was planned. This includes moving from a microcomputer to a

mainframe, from a temporary database structure to the permanent

structure, from command language statements for testing to the

command language statements for operation, and from a temporary

terminal to the ultimate terminal that will be used. It includes

changing from all the things that you may initially do

differently as mentioned in Table V-9, Guidelines for Building

Initial Model. It does not include replacing temporary coding in

another language; you should have done that as you exercised the


If you must change more than one kind of thing, wherever

possible you should try to change only one kind at a time. Test

each change, then make the next change and test it. If, for

example, you must change terminal devices and the DBMS, change

the terminal device first. After you have successfully tested

that with the smallest possible test data set, then change to the

ultimate DBMS and test that. Working this way will make

isolating and correcting problems easier.

In the example of the insurance claims system that has been

used here, you would need to change from the microcomputer and

simulated database that was used to the mainframe computer and

the actual database. This would also imply a change in

terminals, since the microcomputer itself was acting as the

terminal in the prototype. In this case, you will need to change

terminals when you change computers. Also, the mainframe does

not have a DBMS like the one used on the microcomputer to

simulate the ultimate DBMS. You could use an indexed file access

method on the mainframe to simulate the database, but this would

be additional work in which you might make errors. Because of

this, you may decide to change to the ultimate DBMS at the same

time as you change computer and terminal. You should test this

thoroughly with all the test data sets that you have.

Complete Test System


If the exercising coordinator has not been able to keep up

with all the changes and additions that were made to the test

data sets during the prototype exercising phase, he should

complete them. The project leader should also determine whether

the team has produced all the test data sets that were planned.

If they have not, he should have some team members complete them.

This work may continue into the next phase, although it will have

to be finished before the acceptance testing can be completed.

Complete Requirements Agreement


The users and Information Systems should formally give

notice that they agree on the requirements and that the prototype

meets them. Since prototyping has been the means for developing

much of the requirements, doing this may be straightforward.

Instead of separate documentation of them, they may point to the

prototype itself, the data dictionary descriptions of the

information in the system, and the draft user guide as the

requirements documentation.

Progress Monitoring


Progress monitoring the work of this phase may be more

difficult than progress monitoring the work of other phases,

because the exercising itself may lead the team members to add

new features to the system or to eliminate features from it. Yet

the schedule should contain specific milestones to which the team

members should adhere.

If the original planning was good, then the allowances made

for adding and eliminating features should be good. The

principal concern of the project leader may be making specific

changes to the schedule and its milestones while staying within

the major milestones for the phase.

Prototype Becomes the System

When you have finished exercising the prototype, done

anything that was necessary to complete the system, completed the

test system, and agreed on the requirements,




. Exercising a prototype is testing it, training with it,

modifying it, and expanding it until it becomes the


. Persons should join the project team in this phase:

- To maintain version control

- To develop draft user guide.

. Prototyping stages of discovery focus on:

- Data

- Processes

- Edits, validations, and Controls

. Results of prototyping:

- The system

- Test system

- User documentation

- Requirements agreement

- Cadre of trained users

. Test system consists of:

- Test data sets

- Tools

- Controls

. Factors essential for successful prototyping:

- User involvement

- Version control

- Test system

- Exercising frequently

- Changing quickly

- Stabilizing architecture

- Project management

. Method for exercising the prototype:

- Plan

- Develop test system

- Familiarize team with prototype

- Train as you go

- Conduct sessions

- Team reviews

- Complete test system

- Complete system

- Complete requirements agreement

. Parts of a typical exercising session:

- Develop test data

- Exercise the component or feature

- Review results

- Modify the prototype

- Test the modification

Home | Contact Us