-------

-------
           VduroeA
EXECUTIVE
                                                                            ces center
                                                                                   ••/
                                                                                0   ;<
                                                                            *
               This docnment constructs a framework around which Agency program managers and
         contracting officers can document a problem and justify the need for an information processing
         solution. The objective of this document is to provide guidance towards satisfying requirements
         specified in EPA's IRM Policy Manual for the acquisition and management of information
         technology.                               >

               The guidelines within this document are designed to provide program managers and their
         staff with a suggested methodology for assessing and evaluating the need for information
         processing. Applying the methodology in this volume will result in two outputs: 1) a preliminary
         specification of a management requirement for information or information processing; and the
         outputs and benefits tied to the user's organization mission and operation, and 2) an "Initial System
         Concept" which provides an initial depiction of the inputs, outputs, and processes.

               Completion of the steps  outlined in this document will provide management with the
        information required to make a decision whether or not to proceed to the Preliminary Design and
        Options Analysis task defined in  Volume B.  The following exhibit describes the complete
        software life cycle. Each process in the software life cycle is represented by a circle with its corre-
        sponding title on the inside of the circle. Inputs to the Mission Needs Analysis or factors that
        influence the process are shown surrounding the circle. As indicated, influencing factors are: new
        legislation, changes to regulations, program growth and the preceding process Software
        Obsolescence,
                                  HEADQUARTERS LIBRARY
                                  ENVIRONMENTAL PROTECTION AGENCY
                                  WASHINGTON, O.C. 20460
CO

-------
EPA System Design & Development
Guidance: Volume A
            COMPLETE SOFTWARE LIFE CYCLE
                           ii

-------
 EPA System Design &  Development
 Guidance:  Volume A
                         TABLE OF CONTENTS
 1.    INTRODUCTION
Page

 1-1
       1.1   Background	1-1

       1.2   Objectives of the System Design and Development
            Guidance	'...1-3

       1.3.   Authority	!	1-4

       1.4   Applicability  of the  Guidance	1-4

       1.5   Documentation Requirements	1-6

       1.6   Assistance  and  Support Available	1-8


2.     CONDUCTING THE MISSION NEEDS  ANALYSIS AND
       DEVELOPING THE INITIAL SYSTEM CONCEPT           2-1


       2.1   Step 1 - Review of the Information Need Background and
            the Mission and Organizational Needs.	2-3

       2.2   Step 2 - Identification and Preliminary Specification of
            Inputs, Processes and Outputs and Development of the
            "Initial System Concept"	2-5

       2.3   Step 3 - Evaluation and Testing of the Initial System Concept
            Through User  Review	2-7

       2.4   Step 4 - Final Specification and Documentation of Results in
            the Mission Needs Statement	;	.....2-10

       2.5   Step 5-Initiation of the Project Management Plan	2-11


3.    SUMMARY                                                3-1


      3.1   Mission Needs Analysis Outputs...	3-1

      3.2   NextSteps	3-1

Appendix A

      ESSENTIAL ELEMENTS OF INFORMATION                    A-l
                                      Hi

-------
EPA  System Design &  Development
Guidance: Volume A
                            LIST OF EXHIBITS

      1-1   Guidance Audience	1-2
      1-2   EPA System Development Life Cycle and Decision Process	1-5
      1-3   System Categoiy/EEI Matrix....	1-9
      2-1   Process  Flow of Site Information	2-6
      1                                                       ^  .
      2-2   Initial System Concept - Site Management System	2-8

-------
                                    Chapter One
                               INTRODUCTION
       Pursuant to the Environmental Protection Agency's IRM Policy Manual, this volume is the
first of three volumes which provide guidance for Agency system design and development efforts.
This volume provides guidance for the first phase of the EPA system development process — The
Mission Needs Analysis.

       Volume A is intended for use by Agency Program and Management Officials and
responsible staff when making a determination regarding an information or information processing
need and whether to commit resources to identity, develop, and implement an appropriate solution
to satisfy that need. Exhibit 1-1 on the next page identifies the intended audience of this volume.

1.1    BACKGROUND
      The Environmental Protection Agency expends millions of dollars each year on the design,
development, implementation and maintenance of major environmental and administrative systems
vital to EPA's programs and administrative functioning.  Management of these resources is
becoming increasingly complex, since the rapid development of information technology in recent
years has dramatically increased computer capacity and user accessibility. .The result has been two-
fold:

      •   An increasing number of system development efforts by managers and staff at all
          r»iffiiii«aftnMl Igw.lf n/lip, hgeansft pf agceyy tn their own egmpmeny, demilnp fhair nwn
          systems independently of Agency system's start

      •   A wide range of hardware/software options for implementation of any specific system
          concept or design.

Therefore, there has been a proliferation of system development efforts by a broad range of users
with varying levels of sophistication in  making development decisions  and  conducting
development efforts.
                                       I-l

-------
EPA System Design & Development
Guidance: Volume A
                           EXHIBIT 1-1
                    GUIDANCE AUDIENCE
                        PROJECT
                        DIRECTOR
                        PROJECT
                        MANAGER
      EPA
  CONTRACTOR
                        SYSTEM
                        MANAGER
     SENIOR
     ANALYST
JUNIOR
ANALYST
MID-LEVEL
 ANALYST
                              1-2

-------
 EPA  System Design  & Development
 Guidance: Volume A
 1.2   OBJECTTVES OF THE SYSTEM DESIGN AND DEVELOPMENT GUIDANCE

       Within EPA's Office of Administration and Resources Management (OARM), the Office of
 Information Resources Management (OIRM) is responsible for ensuring the effective and efficient
 use of EPA's information resources including automated system design, development and
 maintenance. OIRM's objective in this endeavor is to provide guidance, assistance, and only when
 necessary, controls, to assure that the Agency's considerable information resources are utilized
 cost-effectively for the overall benefit of the Agency. To this end, OIRM has developed umbrella
 policies guiding information system development and acquisition (see Information Resources
 Management Policy Manual). This three-volume set of guidelines and standards for system design
 and development is a pan of OIRM's Software Management Series which is intended to assist EPA
 in efforts to develop and manage software effectively. This series will also include future guidance
 documents related to software management.

             This document is the first of the three-volume set. The volumes cover the
       following:

             Volume A - Mission Needs Analysis — is designed to provide program managers
       and staff with « suggested methodology for  assessing and evaluating the need
       (requirement) for an information system. Applying the methodology in this volume will
       result in:  1) confirmation that a need (requirement) exists and, 2) provide a preliminary
       operational specification of the requirement.

             Volume B  - Preliminary Design and  Options Analysis —  is directed towards
       program managers and staff.  It provides guidance and a methodology for structuring
       design options for meeting the requirement defined in Volume A and provides guidance for
       selecting the most cost-effective option.
                                                     t
             Volume C - System Design. Development and Implementation is intended for use
       primarily by system developers and provides specific guidance and standards which must
       be adhered to when undertaking automated system design and development efforts.

Together these three volumes provide comprehensive guidance and standards for the orderly and
cost-effective development of automated systems. Exhibit 1-2 depicts the flow of the development
life cycle and decision process for the three volumes.
                                        1-3

-------
EPA System Design & Development
Guidance:  Volume A
       In addition to the System Design and Development Guidance, OIRM is currently drafting
the EPA Information Security Manual. As security issues are raised and addressed throughout the
system development life cycle, the security manual should be consulted for proper Agency policy
and guidance.

1.3^   AUTHORITY

       The EPA System Design and Development Guidance derives its authority from Chapter 4
of the IRM Policy Manual, entitled "Software Management," which establishes the Agency
Software Management Program. The guidance serves as the primary guidance for Agency system
design and development efforts.

1.4    APPLICABILITY OF THE GUIDANCE

       Senior Agency managers and responsible staff should read the guidance and become
familiar with the decision-making process involved with system design and development efforts.
They are responsible for ensuring adequate analysis and documentation to support all critical
decision points.  The full documentation requirements for automated system development efforts,
which must be followed to conform to OARM policy, are fully discussed in Volume C.

       In general, Volumes A  and B are  intended to assist program offices and/or users in
conducting their own initial studies of system requirements, needs, option feasibility and cost-
effectiveness. In this context, the term "system" in Volumes A and B refers to a systematic set of
processes and/or procedures which can be used to meet the information needs of a user. It does
   imply that the "system" will be an automated system.
       Volume C, however, presumes that an automated or partially automated solution has been
selected as a result of the Volume B options analysis. Volume C provides guidance and standards
for automated system development efforts. If the automated system is a relatively small application
on a microcomputer targeted for use within a single office (a "user owned information system"),
Volume C provides simplified requirements for system design, development and implementation.
If the proposed system is a larger application (mainframe or minicomputer), which is mission-
critical or involves multiple offices and organizations. Volume C provides the full set of guidance
and standards which must be followed by system developers. This will assure uniform, cost-
effective system development in accordance with EPA policies, guidelines and standards.
                                         1-4

-------
EPA System Desiga & Development
Guidance: Volnme A
                          EXHIBIT 1-2
         EPA SYSTEM DEVELOPMENT LIFE CYCLE
                  AND DECISION PROCESS
    DEVELOPMENT STAGE
                                DECISION/RESULT
  c
 Real World
Mission Need
J
    .VolumeA „,»,
               Analysis
                                   REQUIREMENT AND
                                  OPERATIONAL CONCEPT
                                      DEFINITION
       , Volume B.,
             Preliminary Design Si
               Options Analyst
                                 OPTION DESIGN, BENEFIT/
                                 . COST ANALYSIS, AND
                                   OPTION SELECTION
           Volume C,
                   System Design,
                   Development &
                  Implementation
                                  FULLY IMPLEMENTED
                                       SYSTEM
                            1-5

-------
 EPA  System  Design & Development
 Guidance: Volume  A
 1.5    DOCUMENTATION REOUIREMETfTS

       In general, die intent of the three volume System Design and Development Guidance is to
 provide a consistent focus for system development efforts which will allow both EPA program
 managers and OARM managers to cost-effectively develop and maintain the Agency's systems.
 To achieve this goal, certain documentation requirements termed "Essential Elements of
 Information" (EEI) documents, must be met.  Observance of this guidance in preparing EEI's
 should result in proper documentation for audits. The EETs will also serve as a helpful reference
 for conducting post-evaluations of the system decision making process.  Each volume contains an
 appendix which outlines the required EEI documentation.

       For certain system development efforts OIRM and office Senior Information Resources
 Management Officials (SIRMOs) must be involved in a review capacity to fulfill EPA's IRM
 Policy Manual requirements.  Systems falling into one or more of the following categories must
 have OIRM/SIRMO review involvement:

       •  EPA mission critical

       *  States, local governments or other Federal agencies involved

       •  Interorganizational involvement (e.g., between Assistant Administratorships or
          including Regional Office involvement)

       •  Costs for system development/enhancement are projected  to exceed  $250,000
          (excluding costs associated with long-term system operation and maintenance)

       •  Information security issues involving the three general security areas: applications
          security, installation security and personnel security. In total, information security
          involves the precautions taken to protect the confidentiality, integrity and availability of
          information
      *   Privacy Act or confidential business information involved.

      For system development efforts falling into any one of these categories, OIRM and office
SIRMOs must be involved beginning with a review of EEM, generated at the conclusion of the
Mission Needs Analysis, as described in this volume of the EPA System Design and Development

                                         1-C

-------
Guidance. OIRM/SIRMO review involvement will continue through die development life cycle of
these systems and will include all EEFdocumentation requirements for such systems. For systems
not falling into one of die. above categories, EETs may be forwarded to OIRM/SIRMOs for
information and review as they are developed.

       A review cycle should be developed to monitor each EEI preparation. Hie review cycle
could include several stages, such as a series of status briefings for management, focus groups,
and/or distribution of die EEI in draft form. Throughout the review cycle, the managers and users
involved should be informed of the process and content of the EEI. When die final document is
completed, a consensus among management should be reached before developing the next EEL

       It is not CHUM'S intent to burden EPA managers with a host of documentation requirements
for each system development effort The EEIs simply stress typical documentation requirements
and their outlines highlight major topics that need to be Considered for any system development
effort Managers may use their professional judgment in substituting, combining, or down-scaling
the content of die EEIs to meet the unique requirements of their project

      Criteria for determining the minimum EEI documentation for a specific process during the
design, development and implementation phase is based on the nature and scope of the information
process and its importance to EPA's mission. Three types of categories describing various
systems with differing levels of EEI documentation requirements are identified as follows:

      •   TYPE I:. Major Agency /Widely Accessed Information System: An information process
          that requires special attention because of its importance to an Agency mission; its high
          development, operating, or maintenance costs or its significant impact on administration
          of Agency programs or, is widely accessed by a combination of EPA Headquarters,
          Regional Offices, state and local users and/or Federal agencies.

      *   TYPE IT: Localized Information System: An information process that is not a Major
          Agency Information System but significantly supports accepted program goals and
          missions and is  accessed primarily by users  in  one major area, e.g., EPA
          Headquarters, a single Agency program, or a Region.
      *  TYPE ITT: User Qw*"^j Information System: Unique, stand-alone process developed to
         improve the efficiency or effectiveness of operations for a single user or a small group
         of users.

                                        1-7

-------
EPA System Design &  Development
Guidance:  Volume A
      Documentation requirements for each of these categories are projected in Exhibit 1-3.
Automated systems involving information security will be subject to one additional documentation
requirement — completion of a certification form (certification of sensitive systems is an OMB
requirement).  The form, which is under development and will be issued as part of the forthcoming
EPA Information Security Manual, will capture basic information on system sensitivity, security
requirements, security design, reviews, test scenarios, results and safeguards.

1.6   ASSISTANCE AND SUPPORT AVAILABLE

      Agency Program Management officials embarking on a system development effort should
be aware that there are at least two sources available to them for assistance and support during the
system development life cycle:

      *   Within each AA/RA's office SIRMOs are available for assistance, support and guidance
          relative to the EPA System Design and Development Guidance and other  OIRM
          guidance and standards

      •   OIRM, with its general IRM management oversight role and requirements to exercise
          procurement approval authority, has a staff organized to support EPA's  administrative,
          program and research communities.

      It is appropriate to involve these support sources as early as is feasible in the system
development life cycle for most system development efforts.

      The primary reasons for early involvement of SIRMOs and OIRM staff are:

      •   Fulfilling EPA's IRM policy for system development review requirements

      *   Providing a value-added service role involving consultation, assistance, technical
          standards, guidance and interpretation of requirements

      *   Expediting procurement for system development efforts which proceed to the system
        -  design, development and implementation phase
                                         1-8

-------
EPA System Design & Development
Guidance:  Volume A
                                EXHIBIT 1-3
                         SYSTEM CATEGORY
                             EEI MATRIX
                            System
                           Category
                EEI
                Requirements
                                   Type
Type
  II
Type
 III
                EEM
                Mission Needs
                Analysis
                EEI-2
                Preliminary
                and Options.
                EEI-3
                Project
                Management Plan
                EEI-4
                System
                Implementation Plan
                EEI-5
                System Detailed
                Requirements Doc.
               EEI-6
               Software
               Management Plan
               EEI-7
               Software Test and
               Acceptance Plan
               EEI-8
               Software Design
               Document
               EEI-9
               Software Maint.
               Document
               EEI-10
               Software Operations
               Document
               EEI-11
               Software User's
               Reference Guide
               EEI-12
               System Integration
               Test Report
                                 1-9


-------
EPA System Design & Development
Guidance: Volume A
       *   Providing assistance in determining user needs as early as possible in the life cycle.
                                                                             ~f
Achieving these objectives will strengthen EPA's system development efforts and avoid major
pitfalls that have beset system development efforts in other government agencies (e.g., project
stalls due to outyear funding shortages stemming from  under-projected planning or project
disruptions due to failure to get hardware/software acquisitions into the procurement cycle
expeditiously and when required).

       The remainder of Volume A provides requirements for conducting the first phase of the
system development process - the Mission Needs Analysis, including development of the Initial
System Concept
                                        1-10

-------
                                   .Chapter Two
       CONDUCTING THE MISSION NEEDS ANALYSIS  AND
          DEVELOPING THE INITIAL SYSTEM CONCEPT
       This chapter provides guidance for the first and most critical stage in initiating any system
development effort - the Mission Needs Analysis.

       The decision to initiate system development efforts should be based on a perceived or
existing mission-based information or information processing need. This need may be prompted
by any number of factors such as new legislation, changes in regulations, or program growth
which may create needs for additional data, changes in practices or additional demands on existing
functions and resources.

       As a result of  the Mission Needs Analysis, the manager should have a  complete
understanding of the problem and be able to demonstrate that the problem and solution are within
the manager's organizational mission.   This will  provide the manager with the necessary
information to justify the need for the project which is then used to obtain procurement authority
for the required resources. The manager should be aware of the fact that once the definition of the
needs has started, adequate in-house or contractor resources must be available to complete it

       Successful development and implementation of any process requires careful review,
understanding, and documentation of the  need  for information and the functioning of the
information processes in the context of the user organization's mission and operational framework.
It is, therefore, critical that the "mission-based need" be reviewed as the first step toward?
establishing and defining the requirements for the system.

       The use of computer-aided software engineering (CASE) tools, are becoming increasing
prevalent within the Agency. CASE tools can automate and standardize the activities within a
system development effort possibly resulting in a quicker and more accurately built system. If
appropriate, consideration should be given for using CASE tools early in the development life
cycle.

      Project managers should  be aware of the  types of activities involved in software
development efforts and allow for slippage in schedules  due to uncertainties and unknowns.
Planning for these activities and making estimates is a difficult task for any manager that does not
do this full time. Cost and time factors associated with implementing and managing a software
                                       2-1

-------

EPA System Design & Development
Guidance: Volume A
development effort are dependent on such factors as size of the project, levels of complexity and
the skill level, experience and length of time the project team has been together.

       However, it is vital that managers begin making and recording their estimates early in the
project life cycle so they can compare them with actual recorded program costs and hours. It is this
iterative effort of comparing planned versus actual performance that allows the manager to develop
more accurate estimation slrilfa for future planning efforts.
     •
       Information collected during the Mission Needs Analysis:

       •   Specifies the nature of the program mission, problem, functions, processes  and
          information flows

       •   Validates the need for information or information processing in die context of the
          organizational mission

       •   Provides the basis for developing and evaluating an "Initial System Concept" which
          will meet the need.
                                                                                      >

The five  steps required to conduct a complete Mission Needs Analysis and develop  an Initial
System Concept are as follows:

       •   Step 1 - Background review of the evolution of the perceived need, a concise  statement
          of the  problem and  a review of the user's mission, organizational structure  and
          operational processes. The analysis focuses on the positions and functions of those
          individuals who will be the users of the completed system. The result of this review
          should be a preliminary list of potential users of the system.

       •   Step 2  - Identification and specification  of the information flow, transactions  and
          outputs the system must or potentially could produce. The result of this step is the
          development of a concise (perhaps one page) Initial System Concept

       •   Step 3 - Testing and/or evaluation of the system Concept by reviewing the concept and
          preliminary output "designs" with potential users to test their usefulness and identify
          actual or potential constraints.
                                         2.2

-------
 EPA System Design & Development
 Guidance:  Volume A
       *   Step 4 - Final specification and documentation of the results of the previous steps
           through development of a Mission Needs Statement

       •   Step S - Initiation of the Project Management Plan as a preliminary document to
           facilitate the planning and scheduling of resources for the activities that follow the
           Mission Needs Analysis. .

       The actual approach to conducting the Mission Needs Analysis involves conducting the
 first four steps, and requires continual review, revision and recycling of steps as the analysis
 proceeds. The suggested approaches for conducting each of these steps are presented below.

 2.1    STEP 1 - REVIEW OF THE INFORMATION NEED BACKGROUND  AND THE
       MISSION AND ORGANIZATIONAL NEEDS

       The Mission Needs Analysis should begin with a careful review of the organizational and
 operational context from which the need evolved and the specific users which the process or
 systematic solution is intended to assist  The first task is to determine the genesis of the initially
 identified and/or defined need.  Some possibilities include:

       •   A new program or set of mission functions have been mandated by the President,
           Congress or senior officials, requiring the performance of new tasks, processes and/or
           systems

       •  A manager  has decided to perform a new function or an existing function using
          different procedures in support of the Agency's mission, goals and objectives

       •   The Agency has decided to upgrade and modernize  existing hardware and software
          applications to take advantage of new technology.

       •   An existing process or system has been evaluated and is suspected of being inefficient,
          ineffective or obsolete.

       In each of these cases it is important to review the evolution of the information need to
determine which of these possible causes was principally responsible for the system development
effort. Clearly identifying which of these causes is the basis for the system requirement is
important to future development efforts since knowing the reason for the need helps:
                                         2.3

-------
1 FA System  Design  & Development
(iuidunce: Volume  A
       *   Define the problem in concise teims including any quantifiable facts or conditions
          related to the problem.  For example,  "The program office is unable to respond to
          Freedom of Information Act (FOIA) requests for data due partly to a fifty percent
          increase in FOIA requests and a five percent effective reduction in force."

       •   Define the specific set of users and uses

       •   Establish the likely priority accorded the effort  by senior Agency officials and
          responsible staff

       •   Determine whether the problem is really one requiring a system solution or has some
          other underlying cause.

       In conducting this background review, two primary data collection methods may be used:

       •   Interviews with key officials, managers and staff involved or potentially involved in the
         0 processes to be systematized and those who will be the end users of the system results.
          These user interviews should focus  on what specific outputs are required of the process
          and what benefits users anticipate.  Interviews should include State and Regional users
          to fully understand their system, data and access requirements.

       •   Collection and review of key documents such as relevant legislation, agency policies or
          operational plans, organizational mission/function statements or previous studies of the
          function or process.

The results of the data collection  efforts should  be reviewed to provide those conducting the
Mission Needs Analysis with a clear picture of the operational context within which the process
will operate.
       Perhaps the critical output of this initial review is a preliminary identification of users and
potential benefits of process outputs.  A summary format for displaying this information in a
matrix is provided below:
Potential System User/
Organization
Position/
Function
System
Output
User
Benefit
                                          2-4

-------
EPA System  Design & Development
Guidance: Volume A
       It is important that to the extent practical, this type of matrix be completed for all major
users to ensure adequate consideration of user needs and benefits.

2.2    STEP 2 - IDENTIFICATION AND PRELIMINARY SPECIFICATION OF INPUTS.
       PROCESSES AND OUTPUTS AND DEVELOPMENT OF THE "INITIAL SYSTEM
       CONCEPT"

       Conducting Step 1 will result in the identification of the potential users, uses, outputs and
benefits.  During this second task, the "flow" of information and work processes of the potential
system application are developed and documented. The purpose of this step is to develop an
overall understanding and preliminary design for the flow of information and information
products.  At the conclusion of this step,  a brief (perhaps one page) Initial System Concept is
developed. In addition, the documentation of the information flow ultimately provides the basis
for:

       •   Determining the manual processes and procedures which will become a part of the
          ultimate "system solution" for the need or problem (any and all automated processes
          have a set of manual processes and procedures which support the automated portion of
          the "system" and distribute its output)

       •   Identifying and specifying {he procedures and functions which may be automated and
          therefore may become the "automated system" which will be designed.

      The flow of information or work processes that are candidates to be systematized can be
examined through flow diagrams that depict, on a macro level, the:

      •   Organizations and key individuals involved in the information flow and information
          products

      *   The input processes and documents which feed and support the system

      *   The specific output products.

      Exhibit 2-1 illustrates a format for a  sample process flow diagram which can usefully depict
such information. As shown, the diagram contains these important elements:
                                         2-5

-------
EPA System Design & Development

Outdance: Volume A
                          EXHIBIT 2-1

           PROCESS FLOW OF SITE INFORMATION
                                  His
                                  ii!

                                          iS
                             BMO-OZW
                                                fe
                                                •c
                                                e
                             2-6

-------
EPA System  Design  &  Development
Guidance: Volume A
       *  A stub (vertical axis), containing the major organiTatinny.mnyfir individuals involved in
          die process including those involved in:

          -  Input processes
          -  Information process flow                  .
             Process operation  -
          -  Process output and use.      . ••  .

       •  The  flow and interrelationships of  information among  the  various  involved
          organizations including the relationships between Headquarters, States and Regions
          concerning shared data resources.

       •  Specifically identified outputs of the process.

       The creation of a flow diagram similar to, and at the approximate level of detail as, that
shown is highly recommended. It is a systematic methodology for identifying the specific inputs,
information flow and process outputs. This flow diagram can usually be constructed from a
combination of existing documentation and limited interviews with affected organizations and staff.

       Based upon the data flow diagram, a higher level (ideally one page) Initial System Concept
document should be developed as in Exhibit 2-2. The concept should illustrate:  •<

       •  Major process input documents/sources on the left side

       *  A very brief description of key "processes'* and/or data files in the center

       •  Graphic depictions of "outputs" on the right side.

In most cases it should be possible to construct the "Initial System Concept" on  one page.

2.3    STEP 3  - EVALUATION AND TESTING OF THE  INITIAL SYSTEM CONCEPT
       THROUGH USER REVIEW

       Documentation of processes and functions as oudined in Steps 1 and 2 will result in a high
level Initial System Concept depicting inputs, processes and outputs. During this step, the system
                                         2-7

-------
EPA System Design & Development
Guidance: Volume A
                         EXHIBIT 2-2
               INITIAL SYSTEM CONCEPT -
               SITE MANAGEMENT SYSTEM
      o

                IM i it ii i ii ii
                            inimiiiiii
                                    I
       05
       (A
       0)
       O
       O
el
s a
    1
      PJ
      e
           II
*lll
1,
>
1
Mllllllll
Illl11'

II




                           2-8

-------
 EPA  System Design & Development
 Guidance:  Volume A
concept is evaluated in terms of output usefulness, input feasibility and possible constraints.  A
methodology which should be employed for evaluating output usefulness is to review the system
concept as well as "mock-ups" of the outputs (hand copy or screens) with users or potential users.
The "mock-ups" allow potential users to visualize the output of the process with three results:

       *  The user is able to "relate" to the output and indicate the benefit (or lack of benefit) of
          the output                                          .              '

       •  The discussion surrounding the reports can often identify other types of needs or report
          designs which can be incorporated into the Initial System Concept

       •  A preliminary estimate of the benefit to the user or potential user can be made by the
          user.

       During the review of the system concept and outputs with users, an exploration of possible
constraints to the process design should also be conducted. Constraints  and/or implementation
problems may include:

       •  Resistance by managers or staff to changes in operations

       •  Organizational impediments

       •  Input data compilation/collection problems

       •  Lack of hardware accessible to the organizational units

       •   Lack of staff and/or funds to develop and/or operate a system

       •  .Lack of readily available telecommunications equipment/capability for data sharing and
     ,•     access requirements

       *   Information security needs and considerations based on the sensitivity of the system

       •   Limited development time.
                                          2-9

-------
EPA System Design &  Development
Guidance:  Volume A

       Also, during the system concept review, the proposed output reports can be expected to be
partially redesigned in response to suggestions and reactions to individual reports by the users.

       Finally, it is at this point that process options or process designs for achieving similar
outputs can be explored with the user. Although the options analysis is not fully conducted until a
later phase of the system development life cycle (described in Volume B), it is useful to begin
identifying alternatives with the user during this phase.

       Two results should emerge from this step of the Mission Needs Analysis:

       *   A refined Initial System Concept incorporating the results of user evaluations of both
          the concept and proposed outputs

       •   An initial assessment of the needs feasibility, priorities and constraints.

These and the results from the previous stop provide the basis for documenting each section in the
Mission Needs Statement (EEL-1).

2.4    STEP 4 . FINAL SPECIFICATION AND DQCUMENTATTON OF RESULTS IN THE
       MISSION NEEDS STATEMENT

       The next step in conducting the Mission Needs Analysis is the formal documentation of the
work performed in Steps 1 through 3 in a Mission Needs Statement This document need not be
long. An outline for this document is attached in Appendix A.  As shown, primary chapters in the
statement include:

       *   A background section, with a concise statement of the problem. It should also relate
          the problem and its solution to the agency organizational unit's missions and functions.

       »   An Information Flow/Initial System Concept section which contains the Initial System
          Concept and also identifies:

             -  Input data source
             -  Macro information flow and functions
                Outputs including "mock up" format

       *   A discussion of potential system development constraints.

                                        2-10

-------
 EPA  System Design &  Development
 Guidance: Volume A
       The actual length of the Mission Needs Analysis document is dependent on various factors
 such as: complexity of the problem or the organizational functions and mission, the size or scope
 of the Initial System Concept, the impact of any known elements of risk, and the number and effect
            *
 of potential constraints to development and implementation.

 2.5    STEP 5 - INITIATION OF THE PROJECT MANAGEMENT PLAN

       The final step in conducting the Mission Needs Analysis is to initiate a preliminary Project
 Management Plan.  The format of the Project Management Plan is contained in Volume B,
 Preliminary  Design and Options Analysis. It is important to start this planning effort as early as
 possible in order to plan and schedule the resources required for the activities that follow.  This
 preliminary document should include the following:

       *   Steps and tasks associated with Preliminary Design and Options Analysis

       *   Assignment of roles and responsibilities  for the purpose of accountability which is
                                             i
          particularly critical when dealing with programs that cross organizational lines into the
          States and Regions

       *   Resource allocations to accomplish the Preliminary Design and Options Analysis

       •   Project costs and time frames associated with Preliminary Design and Options
          Analysis.

       At this stage of the system development process, there should also be little, if any, thought
given to the  specific hardware or software that is to be used to support the process. Options in
these areas will be considered as part of the options analysis which is discussed in Volume B.
                                        2-11

-------

-------
                                    Chapter Three
                                   SUMMARY
 3.1    MISSION NEEDS ANALYSIS OUTPUTS

       The outputs, documents and results of the Mission Needs Analysis are as follows:

       *  EEI-1, Mission Needs Analysis, is a concise document that describes the problem and
          the neea to perform the process or function in support of the organization's mission.

       •  An "Initial System Concept" indicating the flow of information required to support the
          function, as well as the preliminary input documents and output reports.
                     v
       •  An initial Project Management Plan that outlines the tasks, resources and deliverables of
          the next phase of the project effort

 3.2    NEXT STEPS

       Once the Mission Needs Statement is complete, it should be understood that it will continue
 to evolve and change as the "Initial System Concept" proceeds through the development life cycle.
 Formal endorsement from management of the Mission Needs Analysis and approval to proceed to
 the next step needs to be obtained. Since staff and management may change during the design and
 development phases of the project, it is important to have a record of management approval at key
 decision point

      The next major step is to prepare the Preliminary Design and Option Analysis as described
in detail in Volume B. Both of these tasks are based on information collected during the Mission
Needs Analysis and embodied in the "Initial System Concept"
                                        3-1

-------

-------
                                    Appendix A
              ESSENTIAL ELEMENTS OF INFORMATION
       Tlus appendix provides a representative outline of documents that will be developed during
 the Preliminary Design and Options Analysis phase.

 A.1   INTRODUCTION

       The documentation requirements  contained in  this appendix  apply to all software
 development or modernization projects, regardless of size, complexity or origin. At a minimum,
 these standards apply to all new software development projects. Maintenance and/or enhancements
 to existing information systems must comply with the requirements set out in Chapter 1, section
 1.4 of Volume B, Preliminary Design and Options Analysis.

       Compliance with the standards and conventions provided in this appendix will ensure that
 adequate documentation is produced for all system development projects.

       The documents defined in this appendix are:

       EEI-2 •• Preliminary Design And Options Analysis
       EEI-3 • • Project Management Plan

       When an asterisk appears within a section number in the outlines, it represents a repetition
of the element as many times as necessary to define multiple iterations of the element

       The following milestone chart illustrates  the relative initiation and completion of each
document with respect to the software development life cycle, its major phases, and the span and
scope of Volumes A, B, and C.
                                       A-1

-------
EPA System Design & Development

Guidance: Volume A
          DOCUMENTATION VERSUS LIFE CYCLE
             6*1
            Sj
                                11
                                           I
                   ffi

I -?,!«« 38 ,
   21 a ^  i i  i c iii
  « cBmi—••— Qu~——i
  (0 CgCdU  i« u u u
  U e o U U S3 UUEd
                             00
     IfJ
                                   l
                                   =1
                      I
        C
        O
I   IS
c3 » »   «
c 5 5 .-a 5
g CdU ^ U

i

                               u
                               Q
•4-rf


1
                            A-2

-------
 EPA System Design & Development
 Guidance: Volume  A
                      MISSION NEEDS  STATEMENT


 1.     BACKGROUND

       •     Agency and organizational mission requiring system support

                    Mission/function statement(s)
                    Organizational chart with key functions/users identified
                    Operational environment
                    Current system description, including manual procedures

       •     Evolution of defined need

                    New program or functions

                    Enhancement/modernization of functioning system, or

                    Current performance mode and limitations/problems

2.     INFORMATION FLOW AND INITIAL SYSTEM CONCEPT

       •      Description/documentation of information flow including:

                   Organizational data flow diagrams
                   Key input processes/documents
                   Primary data integration/data base functions and processes
                   Key output report types and distribution

             "Mock-ups" of key output reports and discussion of their benefits to users

       *      Initial System Concept (ideally one page) and related description

3.     DEVELOPMENT/QPERATTONAL CONSTRAINTS

             User commitment, priority, discipline and budgetary limitations
             Policy or organizational constraints
             Information security needs based on system sensitivity
             Timing of need
             Interface needs
             Shared data/access constraints
             Stability/flexibility of need
                                       A-3

-------

-------
         United States       Office of Information
         Environmental Protection Resources Management
         -Agency  	    Washington DC 2O46O  June 1989
&EPA    EPA SYSTEM DESIGN &
       DEVELOPMENT GUIDANCE:
           VOLUME  B:
         PRELIMINARY
          DESIGN  AND
     OPTIONS  ANALYSIS

-------

-------
EPA System  Design  & Development
Guidance: Volume B
                                      Volume B
                           EXECUTIVE  SUMMARY
       This document establishes the criteria that Agency program managers and their staff should
follow to develop a preliminary design and analysis of all the alternative options that satisfy the
"Initial System Concept" developed during the Mission Needs Analysis. The objective of this
document is to provide guidance towards satisfying requirements specified in EPA's IRM Policy
Manual for the acquisition and management of information technology.

       The guidelines within this document are designed to provide program managers and their
staff with guidance and a methodology for developing design options that satisfy the "Initial
System Concept" developed as a result of the processes in Volume A.  This document also
provides guidance for selecting the most cost-effective solution for the defined problem. The steps
described in this volume will result in the selection of the most cost-effective mission based option
(manual or automated) based on life cycle concepts and an initial project management plan that out-
lines how the selected option will be defined, developed and implemented.
*
       Completion of the steps and subsequent analysis outlined in this document will result in a
list of two or more feasible solutions for the problem and related documentation concerning their
descriptions, life cycle benefits and costs, a formal life cycle benefit-cost analysis, and a summary
of the risks and contingencies associated with  each option.  After selecting an alternative, the
project management plan will be updated to reflect how the system development effort will be
accomplished. The revised project management plan will focus on resources, scheduling and ac-
countability as well as other pertinent factors.  The following exhibit describes the complete
software life cycle.  Each phase in the software life cycle is represented by a circle with its
corresponding title on the inside of the circle.  Inputs to the Preliminary Design and Options
Analysis or factors that influence the phase are shown surrounding the circle.  As indicated, in-
fluencing  factors are: agency budget constraints, GSA and OMB requirements,  available
resources, and the preceding phase, the Mission Needs Analysis.

-------
EPA System Design & Development
Guidance: Volume B
            COMPLETE SOFTWARE LIFE CYCLE
                           ii

-------
EPA System Design  & Development
Guidance: Volume  B
                          TABLE OF CONTENTS
                             Tide
1.    INTRODUCTION
Page
 1-1
      1.1    Background	."	1-1
      1.2    Objectives of the System Design and Development
             Guidance	1-3
      1.3    Authority	1-4
      1.4    Applicability  of the  Guidance	1-4
      1.5    Documentation Requirements	1-6
      1.6    Assistance and  Support Available	1-8
2.    PRELIMINARY OPTIONS DESIGN                          2-1

      2.1    Translating Management and Functional Requirements into
             Operational Specifications	....2-1
             2.1.1  Process  Inputs	2-2
             2.1.2  Functions and Processes	2-2
             2.1.3  Process Outputs	...2-2
             2.1.4  General-Process Requirements	2-2
      2.2    Developing Feasible Options	2-3
             2.2.1  Determining the Flexibility and Relative Priority of
                   Each of the Operational Specifications	2-4
             2.2.2  Reviewing the Range of Hardware and Software
                   Potentially Available to Satisfy the Initial System
                   Concept (Management And Functional
                   Requirements) and Operational Specifications	2-4
             2.2.3  Developing Options by Structuring and Adjusting the
                   Operational Specifications and Varying
                   Manual/Automated Functions	2-14
                                       iii

-------
EPA System Design &  Development
Guidance: Volume B
3.    OPTIONS ANALYSIS                                        3-1
       3.1   Operational and Technical Feasibility Analysis	.....3-1
       3.2   Life Cycle Benefit-Cost Analysis	.-.	3-3
                                                                        T»
             3.2.1 Determining and Valuing Benefits	3-3
                   3.2.1.1       Non-recurring Cost-Reduction
                                Benefits	3-4
                   3.2.1.2       Recurring Cost-Reduction Benefits	3-4
                   3.2.1.3       Qualitative Benefits........	3-5
                   3.2.1.4       Determining Total Benefits	3-5
             3.2.2 Determining and Valuing Costs	3-6
                   3.2.2.1       Non-recurring  Costs	3-7
                   3.2.2.2       Recurring Costs	3-8
                   3.2.2.3       Qualitative Costs	3-9
                   3.2.2.4       Determining Total Costs	3-9
             3.2.3 Benefit-Cost Comparison	3-9
                   3.2.3.1       Benefit-Cost Ratio		..3-10
                   3.2.3.2       Payback  Period	;3-10
             3.2.4 OMB Benefit-Cost Approval Criteria	3-10

4.     OPTION SELECTION AND DOCUMENTATION              4-1

       4.1    Option Selection Criteria	.4-1
       4.2    Documentation Requirements .,,	4-2

5.     SUMMARY                                                   5-1

       5.1    Preliminary Design and Options Analysis Outputs	5-1
       5.2    Next Steps	,	C	5-1
                                        iv

-------
EPA System Design &  Development
Guidance: Volume B
Appendix A;

     ESSENTIAL ELEMENTSOF INFORMATION

-------
EPA System  Design & Development
Guidance: Volume' B
                            LIST OF EXHIBITS

1-1   Guidance Audience	1-2
1-2   EPA System Development Life Cycle and Decision Process	1-5
1-3   System Category/EEI Matrix	1-9
2-1   Typical Functional Requirements Analysis Worksheet, Input/Output
      Flexibility of Grants Payment Process	2-5
2-2   Agency-Supported Hardware and Software	2-7
2-3   Software Support Tool Selection Matrix: Small Systems	2-11
2-4   Software Support Tool Selection Matrix: Medium Systems	2-12
2-5   Software Support Tool Selection Matrix: Large Systems...	2-13
3-1   Operational and Technical Feasibility Analysis	3-2
3-2   Sample Summary of Time-Phased Costs and Benefits for Option A	3-11
3-3   Sample Summary of Option Benefits and Costs	3-12
                                       vi

-------
                                     Chapter One
                                INTRODUCTION
       Pursuant to the Environmental Protection Agency's IRM Policy Manual, this volume is. the
 second of three volumes which provide guidance for Agency system design and development
 efforts. This volume provides guidance for the second phase of the EPA system development
 process — The Preliminary Design and Options Analysis.

       Volume B is to be used by Agency Program and Management Officials and responsible
 staff to identify alternative manual and systems solutions to problems identified in the Mission
 Needs Analysis, and to select  the best solution based upon life cycle benefit-cost analysis
 principles. Exhibit 1-1 on the next page identifies the intended audience of this volume.

 1.1    BACKGROUND

       The Environmental Protection Agency expends millions of dollars each year on the design,
 development, implementation and maintenance of major environmental and adminisoative systems
 vital to EPA's programs and administrative functioning.  Management of these resources is
 becoming increasingly complex, since the rapid development of information technology in recent
 years has dramatically increased computer capacity and user accessibility. The result has been two-
 fold:

       •   An increasing number of system development efforts by managers and  staff at all
          organizational levels who, because of access to their own equipment, develop their own
          systems independently of Agency system's staff

       •   A wide range of hardware/software options for implementation of any specific system
          concept or design.

Therefore, there has been a proliferation of system development efforts by a broad range of users
with varying levels of sophistication in making development decisions and conducting
development efforts.
                                        l-l

-------
EPA System Design & Development
Guidance: Volume B
                           EXHIBIT 1-1
                    GUIDANCE AUDIENCE
    SENIOR
   ANALYST
                        PROJECT
                       DIRECTOR
                       PROJECT
                       MANAGER
                        SYSTEM
                       MANAGER
MID-LEVEL
 ANALYST
                           EPA
                       CONTRACTOR
 JUNIOR
ANALYST
                            1-2

-------
 EPA  System  Design  & Development
 Guidance: Volume  B
 1.2    OBJECTIVES OF THE SYSTEM DESIGN AND DEVELOPMENT GUIDANCE

       Within EPA's Office of Administration and Resources Management (OARM), the Office of
 Information Resources Management (OIRM) is responsible for ensuring the effective and efficient
 use of EPA's information resources including automated  system design, development and
 maintenance. OIRM's objective in this endeavor is to provide guidance, assistance, and only when
 necessary, controls, to assure that the Agency's considerable information resources are utilized
 cost-effectively for the overall benefit of the Agency. To this end, OIRM has developed umbrella
 policies guiding information system development and acquisition (see Information Resources
 Management Policy Manual). This three-volume set of guidelines and standards for system design
 and development is a part of OIRM's Software Management Series which is intended to assist EPA
 in efforts to develop and manage software effectively. This series will also include future guidance
 documents related to software management

       This document is the second of the three-volume set.  The volumes cover the following:

             Volume A - Mission Needs Analysis — is designed to provide program managers
       and staff with a suggested methodology for assessing and  evaluating the need
       (requirement) for an information system. Applying the methodology in this volume will
       result in:  1) confirmation that a need (requirement) exists and, 2) provide a preliminary
       operational specification of the requirement

             Volume B  - Preliminary  Design and Options Analysis -- is  directed  towards
       program managers and staff.  It  provides guidance and  a methodology for structuring
       design options for meeting the requirement defined in Volume A and provides guidance for
       selecting the most cost-effective option.

             Volume C - System Design. Development and Implementation is intended for use
       primarily by system developers and provides specific guidance and standards which must
       be adhered to when undertaking automated system design and development efforts.

Together these three volumes provide comprehensive guidance and standards for the orderly and
cost-effective development of automated systems. Exhibit 1-2 depicts the flow of the development
life cycle and decision process for the three volumes.
                                         1-3

-------
EPA System  Design & Development
Guidance: Volume B
       In addition to the System Design and Development Guidance, OIRM is currently drafting
 the EPA Information Security Manual. As security issues are raised and addressed throughout the
 system development life cycle, the security manual should be consulted for proper Agency policy
 and guidance.

 1.3    AUTHORITY

       The EPA System Design and Development Guidance derives its authority from Chapter 4
 of the IRM Policy Manual, entitled "Software Management," which establishes the Agency
 Software Management Program. The guidance serves as the primary guidance for Agency system
 design and development efforts.

 1.4    APPLICABILITY OF THE GUIDANCE

       Senior Agency managers and responsible staff should read the guidance and become
 familiar with the decision-making process involved with system design and development efforts.
 They are responsible for ensuring adequate analysis and documentation to support all critical
 decision points. The full documentation requirements for automated system development efforts,
 which must be followed to conform to OARM policy, are fully discussed in Volume C

       In general, Volumes A and B are intended to assist program offices and/or users in
 conducting their own initial studies of system requirements, needs, option feasibility and cost-
 effectiveness. In this context, the term "system" in Volumes A and B refers to a systematic set of
 processes and/or procedures which can be used to meet the information needs of a  user. It does
 npi imply that the "system" will be an automated system.

       Volume C, however, presumes that an automated or partially automated solution has been
 selected as a result of the Volume B options analysis. Volume C provides guidance and standards
 for automated system development efforts. If the automated system is a relatively small application
on a microcomputer targeted for use within a single office (a "user owned information system"),
 Volume C provides simplified requirements for system design, development and implementation.
If the proposed system is a larger application (mainframe or minicomputer), which is mission-
critical or involves multiple offices and organizations, Volume C provides the full set of guidance
and standards which must be followed by system developers. This will assure uniform, cost-
effective system development in accordance with EPA policies, guidelines and standards.
                                         1-4

-------
EPA System Design & Development
Guidance: Volume B
                          EXHIBIT 1-2
         EPA SYSTEM DEVELOPMENT LIFE CYCLE
                  AND DECISION PROCESS
    DEVELOPMENT STAGE
                                DECISION /RESULT
   c
 Real World
Mission Need
J
    . Volume A.,
                                          REQUIREMENT AND
                                        OPERATIONAL CONCEPT
                                            DEFINITION
        Volumes,
             Preliminary Design 82,
                Options Analysis
                                 OPTION DESIGN, BENEFIT/
                                   COST ANALYSIS. AND
                                   OPTION SELECTION
           , Volume C
                   System Design,
                   Development 6i
                   Implementation
                                  FULLY IMPLEMENTED
                                       SYSTEM
                             1-5

-------
EPA System Design & Development
Guidance: Volume B
 1.5    DOCUMENTATION REQUIREMENTS

       In general, the intent of the three volume System Design and Development Guidance is to
 provide a consistent focus for system development efforts which will allow both EPA program
 managers and OARM managers to cost-effectively develop and maintain the Agency's systems.
 To achieve this goal, certain documentation requirements termed "Essential Elements of
 Information" (EEI) documents, must be met.  Observance of this guidance in preparing EEI's
 should result in proper documentation for audits. The EEI's will also serve as a helpful reference
 for conducting post-evaluations of the system decision making process. Each volume contains an
 appendix which outlines the required EEI documentation.

       For certain system development efforts OIRM and office Senior Information Resources
 Management Officials (SIRMOs) must be involved in a review capacity to fulfill EPA's IRM
 Policy Manual requirements.  Systems falling into one or more of the following categories must
 have OIRM/SIRMO review involvement:

       •  EPA mission critical

       •  States, local governments or other Federal agencies involved

       •  Intel-organizational involvement (e.g., between Assistant Administratorships or
          including Regional Office involvement)

       *  Costs for system development/enhancement are. projected to exceed $250,000
          (excluding costs associated with long-term system operation and maintenance)
                        f
       •  Information security issues involving the three general security areas:  applications
          security, installation security and personnel security.  In total,  information security
          involves the precautions taken to protect the confidentiality, integrity and availability of
          information              '      ,

       *  Privacy Act or confidential business information involved.

       For system development efforts falling into any one of these categories, OIRM and office
SIRMOs must be involved beginning with a review of EEI-1, generated at the conclusion of the
Mission Needs Analysis, as described in this volume of the EPA System Design and Development
                                         1-6

-------
EPA System  Design •& Development
Guidance: Volume B
Guidance. OIRM/SIRMO review involvement will contimfe through the development life cycle of
these systems and will include all EEI documentation requirements for such systems. For systems
not falling into one of the above categories, EEI's may be forwarded to OIRM/SIRMOs for
information and review as they are developed

       A review cycle should be developed to monitor each EEI preparation. The review cycle
could include several stages, such as a series of status briefings for management, focus groups,
and/or distribution of the EEI in draft form.  Throughout the review cycle, the managers and users
involved should be informed of the process and content of the EEL When the final document is
completed, a consensus among management should be reached before developing the next EEL

       It is not OIRM's intent to burden EPA managers with a host of documentation requirements
for each system development effort. The EEIs simply stress typical documentation requirements
and their outlines highlight major topics that need to be considered tor any system development
effort.  Managers may use their professional judgment in substituting, combining, or down-scaling
the content of the EEIs to meet the unique requirements of their project.

       Criteria for determining the minimum EEI documentation for a specific process during the
design, development and implementation phase is based on the nature and scope of the information
process and its importance to EPA's mission.  Three types of categories describing various
systems with differing levels of EEI documentation requirements are identified as follows:

       •   TYPE I: Major Agency /Widely Accessed Information System: An information process
          that requires special attention because of its importance to an Agency mission; its high
          development, operating, or maintenance costs or its significant impact on administration
          of Agency programs or, is widely accessed by a combination of EPA Headquarters,
          Regional Offices, state and local users and/or Federal agencies.

       •   TYPE II:  Localized Information^ystem: An information process that is not a Major
         < Agency Information System but significantly supports accepted program goals and
          missions  and is accessed primarily by users in  one  major area,  e.g.,  EPA
          Headquarters, a single Agency program, or a Region.   .

       •   TYPE III: User Owned Information System: Unique, stand-alone process developed to
          improve the efficiency or effectiveness of operations for a single user or a small group
          of users.

                                        1-7

-------
EPA System Design &  Development
Guidance:  Volume B
       Documentation requirements for each of these categories are projected in Exhibit 1-3.
Automated systems involving information security will be subject to one additional documentation
requirement - completion of a certification form (certification of sensitive systems is an OMB
requirement).  Hie form, which is under development and will be issued as pan of the forthcoming
EPA Information Security Manual, will capture basic information on system sensitivity, security
requirements, security design, reviews, test scenarios, results and safeguards.

1.6    ASSISTANCE AND SUPPORT AVAILABLE

       Agency Program Management officials embarking on a system development effort should
be aware that there are at least two sources available to them for assistance and support during the
system development life cycle:

       •   Within each AA/RA's office SIRMOs are available for assistance, support and guidance
          relative to the EPA System Design and Development Guidance and other OIRM
          guidance and standards

       •   OIRM, with its general IRM management oversight role and requirements to exercise
          procurement approval authority, has a staff organized to support EPA's administrative,
          program and research communities.

It is appropriate to involve these support sources as early as is feasible in the system development
life cycle for most system development efforts.

       The primary reasons for early involvement of SIRMOs and OIRM staff are:

       •   Fulfilling EPA's IRM policy for system development review requirements

       •   Providing a value-added service role involving consultation,  assistance, technical
          standards, guidance and interpretation of requirements

       *   Expediting procurement for system development efforts which proceed to the system
          design, development and implementation phase
                                        1-8

-------

EPA System Design & Development
Guidance: Volume B
                         EXHIBIT 1-3
                    SYSTEM CATEGORY
                       EEI MATRIX
""V^ System
^sss^ Category
EEI ^"x.
Requirements ^s^
EEI-1
Mission Needs
Analysis
EEI-2
Preliminary Design
and Options Analysis
EEI-3
Project
Management Plan
EEI -4
System
Implementation Plan
EEI-5
System Detailed
Requirements Doc.
EEI-6
Software
Management Plan
EEI-7
Software Test and
Acceptance Plan
EEI-8
Software Design
Document
EEI-9
Software Maint.
Document
EEI- 10
Software Operations
Document
EEI- 11
Software User's
Reference Guide
EEI- 12
System Integration
Test Report
Type
•
.' •
•
•
•
•
•
•
•
•
•
•
Type
II
. •
•
•
•
•


•
•
•
•
• •
Type
III
•



•


• -
•
•
•


                            1-9

-------
EPA System  Design  &  Development
Guidance: Volume  B
       •   Providing assistance in determining user needs as early as possible in the life cycle.
 V
Achieving these objectives will strengthen EPA's system development efforts and avoid major
pitfalls that have beset system development efforts in other government agencies (e.g., project
stalls due to outyear funding shortages stemming from under-projected planning or project
disruptions due to failure to get hardware/software acquisitions into  the procurement-cycle
expeditiously and when required).

       The remainder of Volume B provides guidance for conducting the second phase of the
system development process - the Preliminary Design and Options Analysis phase.

                                         1-10

-------
                                     Chapter Two
                    PRELIMINARY  OPTIONS DESIGN
       Completion of the Mission Needs Analysis phase of the system development process will
have resulted in development of an Initial System Concept (operational concept) meeting the
identified management and functional requirements of the organization. The purpose of Volume B
is to translate these requirements into operational specifications, to identify and develop feasible
options meeting the requirements and to analyze the overall feasibility and cost-effectiveness of the
various options. This chapter presents the methodologies for

       •   Translation of the management and functional requirements identified during the
          Mission Needs Analysis into operational specifications

       •   Identifying and developing procedural and process options satisfying the defined
          management and functional requirements and operational specifications.

       It should be noted that requirements refinement and option definition is an iterative process
in that management and functional requirements are first translated into operational specifications.
Options are then developed to satisfy (insofar as possible)  the management requirements and then
the operational specifications are refined. The result of this iterative analytic process is a set of two
to four feasible design options, which to varying degrees may meet the basic defined management
and functional requirements identified in the Mission Needs Analysis.

2.1    TRANSLATING MANAGEMENT AND FUNCTIONAL  REQUIREMENTS  INTO
       OPERATIONAL SPECIFICATIONS

       The Mission Needs Analysis of Volume A broadly defines the system management and
functional requirements and results in development of the macro-level Initial System Concept The
purpose of this stage is to further examine and define the current process environment and user
needs, then to translate these needs into a specific set of operational specifications. The result of
this step  is a set of operational specifications which provide a basis for structuring combined
automated/manual options meeting the management and functional requirements defined in Volume
A. The objective  is to develop the operational specifications only in sufficient detail to allow
defining of options for a proposed system, but not to complete a detailed system requirements
analysis.  The operational specifications form the baseline for what a proposed system must do.
The detailed requirement analysis is conducted in Phase in (only if an auto- mated system solution
is selected) and is discussed in Volume C.                               .
                                        2-1

-------
EPA  System Design and Development
Guidance:  Volume B
       The operational specification process focuses first on defining and providing details about
 specific operational parameters which are required to meet the management requirement These
 include:

 2.1.1  Process Inputs

       •   Origin/type of input (indirect data entry from forms, interface with other automated
           systems, etc.)
                         •>            .   •
       •   Frequency/rate of input (hourly, daily, weekly, monthly, etc.)

       *   Volume of data/text

 2.1.2  Functions and Processes

       •   Process and flow of each input into the "system"
       *   Data pnxessing/manipulation/tabulation functions
       •   Types and sizes of major data files
       *   Update/purging requirements
                               \
       •   Statistical or scientific analysis requirements
       *   Shared or accessed data requirements
       •   Special functions such as project management/critical path, etc.

2.1.3  Process Outputs

       •   Hard copy report formats
       •   Screen display
       •   Special presentations/graphics
       •   Frequency (daily, weekly, monthly, on demand) and ongoing output rate
       •   Other process interfaces                             •       ,
       •   View locally and/or transmit to remote locations

2.1.4  General PjPfiess Jteguirements
                                    '       -                                    c
       *   Required user interface
       *   Information security requirements, including:
          -   Accuracy and validity requirements
          -   Criticality of key outputs
                                          2-2

-------
EPA System Design and  Development
Guidance:  Volume B
          -  Failure contingency
          -  Access controls
          -  Response time
          -  Flexibility
          -  Failure contingency

       In general,  these  specific operational  specifications  involve an elaboration and
quantification of the Initial System Concept developed during the Mission Needs Analysis.  All
operational specifications should be designed to meet the management and functional requirements
identified in the Mission Needs Analysis. Concentration at this point of the study should be on
creating a detailed picture of the way in which inputs/processes/outputs are generated and used.
Particular attention must be paid to the operational requirements  of systems which involve data
sharing with States and Regions.  Detailed formats and information' field structuring will be
established in the System Design stage described in Volume C.
2.2
        EVELOPING
       Hie operational specifications defined above provide the foundation for structuring two to
four feasible options which largely (but probably not exactly) meet the management and functional
requirements. In general, there are almost always a number of potential options for meeting the
management and functional requirements varying from manual processes through sophisticated
automated system designs. It is generally true that, if only one way to solve a problem is apparent,
the management problem has not been adequately defined and analyzed. Options should include
feasible approaches to solving the management problem and should not be limited to alternatives
involving automation (see FIRMR 201-30.009,  "Analysis of Alternatives for  Satisfying a
Requirement")

       Structuring and developing possible options to satisfy the mission need (management
requirement) and operational specifications is a process which involves several activities performed
simultaneously and iteratively.  They include:

       •  Determining the flexibility and relative priority of each of the operational specifications

       •  Reviewing the range of available hardware and software options available to meet the
          specifications
                                         2-3

-------
EPA System  Design  and Development
Guidance:  Volume B
       *  Constructing alternatives by structuring/adjusting the operational specifications and
          related procedures to meet available hardware and software options

       •  Option refinement through balancing overall  management requirements with
          development costs and timing considerations.

       These four steps are pursued iteratively to first structure and then specify in some detail the
selected options.

2.2.1  Determining the Flexibility and Relative Priority of Each of the Operational Specifications
                                              /
       At this stage, the operational specifications identified earlier are treated as somewhat
flexible and not a rigid set of specifications that every systematic solution must meet Instead, the
management and functional requirements  should be considered as  the overall goal but
determinations must be made regarding  the relative priority of various requirements and
specifications. To assist the system developer with this process, a flexibility/ priority analysis of
each of the requirements and specifications should be performed in order to define the ranges of
associated parameters.  This analysis represents just another step in the iterative process of
structuring avaifablepptions. The flexibility/priority analysis is conducted based upon the overall
management and functional requirements and the operational specifications defined in Section 2.1.
Exhibit 2-1 provides an example of an analysis of the flexibility of inputs/outputs for a grants
payment process. The analysis provides a "flexibility assessment" on key components of the
requirements and. operational specifications developed earlier. Conducting this analysis provides
the system developers with a sense of the way in which the requirements and specifications must
be satisfied including which things are mandatory, and which are desirable.  The results of this
"feel" of relative priorities is used both for the development of options and for the options selection
process.

2.2.2  Reviewing the Range of Hardware and Software Potentially Available to Satisfy the Initial
       System Concept (Management And Functional Requirements^ and Operational  .
       Specifications

       During this step of the development process, a preliminary review of the hardware and
software potentially available for the application should be conducted. The past several years have
seen a major expansion in the range of hardware and software available to potential users. Thus,
this step of the development process  has  become more critical as the  range of options has
                                         2-4

-------
EPA System Design and Development
Guidance:  Volume B
3.



4.

5.
                                EXHIBIT2-1
       TYPICAL FUNCTIONAL REQUIREMENTS  ANALYSIS
   WORKSHEET, INPUT/OUTPUT FLEXIBILITY OF GRANTS
                         PAYMENT PROCESS
      COMPONENT
      Grant authorization form
      Invoice
                                        COMMENTSONPLEXIBILITY
                                  INPUT.
      Ledger
      Check Printing
      Funding check for each
      program operation


      Updated ledger
Management Report A



Management Report B

Queries via on-line
      1.    Form must have entries in all
            blocks conforming to pie-
            defined ranges with 100% edit
            check.

      2.    Must have date, amount,
            grantee name, address, and
            grant authorization number and
            must be 100% edited and
            verified.

PROCESS/FUNCTION

      1.    Must be accurate, be backed
            up, and all incoming
            transactions must have been
            100% edited and verified

      2.    Must be accurate, be backed
            up, provide for safeguards and
            anti-counterfeit procedures,
            and allow 100% edit and
            verification.

     OUTPUT

      1.    Checks issued must be 100%
            accurate and delivered to
          .  grantees by 15th of each month

      2.     Must be 100% accurate and be  •
            completed by 13th of month so
            that checks can be run by 15th

      3.     User would like by 15th but
            indicates not a big problem if
            slips as late as 25th of month

      4.     Nice to have but not essential

      5.     Nice to have but on-line not access
            essential
                                   2-5

-------
EPA System Design  and Development
Guidance:  Volume B
increased.  In conducting this review it is strongly urged that EPA's Office of Information
Resources Management and/or die Senior Information Resource Management Officer (SIRMO) for
the program area be contacted for assistance.

      Exhibit 2-2 briefly summarizes the range of hardware and software currently supported by
the Agency. This list provides an initial basis for determining available options within the Agency
environment The exhibit provides a representative sample of available MS-DOS and Macintosh
application software.  The Macintosh computer is included as a potential option for development of
Localized (Type n) or User Owned (Type HI) information systems. In addition to reviewing the
available environments, the system developer, in conjunction with OIRM or SIRMO staff, might
want to review and consider other kinds of specialized hardware/software for a particular system.

      In reviewing the available hardware/software, the developer should consider such factors
as the following:

      •  What specific hardware is available or can be made available in physical proximity to
         the user(s)? What is its accessibility?

    ^ *  What similar software or data bases already exist, either within EPA or elsewhere,
         which perform similar functions or contain similar data?  For example, EPA's
         personnel and payroll systems already contain much personnel data, and the Agency's
         Integrated Financial Management  System (IFMS) contains comprehensive (and
         accessible)  financial files. OIRM'S Information Systems  Inventory (ISI) which
         contains basic information on over 500 EPA systems, data bases and models should be
         consulted to identify existing systems.

      •  Is the application/system concept one for which software has already been developed
         and is available either within EPA or through service bureaus?  For example,
         LEXIS/NEXIS, a commercially available software package, provides a means for
         storage and retrieval of abstracted data bases.

      •  Has EPA already developed applications which can be readily modified?

-------
EPA System Design and Development
Guidance:  Volume B
                       EXHIBIT 2-2
    AGENCY-SUPPORTED HARDWARE AND SOFTWARE
-
TOOLS
3rd Generation:
COBOL
FORTRAN
PL/1
PASCAL
Atll fi^TKM Hi Illll"

INFO
FOCUS
NATURAL
SAS
, DBASE III PLUS
EASVTR1EVE PLUS
TARGET HARDWARE ENVIRONMENT
IBM
3090

•
•
•



•
•
•

•
IBM
43XX
DEC/
VAX


•




•





- •
•
•

•
•

•
•

PRIME

•
' •

•
MS
DOS


•

•
Mac-
intosh





LAN






•


•
•

•
•

•
•








• '


•

Data Base Management:
ADABAS
Graphics Faculties?

TELL-A-GRAPH/Cuechart
VERSAGRAPH
SASGRAPH
CRICKET DRAW
CRICKET GRAPH
MACDRAW
MACPAINT
Spreadsheet:
LOTUS 1-2-3
20/20
SUPERCALC
SAS/FSP
EXCEL
•

•

•







•
•




















•








•



•
•







•

•











•


•






•
•
•
•





•










•

•


                          2-7

-------
EPA System Design and Development
Guidance:  Volume B
                       EXHIBIT 2-2
    AGENCY-SUPPORTED HARDWARE AND SOFTWARE
                     (CONTINUED)

TOOLS
(igotfmpTite Information Systems*

ARC/INFO
UNIHAS (Pilot)
Word and Text Software:
LEXHYPE
WORDSTAR
MULTIMATE
WORDPERFECT
WORDMARC
BASIS
TEXTWP
INFO-TEXT
MACWRITE
MICROSOFT WORD
 ftTanatf*Tn»Ti+*

TELL-A-PLAN
MICROSOFT PROJECT
TIMELINE
-TARGET HARDWARE ENVIRONMENT
IBM
3090


•






•





•


TVeconi Capabilities:
SNA(3270/RJE)
ASYNCH ASCII
X.25
PRIMENET
DECNET
CROSSTALK
KERMIT
GNETII
•
•
•



•

IBM
43XX
DEC/
VAX
PRIME


















•





•










•






•

•
•


MS
DOS




•
' •
•
•





•





•
•••




•

•
•
•

•

•

•
•
•
•


•
. •

•
•

•
•


• .
•
•

Mac-
intosh







•




•
•
LAN




•
•
•
..•





•





•
•
•



•





•
•
•
•




                         2-8

-------
EPA System Design and Development
Quittance:  Volume B
                      EXHrom-2
    AGENCY-SUPPORTED HARDWARE AND SOFTWARE
                    (CONTINUED)

TOOLS
Telecom Capabilities (Cent.):
PRIMELINK
NATURAL/CONNECTION
SAS/RLINK RTERM
3270 PC FILE TRANSFER (INDSFILE)
ARBITER
BULK DATA TRANSFER (BDT)
DATA TRANSFER FACILITY (DTP)
NOVELL NETWARE
Electronic Mail:
DIALCOM SERVICE
LOCAL CAPABILITIES
TARGET HARDWARE ENVIRONMENT
IBM
3090










•

IBM
43XX




•
•
•


DEC/
VAX







•




•
•
PRIME

• *







' •
•
•
MS
DOS

•
•
•
•
•




•

Mac-
intosh










' •

LAN








~ •



Programmer Productivity Aids/Facilities:
ISPF
LIBRARIAN
EMACS
COBOL DEBUGGER
FORTRAN DEBUGGER
EVE/TPU
VAXSET * •
DeskTop Publishing:

PAGEMAKER
. VENTURA PUBLISHER
•
•

•
•





•



• '






•
•
•







•













.
•
•








•











                         2-9

-------
EPA System Design and Development
Guidance:   Volume B
       •   How complex are the basic functions which must or could be performed by the
          automated system, and  what software  exists to perform these functions (e.g.,
          numerous project management software packages exist which include critical path
          analysis, as do statistical packages to perform regression analysis, etc.)?

       •   What is the desirable form of the output (hard copy tables, text, .graphs and charts,
          screen display, color graphics etc.), and what hardware/software is available or can be
          procured to produce this output?

       •   How long will the hardware/software be available within EPA and when will it be
          replaced?                                            '        •  '.

       *   What security arrangements are available for given hardware or software, and are they
          adequate for the application?

       •   What telecommunications capabilities are required and available to meet system data
          sharing needs?

The review of available hardware/software needs to include examination of all of these areas.

       Beyond the availability of specific hardware and software applications, option designers
should examine the .potential hardware and software based upon defined size and flexibility
requirements identified in the  management and functional requirements  and operational
specifications analyses.  Exhibits 2-3,2-4 and 2-5, following this page, present guidelines for the
type of software required for an application of a given size and complexity.  Small, medium and
large systems are defined by the number of records processed or total storage requirement

       The decision matrices can be used to help determine the support tools appropriate to system
development in the absence of OIRM staff guidance. The matrices apply only to the general
systems which store and retrieve information and should not be construed as taking precedence
over existing EPA system plans, strategies and policies.  Also they do not encompass statistical
systems, spread sheet systems, graphics systems and other specialized functional systems. With
minor exceptions, they do not address hybrid systems - those which are developed using two or
more support tools (e.g., Natural/VSAM for. data entry and Natural/ADABAS for data retrieval).
                                        2-10

-------
EPA System Design  and Development
Guidance:  Volume B
                             EXHIBIT 2-3
       SOFTWARE SUPPORT TOOL SELECTION MATRIX
                         SMALL SYSTEMS
SMALL SYSTEMS -f RECORDS < 10K OB
Number of Stmultaj

neous Users
Complex Random Retrievals?
Location
of Related
Data
None
Main-
Frame
Mini-
Computer
PC
1
YES
2.3,6.7
2.3
6
7.8.9
NO
2.3.4.6.7
2.3.4
6
7.8.9
. TOTAL SIZE < 10 ]

l15 I
YES
2
2
2
2
NO
1
2.3.4 1
2.3,4 1
2.3,4 . 1
2.3.4 1
     Notes:

     1 -Mainframe
     2-Mainframe
     3 - Mainframe
     4-Mainframe

     5 - Minicomputer
     6 - Minicomputer

     7 - Microcomputer
     8 - Microcomputer
     9 - Microcomputer
3GL/DBMS    (COBOL, PL/I, FORTRAN)
4GL/DBMS    (Namrai/ADABAS)
4GL        (FOCUS)
4GL        (NATURAL/VSAM)

3GL        (COBOL, FORTRAN, Pascal)
4GL        (FOCUS. INFO)

4GL        (INFO. FOCUS, dBASE ID)
4GL/DBMS    (dBASE HI)
3GL        (FORTRAN, Pascal)
                                 2-11

-------
EPA System Design and Development
Guidance: Volume B
                             EXHIBIT 2-4
       SOFTWARE SUPPORT TOOL SELECTION MATRIX
                       MEDIUM SYSTEMS
MEDIUM SYSTEMS - 10K <# RECORDS < 100K OR
10 MEGABYTES < TOTAL SIZE < 100 MEGABYTES
Volatility
Number of
Simultaneous Users
Complex Random
Retrievals?
Location
of Related
Data
None
Mini-
Computer
Main-
Frame
Moderate Amount
of Change per Day
S 15
YES
2.3.6
6
2.3
^^^^^^^^^^^^•^^^^^^^^^^^S^^^^lf^^^^'^^'
NO
2.3.
4.6
6
2.3.4
> 15
YES
2
2
2

NO
2.4
2.4
2.4
Volatile
£ IS
YES
2.6
5.6
2
NO
2.3.
4.6
5.6
2.3.4

> 15
YES
2.3
2.3
2.3
NO
2.4
2.4
2.4
^Hswsss&S S^S&SSSSi&i?!
Highly
Volatile
£ 15
YES
1.2.
5.6
5.6
1.2
NO
1.2,
5.6
5.6
1.2

> 15
YES
1.2.
5.6
1.2
1.2
NO
1.2
1.2
1.2

     Notes:

     1 -Mainframe
     2-Mainframe
     3-Mainframe
     4-Mainframe

     5 - Minicomputer
     6 • Minicomputer
3GL/DBMS   (COBOL, PL/I, FORTRAN)
4GL/DBMS   (Natural/ADABAS)
4GL       (FOCUS)
4GL       (NATURAL/VSAM)

3GL       (COBOL, FORTRAN, Pascal)
4GL       (FOCUS. INFO)
                                2-12

-------
EPA System Design and Development
Guidance:  Volume B
                           EXHIBIT 2-5
      SOFTWARE SUPPORT TOOL SELECTION MATRIX
                       LARGE SYSTEMS
LARGE SYSTEMS-* RECORDS > 1OOK OR TOTAL SIZE > IOO MEGABYTES \
Volatility
Number of
Simultaneous Users
Complex Random
Retrievals?
File
Pass
Frequency
n» 1
per day
1 < n < 4O
per day
n>40
per day
Almost Static
(Update Weekly or Less)
S 15
YES
2.3
2
Hybrid
1.2
NO
2.3.4
2.4
4
> IS
YES
2
2
Hybrid
1.2
NO
2.4
2.4
4
Moderate Amount of
Change or Volatile
£ 15
YES
2
2
Hybrid
1.2
> 15
NO
2,4
2,4
4
Highly 1
Volatile 1
1
S. 15
YES
1.2
1.2
Hybrid
1.2
1
> 15 1
NO |
1.2 ' I
1,2
Hybrid
1.2
f
»
                                 Als^y^^tt^feiM
Notes:

1 - Mainframe
2 -Mainframe
3-Mainframe
4-Mainframe
                   3GL/DBMS   (COBOL, PL/I, FORTRAN)
                   4GL/DBMS   (Natural/ADABAS)
                   4GL       (FOCUS)
                   4GL       (NATURAL/VSAM)
                              2-13

-------
EPA System 'Design and Development
Guidance:  Volume B
      The Software Support Tool Selection Matrices address systems that are small, medium,
and large.
                                                       -\
             Small Systems - are generally programmed using 4GLs with or without data base

             support, and they can run in either the mainframe, minicomputer or microcomputer

             environments;
                                             *

             Medium Systems - are generally programmed using either 3GLs or 4GLs with or

             without data base support, and  they  can  run  in  either the mainframe or

             minicomputer environments and;


             Large Systems - are generally programmed using either 3GLs or 4GLs with or

             without data base support, and they run in the mainframe environment.
      The content of each matrix cell and the criteria of small, medium and large systems are
simplified to make them useful. There are several decision criteria along the legs of the matrices
and numbers in the intersections of the rows and columns which correspond to the software
support tools. The key for the software support tools is:
       1 -Mainframe
       2-Mainframe
       3-Mainframe
       4-Mainframe

       5 - Minicomputer
       6 - Minicomputer

       7 - Microcomputer
       8 - Microcomputer
       9 - Microcomputer
3GUDBMS   (COBOL, PL/I, FORTRAN)
4GL/DBMS   (Natural/ADABAS)
4GL         (FOCUS)
4GL         (NATURAL/VSAM)

3GL         (COBOL, FORTRAN, Pascal)
4GL         (FOCUS, INFO)

4GL         (INFO, FOCUS, dBASE HI)
4GL/DBMS   (dBASE HI)
3GL         (FORTRAN, Pascal)
      Based upon the above reviews, the option designer should have a relatively good feel for

the potentially feasible hardware and software options available to meet some or all of the

management, functional and operational specifications.

2.2.3  Developing Options by Structuring a^d Adjusting the Operational Specifications and
      Varying Manual/Automated Functions

      In this step the analyses conducted to date are used to construct manual/automated options.
                                      2*14

-------
 EPA System Design and Development
 Guidance:   Volume B
       In constructing these options, a number of factors must be considered simultaneously.
 Some of these factors include the following:

       •   Specific functions which are candidates for automation.  All automated processes have
           a manual component, and the only question is what portion of the process or function
           will be automated and what will be left as manual processing.  Often the feasible
           alternatives differ in the proportions of the processes and functions that are to be
           automated.                    ;

       •   The amount of effort fand hence cost) of automating certain functions. For example,
           full text automation involving voluminous files is usually not a desirable option because
           of the almost prohibitive effort and cost associated with inputting large amounts of data
           or text.

       •   User sophistication and discipline. Automated processes, but particularly sophisticated
           processes, require considerable effort and discipline to maintain accurate data. If these
           are not present in the user organization, than a manual or simple process is more highly
           preferred to a more sophisticated design, and thus the options should include at least
           one sophisticated option.

       •   Timing of the management requirement.  If a process must be in place quickly, a
           manual or less sophisticated design will probably be required.

       •   Availability of the appropriate hardware/software at the rime of implementation.
          Procurement of new hardware or software may take prohibitively long, and/or existing
           hardware or software may be replaced while the system is being designed.
                                           *
       Based upon  these and other considerations, a set of options for performing the defined
functions should be structured. In general, these options should range from manual processes or
procedures, through  the most highly automated alternative which is potentially feasible.

       In displaying the options, it is highly desirable - in fact virtually mandatory - that all the
manual and automated functions associated with the option be defined and displayed. In fact these
manual/automated differences along with the hardware/software differences are the primary factors
which differentiate the options and which  will form the basis for the benefit-cost analysis and
subsequent option selection.

                                          2-15

-------
EPA System  Design  and Development
Guidance:  Volume B '
       A recommended analytical technique for defining and specifying the manual/automated
alternatives and differences by alternative, is to rely upon the flow diagrams and the Initial System
Concept developed during the Mission Needs Analysis. Beginning with these flow diagrams (see
Exhibits 2-1 and 2-2 of Volume A), updated system concepts can be constructed for each
alternative identifying:                      -                               •

       *  The specific manual functions which must be performed
       •  The specific system functions which must be performed
       •  Changes from the current mode of operation.

This clear specification  of which functions  are to be performed manually and which are to be
automated is critical to the development of benefit and cost estimates for each option.

       As a final step of this analysis, the defined options should be reviewed with the users to
determine their acceptability. This review should include a discussion  of the advantages/
disadvantages as well as the operational implications (additional staff, new procedures, information
security factors, etc.) of each option. The result of this last review with the users is a potential set
of options which appear to satisfy to an acceptable degree the management requirements and
mission need.
                                         2-16

-------
                                     Chapter Three
                             OPTIONS ANALYSIS
       Selecting an appropriate solution to satisfy the mission need and operational specifications
involves evaluating identified options against the identified requirements to determine which
alternative most cost-effectively satisfies the requirements. Thus, two analyses must be conducted:

       *  Operational and technical feasibility analysis
       *  Life cycle benefit-cost analysis.

Guidance for performing these analyses is provided below.

3.1    OPERATIONAL AND TECHNICAL FEASIBILITY ANALYSIS

       For an option to be viable it should be technically, operationally, and economically feasible.
The purpose of the operational and technical feasibility analysis is not only to evaluate how well
each option meets the requirements identified to date but also to determine how operationally and
technically feasible each option is. The primary result of this task is a ranking of the various
options in accordance with their capacity to meet the requirements.

       Completion of a matrix such as the one shown in Exhibit 3-1 should indicate the extent to
which each option is operationally and technically feasible. The matrix can be used, if desired, as a
means  of ranking options by desirability. The matrix provides a formal means of scoring options
based on relative weights assigned to each requirement. First, each requirement is assigned a
weight based on its relative importance.  Each option is then evaluated against the requirement and
assigned a rating. Weighted scores for each option are calculated and totaled giving the relative
desirability of each option.

       A more informal evaluation process can also be used. This may involve a joint review of
the requirements by management, users and developers, to rank each option by desirability.

       The results of this analysis will indicate the relative desirability and effectiveness of each
option.  Before a final determination of an option can be made, however, a life cycle benefit-cost
analysis must be conducted.
                                         3-1

-------
EPA System Design & Development
Guidance: Volume B
                         EXHIBIT 3-1
  OPERATIONAL AND TECHNICAL FEASIBILITY ANALYSIS

OPERATIONAL/TECHNICAL AREA

1. Capability Of Producing Key
Products (Meet Management
Requirement)
• "A"
• "B"
. "C"
2. Developmental Time Compared
To Need
3. Flexibility/Expandability
4. Acceptability To Management
And Users
5. Extensivenesa Of Management/
Operational Changes Required (If Any)
a Resource Availability
(Staff And Dollars)
7. Management Commitment
a Risks Of Development/
Implementation (Security. Etc.)
» Management Risks
* System Hardware/Software Risks
• Security Risks
9. 'Availability /Accessibility Of
Hardware And Software
10. Automated System Characteristics
• Capability to Interface with
Other Systems
• User-friendly Interface
• Failure and Backup Provisions
• Hardware/Software Obsolescence
» Site/Physical Plant Requirements

I
i

*,











TOTAL


OPTION!
Weighted
Rating Score
-













OPTION 11
Weighted
Rating Score












-

OPTION III
Weighted
Rating Score














                           3-2

-------
EPA System  Design  & Development
Guidance: Volume  B

3.2    LIFE CYCLE BENEFIT-COST ANALYSIS

       To ensure that the most cost-effective option is selected, the benefits and costs of each
option over the anticipated life of the process must be carefully reviewed. The benefit-cost analysis
is a methodology for conducting this analysis. The objective of the analysis is to identify and
compare the benefits and costs of feasible options to provide a sound basis for selecting the
preferred alternative.

       The benefit-cost methodology consists of three tasks:

       *   Determining and valuing benefits
       •   Determining and valuing costs
       •   Comparing total benefits and costs.

The result of the benefit-cost analysis is the determination of the most cost-effective option.
Detailed guidelines for completing the benefit-cost analysis are presented below.

3.2.1   Determining and Valuing Benefits

       The purpose of this task is to identify and value  the potential benefits of each selected
option. Benefits usually are expressed in terms of the  mission, goals or operating program
accomplishments over the expected operational life-span. These benefits must be identified for
each year of operation.  In general, benefits are those accruing when compared to the current
situation; benefits that are expected to accrue under the current process are not included in the
analysis.

       Generally, there are three types of potential benefits from automated systems:

       •   Cost reduction benefits which are a direct result of an automated process being more
          efficient than a manual process. In general these benefits accrue only when a system is
          an operational system producing a product, such as payment checks, mailing lists, etc.
          The methodology for valuing these benefits is a relatively straightforward efficiency
          analysis.

       *   Additional capability benefits such as conducting statistical (regression) analyses which
          cannot be done manually because of the immense number of calculations required. It is
          often difficult to quantify these benefits.

                                         3-3

-------
 EPA  System  Design  & Development
 Guidance: Volnme  B
       *  Management effectiveness benefits which result from improved management due to
          improved information from management information systems such as improvements
          related to the state access to information which provides better information for state
          environmental managers. In general, it is impossible to directly measure these benefits
          quantitatively since they stem from the presumed actions of managers who will make
          better and more informed decisions. The approximate magnitude of these benefits may,
          however, be inferred by estimating the total cost of the organization being managed
          and presuming a small increase (2%-10%) in organizational effectiveness or efficiency.
          For example, if a 1,000 person organization is expending $50 million/year, then a 2%
          increase in management effectiveness translates into ah inferred benefit of $1 million
          (.02 x $50 million).

       Every reasonable effort should be made to identify and quantify benefits in units and
dollars with supporting rationale. When benefits cannot be quantified in dollars, they should be
expressed in measurable units. Non-quantifiable benefits may be identified if pertinent to the
decision. The discussion below presents categories of benefits which may result from a project.
3.2.1.1
Non-recurring Cost-Reduction Benefits
       These are one-time benefits that have a dollar value. The benefits may occur at any point in
the life cycle, but they are not continuing benefits.

       1)    Cost reduction - The value of eliminating owned equipment, excess equipment and
            inventory, or any other one-time source of quantifiable benefit.

       2)    Value enhancement - The value of additional tangible procurements (depreciable, not
            consumable) and improvements to owned facilities and equipment.
3.2.1.2
Recurring Cost-Reduction Benefits
      This includes benefits accrued throughout, or during most of, the system life cycle. These
cost-reduction benefits should be quantifiable and may include such categories as:

      1)   Maintenance and Lease of ADP Equipment - The savings for ongoing lease and/or
           maintenance contracts for ADP equipment
                                         3-4

-------
 EPA System Design  & Development
 Guidance:  Volume B
       2)    Communications - The savings on rental, lease or maintenance of data communication
             equipment, services, and facilities.

       3)    Software Maintenance-- The projected savings on the maintenance of application
             software.                                 ,          .

       4)    Personnej - The salaries and fringe benefits saved (net savings) for operations, data
             entry, and other personnel.

       5)    Training and Travel - Savings due to reduced training and travel.

       6)    Space Occupancy - Savings on equipment space, personnel and support facilities, and
             administrative offices.

       7)    Supplies and Utilities - Reduction of both technical and administrative supplies.

       8)    Security - Savings on security guards, devices, etc.

3.2.1.3       Qualitative Benefits

       Many important benefits can result without being able to easily quantify them. Examples
include:    *

       •  Faster processing and/or lower error rate
       *  Enhanced organizational image
       •  Improved morale             .
       *. Standardization                                                         '

It may not be possible to precisely quantify these benefits in dollar terms, but they nevertheless
should be examined and retained as part of the analysis.

3.2.1.4  .     Determining Total Benefits    .      .     .

       Total benefits are determined by summing annual tangible  benefits over the life of the
process and adding non-recurring benefits. To determine present value benefits, adjust the benefits
over the system life cycle to their present value. The net present value is calculated by subtracting
                                          3-5

-------
EPA System  Design  &  Development
Guidance: Volume B
the adjusted cost from the total present value of benefits. FIPS PUB 64 and OMB Circular A-94
provide guidance for calculating the present value of benefits.

3.2.2  Determining and Valuing Costs
                              ;
       The purpose of this task is to determine for each option all costs and required resources,
e.g., personnel, equipment, etc. Costs must be analyzed for each alternative over its life cycle.

       The system life cycle includes both the research and developmental, in addition to the
operational and maintenance phases.  For example, the costs for conducting the  system
development process discussed in Volume C must be included in the life cycle costs. The end of
the life cycle is the projected final year in the useful life of the process, or the last year in which
either costs or benefits are incurred.

       Only relevant costs must be addressed in the economic analysis.  A cost is relevant if the
implementation of an alternative would cause currently occurring costs to change. For example,
site costs are relevant if die current facilities must be modified or expanded to accommodate the
process. Costs which are  not impacted by any alternative are the  same for all alternatives and,
therefore, they are irrelevant to the economic analysis.

       Sunk costs  are riot relevant to the economic analysis.  Sunk costs are costs which have
already been incurred or are irrevocable due to a prior commitment. Sunk costs are irrelevant to the
economic analysis because they will be incurred at the same level regardless of the outcome of the
analysis.

       Relevant non-informational system costs must be included in the analysis. For example, if
workload increases would require future increases to non-information system staff to perform a
program mission, goal or operating function, the additional costs must be shown as increased costs
of the present process.                        .

       Cost estimates must be supported by a reasonably accurate projection of workload and
capacity requirements. Specific workload data and associated capacity requirements for each year
in the process life must be provided.

       The effects of inflation, or anticipated changes in the general price level, are not required in
the  analysis of costs. If inflation is used in the analysis, the resulting costs must be presented in
both present (constant) and future (discounted) dollars.
                                          3-6

-------
EPA System  Design  & Development
Guidance: Volume B
       Although inflation, or an unanticipated increase in the general price level, is not required for
the analysis, a known or expected price increase in a specific cost item should be included when
the magnitude of the price change may affect the decision (for example: an increase in personnel
costs projected due to a planned general Federal pay raise).  Note that costs for all years of the
process life must be presented in both present and future dollars.

       Developmental (non-recurring) and operational (recurring) costs must be separately identi-
fied. Developmental costs are one-time costs to acquire hardware, software, telecommunications,
facilities, capitalized equipment, training and travel. Operational costs may be incurred over the life
of the process and include maintenance, facilities, non-capitalized equipment, supplies, training
and travel. Specific types of costs which should be considered in the analysis are identified below.
3.2.2.1
Non-recurring Costs
       Non-recurring costs are costs associated with the acquisition of equipment, real property,
non-recurring services, non-recurring operations and maintenance (start-up) costs, and other one-
time costs. Non-recurring costs need not all occur in a single year. They include costs for

       1)   Site Modifications - The cost of erecting or modifying a site and surrounding facilities
           to meet the needs of the proposed process, e.g., costs to enlarge a computer room
           and additional space required for personnel involved in this process, etc.

       2)   Equipment - The cost for hardware, e.g., CPUs, disk drives, security devices, filing
           cabinets, microfilming equipment, etc.

       3)   Data Communications - The cost for data communications hardware, communication
           lines and dedicated data communications software.

       4)   Software Purchase - The cost for system software packages procured for the direct
           support of the proposed system.

       5)   Database Development - The cost of implementing database system software and
           database applications software.

       6)   Software Development - The cost of implementing application programs.
                                         3-7

-------
EPA System Design & Development
Guidance: Volume B
       7)   Studies - The cost of studies associated with the requirements, design development,
            or implementation of the proposed process, unless already incurred at the time of
            options analysis.

       8)   Data Conversion - The cost of converting present data and program logic.

       9)   Procurement - The cost of procuring hardware, software and data communications
            such as REP preparation, vendor evaluation, and contract preparation.

       10)  Training - The cost of training, including user, operations, and management training.

       11)  System Test - The cost of evaluating the process, including tests of information
            security safeguards, and quality assurance/quality control measures.

       12)  Management Overhead - The cost of management interface in the development
            process defined in terms of hours required for meetings, reviews and administrative
            functions associated with continued process operation, etc.

3.2.2.2      Recurring Costs

       Recurring (operations) costs are expenses of operating the process on an annual basis that
continue throughout the process life. They include costs for

       1)   Personnel -. The salaries and fringe benefits for operations,  data entry, and other
            personnel assigned  to  the process.   Pan-time  activities  should be  prorated
            accordingly.

       2)   Maintenance and Lease  of Equipment - The cost for lease and/or maintenance
            contracts for equipment

       3)   Space Occupancy -  The cost  of equipment space, personnel and administrative
            offices.

       4)   Supplies and Utilities - The cost of both technical and administrative supplies.

       5\   Timesharing - The cost of buying computer  time from EPA, other government
            agencies or a commercial source.
                                         3-8

-------
 EPA  System Design & Development
 Guidance: Volume B
       6)   Communications  - The cost for the rental, lease or maintenance of data
            communications equipment, services and facilities.

       7)   Software Maintenance - The cost of maintaining application software.

       8)   Training - The cost of training and travel for new employees and upgrades.

       9)   Security - The cost of security guards, security devices, etc.

3.2.2.3       Qualitative Costs

       Costs may or may not be measured in quantitative terms. Although the primary emphasis
of the benefit-cost analysis is to evaluate measurable impacts, the overall objective is to clarify all
of the important effects of any decision. Since this is the case, the identification and consideration
of qualitative or intangible effects which usually defy accurate calculation nevertheless play a part
in the analysis.  Some qualitative costs include, but are not limited to:

       •  Operational disruptions
       •  Reduced employee morale
       *  Degraded organizational image

3.2.2.4       Determining Total Costs

       To calculate total costs, die total non-recurring and recurring cost subtotals for each year of
the process life are added together. The total annual cost can be converted to present  value cost for
each year of the process life. The present value will give a more equitable base when alternatives
have a wide dispersion in the funding years. A percentage rate must be applied to each year's cost
to calculate the present value and aggregate the total system cost. FIPS  PUB 64 and OMB
Circular A-94 provide more detailed guidance for calculating present value costs.  The total cost
over the process life is derived by summing the total costs for all years of the process  life.

3.2.3  Benefit-Cost Comparison

       The final step of the benefit-cost analysis is the summation of all benefits and costs,
selection of the benefit-cost measure, and arrangement of the benefit-cost display.
                                          3-9

-------
 EPA  System Design &  Development
 Guidance: Volume B
       The summation of benefits and costs is a straightforward addition which permits total
 benefits to be compared to total costs. If all benefits and costs are measured in dollar terms, then
 one number will be obtained for each.  However, qualitative benefits or costs frequently will be
 included. In these cases, no single number can be obtained and a number of measures may have to
 be included in the final summation. However, just because a cost or benefit cannot be measured in
 dollar terms does not mean it can be dropped from the final summation or downgraded If it is a
 major effect, it must be considered.

       The actual quantitative benefit-cost comparison involves three primary calculations:

       1)   Determination of the benefit-cost ratio
       2)   Determination of payback period
       3)   Determination of rate-of-rctum on investment

 Exhibit 3-2 provides a sample format for summarizing both benefits and costs of an option (e.g.,
 Option "A") over the system life cycle period. Exhibit 3-3 provides a sample format for displaying
 quantitative benefits for all options evaluated in order to allow easier comparison.
3.2.3.1
Benefit-Cost Ratio
       There are several benefit-cost measures which can be used for comparison purposes. The
benefit-cost ratio (B/C) is one measure which gives an approximate multiple of return on the
investment costs of a project Obviously, for a project to be economically viable, benefits should
outweigh costs so that the B/C ratio should be greater than 1. Another measure is the ratio of net
benefits (benefits minus costs) to costs. This gives an approximate rate of return on investment A
third measure, net benefits (B-Q may be used if the size of benefits is important
3.2.3.2
Payback Period
       The payback period is calculated by determining the year and month in which the sum (in
current dollars) of benefits first exceeds the sum of the costs.

3.2.4  OMB Benefit-Cost Approval Criteria

       Benefit-cost submissions to OMB for external review and approval must show at least a
10% return on investment or provide substantial additional justification for funding based on
                                         3-10

-------
EPA System Design & Development
Guidance: Volume B
                       EXHIBIT 3-2
SAMPLE SUMMARY OF TIME-PHASED COSTS AND BENEFITS
                    FOR OPTION A
OPTION A
CATEGORY
NON-RECURRING COSTS
Site Modification
Equipment
Software Purchase
Software Development
RECURRING COSTS
Personnel
Maintenance
Training
TOTAL COSTS
PRESENT VALUE COSTS
NON-RECURRING
BENEFITS
Equipment Salvage
RECURRING BENEFITS
Maintenance Cost
Reductions
Space Savings
TOTAL BENEFITS
PRESENT VALUE
BENEFITS
NET PRESENT VALUE
FISCAL YEAR
0












1

-


<,







2



'








3 .


.









4






•





5












6












7

•










                          3-11

-------
EPA System Design & Development
Guidance: Volume B
                        EXHIBIT 3-3
   SAMPLE SUMMARY OF OPTION BENEFITS AND COSTS
•
Benefit/Cost Ratio
Net Benefits to Costs
Net Benefits
Payback Period
OPTION A




OPTIONS




OPTION C




                          3.12

-------
EPA System Design & Development
Guidance: Volume B
satisfying non-financial criteria. OMB has also indicated that particular attention will be paid to
narrative amplification of benefits and costs, including assumptions made, options considered,
and die use of sensitivity analysis to evaluate the potential effects of uncertainty.
                                          3-13

-------

-------
                                     Chapter Four
             OPTION SELECTION AND DOCUMENTATION
       When the procedural steps outlined above have been performed, the options analysis and
 the life cycle benefit-cost analysis are complete. The results of these analyses provide decision
 makers with a range of valued alternatives. However, the results must be carefully examined to
 ensure the accuracy of the analysis, and other factors that may be relevant to option selection must
 be considered.                                 "
 4. 1    OPTION SFTrfifTrnNT CRITERIA

       The results of the operational and technical feasibility analysis and the benefit-cost analysis
 support decision makers by providing them with required information to make an informed
 selection. These analyses do not make automatic the decision of which option to select  The
 selection process, while guided by these analyses, still involves a moderate amount of subjectivity.

       One factor which may play an important role in any decision is risk. With any project there
 is a certain element of risk involved, risk that costs may exceed expectations, that benefits will not
 materialize as expected, etc. A benefit-cost analysis and the operational and technical feasibility
 analysis helps minimize risk since they require explicit definition of expected benefits, costs and
 risks. However, some risk always remains. If there is a high possibility that benefits may  not
 materialize from a project, the project's benefits should be much greater than its costs if a decision
 to continue is to be made. Similarly, if costs and benefits are almost assuredly known, the project
may be viable even at a lower benefit-cost ratio or lower rate of return. The risk, factor should be
evaluated in any decision concerning a project

      Another element of the option selection  process which must be  taken  into account,
especially for large systems, is OMB's requirements governing major system development.  As
previously noted, OMB requires a 10% return on investment or substantial additional justification
if it is to approve such development efforts. In addition, OMB requires (OMB Circular A- 11) that
budget estimates must be prepared for all "major information system initiatives" which are defined
as:                    •   ...      •           •        ...-•.              .--.-••

      •   System design or development costs exceeding $1 million

      •   System operation and maintenance costs exceeding $500,000/year.
                                         4-1

-------
EPA System. Design and Development
Guidance:  Volume B
       This approval requirement can affect the timing of a system development project and
potentially even help decide which option is selected.

       Of particular importance in the final decision is the value judgment placed upon qualitative
considerations, either those identified in the analysis or others. Frequently, the desirability of the
project will hinge on these factors. It is the job of the decision maker to evaluate intangibles in
light of his/her knowledge of the project, the people affected by it, and the conditions surrounding
it A final decision must be based upon these factors as well as the results of the benefit-cost
analysis.

4.2    PnaJMENTATTQN REQUIREMENTS
                                                                ^
       Completion of the analyses described in this volume should be documented in a report
outlining the analyses conducted and the results  obtained.  Appendix A,  EEI-2, presents a
suggested outline for this report The report - EEI-2, Preliminary Design and Options Analysis —
or an equivalent report, must be completed for all system development efforts as described in
Chapter 1, section 1.4. If the selected option is a manual solution, it is not strictly necessary to
complete the report shown, since justification for a manual process is not required. Nevertheless,
it is recommended that basic elements of the documentation be retained for future reference.

       It should be remembered that the benefit-cost analysis is an evolving document and that
benefits/costs will change as the project progresses and becomes better defined. Therefore, for
those efforts which proceed to the design, development and implementation phase the benefit-cost
analysis will require updating.

      Additionally, at me conclusion of this phase, if the system development effort appears to be
viable and proceeding to design, development and implementation, there are certain management
actions which must be taken, including:

      *  Appointment of a project manager and team

      •  Consideration of establishment of configuration management and quality assurance/
         control mechanisms

      *  Development of a Project Management Plan (EEI-3).
                                         4-2

-------
EPA System Design and Development
Guidance:  Volume B
       The Project Management Plan is an extremely important document and will set out how the
system development effort will be accomplished, especially focusing on resources and scheduling
as well as other factors.  Appendix A, EEI-3, provides a representative outline for a Project
   'agement Plan.
                                         4-3

-------

-------
                                    Chapter Five
                                  SUMMARY
 5.1    PRELIMINARY DESIGN AND OPTIONS ANALYSTS OUTPUTS

       The outputs, documents and results of the Preliminary Design and Options Analysis are:

       •   EEI-2, Preliminary Design and Options Analysis
       •   EE3-3, Updated Project Management Plan
       *   Detailed supporting documentation and work papers
       «   Summaries of available options, benefits and costs
       »   Operational and technical feasibility analysis
       •   Functional requirements analysis worksheets

 5.2    NEXT STEPS

       The Preliminary Design and Options Analysis represents another major milestone.  As
 such, it is most important to ensure recommendations resulting from this analysis receive formal
 management endorsement before proceeding to the next step.

       If the option analysis and subsequent Project Management Plan indicate that an automated
 system should be developed, either wholly or in part, then the next steps would be System Design,
 System Development, and System Implementation as outlined in Volume C. Otherwise,  the
program manager should develop the written  guidelines and  procedures that outline  the
recommended approach for conducting the process using non-automated methods.
                                       5-1

-------

-------
                                   Appendix A
             ESSENTIAL ELEMENTS OF INFORMATION
      This appendix provides a representative outline of the document mat will be developed
during the Mission Needs Analysis phase.

A.1   INTRODUCTION

      The documentation requirements contained in this appendix apply to all software
development or modernization projects, regardless of size, complexity or origin. At a minimum,
these standards apply to all new software development projects. Maintenance and/or enhancements
to existing information systems must comply with the requirements set out in Chapter 1, section
1.4 of Volume A, Mission Needs Analysis.

      Compliance with the standards and conventions provided in this appendix will ensure tfiif
                       roduced for all system development projects.
      The
4gfiflf«f in thfa appendix is:
      EEI-1»»Mission Needs Statement

      The following milestone chart illustrates the relative initiation and completion of each
document with respect to the software development life cycle, its major phases, and the span and
scope of Volumes A, B, and C.
                                      A.I

-------
EPA System Design and Development

Guidance: Volume B
          DOCUMENTATION VERSUS LIFE CYCLE
       s
       o  bl
         1.



"•  b«J «« •§ =
i   3 ~ i i  ^ ** * •  •
•X*  CO rtj MM hM LJ 4J MM MM MM
   — g JjJ fj   "  -*-•--
                                            cl
       I
       2
      WH UM ..
      uu I



  S5    I
                                       ^
                                       0) »*•*
8tl
8
« £

u
                            A-2

-------
EPA System  Design and Development
Guidance:  Volume B
                                  EET-2
       PRELIMINARY DESIGN AND OPTIONS ANALYSIS
EXECUTIVE SUMMARY
2.
           Background
           System Concept
           Option Summary  .
           Results of Options Analysis
INTRODUCTION

1.1    Background
1.2    Current System Description
1.3    Results of Mission Needs Analysis
1.4    Scope and Purpose

OPTION DESIGNS  "

2.1
      2.2
System Concept, Management Requirements and Functional Requirements
Summary

Operational Requirements Summary (General system requirements like security,
etc.)
      2.3   Option Descriptions

           2.3.1  Option 1
           2.3.2  Option 2
           2.3.*  ~
3.    OPTIONS ANALYSIS

      3.1   Summary of Option Life Cycle Benefits
      3.2   Summary of Option Life Cycle Costs
      3.3   Life Cycle Benefit-Cost Analysis
      3.4   Summary of Risks and Contingencies by Option
4.
OPTION RECOMMENDATION (WITH RATIONALE)
                                   A-3

-------
EPA System Design and Development
Guidance:  Volume B
                   PROJECT MANAGEMENT PLAN
EXECUTIVE SUMMARY
1.




2.

3.
4.

5.

6.

7.

8,
            Background
            System Description
            Funding/scheduling
            AccompIishmentPlan (including Pi
            Risk
INTRODUCTION

1.1   Background
1.2   Current System Overview

System Description

Project Team and Support
                                     rement)
3.1
3.2
3.3
3.4
            Roles and Responsibilities
            Configuration Management
            Quality Assurance/Control
Quality Assura
Procurement Plan
Project Schedule and Task Description

Project Budget and Funding

Test Plan Requirements/Constraints

Project Constraints

Documentation£tandards

8.1   Policy Events
8.2   Forms and Clearances
                                     A-4

-------
      United States      Office of Information
            Protection BWffffTCfH Mfrfl fl
                 Washington DC 20460  June 1989
      EPA SYSTEM DESIGN &
     DEVELOPMENT GUIDANCE:
        VOLUME  C:
    SYSTEM DESIGN,
      DEVELOPMENT
AND IMPLEMENTATION

-------

-------
                                      Volume C
                           EXECUTIVE SUMMARY
       This document defines the process and documentation that system developers prepare
 during the System Design and Development phase of the system life cycle. The objective of this
 document is to provide guidance towards satisfying requirements specified in EPA's IRM Policy
 Manual for the acquisition and management of information technology.

       The guidance within this document is intended to provide system developers with specifics
 concerning software program management, design and related documentation. The objective of the
 Software Management Plan, outlined in this document, is to ensure the quality of EPA software
 design, development^ implementation and maintenance efforts. The EPA Software Management
 Program is based on six software engineering elements that include policies, standard software
 tools, procedures/ methods, guidelines, planning, and oversight and compliance.
                                                                 V
       Completion of the steps and documentation outlined in this document  will result in  an
 automated system that solves a specific problem as  oudined in EEI-1, the Mission Needs
 Statement Accompanying the automated system will be a sufficient quantity of documentation that
 detail inputs, outputs and processes within the system. The rationale behind all the documentation
 requirements is to assure program managers and OIRM staff that the delivered system fulfills  its
 user's requirements, utilizes EPA accepted standards and procedures, and is within the guidance,
 limitations and constraints imposed on the Agency by OMB, GS A and the Congress of the United
 States.

      The following  exhibit describes the complete  software life  cycle. Each phase in the
 software life cycle is represented by a bubble with its corresponding tide on the inside of the circle.
 Factors that influence each phase are shown surrounding each  circle. The scope of this document
 covers three separate phases, System Design, System Development and System  Implementation.
 As indicated,  factors  that influence the System Design phase are programming language
 constraints, detailed user requirements, data requirements, and the physical environment and the
 preceding bubble, die Preliminary Design and Options Analysis. The next phase discussed in this
 volume, System Development, is influenced by the output from the System Design phase and the
 external influences of development resources, programming standards and development tools. The
 final phase detailed in this document is  System Implementation.   As indicated, factors that
 influence this phase are die outputs from the System Development Process, and external factors
such as OMB certification, operations constraints and user acceptance of the delivered product

-------
EPA System Design and Development
Guidance: Volume C
            COMPLETE SOFTWARE LIFE CYCLE

                            ti

-------
 EPA. System Design and Development
 Guidance: Volume C
                         TABLE OF CONTENTS

                      Tide                                     Page
 1.    INTRODUCTION                                         1-1

       1.1   Background	1*1
       1.2   Objectives of the System Design and Development
            Guidance	1-3
       1.3   Authority	1-4
       1.4   Applicability of the Guidance	1-4
       1.5   Documentation Requirements	1-6
       1.6   Assistance and Support Available	1-8
2.    SOFTWARE MANAGEMENT AND ENGINEERING
      COMPONENTS PROGRAM                                2-1

      2.1    Applicability to Small and Large Projects	.2-1
      2.2    Quality Software	2-2
      2.3    Software Management Program Overview	2-3
      2.4    Software Engineering Components	.>.	.2-4
            2.4.1  Standards	2-4
            2.4.2  Procedures/Methodologies	2-5
           2.4.3  Computer-Aided Software Engineering Tools	2-5
           2.4.4  Quality  Assurance	2-5
     2.5   Software Engineering Principles	2-5
           2.5.1  Determining Documentation Requirements	2-7
           2.5.2  Software Life Cycle Reviews	2-8
                                    ill

-------
CPA System Design art Development
Guidance:  Volume  C
      SOFTWARE DEVELOPMENT STANDARDS
3-1
      3.1    Standard Programming Languages	3-1
             3.1.1  Programming Language Selection Guidelines......;........,.3-l
             3.1.2  Source Program Design and Coding Conventions	3-8
      3.2    EPA Standard Specialized Software Tools.....	........3-8
      3.3    Hardware/Software  Environments	3-9

4.    SYSTEM DESIGN, DEVELOPMENT AND
      IMPLEMENTATION OVERVIEW                             4 -1

      4.1    System Design Stage	:....4-l
             4.1.1  System Detailed Requirements Analysis	....4-3
                   4.1.1.1      Activities	•.	4-3
                   4.1.1.2      Documentation	4-4
                   4,1.1.3      System  Requirements  Review	4-5
                   4.1.1.4      Functional Baseline	i	4-5
             4.1.2   Preliminary Design	4-5
                   4.1.2.1       Activities	.4-5
                   4.1.2.2       Documentation	4-8
                   4.1.2.3       Preliminary Design  Review.	.4-8
                   4.1.2.4       Preliminary Design Baseline	4-9
            4.1.3   Detailed Design	4-9
                   4.1.3.1       Activities	,.....,...4-9
                   4.1.3.2       Docurrentation	4-10
              .     4.1.3.3       Critical Design Review	4-11
                   4.1.3.4       Design Baseline	....;	4-11

-------
  EPA  System  Design and  Development
  Guidance: Volume  C
        4.2   System Development Stage	4-12
              4.2.1   System Production and  Programming	4-12
                                                V1
                     4.2.1.1       Activities	4-12
                     4.2.1.2       Documentation	4-13
                     4.2.1.3       System Production and Programming
                                  Reviews	4-14
                     4.2.1.4       Product Baseline.....	4-14
              4.2.2   System Integration, Test and Evaluation	4-14
                                 i
                     4.2.2.1       Activities	4-15
                     4.2.2.2       Documentation	4-15
                     4.2.2.3       System Integration, Test and
                                  Evaluation  Reviews	4-16
                     4.2.2.4      Operational Baseline	,...4-16
       4.3    System Implementation Stage	4-17
             •4.3.1   System  Installation	4-17
                    4.3.1.1      Activities	4-17
     j
                    4.3.1.2      Documentation	4-17
                    4.3.1.3      System Implementation Review	4-18
             4.3.2  System Operations and Maintenance	4-18
5.     SUMMARY                                                    5-1

       5.1    System Design, Development and Implementation Outputs	5-1
       5.2    Next Steps	5-1
Appendix A
       Essential Elements of Information                                  A-l

-------
 EPA  System Design and Development
 Guidance: Volume C
                             LIST OF EXHIBITS
 1-1    Guidance Audience ........................... . .................. '... ................ 1-2
 1-2    EPA System Development Life Cycle and Decision Process ................. 1-5
 1-3    System Category/EEI Matrix [[[ 1-9
 2-1    EH Requirements for Type I Systems ....................................... ....2-9
 2-2    EEI Requirements for Type D Systems .................................. . ....... 2-10
 2-3    EEI Requirements for Type in Systems ......................................... 2-11
 3-1    EPA Standard Application Programming Languages. .......................... 3-2
 3-2    Software Support Tool Selection Matrix: Small Systems ...................... 3-5
 3-3    Software Support Tool Selection Matrix: Medium Systems .............. .....3-6
 3-4    Software Support Tool Selection Matrix: Large Systems .................. ;...3-7
 3-5    EPA Standard Specialized Software Tools. .................. . ................. 3-10
3-6    Agency-Supported Hardware and Software ................... . ................. 3-11

-------
                                    Chapter One
                               INTRODUCTION
       Pursuant to the Environmental Protection Agency's IRM Policy Manual, this volume is the
 last of three volumes which provide guidance for Agency system design and development efforts.
 This volume provides guidance for the last phase of the EPA system development process — The
 System Design, Development and Implementation.
                                               /
                                            •4
       Volume C is intended for use by system developers, including  Agency staff and
 contractors, who are actually responsible for system development  It therefore provides detailed
 guidance for conducting automated system development activities to help insure compatibility and
 uniformity EPA-wide. Exhibit 1-1 on the next page identifies the intended audience of this
 volume.

 I.I    BACKGROUND

       The Environmental Protection Agency expends millions of dollars each year on the design,
 development, implementation and maintenance of major environmental and administrative systems
 vital to EPA's programs and administrative functioning.  Management of these resources is
 becoming increasingly complex, since the rapid development of information technology in recent
 years has dramatically increased computer capacity and user accessibility. The result has been two-
 fold:
                                             •\
      *   An increasing number of system development efforts by managers and staff at all
          organizational levels who, because of access to their own equipment, develop their own
          systems independently of Agency system's staff

      •   A wide range of hardware/software options for implementation of any specific system
          concept or design.

Therefore, there has been a proliferation of system development efforts by a broad range of users
with varying levels of sophistication  in  making development decisions and  conducting
development efforts.
                                        1.1

-------
EPA System Design & Development
Guidance: Volume C
                           EXHIBIT M
                    GUIDANCE AUDIENCE
                       PROJECT
                       DIRECTOR
                       PROJECT
                       MANAGER
                                               •.'•.  '••
                       SYSTEM
                      MANAGER
   SENIOR
  ANALYST
MID-LEVEL
 ANALYST
JUNIOR
ANALYST
                           1-2

-------
 EPA  System  Design  & Development
 Guidance: Volume  C
                                           s
 1.2   OBJECTIVES OF THE SYSTEM PESTfiN AND DEVELOPMENT GUIDANCE

       Within EPA's Office of Administration and Resources Management (OARM), the Office of
 Information Resources Management (OIRM) is responsible for ensuring the effective and efficient
 use of EPA's information resources including automated system design, development and
 maintenance. OIRM*s objective in this endeavor is to provide guidance, assistance, and only when
 necessary, controls, to assure that the Agency's considerable information resources are utilized
 cost-effectively for the overall benefit of the Agency. To this end, OIRM has developed umbrella
 policies guiding information system development and acquisition (see Information Resources
 Management Policy Manual). This three-volume set of guidelines and standards for system design
 and development is a part of OIRM's Software Management Series which is intended to assist EPA
 in efforts to develop and manage software effectively. This series will also include future guidance
 documents related to software management

       This document is the third of the three-volume set The volumes cover the following:

             Volume A - Mission Needs Analysis — is designed to provide program'managers
       and staff with  a  suggested methodology for assessing and evaluating the  need
       (requirement) for an information system. Applying the methodology in this volume will
       result in: 1) confirmation that a need (requirement) exists and, 2) provide a preliminary
       operational specification of the requirement

             Volume B  - Preliminary Design and Options  Analysis — is directed towards
       program managers and staff. It provides guidance and a methodology for  structuring
       design options for meeting the requirement defined in Volume A and provides guidance for
       selecting the most cost-effective option,

             Volume C - System Design. Development and Implementation is intended for use
      primarily by system developers and provides specific guidance and standards which must
      be adhered to when undertaking automated system design and development efforts.

Together these three volumes provide comprehensive guidance and standards for the orderly and
cost-effective development of automated systems. Exhibit 1-2 depicts the  flow of the development
life  cycle and decision process for the three volumes.
                                         1-3

-------
 EPA System Design & Development
 Guidance: Volume C
        In addition to the System Design and Development Guidance, OIRM is currently drafting
 the EPA Information Security Manual As security issues are raised and addressed throughout the
 system development life cycle, the security manual should be consulted for proper Agency policy
 and guidance.

 1,3    AUTHORITY
       The EPA System Design and Development Guidance derives its authority from Chapter 4
 of the IRM Policy Manual, entitled "Software Management," which establishes the Agency
 Software Management Program. The guidance serves as the primary guidance for Agency system
 design and development efforts.
 1.4
APPLICABILITY OFTHE GUIDANCE
       Senior Agency managers and responsible staff should read the guidance and become
 familiar with the decision-making process involved with system design and development efforts.
 They are responsible for ensuring adequate analysis and documentation to support all critical
 decision points. The full documentation requirements for automated system development efforts,
 which mual be followed to conform to OARM policy, are fully discussed in Volume C

       In general, Volumes A and B are intended to assist program offices and/or users in
 conducting their own initial studies of system requirements, needs, option feasibility  and cost*
 effectiveness.  In this context, the term "system" in Volumes A and B refers to a systematic set of
 processes and/or procedures which can be used to meet the information needs of a user. It does
 IM imply that the "system" will be an automated system.
                                                                                   v.
       Volume C, however, presumes that an automated or partially automated solution has been
 selected as a result of the Volume B options analysis. Volume C provides guidance and  standards
 for automated system development efforts. If the automated system is a relatively small application
 on a microcomputer targeted for use within a single office (a "user owned information  system").
 Volume C provides simplified requirements for system design, development and implementation.
 If the proposed system is a larger application (mainframe or minicomputer), which is mission
 critical or involves multiple offices and organizations, Volume C provides the full set of guidance
 and standards  which must be followed by system developers. This will assure  uniform, cost
effective system development in accordance with EPA policies, guidelines and standards.
                                         1-4

-------
EPA System Design & Development
Guidance: Volume C
                          EXHIBIT 1-2
         EPA SYSTEM DEVELOPMENT LIFE CYCLE
                  AND DECISION PROCESS
    DEVELOPMENT STAGE
                                DECISION/RESULT
  C
 Real World
Mission Need
J
    .Volume A
               Analysis
                                   REQUIREMENT AND
                                 OPERATIONAL CONCEPT
                                      DEFINITION
       , Volume B.,
             Prel£minory Design
               Options Analysis
                                 OPTION DESIGN. BENEFIT/
                                  COST ANALYSIS. AND
                                   OPTION SELECTION
           Volume C,
                   System Design*
                   Development
                  Implementation
                                  FULLY IMPLEMENTED
                                       SYSTEM
                             1-5

-------
 EPA System Design &  Development
 Guidance:  Volume C
 1.5   DQTTTMENTATION
       In general, die intent of the three volume System Design and Development Guidance is to
 provide a consistent 'focus for system development efforts which will allow both EPA program
 managers and OARM managers to cost-effectively develop and maintain the Agency's systems.
 To achieve this  goalt certain documentation requirements termed "Essential Elements of
 Information" (EEI) documents, must be met  Observance of this guidance in preparing EEFs
 should result in proper documentation for audits. The EEI's will also serve as a helpful reference
 for conducting post-evaluations of the system decision making process. Each volume contains an
 appendix which outlines die required EEI documentation.

       For certain system development efforts OIRM and office Senior Information Resources
 Management Officials (SIRMOs) must be involved in a review capacity to fulfill EPA's IRM
 Policy Manual requirements. Systems falling into one or more of the following categories must
 have OIRM/SIRMO review involvement:

       *   EPA mission critical

       •   States, local governments or other Federal agencies involved

       •   Interorganizarional involvement (e.g., between Assistant Administratorships or
          including Regional Office involvement)

       *   Costs for system development/enhancement are projected to exceed $250,000
          (excluding costs associated with long-term system operation and maintenance)

       •   Information security issues involving the three general security areas: applications
          security, installation security and personnel security.  In total, information security
          involves die precautions taken to protect the confidentiality, integrity and availability of
          information

       *   Privacy Act or confidential business information involved.

       For system development efforts falling into any one of these categories, OIRM and office
SIRMOs must be involved beginning with a review of EEI- 1, generated at the conclusion of the
Mission Needs Analysis, as described in  this volume of die EPA System Design and Development
                                         1-6

-------
 EPA System  Design & Development
 Guidance; Volume C
Guidance. OIRM/SIRMO review involvement will continue through the development life cycle of
these systems and will include all EEI documentation requirements for such systems. For systems
not falling into one of the above categories, EEI's may be forwarded to OIRM/SIRMOs for
information and review as they are developed. .

       A review cycle should be developed to monitor each EEI preparation.  Hie review cycle
could include several stages, such as a series of status briefings for management, focus groups,
and/or distribution of die EEI in draft form. Throughout the review cycle, the managers and users
involved should be informed of the process and content of the EEL When the final document is
completed, a consensus among management should be reached before developing the next EEL

       It is not OIRM's intent to burden EPA managers with a host of documentation requirements
for each system development effort  The EEIs simply stress typical documentation requirements
and their outlines highlight major topics that need to be considered for any system development
effort Managers may use their professional judgment in substituting, combining, or down-scaling
the content of die EEIs to meet the unique requirements of their project

      Criteria for determining the minimum EEI documentation for a specific process during the
design, development and implementation phase is based on the nature and scope of the information
process  and its importance to EPA's mission. Three types of categories describing various
systems with differing levels of EEI documentation requirements are identified as follows:

      «   TYPE I: M^far Agency /Widely Accessed Information System; An information process
          that requires special attention because of its importance to an Agency mission; its high
          development, operating, or maintenance costs or its significant impact on administration
          of Agency programs or; is widely accessed by a combination of EPA Headquarters,
          Regional Offices, state and local users and/or Federal agencies.

      •   TYPE II:  Localized Information System: An information process that is not a Major
          Agency Information System but significantly  supports accepted program goals and
          missions  and is  accessed primarily by  users  in  one major  area, e.g., EPA
          Headquarters, a single Agency program, or a Region.

      •   TYPE HI: User Owned Information System: Unique, stand-alone process developed to
          improve the efficiency or effectiveness of operations for a single user or a small group
         of users.
                                        1-7

-------
  EPA  System  Design & Development
  Guidance: Volume C
        Documentation requirements for each of these categories are projected in Exhibit 1*3.
  Automated systems involving information security will be subject to one additional documentation
  requirement — completion of a certification form (certification of sensitive systems is an OMB
  requirement).  Hie form, which is under development and will be issued as pan of the forthcoming
  EPA Information Security Manual, will capture basic information on system sensitivity, security
  requirements, security design, reviews, test scenarios, results and safeguards.

  1.6    ASSISTANCE AND SU
   /

        Agency Program Management officials embarking on a system development effort should
 be aware that there are at least two sources available to them for assistance and support during the
 system development life cycle:

       •  Within each AA/RA's office SIRMOs are available for assistance, support and guidance
          relative to the EPA System Design and Development Guidance and other OIRM
          guidance and standards

       •  OIRM, with its general IRM management oversight role and requirements to exercise
          procurement approval authority, has a staff organized to support EPA's administrative,
          program and research communities.

It is appropriate to involve these support sources as early as is feasible in the system development
life cycle for most system development efforts.

      The primary reasons for early involvement of SIRMOs and OIRM staff are:

      •   Fulfilling EPA's IRM policy for system development review requirements .

      •  Providing a value-added service role involving consultation, assistance, technical
         standards, guidance and interpretation of requirements
                                                    t
      *  Expediting procurement for system development efforts which proceed to the system
         design, development and implementation phase.
                                       1-8

-------
EPA System Design & Development
Guidance: Volume C     -,
                         EXHIBIT 1-3
                    SYSTEM CATEGORY
                       EEI MATRIX
TV^ System
\ ^**^ Category
EEI ^"Vs.
Requirements' ^"s^
EEM
Mission Needs
Analysis
EEI-2
Preliminary Design
and Options Analysis
EEI-3
Project
Management Plan
EEI-4
System
Implementation Plan
EEI-S
System Detailed
Requirements Doc.
EEI-6
Software
Management Plan

EEI-7
Software Test and
Acceptance Plan
EEI-8
Software Design
Document
EEI-9
Software Maint
Document
EEI- 10
Software Operations
Document
EEI -11
Software User's
Reference Guide
EEI- 12
System Integration
Test Report
Type
•
•
•
•
•
•
•
•
•
•
•
•
Type
II
•
•
•
•
•


•
•
•
•
•
Type
III
•



•


•
•
•
•

                            1*9

-------
 EPA  System Design &  Development
 Guidance: Volume C
       •  Providing assistance in determining user needs as early as possible in the life cycle.

 Achieving these objectives will strengthen EPA's system development efforts and avoid major
 pitfalls that have beset system development efforts in other government agencies (e.g., project
 stalls due to outyear funding shortages stemming from under-projected planning or project
 disruptions due  to failure to get hardware/software acquisitions into the procurement cycle
 expeditiously and when required).

       The remainder of Volume C provides guidance and standards for conducting the third
phase of the system development process - the System Design, Development and Implementation
phase.
                                        1-10

-------
 EPA  System Design  & Development
 Guidance:  Volume C
                                   Chapter Two
                    SOFTWARE MANAGEMENT AND
               ENGINEERING  COMPONENTS PROGRAM
       Implementation of the EPA Software Management Program draws on the experience of
 software professionals within EPA and on the experience of the Federal Government through both
 the Office of Information Resources Management, the General Services Administration and the
 National Institute of Standards and Technology.

       The objective of the Software Management Program is to ensure the quality with which
 EPA designs, develops, implements and maintains software. The EPA Software Management
 Program consists of the following Software Engineering Elements:

       •  Policies
       •  Standard Software Tools
       •  Procedures/Methods
       •  Guidelines
       * . Planning, and                                       '•
       •  Oversight and Compliance.

 This volume specifically addresses standard software tools, procedures/methods, guidelines,
 planning and oversight and compliance.

 2.1    APPLICABILITY TO SMALL AND LARGE PROJECTS

       The Software Management Program is designed to be applicable to both large and small
 projects. Managers of specific projects must use their professional judgment (aided by the
 guidelines provided in this methodology) on how to apply the Software Management Program.
 For larger projects, the Software Management Program should be used in its entirety. For smaller
 software projects, the Software Management Program should be adjusted to meet the needs of the
 specific project. For example, a judgment might be made that the documentation requiremc its are
excessive for a particular project, so parts of different documents could be combined or eliminated
 to reduce the number of documents and level of documentation required.
                                      2-1

-------
EPA System Design &  Development
Guidance:   Volume C
2.2   QUALITY SOFTWARE
                           .•*
      The Software Management Program will produce significant results, including:

      •   Improved inter-organizational relationships

          -   Demonstrated software engineering expertise
          •   Improved user acceptance of final products
          -   Improved ability to react to changes
          -   Increased reliability of the software
          -   Improved maintainability of the software

      •   Institutionalization of the software development process

          -   Enhanced technology transfer between projects

          -   Better utilization of personnel resources

          -   Reduced dependency on specific individuals

          -   Improved ability  to measure  and control  software development for project
             scheduling and cost purposes

         -   A production line approach to software development and maintenance

      *   Reduced cost of developing and maintaining software
            Increased
                       productivity
-  Fewer problems (errors) with delivered products
•  More easily enhanced software

Improved software portability

-  Isolation of computer architecture dependencies
   Elimination of non-standard source code
-  Development of reusable source code
                                        2-2

-------
 EPA  System Design  & Development
 Guidance:  Volume C
       The Software Management Program has been developed to assist personnel directly
 involved in software development projects, including:

       *  Program Managers - It provides assurance that EPA will apply uniform, cost-effective
          methods throughout its software life cycle projects.  New projects need not produce
          their own unique software management and development procedures, but, through the
          Software Management Program, can benefit from the experience of successful software
          development projects.               "                      -      "'"-'.

       •  Project Managers  — It includes the "what, why and how" of software life cycle
          management
                                                                       . •»
       *  Programmers and Analysts —  It describes specific tools arid techniques for 'the
          software development life cycle.                                         •

 2.3    SOFTWARE MANAGEMENT PROGRAM OVERVIEW

       The EPA Software Management Program includes a system life cycle model, and for each
 phase of the life cycle process, the software engineering components related to controlling and
 regulating that phase. The Software Management Program has major inputs from Volumes A and
 B of the System Design and Development Guidance series. These inputs are:

       •   Phase 1  - Mission Needs Analysis

          Mission Needs Statement (including Initial System Concept) is produced during the
          Mission Needs Analysis phase.

       • •-  Phase 2 - Preliminary Design and Options Analysis

          Preliminary Design and Options Analysis Document and a Project Management Plan are
          produced during the Preliminary Design and Options Analysis phase.

The Software Management Program defines the following additional phases of the system.life'
cycle:  t              .     •                          ..•:•:••••";...•••'':•
      •   Phase 3 - System Design, Development and Implementation
      •   Phase 4 - Operations and Maintenance.
                                         2-3

-------
EPA System Design & Development
Guidance:  Volume C
Detailed discussions of the System Design, Development and Implementation phase aze contained
in Chapter 4 of this document. The Operations and Maintenance phase of the system life cycle is
discussed in OIRM's Operations and Maintenance Manual
2.4
                    NGINEER TNft COMPONENTS
       This section addresses the software engineering components necessary to successfully
implement the EPA Software Management Program during the EPA software development life
cycle phases and the quality assurance considerations for successful software development

       There are four software engineering components that direct, control or support each of the
life cycle phases and are essential to the successful execution of each phase. These software
engineering components are:

       •   Standards
       •   Procedures/methodologies
       •   Software Development Support Tools
       •   Quality Assurance.

       Each life cycle phase is supported, in different degrees, by the four software engineering
components.  These components provide the necessary technology and discipline to create a
software engineering environment

2.44

       Standards  are grouped  in two major categories:  methodology standards (uniform
procedures for  accomplishing  a  function)  and performance standards  (metrics to  evaluate
performance).

       Methodology standards allow work to be accomplished systematically. They facilitate the
turnover of work whether it is from personnel working in one life cycle phase to those working in
another life cycle phase or among personnel working on  the project Personnel trained in the
Software Engineering Program should be able to join a project at any time and become productive
soon thereafter.
                                        2-4

-------
 EPA System Design & Development
 Guidance:  Volume C
        Performance standards deal with the quantifiable aspect of a task, for example, the amount
 of time it should take to perform a task and the expected quality of the task's end product.
 Performance standards depend-on methodology standards being in place and enforced so that
 performance can be measured accurately.

 2.4.2  Procedures/Methodologies

        Procedures/methodologies define the processes that are followed in each of the particular
 phases of the system development life cycle.

        The two classes of procedures are manual and automated. Manual procedures, which
 programmers and analysts follow when  performing a task, direct the flow of activities.  For
 example, a programming procedures manual provides the direction for achieving progress using
 the proper programming language elements, associated structured techniques and source code
 formatting.  Automated procedures; on the other hand, direct the execution of computer programs
 and software development support tools.

 2.4,3  Computer-Aided Software Engineering Tools

       Computer-aided  software engineering (CASE) tools are  computer programs used by
 system developers which  automate several of the labor-intensive activities including project
 management,  design and coding.   One distinct  advantage of using CASE tools is the
 standardization they enforce over the entire development effort. This standardization eliminates the
 concept of a "key"  manager or programmer and enables new staff joining the project to be
 productive at any stage of the development life cycle. CASE tools support EPA's standards,
 procedures and methodologies and should be used, if appropriate, by contractors and EPA staff in
 the software development and maintenance efforts.

 2.4.4  Quality Assurance

       Quality Assurance is the formal process of measuring or evaluating the degree to which a
 product meets the standards by which it was developed and the specifications upon which it was
 based. Each product (both software and documentation) produced within each life cycle phase
 should be subjected to a Quality Assurance process

 2.5    SOFTWARE ENGINEERING PRINCIPLES

       Effective system development requires a thorough understanding of the user's requirements
coupled with a development process capable of fulfilling those requirements with a responsive
                                         2-5

-------
 EPA System Design &  Development
 Guidance:   Volume C
 system. A clear understanding must be established of the user's requirements, their relationship to
 the overall  system and the functional elements constituting the system.  The EPA Software
 Management Program provides an approach to software development that divides the life cycle into
 well defined phases.

       The  Software Management Program indicates the activities and tasks that should be
 performed for each phase of the life cycle and the resulting deliverables. It also identifies what has
 to be done, when it should be done and how it should be done. •

       The Software Engineering Program defines the Essential Elements of Information (EEIs) or
 documentation that should be produced and/or updated. The baselines for each phase and reviews
 necessary to approve the documentation are also defined in the Software Engineering Program.

       The characteristics of an evolving system are defined and documented in increasing detail at
 logical transition points, or baselines, of the software development life cycle.  Approved
 documentation and/or software products constitute a baseline. At any time in the system life cycle,
 all  previously established baselines, together with any approved changes to these baselines,
 constitute  the formal identification of the system and its components.

       The type of system being developed will dictate the level of documentation necessary to
 support that system.  The diligent use of EEIs will resolve die conflicts that arise between the:

       •  Cost of documentation

       *  Classical life cycle for system development

       *   Changes in computing capabilities and system development techniques.

       The use of the  EEIs  defined in this volume represent a flexible approach to system
documentation. All systems require some form of documentation.  However, the degree of
documentation needed is dependent on the nature of the system, constituency (who will use it), and
life cycle  costs. Software systems that are used nationwide. Agency wide and support  major
program initiatives require complete documentation and thoughtful consideration of options, life
cycle costs and mission needs.
                                         2-6

-------
 EPA  System  Design & Development
 Guidance:  Volume C
       Key points to consider are:

       •  A mission needs analysis and a requirements analysis which includes feasibility and
          benefit-cost analyses must be conducted prior to embarking on a major agency
          information system development effort

       •  EEIs are required for both new systems and existing systems.

       *  The EEI outlines contained in Appendix A  of this volume represent the basic EEI
          requirements (see section 1.6 for the minimum EEI requirements for the different sizes
          and types of systems). Information managers may want to increase the depth and
          breadth of these PFT« based on the circumstances of the project For example:

          -   Elements not included in a particular EEI outline that are considered necessary
             within  . specific project may be added, thus tailoring the EEI for that specific
             project                   .

          •   Additional EEIs may have to be developed to meet the specific needs of a given
             software system or project

2.5.1  Determining Documentation Requirements

       Criteria for determining the minimum EEI documentation for a specific software system are
based on the nature and scope of the information system and its importance to EPA's mission.
Four types of systems are presented below along with guidance for determining the minimum level
of EEI documentation for each:

       a.   Type I
 1          "Major Agency Information System: An information system that requires special
           continuing management attention because of its importance to an agency mission, its
           high development, operating, or maintenance costs or its significant impact  on
           administration of agency programs.

           In this context, a system which requires obligations of more than $500,000 per year
           to maintain or whose software component contains more than 500,000 lines of 3GL
           source  code or 100,000 lines of 4GL source code is considered a Major Agency
           Information System.
                                        2-7

-------
 EPA System Design & Development
 Guidance:   Volume C
                    Accessed Infqpnarion System: An information system that is hot a Major
            Agency Information System, (but significantly supports accepted program goals and
            missions). It is widely accessed by a combination of EPA Headquarters, Regional
            Offices and/or State and local users and other Federal agencies.

            Exhibit 2-1 presents the EETs required for Type I information systems which include
            both Major Agency Information Systems and Widely Accessed Information Systems.

       b.   Tvpen
            Localized Information System:  An information system that is not a Major Agency
            Information System, but significantly supports accepted program goals and missions.
            It is accessed primarily by users in one major area, e.g., EPA Headquarters, a single
            agency program, or a Region.

            Exhibit 2-2 presents the EEIs required for Type n, Localized Information Systems.

       c.    Tvpem
            User Owned Informatiop System: Unique, stand-alone system developed to improve
            the efficiency or effectiveness of operations for a single user or a small group of
            users.                                   .   •             .
            Exhibit 2-3 presents the
            Systems.

2.5,2  Software Life Cvcle Reviews
required for Type IH, User Owned Information
Formal reviews are carried out at key points in the life cycle to ensure that the software
development activities are progressing consistent with user requirements and EPA standards. The
reviews used in the EPA System Development life cycle are described in detail in Chapter 4.
                                        2-8

-------
EPA System Design & Development
Guidance: Volume C
                         Exhibit 2-1
        EEI REQUIREMENTS FOR TYPE I SYSTEMS
                              Jl
                             iiij
             A "S
      1
      Q
       *
I
         I
                             ill!

                 ill! i!


                         DOCUMENTATION
                      REQUIREMENTS (EEIs)
                           2-9

-------
EPA System Design & Development
Guidance: Volume C
                         Exhibit-2-2 •
        EEI REQUIREMENTS FOR TYPE II SYSTEMS
              1
              1

                                                2
                        1
         i
              ,§
              I
           *I
ill
                   Is,
                 i,
                        DOCUMENTATION
                      REQUIREMENTS  (EEIs)
                          2-10

-------
EPA System Design & Development
Guidance: Volume C
                         Exhibit 2-3
       EEI REQUIREMENTS FOR TYPE III SYSTEMS
                                             if
         !
      a
       »
ii
1;
             I!
            DOCUMENTATION
          REQUIREMENTS (EEIs)
                           2-11

-------

-------
                                   Chapter Three
               SOFTWARE DEVELOPMENT STANDARDS
       This chapter addresses the software development standards that have been approved for use
 in the development of EPA information systems. They include standard 3rd and 4th generation
 programming languages, data base management systems, specialized software tools, graphics
 packages and telecommunications support software.
 3.1
       STANDARD PROGRAMMING LANGUAGES
       EPA standard programming languages have been established for developing software
 systems for use within EPA. These include the 3rd generation programming languages (3GLs)
 that have been standardized by the American National Standards Institute as national standards and
 by the National Institute  of Standards and Technology as Federal Information Processing
 Standards.

       In addition, EPA has internally standardized several 4th generation programming languages
 (4GLs) in the interest of improving productivity and reducing the cost of software development
 and maintenance within the agency. Development and maintenance requirements should be
 evaluated in relationship to the costs and benefits of using 3GL and 4GL languages.  This
 evaluation will determine which language is most beneficial for system development based on total
 system life-cycle considerations.  Exhibit 3-1 presents the standard programming languages used
 within EPA.
3.1.1  Programming Language
                                   Guidelines
      A number of factors go into deciding in which computer environment an application will
operate.  After the computer hardware configuration has been identified, the application
programming language and associated support software tools must be selected.  While there is no
"right" answer for each information system being developed, the use of common sense and the
guidelines presented in this volume can lead to a reasonable solution.

      Software developers should consider the following questions:

      *  Is an off-the-shelf solution available?
                                       3-1

-------
EPA System Design & Development
Guidance:  Volume C
                       EXHIBIT 3-1
             EPA STANDARD APPLICATION
              PROGRAMMING LANGUAGES
APPLICATION SOFTWARE
PROGRAMMING LANGUAGE


3GL




4GL

COBOL
FORTRAN
PL/I
PASCAL
INFO
NATURAL
FOCUS
dBASE III
SAS
STANDARD
EPA
Yes
Yes
Yes
Yes
Yes
Yes
Yes
5 Yes
Yes
FIPS
Yes
Yes
Yes
Yes





                          3-2

-------
 EPA System Design &  Development
 Guidance:   Volume C
       *   Has OIRM staff advice been solicited?

       •   Can the application be satisfied by using an existing system or its software (e.g.,
           software reuse,  off-the-shelf software, consulting the EPA Information System
           Inventory)?                                 .

       Some of the factors which should be addressed when determining the hardware/software
 environment are:

       •   Results of the requirements and feasibility studies

       •   Potential life span of the application

       •   Resources  available now and in the future to support both the development and
           maintenance of the application

       •   Telecommunications and local communications facilities

       »   Location and size of the data base(s)
                                                    'v
       •   Number of users / Number of simultaneous users

       *   Complexity of the data                                       '•

       •   Information security needs such as access controls, backup, and recovery.

       In an attempt to reduce the complexity of this effort, EPA has defined the computer
hardware/software environments available for use. As a guideline, a decision matrix approach to
identifying what software support tools are appropriate has been defined.

       The decision matrices can be used to help determine the support tools appropriate to system
development in the absence of OIRM staff guidance.  The matrices apply only to the general
systems which store and retrieve information and should not be construed as taking precedence
over existing EPA system plans, strategies and policies.  Also they do not encompass statistical
systems, spread sheet systems, graphics systems and other specialized functional systems. With
                                         3.3

-------
 EPA System Design &  Development
 Guidance:  Volume C
minor exceptions, they do not address hybrid systems - those which are developed using two or
more support tools (e.g., NaturaJ/VSAM for data entry and NaturaJ/ADABAS for data retrieval).


      The Software Support Tool Selection Matrices, as depicted in Exhibits 3-2, 3-3 and 3-4,
address systems that are  small, medium, and large.  Size is defined by the number of records
processed or total storage requirement.


      •   Small Systems - are generally programmed using 4GLs with or without data base
          support, and they can run in either the mainframe, minicomputer or microcomputer

          environments;
         Medium Systems - are generally programmed using either 3GLs or 4GLs with or
         without data base support, and they can run in either the mainframe or minicomputer

         environments:
         Large Systems - are generally programmed using either 3GLs or 4GLs with or without
         data base support, and they run in the mainframe environment
      The content of each matrix cell and the criteria of small, medium and large systems are
simplified to make them useful. There are several decision criteria along the legs of the matrices

and numbers in the intersections of the rows and columns which correspond to the software
support tools. The key for the software support tools is:
      1 -Mainframe
      2-Mainframe
      3-Mainframe
      4-Mainframe
5 - Minicomputer
6 - Minicomputer
7 - Microcomputer
8^ it :.*_» *M i, ... ..•._
- iVucrocompuier
Q X>f:— — >._ ...
3GL
4GL
4GL
4GUDBMS
•any
3GL/DBMS  (COBOL, PL/I, FORTRAN)
4GL/DBMS  (Natural/ADABAS)
4GL        (FOCUS)
4GL        (NATURAL/VSAM)
                                     (COBOL, FORTRAN, PASCAL)
                                     (FOCUS, INFO)

                                     (INFO, FOCUS, dBASE HI)
                                     (dBASE HI)
                                     (FORTRAN, PASCAL)
                                      3-4

-------
EPA System Design & Development
Guidance:  Volume C
                             EXHIBIT 3-2
       SOFTWARE SUPPORT TOOL SELECTION MATRIX
                         SMALL SYSTEMS
SMALL SYSTEMS -f RECORDS <10K OR
Number of Simultaneous Users
Complex Random Retrievals?
Location
of Related
Data
s
None
Main-
Frame
Mini-
Computer
PC
I
YES
2.3.6,7
2.3
6
7.8.9
NO
2.3.4.6.7
2.3.4
6
7.8.9
. TOTAL SIZE < 10 1

1< n < 15
YES
2.3.6
2.3
5.6
2.3.6
NO
2.3.4.6
2.3.4
5.6
2.3.4.6
1
	 ;;•
dEGABTTES i
>15 j
YES
2 .
2
2
2
•'.
A
NO |
s
•:-
if
2.3.4 i
s
j
2.3.4 j
i
2,3,4 ' j
2.3.4 |
     Notes:

     1 - Mainframe
     3 -Mainframe
     4 - Mainframe

     5 - Minicomputer
     6 - Minicomputer

     7 - Microcomputer
     8 - Microcomputer
     9 - Microcomputer
3GL/DBMS    (COBOL, PL/I. FORTRAN)
4G1VDBMS    (Natural/ADABAS)
4GL        (FOCUS)
4GL        (NATURAL/VSAM)

3GL        (COBOL, FORTRAN. Pascal)
4GL        (FOCUS. INFO)

4GL        (INFO, FOCUS, dBASEffl)
4GUDBMS    (dBASEffl)
3GL        (FORTRAN. Pascal)
                                 3.5

-------
EPA System Design & Development
Guidance:  Volume C
                              EXHIBIT 3-3
       SOFTWARE SUPPORT TOOL SELECTION MATRIX
                        MEDIUM SYSTEMS
               MEDIUM SYSTEMS-10K
-------
EPA System Design A Development
Guidance:  Volume C
                           EXHIBIT 3-4
      SOFTWARE SUPPORT TOOL SELECTION MATRIX
                       LARGE SYSTEMS
LARGB SSSTCUS-
Volatility
Number of
Simultaneous Uaen
Complex Random
Retrieval*?
File
Pass
Frequency
n« 1
per day
I 4O
per day
X9||^^i[
%
m 9 REOORD0 2

• 100K OR TOTAL SEE > 100 MEGABYTES
Almost Static
(Update Weekly or Leu)
S 15
YES
2.3
2
Hybrid
1.3
NO
2.3.4
2.4
4
jgMt&&&£j&&g^g&33&iftMg
> IS
YES
2
2
Hybrid
1.2
aa&gajBE
NO
2.4
2.4
4
Moderate Amount of
Change or Volatile
S IS
YES
2
2
Hybrid
1.2

> 15
NO
2.4
2.4
4
Highly
Volatile !
S IS
YES
1.2
1.2
Hybrid
1.2
> 15
NO
1.2
1.2
Hybrid
1.2
^f;fi1fa™Wf'fff^ffl^^Mff:^
    Notes:

    1-Mainframe
    2-Mainframe
    3-Mainframe
    4 •Mainframe
3GUDBMS   (COBOL. PUT, FORTRAN)
4GL/DBMS   (Natural/ADABAS)
4OL       (FOCUS)
4GL       (NATURAIWSAM)
                              3-7

-------
 EPA  System  Deftgn & Development
 Guidance:  Volume C
 3.1.2  Soureq Program Design and Coding
       EPA has a general set of mi"'*""*" program design and program coding standards which
 promote productivity, source code maintainability and software sharing and reuse.  These
 standards are patterned after die standards used by the Department of Defense.  The salient
 characteristics of these standards are:

       *  Use of structured programming constructs to control the flow of execution

       •  Elimination or significant reduction in the use of "GO TO" statements and complicated
          negative Boolean expressions
                                           tf
    .   •  Applicability to 3GL and 4GL programming

       *  Modularity in source program design and coding

       •  Good documentation practices such as:

          -  Naming conventions
          -  Symbolic parameters
          -  Paragraphing
          -  Blocking .
          -  Indentation of source code
          -  Single statement per line
          -  Intelligent use of comments
          •  Error messages

3.2    EPA STANDARD SPECTAT .T7FD SOFTWARE TOOLS

       The EPA has a number of specialized tools for use on  its various computer hardware
configurations. The standard specialized software packages that have been approved for use in the
development of EPA software systems are presented in Exhibit 3-5. For detailed information on
current software development standards contact OIRM or the National Data Processing Division
(NDPD).
                                        3-8

-------
 CPA System Design  & Development
 Guidance:   Volume C
3.3    HARDWARE/SOFTWARE ENVIRONMENTS

       The EPA hardware/software environments available for software development are
presented in Exhibit 3-6.  This exhibit identifies the EPA software packages that are available and
the hardware environments in which each of the software packages is supported.  The exhibit
provides a representative sample of available MS-DOS and Macintosh application software. The
Macintosh computer is included as a potential option for development of Localized (Type II) or
User Owned (Type El)  information systems.  Any software development effort which uses
software packages or hardware outside the EPA Hardware/Software Environments must have
approval from the Director, Office of Information Resources Management (OIRM).

-------
EPA System Design & Development
Guidance: Volume C
                        EXHIBIT 3-5
     EPA STANDARD SPECIALIZED SOFTWARE TOOLS
FUNCTION
Data Rase
Management
Graphics



Geographies


Spreadsheet


Word Processing




Text Processing
and Retrieval


Programmer Tools

Software
Maintenance Tools


Communications
Software












TOOL
ADABAS
DBASE HI PLUS
SASGRAPH
TELAGRAPH
VERSAGRAPH

ARC/INFO
UNIRAS
"S
LOTUS 1-2-3
20/20
SUPERCALC
LEXTTYPE
WORDSTAR
MULTI-MATE
TEXT
WORD MARC
BASIS
INFO-TEXT


ISPF
EMACS
LIBRARIAN
COBOL DEBUGGERS
PL/I DEBUGGERS
FORTRAN DEBUGGERS
SNA
DECNET
PRIMENET
GNcrn
PRfMEUNK
CROSSTALK
KERMIT
ARBITER
Bulk Data Transfer CBDT)
3270 PC FILE
TRANSFER (IND$FILE)
Data Transfer Facility (DTF)


INTEGRATED \
WITH
NATURAL !
SUPER. NATURAL
SAS 1
• • . s
INFO

INFO


,
J





^_
INFO-TEXT
INFO

i

|



!


1
1
- 'i
PRIME/PC Connection !
•;
|
I
t
i


j
:•


                           3-10

-------
EPA System Design & Development
Guidance:  Volume C
                       EXHIBIT 3-6
    AGENCY-SUPPORTED HARDWARE AND SOFTWARE

TOOLS
3rd Generation:
COBOL
FORTRAN
PL/1
PASCAL
4th Generation!

INFO
FOCUS
NATURAL
SAS
DBASE in PLUS
EASYTRIEVE PLUS
fid fit Hair- Mt>yiarf«>im>i»«

ADABAS
Graphics Faculties:
TELL-A-GRAPH/Cuechart
VERSACRAPH
SASGRAPH
CRICKET DRAW
CRICKET GRAPH
MACDRAW
MACPAINT
Spreadsheet:
LOTUS 1-2-3
20/20
SUPERCALC
SAS/FSP
EXCEL
TARGET HARDWARE ENVIRONMENT
IBM
3090

•
•
•



•
•
•

•
IBM
43XX
DEC/
VAX
PRIME


•




•





•
•
•

. •
•

•
•

•
•

•

•


• '
•

MS
DOS


•

•

•
•

•
•

Mac-
Intoah
LAN
-

















•


•

,
•

•

•
















•
• '










•








•



•
•







•

•










•
•


•



-


•
•
•
. •





•










•




                          3-11

-------
EPA System Design & Development
Guidance:  Volume C
                      EXHmiT3-6
    AGENCY-SUPPORTED HARDWARE AND SOFTWARE
                    (CONTINUED)

TOOLS


ARC/INFO
UNIRAS (Pilot)

word ana Text software:
LEXTIYPE
WORDSTAR
MULTIMATE
WORDPERFECT
WORDMARC
BASIS
TEXTWP
INFO-TEXT
MACWRITE
MICROSOFT WORD
Project MaxHUtexneiit:
""
TELL-A-PLAN
MICROSOFT PROJECT
TIMELINE
Telecom Capabilities:
SNA(3270/RJE)
ASYNCH ASCn
X.25
PRIMENET
DECNET
CROSSTALK
KERMIT
GNET II
TARGET HARDWARE ENVIRONMENT
IBM -
3090


•






•





•



•
•
•



•

IBM
43XX
-


-















•
•




•

DEC/
VAX
1
•





•











•
•
•
-
•

•

PRIME

•






•

•
•







•
•
•
•


•
•
MS
DOS




•
•
•
•





•


•
•

•
•


•
•
•

Mac-
intosh







•




•
•





•
•
•
j


• .

LAN




•
•
•
•





•





•
•
•
•




                         3.12

-------
EPA System Design & Development
Guidance:  Volume C
                      EXHmiT 3-6
    AGENCY-SUPPORTED HARDWARE AND SOFTWARE
                    (CONTINUED)

TOOLS
TARGET HARDWARE ENVIRONMENT
IBM
3090
IBM
43XX
DEC/
VAX
PRIME
MS
DOS
Mac-
intosh
LAN
Telecom Capabilities (Coot.):
PRIMELINK
NATURAL/CONNECTION
SAS/RLINK RTERM
3270 PC FILE TRANSFER (INDSFILE)
ARBITER
BULK DATA TRANSFER (EOT)
DATA TRANSFER FACILTTY (DTF)
NOVELL NETWARE
Electronic Mail;
DIALCOM SERVICE
LOCAL CAPABILITIES









•

I*mtrrninin«Mr P
-------

-------
                                   Chapter Four
               SYSTEM DESIGN, DEVELOPMENT, AND
                     IMPLEMENTATION OVERVIEW
       This chapter addresses the third phase of the system development life cycle -r the System
 Design, Development and Implementation phase and provides amplifying details on the three
 stages which comprise this phase:

       »  System Design Stage» which comprises tasks and activities associated with System
          Detailed Requirements Analysis; Preliminary Design and Detailed Design;

       •  System Development Stage • which comprises tasks and activities associated with
         . System Production and Programming and System Integration, Test and Evaluation; and

       •  System Implementation Stage - which comprises tasks and activities associated with
          System Installation.

 For each stage, this chapter presents the associated tasks and activities that must be accomplished
 under each task. During each task, EEI documentation is prepared or revised. Also, indicated is
 the status of EEI documentation that is affected during the task, Le., preliminary, update, final.  At
 the completion of each task, a review involving OIRM/SIRMO representation is accomplished.
 Successful completion of the review establishes a baseline which becomes the foundation for
 continued development under subsequent tasks. Exhibit 4-1, on the following page, overviews the
 process.

      EEI documentation requirements  during the System Design, Development and
 Implementation phase are discussed generally in this chapter. Detailed representative outlines for
 each EEI (numbers 4 through 13) are contained in Appendix A.  EEIs 1 through 3 were detailed
 previously in Volumes A and B.

 4.1   SYSTEM DESIGN STAGE

      Associated tasks and activities include System Detailed Requirements Analysis, Preliminary
Design and Detailed Design.
                                      4*1

-------
EPA System Design & Develop meat
Guidance:  Volume C
                           Exhibit 4-1
                   EEI DOCUMENTATION






o
3
3
I
3
i


i

*
I

SYSTEM DESIGN, DEVELOPMENT AND IMPLEMENTATION
System Design
System
Detailed
Requirements
Analysis
EEI-4
EEI-5
EEI-6


System
Require-
ments
Review

Functional
Baseline

Preliminary
Design


EEI-7
EEI-8



Pre-
liminary
Design
Review

Pre-
liminary
Design
Baseline
Detailed
Design


EEI-8




Critical
Design
Review


Design
Baseline

System Development
System
, Production
and
Programming
EEI-9
EEMO
EEM1


Develop*
mentTest
And
Evaluation
Review
Product
Baseline

System
Integration,
Test and
Evaluation
EEM2




Opera-
tional Test
And Eval-
uation •
Review
Opera-
tional
Baseline

System Implementation
System
Installation







User
Accept-
ance




System
Operation* and
Maintenance ,













                              4-2

-------
 EPA System Design & Development
 Guidance:   Volume C
 4.1.1  System Pe,TflJIc4 Requirements Analysis

       The major inputs to this task are the:  ,

       •   Mission Needs Statement document produced during the Mission Needs Analysis
           phase - defined in Volume A

       •   Preliminary Design and Options Analysis Document and Project Management Plan
           produced during  the Preliminary Design and Options Analysis phase - defined in
           Volume B.

       These documents are used in performing the detailed requirements analysis for the software
system. The conclusions of these documents are confirmed by the software development staff that
will ultimately produce the software system.

       This task entails further  analysis of the problem, the definition of the functional
components of the  major software and hardware elements of the  system and association of
functional components to requirements. The scope of the software development project is revised,
if necessary, and further defined.

4.1.1.1        Activities

       The activities associated with the System Detailed Requirements Analysis are:

       •   Confirm the analysis of current systems that  have  been reviewed and their
          adequacy/inadequacy for use in solving the problem

       •   Confirm the alternative solutions that have been proposed and ensure that the selected
          alternative is the one that should be used

       •   Prepare die System Implementation Plan (EEI-4)

          •  Identify events, actions and milestones
          •  Identify resource requirements
          -  Review schedules and work plans
          -  Produce integrated project plan

                                          4-3

-------
 EPA  System  Design & Development
 Guidance:  Volume C
       *  Prepare the System Detailed Requirements Document (EEI-5)

          •  Define major system functions
          •  Define physical requirements
          -  Define security requirements
          -  Define quality requirements  -
          -  Define life cycle resource requirements      -.
          •  Define testing and verification requirements
          -  Define project work schedule(s) and work plan(s)
                                 x
       •  Prepare the Software Management Plan (EEI-6)

          •  Identify project resources
          -  Define review responsibilities
          •  Identify organizational structure and required resources
          -  Establish project schedules, reviews and reporting controls
             Implement risk management
          -  Implement software product assurance procedures
          -  Implement software development procedures for the project

       While defining the System Detailed Requirements, a separate data dictionary document
should be prepared that lists and describes each data element to be referenced by the system.
Additional guidance on the content of the Data Dictionary Document is provided in OIRM's
Operations and Maintenance Manual.
4.1.1.2
Documentation
      Documentation associated with the System Detailed Requirements Analysis includes;
         System Implementation Plan
         System Detailed Requirements
         Document
         Software Management Plan
                                EEI-4 (Final)

                                EEI-5 (Preliminary)
                                EEI-6 (Preliminary)
                                       4-4

-------
 EPA System  Design & Development
 Guidance:  Volume C
4.1.1.3      System Requirements Review

       The System Requirements Review is performed to ensure the adequacy of the system
requirements and approve formally the definition of the user's requirements. The System Detailed
Requirements Document is the primary subject of the review. The Software Management Plan and
the System Implementation Plan are also input to the review process.

       The System Requirements Review takes place at the end of the System Detailed
Requirements Analysis task.  A successful  System Requirements Review  results in the
establishment of the Functional Baseline.  OIRM/SIRMO representatives should participate in the
System Requirements Review.

4.1.1.4      Functional Baseline

       The Functional Baseline is established as the original baseline configuration and consists of
the functional system specifications contained in the System Detailed Requirements Document
(EEI-5).  Once the System Detailed Requirements Document is basetined, any changes to that
document represent a change in the scope of the project and must have management approval. The
Functional Baseline is established after a successful System Requirements Review.
4.1.2   Preliminary Design

       The Preliminary Design task represents the initial effort in producing a design that can be
used in developing an operational software product
                                                            v

4.1.2.1        Activities

       The activities associated with Preliminary Design are:

       •   Confirm that candidate packages/existing software can be used or integrated into the
          new system

       •   Prepare Software Design Document (EEI-8) .         .  •  •    .

          -   Identify each software design requirement

                                         4-5

-------
EPA System Design &  Development
Guidance:   Volume C
          -   Identify the functional flow of the system, address each design requirement and
             describe each requirement and associated software design functions (SDFs)

          •   Detail each SDF by defining:                                           _

             -  Inputs
             —  Local Data
             -  Initiation, Timing and Sequencing
             —  Interrupts
             -  Processing
             ..  Outputs
             —  Adaptation

          -   Define Data Base and File Structures

             --  Data Base Management System
             --  Logical Design of the Data Structures                             /
             —  Data Interrelationships
             --  Characteristic/Requirements Traceability

          Update Software Management Plan (EH-6)

          Prepare preliminary Software Test and Acceptance Plan (EEI-7)

          -   Software Unit Test Plans

             -  Test Requirements
             —  Test Management
             -  Test Schedule
             --  Tests and Results

          •   Integration Testing of Software Units, Modules and Software Functions - Test
             Plans

             -  Integration Test Requirements

                                        4-6

-------
EPA System Design & Development
Guidance:   Volume C
             —  Integration Test Management
             --  Integration Test Categories
             -  Integration Test Methods
             —  Integration Test Schedules
             --  Integration Tests and Results

         -   Required Resources for Unit and Integration Testing

             —  Facilities
             —  Hardware Environment           v
             -  Interface/Support Software
             —  Personnel

         -   System Test Plans

             ~  System Test Requirements
             --  System Test Management
            —  System Test Categories
             --  System Test Methods
             —  System Test Schedules
             -  System Tests and Results

         -   User Acceptance Test Plans

             -  Test Team
            .—  Pretest Procedures
             —  Acceptance Test Procedures
             —  Formal Acceptance

     •   Address:

         -   Initial design of user procedures

         -   Conversion software and appropriate procedures

         *   Operations procedures.

                                        4.7

-------
 EPA System Design  &  Development
 Guidance:  Volume C
 4.1.2.2
       Documentation associated with the Preliminary Design task includes:
       •  Software Management Plan
       •  Software Test and
              Acceptance Plan
       •  Software Design Document
 4.1.2.3
Preliminary Design Review
                                EEI-6" (Update)

                                EEI-7 (Preliminary)
                                EEI-8 (Final)
       The Preliminary Design Review is performed for each system element to ensure the
adequacy of the preliminary design and the test plans for verifying the accuracy of the software
system.  The Software Design Document and the Software Test and Acceptance Plan are the
primary subject of the review. The updated Software Management Plan is also input to the review
process.

       The purpose of the Preliminary Design Review is to:

       •   Evaluate the progress, technical adequacy and risk resolution (on a technical, cost and
          schedule basis) of the selected design approach

       *   Determine the compatibility of the selected design approach with the requirements and
          performance of the System Detailed Requirements Document

       *   Establish the existence and compatibility of the physical and functional interfaces
          among the other elements (equipment, facilities, computer programs and personnel)

       *   Determine the adequacy of the test plans in accurately verifying the software system
          against the design criteria.

       The Preliminary Design Review takes place at the end of the Preliminary Design task. A
successful Preliminary Design Review results in the establishment of the Preliminary Design
Baseline.  OIRM/SIRMO representatives should participate in  the Preliminary Design Review.
                                         4-t


-------
 EPA System Design & Development
 Guidance:   Volume C
 4.1.2.4       Preliminary Design Baseline

       The Preliminary, Design Baseline is established after a successful Preliminary Design
 Review. It consists of the initial design specifications - including data base specifications. The
 Preliminary Design Baseline is made up of the Software Design Document (EEI-8) and the
 Software Test and Acceptance Plan (EEI-7). Once these documents are baselined, any changes to
 those documents represent a change -in the scope of the project and must have management
 approval.

 4.1.3  Detailed Design

       The Detailed Design task represents the final effort in producing a detailed design that will
 be used in developing an operational software product The Software Design Document is updated
 with detailed design specifications. The additional  detail is added to produce a detailed design
 adequate for code production. The first draft of the Software User's  Reference Guide should be
 prepared. The Software Management Plan and Software Test and Acceptance Plan are updated as
 necessary. The Project Management Plan and Benefit-Cost Analysis should be updated during this
 task.

4.1.3.1        Activities
                                 s_
       The activities associated with Detailed Design include:

       •   Update Software Design Document (EEI-8)

          -  Update/refine design information

          -  Decompose each Software Design Function

             -  Software Unit Formal Parameters
             -  Software Unit Inputs                             .
             -  Software Unit Local Data
             -  Software Unit Processing
             -  Software Unit Outputs
             -  Software Unit Limitations
             —  Use of other software elements

                                         4-9

-------
 EPA System  Design & Development
 Guidance:  Volume C
           •  Data Base Physical Design

              - File
              - Record
              - Field
              - Item                    -  \    •

       •   Prepare initial draft of the Software User's Reference Guide (EEI-11) with at least
           sections one through three completed and a detailed outline of the remainder of the
           document

           -   Description of the system
           -   System access techniques
           -   User analysis/reporting options
           -   Data entry and update process
           •   User support and training program/sources
           -   Security requirements

       *   Update the Preliminary Design and Options Analysis (EEI-2) with revised benefit-cost
           analysis

       •   Update Program Management Plan (EEI-3)

       *   Update Software Management Plan (EEI-6)

       •   Update Software Test and Acceptance Plan (EEI-7).

4.1.3.2       Documentation

       Documentation associated with the Detailed Design includes:

       *   Preliminary Design and Options
          Analysis                             EEI-2 (Update)
       *   Project Management Plan              EEI-3 (Update)
       •   Software Management Plan            EEI-6 (Update)

                                         4-10

-------
 EPA System Design &  Development
 Guidance:   Volume C
           Software Test and
              Acceptance Plan
           Software Design Document
           Software User's
              Reference Guide
                                 EEI-7 (Final)
                                 EEI-8 (Final)

                                 EEM1 (Preliminary)
 4.1.3.3
Critical Design Review
       The Critical Design Review is conducted for each system element when the detailed design
 is complete.  The updated Software Design Document and the* updated Software Test and
 Acceptance Plan are the primary subject of the review.  The Software Management Plan and the
 Software User's Reference Guide are also input to the review as necessary. The purpose is to
 accomplish the following:

       *  Determine that the detailed design of the software system element under review satisfies
          the performance requirements of the System Detailed Requirements Document

       *  Establish compatibility among system elements in the detailed design
       *  Assess the productivity and risk areas (on a technical, cost and schedule basis).
       •  Review the preliminary product specifications.

 A successful Critical Design Review establishes or  updates the Design Baseline. The Design
 Baseline is then  used  as the basis for  the production and coding of the software system.
 OIRM/SIRMO representatives should participate in the Critical Design Review.
4.1.3.4
Design Baseline
       The Design Baseline is established after a successful Critical Design Review. It consists of
the final design specifications - including data base specifications and the test plans associated
with the software product The Detailed Design Baseline is made up of the Software Design
Document  (EEI-8) and the final Software Test and Acceptance Plan (EEI-7).  Once these
documents  are baselined, any changes to the documents represent a change in the scope of the
project and must have management approval
                                        4-11

-------
 EPA System Design &  Development
 Guidance:   Volume C

 4.2    SYSTEM DEVELOPMENT STAGE
                                                                                              \
       Associated tasks include System Production and Programming, and System Integration,
 Test and Evaluation.
                                            i
 4.2.1   System Production and Programming

       The specifications developed during the System Design stage are used to develop a system
 that functions correctly in a controlled environment At the completion of the System Production
 and Programming task, all programs, job streams, data bases, security controls, user procedures
 and operations procedures will have been developed and thoroughly tested by the development
 team.

4.2.1.1      Activities

       The activities associated with System Production and Programming are:

       •   Develop Software System

          -   Code software units
          -   Review software unit code
          -   Unit test software unit code  '                             •            •
          -   Produce unit test reports
             Perform subsystem integration testing
          -   Prepare subsystem integration test reports

      •   Prepare Software Maintenance Document (EEI-9)

          •   Maintenance Procedures including:

            -   Source Code Standards                   <
            -   Documentation Update Procedures
            -   Coding and Review Process
            -   Change Control Process
            —   Testing Standards and Procedures
            —   Change Implementation Methods

                                       4-11

-------
EPA System Design  & Development
Guidance:  Volume C
             Maintenance Tools

             -  Technical tools
             -.  Management tools

             Source code      •
            .. Source listings or equivalent
         Prepare Software Operations Document (EEI- 10)
            System Initialization
            System Restart by Functional Element
            System Manager functions
         -   System Backup/Recovery Provisions and other Information Security Provisions
                  /
         Update Software User's Reference Guide (EEM1).
4.2.1.2
            Documentation
     Documentation associated with the System Production and Programming task includes:
     •  Software Maintenance Document
     •  Software Operations Document
     •  Software User's Reference
           Guide
     *  Unit Tested Source Code
     •  Unit Test Data.
                                               1-9 (Preliminary)
                                               MO (Preliminary)

                                               I-11 (Update)
                                      4-13

-------
 EPA System Design  &  Development
 Guidance:   Volume C
 4.2.1.3
Svstem Production and Programming Reviews
       Preliminary Functional Configuration and Physical Configuration reviews are performed as
 each piece of software is delivered for inclusion into the product baseline. They confirm that the
 software product or component of the software product performs according to the requirements
 and design specifications that have been prepared and  baselined during System Design.  The
 results of the review are Input to the Development Test and Evaluation Review.

       The Development Test and Evaluation Review ensures that the developmental testing of the
 software is successful and that the system requirements are satisfied. The Software Maintenance
 Document, the Software Operations Document, the  updated User's Guide, the results of the
 Functional Configuration Review and the results of the Physical Configuration Review are also
 reviewed for completeness and accuracy.  Upon completion of a successful review, these
 documents are placed in the Product Baseline.

       The Development Test and Evaluation Review  is performed at the end of the System
 Production and Programming task.  A successful Development Test and Evaluation Review
 establishes or updates the Product Baseline. OIRM/SIRMO representatives should participate in
 the Development Test and Evaluation Review.
 4.2.1.4
Product Baseline
       The Product Baseline establishes a tested, operable version of the software system in its
operating environment. As each subsystem is successfully tested, the product baseline is updated.
The baseline of the completed and tested version of the software product ensures that any changes
or enhancements take place against a stable, controlled set of functional and technical components.
The Product Baseline will include the completed product specifications, the operation/maintenance
documents and the user's guide.

       The Product Baseline is established/updated after a successful Development Test and
Evaluation Review at the end of the System'Production and Programming task.

4.2.2  Svstem Integration. Test and Evaluation     *
       The System Integration, Test and Evaluation task includes the testing of the fully integrated
software product in its operational environment  This task is performed by a test team that does
                                         4-14

-------
 EPA System  Design & Development
 Guidance:  Volume C
 not include any of the software development team members. The purpose is -to provide a test and
 evaluation environment that is independent of the development effort

       The Software Maintenance Document, the Software Operations Document and the Software
 User's Reference Guide are updated as necessary based on the testing process. The software
 product and its related documents may have to be sent back to the development team if rework is
 required based on the results of system integration testing.
                                         t
 4.2.2.1       Activities                                    .

       The activities associated with the System Integration, Test and Evaluation task are:

       •   Install the working system using the installation procedures

       *   Execute the System Test portion of the Software Test and Acceptance Plan

       *   Document any discrepancies noted during testing for resolution with the development
          team and user

       •   Verify that discrepancies that require software modification have been modified
          correctly                          .

       •   Prepare System Integration Test Report (EEI-12)

       •   Recommend disposition of the software and documentation

       *   Update Software Maintenance Document (EEI-9), Software Operations Document
          (EEMO), and Software User's Reference Guide (EEI-11).

4.2.2.2      Documentation

       Documentation associated with the System Integration, Test and Evaluation task includes:

       •   Software Maintenance Document       EEI-9 (Update)
       •   Software Operations Document         EEMO  (Update)
                                        4-15

-------
 EPA System Design &  Development
 Guidance:   Volume C
        *   Software User's Reference
              Guide                           EEI-11 (Update)
        •   System Integration Test Reports        EEI-12 (Final)
        •   System Integration Tested Software
        *   System Integration Test Data •

 4.2.2.3      System Integration. Test and Evaluation R$y|evyy
                                                     •»
        The final Functional Configuration and the Physical Configuration reviews are performed
 when all the subsystems are delivered and integrated into the Product Baseline. They confirm that
 the software product or component of the software product performs according to the requirements
 and design specifications baselined in the Product Baseline. The results of the review are input to
 the Operational Test and Evaluation Review.

       The Operational Test and Evaluation Review ensures that the software system is viable in
                     _/
 its intended environment. The Operational Test and Evaluation Review is performed at the end of
 the System Integration, Test and Evaluation task.

       The Software Maintenance Document, Software Operations Document and the User's
 Guide are the major inputs to the review. The System Integration Test Reports drive the review in
 that they contain the results of testing  the software product All errors or incidents that were
 encountered during formal testing are identified.  The resolution of each incident is noted. Those
 incidents that were  determined to be errors are presented in two categories — corrected and
 unresolved. This information is used in determining if the software product is ready for formal
 use. A successful Operational Test and Evaluation Review establishes or updates the Operational
 Baseline. OIRM/SIRMO representatives should participate in the Operational Test and Evaluation
 Review..                                               •

4.2.2.4       Operational Baseline.
                                    i                                                *
      The Operational Baseline represents the completely implemented and tested software
system.  It is the basis for future maintenance changes and enhancements. All documentation is
modified as required, validation and system testing is completed and the system is placed in
production and/or turned over to the user. The Operational Baseline is established and/or updated
                                                            t
after a successful Operational Test and Evaluation Review.
                                        4-16

-------
 EPA System  Design  & Development
 Guidance:  Volume C

 4.3    SYSTEM IMPLEMENTATION STAGE

        This stage comprises System Installation and System Operations and Maintenance.

 4.3.1  System Installation

        The System Installation task is primarily for formal user acceptance of the software
 product. The software product is installed in a production environment, and the user exercises the
 product to determine if it meets his/her needs and requirements.

 4.3.1.1       Activities

       The activities associated with System Installation are:

       •   Install the software product in a production environment

       •   Complete user acceptance of the software product in accordance with Software Test and
           Acceptance Plan (EEI-7)

       *   Train users.

4.3.1.2       Documentation

       The major milestones associated with System Installation are:

       •  Operational software installed
       •  Training completed
       *  User agreement to accept the software and documentation.

In addition, the final version of the following system documentation is delivered:

       •   System Detailed Requirements          EEI-5 (Final)
             Document
       •   Software Management Plan            EEI-6 (Final)
       •   Software Design Document            EEI-8 (Final)
       •   Software Maintenance Document        EEI-9 (Final)

                                         4.17

-------
 EPA  System  Design .& Development
 Guidance:  Volume C
4.3.1.3
Software Operations Document
Software User's Reference Guide
System Integration Test Reports

   System Implementation Review
                                                I-10 (Final)
                                                Ml (Final)
                                                1-12 (Final)
       The System Implementation Review ensures the new system has been accepted by its users
and is ready to begin full operation.  During the implementation stage, problems, users likes and
dislikes, in addition to possible enhancements are identified. The procedures for addressing these
concerns are reviewed and software is enhanced following system operations and maintenance
procedures.

4.3.2  Systenfl Operations and Maintenance

       Procedures for the operating and maintaining fully installed systems are important in
ensuring that the system continues to operate effectively throughout its life cycle and that
obsolescence is declared when the system no longer fulfills the requirement. Procedures for.
operating and maintaining an existing system are contained in OIRM's Operations and Maintenance
Manual.  This manual has been created as the follow-on guidance for EPA's System Design and
Development Guidance. The manual will assist system managers in developing proper operating
procedures, defining staff responsibilities, documenting system requirements, designing follow-on
training programs and performing configuration management The Operations and Maintenance
Manual should be followed to ensure the resources dedicated to the system after implementation,
will be  used in the most efficient and effective manner.
                                        4-18

-------
 EPA System Design  & Development
 Guidance:   Volume C
                                    Chapter Five
                                   SUMMARY
 5.1   SYSTEM DESIGN. DEVELOPMENT AND IMPLEMENTATION OUTPUTS,

       The outputs, documents and results of  the  System Design, Development and
 Implementation process are as follows:
                                          *
       •  EEI-4, System Implementation Plan*
       •  EEI-5, System Detailed Requirements Document
       •  EEI-6, Software Management Plan*
       •  EEI-7. Software Test and Acceptance Plan*
       •  EEI-8, Software Design Document*
       •  EEI-9, Software Maintenance Document
       *  EEI-10, Software Operations Document
       •  EEI-11. Software User's Reference Guide
       *  EEI-12, System Integration Test Reports*
                              ;
       *   Working, tested and user accepted automated or partially automated solution to the
          problem
    \

       •   Established Configuration Management or change control procedures

* Note: These EEI requirements are the basic requirements for User Owned Systems that DO NOT
involve OIRM.

5.2   NEXT STEPS

      After the user has accepted the application system it begins the transition to the operation
and maintenance phase of the system life cycle. The application specific guidelines for conducting
this phase are outlined in the Software Maintenance Document (EEI-9), which is required for all
systems. Guidance concerning the maintenance and operation phase of the software life cycle is
contained in OIRM's Operations and Maintenance Manual
                                       5-1

-------

-------
 EPA System Design & Development
 Guidance:  Volume C
                                   APPENDIX A
              ESSENTIAL ELEMENTS OF INFORMATION
       This appendix provides representative outlines of each of the system-level documents that
 will be developed during the system design, development and implementation phase.

 A.I   INTRODUCTION
                                           L
       The documentation requirements contained in this appendix apply to  all software
 development projects, regardless of size, complexity or origin — except as noted in subsection
 1.6, "Determining Documentation Requirements" in Chapter 1 of this Volume. At a minimum,
 these standards apply to all new software development projects. Maintenance and/or enhancements
 to existing information systems must comply with the requirements set but in Chapter 1, section
 1.5 of Volume C, System Design, Development and Implementation.

       Compliance with the standards and conventions provided in this appendix will ensure thaj
 adequate documentation is produced for all system development projects.

       The documents defined in this appendix are:

       EEI-4 • • System Implementation Plan
       EEI-5 • • System Detailed Requirements Document
      EEI-6 •• Software Management Plan
      EEI-7 • • Software Test and Acceptance Plan
      EEI-8 • • Software Design Document
      EEI-9 • • Software Maintenance Document
      EEI-10 •• Software Operations Document
      EEI-11 • • Software User's Reference Guide
      EEI-12 • • System Integration Test Reports

      When an asterisk or alphanumeric appears  within  a section number in the outlines, it
represents a repetition of the element as many times as necessary to define multiple iterations of the
element
                                       A.I

-------
EPA System  Design  & Develop meat
Guidance:  Volume C
       The following milestone chart illustrates the relative initiation and completion ot each
document with respect to the software development life cycle, its major phases, and the span and
scope of Volumes A, B, and C.
                                       A-2

-------
EPA System Design & Development
Guidance:  Volume C
          DOCUMENTATION VERSUS LIFE CYCLE

            u i
            Ii
            £.
            Si
           PI
           t w C
           OQ K


           if!
           73 B S

                                     1
                             r
           n
      I-
      3
      2,

I-
c 5
o bJ
8
i
           w«

           S
,>.

                   E I*1??
          !°
      -
      B3

      P
                     tJUCd
bib)

bl

                            A-3

-------
 EPA System Design & Development
 Guidance:   Volume. C
                                     EH-4
                  SYSTEM IMPLEMENTATION PLAN
 1.     INTRODUCTION

       1.1   Purpose
       1.2   Background
       1.3   Scope
       1.4   System References
       1.5   Tenns and Abbreviations
       1.6   Organization of This Document             '



      2.1   Government Documents
      2.2   Non-government Documents

3.    IMPLEMENTATION PLAN

      3.1   Plan Management

            3.1.1  Policy Events and Actions
            3.1.2  Program Management
            3.1.3  Strategy for Acquiring Information/Data

                  3.1.3.1      Information Collection
                  3.1.3.2      Forms
                  3.1.3.3      Clearance

            3.1.4  Strategy for Integrating with other EPA Information
                              Envii
                            italData
       3.1.4.1               	
       3.1.4.2       Administrative Data

3.1.5  Access Policy and Standards

3.1.6  Assessment of Existing Hardware/Software Alternatives

       3.1.6.1      EPA
       3.1.6.2      Other Government Agencies
       3.1.6.3      Commercial Vendors

3.1.7 ,  Information Systems
                 3.1.7.1
                 3.1.7.2
                  Automated
                  Manual
     3.2
3.1.8  Process and Procedure

Work Plans and Schedules
                                    A-4

-------
 EPA System Design & Development
 Guidance:   Volume C
                SYSTEM IMPLEMENTATION PLAN
                               (Continued)
4.
5.
6.
3.3   Resource Requirements
      3.3.1 Contractor
      3.3.2 Personnel
      3.3.3 Facilities   -
      3.3.4 Government Furnished Property
3.4   Integrated Project Plan
NOTES
APPENDICES
GLOSSARY
                                  A-5

-------
EPA System Design &  Development
Guidance:   Volume C
                                      1-5
        SYSTEM DETAILED REQUIREMENTS  DOCUMENT
      INTRODUCTION

      1.1   Purpose
      1.2   Background
      1.3   Scope
      1.4   System References
      1.5   Tenns and Abbreviations
      1.6   Organization of This Document

      REFERENCED DOCUMENTS

      2.1   Government Documents
      2.2   Non-government Documents

      DETAILED CHARACTERISTICS AND REQUIREMENTS

      3.1   System Definition Requirements
     3.
     3.
 .1.1
 .1.2
3.1.3
3.1.4
3.1.5
3.1.6

3.2
System Purpose
Concept of Operation
System Sizing and Timing Requirements
Design Standards
Design Constraints
Data Requirements

Subsystem Definition Requirements

3.2.1  Subsystem #1
                 3.2.1.1
                 3.2.1.2
                       Subsystem #1 Purpose/Definition
                       Subsystem #1 Interface Definition
                             3.2.1.2.1
                             3.2.1.2.2
                             3.2.1.2.3
                             3.2.1.2.4
                                   Network
                                   Software Systems
                                   DataBase
                                   Entity Relationships
                 3.2.1.3
                 3.2.1.4
                       Assumptions and Constraints
                       Subsystem #1 Level II Requirement 1

                       3.2.1.4.1     Level n Requirement 1 Description

                                   3.2.1.4.1.1  Level m Detailed Functional
                                              Requirement
                                    A-6

-------
EPA  System  Design &  Development
Guidance:  Volume C


                                     EH-5
        SYSTEM DETAILED  REQUIREMENTS DOCUMENT
                                   (Continued)


                                                       3.2,1.4.1.1.1 Titleand
                                                                   Description Of
                                                                   Level m
                                                                   Function 1

                                                       3.2.1.4.1.1.* Titleand
                                                                   Description Of
                                                                   Level m
                                                                   Function *

                                          3.2.1.4.1.*   Level in Requirement *
                                                      Description

                              3.2.1.4.*     Level n Requirement * Description

           3.2.* Subsystem*

     3.3   System Physical Requirements

           3.3.1  HVAC and Electrical Requirements
           3.3.2  Facilities Management  .•
           3.3.3  Computer Hardware Requirements
           3.3.4  Computer Operating System Requirements
           3.3.5  Software Utilities and Tools

     3.4    System Security Requirements

           3.4.1  System Backup Procedures
           3.4.2  Review/Activity Log Files
           3.4.3  Disaster Recovery Procedures

    3.5    Quality Requirements

           3.5.1   Reliability
           3.5.2   Maintainability
           3.5.3   Flexibility and Expansion
           3.5.4   Transportability

    3.6   Life Cycle Requirements

          3.6.1   Software Maintenance Personnel
          3.6.2   User Support and Training
          3.6.3   Hardware and Supplies
                                    A-7


-------
EPA  System  Design & Development
Guidance:  Volume C
                                   1-5
       SYSTEM  DETAILED REQUIREMENTS DOCUMENT
                               (Continued)
4 .     Testing and Verification Requirements
      4. 1   Testing Requirements
           4.1.1 Method
           4.1.2 Responsibility
5 .     Project Schedules and Work Plans
      5.1   Schedules
      5.2   Work Plan
           5.2.1 Personnel
           5.2.2 Milestones
           5.2.3 Budget
6.     NOTES
7.     APPENDICES
>
8.     GLOSSARY

-------
 EPA System  Design &  Development
 Guidance:  Volume C
 2.
                   SOFTWARE MANAGEMENT PLAN
 1.     INTRODUCTION

       1.1    Purpose.
       1.2    Background
       1.3    Scope
       1.4    System References
       1.5    Terms and Abbreviations
       1.6    Organization of This Document
       2.1    Government Documents
       2.2    Non-government Documents
 3.     PLANNING

       3.1    Project Resources

             3.1.1  Contractor Facilities
             3.1.2  Government Furnished Equipment, Software and Services
             3.1.3  Personnel
             3.1.4  Organizations Responsible for Design, Implementation, Configuration
                   Management, Reliability and Quality Assurance

       3.2    Review Responsibilities
       3.3    Software Development

             3.3.1  Organization Structure
             3.3.2  Personnel
             3.3.3  Resources
             3.3.4  Software Development Tools, Techniques, Methodologies and Standards
             3.3.5  Manual Procedures/Forms

4.    MANAGEMENT CONTROLS

      4.1    Project Schedule, Reviews and Report Controls

             4.1.1 WorkPlan
             4.1.2 Activity Network and Dependencies
             4-t.3 Risk Areas

      4.2    Risk Management

             4.1.1  New Technologies             '
             4.1.2 Backup - Recovery
             4.1.3 Manual Procedures/Forms
                                      A-9

-------
 EPA System  Design &  Development
 Guidance:  Volume C
                   SOFTWARE MANAGEMENT PLAN
                                   (Continued)
 5     SOFTWARE PRODUCT ASSURANCE

       5.1   Software Configuration Management
       5.2   Software Independent Verification and Validation
       5.3   Software Security         •
       5.4   Software Reliability and Quality Control
       5.5   Software Interface Definition
       5.6   Software Waivers to Policy and Procedures

             5.6.1  Permanent Waivers
             5.6.2  Temporary Waivers
             5.6.3  Tools and Standards Waivers

       5.7   Data Administration
       5.8   Quality Assurance

             5.8.1  Program Monitoring
             5.8.2  Quality Reviews
             5.8.3  Reporting and Control
             5.8.4  Reviews

                   5.8.4.1      System Requirements Reviews
                   5.8.4.2      Preliminary Design Review
                   5.8.4.3      Critical Design Review
                   5.8.4.4      Code Reviews
                   5.8.4.5      Development Test and Evaluation Review
                   5.8.4.6      Operational Test and Evaluation Review

      5.9   Testing

            5.9.1   Software Test Plan
            5.9.2   Software Test Description
            5.9.3   Software Test Procedures
            5.9.4  Conducting the Software Test
            5.9.5  Software Test Reports

6.     SOFTWARE DEVELOPMENT PROCEDURES

      6.1   Software Standards and Procedures

            6.1.1  Software Tools
            6.1.2  Commercial and Reusable
                  6.1.2. i      5at^ Righc and Documentation
                  s.i.2.2
Certification
                                     A-10

-------
 EPA System Design &  Development
 Guidance:  Volume C
                  SOFTWARE MANAGEMENT PLAN
                                  (Continued)
            6.1.3 Software Test Tools
            6.1.4 Software Design
                  6.1 4.1
                  6.1.4.2
                  6.1.4.2
                  6.1.4.4
Software Desij
piN
MM
^ VJU CUAUA^UlK ' rftfUJ
Interface Methodo
fcthodology
juage
ogy
Network Methodology
            6.1.5  Software Design and Coding Standards
            6.1.6  Firmware
      6.2   Software Configuration Management
            6.2.1  Configuration Identification
                  6.2.1.1      Documentation Baselines
                  6.2.1.2      Methods and Approach to Standards Implementation
            6.2.2  Configuration Control
                  6.2.2.1      Configuration Control Flow Diagram
                  6.2.2.2      Forms
                  6.2.2.3      Storage and Release of Master Copies
            6.2.3  Configuration Reviews
7.    NOTES
8.    APPENDICES
9.    GLOSSARY
                                     A-ll

-------
EPA  System Design & Development
Guidance:  Volume C
                                        1-7
            SOFTWARE TEST AND ACCEPTANCE  PLAN
      INTRODUCTION

      1.1    Purpose
      1.2    Background
      1.3    Scope
      1.4    System References
      l.S    Terms and Abbreviations
      1.6    Organization of This Document
      2.1    Government Documents
      2.2    Non-government Documents

      UMTTATIONS/TRACEABILrrY
      3.1
      3.2
 Limitations
 Traceability
     TEST PLANS

     4.1    Software Unit Testing (includes Manual Procedures)
     4.2
            4.1.1
            4.1.2
       Test Requirements
       Test Management
           4.1.3
           4.1.4
       4.1.2.1
       4.1.2.2
       4.1.2.3
       4.1.2.4
       4.1.2.5
       4.1.2.6
       4.1.2.7
       4.1.2.8
       4.1.2.9

       Test Schedule
       Test Results
                              Integration Test Team
                              Responsibilities of Other
                              Product Control
                              Test Control
                              Evaluation and Retest Criteria
                              Test Reporting
                              Test Review
                              Test Identification
                              TestData Environment
ization and Responsibility
 luxations
Integration Testing of Software Units, Modules and Software Functions/Risk
Management

4.2.1  Integration Test Requirements
4.2.2  Integration Test Management
4.2.3  Integration Test Categories
4.2.4  Integration Test Methods
4.2.5  Integration Test Schedules
4.2.6  Integration Test Results
                                     A-12

-------
 EPA System  Design & Development
 Guidance:  Volume C

             SOFTWARE TEST AND ACCEPTANCE PLAN
                                    (Continued)

                   4.2.6.*       (Insert Name) Integration Test
       4.3   Required Resources
             4.3.1  Facilities
             4.3.2  Hardware
             4.3.3  Interface/Support Software                 '
             4.3.4  Personnel
       4.4   System Test                               .
             4.4.1  System Test Requirements
             4.4.2  System Test Management
             4.4.3  System Test Categories
             4.4.4  System Test Methods
             4.4.5  System Test Schedules
             4.4.6  System Test Results
 5.     USER ACCEPTANCE
       5.1    Test Team
       5.2    Pretest Preparations
             5.2.1  Development of Test Scenarios and Test Data
             5.2.2  Development of Predicted Results
             5.2.3  Development of Acceptance Procedures
       5.3    Test Execution
             5.3.1  Data Analysis
             5.3.2  Test Evaluation
             5.3.3  Problem Report and Problem Resolution Process
       5.4    Formal Acceptance
             5.4.1   Test Report
                   5.4.1.1       Detailed Test History
                   5.4.1.2       Detailed Test Results
                               5.4.1.2.*    (Insert Test Name) Test Results
6.     NOTES
7.     APPENDICES
8.     GLOSSARY
                                      A-13

-------
 EPA System  Design  & Development
 Guidance:  Volume C
                                        1-8
                   SOFTWARE DESIGN DOCUMENT
4.
       INTRODUCTION

       1.1    Purpose
       1.2    Background
       1.3    Scope
       1.4    System References
       1.5    Terms and Abbreviations
       1.6    Organization of This Document
       2.1
       2.2
       Government Documents
       Non-government Documents
SOFTWARE DESIGN REQUIREMENTS (SDR)
                                                         \
3.1   Concepts
3.2   Functional Flow
3.n   (Insert Name) Requirement

      3.*.1  Description of Requirements and Associated Software Design Functions
            (SDFs), including Manual Procedures

SOFTWARE DESIGN FUNCTION (SDF)

4.*   (Insert Name) Function

      4.*.1  Inputs
      4.*.2  Local Data
      4. *.3  Initiation, Timing and Sequencing
      4.*.4  Interrupts
      4.*.5  Processing
                 4.*.5.1
                 4.*.5.2
                 4,*.5.3

           4.*.6 Outputs
           4.*.7 Adaption
                        Algorithms
                        Error Handling
                        Test Structures
     Software Function Requirements (SFR)

     5.1   SFR External Interfaces (including Manual Procedures)

           5.1.*  (Insert Name) Interfacer

                 5.1.*.*      (Insert Name) Software Unit (SU)
                                    A.14

-------
  EPA System Design &  Development
  Guidance:  Volume C
                                        EEI-8
                     SOFTWARE  DESIGN DOCUMENT
                                     (Continued)
        Detail Design

        6.*    (Insert Name) SFR

              6.*.1  SFR Inputs
              6.*.2  SFR Local Data
              6.*.3  SFR Processing
                    6.*.3.1
                    6.*.3.2
                    6.*.3.3
                    6.*.3.4
                    6.*.3.5
                    6.*.3.6
                    Control
                    Algorithms
                    Error Handling
                    Data Conversion
                    Test Structure
                    Manual Procedures
             6.*.4
             6.*.5
       SFR Outputs
       SFR Decomposition
                    6A5.1
                   (Insert Name) Software Unit (SU)
                                6.*.5.*.1
                                6.*.5.*.2
                                6.*.5.*.3
                                6.*.5.*.4
                                6.*.5.*.5
                                6.*.5.*.6
                                6.*.5.*.7
                                6.*.5.*.8
                                SU Formal Parameters
                                SU Inputs
                                SU Local Data
                                SU Processing
                                SU Outputs
                                SU Limitations  ,
                                Use of Other Elements
                                Manual Procedures
7.     Data Base Design (If Applicable)
       7.1
       7.2
       7.3
       7.4
       7.5
Data Base Management System
Data Structure (Logical Design)1
Interrelationships
Design Characteristic/Requirements Traceability
Physical Design2

7.5.*  File (Insert Name)

      7.5.*.*      Record (Insert Name)
1  For ADAS AS refer to EPA/NCC ADAS AS Application Development Procedures Manual for CDBA
   requirements

2  For ADABAS refer to EPA/NCC ADAB AS Application Development Procedures Manual for CDBA
   requirements

                                       A-15

-------
 EPA System Design & Development
 Guidance:  Volume C
                                 1-8
                SOFTWARE DESIGN DOCUMENT
                             (Continued)


                         7.5.*.*.*    Field (Insert Name)

                                    7.5.*.*.*.*   Item (Insert Name)
8.    NOTES

9.    APPENDICES

10.   GLOSSARY
                              A-U

-------
EPA  System Design St  Development
Guidance:  Volume C
             SOFTWARE MAINTENANCE DOCUMENT
      INTRODUCTION
                       i
      1.1   Purpose
      1.2   Background
      1.3   Scope
      1.4   System References  .
      1.5   Terms and Abbreviations
      1.6   Organization of This Document
     2.1   Government Documents
     2.2   Non-government Documents

     MAINTENANCE PROCEDURES

     3.1   Source Code Standards
     3.2   Documentation Update (including non-software elements)
     3.3   Coding and Review Process

           3.3.1  Top Down Approach
           3.3.2  Peer Review
           3.3.3  Walkthrough
           3.3.4  Team Leader Review

     3.4   Change Control Process

           3.4.1  Change Request
           3.4.2  Code Review
           3.4.3  Review and Approval
                 3.4.3.1
                 3.4.3.2
Maintai
User
     3.5   Testing Standards and Procedures

           3.5.1  Test Plans
           3.5.2  Test Data
           3.5.3  Test Scenarios
           3.5.4  Test Results

     3.6   Change Implementation Methods

           3.6.1  Test to Production Method
                                   A-17

-------
\
EPA System Dcsigi & Development
Guidance:   Volume C
              SOFTWARE MAINTENANCE  DOCUMENT
                                  (Continued)
       MAINTENANCE TOOLS

       4.1    Technical Tools

             4.1.1  Processing Tools
                              Compilers
                              Cross Reference
                              Hie Comparator
                              Traces/Dumps
                              Test Data Generator
                              Test Coverage Analyzer
                              Preprocessor
                              Verification/Validation
4.
4.
4.
4.
4.
4.
4.1
4.1
.1.1
.1.2
.1.3
.1.4
.1.5
.1.6
1.1.7
1.1.8
             4.1.2 Clerical Tools

                  4.1.2.1
                  4.1.2.2
                  4.1.2.3
                  4.1.2.4
                  4,1.2.5

       4.2    Management Tools
                             On-line Editor
                             Dccumentation Library
                             Archival Processor
                             Source Code Reformatter
                             Data Dictionary
            4.2.1 Problem Reporting
            4.2.2 Status Reporting
            4.2.3 Scheduling
            4.2.4 Configuration Management

 5.     SOURCE CODE

       5. *   (Insert Software Unit Name) Source Listing

 6.     NOTES

 7.     APPENDICES

 8.     GLOSSARY
                                     A-IS

-------
 EPA System Design & Development
 Guidance:  Volume C
               SOFTWARE OPERATIONS  DOCUMENT
 1.    INTRODUCTION

      1.1   Purpose
      1.2   Background
      1.3   Scope
      1.4   System References
      1.5   Terms and Abbreviations
      1.6   Organization of This Document

 2.    REFERENCED DOCUMENTS

      2.1   Government Documents
      2.2   Non-government Documents

 3.    OPERATIONS

      3.1   System Initialization
      3.2   System Restart

            3.2.*  (Insert Name) Function
3.2.*. 1
3.2.*.2

3.2.*.3 .
3.2.*.4
3.2.*.5
Execution
Inputs
3.2.*.2.1
3.2.*.2.2

User Inputs
System Inputs
Outputs
Termination
Error Messages
      3.3   System Manager

           3.3.1  Manager's Functions/Menu

                 3.3.1.*      (Insert Name ) Function

      3.4   System Backup/Recovery Provisions
      3.5   System Security

4.    NOTES

5.    APPENDICES

6.    GLOSSARY
                                  A-19

-------
 EPA System Design & Development
 Guidance:  Volume C
                                     Ml
              SOFTWARE USER'S REFERENCE GUIDE
       INTRODUCTION
 1 • X
 1.2
 1.3
 1.4
 1 .5
 1.6
            Background
            Scope
            System References
            Terms and Abbreviations
            Organization of This Document
5.
2.1   Government Documents
2.2   Non-government Documents

DESCRIPTION OF THE SYSTEM

3.1   System Overview and Mission Based Activities
3.2   System Flow and Data Descriptions
3.3   System and Program Manager
3.4   Data Dictionary

SYSTEM ACCESS TECHNIQUE(S)

4.1   Hardware/Software Interface(s)
4.2   Menus and Other Methods of Access
4.3   Manual Procedures

USER ANALYSIS / REPORTING OPTIONS
      5.1    Standard Reports
      5.2    Ad-hoc Capabilities
      5.3    Specialized Capabilities

            5.3.1 Models, Algorithms, Etc.
            5.3.2 Graphics
            5.3.3 Expert Systems
            5.3.4 Laser and Other Output Media

6.    DATA ENTRY AND UPDATE PROCESSES

      6.1    Methods and Descriptions of Processes
      6.2    Data Responsibilities

7,    USER SUPPORT AND TRAINING PROGRAM/SOURCES

      7.1    User Support
      7.2  ,  Training Sources/Schedules
                                   A-20

-------
EPA System  Design & Development
Guidance:   Volume C
                              EEI-11
             SOFTWARE USER-S REFERENCE GUIDE
                            (Continued)
 8.   NOTES


 9.   APPENDICES


10.  GLOSSARY
                               A-21

-------
EPA System  Design & Development
Guidance:   Volume C
                             EEI-12
              SYSTEM INTEGRATION TEST REPORT
1.    INTRODUCTION

      1.1   Purpose
      1.2   Background
      1.3   Scope
      1.4   System  References
      1.5   Terms and  Abbreviations
      1.6   Assumptions and Constraints,
      1.7   Organization of This Document

2.    REFERENCED DOCUMENTS

      2.1   Government Documents
      2.2   Non-government Documents

3.    SUMMARY OF TESTING

      3.1   Test Environment
      3.2   Chronology of the Testing

4.    TEST RESULTS

      4.1   Resolved Incidents
      4.2   Outstanding Incidents
      4.3   Evaluation and Recommended Disposition

5.    NOTES

6.    APPENDICES

7.    GLOSSARY
                                 A-22

-------