I \
-------
The classical roles of users as identifiers of
problems/information-related needs and of ADP per-
sonnel as the developers of the solutions are still
valid. PSTF must assist the program office in under-
standing the role of ADP in meeting program goals.
Although there are exceptions, many program managers
lack an understanding of what ADP can and cannot do
for them. Discussions between program and technical
ADP staff that purport to deal with how ADP can help
too often focus on the technology of the solution,
rather than on the need or the requirement. PSTF must
refocus user thinking, away from technology and toward
problem/need definition. This will require PSTF staff
to communicate with program personnel in the language
of the program. It will also require an effort on the
part of PSTF staff to become familiar with what the
program goals are and of what the potential ADP needs
might be. And it will require that PSTF personnel
build a working relationship between themselves and the
the program offices they serve. Customers cannot be
allowed to dictate solutions; ADP personnel must avoid
"pushing" a technology where no user need exists.
Identification of ADP Needs
The next step in the program systems manage-
ment and development strategy requires PSTF and the
program offices to identify, describe, and prioritize
the information-related needs of each program. The
effort is not a data processing activity per se.
Rather, it is an attempt to locate those activities
to which ADP resources may have to be applied. This
step, which will consider both the short and mid-
term, must place emphasis on explaining how the meeting
of each need relates to the accomplishment of specific
program goals. With a dwindling supply of resources,
we must be certain that the needs/problems to which we
respond are only those whose solutions impact the
achievement of major program goals.
I
-------
Inventory of ADP Resources
The Agency has made a number of attempts to inven-
tory and to describe its information resources. This is
an important activity, but such efforts have not been a
part of an Agency information strategy. The preliminary
step to such an inventory is the identification and priori-
tization of information-related needs described in the
previous paragraph. Having successfully completed this
step, an information resource inventory begins to make
sense.
Such an inventory becomes one dimension of a matrix
that matches information resources with needs. The
matrix will help us to see how well information resources
have been applied to the attainment of program goals.
The matrix may uncover several things. First, we may find
needs that relate to critical program goals that are un-
matched with any information resource. Second, we may
see information resources which have no corresponding
need. And, third, we may find resource-need pairs that
match either perfectly or imperfectly. With this infor-
mation, PSTF is positioned to help program personnel to
develop and/or to reallocate, through PSTF, the ADP re-
sources that may be required.
Justification for the Preliminary Work
The preliminary steps just discussed are basic to
all that follows. Given the resource constraints that we
now face, we must be absolutely certain that ADP is assist-
ing the program offices in attaining the goals set for the
Agency by the Administrator and the Congress. If we first
identify how ADP can help, and then apply the resources we
have (or can develop) where needed, the probability for
success on the parfof both the Agency and ADP is greatly
increased.
The action plan now addresses the technical aspects of
program system development and management.
-------
Integration of Related Data Systems
During FY84, the PSTF will emphasize the integration
of related systems. Classifying and integrating data
systems by family will help the Agency to standardize
data element names and formats and will further the sharing
of similar software. More importantly, the integrating
of systems that are similar will aid Agency managers and
analysts in responding to evolving priorities in a cost
effective manner.
For air and water quality systems {environmental
data bases), the FY84 effort will consider the impact of
standardizing data element names, parameter codes, look-
up tables, and machine readable output report files,
within and across each major system category (air systems
and water systems). The first step toward this end will
be taken in late 1984, when representatives of the air
and water offices will meet to discuss the changes that
would be required to effect standardization. The long
range goal remains the full integration of air quality
systems and water quality systems. While initial invest-
igation into system integration will take place during
the fiscal year, the actual work that will lead to inte-
gration may not begin before FY86. This we believe to
be consistent with the Deputy Administrator's goal of
avoiding program disruption where at all possible.
Facility and chemical data systems are also scheduled
to be standardized and integrated. Because of the under-
lying similarities among the systems of the facility
family, as well as among those of the chemical family,
actual work should begin in FY85. We also view these
families of systems to be in a somewhat more dynamic
state than is the environmental family. Such character-
istics make systems* within the two families particularly
well suited for integration in the near future.
Our efforts to integrate systems within these two
families will address the more basic concerns of file
organization, access methods, use of data base systems,
and update and retrieval software, along with those
already mentioned* for environmental systems (standard
data element names, parameter codes, look-up tables, and
machine readable output formats), what we foresee
resulting from our work is not a single facilities data
system and a single chemical data system. Rather, a
more likely outcome will be a confederation of related.
and compatible data systems within each family.
-------
Our detailed plan for integrating enforcement tracking
and compliance monitoring data systems is now under deve-
lopment. We expect it to be available by mid-April 1984.
Short Term Program Systems Plans
o Chemical Systems
** To be provided **
o OSWER Systems
See the Attachment to this document.
o Water Systems
** To be provided **
Uniform Application of Structured Design and Development
Technologies
The Program Systems Task Force, during FY 1984, will
begin an intensive effort to standardize applications
software systems development, both by in-house and contractor
staff. This will include; 1) wider application of structured
technologies (in particular, structured programming and
structured walkthroughs) and 2) use by programmers of IBM
3270 (or equivalent) terminals with SPF (System Productivity
Facility). The Task Force presently has in place (or has
firm plans to install) a substantial number of terminals
of this type.
Structured definition, design, and development techno-
logies are not consistently used within EPA. With the
rapid increase in the price we pay for software engineers,
we must require immediate use of structured techniques by
all Agency and contractor personnel involved in software
design and development. Individual managers must not be
given the option of waiving this requirement. Obviously,
the transition from the old technology to the new may
initially appear to have a potential for disruption. In-
dividual employees may fight the change. Program offices
S
-------
may fear interruption in service. Although there is no
guarantee that anything we do will counter these fears,
our best response will be to educate both the employee and
our program office client—the employee in the application
and benefits of the technologies and the client in how
he/she will ultimately get greater return for each dollar
spent.
The second part of this strategy element is the uniform
use of IBM 3270 (or equivalent) terminals with the System
Productivity Facility (SPF). As noted earlier, program
system offices are already beginning to acquire and to
install 3270s. We may face a problem here similar to that
described in the previous paragraph—a reluctance on the
part of individual software designers and developers to
move to something new. The use of such terminals will be
enforced. Waiving the requirement will not be an option
available to any PSTF manager.
SPF will make the writing of a structured program an
easier task. Margin alignment, among other things, can
be accomplished with little effort on the part of the
programmer. This SPF feature not only increases the main-
tainability of the program, but also produces as a by-
product source text which becomes an integral part of
the software documentation.
SPF also aids the software developer in managing
and controlling source libraries. All too often users
have experienced problems in data systems that are
directly attributable to our failing to have the proper
load module online. This facility will not eliminate
the problem, but can go along way toward reducing the
frequency of its occurrence.
Communication Between All Involved Parties
4
Failing to communicate in an adequate way has often
been cited as the cause of a diverse range of problems.
While we do not attribute all of our problems to this
failure, we do acknowledge that we can do better in
our exchange of information. Our communication failures
include the lack of any dialogue between the parties
and the absence, in some cases, where there is dialogue,
of any meaningful exchange of information. Formalizing
S
-------
communication between PSTF and the program offices is
a partial remedy. Under a consolidated ADP office,
PSTF is in effect a contractor and the program office
is the customer. Formal communication between the two
parties is a natural outgrowth of the arrangement. This
is seen in all arm's length relationships, where written
communication documents the interchange of ideas, the
issuance of orders, and the response to such orders.
American Management System's final report on CADP speci-
fies the type of formal communication that we invision.
We strongly support the designating of individual points
of contact through which all major communication is funnel-
led, not only in PSTF and the program offices, but also in
all involved regions, states, and contractor offices.
Each point of contact is then responsible for disseminating
the information exchanged to all interested parties.
Points of contact for each project will also be designated.
Having formal points of contact at the program and project
levels does not bar communication at any level. Indeed,
it requires it. Informal communication lays the groundwork
for our formal, written exchanges. Both are indispensible.
Our emphasis now on formal communication stems from our
past failure to use it to the extent we should have.
Periodic PSTF-user/client meetings are also desir-
able. Such gatherings may take the form of past STORET
user meetings or involve smaller groups over shorter
periods of time. Regardless of the shape, meetings of
this type provide managers and technicians on both sides
of the fence, opportunities to learn from the experiences
of others, to air complaints, and to suggest solutions.
Customer orientation, the first principle of the strategy,
requires that the customer be heard. Forums of this type
provide the opportunity.
Earlier, this'paper spoke of a need for program per-
sonnel and ADP staff to communicate in a language that
both understand. Jargon, which clouds our exchanges, is
not the sole property of ADP personnel. Program offices
have their acronyms, too, which they freely use. While
our goal is to communicate in English, we recognize that
jargon can facilitate the exchange of ideas. There is
an obligation, therefore, on the part of both Program and
-------
ADP staff, to learn each other's language, and a parti-
cular responsibility on the part of ADP personnel to
become familiar with the programs and with the goals of
the offices they serve.
Standardization
Many of the benefits associated with consoli-
dated ADP result directly from the standardization
that consolidation encourages. PSTF will require
standardization in a number of areas. Some of these
are presented below:
o Data element names, parameter codes, look-
up table values, and machine readable out-
put report files within system families.
(This was addressed in the section on system
integration.)
o File structure, access methods, update and
retrieval software, and data base management
systems, where appropriate. (Also addressed
earlier as a longer term goal.)
o Communication. (See the section above on
communication.)
o System and program documentation. Documen-
tation for systems of medium to large size
will include the problem specification,
logical and physical design specification,
the programming specification, the users
guide (which includes a glossary of terms
and a data element dictionary), and a
systems maintenance guide. Each of these
will be a deliverable item for all work
performed by a contractor and will be fully
in accord with all EPA standards and PIPS
Publications 38 and 64.
Much of the technical documentation
that is required will be a by-product of
the software system design and development
methodology. The System Productivity Facility
(SPF) will aid the programmer in developing
software text that reflects the logic of the
solution (e.g., subordinated program blocks
S
-------
will be indented under the higher level blocks
to which they belong). Structured programming,
top down design and development, HIPO, pseudo-
code, and structured flowcharts each contribute
documents or are themselves documents that be-
come part of the technical system documentation.
User-oriented documentation will be
written in the language of the customer, not in
the jargon of ADP. Documentation of this type
is intended to help the customer to use the
systems we provide. While description of the
internal workings of the systems and programs
are important, they do not belong in user
manuals, procedures, and guides that we give to
users. Such material is the property of
technical documentation for systems and computer
programs.
The level of detail and formality and
the number of unique documents required will
depend on the size of the system developed.
Obviously, smaller systems require less
documentation than the larger ones. But, in
every case, regardless of system size, we must
ensure that the written record communicates
what we did, why we did it, how we did it, and
how what we produced is used. The sophisti-
cation of the documentation can vary, but not
its purpose.
Software Sharing and Dissemination. PSTF will
develop standard procedures for making soft-
ware available to other ADP groups and to in-
terested users. Although the procedures are
not yet fully developed, it is clear at this
time that two things must be done early in
the process. First, a catalog of existing
software must be prepared that provides the
program name, the language, the hardware
environment, and an abstract. This step can
be part of the information resource inven-
tory described earlier in this paper.
Second, a formal mechanism will be esta-
blished for software exchange. This central
exchange authority will keep the software
S
-------
inventory up-to-date, circulate the inventory
to interested parties, receive requests, send
out requested programs, and maintain a list
of those who provide and receive the software.
o Testing
PSTF will require that program module and
system tests be developed before solution
implementation (programming) begins. Test
specifications will be jointly developed
by the client and PSTF staff as early in
the design phase as possible.
in PSTF
Software design and development personnel
STF will employ four levels of testing:
testing, where each module is separately
sd. svstem testina. where the svstem is
±11 t »j A * w JL ~L a. *.; ii i ^ J. *_-" y i-wui. a_ t v ^ j. .j wi_ w^«jv-.4.ijy»
unit testing, where each module is separatel
tested, system testing, where the system is
tested, acceptance testing, and installation
testing. Because top down design and deve-
lopment will be used, system testing begins
with the development of the first module.
PSTF will use the testing procedures
outlined in Managing a Program Project, by
Philip W. Metzger. This formal procedure re-
quires early planning, user participation,
and third party involvement. We believe test
execution by persons not involved in the
actual program coding to be essential.
o User Training
Training programs will aid our clients
in using the automated tools we provide. Such
training will include lecture, workshops, and
"hands-on" terminal sessions. All training
activity will emphasize the practical over the
theoretical, and will give examples that the
user can employ with little modification.
Career Development
Retaining high calibre ADP staff is difficult under
10
t
-------
9
the best of conditions. Unfortunately, conditions at
EPA have not always been ideal. PSTF intends to create a
climate that offers qualified technical personnel the
opportunity to attain career goals. Throughout the
Government, technically qualified personnel have had
to move to a management position to reach grade levels
above GS-13. Although this situation is not presently
within our control, we must work to get career paths
for our technical personnel that lead to GS-13 and
GS-14 levels, without such personnel having to accept
management responsibilities.
PSTF will also encourage technical personnel to attend
short and long term training sessions, conferences, exposi-
tions, etc., to become familiar with state-of-the-art
technology. Periodic, informal briefings will be conducted
by individual PSTF employees for fellow staff members and
interested users. These sessions will allow individuals
to share with others the indepth understanding that they
possess in their area of specialization.
Our goal is three fold. First, we want to offer the
employee an employment benefit that is legitimately
his/hers: the opportunity to acquire the expertise necesary
for career advancement. Second, we want to attract and
retain competent personnel. And third, we want to develop
our most important resource, the ADP professional.
Role of Planning
Planning at EPA is often viewed as a paper excercise.
The real purpose and long term benefits of planning have
difficulty emerging from the mountain of forms that we
prepare and circulate. PSTF will strongly support and
participate in all OIRM and Agency planning processes.
However, the task force urges that we re-examine both our
planning goals and procedures. A reduction in paper
work seems an obvious first step. Gaining the support
of program managers and budgetary personnel is a second.
Planning for ADP has historicallly met with much program
office resistance. We believe that cooperation will
replace opposition when the program office begins to
see planning as a way to prepare for the future. This
transformation in user thinking requires 1) that we
streamline the process and 2) that we impart to the
client an understanding of and appreciation for what we
are trying to do.
11
-------
We think it significant to note that ADP planning
is tied, to a very large degree, to program planning.
PSTF must become familiar with the tactical and strategic
plans of each program office. Program offices have not
historically been very successful in laying out short and
long-term goals. The potential impact of this program
failure on ADP planning must be recognized.
Movement__JLO_ IBM Compatible CPUs
An important mid term goal of PSTF is the installa-
tion and operation of all large program systems on IBM
compatible CPUs. We are convinced that such hardware
offers the Agency the capabilities that it will
need in the mid and late 1980s, at a price that will be
hard to beat. The movement to such hardware has begun.
Both the Office of Water and the Office of Pestcides and
Toxic Substances have acquired IBM 4341 computers.
The central computer facility at RTP has recently pro-
cured an IBM 3081. It is now time to acknowledge that
for the next five to seven years, IBM (or one of several
IBM plug compatible vendors) will provide the hardware
environment in which our systems operate. Denying
this only delays getting our systems to the opera-
tional state that we seek.
We also intend to investigate the role that the
distributed IBM 4341 (or equivalent) network will
play. One option under consideration involves dis-
tributing relevant portions of our large program
systems to each 4341 site. We await the final recom-
mendation of the ADP modernization study. With these
in hand a rational policy can be developed.
Conclusion
Our strategy for program system development and
management emphasizes providing the program offices
with the ADP support they require to meet their
program goals. This demands a customer orientation
on the part of PSTF and an understanding of and an
appreciation for the Agency's information resources
management (IRM) policy. The approach laid out here
is fully consistent with such policy. PSTF looks
forward to its implementation within the IRM frame-
work.
12
------- |