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

             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

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

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.


                  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

                  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

                  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

                      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

                           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

                      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

            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.


     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.


     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-