-------
-------
Volume A
Volume B
Volume C
G "0
B V)
rt •<
A w
*
o
I
Operations and Maintenance Manual
-------
EPA System Design & Development
Guidance: Volume A
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. 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 Next Steps 3-1
Appendix A
ESSENTIAL ELEMENTS OF INFORMATION A-1
iii
-------
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 Category/EEI Matrix 1-9
2-1 Process Flow of Site Information 2-6
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 die 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 4ftfrTm«tM!*ion 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 awtifncf 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
yam HM rfTMiMtir^lly mrr***rA rtwnfnti* rapacity and ii«*r «
-------
EPA System Design & Development
Guidance: Volume A
EXHIBIT 1-1
GUIDANCE AUDIENCE
PROJECT
DIRECTOR
PROJECT
MANAGER
SYSTEM
MANAGER
SENIOR
ANALYST
MID-LEVEL
ANALYST
JUNIOR
ANALYST
1.2
-------
EPA System Desiga & Development
Guidance: Volume A
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 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 -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 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
not 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 Amplified 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 Dcsiga & Development
Guidance: Volume A
EXHIBIT 1-2
EPA SYSTEM DEVELOPMENT LIFE CYCLE
AND DECISION PROCESS
DEVELOPMENT STAGE
DECISION /RESULT
C
Reed World
Mission Need
j
.Volume A
Mission Needs
Analysis
REQUIREMENT AND
OPERATIONAL CONCEPT
DEFINITION
. Volume B..
Preliminary Design 8t
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 A
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 EETs
should result in proper documentation for audits. The EEFs 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:
• FPA mission
• 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 EEI- 1, generated at the conclusion of the
Mission Needs Analysis, as described in this volume of the EPA System Design and Development
-------
uidance. OIRM/SIRMO review involvement will continue through die development life cycle of
systems and will include all EEfaocmncntation requirements fig such systems. For systems
falling into one of the above categories, EETs may be forwarded to OIRM/SIRMOs for
bnnation and review as they are developed.
A review cycle should be developed to monitor each EEI preparation. The review cycle
>uld include several stages, such as a series of status briefings for management, focus groups,
/or distribution of the EEI in draft form. Throughout the review cycle, die managers and users
ivolved should be informed of the process and content of the EET. When the final document is
completed, a consensus among management should be reached before developing the next ERT
It is not GERM'S intent to burden EPA managers with a host of documentation requirements
or each system development effort. The EEIs simply stress typical documentation requirements
rod their outlines highlight major topics that need to be considered for any system development
sffort Managers may use their professional judgment in substituting, combining, or down-scaling
&
the content of die FTfls to meet the unique requirements of dieir project
Criteria for determining the minimum EEI documentation for a specific process during die
design, development and implementation phase is based on the nature and scope of die 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 /Widejy 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 III: User Owned Information System: Unique, stand-alone process developed to
improve die 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
Age icy Program Management officials embarking on a system development effort should
be aware u. . 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
indards, 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
">ss^ System
^^^ Category
EEI ^V^
Requirements ^s^
EEI-1
Mission Needs
Analysis
EEI-2
Preliminary Design
and Options Analysis
EEI-3
Project
MancKTrmOTit 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 Malnt
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 A
• 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
expeditionsly and when required).
The remainder of Volume A provides requirements for conducting the first phase of the
i ystem development process — die Mission Needs Analysis, including development of the Initial
System Concept.
1-lt
-------
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 ft 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 die 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 skills far 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 the context of the
organizational
• Provides the basis for developing and evaluating an "Initial System Concept" which
will meet die 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 me 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 tfwse
individuals who will be the users of die completed system. The result of this review
should be a preliminary list of potential lisas of die system.
• Step 2 - Identification and specification of the information flow, transactions and
ojujaitt the system must or potentially could produce. The result of diis step is die
development of a concise (perhaps one page) Initial System Concept
• Step 3 - Testing and/or evaluation of die system concept by reviewing die concept and
preliminary output "designs" widi 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 5 - 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
-------
I I'A System Design & Development
(Guidance: Volume A
• Define the problem in concise terms 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
, 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/ Position/ System User
Organisation Function Output 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 AMD 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 pan 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 jhe 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
-------
R a
I
«•
R
-------
EPA System Desiga & DevetopMcai
Gudaacc: Vohmc A
• A stub (vertical axis), containing die major nrg^niygfipn^ and/or in^iviHnai^ involved in
die process incliy^c diose 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 die relationships between Headquarters. States and Regions
concerning shared data resources.
• Specifically identified outputs of die process.
The creation of a flow diagram similar to, and at die approximate level of detail as, dial
shown is highly recommended. It is a systematic mediodology for identifying die specific inputs,
information flow and process outputs. This flow diagram can usually be constructed from a
combination of existing documentation and Kmit**i interviews widi affected organizations P"d staff.
Based upon die 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 die left side
• A very brief description of key "processes" and/or data files in die center
• Graphic depictions of "outputs" on die right side.
In most cases it should be possible to construct die Initial System Concept" on one page.
2.3 STEP 3 - EVALUATION AND TESTING OF THE INITIAL SYSTEM rnNCEPT
THROUGH USER REVIEW
Documentation of processes and functions as outlined in Steps 1 and 2 will result in a high
level Initial System Concept depicting inputs, processes and outputs. During diis step, die system
2-7
-------
Input
Site Plan
Process
Activity
Schedule
—
»
•M •
••• *•
^i« •<
••• ••
•M ••
^•B ••
Initiation
Forms
Monthly Update
Activity
Progress
==
==•
$
^J
=
Major Changes
1
1
Maintenance Forms
Current
Data
We.w
pata
-
• Sort
• Select
• Stattotfcid
Data
Translation
Security
Output
Updated Site Plan
Site Summary Report
Activity
Progress
Regional/National
Summary
Site » By Activity
Management Assistance
Reports
j Start Lag
I Activity Completion
Task Start
£>
t>
a vi
f» *<
s a
Bft
M
;«
*
0
•S
<•
B
-------
EPA System Design & Development
Guidance: Volume A
concept is evaluated in tenns 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 (hard 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
idcntir -*ng alternatives with the user during this phase.
Two results should emerge from mis 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 step provide the basis for documenting each section in the
Mission Needs Statement (EEI-1).
2.4 STEP 4 - FINAL SPECIFICATION AND DOCUMENTATION OF RESULTS IN THE
MISSION MEEDS 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 die 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 - INITIATTQN 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
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 need 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.
• An initial Project Management Plan that outlines the tasks, resources and detiverables 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
This 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
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 elc
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-l
-------
on
B "fl
Mission Needs Analysts
EEI-1
Preliminary Design/
Options Analysts
EEI-2
EEI-3
System Detailed
Requirements Analysis
EEI-4
EEI-5
EEI-6
Preliminary Design
EE1-7
EEI-8
Detailed Design
EEI-8
System Production
and Programming
EEI-9
EEI-10
EE1-11
System Integration
Testing & Evaluation
EEI-12
System Installation
o
n
cj
S
w
H
HH
O
z
-------
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/OPERATIONAL 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 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.
Completion of the steps and documentation outlined in this document will result in an
automated system that solves a specific problem as outlined 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 title 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, the 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 the outputs from the System Development Process, and external factors
such as OMB certification, operations constraints and user acceptance of the delivered product
-------
Volume A
Volume B
Volume C
O
O
5
Si
CM
O
O
><
o
r
w
Operations and Maintenance Manual
-------
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
iii
-------
EPA System Design aotf Development
Guidance: Volume C
3. SOFTWARE DEVELOPMENT STANDARDS 3-1
3.1 Standard Programming Languages 3-1
3.1.1 Programming Language Selection Guidelines 3-1
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-1
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 * .4-5
4.1.2 Preliminary Design 4-5
4.L2.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.L3.1 Activities v 4-9
4.1.3.2 Docmrentation 4-10
4.1.3.3 Critical Design Review 4-11
4.1.3.4 Design Baseline 4-11
Iv
-------
EPA System Design and Development
Guidance: Volume C
4.2 System Development Stage 4-12
4.2.1 System Production and Programming 4-12
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
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
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 EEI Requirements for Type I Systems .2-9
2-2 EEI Requirements for Type H Systems . 2-10
2-3 EH Requirements for Type ID 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
4* Jl CiCx ir*OCUniCflt3tlOBI • • - • 4*2
vi
-------
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 die EPA system development process — The
System Design, Development and Implementation.
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 die intended audience of this
volume.
1.1 BACKGROUND
The Environmental Protection Agency expends millions of dollars each year on die design,
development, irnp^^DCTtation 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 die 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 dieir 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 1-1
GUIDANCE AUDIENCE
PROJECT
DIRECTOR
PROJECT
BiANAGER
CONTRACTOR
SYSTEM
BiANAGER
MID-LEVEI*
ANALYST
SENIOR
ANALYST
JUNIOR
ANALYST
,j£i»
^
1-2
-------
EPA System Design & Development
Guidance: Volume C
1.2 OBJECTIVES OF THE SYSTEM DESIGN AND DEVE
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 progranrmanagers
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 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
not 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 guida
lance
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
REQUIREMENT AND
OPERATIONAL CONCEPT
DEFINITION
Volume B.,
Preliminary Design 6i
Options Analysis
OPTION DESIGN. BENEFIT/
COST ANALYSIS. AND
OPTION SELECTION
Volume C,
System Design,
Development 6l
Implementation,
FULLY IMPLEMENTED
SYSTEM
1-5
-------
EPA System Design & Development
Guidance: Volume C
1.5 DOniMENTATIQN 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 EEFs
should resuu 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 EFT 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 die. following categories must
have OIRM/SIRMO review involvement:
• EPA mission critical
• States, local governments or other Federal agencies involved
• InterorganiTational involvement (e.g^ between Assistant Administratorship* or
including PggiffMl Office involvement)
• Costs for system development/enhancrment are projected to exceed $250,000
(excluding costs iissoci sited with long-term system operation flfM1 ina"|*|fnflncft)
• 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 die EPA System Design and Development
1-C
-------
Guidance. OIRM/SIRMO review involvement will continue through die development fife cyck of
these systems and will include all EEfdoaimcntarion requirements Cor such systems. For systems
not falling into one of the 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. 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 FFT, When the final document is
completed, a consensus among management should be reached before developing the next EET
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
die content of the PPTy to meet the unique requirements of their project
Criteria for determining the mimtmim 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 /^Vffig]y Accessed Information Systran* 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.
• TYPEIII: 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 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 z. certification form (certification of sensitive systems is an OMB
requirement). The 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
Agf icy Program Management officials embarking on a system development effort should
be aware ti... 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
indards, 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 C
EXHIBIT 1-3
SYSTEM CATEGORY
» EEI MATRIX
"^V^ System
^•s^^ Category
EEI ^^X^
Requirement* ^^^^
EEI-1
Mission Need*
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
Msnagwnv?nt Plan
EE1-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
TVpc
•
•
•
•
•
•
•
•
•
•
•
•
TP
•
•
•
•
•
•
•
•
•
•
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 die 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 SMAT J. 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 requireme 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 QUALJTY SOFTWARE
The Software Management Program wil^ produce significant results, including:
• TmprtwaH int»»r-nrganiyflrif>nfll relationships
- Demonstrated software engineering expertise
- Improved user acceptance of final products
- Improved abUity to react to changes
- Increased reliability of the software
- Improved maintainability of die software
• Insdtutionalization 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
jmnjinnnvity
- Fewer problems (errors) with delivered products
• More easily enhanced software
• Improved so ware 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:
I • -.:..••
• 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 die 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 and 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 life1
cycle: -
• 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 are 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 SOFTWARE ENGINEERING
This section mfrfrpffgf 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
• Software Development Suppon 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.4.1
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 die 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 die 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 me 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.
-------
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
• 5FTs are required for both new systems and existing systems.
• The 5FT outlines contained in Appendix A of this volume represent the basic EFT
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 EEb based on the circumstances of the project For example:
- Elements not included in a particular F.F.T 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 Fffi 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 Efrfl documentation for each:
a. Type I
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
Widely Accessed Information System: An information system that is not 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 F.FTs required for Type I information systems which include
both Major Agency Information Systems and Widely Accessed Information Systems.
b. Tvpell
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 PPT« required for Type H, localired Information Systems.
c. Tvpein
User Owned Information 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 EEIs required for Type HI, User Owned Information
Systems.
2.5.2 Software Life Cycle Reviews
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
-------
CJP1
Ufa Crete
Phase
•ta*.
T*sk*a*4
ActfvtdM
M
pi
FQ
(Dg
fcpj ^4
a tj
S S
gC M
n 2
25 H
as
Is
*,
SYSTEM DESIGN. DEVELOPMENT AND IMPLEMENTATION
System Design
System
Detailed
Requirements
Analysis
EH -4:
System
Implementation
Plan
EH 5:
System Detailed
Requirements
DoCUMBVll
EQ-*
SoftMIC
Preliminary
Design
EO-7:
SoAwMcTeat
Plan
Detailed
Design
EB-S:
nSS^IIL?"**1
System Development
System
Production
And
Programming
EH*
BCI-lOe
EEI-II:
System
Integration.
Test And
Evaluation
EEM*
System
IntejrallM Teat
Rcp«fl
System Implementation
System
System
Operations
and
Maintenance
,
EEI-7:
SoftwsJcTest
and Acceptance
PmA
EB-ft
Softwuc
EBI-IO:
na-ii|
{^a^SSt
8*2
•• 9*
«•
^a
W
w
O
w
w
JO
H
3
w
CD
H
W
o
5"
1
-------
on
B "fl
UfeCycU
Stage*
TMkaaad
Acttvtdc*
*«
-------
Otn
Ufa Cycle
Stage*
Acdvide*
DOCUMENTATION
REQUIREMENTS (EEIs)
SYSTEM DESIGN, DEVELOPMENT AND IMPLEMENTATION
System Design
System
Detailed
Requirements
Analysis
EEI-S:
Sy»um Detailed
Requirement*
Document
Preliminary
Design
Detailed
Design
Document
System Development
System
Production
And
Programming
BEI-fe
Software
Malnlenanoi
Document
EH 10:
Document
EEI-II:
Software Uaer'a
Reference Oukte
System
Integration.
Test And
Evaluation
•/A
System Implementation
System
System
Operations
and
Maintenance
Maintenance
DodiHwnC
EEt-IO:
Software Operation*
Docunent
EEI-II:
Software U*ef«
Reference Guide
i-o
O
1
-------
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 Proramming T -flnUflK Selection 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
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 arc:
• Results of the requirements and feasibility studies
• Potential life span of die application
• Resources available now and in the future to support both the development and
mflinffparvr of the application
• Telecommunications and local communications facilities
• Location and size of the data base(s)
• 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., Natural/VS AM for data entry and Natural/ADAB AS 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 and;
• Large Systems - are generally programmed using either 3GLs or 4GLs with or without
data base support, and they tun in the mainframe environment
The content of each matrix cell and the criteria of small, timHimn 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
suppct tools. The key for the software support tools is:
1 -Mainframe
2 - Mainframe
3 - Mainframe
4- Mainframe
5 - Minicomputer
6 - Minicomputer
7-Mic
nputt
8 - Microcomputer
9 - Microcomputer
3GUDBMS (COBOL, PL/I, FORTRAN)
4GUDBMS (Natural/ADABAS)
4GL (FOCUS)
4GL (NATURAL/VSAM)
3GL
4GL
(COBOL, FORTRAN, PASCAL)
(FOCUS, INFO)
4GL (INFO. FOCUS, dBASEm)
4GL/DBMS (dBASEm)
3GL (FORTRAN, PASCAL)
3-4
-------
EPA System Design A Development
Guidance: Volume C
EXHIBIT 3-2
SOFTWARE SUPPORT TOOL SELECTION MATRIX
SMALL SYSTEMS
;
SMALL SYSTEMS -f RECORDS <10X OR TOTAL SCZB < 10 MEGABYTES f
Number of Simultaneous User*
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
]
Kn<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
YES
2
2
2
2
NO
2.3.4
2.3.4
i
2.3.4 j
i
2.3.4 |
Notes:
1- Mainframe
4 -Mainframe
5 - Minicomputer
6 - Minicomputer
7 • Microcomputer
8 - Microcomputer
9 - Microcomputer
3GL/DBMS (COBOL. PL/I. FORTRAN)
4GL/DBMS (N*ural/ADABAS)
4GL (FOCUS)
4GL (NATURAL/VSAM)
3GL (COBOL, FORTRAN. Pascal)
4GL (FOCUS. INFO)
4GL (INFO, FOCUS, dBASEIH)
4GL/DBMS (dBASEm)
3GL (FORTRAN. Pascal)
3-5
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 3-3
SOFTWARE SUPPORT TOOL SELECTION MATRIX
MEDIUM SYSTEMS
10
Volatility
Number of
Simultaneous Users
Complex Random
Retrievals?
Location
of Related
Data
None
Mini-
Computer
Main-
Frame
I MEGABYTE
» 15
YES
2
2
2
_
NO
2.4
2.4
2.4
_
*JW**K*
elOOl
<10OK OR
IIEQABRES
Volatile
S 15
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
_
1
HUhhr
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
3GUDBMS (COBOL, PU1. FORTRAN)
4GUDBMS (NfloraVADABAS)
4GL (FOCUS)
4GL (NATURAL/VSAM)
S • Minicomputer 3GL
6 - Minicomputer 4GL
(COBOL, FORTRAN, Pascal)
(FOCUS. INFO)
-------
EPA System Design ft Development
Guidance: Volume C
EXHIBIT 3-4
SOFTWARE SUPPORT TOOL SELECTION MATRIX
LARGE SYSTEMS
Volatility
Number of
stm"itinfoin Uwra
Complex Random
Retrieval*?
Ftie
PfeM
Frequency
n» 1
per day
1 40
per day
-• RECORDS >100K OR TOTAL SBE > 10O iOBQABTRS
Almost Static
(Update Weekly or Leu)
S 15
YES
2.3
2
Hybrid
1.2
NO
2.3.4
2.4
1
> IS
YES
2
2
nyono
1.2
NO
3.4
2.4
4
Moderate Amount of
Change or Volatile
1 IS
YES
2
2
Hybrid
1.2
» IS
NO
2.4
2.4
4
Highly
Volatile
S IS
YES
1.2
1.2
Hybrid
1.2
> IS
NO
1.2
1.2
Hybrid
1.2
Notes:
1 • Mainframe
2-Mainframe
3 - Mainframe
4-Mainframe
3GL/DBMS
4GL/DBMS
4GL
4GL
(COBOL. PL/I, FORTRAN)
(Naunl/ADABAS)
(FOCUS)
(NATURAL/VSAM)
3-7
-------
EPA System Design & Development
Guidance: Volume C
3.1.2 Source Program Design and Coding Conventions
EPA has a general set of miV™1"" program design and program coding standards which
promote productivity, source code maintainability and software sharing and reuse. These
standards are patterned after the 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 ~0" statements and complicated
negative Boolean expressions
• ApplicabiUty 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 SPECTATTTFTi 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-S
-------
EPA 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 HI) 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).
3-9
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 3-5
EPA STANDARD SPECIALIZED SOFTWARE TOOLS
FUNCTION
TOOL
INTEGRATED
WITH
DataBase
Management
Graphics
Geographies
Spreadsheet
Word Processing
Text Processing
and Retrieval
Programmer Tools
Software
Maintenance Tools
Communications
Software
ADABAS
DBASE m PLUS
SASGRAPH
TELAGRAPH
VERSAGRAPH
ARC/INFO
UNIRAS
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
GNETH
PRIMEUNK
CROSSTALK
KERMIT
ARBITER
Bulk Data Transfer (BDT)
3270 PC FILE
TRANSFER (IND$FILE)
Data Transfer Facility (DTF)
NATURAL
SUPERNATURAL
SAS
INFO
INFO
INFO-TEXT
INFO
PRIME/PC Connection I
3-10
-------
EPA System Design ft Development
Guidance: Volume C
EXHIBIT 3-6
AGENCY-SUPPORTED HARDWARE AND SOFTWARE
TOOLS
3rd Generation:
COBOL
FORTRAN
PL/1
PASCAL
... 4_ ..
4u uenenuions
INFO
FOCUS
NATURAL
SAS
DBASE ID PLUS
EASYTRIEVE PLUS
TARGET HARDWARE ENVIRONMENT
IBM
3000
•
•
•
•
•
•
•
IBM
43XX
•
•
DEC/
VAX
•
•
•
•
•
•
•
PRIME
•
•
•
•
•
•
MS
DOS
•
•
•
•
•
•
Mac-
intosh
LAN
•
•
^9aUiH ^Setflvfi flffB^A^t^MVJffA^h^Mv*
AD ABAS
GM«M«»« WB«HIIHM>
TELL-A-GRAPH/CuedMrt
VERSAGRAPH
SASGRAPH
CRICKET DRAW
CRICKET GRAPH
MACORAW
MACPAINT
Spreadsheet:
LOTUS 1-2-3
20/20
SUPERCALC
SAS/FSP
EXCEL
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
3-11
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 3-6
AGENCY-SUPPORTED HARDWARE AND SOFTWARE
(CONTINUED)
TOOLS
TARGET HARDWARE ENVIRONMENT
IBM
3080
IBM
43XX
DEC/
VAX
PRIME
MS
DOS
Mac-
intosh
LAN
Geographic Information Syvtem*:
ARC/INFO
UNIRAS (Pilot)
wom ana Text son wares
LEXTTYPE
WORDSTAR
MULTIMATE
WORDPERFECT
WORDMARC
BASIS
TEXTWP
INFO-TEXT
MACWRITE
MICROSOFT WORD
Project Management!
TELL-A-PLAN
MICROSOFT PROJECT
TIMELINE
Telecom Capabilities;
""
SNA(3270/RJE)
ASYNCH ASCD
X.25
PRIMENET
DECNET
CROSSTALK
KERMIT
GNETII
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
3-12
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 3-6
AGENCY-SUPPORTED HARDWARE AND SOFTWARE
(CONTINUED)
TOOLS
Telecom Capabilities (Coat.):
PR1MEL1NK
NATURAL/CONNECTION
SAS/RLINK RTERM
3270 PC FILE TRANSFER (IND3FILE)
ARBITER
BULK DATA TRANSFER (BDT)
DATA TRANSFER FACILITY (DTF)
NOVELL NETWARE
Electronic Matt:
DIALCOM SERVICE
LOCAL CAPABILITIES
PrmgrumTn^r Productivity Alfln/F*
ISPF
LIBRARIAN
EMACS
COBOL DEBUGGER
FORTRAN DEBUGGER
EVE/TPU
VAXSET
DeskTop Publishing:
PAGEMAKER
VENTURA PUBLISHER
TARGET HARDWARE ENVIRONMENT
IBM
3090
•
dlities:
•
•
•
•
IBM
43XX
•
•
•
•
•
DEC/
VAX
•
•
•
•
•
•
PRIME
•
•
•
•
MS
DOS
•
•
•
•
•
Mac-
intosh
LAN
•
•
•
•
•
•
3-13
-------
Chapter Four
SYSTEM DESIGN, DEVELOPMENT, AND
IMPLEMENTATION OVERVIEW
This chapter addresses the third phase of the system development life cycle — 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 fiEI documentation th?t is affected during the t?sk, 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 & Development
Guidance: Volume C
Exhibit 4-1
EEI DOCUMENTATION
Documentation
Reviews
a
SYSTEM DESIGN, DEVELOPMENT AND IMPLEMENTATION
System Design
System
Detailed
Requirement*
Analysis
EEI-4
EEI-5
EEI-6
System
Require-
ments
Review
Functional
Baseline
Pwlli&ixisVY
Design
EEI-7
EEI-8
Pre-
Umlnary
Design
Review
Pre-
Umlnary
Design
Baseline
Detailed
Design
EEI-8
Critical
Design
Review
Design
Rait^fin^
System Development
System
Production
and
Programming
EEI-9
EEI- 10
EEI- 11
Develop-
ment Test
And
Evaluation
Review
Product
BsnfllfMT
System
Integration.
Test, and
Evaluation
EEI-12
Opera-
tional Test
And Eval-
uation
Review
Opera-
tional
Ftat^Hn?
System Implementation
System
Installation
User
Accept-
ance
System
Operations and
Maintenance
4-2
-------
EPA System Design & Development
Guidance: Volume C
4.1.1 System Detai1«l 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 the 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 die System Detailed Requirements
)
- Define major system functions
• Define physical requirements
Define security requirements
- Define life cvck resource requirements
- Define testing and verification requirements
- Define project work schedule(s) and workplan(s)
• Prepare the Software Management Plan (EEI-6)
- Identify project resources
• Define review responsibilities
- Identify organiTational structure and required resources
- Establish project schedules, reviews and reporting controls
- Implement risk management
- Implement software product assurance procedures
- miplement software devdopmemproc»duies for n^ project
While defining the System Detailed Requirements, t separate data dictionary Homm^nt
should be prepared that lists and describes each data element to be referenced by the system.
Additional guidance on die content of the Data Dictionary Document is provided in OQtNfs
Operations and Maintenance Manual
4.1.1.2
afsociatffd *«"*h tftc System Debited Rggflfrpreffts A"? fyirii includes;
• System Implementation Plan EEI-4 (F*nal)
• System Detailed Requiiements
Document EEI-5 (Preliminary)
• Software Management Plan EEI-6 preliminary)
4-4
-------
EPA System Design & Development
Guidance: Volume C
4.1.1.3 System Requirements Revie^y
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 baselined, 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 Preliminaiy Design
The Preliminary Design task represents the initial effort in producing a design that can be
used in developing an operational software product
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
- CharacteristicyRequirementsTraceability
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
-------
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
— 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 8t Development
Guidance: Volume C
4.1.2,2 Documentation
Documentation associated with the Preliminary Design task includes:
• Software Management Plan EEI-6 (Update)
• Software Test and
Acceptance Plan EEI-7 (Preliminary)
• Software Design Document EEI-8 (Final)
4.1.2.3 Preliminary Design Review
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-1
-------
EPA System Design & Development
Guidance: Volume C
4.1.2.4 Preliminary Design Baseline
The Preliminary Design Dateline 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
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 die 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 EEI-7 (Final)
• Software Design Document EEI-8 (Final)
• Software User's
Reference Guide EEI-11 (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.
4.2.1 System Production and Programming
The specifications developed during the System Design stage aze used to develop a system
that functions correctly in a controlled environment. Ac the completion of the System Production
-nd 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
Peifmui 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-12
-------
EPA System Design & Development
Guidance: Volume C
- Maintenance Tools
\
- Technical tools
— Management tools
- Source code
- Source listings or equivalent
• Prepare Software Operations Document (EH- 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 (EEI-1 1).
4.2.1.2
Documentation associated with the System Production and Programming task includes:
• Software Maintenance Document EEI-9 (Preliminary)
• Software Operations Document EEI-10 (Preliminary)
• Software User's Reference
Guide EH- 11 (Update)
• Unit Tested Source Code
• Unit Test Data.
4-13
-------
EPA System Design & Development
Guidance: Volume C
4.2.1.3 System 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 System 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
l
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.
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
(EEI-10), 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 EEI-10 (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 Reviews
The final Functional Configuration and the Physical Configuration reviews are performed
when all the subsystems are delivered and integrated into die Product Baseline. They confirm that
the software product or component of the software product performs according to die 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 die results of testing the software product All errors or incidents diat 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
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 die user. The Operational Baseline is established and/or updated
after a successful Operational Test and Evaluation Review.
4-U
-------
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.
Ifl 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
• Software Operations Document EEI-10 (Final)
• Software User's Reference Guide EEI-11 (Final)
• System Integration Test Reports I EEI-12 (FinaP
4.3.1.3 System Implementation Review
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 System 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 die most efficient and effective manner.
4-1S
-------
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-S. 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
systc. is. 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.1 INTRODUCTION
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 out 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 that
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
EH-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
EEM2 • • 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-l
-------
EPA System Design & Development
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
-------
Mission Needs Analysis
EEl-1
Prellmlnaiy Design/
Options Analysis
EEI-2
EEI-3
System Detailed
Requirements Analysis
EEI-4
EE.-5
EEI-6
Preliminary Design
EE1-7
EEI-8
Detailed Design
EEI-8
System Production
and Programming
EEI-9
EEI-10
EE1-11
System Integration
Testing & Evaluation
EEI-12
System Installation
Volume A
Volume U
Volume C
System Preliminary Critical
Requirement Design Design DT&E OT&E Us yt
Review Review Review Review Review Ac *pt*n<*
o
o
n
c
S
w
2!
H
>
H
c-t
O
2!
I?
5*
a
n
B
A
a
-------
EPA System Design & Development
Guidance: Volume C
2.
SYSTEM IMPLEMENTATION 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
IMPLEMENTATION PLAN
3.1 Plan Management
3.1.1 Policy Events and Actions
3.1.2 Program Management
3.1.3 Strategy for Acquiring Informadon/Data
3.1.3.1 Information Collection
3.1.3.2 Forms
3.1.3.3 Clearance
3.1.4 Strategy tor Integrating with other EPA Information
3.1.4.1 Environmental Data
3.1.4.2 Administrative Data
3.1.5 Access Policy and Standards
3.1.6 A sscssmrnt 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 Automated
3.1.7.2 Manual
3.1.8 Process and Procedure
3.2 Work Plans and Schedules
A-4
-------
EPA System Design & Development
Guidance: Volume C
SYSTEM IMPLEMENTATION PLAN
(Continued)
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
4. NOTES
5. APPENDICES
6. GLOSSARY
A-5
-------
EPA System Design & Development
Guidance: Volume C
SYSTEM DETAILED REQUIREMENTS DOCUMENT
1. INTRODUCnON
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. DETAILED CHARACTERISTICS AND REQUIREMENTS
3.1 System Definition Requirements
3.1.1 System Purpose
3.1.2 Concept of Operation
3.1.3 System Sizing and Timing Requirements
3.1.4 Design Standards
3.1.5 Design Constraints
3.1.6 Data Requirements
3.2 Subsystem Definition Requirements
3.2.1 Subsystem #1
3.2.1.1 Subsystem #1 Purpose/Definition
3.2.1.2 Subsystem #1 Interface Definition
3.2.1.2.1 Network
3.2.1.2.2 Software Systems
3.2.1.2.3 DataBase
3.2.1.2.4 Entity Relationships
3.2.1.3 Assumptions and Constraints
3.2.1.4 Subsystem #1 Level n Requirement 1
3.2.1.4.1 Level H Requirement 1 Description
3.2.1.4.1.1 Level m Detailed Functional
Requirement
-------
EPA System Design & Development
Guidance: Volume C
EEI-5
SYSTEM DETAILED REQUIREMENTS DOCUMENT
(Continued)
3.2.1.4.1.1.1 Tide and
Description Of
Level ffl
Function 1
3.2.1.4.1.1.* Tide and
Description Of
Level ffl
Function *
3.2.1.4.1.* Level ffl 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
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
S.2 Work Plan
5.2.1 Personnel
5.2.2 Milestones
5.2.3 Budget
6. NOTES
7. APPENDICES
8. GLOSSARY
A-l
-------
EPA System Design & Development
Guidance: Volume C
SOFTWARE MANAGEMENT PLAN
1. INTRODUCTION
I.I 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 Work Plan
4.1.2 Activity Network and Dependencies
4-1 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
EH-6
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 Softw»*»
6.1.2. i Data. Rights and Documentation
*. 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 Software Design Methodology
6.1.4.2 Programming Language
6.1.4.2 Interface Methodology
6.1.4.4 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
SOFTWARE TEST AND ACCEPTANCE PLAN
1. INTRODUCTION
Purpose
2 Background
.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. UMTTATIONS/TRACEABILrrY
3.1 Limitations
3.2 Traceabiliry
4. TEST PLANS
4.1 Software Unit Testing (includes Manual Procedures)
4.1.1 Test Requirements
4.1.2 Test Management
4.1.2.1 Integration Test Team Organization and Responsibility
4.1.2.2 Responsibilities of Other Organizations
4.1.2.3 Product Control
4.1.2.4 Test Control
4.1.2.5 Evaluation and Retest Criteria
4.1.2.6 Test Reporting
4.1.2.7 Test Review
4.1.2.8 Test Identification
4.1.2.9 TestData Environment
4.1.3 Test Schedule
4.1.4 Test Results
4.2 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.S 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
SOFTWARE DESIGN 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.1 Government Documents
2.2 Non-government Documents
3. SOFTWARE DESIGN REQUIREMENTS (SDR)
3.1 Concepts
3.2 Functional Flow
3 .n (Insert Name) Requirement
3. *.l Description of Requirements and Associated Software Design Functions
(SDFs), including Manual Procedures
4. SOFTWARE DESIGN FUNCTION (SDF)
4. * (Insert Name) Function
4.M Inputs
4.*.2 Local Data
4.*.3 Initiation, Timing and Sequencing
4.*.4 Interrupts
4.*.5 Processing
4.*.5.1 Algorithms
4.*.5.2 Error Handling
4.*.5.3 Test Structures
4.*.6 Outputs
4.*.7 Adaption
5. 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)
6. Detail Design
6.* (Insert Name) SFR
6.*.1 SFR Inputs
6.*.2 SFR Local Data
6.*.3 SFR Processing
6.*.3.1 Control
6.*.3.2 Algorithms
6.*.3.3 Error Handling
6.*.3.4 Data Conversion
6.*.3.5 Test Structure
6.*.3.6 Manual Procedures
6.*.4 SFR Outputs
6.*.5 SFR Decomposition
6.*.5.1 (Insert Name) Software Unit (SU)
6.*.5.*.1 SU Formal Parameters
6.*.5.*.2 SU Inputs
6.*.5.*.3 SU Local Data
6.*.5.*.4 SU Processing
6.*.5.*.5 SU Outputs
6.*.5.*.6 SU Limitations
6.*.5.*.7 Use of Other Elements
6.*.5.*.8 Manual Procedures
7. Data Base Design (If Applicable)
7.1 Data Base Management System
7.2 Data Structure (Logical Design)1
7.3 Interrelationships
7.4 Design Characteristic/Requirements Traceability
7.5 Physical Design2
7.5.* Rk (Insert Name)
7.5.*.* Record (Insert Name)
1 For ADABAS refer to EPA/NCC ADAS AS Application Development Procedures Manual for CDB A
requirements
2 For ADABAS refer to EPA/NCC ADABAS Application Development Procedures Manual for CDB A
requirements
A-15
-------
EPA System Design & Development
Guidance: Volume C
1-8
SOFTWARE DESIGN DOCUMENT
(Continued)
i
7.5.*.*.* Held (Insert Name)
7.5.*.*.*.* Item (Insert Name)
8. NOTES
9. APPENDICES
10. GLOSSARY
A-U
-------
EPA System Design & Development
Guidance: Volume C
SOFTWARE MAINTENANCE 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.1 Government Documents
2.2 Non-government Documents
3. 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 Mainedner
3.4.3.2 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 Design &
Guidance: Volume C
Development
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.1
4.1
4.
4.
4.
4.
4.
4.
1.1
1.2
1.3
1.4
1.5
1.6
1.7
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
Documentation 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.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 Execution
3.2.*.2 Inputs
3.2.*.2.1 User Inputs
3.2.*.2.2 System Inputs
3.2.*.3 Outputs
3.2.*.4 Termination
3.2.*.5 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
NOTES
APPENDICES
GLOSSARY
A-19
-------
EPA System Design & Development
Guidance: Volume C
SOFTWARE USER'S REFERENCE GUIDE
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 . 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
4. SYSTEM ACCESS TECHNIQUE^)
4. 1 Hardware/Software Interface^)
4.2 Menus and Other Methods of Access
4.3 Manual Procedures
5 . USER ANALYSIS / REPORTING OPTIONS
5.1 Standard Reports
5.2 Ad-hoc Capabilities
5.3
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
USER SUPPORT AND TRAINING PROGRAM/SOURCES
7.1 User Su
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
I.I 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
-------
United States Office of Information
Environmental Protection Resources Management
Agency Washington DC 20460 June 1989
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 mat 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.
-------
Volume A
Volume B
Volume C
o
«s
o
r
w
8
-------
EPA System Design & Development
Guidance: Volume B
TABLE OF CONTENTS
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. 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 GeneraH^ocess 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
-------
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
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 > 5-1
-------
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 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.
l-l
-------
EPA System Design & Development
Guidance: Volume B
EXHIBIT 1-1
GUIDANCE AUDIENCE
PROJECT
DIRECTOR
PROJECT
MANAGER
SYSTEM
MANAGER
SENIOR
ANALYST
MID-LEVEL
ANALYST
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 - Missioq 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 ano\ Qprions 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 auiQtnaicd 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
not 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
Reed World
Mission Need
.Volume A.,
Analysis
REQUIREMENT AND
OPERATIONAL CONCEPT
DEFINITION
Volume B.
Preliminary Design 8k
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 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
• 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 EEI-1, generated at the conclusion of the
Mission Needs Analysis, as described in this volume of the EPA System Design and Development
-------
EPA System Design ~& Development
Guidance: Volume B
Guidance. OIRM/SIRMO review involvement will continue through the development life cycle of
these systems andVill 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 EEI. 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 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 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). 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 die
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.
\ ne 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 dev >pment efforts which proceed to the system
design, development and implementation phase
1-t
-------
EPA System Design & Development
Guidance: Volume B
EXHIBIT 1-3
SYSTEM CATEGORY
EEI MATRIX
""^x^ System
^v. Category
EEI ^^^
Requirements ^v^
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-1 1
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.
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.
i
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 HI (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 processingAnanq>ulationAabulation functions
• Types and sizes of major data files
• Update^purging require
• 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 Process Requirements
• Required user interface
• Information security requirements, including:
. Accuracy and validity requirements
- Criticality of key outputs
2-2
-------
EPA System Design and Develop
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 DEVELOPING FEASIBLE OPTIONS
The 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 availableoptions. The flexibility/priority analysis is conducted based upon the overall
management and functional requirements and die 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
EXHIBIT 2-1
TYPICAL FUNCTIONAL REQUIREMENTS ANALYSIS
WORKSHEET, INPUT/OUTPUT FLEXIBILITY OF GRANTS
PAYMENT PROCESS
COMPONENT
Grant authorization form
COMMENTS ON FLEXIBILITY
INPUT
2. Invoice
1. Ledger
2. Check Printing
1. Funding check for each
program operation
2. Updated ledger
3. Management Report A
4. Management Report B
5. Queries via on-line
1. Form must have entries in all
blocks conforming to pre-
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 the Senior Information Resource Management Officer (SIRMO) for
die 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, die 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
*» _« _ ..
3ZQ GCTCTKlOHi
COBOL
FORTRAN
PL/1
PASCAL
INFO
FOCUS
NATURAL
SAS
DBASE m PLUS
EASYTRIEVE PLUS
TARGET HARDWARE ENVIRONMENT
IBM
3090
•
•
•
•
•
•
•
IBM
43XX
•
•
DEC/
VAX
•
•
•
•
•
•
•
PRIME
•
•
•
•
•
•
MS
DOS
•
•
•
•
•
•
Mac-
intosh
LAN
•
•
DatftBaje if«r»«jfm»n»?
ADABAS
Graphic* Ficflitlet;
TELL-A-GRAPH/Cuechait
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
^Seojcrapnic in •o'nnfflsf ion systems:
m
ARC/INFO
UNIRAS (Pilot)
Word and Text Software:
LEXTTYPE
WORDSTAR
MULTIMATE
. WORDPERFECT
WORDMARC
BASIS
TEXTWP
INFO-TEXT
MACWRTTE
MICROSOFT WORD
Project Management:
TELL-A-PLAN
MICROSOFT PROJECT
TIMELINE
Telecom Capabilities:
SNA(3270/RJE)
ASYNCH ASCII
X.25
PRIMENET
DECNET
CROSSTALK
KERMIT
GNETII
TARGET HARDWARE ENVIRONMENT
IBM
3000
•
•
•
•
•
•
•
IBM
43XX
•
•
•
DEC/
VAX
•
•
PRIME
MS
DOS
Mac-
intosh
LAN
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
,.•
•
•
•
•
•
•
•
•
•
2-8
-------
EPA System Design and Development
Quittance: Volume B
EXHIBIT 2-2
AGENCY-SUPPORTED HARDWARE AND SOFTWARE
(CONTINUED)
TOOLS
TARGET HARDWARE ENVIRONMENT
IBM
3090
IBM
43XX
DEC/
VAX
PRIME
MS
DOS
Mac-
intosh
LAN
Telecom Capabilities (Cont.):
PRIMELINK
NATURAL/CONNECTION
SAS/RLJNK RTERM
3270 PC FILE TRANSFER (1NDSFILE)
ARBITER
BULK DATA TRANSFER (BDT)
DATA TRANSFER FACILITY (DTP)
NOVELL NETWARE
Electronic Mail:
DIALCOM SERVICE
LOCAL CAPABILITIES
•
•
•
•
•
Frotfrummor PimHiM»HiHtv AMn/*far>ttm*f'
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
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-* RECORDS <10K OE
Number of Simultaneous 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 SDSB < 10 1
l15
YES
2
2
2
2
NO
2.3.4
2.3.4
2.3.4
2.3.4
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 (Natural/ADABAS)
4GL (FOCUS)
4GL (NATURAL/VSAM)
3GL (COBOL, FORTRAN. Pascal)
4GL (FOCUS, INFO)
4GL (INFO, FOCUS. dBASE HJ)
4GL/DBMS (dBASE IH)
3GL (FORTRAN, Pascal)
2-11
-------
EPA System Design and Development
Guidance: Volume B
EXHIBIT 2-4
SOFTWARE SUPPORT TOOL SELECTION MATRIX
MEDIUM SYSTEMS
1
MEDIUM SYSTEMS -10X 15
YES
2
2
2
NO
2.4
2.4
2.4
Volatile
* 15
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
Highly
Volatile
* 15
YES
1.2.
5.6
5.6
1.2
NO
1.2.
5.6
5.6
1.2
_
> 15 §
I
YES
1.2.
5.6
1.2
1.2
1
NO
1.2
1.2
1.2
Notes:
1 -Mainframe
2-Mainframe
3-Mainframe
4-Mainframe
5 - Minicomputer
6 - Minicomputer
3GL/DBMS (COBOL. PUT, FORTRAN)
4GL/DBMS (NatunWADABAS)
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 -i RECORDS > 100K OR TOTAL SIZE > 1OO MEGABYTES
Volatility
Number of
Simultaneous Users
Complex Random
Retrievals?
File
Pass
Frequency
n- 1
per day
1 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
> 15
YES
2
2
Hybrid
1.2
NO
2.4
2.4
4
Moderate Amount of
Change or Volatile
S 15
YES
2
2
Hybrid
1.2
> 15
NO
2.4
2.4
4
Highly
Volatile
S 15
YES
1.2
1.2
Hybrid
1.2
> 15
NO
1.2
1.2
Hybrid
1.2
Notes:
1 -Mainframe
2 -Mainframe
3 -Mainframe
4 -Mainframe
3GL/DBMS
4GL/DBMS
4GL
4GL
(COBOL, PL/I, FORTRAN)
(Natural/ADABAS)
(FOCUS)
(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
3GL/DBMS (COBOL, PL/I, FORTRAN)
4GL/DBMS (Natural/ADABAS)
4GL (FOCUS)
4GL (NATURAL/VSAM)
3GL
4GL
(COBOL, FORTRAN, Pascal)
(FOCUS, INFO)
4GL (INFO, FOCUS, dBASE ffi)
4G1VDBMS (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 bv Structuring and 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 (and hence cosrt 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 time 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-1*
-------
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 ANALYSTS
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
a Flexibility/Expandability
4. Acceptability To Management
And Users
5. Extensiveness Of Management/
Operational Changes Required (If Any)
a Resource Availability
(Staff And Dollars)
7. Management Commitment
& 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
w
TOTAL
rWXrRFF- EACH OPTION MEETS REQUIREMENT
OPTION I
Weighted
Rating Score
OPTION 0
Weighted
Rating Score
OPTION III
Weighted
Rating Score
3-2
-------
EPA System Design & Development
Guidance: Volume B
3.2 LIFE CYCLE BENEFIT-COST ANALYSTS
To ensure that the most cost-effective option is selected, the benefits and costs of each
option over the anticipated life of die 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 4s 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 an 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) Personnel - 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
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. FTPS PUB 64 and OMB Circular A-94
provide guidance for calculating die 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 the current facilities must be modified or expanded to accommodate die
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
econooc ; analysis because they will be incurred at the same level regardless of the outcome of die
analysis.
Relevant non-informational system costs must be included in die 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 die general price level, are not required in
the analysis of costs. If inflation is used in die analysis, the resulting costs must be presented in
both present (constant) and future (discounted) dollars.
-------
EPA System Design & Development
Guidance: Volume B
Although inflation, or an unanticipated increase in die 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 rite 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) Sflldks - 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 RFP 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
Re urring (operations) costs are expenses of operating die process on an annual basis that
continue t oughout 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, the 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-retum 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/Q 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
OPTION B
OPTION C
9-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 the 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 OPTTO^ TSET .prrrfw CRITERIA
The results of die 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, white 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 minimise 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-l 1) 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 DOCUMENTATION 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 die selected option is t manual solution, it is not strictly necessary to
complete the report shown, since justification for t manual process is not required. Nevertheless,
IT
It should be remembered mat the benefit-cost analysis is an evolving document and mat
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 the conclusion of this phase, if the system development effort appears to be
viable and proceeding to design, development and implementation, mere are certain management
actions which nuift be n»fa^*»_ 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
t
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
4.3
-------
Chapter Rve
SUMMARY
5.1 PRELIMINARY DESIGN AND OPTIONS ANALYSIS OUTPUTS
The outputs, documents and results of the Preliminary Design and Options Analysis are:
• EEI-2, Preliminary Design and Options Analysis
• EEI-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 die document mat win be developed
dining the Mission Needs Analysis phase.
A.1
The documentation requirements contained in this appendix apply to all software
develoi>mertorii*0deniizattap^ At a minimum,
these standards apply to aQ new software devdopment projects. Maintenance i
to existing information systems must comply with die requirements set out in Chapter 1, section
1.4 of Volume A, Mission Needs Analysis.
Compliance with the standards and conventions provided m this appendix will ensure that
adequate documentation is produced tor all system development projects.
"Riff ^ff^11^ *** ***** •ppMM^* *«*
EQ-1 •• Mission Needs Statement
The following milestone chart illustrates the relative initiation and completion of each
document with respect to die software development life cycle, its major phases, and die span and
scope of Volumes A, B, andC
A-l
-------
>
I
Mission Needs Analysis
EEI-1
Preliminary Design/
Options Analysis
EEI-2
EEI-3
System Detailed
Requirements Analysis
EE1-4
EEI-5
EEI-6
Prellmlnaiy Design
EEI-7
EEI-8
Detailed Design
EEI-8
System Production
and Programming
EE1-9
EEI-10
EEI-11
System Integration
Testing & Evaluation
EEI-12
System Installation
o
o
cj
g
w
§
r
n
r
w
f*
a V)
S3
" Sf
8
a
I
-------
EPA System Design and Development
Guidance: Volume B
PRELIMINARY DESIGN AND OPTIONS ANALYSIS
EXECUTIVE SUMMARY
• Background
• System Concept
• Option Summary
• Results of Options Analysis
1. INTRODUCTION
1.1 Background
1.2 Current System Description
1.3 Results of Mission Needs Analysis
1.4 Scope and Purpose
2. OPTION DESIGNS
2.1 System Concept, Management Requirements and Functional Requirements
Summary
2.2 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.* Option*
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
Background
System Description
Funding/scheduling
AccomplishmentPlan (including Procurement)
Risk
1. INTRODUCTION
1.1 Background
1.2 Current System Overview
2. System Description
3. Project Team and Support
3.1 Rotes and Responsibilities
3.2 Configuration Management
3.3 Quality Assurance/Control
3.4 Procurement Pun
4. Project Schedule and Task Description
5. Project Budget and Funding
6. TestPlan Requirements/Consttaints
7. Project Constraints
8, Documentation .Standards
8.1 Policy Events
8.2 Forms and Clearances
A-4
------- |