I \
-------
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
------- |