ManageKnowledge.com
Atwater, Lantz, Hunter & Co.
Site Under Construction
CHAPTER V: BUILDING THE PROTOTYPE
This chapter describes building the prototype, including the
database, program modules, screens, and reports. It also discusses
expanding the team, choosing tools, and building the prototype on a
microcomputer.
In the phase described in the last chapter, you define the
blueprint for the prototype by:
. Doing system talkthroughs
. Listing system functions, screen and report contents
. Defining the information using a data dictionary
. Developing the physical definition
. Ordering equipment needed for prototyping
In the prototype building phase you are actually going to put all
the pieces together and make them work. The initial model of the
prototype will be a software mock-up. It will move data between program
modules and to and from communicating systems, process input from
screens, and produce reports and screens. Table V-4 shows what you must
build.
BUILDING THE PROTOTYPE
. Build the database
- Define it
- Enter test data into it
. Build the initial model
- Program modules
- Screens
- Reports
- Program-to-program files
Table 5 - 1 Building the Prototype
This chapter will also consider the differences in building the
prototype depending on whether the system it is for is batch, on-line,
based on a package, or an enhancement or modification to an existing
system.
Table V-2 lists the criteria for building the prototype. Speed is
the most important consideration in building a prototype. Build
something quickly so you may begin to exercise it.
CRITERIA FOR INITIAL MODEL
. Bring it up fast
. Build all the components
. Move data with it
Table 5 - 2 Criteria for Initial Model
Build all the components of the initial model. Construct as
complete as possible a database from its definition. Also, make all
program-to-program files as complete as possible. The other components
of the prototype must all be present. You must program something for
each program module, even if it is only an entrance and an exit. You
must produce something for each screen or report, even if it is only a
heading or one or two elements. You must have some data on the
database. But, you do not need to complete all parts of the screens,
reports, and program modules. Table V-3 shows which parts of the
initial model must be complete and which may be only partly done.
The prototype must work, or you cannot exercise it. Build the
initial model so that it moves data from initial input through final
output.
COMPLETENESS OF INITIAL MODEL
. Database . Complete
. Test data . Partial
. Program modules . Partial
. Program-to-program files . Complete
. Screens . Partial
. Reports . Partial
Table 5 - 3 Completeness of Initial Model
Expanding the Project Team
Chapter IV discusses establishing the project team to define the
prototype. Now you must expand the team, first to build the prototype
and then to exercise it. Ideally the same users will stay with the
project,
although those who are managers may not spend much time building the
prototype nor making the modifications to it that exercising it
requires. Different Information Systems persons may join the project
now. And, some of the Information Systems persons skilled in
preliminary requirements definition may leave the project.
Persons with different skills should work on different parts of the
prototype building. Table V-4 lists who should build the different
components. If a fourth generation language (4GL) is used, teams
composed of users and programmer-analysts (PA) can build many of the
prototype's components. If a fourth generation language is not used,
programmer-analysts will have to do more of the prototype building.
They will need to use problem solution languages and utilities which
users cannot readily learn.
PROTOTYPE BUILDING TASKS
_____________________________________________________
| COMPONENT | TO BE DONE BY |
| |______________________________________|
| | WITH 4GL | WITHOUT 4GL |
|______________|__________________|___________________|
| Database | User-PA Teams | Database Admin. |
| | | |
| Test data | User-PA Teams | User-PA Teams |
| | | |
| Program | User-PA Teams | PAs |
| modules | or PAs | |
| | | |
| Screens | User-PA Teams | PAs |
| | | |
| Reports | User-PA Teams | PAs |
| | | |
| Program-to- | PAs | PAs |
|_program_files|__________________|___________________|
Table 5 - 4 Prototype Building Tasks
Table V-5 lists the skills the team members need to build the
prototype. Either users or Information Systems persons may possess some
skills, depending on whether fourth generation languages are used. For
example, if a relational DBMS is used, users may readily learn how to
define database records. If a hierarchical database is used, not only
may the users on the team not be able to define the database, but the
programmer-analyst may also need the assistance of the database
administrators. Similarly, the utilities for loading a relational
database are often easy to use, whereas one to load a network database
may require specialized Information Systems skills.
Team members should be skilled in the language or languages to be
used for writing the program modules and the command language procedures
that will comprise the prototype. Some team members should be skilled
in structured programming and modularization techniques to ensure the
modules and their interrelationships are well developed. Team members
will also need knowledge of the screen painters or mappers and the
report writers that will be used.
SKILLS REQUIRED FOR PROTOTYPE BUILDING
. DBMS Definition Language
. Database Loading Utilities
. Ability To Program in Language Used for Modules
. Structured Programming and Program Modularization
Techniques
. Screen Painter/Mapper
. Report Writer
. Knowledge of System Requirements and Data Characteristics
. Procedures for Control of Different Versions
Table 5 - 5 Skills for Building Prototype
Knowledge of the system requirements and data characteristics is
also essential for successfully building the prototype. Part of this
knowledge should be provided by the users and the Information Systems
persons who have stayed with the project to provide continuity. Another
part of it should be provided by team members who are able to use and
understand the prototype definition and data dictionary entries made in
the previous phase.
Another function, which will be even more important when you begin
to exercise the prototype, is maintaining control of the different
versions of its components. The title for this function is exercising
coordinator (see Chapter VI). Someone, possibly a documentation
specialist or a programmer, should have this as their primary
responsibility.
Choosing the Tools
As Chapter I stated, you can prototype without using any of the
tools commonly associated with it. But, using tools does make
prototyping easier. Table V-6 lists those tools that help you to
prototype.
TOOLS FOR PROTOTYPING
. Data dictionary
. Interactive testing
. Version control
. Fourth generation language
. Relational DBMS
Table 5 - 6 Tools for Prototyping
Data dictionary You should have already chosen the data dictionary
to use, when you defined the prototype. It should serve you as you
build the prototype. For example, when you use the name of an element
in painting a screen or specifying a report, the data dictionary ideally
will provide you the characteristics of the element for incorporation in
the screen map or report program. If the data dictionary will not do
that automatically, you should at least be able to use it to get the
definition and characteristics of each element that you use. If changes
arise as you are building the prototype, the data dictionary should
allow you to update it easily.
Interactive testing An interactive testing system lets you use a
terminal to change programs easily, to submit frequent tests, and to
review the results of test sessions quickly without having to wait for
batch output. It should also allow you to switch readily between
different versions of programs and databases. You will be testing
extensively as you exercise the prototype, but you will also be testing
as you build it to ensure that is works.
Version control A library system, that may be a part of the
operating system, to allow the storage and retrieval of different
versions of the prototype's components, is important for exercising the
prototype. Even though you will not use it until exercising begins, you
should prepare for it when you build the prototype. The components are
all the parts of the prototype: program modules, screen maps, record
definitions, report programs, collections of test data, and command
language procedures.
You may have reasons for having more than one version of the
prototype at any one time. If you do, what is said here for one version
applies to each that you may be using.
You need to know two kinds of version information about the
prototype:
1. The version of each component that was part of it any
time it was operating
2. A description of each component.
Fourth generation language The features of a fourth generation
language (4GL) that are particularly helpful are its report writer,
screen mapper, and query language. Fourth generation languages often
contain their own DBMS. You may actually obtain these features
separately without obtaining a fourth generation language.
You may want to use a fourth generation language for parts of the
prototype or for all of it. You may want to use it temporarily or also
in the final version of the system. In deciding whether and where to
use a fourth generation language, you should consider the advantages and
disadvantages listed in Table V-7.
Fourth generation languages enable you to bring up the more
straightforward parts of the prototype quickly. Establishing databases,
mapping screens, writing reports, and setting up inquiries are easy
using them. Making a change this afternoon to what you did this morning
is easy. With guidance from Information Systems programmer-analysts
users normally learn their basic features readily and can work
extensively with them.
FOURTH GENERATION LANGUAGE FEATURES
ADVANTAGES DISADVANTAGES
. Quick Implementation . Stylized Formats
. Easy To Use . Requires Own Environment
. Easy to Change . Peculiar Files
. User-Friendly . Complex Logic Is Difficult
. Inefficient
Table 5 - 7 Fourth Generation Language Features
Fourth generation languages often have stylized formats for
screens, reports, and inquiries. You may not want to continue to use
these formats if you replace the fourth generation language. Since
users and Information Systems persons may have become familiar with the
formats of the fourth generation language, some additional time may be
needed for familiarization and training with the ultimate formats.
Fourth generation languages often require their own environment.
If a mixture of languages is allowed at all, the fourth generation
language may have to be in control. These languages often use only
their own peculiar files. These factors may require that major portions
of the prototype be controlled by fourth generation languages.
Programming simple processes in fourth generation languages is
usually easy, but programming complicated logic may be much more
difficult than with problem solution languages like COBOL.
Programs developed with fourth generation languages are often
operationally inefficient. This should not affect the use of fourth
generation languages for the early versions of the prototype, but it
should influence the decision of whether to keep parts of the final
version in the fourth generation language. You should balance estimates
of processing cost differences during a time period, such as one or two
years, against any increased development and maintenance costs using a
problem solution language.
You must also balance the ability the fourth generation language
gives you to get the prototype up fast against the later need to
reprogram, and possibly to redo the physical design, for the use of the
ultimate language or the ultimate DBMS.
Relational DBMS Using a relational DBMS for prototyping lets you
modify the database much more quickly than using a hierarchical or
network DBMS. You must balance the ease of using it with the work that
will be required to replace it with the ultimate DBMS.
Planning To Build and Monitoring Progress
Table V-8 lists the essential elements for success in building the
prototype. The plan and schedule that you develop should meet the
criteria for the initial model in Table V-2 and should include a firm
schedule with specific assignments for the various team members.
Earlier parts of this chapter discuss what must be done to build the
prototype. Table V-4 lists the prototype building tasks.
ESSENTIAL ELEMENTS FOR PROTOTYPE BUILDING SUCCESS
. Assign specific responsibilities
. Publish and follow a firm schedule
. Keep team members and management informed
. Monitor quality and quantity of work
. Follow the criteria for the initial model (Table V-2)
Table 5 - 8 Essential Elements for Prototype Building Success
Table V-3 differentiates between those components of the prototype
that should be completely built and those that only need to be partially
built. You do not need to develop a set of test data that will
exhaustively test the prototype's features, but you should develop some
data for all the different information elements and records on the data
base. Whether you should completely build a screen should depend on
whether the screen is significant for modifying the database or
controlling the processing of the system. Similarly, whether you should
completely write a report should depend on the importance of the report
for reviewing the contents and status of the database.
One criteria for building the prototype is to bring it up fast. If
the team is large enough, on a typical day, early in the prototype
building phase, some team members will be specifying the database, user
members will be developing test data to load into the database, teams of
users and programmer analysts will be painting screens and writing
reports, and others will be developing program modules. Figure V-1
depicts this overlapping of tasks.
SIMULTANEITY OF TASKS
________________________ ________________________
| Build Database | |
|________________________| Load Database |
| Develop Test Data | |
|________________________|________________________|
| Paint Screens |
|_________________________________________________|
| Write Program Modules |
|_________________________________________________|
| Write Reports |
|_________________________________________________|
Figure 5 - 1 Simultaneity of Prototype Building Tasks
Drawing a line between building the prototype and exercising it is
difficult, because you should verify that the modules function correctly
before you are finished. This requires testing them. If they do not
perform properly, you should correct them. This implies iteration which
is the very life's breath of exercising the prototype. Nevertheless, to
be methodological about prototyping, you must schedule distinct
beginnings and endings to the various prototyping phases, including
building the prototype. Likewise, you must assign persons to individual
tasks with the intention of completing these tasks with the manpower
allocated by the dates indicated.
The project team members should meet frequently to discuss progress
and problems. The project leader should also meet often with user and
Information Systems management to inform them about the project.
One final key milestone should be a demonstration of the initial
model to user and Information Systems management at the completion of
this phase.
The Initial Model and Final System
The initial model of a prototype should feel as much as possible
like the final version of the system. This is why you should expedite
securing any special equipment that may be needed, as mentioned in
Chapter IV. But, what does feeling like the final version of the system
mean? If a specific brand of CRT terminal will be used for input,
should you only use such a terminal for prototyping? If a report will
be produced on special stock paper, should you wait for that paper
before running the report? The answer to such questions is "Yes;" it
is also "No." Before you finish prototyping, you should use the
terminal you will use in the production system and you should run the
report on the special form for it. Nevertheless, in the early stages of
prototyping you may use other terminals and plain stock paper.
You should not simulate a report with a screen, nor should you
simulate a screen with paper. But, you may simulate one terminal with
another or one type of paper with another. Table V-9 specifies what you
should or should not change in the initial model of the prototype
compared to the final version of the system.
Since the prototype eventually becomes the system, all differences
between the initial model and the final version of the system must
gradually be changed. You should weigh the work of making the changes
with the advantages creating temporary differences will give. Table V-
10 lists the possible advantages you may receive from making such
differences.
GUIDELINES FOR INITIAL MODEL
DON'T CHANGE:
. Media of external inputs or outputs
. Sequence of inputs, outputs, or program-to-program
files
. Structure of the system or interrelationships between
programs
. Database sequence, contents, or structure
YOU MAY CHANGE:
. Media of database or program-to-program files
. DBMS
. Programming language and command language
. Specific input or output devices or forms
. Computer
Table 5 - 9 Guidelines for Building Initial Model
A difference in the initial model may be much easier to use than
what will be used in the ultimate system. A relational DBMS may be much
less complicated than a hierarchical one. Running tests with a program-
to-program file on disk rather than the tape that will later be used for
it should improve the turnaround time for tests.
POSSIBLE ADVANTAGES OF TEMPORARY DIFFERENCES
. Easy to use
. Start up quickly
. Easy to modify
. Available
. Accessible
Table 5 - 10 Possible Advantages of Temporary Differences
You may be able to start up the initial model more quickly by
making some differences between it and the final system. An obvious
example is not waiting for special forms before printing reports.
Another example is that bringing up program modules with a fourth
generation language is much quicker than with a problem solution
language.
Some differences in the initial model may make it easy to modify
compared to the ultimate system. Changing a relational database should
be much quicker than changing a network database.
Some equipment may be more readily available than the exact
equipment that will be used in the final version of the system. This
may be true of storage media or input and output devices, or even
computers.
Also, some equipment may be more accessible than what will
eventually be used. You may be able to use microcomputers, but not able
to schedule sufficient time on a mainframe like what the final version
of the system will use.
Building the Prototype on a Micro First
Even though a new system will ultimately operate on a mainframe or
minicomputer, you may have cogent reasons for building it first on a
microcomputer.
As an example the new system may be for casualty insurance claims
administration. It will contain provisions for recording new claims,
evaluating them, assigning them to claims administrators, processing
them, informing reinsurers of them, paying them, closing them, and
reporting and answering inquiries on them. Bringing up the system will
require adding records and information elements to an existing insurance
data base on a hierarchical DBMS containing information on insurance
policies in force, premium payments, and reinsurance. The system will
be on-line on a large mainframe using dumb terminals for updating and
inquiry.
The system will consist primarily of COBOL programs with some
infrequently used screens and reports in a fourth generation language.
Some problems you might encounter include:
1. The claims department has no terminals that may be used
for prototyping and delivery of additional terminals will
require six months
2. Data administration does not want to set up a new test
database, when the team is only 80% sure of its contents and structure
3. Data administration does not have the resources to make
frequent changes to the database during the early prototyping
You might have available:
1. Several microcomputers
2. A COBOL processor with provisions for indexed sequential
files
3. A microcomputer version of the fourth generation
language you will use in the final version of the system
4. A relational DBMS peculiar to microcomputers
You could install microcomputers in the claims department. They
would serve as terminals for the early stages of prototyping. You might
write the program modules for the initial model in COBOL and the fourth
generation language. You would change the media of the database and
program-to-program files to floppy diskette.
To simulate a hierarchical database you might use overlaying
definitions of different record types on an indexed sequential file.
Naturally, you would be temporarily changing computers, command
language, and printers.
Using microcomputers this way is within the guidelines for building
the initial model in Table V-9. In fact, you would not have changed
programming language.
A different alternative would be to build the initial model using
the DBMS peculiar to the microcomputer, instead of using COBOL. This
might enable you to shake out at least some of the changes to the
database more quickly. But, since this might be quite different from
the final version of the system, you might not want to build the
complete initial model. Furthermore, you might not want to exercise the
prototype much, before rewriting the programs.
Building the Database
The following is the definition of database used in this book:
database: a file used by more than one system and
accessible in more than one way
The definition of file follows.
file: a collection of one or more record types
According to these definitions, an indexed sequential file with
alternate indices would be a database if it is used by more than one
system. It is a collection of records, accessible in more than one way,
and used by more than one system. Its DBMS may be no more elaborate
than the implementation of its access method.
Building the database is specifying it to the DBMS. The definition
of it in the data dictionary is the source for its specification.
Ideally, the actual specification statements may be generated from the
data dictionary entries.
The project team is responsible for the database specification,
whether it is generated from the data dictionary, by persons working on
the project, or by the database administrators. The database to be
built may be either hierarchical, network, relational, or indexed. If
it is hierarchical or network, designers, possibly from the
organization's database administration area, should specify it. If it
is relational, users and programmer-analysts may specify it. If it is
indexed, programmer-analysts will need to apply their skills to
specifying it.
If the prototype is for a new on-line or batch system, the database
may be entirely new. If the project is based on a software package, it
has probably already been specified. If the project is a modification
to an existing system, the database may be a change to an existing
database.
You should begin building the database as soon as possible and try
to complete it as quickly as possible. You cannot load test data into
it until you have finished it. And, without the database you cannot
test program modules, screens, and reports that use it.
Especially if the DBMS used for the initial model will not be the
one used in the final version of the system, build data access modules
that insulate the programs from the actual DBMS. A using program will
call a module to bring in or put out each record. Then the later
migration to another DBMS should only require changing the access
modules.
Entering Test Data
The early entry into the database of some selected test data will
help you test the processing of the initial model and its generation of
reports and output screens. Selected test data is small in quantity,
but intended to contain a rich variety of combinations useful for
testing the features of a system. Not only is an initial set of test
data on the database a part of the initial model, but it is also needed
to test that the initial model was properly built and does work.
The users on the project team should lead the development of the
selected test data with the assistance of programmer-analysts. If easy-
to-use, on-line utilities are used for loading the database, users
should be able to do it. If specialized batch utilities are used,
programmer-analysts on the team should probably load it.
Chapter VI will discuss developing test data in more detail. But,
you should save and label any transactions you use to test the initial
model in this phase. They may form a part of one or more test data sets
to be used to exercise the system.
Building the Initial Model (Skeletal System)
In addition to the database, the initial model of the prototype
consists of program modules, program-to-program files, screens, and
reports.
Program Stubs Moving Data
The prototype's ability to move data is one of its essential
features. Since the prototype should be as realistic as possible, you
should want the modules of the system to appear to be complete when
viewed from the outside. As you exercise the prototype, you will
concentrate on different modules at different times, changing them. To
test them you will want the modules that communicate with them to do so
in a realistic way. Consequently, whether an individual module is
complete is not important; what is important is that the module appears
to be complete - that it moves data. In this way, one may view a
prototype as comprised of program stubs moving data.
Each module should appear to read all its input files and to
produce all its output files. It may initially dummy out its output
files with hard coding, until logic can be placed in the module to
produce output from input and database data.
As an example, a payroll system module is supposed to produce the
file from which the system will print the paychecks, pay stubs, and
registers for everyone on a payroll. It calls a module to read a
calendar specifying what payrolls are to be run on what days, calls
other modules to find the database records for those employees to be
paid, calls a module to calculate the net pay, and produces the file for
the checks, stubs, and registers. The initial model will read the
calendar first. Then it will find the database records containing basic
information on employees such as social security number, name, and home
address. It will place this data on the output file along with dummy
information representing the results of the payroll calculation. The
team will add the full logic and calculations later in the exercising
phase.
If the prototype is for a new on-line or batch system all the
modules will be new. If it is for a system based on a software package,
the only new modules may be those for a pre-processor or a post-
processor to the package itself; the additional modules will join a
test copy made
of the package for prototyping. If the prototype is of a
modification to a system, many of the programs may not be changed. Test
copies of the programs that will not change along with copies of any
modified or new modules will comprise the prototype.
Table V-11 lists the sources for building the modules. The system
flow depicts all of the modules and their functions, lists the data they
will use and produce, and refers to the program-to-program files. The
logical definition contains a further description of those functions,
referenced on the system flow, that seemed to need additional
explanation.
SOURCES FOR BUILDING MODULES
. System flow
. Functions
Table 5 - 11 Sources for Building Modules
Team members should write the program modules. Wherever a fourth
generation language is used, users members, with the guidance and
assistance of Information Systems programmer-analysts, may be able to
write them. If problem solution languages are used, the programmer
analysts will have to write them.
After they are written, test whether the modules can read their
input and whether the output they produce can be read by the modules
that receive it. If the module produces reports or screens (see below),
determine whether they conform to the prototype definition. When you
have successfully tested a module, leave it and go on to other tasks.
Remember you are only building the initial model, not exercising it.
Exercising the prototype will begin when the initial model is ready.
Painting Screens
Screens provide users the ability to communicate with information
systems. With screens users can inquire about information, enter or
update information, or receive information.
Painting a screen is the process of laying out the format of a
screen, specifying the information that will be on it, identifying the
database that will be the source or recipient of its contents,
establishing the order of the conversation that uses the screen, and
providing access controls. Table V-12 lists the different facets of
screen painting.
Establishing the order of the conversation includes specifying the
sequence in which information will be displayed on a screen and the
conditions for displaying or using other screens. Access controls are
used to restrict who can enter or receive information with a screen.
SCREEN PAINTING
. Format
. Contents
. Source/Disposition
. Sequence (of presentation)
. Relationship to other screens
. Access
Table 5 - 12 Facets of Screen Painting
The screen description portion of the logical definition is the
source for all the different parts of screen painting except the format
and the information element descriptions. It also includes the
determination whether any particular screen should be completely or only
partially prepared for the initial model. The team members will lay out
the format as they paint the screens. The data dictionary is the source
for the information element descriptions. Ideally, extracting
information from the data dictionary will be automatic.
Whether screen painting is easy depends on the tools to be used.
Most fourth generation languages contain a screen mapper which
simplifies the process. A person using a screen mapper lays out the
format of the screen, differentiating between constant and variable
data. He then identifies each of the variable information elements and
the database record that contains them. He can also specify the
sequence of the information, what screen the system should display next,
and who may access the system using the screen.
If a fourth generation language is not used, the team members will
paint the screens directly with a communications control language or
indirectly with a map editor. A communications control language
requires that the screen specifications be made in a problem solution
language, such as a set of COBOL functions. A map editor allows the
user to paint the screens somewhat as he would with a fourth generation
language. Programs supporting the editor will then produce the actual
communications control language statements that are needed.
A screen mapper is normally easier to use than a map editor, and a
map editor is easier to use than a plain communications control
language. The critical difference is in who can do the screen painting.
If a fourth generation language is available, users on the team can do
much of the screen painting with guidance from Information Systems
members of the team. If a map editor is available, users may still be
able to do much of the screen painting. If only a communications
control language is available, then programmer-analysts must write the
actual language statements; although, users may assist, especially
contributing to the screen layouts.
If, when planning to build the prototype, the decision was made not
to build a screen completely, then the screen you build only needs an
identification or a heading.
Example of a New On-line System
As an example, the prototype may be for a new on-line automobile
insurance claims system. A screen to be painted is the one on which a
clerk records a claim when the company first receives notice of it. The
clerk will record the claim while taking a phone call in which the claim
is being reported or from a written notice made either by the claimant
or an adjuster.
The decision made in the prototype definition phase was that this
screen would be complete. Table V-13 lists as input the data to be
entered on the screen. Also, the system will produce a verification of
an adequate policy coverage as output.
INFORMATION FOR LOGGING INSURANCE CLAIM
. Claim number Input
. Claimant name and address Input
. Policy number Input
. Adjuster identification Input
. Description of the claim Input
. Date received Input
. Estimated claim amount Input
. Verification of coverage Output
Table 5 - 13 Information for Logging Insurance Claim
A fourth generation language is available for screen painting. The
data dictionary to be used can be accessed on-line, but the element
definitions from it cannot be incorporated automatically into the screen
painting process.
A claims department supervisor will have been trained to use the
fourth generation language, but will not have much experience using it.
The supervisor sits at the terminal, and a programmer-analyst sits with
the supervisor.
The supervisor first does the format. The supervisor is
particularly concerned that the layout of the screen fits the way the
clerk should work and also fits any documents the clerk uses as sources.
Then the supervisor and the programmer-analyst review the format and
identify the various information elements and their sources. They use
the data dictionary for the exact names and characteristics of the
various elements. The programmer-analyst specifies how the system will
call up the screen and what the access codes will be.
Example of a Package Modification
Another example is a prototype of a modification to a financial
system package for general ledger, budget, and cost accounting. The
modifications include using the package's input parameterization
features to customize its processing of input from screens and various
subsidiary systems, such as inventory control, billing, and accounts
payable. The team will also use a fourth generation language to produce
output screens and a stand-alone report writer to prepare reports.
An important input screen is the one used to enter manually
prepared journal entries. The decision made in the prototype definition
was to paint it completely. Its description is a source for the screen
painting process. The package dictates the order of the conversation of
which the screen is a part, how access control will be handled, and what
information elements must appear on the screen. It allows you to decide
on most major headings, the placement of elements on the screen, and
their exact size and characteristics. It also allows you to add several
additional characters of data which the package will maintain as part of
the journal entry.
The screen painter is a map editor. A person uses it on-line to
lay out the format of a screen and specify the size and characteristics
of the information elements. The package then edits the screen map. If
it accepts it, you may run it as a test.
The package has its own limited data dictionary which maintains
changes to package element characteristics. The organization's data
dictionary is the source for entries to the package's dictionary. The
organization's data dictionary can be accessed on-line, but the element
definitions from it cannot be incorporated automatically into the
package's dictionary.
A supervisor from corporate accounting, who has been trained in
using the map editor, will paint the journal entry screen with
assistance from a programmer-analyst. The supervisor will first lay out
the screen. Then, with the help of the programmer-analyst and drawing
information from the organization's data dictionary, the supervisor will
specify the information elements and their characteristics. The package
has pre-determined their sources and dispositions.
Example of a System Enhancement
A final example is a prototype of an enhancement to an airline
customer profile system to change it to an on-line reservations control
system. The existing system contains many reports and inquiries on
passenger trips and allows on-line input. The enhanced system will
retain the reports and inquiries, buts its focus will change to
supporting reservations clerks as they make flight reservations. The
enhancement will operate on a microcomputer. The team members will program
it in the same relational DBMS language used for the existing system.
The existing system contains a screen for entering information on a
reservation. The screen in the enhanced system will be similar, but
will have less elements and a modified layout.
A limited map editor is available. It will partially produce
programs for displaying screens. Programmers have to expand the
programs it generates.
Team members use the DBMS to implement a simplified data
dictionary. It has no automatic link to the screen mapping process.
A programmer-analyst and the reservations department manager, who
is a member of the project team, use the map editor to lay out the
modified screen. The manager sketches what he wants on a screen, then
the programmer-analyst adds element designations. They look up element
characteristics in the data dictionary to add them to the screen map.
The programmer-analyst writes a simple program to display the screen and
to allow data to be entered on it. The program at first will not update
the database.
Programs that use the screen specify the sequence of presenting
data and when, in the conversation with the reservations clerk, the
system will use the screen. Also, access controls are a feature of the
operating system; they are not specified in the DBMS language.
Producing Reports
Reports are hardcopy displays of information produced by
information systems. They include one-page summaries, voluminous
records of details, and such action documents as paychecks. Team
members may specify the production of reports using stand-alone report
writers, report writers within fourth generation languages, or problem
solution languages. Data developed as an intermediate part of a process
or data filed in a database may be the source for a report. If
intermediate data is used or the report is an action document, the
module that does the processing may produce the report.
The description of report writing here applies to modules dedicated
to producing reports or to reports produced from the program modules
described above.
The team members describe the report contents, information sources,
sequence, totaling, frequency of preparation, use of special forms, and
distribution in the prototype definition phase. The data dictionary
describes the characteristics of the information elements that will
appear on the reports. All of this information is a source for
producing the report for the initial model. The only aspect to be
decided in this phase is the report's format.
If a report is not to be built completely for the initial model,
you only need to produce an identification or a heading for it.
The user members of the project team will play a key role in laying
out the reports. If a freestanding or a fourth generation language
report writer that is easy to use is the tool chosen for report writing,
user members should also be able to do the report writing. If the
report writer is not so easy to use or a problem solution language is
used, programmer-analyst team members will have to write the reports.
Examples of Differences Based on Tools
The prototyping project team developing a batch payroll system
decide to produce complete checks and check stubs using COBOL. Their
layout is based on the design of the new special form for checks and
stubs. The input will be the program-to-program file described in an
earlier example. User members of the team will lay out the checks and
check stubs. A programmer-analyst will write the program, because COBOL
is being used.
An on-line casualty insurance claims system will produce a letter
to be sent to reinsurers to notify them of a claim against an insurance
policy for which they are providing reinsurance. Preliminary
information about the claim from the insurance database will be a source
for the report. A fourth generation language containing a good report
writer is being used for this project. A claims department supervisor
on the project team with training in the report writer can lay out the
report as he writes it.
The team developing a prototype based on a new financial system
package will produce a report of income and expense by project for a
specified time period from the database maintained by the package.
Project code is an element the organization is adding to the system; it
is not part of the package's elements. Instead of using the report
writer provided with the package, the project team is using the stand-
alone report writer that is the organization's standard. A supervisor
on the team from corporate accounting will lay out the report based on
the report description and the data dictionary. The stand-alone report
writer is somewhat easy to use. With assistance from time to time from
a programmer-analyst, the supervisor can also produce the report.
The team changing a customer profile system into an airlines
reservations control system will produce a report of passenger trips
taken and the fares received for them for a specific period of time.
The team will use the report writer which is a part of the microcomputer
relational DBMS language in which the system will be written. A manager
from accounting will lay out the report based on the description of it
in the prototype definition and based on the data dictionary. Even
though the report writer is fairly easy to use, a programmer-analyst
will write the statements to produce the report.
Communicating with Other Systems
You should consider the prototype's communication with other
systems as you build it. The prototype probably communicates with other
systems in at least one of the ways listed in Table V-14.
If the system will process data from another system, the team
should secure a test copy of the file and include it in the initial
model of the prototype.
COMMUNICATION WITH OTHER SYSTEMS
. Processes data from other system
. Shares database with other system
. Produces data for other system
. Uses data converted from other system
Table 5 - 14 Communication with Other Systems
As described earlier under Building the Database, if the prototype
will share a database with another system, the team should have a test
version of the database built for the initial model.
If the system being prototyped will produce data that will be used
by another system, the team should produce that data from the initial
model. The team should arrange to have the data the prototype produces
run through the receiving system's test system each time they change it
significantly.
If the system being prototyped will replace an existing system and
if data from the existing system will be converted to the database of
the new system by a computerized process, the conversion process itself
should become part of the prototype. The system flow describes the
conversion. The team does not have to build it as a part of the initial
model. But, since it is a source of test data for the database,
implementing it for the initial model may be a practical thing to do.
Version Control
The section above on Choosing the Tools briefly discusses tools for
maintaining version control. Theoretically the team will not establish
version control until after the initial model has been built. Actually,
during the building phase, problems may arise that will cause the team
to develop additional versions of program modules, files, or a database.
If such a need arises, refer to Chapter VI for a more thorough
discussion of this subject.
Delaying Controls and Validations
The prototype definition should describe any controls planned for
the system. But, the initial model should not include controls nor
validations. The team should implement them in the latter part of the
prototype exercising phase.
Summary
. Building the initial model, which is a software mock-up,
includes building:
- Database
- Program modules
- Screens
- Reports
- Program-to-program files
. Tools that help you prototype:
- Data dictionary
- Interactive testing
- Version control
- Fourth generation language
- Relational DBMS
. Differences are allowed between the initial model and the
final version of the prototype for:
- Media of database or program-to-program files
- DBMS
- Programming language and command language
- Specific input or output devices or forms
- Computer
. Possible advantages of building a prototype on a
microcomputer first:
- Easy to use
- Start up quickly
- Easy to modify
- Available
- Accessible
. Definition of database:
A database is a file used by more than one system and
accessible in more than one way.
. Definition of file:
A file is a collection of one or more record types.
. When building the data base use access modules to insulate
the using programs from the actual DBMS.
. Program modules must move data by reading their inputs and
producing their outputs.
. The tools available for screen painting and report writing
determine which team members can do them.
. Users should lead the laying out of screens and reports.
. Consider the prototype's communication with other systems
as you build it.