ManageKnowledge.com
Atwater, Lantz, Hunter & Co.
Site Under Construction
CHAPTER VI: EXERCISING THE PROTOTYPE
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
discovery.
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
files.
EXERCISING THE PROTOTYPE
STAGES OF DISCOVERY
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
files.
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.
RESULTS OF EXERCISING
. 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
system.
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
effort.
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.
REASONS FOR TESTING
Designing
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
expected.
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
system.
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.
TEST DATA SETS
. 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.
TEST DATA SET LOG
. 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.
DATA SET TYPES
. 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
set.
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
prototype.
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.
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
them.
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
Programs
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.
DUTIES OF EXERCISING COORDINATOR
. 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
fail.
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.
VERSION CONTROL LOG
. 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
VI-11.
TEST LOG CONTENTS
. 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
itself.
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
prototype.
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.
TOPICS OF A REQUIREMENTS AGREEMENT
Inputs
Outputs
Database
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.
FACTORS TO MAKE EXERCISING SUCCESSFUL
. 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
confusion.
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
results.
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
controls.
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
exercising.
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.
APPROACH FOR EXERCISING THE PROTOTYPE
. 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.
EXERCISING TASKS TO BE SCHEDULED
. 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
familiarization.
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
use.
ELEMENTS OF AN EXERCISING SESSION
. 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
unnecessary.
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
availability.
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.
Familiarization
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
system.
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.
Training
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
session.
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
dictionary.
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.
SAMPLE AIR CORPORATION
PASSENGER PROFILE SYSTEM
PASSENGER INFORMATION: PNR NUMBER:999901:
AGENT:KE:
BOOKED BY: Psgr (1), Sec'y (2), or Tr Agnt (3):1: SALES OFFICE: :
LAST NAME:Lantz : SAL:Mr :FIRST AND INIT:Kenneth E :
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: :
TITLE: :
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 :
SEAT RESERVATION: 5A: SMOKING?:N: SPECIAL REQUESTS:haircut :
PASSENGER COMMENTS:Works while travelling; likes good lighting
AMT: 850.80:TYPE: :LIMO: 50.00:PAY FORM:AC :
CR CARD NAME:K E Lantz :
CARD/CHECK NUMBER:88888888888888888:EXP DATE:12/86:
TRANSPORTATION TO:FROM AIRPORT:limo:limo:
COPY AND UPDATE (C) UPDATE (U) OR IGNORE (I): :
ENTER h FOR HELP: :
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
program.
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
guide.
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.
ASPECTS OF DATA EXERCISING
. Exercise everything containing data
. Test data prepared beforehand
. Test data for a session may be incorporated into test data
sets
. 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
components.
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
team.
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.
ADDITIONAL ASPECTS OF PROCESS EXERCISING
. Change to final programming language now
. First full development of processing requirements
. One exercising assignment may require several
mandays
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
occur.
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
processes.
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,
THE PROTOTYPE HAS BECOME THE SYSTEM.
Summary
. Exercising a prototype is testing it, training with it,
modifying it, and expanding it until it becomes the
system.
. 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