-------
-------
VduroeA
EXECUTIVE
ces center
/
0 ;<
*
This docnment constructs a framework around which Agency program managers and
contracting officers can document a problem and justify the need for an information processing
solution. The objective of this document is to provide guidance towards satisfying requirements
specified in EPA's IRM Policy Manual for the acquisition and management of information
technology. >
The guidelines within this document are designed to provide program managers and their
staff with a suggested methodology for assessing and evaluating the need for information
processing. Applying the methodology in this volume will result in two outputs: 1) a preliminary
specification of a management requirement for information or information processing; and the
outputs and benefits tied to the user's organization mission and operation, and 2) an "Initial System
Concept" which provides an initial depiction of the inputs, outputs, and processes.
Completion of the steps outlined in this document will provide management with the
information required to make a decision whether or not to proceed to the Preliminary Design and
Options Analysis task defined in Volume B. The following exhibit describes the complete
software life cycle. Each process in the software life cycle is represented by a circle with its corre-
sponding title on the inside of the circle. Inputs to the Mission Needs Analysis or factors that
influence the process are shown surrounding the circle. As indicated, influencing factors are: new
legislation, changes to regulations, program growth and the preceding process Software
Obsolescence,
HEADQUARTERS LIBRARY
ENVIRONMENTAL PROTECTION AGENCY
WASHINGTON, O.C. 20460
CO
-------
EPA System Design & Development
Guidance: Volume A
COMPLETE SOFTWARE LIFE CYCLE
ii
-------
EPA System Design & Development
Guidance: Volume A
TABLE OF CONTENTS
1. INTRODUCTION
Page
1-1
1.1 Background 1-1
1.2 Objectives of the System Design and Development
Guidance '...1-3
1.3. Authority ! 1-4
1.4 Applicability of the Guidance 1-4
1.5 Documentation Requirements 1-6
1.6 Assistance and Support Available 1-8
2. CONDUCTING THE MISSION NEEDS ANALYSIS AND
DEVELOPING THE INITIAL SYSTEM CONCEPT 2-1
2.1 Step 1 - Review of the Information Need Background and
the Mission and Organizational Needs. 2-3
2.2 Step 2 - Identification and Preliminary Specification of
Inputs, Processes and Outputs and Development of the
"Initial System Concept" 2-5
2.3 Step 3 - Evaluation and Testing of the Initial System Concept
Through User Review 2-7
2.4 Step 4 - Final Specification and Documentation of Results in
the Mission Needs Statement ; .....2-10
2.5 Step 5-Initiation of the Project Management Plan 2-11
3. SUMMARY 3-1
3.1 Mission Needs Analysis Outputs... 3-1
3.2 NextSteps 3-1
Appendix A
ESSENTIAL ELEMENTS OF INFORMATION A-l
Hi
-------
EPA System Design & Development
Guidance: Volume A
LIST OF EXHIBITS
1-1 Guidance Audience 1-2
1-2 EPA System Development Life Cycle and Decision Process 1-5
1-3 System Categoiy/EEI Matrix.... 1-9
2-1 Process Flow of Site Information 2-6
1 ^ .
2-2 Initial System Concept - Site Management System 2-8
-------
Chapter One
INTRODUCTION
Pursuant to the Environmental Protection Agency's IRM Policy Manual, this volume is the
first of three volumes which provide guidance for Agency system design and development efforts.
This volume provides guidance for the first phase of the EPA system development process The
Mission Needs Analysis.
Volume A is intended for use by Agency Program and Management Officials and
responsible staff when making a determination regarding an information or information processing
need and whether to commit resources to identity, develop, and implement an appropriate solution
to satisfy that need. Exhibit 1-1 on the next page identifies the intended audience of this volume.
1.1 BACKGROUND
The Environmental Protection Agency expends millions of dollars each year on the design,
development, implementation and maintenance of major environmental and administrative systems
vital to EPA's programs and administrative functioning. Management of these resources is
becoming increasingly complex, since the rapid development of information technology in recent
years has dramatically increased computer capacity and user accessibility. .The result has been two-
fold:
An increasing number of system development efforts by managers and staff at all
r»iffiiii«aftnMl Igw.lf n/lip, hgeansft pf agceyy tn their own egmpmeny, demilnp fhair nwn
systems independently of Agency system's start
A wide range of hardware/software options for implementation of any specific system
concept or design.
Therefore, there has been a proliferation of system development efforts by a broad range of users
with varying levels of sophistication in making development decisions and conducting
development efforts.
I-l
-------
EPA System Design & Development
Guidance: Volume A
EXHIBIT 1-1
GUIDANCE AUDIENCE
PROJECT
DIRECTOR
PROJECT
MANAGER
EPA
CONTRACTOR
SYSTEM
MANAGER
SENIOR
ANALYST
JUNIOR
ANALYST
MID-LEVEL
ANALYST
1-2
-------
EPA System Design & Development
Guidance: Volume A
1.2 OBJECTTVES OF THE SYSTEM DESIGN AND DEVELOPMENT GUIDANCE
Within EPA's Office of Administration and Resources Management (OARM), the Office of
Information Resources Management (OIRM) is responsible for ensuring the effective and efficient
use of EPA's information resources including automated system design, development and
maintenance. OIRM's objective in this endeavor is to provide guidance, assistance, and only when
necessary, controls, to assure that the Agency's considerable information resources are utilized
cost-effectively for the overall benefit of the Agency. To this end, OIRM has developed umbrella
policies guiding information system development and acquisition (see Information Resources
Management Policy Manual). This three-volume set of guidelines and standards for system design
and development is a pan of OIRM's Software Management Series which is intended to assist EPA
in efforts to develop and manage software effectively. This series will also include future guidance
documents related to software management.
This document is the first of the three-volume set. The volumes cover the
following:
Volume A - Mission Needs Analysis is designed to provide program managers
and staff with « suggested methodology for assessing and evaluating the need
(requirement) for an information system. Applying the methodology in this volume will
result in: 1) confirmation that a need (requirement) exists and, 2) provide a preliminary
operational specification of the requirement.
Volume B - Preliminary Design and Options Analysis is directed towards
program managers and staff. It provides guidance and a methodology for structuring
design options for meeting the requirement defined in Volume A and provides guidance for
selecting the most cost-effective option.
t
Volume C - System Design. Development and Implementation is intended for use
primarily by system developers and provides specific guidance and standards which must
be adhered to when undertaking automated system design and development efforts.
Together these three volumes provide comprehensive guidance and standards for the orderly and
cost-effective development of automated systems. Exhibit 1-2 depicts the flow of the development
life cycle and decision process for the three volumes.
1-3
-------
EPA System Design & Development
Guidance: Volume A
In addition to the System Design and Development Guidance, OIRM is currently drafting
the EPA Information Security Manual. As security issues are raised and addressed throughout the
system development life cycle, the security manual should be consulted for proper Agency policy
and guidance.
1.3^ AUTHORITY
The EPA System Design and Development Guidance derives its authority from Chapter 4
of the IRM Policy Manual, entitled "Software Management," which establishes the Agency
Software Management Program. The guidance serves as the primary guidance for Agency system
design and development efforts.
1.4 APPLICABILITY OF THE GUIDANCE
Senior Agency managers and responsible staff should read the guidance and become
familiar with the decision-making process involved with system design and development efforts.
They are responsible for ensuring adequate analysis and documentation to support all critical
decision points. The full documentation requirements for automated system development efforts,
which must be followed to conform to OARM policy, are fully discussed in Volume C.
In general, Volumes A and B are intended to assist program offices and/or users in
conducting their own initial studies of system requirements, needs, option feasibility and cost-
effectiveness. In this context, the term "system" in Volumes A and B refers to a systematic set of
processes and/or procedures which can be used to meet the information needs of a user. It does
imply that the "system" will be an automated system.
Volume C, however, presumes that an automated or partially automated solution has been
selected as a result of the Volume B options analysis. Volume C provides guidance and standards
for automated system development efforts. If the automated system is a relatively small application
on a microcomputer targeted for use within a single office (a "user owned information system"),
Volume C provides simplified requirements for system design, development and implementation.
If the proposed system is a larger application (mainframe or minicomputer), which is mission-
critical or involves multiple offices and organizations. Volume C provides the full set of guidance
and standards which must be followed by system developers. This will assure uniform, cost-
effective system development in accordance with EPA policies, guidelines and standards.
1-4
-------
EPA System Desiga & Development
Guidance: Volnme A
EXHIBIT 1-2
EPA SYSTEM DEVELOPMENT LIFE CYCLE
AND DECISION PROCESS
DEVELOPMENT STAGE
DECISION/RESULT
c
Real World
Mission Need
J
.VolumeA ,»,
Analysis
REQUIREMENT AND
OPERATIONAL CONCEPT
DEFINITION
, Volume B.,
Preliminary Design Si
Options Analyst
OPTION DESIGN, BENEFIT/
. COST ANALYSIS, AND
OPTION SELECTION
Volume C,
System Design,
Development &
Implementation
FULLY IMPLEMENTED
SYSTEM
1-5
-------
EPA System Design & Development
Guidance: Volume A
1.5 DOCUMENTATION REOUIREMETfTS
In general, die intent of the three volume System Design and Development Guidance is to
provide a consistent focus for system development efforts which will allow both EPA program
managers and OARM managers to cost-effectively develop and maintain the Agency's systems.
To achieve this goal, certain documentation requirements termed "Essential Elements of
Information" (EEI) documents, must be met. Observance of this guidance in preparing EEI's
should result in proper documentation for audits. The EETs will also serve as a helpful reference
for conducting post-evaluations of the system decision making process. Each volume contains an
appendix which outlines the required EEI documentation.
For certain system development efforts OIRM and office Senior Information Resources
Management Officials (SIRMOs) must be involved in a review capacity to fulfill EPA's IRM
Policy Manual requirements. Systems falling into one or more of the following categories must
have OIRM/SIRMO review involvement:
EPA mission critical
* States, local governments or other Federal agencies involved
Interorganizational involvement (e.g., between Assistant Administratorships or
including Regional Office involvement)
Costs for system development/enhancement are projected to exceed $250,000
(excluding costs associated with long-term system operation and maintenance)
Information security issues involving the three general security areas: applications
security, installation security and personnel security. In total, information security
involves the precautions taken to protect the confidentiality, integrity and availability of
information
* Privacy Act or confidential business information involved.
For system development efforts falling into any one of these categories, OIRM and office
SIRMOs must be involved beginning with a review of EEM, generated at the conclusion of the
Mission Needs Analysis, as described in this volume of the EPA System Design and Development
1-C
-------
Guidance. OIRM/SIRMO review involvement will continue through die development life cycle of
these systems and will include all EEFdocumentation requirements for such systems. For systems
not falling into one of die. above categories, EETs may be forwarded to OIRM/SIRMOs for
information and review as they are developed.
A review cycle should be developed to monitor each EEI preparation. Hie review cycle
could include several stages, such as a series of status briefings for management, focus groups,
and/or distribution of die EEI in draft form. Throughout the review cycle, the managers and users
involved should be informed of the process and content of the EEI. When die final document is
completed, a consensus among management should be reached before developing the next EEL
It is not CHUM'S intent to burden EPA managers with a host of documentation requirements
for each system development effort The EEIs simply stress typical documentation requirements
and their outlines highlight major topics that need to be Considered for any system development
effort Managers may use their professional judgment in substituting, combining, or down-scaling
the content of die EEIs to meet the unique requirements of their project
Criteria for determining the minimum EEI documentation for a specific process during the
design, development and implementation phase is based on the nature and scope of the information
process and its importance to EPA's mission. Three types of categories describing various
systems with differing levels of EEI documentation requirements are identified as follows:
TYPE I:. Major Agency /Widely Accessed Information System: An information process
that requires special attention because of its importance to an Agency mission; its high
development, operating, or maintenance costs or its significant impact on administration
of Agency programs or, is widely accessed by a combination of EPA Headquarters,
Regional Offices, state and local users and/or Federal agencies.
* TYPE IT: Localized Information System: An information process that is not a Major
Agency Information System but significantly supports accepted program goals and
missions and is accessed primarily by users in one major area, e.g., EPA
Headquarters, a single Agency program, or a Region.
* TYPE ITT: User Qw*"^j Information System: Unique, stand-alone process developed to
improve the efficiency or effectiveness of operations for a single user or a small group
of users.
1-7
-------
EPA System Design & Development
Guidance: Volume A
Documentation requirements for each of these categories are projected in Exhibit 1-3.
Automated systems involving information security will be subject to one additional documentation
requirement completion of a certification form (certification of sensitive systems is an OMB
requirement). The form, which is under development and will be issued as part of the forthcoming
EPA Information Security Manual, will capture basic information on system sensitivity, security
requirements, security design, reviews, test scenarios, results and safeguards.
1.6 ASSISTANCE AND SUPPORT AVAILABLE
Agency Program Management officials embarking on a system development effort should
be aware that there are at least two sources available to them for assistance and support during the
system development life cycle:
* Within each AA/RA's office SIRMOs are available for assistance, support and guidance
relative to the EPA System Design and Development Guidance and other OIRM
guidance and standards
OIRM, with its general IRM management oversight role and requirements to exercise
procurement approval authority, has a staff organized to support EPA's administrative,
program and research communities.
It is appropriate to involve these support sources as early as is feasible in the system
development life cycle for most system development efforts.
The primary reasons for early involvement of SIRMOs and OIRM staff are:
Fulfilling EPA's IRM policy for system development review requirements
* Providing a value-added service role involving consultation, assistance, technical
standards, guidance and interpretation of requirements
* Expediting procurement for system development efforts which proceed to the system
- design, development and implementation phase
1-8
-------
EPA System Design & Development
Guidance: Volume A
EXHIBIT 1-3
SYSTEM CATEGORY
EEI MATRIX
System
Category
EEI
Requirements
Type
Type
II
Type
III
EEM
Mission Needs
Analysis
EEI-2
Preliminary
and Options.
EEI-3
Project
Management Plan
EEI-4
System
Implementation Plan
EEI-5
System Detailed
Requirements Doc.
EEI-6
Software
Management Plan
EEI-7
Software Test and
Acceptance Plan
EEI-8
Software Design
Document
EEI-9
Software Maint.
Document
EEI-10
Software Operations
Document
EEI-11
Software User's
Reference Guide
EEI-12
System Integration
Test Report
1-9
-------
EPA System Design & Development
Guidance: Volume A
* Providing assistance in determining user needs as early as possible in the life cycle.
~f
Achieving these objectives will strengthen EPA's system development efforts and avoid major
pitfalls that have beset system development efforts in other government agencies (e.g., project
stalls due to outyear funding shortages stemming from under-projected planning or project
disruptions due to failure to get hardware/software acquisitions into the procurement cycle
expeditiously and when required).
The remainder of Volume A provides requirements for conducting the first phase of the
system development process - the Mission Needs Analysis, including development of the Initial
System Concept
1-10
-------
.Chapter Two
CONDUCTING THE MISSION NEEDS ANALYSIS AND
DEVELOPING THE INITIAL SYSTEM CONCEPT
This chapter provides guidance for the first and most critical stage in initiating any system
development effort - the Mission Needs Analysis.
The decision to initiate system development efforts should be based on a perceived or
existing mission-based information or information processing need. This need may be prompted
by any number of factors such as new legislation, changes in regulations, or program growth
which may create needs for additional data, changes in practices or additional demands on existing
functions and resources.
As a result of the Mission Needs Analysis, the manager should have a complete
understanding of the problem and be able to demonstrate that the problem and solution are within
the manager's organizational mission. This will provide the manager with the necessary
information to justify the need for the project which is then used to obtain procurement authority
for the required resources. The manager should be aware of the fact that once the definition of the
needs has started, adequate in-house or contractor resources must be available to complete it
Successful development and implementation of any process requires careful review,
understanding, and documentation of the need for information and the functioning of the
information processes in the context of the user organization's mission and operational framework.
It is, therefore, critical that the "mission-based need" be reviewed as the first step toward?
establishing and defining the requirements for the system.
The use of computer-aided software engineering (CASE) tools, are becoming increasing
prevalent within the Agency. CASE tools can automate and standardize the activities within a
system development effort possibly resulting in a quicker and more accurately built system. If
appropriate, consideration should be given for using CASE tools early in the development life
cycle.
Project managers should be aware of the types of activities involved in software
development efforts and allow for slippage in schedules due to uncertainties and unknowns.
Planning for these activities and making estimates is a difficult task for any manager that does not
do this full time. Cost and time factors associated with implementing and managing a software
2-1
-------
EPA System Design & Development
Guidance: Volume A
development effort are dependent on such factors as size of the project, levels of complexity and
the skill level, experience and length of time the project team has been together.
However, it is vital that managers begin making and recording their estimates early in the
project life cycle so they can compare them with actual recorded program costs and hours. It is this
iterative effort of comparing planned versus actual performance that allows the manager to develop
more accurate estimation slrilfa for future planning efforts.
Information collected during the Mission Needs Analysis:
Specifies the nature of the program mission, problem, functions, processes and
information flows
Validates the need for information or information processing in die context of the
organizational mission
Provides the basis for developing and evaluating an "Initial System Concept" which
will meet the need.
>
The five steps required to conduct a complete Mission Needs Analysis and develop an Initial
System Concept are as follows:
Step 1 - Background review of the evolution of the perceived need, a concise statement
of the problem and a review of the user's mission, organizational structure and
operational processes. The analysis focuses on the positions and functions of those
individuals who will be the users of the completed system. The result of this review
should be a preliminary list of potential users of the system.
Step 2 - Identification and specification of the information flow, transactions and
outputs the system must or potentially could produce. The result of this step is the
development of a concise (perhaps one page) Initial System Concept
Step 3 - Testing and/or evaluation of the system Concept by reviewing the concept and
preliminary output "designs" with potential users to test their usefulness and identify
actual or potential constraints.
2.2
-------
EPA System Design & Development
Guidance: Volume A
* Step 4 - Final specification and documentation of the results of the previous steps
through development of a Mission Needs Statement
Step S - Initiation of the Project Management Plan as a preliminary document to
facilitate the planning and scheduling of resources for the activities that follow the
Mission Needs Analysis. .
The actual approach to conducting the Mission Needs Analysis involves conducting the
first four steps, and requires continual review, revision and recycling of steps as the analysis
proceeds. The suggested approaches for conducting each of these steps are presented below.
2.1 STEP 1 - REVIEW OF THE INFORMATION NEED BACKGROUND AND THE
MISSION AND ORGANIZATIONAL NEEDS
The Mission Needs Analysis should begin with a careful review of the organizational and
operational context from which the need evolved and the specific users which the process or
systematic solution is intended to assist The first task is to determine the genesis of the initially
identified and/or defined need. Some possibilities include:
A new program or set of mission functions have been mandated by the President,
Congress or senior officials, requiring the performance of new tasks, processes and/or
systems
A manager has decided to perform a new function or an existing function using
different procedures in support of the Agency's mission, goals and objectives
The Agency has decided to upgrade and modernize existing hardware and software
applications to take advantage of new technology.
An existing process or system has been evaluated and is suspected of being inefficient,
ineffective or obsolete.
In each of these cases it is important to review the evolution of the information need to
determine which of these possible causes was principally responsible for the system development
effort. Clearly identifying which of these causes is the basis for the system requirement is
important to future development efforts since knowing the reason for the need helps:
2.3
-------
1 FA System Design & Development
(iuidunce: Volume A
* Define the problem in concise teims including any quantifiable facts or conditions
related to the problem. For example, "The program office is unable to respond to
Freedom of Information Act (FOIA) requests for data due partly to a fifty percent
increase in FOIA requests and a five percent effective reduction in force."
Define the specific set of users and uses
Establish the likely priority accorded the effort by senior Agency officials and
responsible staff
Determine whether the problem is really one requiring a system solution or has some
other underlying cause.
In conducting this background review, two primary data collection methods may be used:
Interviews with key officials, managers and staff involved or potentially involved in the
0 processes to be systematized and those who will be the end users of the system results.
These user interviews should focus on what specific outputs are required of the process
and what benefits users anticipate. Interviews should include State and Regional users
to fully understand their system, data and access requirements.
Collection and review of key documents such as relevant legislation, agency policies or
operational plans, organizational mission/function statements or previous studies of the
function or process.
The results of the data collection efforts should be reviewed to provide those conducting the
Mission Needs Analysis with a clear picture of the operational context within which the process
will operate.
Perhaps the critical output of this initial review is a preliminary identification of users and
potential benefits of process outputs. A summary format for displaying this information in a
matrix is provided below:
Potential System User/
Organization
Position/
Function
System
Output
User
Benefit
2-4
-------
EPA System Design & Development
Guidance: Volume A
It is important that to the extent practical, this type of matrix be completed for all major
users to ensure adequate consideration of user needs and benefits.
2.2 STEP 2 - IDENTIFICATION AND PRELIMINARY SPECIFICATION OF INPUTS.
PROCESSES AND OUTPUTS AND DEVELOPMENT OF THE "INITIAL SYSTEM
CONCEPT"
Conducting Step 1 will result in the identification of the potential users, uses, outputs and
benefits. During this second task, the "flow" of information and work processes of the potential
system application are developed and documented. The purpose of this step is to develop an
overall understanding and preliminary design for the flow of information and information
products. At the conclusion of this step, a brief (perhaps one page) Initial System Concept is
developed. In addition, the documentation of the information flow ultimately provides the basis
for:
Determining the manual processes and procedures which will become a part of the
ultimate "system solution" for the need or problem (any and all automated processes
have a set of manual processes and procedures which support the automated portion of
the "system" and distribute its output)
Identifying and specifying {he procedures and functions which may be automated and
therefore may become the "automated system" which will be designed.
The flow of information or work processes that are candidates to be systematized can be
examined through flow diagrams that depict, on a macro level, the:
Organizations and key individuals involved in the information flow and information
products
* The input processes and documents which feed and support the system
* The specific output products.
Exhibit 2-1 illustrates a format for a sample process flow diagram which can usefully depict
such information. As shown, the diagram contains these important elements:
2-5
-------
EPA System Design & Development
Outdance: Volume A
EXHIBIT 2-1
PROCESS FLOW OF SITE INFORMATION
His
ii!
iS
BMO-OZW
fe
c
e
2-6
-------
EPA System Design & Development
Guidance: Volume A
* A stub (vertical axis), containing the major organiTatinny.mnyfir individuals involved in
die process including those involved in:
- Input processes
- Information process flow .
Process operation -
- Process output and use. . .
The flow and interrelationships of information among the various involved
organizations including the relationships between Headquarters, States and Regions
concerning shared data resources.
Specifically identified outputs of the process.
The creation of a flow diagram similar to, and at the approximate level of detail as, that
shown is highly recommended. It is a systematic methodology for identifying the specific inputs,
information flow and process outputs. This flow diagram can usually be constructed from a
combination of existing documentation and limited interviews with affected organizations and staff.
Based upon the data flow diagram, a higher level (ideally one page) Initial System Concept
document should be developed as in Exhibit 2-2. The concept should illustrate: <
Major process input documents/sources on the left side
* A very brief description of key "processes'* and/or data files in the center
Graphic depictions of "outputs" on the right side.
In most cases it should be possible to construct the "Initial System Concept" on one page.
2.3 STEP 3 - EVALUATION AND TESTING OF THE INITIAL SYSTEM CONCEPT
THROUGH USER REVIEW
Documentation of processes and functions as oudined in Steps 1 and 2 will result in a high
level Initial System Concept depicting inputs, processes and outputs. During this step, the system
2-7
-------
EPA System Design & Development
Guidance: Volume A
EXHIBIT 2-2
INITIAL SYSTEM CONCEPT -
SITE MANAGEMENT SYSTEM
o
IM i it ii i ii ii
inimiiiiii
I
05
(A
0)
O
O
el
s a
1
PJ
e
II
*lll
1,
>
1
Mllllllll
Illl11'
II
2-8
-------
EPA System Design & Development
Guidance: Volume A
concept is evaluated in terms of output usefulness, input feasibility and possible constraints. A
methodology which should be employed for evaluating output usefulness is to review the system
concept as well as "mock-ups" of the outputs (hand copy or screens) with users or potential users.
The "mock-ups" allow potential users to visualize the output of the process with three results:
* The user is able to "relate" to the output and indicate the benefit (or lack of benefit) of
the output . '
The discussion surrounding the reports can often identify other types of needs or report
designs which can be incorporated into the Initial System Concept
A preliminary estimate of the benefit to the user or potential user can be made by the
user.
During the review of the system concept and outputs with users, an exploration of possible
constraints to the process design should also be conducted. Constraints and/or implementation
problems may include:
Resistance by managers or staff to changes in operations
Organizational impediments
Input data compilation/collection problems
Lack of hardware accessible to the organizational units
Lack of staff and/or funds to develop and/or operate a system
.Lack of readily available telecommunications equipment/capability for data sharing and
, access requirements
* Information security needs and considerations based on the sensitivity of the system
Limited development time.
2-9
-------
EPA System Design & Development
Guidance: Volume A
Also, during the system concept review, the proposed output reports can be expected to be
partially redesigned in response to suggestions and reactions to individual reports by the users.
Finally, it is at this point that process options or process designs for achieving similar
outputs can be explored with the user. Although the options analysis is not fully conducted until a
later phase of the system development life cycle (described in Volume B), it is useful to begin
identifying alternatives with the user during this phase.
Two results should emerge from this step of the Mission Needs Analysis:
* A refined Initial System Concept incorporating the results of user evaluations of both
the concept and proposed outputs
An initial assessment of the needs feasibility, priorities and constraints.
These and the results from the previous stop provide the basis for documenting each section in the
Mission Needs Statement (EEL-1).
2.4 STEP 4 . FINAL SPECIFICATION AND DQCUMENTATTON OF RESULTS IN THE
MISSION NEEDS STATEMENT
The next step in conducting the Mission Needs Analysis is the formal documentation of the
work performed in Steps 1 through 3 in a Mission Needs Statement This document need not be
long. An outline for this document is attached in Appendix A. As shown, primary chapters in the
statement include:
* A background section, with a concise statement of the problem. It should also relate
the problem and its solution to the agency organizational unit's missions and functions.
» An Information Flow/Initial System Concept section which contains the Initial System
Concept and also identifies:
- Input data source
- Macro information flow and functions
Outputs including "mock up" format
* A discussion of potential system development constraints.
2-10
-------
EPA System Design & Development
Guidance: Volume A
The actual length of the Mission Needs Analysis document is dependent on various factors
such as: complexity of the problem or the organizational functions and mission, the size or scope
of the Initial System Concept, the impact of any known elements of risk, and the number and effect
*
of potential constraints to development and implementation.
2.5 STEP 5 - INITIATION OF THE PROJECT MANAGEMENT PLAN
The final step in conducting the Mission Needs Analysis is to initiate a preliminary Project
Management Plan. The format of the Project Management Plan is contained in Volume B,
Preliminary Design and Options Analysis. It is important to start this planning effort as early as
possible in order to plan and schedule the resources required for the activities that follow. This
preliminary document should include the following:
* Steps and tasks associated with Preliminary Design and Options Analysis
* Assignment of roles and responsibilities for the purpose of accountability which is
i
particularly critical when dealing with programs that cross organizational lines into the
States and Regions
* Resource allocations to accomplish the Preliminary Design and Options Analysis
Project costs and time frames associated with Preliminary Design and Options
Analysis.
At this stage of the system development process, there should also be little, if any, thought
given to the specific hardware or software that is to be used to support the process. Options in
these areas will be considered as part of the options analysis which is discussed in Volume B.
2-11
-------
-------
Chapter Three
SUMMARY
3.1 MISSION NEEDS ANALYSIS OUTPUTS
The outputs, documents and results of the Mission Needs Analysis are as follows:
* EEI-1, Mission Needs Analysis, is a concise document that describes the problem and
the neea to perform the process or function in support of the organization's mission.
An "Initial System Concept" indicating the flow of information required to support the
function, as well as the preliminary input documents and output reports.
v
An initial Project Management Plan that outlines the tasks, resources and deliverables of
the next phase of the project effort
3.2 NEXT STEPS
Once the Mission Needs Statement is complete, it should be understood that it will continue
to evolve and change as the "Initial System Concept" proceeds through the development life cycle.
Formal endorsement from management of the Mission Needs Analysis and approval to proceed to
the next step needs to be obtained. Since staff and management may change during the design and
development phases of the project, it is important to have a record of management approval at key
decision point
The next major step is to prepare the Preliminary Design and Option Analysis as described
in detail in Volume B. Both of these tasks are based on information collected during the Mission
Needs Analysis and embodied in the "Initial System Concept"
3-1
-------
-------
Appendix A
ESSENTIAL ELEMENTS OF INFORMATION
Tlus appendix provides a representative outline of documents that will be developed during
the Preliminary Design and Options Analysis phase.
A.1 INTRODUCTION
The documentation requirements contained in this appendix apply to all software
development or modernization projects, regardless of size, complexity or origin. At a minimum,
these standards apply to all new software development projects. Maintenance and/or enhancements
to existing information systems must comply with the requirements set out in Chapter 1, section
1.4 of Volume B, Preliminary Design and Options Analysis.
Compliance with the standards and conventions provided in this appendix will ensure that
adequate documentation is produced for all system development projects.
The documents defined in this appendix are:
EEI-2 Preliminary Design And Options Analysis
EEI-3 Project Management Plan
When an asterisk appears within a section number in the outlines, it represents a repetition
of the element as many times as necessary to define multiple iterations of the element
The following milestone chart illustrates the relative initiation and completion of each
document with respect to the software development life cycle, its major phases, and the span and
scope of Volumes A, B, and C.
A-1
-------
EPA System Design & Development
Guidance: Volume A
DOCUMENTATION VERSUS LIFE CYCLE
6*1
Sj
11
I
ffi
I -?,!«« 38 ,
21 a ^ i i i c iii
« cBmi Qu~i
(0 CgCdU i« u u u
U e o U U S3 UUEd
00
IfJ
l
=1
I
C
O
I IS
c3 » » «
c 5 5 .-a 5
g CdU ^ U
i
u
Q
4-rf
1
A-2
-------
EPA System Design & Development
Guidance: Volume A
MISSION NEEDS STATEMENT
1. BACKGROUND
Agency and organizational mission requiring system support
Mission/function statement(s)
Organizational chart with key functions/users identified
Operational environment
Current system description, including manual procedures
Evolution of defined need
New program or functions
Enhancement/modernization of functioning system, or
Current performance mode and limitations/problems
2. INFORMATION FLOW AND INITIAL SYSTEM CONCEPT
Description/documentation of information flow including:
Organizational data flow diagrams
Key input processes/documents
Primary data integration/data base functions and processes
Key output report types and distribution
"Mock-ups" of key output reports and discussion of their benefits to users
* Initial System Concept (ideally one page) and related description
3. DEVELOPMENT/QPERATTONAL CONSTRAINTS
User commitment, priority, discipline and budgetary limitations
Policy or organizational constraints
Information security needs based on system sensitivity
Timing of need
Interface needs
Shared data/access constraints
Stability/flexibility of need
A-3
-------
-------
United States Office of Information
Environmental Protection Resources Management
-Agency Washington DC 2O46O June 1989
&EPA EPA SYSTEM DESIGN &
DEVELOPMENT GUIDANCE:
VOLUME B:
PRELIMINARY
DESIGN AND
OPTIONS ANALYSIS
-------
-------
EPA System Design & Development
Guidance: Volume B
Volume B
EXECUTIVE SUMMARY
This document establishes the criteria that Agency program managers and their staff should
follow to develop a preliminary design and analysis of all the alternative options that satisfy the
"Initial System Concept" developed during the Mission Needs Analysis. The objective of this
document is to provide guidance towards satisfying requirements specified in EPA's IRM Policy
Manual for the acquisition and management of information technology.
The guidelines within this document are designed to provide program managers and their
staff with guidance and a methodology for developing design options that satisfy the "Initial
System Concept" developed as a result of the processes in Volume A. This document also
provides guidance for selecting the most cost-effective solution for the defined problem. The steps
described in this volume will result in the selection of the most cost-effective mission based option
(manual or automated) based on life cycle concepts and an initial project management plan that out-
lines how the selected option will be defined, developed and implemented.
*
Completion of the steps and subsequent analysis outlined in this document will result in a
list of two or more feasible solutions for the problem and related documentation concerning their
descriptions, life cycle benefits and costs, a formal life cycle benefit-cost analysis, and a summary
of the risks and contingencies associated with each option. After selecting an alternative, the
project management plan will be updated to reflect how the system development effort will be
accomplished. The revised project management plan will focus on resources, scheduling and ac-
countability as well as other pertinent factors. The following exhibit describes the complete
software life cycle. Each phase in the software life cycle is represented by a circle with its
corresponding title on the inside of the circle. Inputs to the Preliminary Design and Options
Analysis or factors that influence the phase are shown surrounding the circle. As indicated, in-
fluencing factors are: agency budget constraints, GSA and OMB requirements, available
resources, and the preceding phase, the Mission Needs Analysis.
-------
EPA System Design & Development
Guidance: Volume B
COMPLETE SOFTWARE LIFE CYCLE
ii
-------
EPA System Design & Development
Guidance: Volume B
TABLE OF CONTENTS
Tide
1. INTRODUCTION
Page
1-1
1.1 Background ." 1-1
1.2 Objectives of the System Design and Development
Guidance 1-3
1.3 Authority 1-4
1.4 Applicability of the Guidance 1-4
1.5 Documentation Requirements 1-6
1.6 Assistance and Support Available 1-8
2. PRELIMINARY OPTIONS DESIGN 2-1
2.1 Translating Management and Functional Requirements into
Operational Specifications ....2-1
2.1.1 Process Inputs 2-2
2.1.2 Functions and Processes 2-2
2.1.3 Process Outputs ...2-2
2.1.4 General-Process Requirements 2-2
2.2 Developing Feasible Options 2-3
2.2.1 Determining the Flexibility and Relative Priority of
Each of the Operational Specifications 2-4
2.2.2 Reviewing the Range of Hardware and Software
Potentially Available to Satisfy the Initial System
Concept (Management And Functional
Requirements) and Operational Specifications 2-4
2.2.3 Developing Options by Structuring and Adjusting the
Operational Specifications and Varying
Manual/Automated Functions 2-14
iii
-------
EPA System Design & Development
Guidance: Volume B
3. OPTIONS ANALYSIS 3-1
3.1 Operational and Technical Feasibility Analysis .....3-1
3.2 Life Cycle Benefit-Cost Analysis .-. 3-3
T»
3.2.1 Determining and Valuing Benefits 3-3
3.2.1.1 Non-recurring Cost-Reduction
Benefits 3-4
3.2.1.2 Recurring Cost-Reduction Benefits 3-4
3.2.1.3 Qualitative Benefits........ 3-5
3.2.1.4 Determining Total Benefits 3-5
3.2.2 Determining and Valuing Costs 3-6
3.2.2.1 Non-recurring Costs 3-7
3.2.2.2 Recurring Costs 3-8
3.2.2.3 Qualitative Costs 3-9
3.2.2.4 Determining Total Costs 3-9
3.2.3 Benefit-Cost Comparison 3-9
3.2.3.1 Benefit-Cost Ratio ..3-10
3.2.3.2 Payback Period ;3-10
3.2.4 OMB Benefit-Cost Approval Criteria 3-10
4. OPTION SELECTION AND DOCUMENTATION 4-1
4.1 Option Selection Criteria .4-1
4.2 Documentation Requirements .,, 4-2
5. SUMMARY 5-1
5.1 Preliminary Design and Options Analysis Outputs 5-1
5.2 Next Steps , C 5-1
iv
-------
EPA System Design & Development
Guidance: Volume B
Appendix A;
ESSENTIAL ELEMENTSOF INFORMATION
-------
EPA System Design & Development
Guidance: Volume' B
LIST OF EXHIBITS
1-1 Guidance Audience 1-2
1-2 EPA System Development Life Cycle and Decision Process 1-5
1-3 System Category/EEI Matrix 1-9
2-1 Typical Functional Requirements Analysis Worksheet, Input/Output
Flexibility of Grants Payment Process 2-5
2-2 Agency-Supported Hardware and Software 2-7
2-3 Software Support Tool Selection Matrix: Small Systems 2-11
2-4 Software Support Tool Selection Matrix: Medium Systems 2-12
2-5 Software Support Tool Selection Matrix: Large Systems... 2-13
3-1 Operational and Technical Feasibility Analysis 3-2
3-2 Sample Summary of Time-Phased Costs and Benefits for Option A 3-11
3-3 Sample Summary of Option Benefits and Costs 3-12
vi
-------
Chapter One
INTRODUCTION
Pursuant to the Environmental Protection Agency's IRM Policy Manual, this volume is. the
second of three volumes which provide guidance for Agency system design and development
efforts. This volume provides guidance for the second phase of the EPA system development
process The Preliminary Design and Options Analysis.
Volume B is to be used by Agency Program and Management Officials and responsible
staff to identify alternative manual and systems solutions to problems identified in the Mission
Needs Analysis, and to select the best solution based upon life cycle benefit-cost analysis
principles. Exhibit 1-1 on the next page identifies the intended audience of this volume.
1.1 BACKGROUND
The Environmental Protection Agency expends millions of dollars each year on the design,
development, implementation and maintenance of major environmental and adminisoative systems
vital to EPA's programs and administrative functioning. Management of these resources is
becoming increasingly complex, since the rapid development of information technology in recent
years has dramatically increased computer capacity and user accessibility. The result has been two-
fold:
An increasing number of system development efforts by managers and staff at all
organizational levels who, because of access to their own equipment, develop their own
systems independently of Agency system's staff
A wide range of hardware/software options for implementation of any specific system
concept or design.
Therefore, there has been a proliferation of system development efforts by a broad range of users
with varying levels of sophistication in making development decisions and conducting
development efforts.
l-l
-------
EPA System Design & Development
Guidance: Volume B
EXHIBIT 1-1
GUIDANCE AUDIENCE
SENIOR
ANALYST
PROJECT
DIRECTOR
PROJECT
MANAGER
SYSTEM
MANAGER
MID-LEVEL
ANALYST
EPA
CONTRACTOR
JUNIOR
ANALYST
1-2
-------
EPA System Design & Development
Guidance: Volume B
1.2 OBJECTIVES OF THE SYSTEM DESIGN AND DEVELOPMENT GUIDANCE
Within EPA's Office of Administration and Resources Management (OARM), the Office of
Information Resources Management (OIRM) is responsible for ensuring the effective and efficient
use of EPA's information resources including automated system design, development and
maintenance. OIRM's objective in this endeavor is to provide guidance, assistance, and only when
necessary, controls, to assure that the Agency's considerable information resources are utilized
cost-effectively for the overall benefit of the Agency. To this end, OIRM has developed umbrella
policies guiding information system development and acquisition (see Information Resources
Management Policy Manual). This three-volume set of guidelines and standards for system design
and development is a part of OIRM's Software Management Series which is intended to assist EPA
in efforts to develop and manage software effectively. This series will also include future guidance
documents related to software management
This document is the second of the three-volume set. The volumes cover the following:
Volume A - Mission Needs Analysis is designed to provide program managers
and staff with a suggested methodology for assessing and evaluating the need
(requirement) for an information system. Applying the methodology in this volume will
result in: 1) confirmation that a need (requirement) exists and, 2) provide a preliminary
operational specification of the requirement
Volume B - Preliminary Design and Options Analysis -- is directed towards
program managers and staff. It provides guidance and a methodology for structuring
design options for meeting the requirement defined in Volume A and provides guidance for
selecting the most cost-effective option.
Volume C - System Design. Development and Implementation is intended for use
primarily by system developers and provides specific guidance and standards which must
be adhered to when undertaking automated system design and development efforts.
Together these three volumes provide comprehensive guidance and standards for the orderly and
cost-effective development of automated systems. Exhibit 1-2 depicts the flow of the development
life cycle and decision process for the three volumes.
1-3
-------
EPA System Design & Development
Guidance: Volume B
In addition to the System Design and Development Guidance, OIRM is currently drafting
the EPA Information Security Manual. As security issues are raised and addressed throughout the
system development life cycle, the security manual should be consulted for proper Agency policy
and guidance.
1.3 AUTHORITY
The EPA System Design and Development Guidance derives its authority from Chapter 4
of the IRM Policy Manual, entitled "Software Management," which establishes the Agency
Software Management Program. The guidance serves as the primary guidance for Agency system
design and development efforts.
1.4 APPLICABILITY OF THE GUIDANCE
Senior Agency managers and responsible staff should read the guidance and become
familiar with the decision-making process involved with system design and development efforts.
They are responsible for ensuring adequate analysis and documentation to support all critical
decision points. The full documentation requirements for automated system development efforts,
which must be followed to conform to OARM policy, are fully discussed in Volume C
In general, Volumes A and B are intended to assist program offices and/or users in
conducting their own initial studies of system requirements, needs, option feasibility and cost-
effectiveness. In this context, the term "system" in Volumes A and B refers to a systematic set of
processes and/or procedures which can be used to meet the information needs of a user. It does
npi imply that the "system" will be an automated system.
Volume C, however, presumes that an automated or partially automated solution has been
selected as a result of the Volume B options analysis. Volume C provides guidance and standards
for automated system development efforts. If the automated system is a relatively small application
on a microcomputer targeted for use within a single office (a "user owned information system"),
Volume C provides simplified requirements for system design, development and implementation.
If the proposed system is a larger application (mainframe or minicomputer), which is mission-
critical or involves multiple offices and organizations, Volume C provides the full set of guidance
and standards which must be followed by system developers. This will assure uniform, cost-
effective system development in accordance with EPA policies, guidelines and standards.
1-4
-------
EPA System Design & Development
Guidance: Volume B
EXHIBIT 1-2
EPA SYSTEM DEVELOPMENT LIFE CYCLE
AND DECISION PROCESS
DEVELOPMENT STAGE
DECISION /RESULT
c
Real World
Mission Need
J
. Volume A.,
REQUIREMENT AND
OPERATIONAL CONCEPT
DEFINITION
Volumes,
Preliminary Design 82,
Options Analysis
OPTION DESIGN, BENEFIT/
COST ANALYSIS. AND
OPTION SELECTION
, Volume C
System Design,
Development 6i
Implementation
FULLY IMPLEMENTED
SYSTEM
1-5
-------
EPA System Design & Development
Guidance: Volume B
1.5 DOCUMENTATION REQUIREMENTS
In general, the intent of the three volume System Design and Development Guidance is to
provide a consistent focus for system development efforts which will allow both EPA program
managers and OARM managers to cost-effectively develop and maintain the Agency's systems.
To achieve this goal, certain documentation requirements termed "Essential Elements of
Information" (EEI) documents, must be met. Observance of this guidance in preparing EEI's
should result in proper documentation for audits. The EEI's will also serve as a helpful reference
for conducting post-evaluations of the system decision making process. Each volume contains an
appendix which outlines the required EEI documentation.
For certain system development efforts OIRM and office Senior Information Resources
Management Officials (SIRMOs) must be involved in a review capacity to fulfill EPA's IRM
Policy Manual requirements. Systems falling into one or more of the following categories must
have OIRM/SIRMO review involvement:
EPA mission critical
States, local governments or other Federal agencies involved
Intel-organizational involvement (e.g., between Assistant Administratorships or
including Regional Office involvement)
* Costs for system development/enhancement are. projected to exceed $250,000
(excluding costs associated with long-term system operation and maintenance)
f
Information security issues involving the three general security areas: applications
security, installation security and personnel security. In total, information security
involves the precautions taken to protect the confidentiality, integrity and availability of
information ' ,
* Privacy Act or confidential business information involved.
For system development efforts falling into any one of these categories, OIRM and office
SIRMOs must be involved beginning with a review of EEI-1, generated at the conclusion of the
Mission Needs Analysis, as described in this volume of the EPA System Design and Development
1-6
-------
EPA System Design & Development
Guidance: Volume B
Guidance. OIRM/SIRMO review involvement will contimfe through the development life cycle of
these systems and will include all EEI documentation requirements for such systems. For systems
not falling into one of the above categories, EEI's may be forwarded to OIRM/SIRMOs for
information and review as they are developed
A review cycle should be developed to monitor each EEI preparation. The review cycle
could include several stages, such as a series of status briefings for management, focus groups,
and/or distribution of the EEI in draft form. Throughout the review cycle, the managers and users
involved should be informed of the process and content of the EEL When the final document is
completed, a consensus among management should be reached before developing the next EEL
It is not OIRM's intent to burden EPA managers with a host of documentation requirements
for each system development effort. The EEIs simply stress typical documentation requirements
and their outlines highlight major topics that need to be considered tor any system development
effort. Managers may use their professional judgment in substituting, combining, or down-scaling
the content of the EEIs to meet the unique requirements of their project.
Criteria for determining the minimum EEI documentation for a specific process during the
design, development and implementation phase is based on the nature and scope of the information
process and its importance to EPA's mission. Three types of categories describing various
systems with differing levels of EEI documentation requirements are identified as follows:
TYPE I: Major Agency /Widely Accessed Information System: An information process
that requires special attention because of its importance to an Agency mission; its high
development, operating, or maintenance costs or its significant impact on administration
of Agency programs or, is widely accessed by a combination of EPA Headquarters,
Regional Offices, state and local users and/or Federal agencies.
TYPE II: Localized Information^ystem: An information process that is not a Major
< Agency Information System but significantly supports accepted program goals and
missions and is accessed primarily by users in one major area, e.g., EPA
Headquarters, a single Agency program, or a Region. .
TYPE III: User Owned Information System: Unique, stand-alone process developed to
improve the efficiency or effectiveness of operations for a single user or a small group
of users.
1-7
-------
EPA System Design & Development
Guidance: Volume B
Documentation requirements for each of these categories are projected in Exhibit 1-3.
Automated systems involving information security will be subject to one additional documentation
requirement - completion of a certification form (certification of sensitive systems is an OMB
requirement). Hie form, which is under development and will be issued as pan of the forthcoming
EPA Information Security Manual, will capture basic information on system sensitivity, security
requirements, security design, reviews, test scenarios, results and safeguards.
1.6 ASSISTANCE AND SUPPORT AVAILABLE
Agency Program Management officials embarking on a system development effort should
be aware that there are at least two sources available to them for assistance and support during the
system development life cycle:
Within each AA/RA's office SIRMOs are available for assistance, support and guidance
relative to the EPA System Design and Development Guidance and other OIRM
guidance and standards
OIRM, with its general IRM management oversight role and requirements to exercise
procurement approval authority, has a staff organized to support EPA's administrative,
program and research communities.
It is appropriate to involve these support sources as early as is feasible in the system development
life cycle for most system development efforts.
The primary reasons for early involvement of SIRMOs and OIRM staff are:
Fulfilling EPA's IRM policy for system development review requirements
Providing a value-added service role involving consultation, assistance, technical
standards, guidance and interpretation of requirements
* Expediting procurement for system development efforts which proceed to the system
design, development and implementation phase
1-8
-------
EPA System Design & Development
Guidance: Volume B
EXHIBIT 1-3
SYSTEM CATEGORY
EEI MATRIX
""V^ System
^sss^ Category
EEI ^"x.
Requirements ^s^
EEI-1
Mission Needs
Analysis
EEI-2
Preliminary Design
and Options Analysis
EEI-3
Project
Management Plan
EEI -4
System
Implementation Plan
EEI-5
System Detailed
Requirements Doc.
EEI-6
Software
Management Plan
EEI-7
Software Test and
Acceptance Plan
EEI-8
Software Design
Document
EEI-9
Software Maint.
Document
EEI- 10
Software Operations
Document
EEI- 11
Software User's
Reference Guide
EEI- 12
System Integration
Test Report
Type
.'
Type
II
.
Type
III
-
1-9
-------
EPA System Design & Development
Guidance: Volume B
Providing assistance in determining user needs as early as possible in the life cycle.
V
Achieving these objectives will strengthen EPA's system development efforts and avoid major
pitfalls that have beset system development efforts in other government agencies (e.g., project
stalls due to outyear funding shortages stemming from under-projected planning or project
disruptions due to failure to get hardware/software acquisitions into the procurement-cycle
expeditiously and when required).
The remainder of Volume B provides guidance for conducting the second phase of the
system development process - the Preliminary Design and Options Analysis phase.
1-10
-------
Chapter Two
PRELIMINARY OPTIONS DESIGN
Completion of the Mission Needs Analysis phase of the system development process will
have resulted in development of an Initial System Concept (operational concept) meeting the
identified management and functional requirements of the organization. The purpose of Volume B
is to translate these requirements into operational specifications, to identify and develop feasible
options meeting the requirements and to analyze the overall feasibility and cost-effectiveness of the
various options. This chapter presents the methodologies for
Translation of the management and functional requirements identified during the
Mission Needs Analysis into operational specifications
Identifying and developing procedural and process options satisfying the defined
management and functional requirements and operational specifications.
It should be noted that requirements refinement and option definition is an iterative process
in that management and functional requirements are first translated into operational specifications.
Options are then developed to satisfy (insofar as possible) the management requirements and then
the operational specifications are refined. The result of this iterative analytic process is a set of two
to four feasible design options, which to varying degrees may meet the basic defined management
and functional requirements identified in the Mission Needs Analysis.
2.1 TRANSLATING MANAGEMENT AND FUNCTIONAL REQUIREMENTS INTO
OPERATIONAL SPECIFICATIONS
The Mission Needs Analysis of Volume A broadly defines the system management and
functional requirements and results in development of the macro-level Initial System Concept The
purpose of this stage is to further examine and define the current process environment and user
needs, then to translate these needs into a specific set of operational specifications. The result of
this step is a set of operational specifications which provide a basis for structuring combined
automated/manual options meeting the management and functional requirements defined in Volume
A. The objective is to develop the operational specifications only in sufficient detail to allow
defining of options for a proposed system, but not to complete a detailed system requirements
analysis. The operational specifications form the baseline for what a proposed system must do.
The detailed requirement analysis is conducted in Phase in (only if an auto- mated system solution
is selected) and is discussed in Volume C. .
2-1
-------
EPA System Design and Development
Guidance: Volume B
The operational specification process focuses first on defining and providing details about
specific operational parameters which are required to meet the management requirement These
include:
2.1.1 Process Inputs
Origin/type of input (indirect data entry from forms, interface with other automated
systems, etc.)
> .
Frequency/rate of input (hourly, daily, weekly, monthly, etc.)
* Volume of data/text
2.1.2 Functions and Processes
Process and flow of each input into the "system"
* Data pnxessing/manipulation/tabulation functions
Types and sizes of major data files
* Update/purging requirements
\
Statistical or scientific analysis requirements
* Shared or accessed data requirements
Special functions such as project management/critical path, etc.
2.1.3 Process Outputs
Hard copy report formats
Screen display
Special presentations/graphics
Frequency (daily, weekly, monthly, on demand) and ongoing output rate
Other process interfaces ,
View locally and/or transmit to remote locations
2.1.4 General PjPfiess Jteguirements
' - c
* Required user interface
* Information security requirements, including:
- Accuracy and validity requirements
- Criticality of key outputs
2-2
-------
EPA System Design and Development
Guidance: Volume B
- Failure contingency
- Access controls
- Response time
- Flexibility
- Failure contingency
In general, these specific operational specifications involve an elaboration and
quantification of the Initial System Concept developed during the Mission Needs Analysis. All
operational specifications should be designed to meet the management and functional requirements
identified in the Mission Needs Analysis. Concentration at this point of the study should be on
creating a detailed picture of the way in which inputs/processes/outputs are generated and used.
Particular attention must be paid to the operational requirements of systems which involve data
sharing with States and Regions. Detailed formats and information' field structuring will be
established in the System Design stage described in Volume C.
2.2
EVELOPING
Hie operational specifications defined above provide the foundation for structuring two to
four feasible options which largely (but probably not exactly) meet the management and functional
requirements. In general, there are almost always a number of potential options for meeting the
management and functional requirements varying from manual processes through sophisticated
automated system designs. It is generally true that, if only one way to solve a problem is apparent,
the management problem has not been adequately defined and analyzed. Options should include
feasible approaches to solving the management problem and should not be limited to alternatives
involving automation (see FIRMR 201-30.009, "Analysis of Alternatives for Satisfying a
Requirement")
Structuring and developing possible options to satisfy the mission need (management
requirement) and operational specifications is a process which involves several activities performed
simultaneously and iteratively. They include:
Determining the flexibility and relative priority of each of the operational specifications
Reviewing the range of available hardware and software options available to meet the
specifications
2-3
-------
EPA System Design and Development
Guidance: Volume B
* Constructing alternatives by structuring/adjusting the operational specifications and
related procedures to meet available hardware and software options
Option refinement through balancing overall management requirements with
development costs and timing considerations.
These four steps are pursued iteratively to first structure and then specify in some detail the
selected options.
2.2.1 Determining the Flexibility and Relative Priority of Each of the Operational Specifications
/
At this stage, the operational specifications identified earlier are treated as somewhat
flexible and not a rigid set of specifications that every systematic solution must meet Instead, the
management and functional requirements should be considered as the overall goal but
determinations must be made regarding the relative priority of various requirements and
specifications. To assist the system developer with this process, a flexibility/ priority analysis of
each of the requirements and specifications should be performed in order to define the ranges of
associated parameters. This analysis represents just another step in the iterative process of
structuring avaifablepptions. The flexibility/priority analysis is conducted based upon the overall
management and functional requirements and the operational specifications defined in Section 2.1.
Exhibit 2-1 provides an example of an analysis of the flexibility of inputs/outputs for a grants
payment process. The analysis provides a "flexibility assessment" on key components of the
requirements and. operational specifications developed earlier. Conducting this analysis provides
the system developers with a sense of the way in which the requirements and specifications must
be satisfied including which things are mandatory, and which are desirable. The results of this
"feel" of relative priorities is used both for the development of options and for the options selection
process.
2.2.2 Reviewing the Range of Hardware and Software Potentially Available to Satisfy the Initial
System Concept (Management And Functional Requirements^ and Operational .
Specifications
During this step of the development process, a preliminary review of the hardware and
software potentially available for the application should be conducted. The past several years have
seen a major expansion in the range of hardware and software available to potential users. Thus,
this step of the development process has become more critical as the range of options has
2-4
-------
EPA System Design and Development
Guidance: Volume B
3.
4.
5.
EXHIBIT2-1
TYPICAL FUNCTIONAL REQUIREMENTS ANALYSIS
WORKSHEET, INPUT/OUTPUT FLEXIBILITY OF GRANTS
PAYMENT PROCESS
COMPONENT
Grant authorization form
Invoice
COMMENTSONPLEXIBILITY
INPUT.
Ledger
Check Printing
Funding check for each
program operation
Updated ledger
Management Report A
Management Report B
Queries via on-line
1. Form must have entries in all
blocks conforming to pie-
defined ranges with 100% edit
check.
2. Must have date, amount,
grantee name, address, and
grant authorization number and
must be 100% edited and
verified.
PROCESS/FUNCTION
1. Must be accurate, be backed
up, and all incoming
transactions must have been
100% edited and verified
2. Must be accurate, be backed
up, provide for safeguards and
anti-counterfeit procedures,
and allow 100% edit and
verification.
OUTPUT
1. Checks issued must be 100%
accurate and delivered to
. grantees by 15th of each month
2. Must be 100% accurate and be
completed by 13th of month so
that checks can be run by 15th
3. User would like by 15th but
indicates not a big problem if
slips as late as 25th of month
4. Nice to have but not essential
5. Nice to have but on-line not access
essential
2-5
-------
EPA System Design and Development
Guidance: Volume B
increased. In conducting this review it is strongly urged that EPA's Office of Information
Resources Management and/or die Senior Information Resource Management Officer (SIRMO) for
the program area be contacted for assistance.
Exhibit 2-2 briefly summarizes the range of hardware and software currently supported by
the Agency. This list provides an initial basis for determining available options within the Agency
environment The exhibit provides a representative sample of available MS-DOS and Macintosh
application software. The Macintosh computer is included as a potential option for development of
Localized (Type n) or User Owned (Type HI) information systems. In addition to reviewing the
available environments, the system developer, in conjunction with OIRM or SIRMO staff, might
want to review and consider other kinds of specialized hardware/software for a particular system.
In reviewing the available hardware/software, the developer should consider such factors
as the following:
What specific hardware is available or can be made available in physical proximity to
the user(s)? What is its accessibility?
^ * What similar software or data bases already exist, either within EPA or elsewhere,
which perform similar functions or contain similar data? For example, EPA's
personnel and payroll systems already contain much personnel data, and the Agency's
Integrated Financial Management System (IFMS) contains comprehensive (and
accessible) financial files. OIRM'S Information Systems Inventory (ISI) which
contains basic information on over 500 EPA systems, data bases and models should be
consulted to identify existing systems.
Is the application/system concept one for which software has already been developed
and is available either within EPA or through service bureaus? For example,
LEXIS/NEXIS, a commercially available software package, provides a means for
storage and retrieval of abstracted data bases.
Has EPA already developed applications which can be readily modified?
-------
EPA System Design and Development
Guidance: Volume B
EXHIBIT 2-2
AGENCY-SUPPORTED HARDWARE AND SOFTWARE
-
TOOLS
3rd Generation:
COBOL
FORTRAN
PL/1
PASCAL
Atll fi^TKM Hi Illll"
INFO
FOCUS
NATURAL
SAS
, DBASE III PLUS
EASVTR1EVE PLUS
TARGET HARDWARE ENVIRONMENT
IBM
3090
IBM
43XX
DEC/
VAX
-
PRIME
'
MS
DOS
Mac-
intosh
LAN
'
Data Base Management:
ADABAS
Graphics Faculties?
TELL-A-GRAPH/Cuechart
VERSAGRAPH
SASGRAPH
CRICKET DRAW
CRICKET GRAPH
MACDRAW
MACPAINT
Spreadsheet:
LOTUS 1-2-3
20/20
SUPERCALC
SAS/FSP
EXCEL
2-7
-------
EPA System Design and Development
Guidance: Volume B
EXHIBIT 2-2
AGENCY-SUPPORTED HARDWARE AND SOFTWARE
(CONTINUED)
TOOLS
(igotfmpTite Information Systems*
ARC/INFO
UNIHAS (Pilot)
Word and Text Software:
LEXHYPE
WORDSTAR
MULTIMATE
WORDPERFECT
WORDMARC
BASIS
TEXTWP
INFO-TEXT
MACWRITE
MICROSOFT WORD
ftTanatf*Tn»Ti+*
TELL-A-PLAN
MICROSOFT PROJECT
TIMELINE
-TARGET HARDWARE ENVIRONMENT
IBM
3090
TVeconi Capabilities:
SNA(3270/RJE)
ASYNCH ASCII
X.25
PRIMENET
DECNET
CROSSTALK
KERMIT
GNETII
IBM
43XX
DEC/
VAX
PRIME
MS
DOS
'
.
.
Mac-
intosh
LAN
..
2-8
-------
EPA System Design and Development
Quittance: Volume B
EXHrom-2
AGENCY-SUPPORTED HARDWARE AND SOFTWARE
(CONTINUED)
TOOLS
Telecom Capabilities (Cent.):
PRIMELINK
NATURAL/CONNECTION
SAS/RLINK RTERM
3270 PC FILE TRANSFER (INDSFILE)
ARBITER
BULK DATA TRANSFER (BDT)
DATA TRANSFER FACILITY (DTP)
NOVELL NETWARE
Electronic Mail:
DIALCOM SERVICE
LOCAL CAPABILITIES
TARGET HARDWARE ENVIRONMENT
IBM
3090
IBM
43XX
DEC/
VAX
PRIME
*
'
MS
DOS
Mac-
intosh
'
LAN
~
Programmer Productivity Aids/Facilities:
ISPF
LIBRARIAN
EMACS
COBOL DEBUGGER
FORTRAN DEBUGGER
EVE/TPU
VAXSET *
DeskTop Publishing:
PAGEMAKER
. VENTURA PUBLISHER
'
.
2-9
-------
EPA System Design and Development
Guidance: Volume B
How complex are the basic functions which must or could be performed by the
automated system, and what software exists to perform these functions (e.g.,
numerous project management software packages exist which include critical path
analysis, as do statistical packages to perform regression analysis, etc.)?
What is the desirable form of the output (hard copy tables, text, .graphs and charts,
screen display, color graphics etc.), and what hardware/software is available or can be
procured to produce this output?
How long will the hardware/software be available within EPA and when will it be
replaced? ' '.
* What security arrangements are available for given hardware or software, and are they
adequate for the application?
What telecommunications capabilities are required and available to meet system data
sharing needs?
The review of available hardware/software needs to include examination of all of these areas.
Beyond the availability of specific hardware and software applications, option designers
should examine the .potential hardware and software based upon defined size and flexibility
requirements identified in the management and functional requirements and operational
specifications analyses. Exhibits 2-3,2-4 and 2-5, following this page, present guidelines for the
type of software required for an application of a given size and complexity. Small, medium and
large systems are defined by the number of records processed or total storage requirement
The decision matrices can be used to help determine the support tools appropriate to system
development in the absence of OIRM staff guidance. The matrices apply only to the general
systems which store and retrieve information and should not be construed as taking precedence
over existing EPA system plans, strategies and policies. Also they do not encompass statistical
systems, spread sheet systems, graphics systems and other specialized functional systems. With
minor exceptions, they do not address hybrid systems - those which are developed using two or
more support tools (e.g., Natural/VSAM for. data entry and Natural/ADABAS for data retrieval).
2-10
-------
EPA System Design and Development
Guidance: Volume B
EXHIBIT 2-3
SOFTWARE SUPPORT TOOL SELECTION MATRIX
SMALL SYSTEMS
SMALL SYSTEMS -f RECORDS < 10K OB
Number of Stmultaj
neous Users
Complex Random Retrievals?
Location
of Related
Data
None
Main-
Frame
Mini-
Computer
PC
1
YES
2.3,6.7
2.3
6
7.8.9
NO
2.3.4.6.7
2.3.4
6
7.8.9
. TOTAL SIZE < 10 ]
l15 I
YES
2
2
2
2
NO
1
2.3.4 1
2.3,4 1
2.3,4 . 1
2.3.4 1
Notes:
1 -Mainframe
2-Mainframe
3 - Mainframe
4-Mainframe
5 - Minicomputer
6 - Minicomputer
7 - Microcomputer
8 - Microcomputer
9 - Microcomputer
3GL/DBMS (COBOL, PL/I, FORTRAN)
4GL/DBMS (Namrai/ADABAS)
4GL (FOCUS)
4GL (NATURAL/VSAM)
3GL (COBOL, FORTRAN, Pascal)
4GL (FOCUS. INFO)
4GL (INFO. FOCUS, dBASE ID)
4GL/DBMS (dBASE HI)
3GL (FORTRAN, Pascal)
2-11
-------
EPA System Design and Development
Guidance: Volume B
EXHIBIT 2-4
SOFTWARE SUPPORT TOOL SELECTION MATRIX
MEDIUM SYSTEMS
MEDIUM SYSTEMS - 10K <# RECORDS < 100K OR
10 MEGABYTES < TOTAL SIZE < 100 MEGABYTES
Volatility
Number of
Simultaneous Users
Complex Random
Retrievals?
Location
of Related
Data
None
Mini-
Computer
Main-
Frame
Moderate Amount
of Change per Day
S 15
YES
2.3.6
6
2.3
^^^^^^^^^^^^^^^^^^^^^^^S^^^^lf^^^^'^^'
NO
2.3.
4.6
6
2.3.4
> 15
YES
2
2
2
NO
2.4
2.4
2.4
Volatile
£ IS
YES
2.6
5.6
2
NO
2.3.
4.6
5.6
2.3.4
> 15
YES
2.3
2.3
2.3
NO
2.4
2.4
2.4
^Hswsss&S S^S&SSSSi&i?!
Highly
Volatile
£ 15
YES
1.2.
5.6
5.6
1.2
NO
1.2,
5.6
5.6
1.2
> 15
YES
1.2.
5.6
1.2
1.2
NO
1.2
1.2
1.2
Notes:
1 -Mainframe
2-Mainframe
3-Mainframe
4-Mainframe
5 - Minicomputer
6 Minicomputer
3GL/DBMS (COBOL, PL/I, FORTRAN)
4GL/DBMS (Natural/ADABAS)
4GL (FOCUS)
4GL (NATURAL/VSAM)
3GL (COBOL, FORTRAN, Pascal)
4GL (FOCUS. INFO)
2-12
-------
EPA System Design and Development
Guidance: Volume B
EXHIBIT 2-5
SOFTWARE SUPPORT TOOL SELECTION MATRIX
LARGE SYSTEMS
LARGE SYSTEMS-* RECORDS > 1OOK OR TOTAL SIZE > IOO MEGABYTES \
Volatility
Number of
Simultaneous Users
Complex Random
Retrievals?
File
Pass
Frequency
n» 1
per day
1 < n < 4O
per day
n>40
per day
Almost Static
(Update Weekly or Less)
S 15
YES
2.3
2
Hybrid
1.2
NO
2.3.4
2.4
4
> IS
YES
2
2
Hybrid
1.2
NO
2.4
2.4
4
Moderate Amount of
Change or Volatile
£ 15
YES
2
2
Hybrid
1.2
> 15
NO
2,4
2,4
4
Highly 1
Volatile 1
1
S. 15
YES
1.2
1.2
Hybrid
1.2
1
> 15 1
NO |
1.2 ' I
1,2
Hybrid
1.2
f
»
Als^y^^tt^feiM
Notes:
1 - Mainframe
2 -Mainframe
3-Mainframe
4-Mainframe
3GL/DBMS (COBOL, PL/I, FORTRAN)
4GL/DBMS (Natural/ADABAS)
4GL (FOCUS)
4GL (NATURAL/VSAM)
2-13
-------
EPA System 'Design and Development
Guidance: Volume B
The Software Support Tool Selection Matrices address systems that are small, medium,
and large.
-\
Small Systems - are generally programmed using 4GLs with or without data base
support, and they can run in either the mainframe, minicomputer or microcomputer
environments;
*
Medium Systems - are generally programmed using either 3GLs or 4GLs with or
without data base support, and they can run in either the mainframe or
minicomputer environments and;
Large Systems - are generally programmed using either 3GLs or 4GLs with or
without data base support, and they run in the mainframe environment.
The content of each matrix cell and the criteria of small, medium and large systems are
simplified to make them useful. There are several decision criteria along the legs of the matrices
and numbers in the intersections of the rows and columns which correspond to the software
support tools. The key for the software support tools is:
1 -Mainframe
2-Mainframe
3-Mainframe
4-Mainframe
5 - Minicomputer
6 - Minicomputer
7 - Microcomputer
8 - Microcomputer
9 - Microcomputer
3GUDBMS (COBOL, PL/I, FORTRAN)
4GL/DBMS (Natural/ADABAS)
4GL (FOCUS)
4GL (NATURAL/VSAM)
3GL (COBOL, FORTRAN, Pascal)
4GL (FOCUS, INFO)
4GL (INFO, FOCUS, dBASE HI)
4GL/DBMS (dBASE HI)
3GL (FORTRAN, Pascal)
Based upon the above reviews, the option designer should have a relatively good feel for
the potentially feasible hardware and software options available to meet some or all of the
management, functional and operational specifications.
2.2.3 Developing Options by Structuring a^d Adjusting the Operational Specifications and
Varying Manual/Automated Functions
In this step the analyses conducted to date are used to construct manual/automated options.
2*14
-------
EPA System Design and Development
Guidance: Volume B
In constructing these options, a number of factors must be considered simultaneously.
Some of these factors include the following:
Specific functions which are candidates for automation. All automated processes have
a manual component, and the only question is what portion of the process or function
will be automated and what will be left as manual processing. Often the feasible
alternatives differ in the proportions of the processes and functions that are to be
automated. ;
The amount of effort fand hence cost) of automating certain functions. For example,
full text automation involving voluminous files is usually not a desirable option because
of the almost prohibitive effort and cost associated with inputting large amounts of data
or text.
User sophistication and discipline. Automated processes, but particularly sophisticated
processes, require considerable effort and discipline to maintain accurate data. If these
are not present in the user organization, than a manual or simple process is more highly
preferred to a more sophisticated design, and thus the options should include at least
one sophisticated option.
Timing of the management requirement. If a process must be in place quickly, a
manual or less sophisticated design will probably be required.
Availability of the appropriate hardware/software at the rime of implementation.
Procurement of new hardware or software may take prohibitively long, and/or existing
hardware or software may be replaced while the system is being designed.
*
Based upon these and other considerations, a set of options for performing the defined
functions should be structured. In general, these options should range from manual processes or
procedures, through the most highly automated alternative which is potentially feasible.
In displaying the options, it is highly desirable - in fact virtually mandatory - that all the
manual and automated functions associated with the option be defined and displayed. In fact these
manual/automated differences along with the hardware/software differences are the primary factors
which differentiate the options and which will form the basis for the benefit-cost analysis and
subsequent option selection.
2-15
-------
EPA System Design and Development
Guidance: Volume B '
A recommended analytical technique for defining and specifying the manual/automated
alternatives and differences by alternative, is to rely upon the flow diagrams and the Initial System
Concept developed during the Mission Needs Analysis. Beginning with these flow diagrams (see
Exhibits 2-1 and 2-2 of Volume A), updated system concepts can be constructed for each
alternative identifying: -
* The specific manual functions which must be performed
The specific system functions which must be performed
Changes from the current mode of operation.
This clear specification of which functions are to be performed manually and which are to be
automated is critical to the development of benefit and cost estimates for each option.
As a final step of this analysis, the defined options should be reviewed with the users to
determine their acceptability. This review should include a discussion of the advantages/
disadvantages as well as the operational implications (additional staff, new procedures, information
security factors, etc.) of each option. The result of this last review with the users is a potential set
of options which appear to satisfy to an acceptable degree the management requirements and
mission need.
2-16
-------
Chapter Three
OPTIONS ANALYSIS
Selecting an appropriate solution to satisfy the mission need and operational specifications
involves evaluating identified options against the identified requirements to determine which
alternative most cost-effectively satisfies the requirements. Thus, two analyses must be conducted:
* Operational and technical feasibility analysis
* Life cycle benefit-cost analysis.
Guidance for performing these analyses is provided below.
3.1 OPERATIONAL AND TECHNICAL FEASIBILITY ANALYSIS
For an option to be viable it should be technically, operationally, and economically feasible.
The purpose of the operational and technical feasibility analysis is not only to evaluate how well
each option meets the requirements identified to date but also to determine how operationally and
technically feasible each option is. The primary result of this task is a ranking of the various
options in accordance with their capacity to meet the requirements.
Completion of a matrix such as the one shown in Exhibit 3-1 should indicate the extent to
which each option is operationally and technically feasible. The matrix can be used, if desired, as a
means of ranking options by desirability. The matrix provides a formal means of scoring options
based on relative weights assigned to each requirement. First, each requirement is assigned a
weight based on its relative importance. Each option is then evaluated against the requirement and
assigned a rating. Weighted scores for each option are calculated and totaled giving the relative
desirability of each option.
A more informal evaluation process can also be used. This may involve a joint review of
the requirements by management, users and developers, to rank each option by desirability.
The results of this analysis will indicate the relative desirability and effectiveness of each
option. Before a final determination of an option can be made, however, a life cycle benefit-cost
analysis must be conducted.
3-1
-------
EPA System Design & Development
Guidance: Volume B
EXHIBIT 3-1
OPERATIONAL AND TECHNICAL FEASIBILITY ANALYSIS
OPERATIONAL/TECHNICAL AREA
1. Capability Of Producing Key
Products (Meet Management
Requirement)
"A"
"B"
. "C"
2. Developmental Time Compared
To Need
3. Flexibility/Expandability
4. Acceptability To Management
And Users
5. Extensivenesa Of Management/
Operational Changes Required (If Any)
a Resource Availability
(Staff And Dollars)
7. Management Commitment
a Risks Of Development/
Implementation (Security. Etc.)
» Management Risks
* System Hardware/Software Risks
Security Risks
9. 'Availability /Accessibility Of
Hardware And Software
10. Automated System Characteristics
Capability to Interface with
Other Systems
User-friendly Interface
Failure and Backup Provisions
Hardware/Software Obsolescence
» Site/Physical Plant Requirements
I
i
*,
TOTAL
OPTION!
Weighted
Rating Score
-
OPTION 11
Weighted
Rating Score
-
OPTION III
Weighted
Rating Score
3-2
-------
EPA System Design & Development
Guidance: Volume B
3.2 LIFE CYCLE BENEFIT-COST ANALYSIS
To ensure that the most cost-effective option is selected, the benefits and costs of each
option over the anticipated life of the process must be carefully reviewed. The benefit-cost analysis
is a methodology for conducting this analysis. The objective of the analysis is to identify and
compare the benefits and costs of feasible options to provide a sound basis for selecting the
preferred alternative.
The benefit-cost methodology consists of three tasks:
* Determining and valuing benefits
Determining and valuing costs
Comparing total benefits and costs.
The result of the benefit-cost analysis is the determination of the most cost-effective option.
Detailed guidelines for completing the benefit-cost analysis are presented below.
3.2.1 Determining and Valuing Benefits
The purpose of this task is to identify and value the potential benefits of each selected
option. Benefits usually are expressed in terms of the mission, goals or operating program
accomplishments over the expected operational life-span. These benefits must be identified for
each year of operation. In general, benefits are those accruing when compared to the current
situation; benefits that are expected to accrue under the current process are not included in the
analysis.
Generally, there are three types of potential benefits from automated systems:
Cost reduction benefits which are a direct result of an automated process being more
efficient than a manual process. In general these benefits accrue only when a system is
an operational system producing a product, such as payment checks, mailing lists, etc.
The methodology for valuing these benefits is a relatively straightforward efficiency
analysis.
* Additional capability benefits such as conducting statistical (regression) analyses which
cannot be done manually because of the immense number of calculations required. It is
often difficult to quantify these benefits.
3-3
-------
EPA System Design & Development
Guidance: Volnme B
* Management effectiveness benefits which result from improved management due to
improved information from management information systems such as improvements
related to the state access to information which provides better information for state
environmental managers. In general, it is impossible to directly measure these benefits
quantitatively since they stem from the presumed actions of managers who will make
better and more informed decisions. The approximate magnitude of these benefits may,
however, be inferred by estimating the total cost of the organization being managed
and presuming a small increase (2%-10%) in organizational effectiveness or efficiency.
For example, if a 1,000 person organization is expending $50 million/year, then a 2%
increase in management effectiveness translates into ah inferred benefit of $1 million
(.02 x $50 million).
Every reasonable effort should be made to identify and quantify benefits in units and
dollars with supporting rationale. When benefits cannot be quantified in dollars, they should be
expressed in measurable units. Non-quantifiable benefits may be identified if pertinent to the
decision. The discussion below presents categories of benefits which may result from a project.
3.2.1.1
Non-recurring Cost-Reduction Benefits
These are one-time benefits that have a dollar value. The benefits may occur at any point in
the life cycle, but they are not continuing benefits.
1) Cost reduction - The value of eliminating owned equipment, excess equipment and
inventory, or any other one-time source of quantifiable benefit.
2) Value enhancement - The value of additional tangible procurements (depreciable, not
consumable) and improvements to owned facilities and equipment.
3.2.1.2
Recurring Cost-Reduction Benefits
This includes benefits accrued throughout, or during most of, the system life cycle. These
cost-reduction benefits should be quantifiable and may include such categories as:
1) Maintenance and Lease of ADP Equipment - The savings for ongoing lease and/or
maintenance contracts for ADP equipment
3-4
-------
EPA System Design & Development
Guidance: Volume B
2) Communications - The savings on rental, lease or maintenance of data communication
equipment, services, and facilities.
3) Software Maintenance-- The projected savings on the maintenance of application
software. , .
4) Personnej - The salaries and fringe benefits saved (net savings) for operations, data
entry, and other personnel.
5) Training and Travel - Savings due to reduced training and travel.
6) Space Occupancy - Savings on equipment space, personnel and support facilities, and
administrative offices.
7) Supplies and Utilities - Reduction of both technical and administrative supplies.
8) Security - Savings on security guards, devices, etc.
3.2.1.3 Qualitative Benefits
Many important benefits can result without being able to easily quantify them. Examples
include: *
Faster processing and/or lower error rate
* Enhanced organizational image
Improved morale .
*. Standardization '
It may not be possible to precisely quantify these benefits in dollar terms, but they nevertheless
should be examined and retained as part of the analysis.
3.2.1.4 . Determining Total Benefits . . .
Total benefits are determined by summing annual tangible benefits over the life of the
process and adding non-recurring benefits. To determine present value benefits, adjust the benefits
over the system life cycle to their present value. The net present value is calculated by subtracting
3-5
-------
EPA System Design & Development
Guidance: Volume B
the adjusted cost from the total present value of benefits. FIPS PUB 64 and OMB Circular A-94
provide guidance for calculating the present value of benefits.
3.2.2 Determining and Valuing Costs
;
The purpose of this task is to determine for each option all costs and required resources,
e.g., personnel, equipment, etc. Costs must be analyzed for each alternative over its life cycle.
The system life cycle includes both the research and developmental, in addition to the
operational and maintenance phases. For example, the costs for conducting the system
development process discussed in Volume C must be included in the life cycle costs. The end of
the life cycle is the projected final year in the useful life of the process, or the last year in which
either costs or benefits are incurred.
Only relevant costs must be addressed in the economic analysis. A cost is relevant if the
implementation of an alternative would cause currently occurring costs to change. For example,
site costs are relevant if die current facilities must be modified or expanded to accommodate the
process. Costs which are not impacted by any alternative are the same for all alternatives and,
therefore, they are irrelevant to the economic analysis.
Sunk costs are riot relevant to the economic analysis. Sunk costs are costs which have
already been incurred or are irrevocable due to a prior commitment. Sunk costs are irrelevant to the
economic analysis because they will be incurred at the same level regardless of the outcome of the
analysis.
Relevant non-informational system costs must be included in the analysis. For example, if
workload increases would require future increases to non-information system staff to perform a
program mission, goal or operating function, the additional costs must be shown as increased costs
of the present process. .
Cost estimates must be supported by a reasonably accurate projection of workload and
capacity requirements. Specific workload data and associated capacity requirements for each year
in the process life must be provided.
The effects of inflation, or anticipated changes in the general price level, are not required in
the analysis of costs. If inflation is used in the analysis, the resulting costs must be presented in
both present (constant) and future (discounted) dollars.
3-6
-------
EPA System Design & Development
Guidance: Volume B
Although inflation, or an unanticipated increase in the general price level, is not required for
the analysis, a known or expected price increase in a specific cost item should be included when
the magnitude of the price change may affect the decision (for example: an increase in personnel
costs projected due to a planned general Federal pay raise). Note that costs for all years of the
process life must be presented in both present and future dollars.
Developmental (non-recurring) and operational (recurring) costs must be separately identi-
fied. Developmental costs are one-time costs to acquire hardware, software, telecommunications,
facilities, capitalized equipment, training and travel. Operational costs may be incurred over the life
of the process and include maintenance, facilities, non-capitalized equipment, supplies, training
and travel. Specific types of costs which should be considered in the analysis are identified below.
3.2.2.1
Non-recurring Costs
Non-recurring costs are costs associated with the acquisition of equipment, real property,
non-recurring services, non-recurring operations and maintenance (start-up) costs, and other one-
time costs. Non-recurring costs need not all occur in a single year. They include costs for
1) Site Modifications - The cost of erecting or modifying a site and surrounding facilities
to meet the needs of the proposed process, e.g., costs to enlarge a computer room
and additional space required for personnel involved in this process, etc.
2) Equipment - The cost for hardware, e.g., CPUs, disk drives, security devices, filing
cabinets, microfilming equipment, etc.
3) Data Communications - The cost for data communications hardware, communication
lines and dedicated data communications software.
4) Software Purchase - The cost for system software packages procured for the direct
support of the proposed system.
5) Database Development - The cost of implementing database system software and
database applications software.
6) Software Development - The cost of implementing application programs.
3-7
-------
EPA System Design & Development
Guidance: Volume B
7) Studies - The cost of studies associated with the requirements, design development,
or implementation of the proposed process, unless already incurred at the time of
options analysis.
8) Data Conversion - The cost of converting present data and program logic.
9) Procurement - The cost of procuring hardware, software and data communications
such as REP preparation, vendor evaluation, and contract preparation.
10) Training - The cost of training, including user, operations, and management training.
11) System Test - The cost of evaluating the process, including tests of information
security safeguards, and quality assurance/quality control measures.
12) Management Overhead - The cost of management interface in the development
process defined in terms of hours required for meetings, reviews and administrative
functions associated with continued process operation, etc.
3.2.2.2 Recurring Costs
Recurring (operations) costs are expenses of operating the process on an annual basis that
continue throughout the process life. They include costs for
1) Personnel -. The salaries and fringe benefits for operations, data entry, and other
personnel assigned to the process. Pan-time activities should be prorated
accordingly.
2) Maintenance and Lease of Equipment - The cost for lease and/or maintenance
contracts for equipment
3) Space Occupancy - The cost of equipment space, personnel and administrative
offices.
4) Supplies and Utilities - The cost of both technical and administrative supplies.
5\ Timesharing - The cost of buying computer time from EPA, other government
agencies or a commercial source.
3-8
-------
EPA System Design & Development
Guidance: Volume B
6) Communications - The cost for the rental, lease or maintenance of data
communications equipment, services and facilities.
7) Software Maintenance - The cost of maintaining application software.
8) Training - The cost of training and travel for new employees and upgrades.
9) Security - The cost of security guards, security devices, etc.
3.2.2.3 Qualitative Costs
Costs may or may not be measured in quantitative terms. Although the primary emphasis
of the benefit-cost analysis is to evaluate measurable impacts, the overall objective is to clarify all
of the important effects of any decision. Since this is the case, the identification and consideration
of qualitative or intangible effects which usually defy accurate calculation nevertheless play a part
in the analysis. Some qualitative costs include, but are not limited to:
Operational disruptions
Reduced employee morale
* Degraded organizational image
3.2.2.4 Determining Total Costs
To calculate total costs, die total non-recurring and recurring cost subtotals for each year of
the process life are added together. The total annual cost can be converted to present value cost for
each year of the process life. The present value will give a more equitable base when alternatives
have a wide dispersion in the funding years. A percentage rate must be applied to each year's cost
to calculate the present value and aggregate the total system cost. FIPS PUB 64 and OMB
Circular A-94 provide more detailed guidance for calculating present value costs. The total cost
over the process life is derived by summing the total costs for all years of the process life.
3.2.3 Benefit-Cost Comparison
The final step of the benefit-cost analysis is the summation of all benefits and costs,
selection of the benefit-cost measure, and arrangement of the benefit-cost display.
3-9
-------
EPA System Design & Development
Guidance: Volume B
The summation of benefits and costs is a straightforward addition which permits total
benefits to be compared to total costs. If all benefits and costs are measured in dollar terms, then
one number will be obtained for each. However, qualitative benefits or costs frequently will be
included. In these cases, no single number can be obtained and a number of measures may have to
be included in the final summation. However, just because a cost or benefit cannot be measured in
dollar terms does not mean it can be dropped from the final summation or downgraded If it is a
major effect, it must be considered.
The actual quantitative benefit-cost comparison involves three primary calculations:
1) Determination of the benefit-cost ratio
2) Determination of payback period
3) Determination of rate-of-rctum on investment
Exhibit 3-2 provides a sample format for summarizing both benefits and costs of an option (e.g.,
Option "A") over the system life cycle period. Exhibit 3-3 provides a sample format for displaying
quantitative benefits for all options evaluated in order to allow easier comparison.
3.2.3.1
Benefit-Cost Ratio
There are several benefit-cost measures which can be used for comparison purposes. The
benefit-cost ratio (B/C) is one measure which gives an approximate multiple of return on the
investment costs of a project Obviously, for a project to be economically viable, benefits should
outweigh costs so that the B/C ratio should be greater than 1. Another measure is the ratio of net
benefits (benefits minus costs) to costs. This gives an approximate rate of return on investment A
third measure, net benefits (B-Q may be used if the size of benefits is important
3.2.3.2
Payback Period
The payback period is calculated by determining the year and month in which the sum (in
current dollars) of benefits first exceeds the sum of the costs.
3.2.4 OMB Benefit-Cost Approval Criteria
Benefit-cost submissions to OMB for external review and approval must show at least a
10% return on investment or provide substantial additional justification for funding based on
3-10
-------
EPA System Design & Development
Guidance: Volume B
EXHIBIT 3-2
SAMPLE SUMMARY OF TIME-PHASED COSTS AND BENEFITS
FOR OPTION A
OPTION A
CATEGORY
NON-RECURRING COSTS
Site Modification
Equipment
Software Purchase
Software Development
RECURRING COSTS
Personnel
Maintenance
Training
TOTAL COSTS
PRESENT VALUE COSTS
NON-RECURRING
BENEFITS
Equipment Salvage
RECURRING BENEFITS
Maintenance Cost
Reductions
Space Savings
TOTAL BENEFITS
PRESENT VALUE
BENEFITS
NET PRESENT VALUE
FISCAL YEAR
0
1
-
<,
2
'
3 .
.
4
5
6
7
3-11
-------
EPA System Design & Development
Guidance: Volume B
EXHIBIT 3-3
SAMPLE SUMMARY OF OPTION BENEFITS AND COSTS
Benefit/Cost Ratio
Net Benefits to Costs
Net Benefits
Payback Period
OPTION A
OPTIONS
OPTION C
3.12
-------
EPA System Design & Development
Guidance: Volume B
satisfying non-financial criteria. OMB has also indicated that particular attention will be paid to
narrative amplification of benefits and costs, including assumptions made, options considered,
and die use of sensitivity analysis to evaluate the potential effects of uncertainty.
3-13
-------
-------
Chapter Four
OPTION SELECTION AND DOCUMENTATION
When the procedural steps outlined above have been performed, the options analysis and
the life cycle benefit-cost analysis are complete. The results of these analyses provide decision
makers with a range of valued alternatives. However, the results must be carefully examined to
ensure the accuracy of the analysis, and other factors that may be relevant to option selection must
be considered. "
4. 1 OPTION SFTrfifTrnNT CRITERIA
The results of the operational and technical feasibility analysis and the benefit-cost analysis
support decision makers by providing them with required information to make an informed
selection. These analyses do not make automatic the decision of which option to select The
selection process, while guided by these analyses, still involves a moderate amount of subjectivity.
One factor which may play an important role in any decision is risk. With any project there
is a certain element of risk involved, risk that costs may exceed expectations, that benefits will not
materialize as expected, etc. A benefit-cost analysis and the operational and technical feasibility
analysis helps minimize risk since they require explicit definition of expected benefits, costs and
risks. However, some risk always remains. If there is a high possibility that benefits may not
materialize from a project, the project's benefits should be much greater than its costs if a decision
to continue is to be made. Similarly, if costs and benefits are almost assuredly known, the project
may be viable even at a lower benefit-cost ratio or lower rate of return. The risk, factor should be
evaluated in any decision concerning a project
Another element of the option selection process which must be taken into account,
especially for large systems, is OMB's requirements governing major system development. As
previously noted, OMB requires a 10% return on investment or substantial additional justification
if it is to approve such development efforts. In addition, OMB requires (OMB Circular A- 11) that
budget estimates must be prepared for all "major information system initiatives" which are defined
as: ... ...-. .--.-
System design or development costs exceeding $1 million
System operation and maintenance costs exceeding $500,000/year.
4-1
-------
EPA System. Design and Development
Guidance: Volume B
This approval requirement can affect the timing of a system development project and
potentially even help decide which option is selected.
Of particular importance in the final decision is the value judgment placed upon qualitative
considerations, either those identified in the analysis or others. Frequently, the desirability of the
project will hinge on these factors. It is the job of the decision maker to evaluate intangibles in
light of his/her knowledge of the project, the people affected by it, and the conditions surrounding
it A final decision must be based upon these factors as well as the results of the benefit-cost
analysis.
4.2 PnaJMENTATTQN REQUIREMENTS
^
Completion of the analyses described in this volume should be documented in a report
outlining the analyses conducted and the results obtained. Appendix A, EEI-2, presents a
suggested outline for this report The report - EEI-2, Preliminary Design and Options Analysis
or an equivalent report, must be completed for all system development efforts as described in
Chapter 1, section 1.4. If the selected option is a manual solution, it is not strictly necessary to
complete the report shown, since justification for a manual process is not required. Nevertheless,
it is recommended that basic elements of the documentation be retained for future reference.
It should be remembered that the benefit-cost analysis is an evolving document and that
benefits/costs will change as the project progresses and becomes better defined. Therefore, for
those efforts which proceed to the design, development and implementation phase the benefit-cost
analysis will require updating.
Additionally, at me conclusion of this phase, if the system development effort appears to be
viable and proceeding to design, development and implementation, there are certain management
actions which must be taken, including:
* Appointment of a project manager and team
Consideration of establishment of configuration management and quality assurance/
control mechanisms
* Development of a Project Management Plan (EEI-3).
4-2
-------
EPA System Design and Development
Guidance: Volume B
The Project Management Plan is an extremely important document and will set out how the
system development effort will be accomplished, especially focusing on resources and scheduling
as well as other factors. Appendix A, EEI-3, provides a representative outline for a Project
'agement Plan.
4-3
-------
-------
Chapter Five
SUMMARY
5.1 PRELIMINARY DESIGN AND OPTIONS ANALYSTS OUTPUTS
The outputs, documents and results of the Preliminary Design and Options Analysis are:
EEI-2, Preliminary Design and Options Analysis
EE3-3, Updated Project Management Plan
* Detailed supporting documentation and work papers
« Summaries of available options, benefits and costs
» Operational and technical feasibility analysis
Functional requirements analysis worksheets
5.2 NEXT STEPS
The Preliminary Design and Options Analysis represents another major milestone. As
such, it is most important to ensure recommendations resulting from this analysis receive formal
management endorsement before proceeding to the next step.
If the option analysis and subsequent Project Management Plan indicate that an automated
system should be developed, either wholly or in part, then the next steps would be System Design,
System Development, and System Implementation as outlined in Volume C. Otherwise, the
program manager should develop the written guidelines and procedures that outline the
recommended approach for conducting the process using non-automated methods.
5-1
-------
-------
Appendix A
ESSENTIAL ELEMENTS OF INFORMATION
This appendix provides a representative outline of the document mat will be developed
during the Mission Needs Analysis phase.
A.1 INTRODUCTION
The documentation requirements contained in this appendix apply to all software
development or modernization projects, regardless of size, complexity or origin. At a minimum,
these standards apply to all new software development projects. Maintenance and/or enhancements
to existing information systems must comply with the requirements set out in Chapter 1, section
1.4 of Volume A, Mission Needs Analysis.
Compliance with the standards and conventions provided in this appendix will ensure tfiif
roduced for all system development projects.
The
4gfiflf«f in thfa appendix is:
EEI-1»»Mission Needs Statement
The following milestone chart illustrates the relative initiation and completion of each
document with respect to the software development life cycle, its major phases, and the span and
scope of Volumes A, B, and C.
A.I
-------
EPA System Design and Development
Guidance: Volume B
DOCUMENTATION VERSUS LIFE CYCLE
s
o bl
1.
" b«J «« § =
i 3 ~ i i ^ ** *
X* CO rtj MM hM LJ 4J MM MM MM
g JjJ fj " -*---
cl
I
2
WH UM ..
uu I
S5 I
^
0) »**
8tl
8
« £
u
A-2
-------
EPA System Design and Development
Guidance: Volume B
EET-2
PRELIMINARY DESIGN AND OPTIONS ANALYSIS
EXECUTIVE SUMMARY
2.
Background
System Concept
Option Summary .
Results of Options Analysis
INTRODUCTION
1.1 Background
1.2 Current System Description
1.3 Results of Mission Needs Analysis
1.4 Scope and Purpose
OPTION DESIGNS "
2.1
2.2
System Concept, Management Requirements and Functional Requirements
Summary
Operational Requirements Summary (General system requirements like security,
etc.)
2.3 Option Descriptions
2.3.1 Option 1
2.3.2 Option 2
2.3.* ~
3. OPTIONS ANALYSIS
3.1 Summary of Option Life Cycle Benefits
3.2 Summary of Option Life Cycle Costs
3.3 Life Cycle Benefit-Cost Analysis
3.4 Summary of Risks and Contingencies by Option
4.
OPTION RECOMMENDATION (WITH RATIONALE)
A-3
-------
EPA System Design and Development
Guidance: Volume B
PROJECT MANAGEMENT PLAN
EXECUTIVE SUMMARY
1.
2.
3.
4.
5.
6.
7.
8,
Background
System Description
Funding/scheduling
AccompIishmentPlan (including Pi
Risk
INTRODUCTION
1.1 Background
1.2 Current System Overview
System Description
Project Team and Support
rement)
3.1
3.2
3.3
3.4
Roles and Responsibilities
Configuration Management
Quality Assurance/Control
Quality Assura
Procurement Plan
Project Schedule and Task Description
Project Budget and Funding
Test Plan Requirements/Constraints
Project Constraints
Documentation£tandards
8.1 Policy Events
8.2 Forms and Clearances
A-4
-------
United States Office of Information
Protection BWffffTCfH Mfrfl fl
Washington DC 20460 June 1989
EPA SYSTEM DESIGN &
DEVELOPMENT GUIDANCE:
VOLUME C:
SYSTEM DESIGN,
DEVELOPMENT
AND IMPLEMENTATION
-------
-------
Volume C
EXECUTIVE SUMMARY
This document defines the process and documentation that system developers prepare
during the System Design and Development phase of the system life cycle. The objective of this
document is to provide guidance towards satisfying requirements specified in EPA's IRM Policy
Manual for the acquisition and management of information technology.
The guidance within this document is intended to provide system developers with specifics
concerning software program management, design and related documentation. The objective of the
Software Management Plan, outlined in this document, is to ensure the quality of EPA software
design, development^ implementation and maintenance efforts. The EPA Software Management
Program is based on six software engineering elements that include policies, standard software
tools, procedures/ methods, guidelines, planning, and oversight and compliance.
V
Completion of the steps and documentation outlined in this document will result in an
automated system that solves a specific problem as oudined in EEI-1, the Mission Needs
Statement Accompanying the automated system will be a sufficient quantity of documentation that
detail inputs, outputs and processes within the system. The rationale behind all the documentation
requirements is to assure program managers and OIRM staff that the delivered system fulfills its
user's requirements, utilizes EPA accepted standards and procedures, and is within the guidance,
limitations and constraints imposed on the Agency by OMB, GS A and the Congress of the United
States.
The following exhibit describes the complete software life cycle. Each phase in the
software life cycle is represented by a bubble with its corresponding tide on the inside of the circle.
Factors that influence each phase are shown surrounding each circle. The scope of this document
covers three separate phases, System Design, System Development and System Implementation.
As indicated, factors that influence the System Design phase are programming language
constraints, detailed user requirements, data requirements, and the physical environment and the
preceding bubble, die Preliminary Design and Options Analysis. The next phase discussed in this
volume, System Development, is influenced by the output from the System Design phase and the
external influences of development resources, programming standards and development tools. The
final phase detailed in this document is System Implementation. As indicated, factors that
influence this phase are die outputs from the System Development Process, and external factors
such as OMB certification, operations constraints and user acceptance of the delivered product
-------
EPA System Design and Development
Guidance: Volume C
COMPLETE SOFTWARE LIFE CYCLE
ti
-------
EPA. System Design and Development
Guidance: Volume C
TABLE OF CONTENTS
Tide Page
1. INTRODUCTION 1-1
1.1 Background 1*1
1.2 Objectives of the System Design and Development
Guidance 1-3
1.3 Authority 1-4
1.4 Applicability of the Guidance 1-4
1.5 Documentation Requirements 1-6
1.6 Assistance and Support Available 1-8
2. SOFTWARE MANAGEMENT AND ENGINEERING
COMPONENTS PROGRAM 2-1
2.1 Applicability to Small and Large Projects .2-1
2.2 Quality Software 2-2
2.3 Software Management Program Overview 2-3
2.4 Software Engineering Components .>. .2-4
2.4.1 Standards 2-4
2.4.2 Procedures/Methodologies 2-5
2.4.3 Computer-Aided Software Engineering Tools 2-5
2.4.4 Quality Assurance 2-5
2.5 Software Engineering Principles 2-5
2.5.1 Determining Documentation Requirements 2-7
2.5.2 Software Life Cycle Reviews 2-8
ill
-------
CPA System Design art Development
Guidance: Volume C
SOFTWARE DEVELOPMENT STANDARDS
3-1
3.1 Standard Programming Languages 3-1
3.1.1 Programming Language Selection Guidelines......;........,.3-l
3.1.2 Source Program Design and Coding Conventions 3-8
3.2 EPA Standard Specialized Software Tools..... ........3-8
3.3 Hardware/Software Environments 3-9
4. SYSTEM DESIGN, DEVELOPMENT AND
IMPLEMENTATION OVERVIEW 4 -1
4.1 System Design Stage :....4-l
4.1.1 System Detailed Requirements Analysis ....4-3
4.1.1.1 Activities . 4-3
4.1.1.2 Documentation 4-4
4,1.1.3 System Requirements Review 4-5
4.1.1.4 Functional Baseline i 4-5
4.1.2 Preliminary Design 4-5
4.1.2.1 Activities .4-5
4.1.2.2 Documentation 4-8
4.1.2.3 Preliminary Design Review. .4-8
4.1.2.4 Preliminary Design Baseline 4-9
4.1.3 Detailed Design 4-9
4.1.3.1 Activities ,.....,...4-9
4.1.3.2 Docurrentation 4-10
. 4.1.3.3 Critical Design Review 4-11
4.1.3.4 Design Baseline ....; 4-11
-------
EPA System Design and Development
Guidance: Volume C
4.2 System Development Stage 4-12
4.2.1 System Production and Programming 4-12
V1
4.2.1.1 Activities 4-12
4.2.1.2 Documentation 4-13
4.2.1.3 System Production and Programming
Reviews 4-14
4.2.1.4 Product Baseline..... 4-14
4.2.2 System Integration, Test and Evaluation 4-14
i
4.2.2.1 Activities 4-15
4.2.2.2 Documentation 4-15
4.2.2.3 System Integration, Test and
Evaluation Reviews 4-16
4.2.2.4 Operational Baseline ,...4-16
4.3 System Implementation Stage 4-17
4.3.1 System Installation 4-17
4.3.1.1 Activities 4-17
j
4.3.1.2 Documentation 4-17
4.3.1.3 System Implementation Review 4-18
4.3.2 System Operations and Maintenance 4-18
5. SUMMARY 5-1
5.1 System Design, Development and Implementation Outputs 5-1
5.2 Next Steps 5-1
Appendix A
Essential Elements of Information A-l
-------
EPA System Design and Development
Guidance: Volume C
LIST OF EXHIBITS
1-1 Guidance Audience ........................... . .................. '... ................ 1-2
1-2 EPA System Development Life Cycle and Decision Process ................. 1-5
1-3 System Category/EEI Matrix [[[ 1-9
2-1 EH Requirements for Type I Systems ....................................... ....2-9
2-2 EEI Requirements for Type D Systems .................................. . ....... 2-10
2-3 EEI Requirements for Type in Systems ......................................... 2-11
3-1 EPA Standard Application Programming Languages. .......................... 3-2
3-2 Software Support Tool Selection Matrix: Small Systems ...................... 3-5
3-3 Software Support Tool Selection Matrix: Medium Systems .............. .....3-6
3-4 Software Support Tool Selection Matrix: Large Systems .................. ;...3-7
3-5 EPA Standard Specialized Software Tools. .................. . ................. 3-10
3-6 Agency-Supported Hardware and Software ................... . ................. 3-11
-------
Chapter One
INTRODUCTION
Pursuant to the Environmental Protection Agency's IRM Policy Manual, this volume is the
last of three volumes which provide guidance for Agency system design and development efforts.
This volume provides guidance for the last phase of the EPA system development process The
System Design, Development and Implementation.
/
4
Volume C is intended for use by system developers, including Agency staff and
contractors, who are actually responsible for system development It therefore provides detailed
guidance for conducting automated system development activities to help insure compatibility and
uniformity EPA-wide. Exhibit 1-1 on the next page identifies the intended audience of this
volume.
I.I BACKGROUND
The Environmental Protection Agency expends millions of dollars each year on the design,
development, implementation and maintenance of major environmental and administrative systems
vital to EPA's programs and administrative functioning. Management of these resources is
becoming increasingly complex, since the rapid development of information technology in recent
years has dramatically increased computer capacity and user accessibility. The result has been two-
fold:
\
* An increasing number of system development efforts by managers and staff at all
organizational levels who, because of access to their own equipment, develop their own
systems independently of Agency system's staff
A wide range of hardware/software options for implementation of any specific system
concept or design.
Therefore, there has been a proliferation of system development efforts by a broad range of users
with varying levels of sophistication in making development decisions and conducting
development efforts.
1.1
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT M
GUIDANCE AUDIENCE
PROJECT
DIRECTOR
PROJECT
MANAGER
.'. '
SYSTEM
MANAGER
SENIOR
ANALYST
MID-LEVEL
ANALYST
JUNIOR
ANALYST
1-2
-------
EPA System Design & Development
Guidance: Volume C
s
1.2 OBJECTIVES OF THE SYSTEM PESTfiN AND DEVELOPMENT GUIDANCE
Within EPA's Office of Administration and Resources Management (OARM), the Office of
Information Resources Management (OIRM) is responsible for ensuring the effective and efficient
use of EPA's information resources including automated system design, development and
maintenance. OIRM*s objective in this endeavor is to provide guidance, assistance, and only when
necessary, controls, to assure that the Agency's considerable information resources are utilized
cost-effectively for the overall benefit of the Agency. To this end, OIRM has developed umbrella
policies guiding information system development and acquisition (see Information Resources
Management Policy Manual). This three-volume set of guidelines and standards for system design
and development is a part of OIRM's Software Management Series which is intended to assist EPA
in efforts to develop and manage software effectively. This series will also include future guidance
documents related to software management
This document is the third of the three-volume set The volumes cover the following:
Volume A - Mission Needs Analysis is designed to provide program'managers
and staff with a suggested methodology for assessing and evaluating the need
(requirement) for an information system. Applying the methodology in this volume will
result in: 1) confirmation that a need (requirement) exists and, 2) provide a preliminary
operational specification of the requirement
Volume B - Preliminary Design and Options Analysis is directed towards
program managers and staff. It provides guidance and a methodology for structuring
design options for meeting the requirement defined in Volume A and provides guidance for
selecting the most cost-effective option,
Volume C - System Design. Development and Implementation is intended for use
primarily by system developers and provides specific guidance and standards which must
be adhered to when undertaking automated system design and development efforts.
Together these three volumes provide comprehensive guidance and standards for the orderly and
cost-effective development of automated systems. Exhibit 1-2 depicts the flow of the development
life cycle and decision process for the three volumes.
1-3
-------
EPA System Design & Development
Guidance: Volume C
In addition to the System Design and Development Guidance, OIRM is currently drafting
the EPA Information Security Manual As security issues are raised and addressed throughout the
system development life cycle, the security manual should be consulted for proper Agency policy
and guidance.
1,3 AUTHORITY
The EPA System Design and Development Guidance derives its authority from Chapter 4
of the IRM Policy Manual, entitled "Software Management," which establishes the Agency
Software Management Program. The guidance serves as the primary guidance for Agency system
design and development efforts.
1.4
APPLICABILITY OFTHE GUIDANCE
Senior Agency managers and responsible staff should read the guidance and become
familiar with the decision-making process involved with system design and development efforts.
They are responsible for ensuring adequate analysis and documentation to support all critical
decision points. The full documentation requirements for automated system development efforts,
which mual be followed to conform to OARM policy, are fully discussed in Volume C
In general, Volumes A and B are intended to assist program offices and/or users in
conducting their own initial studies of system requirements, needs, option feasibility and cost*
effectiveness. In this context, the term "system" in Volumes A and B refers to a systematic set of
processes and/or procedures which can be used to meet the information needs of a user. It does
IM imply that the "system" will be an automated system.
v.
Volume C, however, presumes that an automated or partially automated solution has been
selected as a result of the Volume B options analysis. Volume C provides guidance and standards
for automated system development efforts. If the automated system is a relatively small application
on a microcomputer targeted for use within a single office (a "user owned information system").
Volume C provides simplified requirements for system design, development and implementation.
If the proposed system is a larger application (mainframe or minicomputer), which is mission
critical or involves multiple offices and organizations, Volume C provides the full set of guidance
and standards which must be followed by system developers. This will assure uniform, cost
effective system development in accordance with EPA policies, guidelines and standards.
1-4
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 1-2
EPA SYSTEM DEVELOPMENT LIFE CYCLE
AND DECISION PROCESS
DEVELOPMENT STAGE
DECISION/RESULT
C
Real World
Mission Need
J
.Volume A
Analysis
REQUIREMENT AND
OPERATIONAL CONCEPT
DEFINITION
, Volume B.,
Prel£minory Design
Options Analysis
OPTION DESIGN. BENEFIT/
COST ANALYSIS. AND
OPTION SELECTION
Volume C,
System Design*
Development
Implementation
FULLY IMPLEMENTED
SYSTEM
1-5
-------
EPA System Design & Development
Guidance: Volume C
1.5 DQTTTMENTATION
In general, die intent of the three volume System Design and Development Guidance is to
provide a consistent 'focus for system development efforts which will allow both EPA program
managers and OARM managers to cost-effectively develop and maintain the Agency's systems.
To achieve this goalt certain documentation requirements termed "Essential Elements of
Information" (EEI) documents, must be met Observance of this guidance in preparing EEFs
should result in proper documentation for audits. The EEI's will also serve as a helpful reference
for conducting post-evaluations of the system decision making process. Each volume contains an
appendix which outlines die required EEI documentation.
For certain system development efforts OIRM and office Senior Information Resources
Management Officials (SIRMOs) must be involved in a review capacity to fulfill EPA's IRM
Policy Manual requirements. Systems falling into one or more of the following categories must
have OIRM/SIRMO review involvement:
* EPA mission critical
States, local governments or other Federal agencies involved
Interorganizarional involvement (e.g., between Assistant Administratorships or
including Regional Office involvement)
* Costs for system development/enhancement are projected to exceed $250,000
(excluding costs associated with long-term system operation and maintenance)
Information security issues involving the three general security areas: applications
security, installation security and personnel security. In total, information security
involves die precautions taken to protect the confidentiality, integrity and availability of
information
* Privacy Act or confidential business information involved.
For system development efforts falling into any one of these categories, OIRM and office
SIRMOs must be involved beginning with a review of EEI- 1, generated at the conclusion of the
Mission Needs Analysis, as described in this volume of die EPA System Design and Development
1-6
-------
EPA System Design & Development
Guidance; Volume C
Guidance. OIRM/SIRMO review involvement will continue through the development life cycle of
these systems and will include all EEI documentation requirements for such systems. For systems
not falling into one of the above categories, EEI's may be forwarded to OIRM/SIRMOs for
information and review as they are developed. .
A review cycle should be developed to monitor each EEI preparation. Hie review cycle
could include several stages, such as a series of status briefings for management, focus groups,
and/or distribution of die EEI in draft form. Throughout the review cycle, the managers and users
involved should be informed of the process and content of the EEL When the final document is
completed, a consensus among management should be reached before developing the next EEL
It is not OIRM's intent to burden EPA managers with a host of documentation requirements
for each system development effort The EEIs simply stress typical documentation requirements
and their outlines highlight major topics that need to be considered for any system development
effort Managers may use their professional judgment in substituting, combining, or down-scaling
the content of die EEIs to meet the unique requirements of their project
Criteria for determining the minimum EEI documentation for a specific process during the
design, development and implementation phase is based on the nature and scope of the information
process and its importance to EPA's mission. Three types of categories describing various
systems with differing levels of EEI documentation requirements are identified as follows:
« TYPE I: M^far Agency /Widely Accessed Information System; An information process
that requires special attention because of its importance to an Agency mission; its high
development, operating, or maintenance costs or its significant impact on administration
of Agency programs or; is widely accessed by a combination of EPA Headquarters,
Regional Offices, state and local users and/or Federal agencies.
TYPE II: Localized Information System: An information process that is not a Major
Agency Information System but significantly supports accepted program goals and
missions and is accessed primarily by users in one major area, e.g., EPA
Headquarters, a single Agency program, or a Region.
TYPE HI: User Owned Information System: Unique, stand-alone process developed to
improve the efficiency or effectiveness of operations for a single user or a small group
of users.
1-7
-------
EPA System Design & Development
Guidance: Volume C
Documentation requirements for each of these categories are projected in Exhibit 1*3.
Automated systems involving information security will be subject to one additional documentation
requirement completion of a certification form (certification of sensitive systems is an OMB
requirement). Hie form, which is under development and will be issued as pan of the forthcoming
EPA Information Security Manual, will capture basic information on system sensitivity, security
requirements, security design, reviews, test scenarios, results and safeguards.
1.6 ASSISTANCE AND SU
/
Agency Program Management officials embarking on a system development effort should
be aware that there are at least two sources available to them for assistance and support during the
system development life cycle:
Within each AA/RA's office SIRMOs are available for assistance, support and guidance
relative to the EPA System Design and Development Guidance and other OIRM
guidance and standards
OIRM, with its general IRM management oversight role and requirements to exercise
procurement approval authority, has a staff organized to support EPA's administrative,
program and research communities.
It is appropriate to involve these support sources as early as is feasible in the system development
life cycle for most system development efforts.
The primary reasons for early involvement of SIRMOs and OIRM staff are:
Fulfilling EPA's IRM policy for system development review requirements .
Providing a value-added service role involving consultation, assistance, technical
standards, guidance and interpretation of requirements
t
* Expediting procurement for system development efforts which proceed to the system
design, development and implementation phase.
1-8
-------
EPA System Design & Development
Guidance: Volume C -,
EXHIBIT 1-3
SYSTEM CATEGORY
EEI MATRIX
TV^ System
\ ^**^ Category
EEI ^"Vs.
Requirements' ^"s^
EEM
Mission Needs
Analysis
EEI-2
Preliminary Design
and Options Analysis
EEI-3
Project
Management Plan
EEI-4
System
Implementation Plan
EEI-S
System Detailed
Requirements Doc.
EEI-6
Software
Management Plan
EEI-7
Software Test and
Acceptance Plan
EEI-8
Software Design
Document
EEI-9
Software Maint
Document
EEI- 10
Software Operations
Document
EEI -11
Software User's
Reference Guide
EEI- 12
System Integration
Test Report
Type
Type
II
Type
III
1*9
-------
EPA System Design & Development
Guidance: Volume C
Providing assistance in determining user needs as early as possible in the life cycle.
Achieving these objectives will strengthen EPA's system development efforts and avoid major
pitfalls that have beset system development efforts in other government agencies (e.g., project
stalls due to outyear funding shortages stemming from under-projected planning or project
disruptions due to failure to get hardware/software acquisitions into the procurement cycle
expeditiously and when required).
The remainder of Volume C provides guidance and standards for conducting the third
phase of the system development process - the System Design, Development and Implementation
phase.
1-10
-------
EPA System Design & Development
Guidance: Volume C
Chapter Two
SOFTWARE MANAGEMENT AND
ENGINEERING COMPONENTS PROGRAM
Implementation of the EPA Software Management Program draws on the experience of
software professionals within EPA and on the experience of the Federal Government through both
the Office of Information Resources Management, the General Services Administration and the
National Institute of Standards and Technology.
The objective of the Software Management Program is to ensure the quality with which
EPA designs, develops, implements and maintains software. The EPA Software Management
Program consists of the following Software Engineering Elements:
Policies
Standard Software Tools
Procedures/Methods
Guidelines
* . Planning, and '
Oversight and Compliance.
This volume specifically addresses standard software tools, procedures/methods, guidelines,
planning and oversight and compliance.
2.1 APPLICABILITY TO SMALL AND LARGE PROJECTS
The Software Management Program is designed to be applicable to both large and small
projects. Managers of specific projects must use their professional judgment (aided by the
guidelines provided in this methodology) on how to apply the Software Management Program.
For larger projects, the Software Management Program should be used in its entirety. For smaller
software projects, the Software Management Program should be adjusted to meet the needs of the
specific project. For example, a judgment might be made that the documentation requiremc its are
excessive for a particular project, so parts of different documents could be combined or eliminated
to reduce the number of documents and level of documentation required.
2-1
-------
EPA System Design & Development
Guidance: Volume C
2.2 QUALITY SOFTWARE
.*
The Software Management Program will produce significant results, including:
Improved inter-organizational relationships
- Demonstrated software engineering expertise
Improved user acceptance of final products
- Improved ability to react to changes
- Increased reliability of the software
- Improved maintainability of the software
Institutionalization of the software development process
- Enhanced technology transfer between projects
- Better utilization of personnel resources
- Reduced dependency on specific individuals
- Improved ability to measure and control software development for project
scheduling and cost purposes
- A production line approach to software development and maintenance
* Reduced cost of developing and maintaining software
Increased
productivity
- Fewer problems (errors) with delivered products
More easily enhanced software
Improved software portability
- Isolation of computer architecture dependencies
Elimination of non-standard source code
- Development of reusable source code
2-2
-------
EPA System Design & Development
Guidance: Volume C
The Software Management Program has been developed to assist personnel directly
involved in software development projects, including:
* Program Managers - It provides assurance that EPA will apply uniform, cost-effective
methods throughout its software life cycle projects. New projects need not produce
their own unique software management and development procedures, but, through the
Software Management Program, can benefit from the experience of successful software
development projects. " - "'"-'.
Project Managers It includes the "what, why and how" of software life cycle
management
. »
* Programmers and Analysts It describes specific tools arid techniques for 'the
software development life cycle.
2.3 SOFTWARE MANAGEMENT PROGRAM OVERVIEW
The EPA Software Management Program includes a system life cycle model, and for each
phase of the life cycle process, the software engineering components related to controlling and
regulating that phase. The Software Management Program has major inputs from Volumes A and
B of the System Design and Development Guidance series. These inputs are:
Phase 1 - Mission Needs Analysis
Mission Needs Statement (including Initial System Concept) is produced during the
Mission Needs Analysis phase.
- Phase 2 - Preliminary Design and Options Analysis
Preliminary Design and Options Analysis Document and a Project Management Plan are
produced during the Preliminary Design and Options Analysis phase.
The Software Management Program defines the following additional phases of the system.life'
cycle: t . ..::";...'':
Phase 3 - System Design, Development and Implementation
Phase 4 - Operations and Maintenance.
2-3
-------
EPA System Design & Development
Guidance: Volume C
Detailed discussions of the System Design, Development and Implementation phase aze contained
in Chapter 4 of this document. The Operations and Maintenance phase of the system life cycle is
discussed in OIRM's Operations and Maintenance Manual
2.4
NGINEER TNft COMPONENTS
This section addresses the software engineering components necessary to successfully
implement the EPA Software Management Program during the EPA software development life
cycle phases and the quality assurance considerations for successful software development
There are four software engineering components that direct, control or support each of the
life cycle phases and are essential to the successful execution of each phase. These software
engineering components are:
Standards
Procedures/methodologies
Software Development Support Tools
Quality Assurance.
Each life cycle phase is supported, in different degrees, by the four software engineering
components. These components provide the necessary technology and discipline to create a
software engineering environment
2.44
Standards are grouped in two major categories: methodology standards (uniform
procedures for accomplishing a function) and performance standards (metrics to evaluate
performance).
Methodology standards allow work to be accomplished systematically. They facilitate the
turnover of work whether it is from personnel working in one life cycle phase to those working in
another life cycle phase or among personnel working on the project Personnel trained in the
Software Engineering Program should be able to join a project at any time and become productive
soon thereafter.
2-4
-------
EPA System Design & Development
Guidance: Volume C
Performance standards deal with the quantifiable aspect of a task, for example, the amount
of time it should take to perform a task and the expected quality of the task's end product.
Performance standards depend-on methodology standards being in place and enforced so that
performance can be measured accurately.
2.4.2 Procedures/Methodologies
Procedures/methodologies define the processes that are followed in each of the particular
phases of the system development life cycle.
The two classes of procedures are manual and automated. Manual procedures, which
programmers and analysts follow when performing a task, direct the flow of activities. For
example, a programming procedures manual provides the direction for achieving progress using
the proper programming language elements, associated structured techniques and source code
formatting. Automated procedures; on the other hand, direct the execution of computer programs
and software development support tools.
2.4,3 Computer-Aided Software Engineering Tools
Computer-aided software engineering (CASE) tools are computer programs used by
system developers which automate several of the labor-intensive activities including project
management, design and coding. One distinct advantage of using CASE tools is the
standardization they enforce over the entire development effort. This standardization eliminates the
concept of a "key" manager or programmer and enables new staff joining the project to be
productive at any stage of the development life cycle. CASE tools support EPA's standards,
procedures and methodologies and should be used, if appropriate, by contractors and EPA staff in
the software development and maintenance efforts.
2.4.4 Quality Assurance
Quality Assurance is the formal process of measuring or evaluating the degree to which a
product meets the standards by which it was developed and the specifications upon which it was
based. Each product (both software and documentation) produced within each life cycle phase
should be subjected to a Quality Assurance process
2.5 SOFTWARE ENGINEERING PRINCIPLES
Effective system development requires a thorough understanding of the user's requirements
coupled with a development process capable of fulfilling those requirements with a responsive
2-5
-------
EPA System Design & Development
Guidance: Volume C
system. A clear understanding must be established of the user's requirements, their relationship to
the overall system and the functional elements constituting the system. The EPA Software
Management Program provides an approach to software development that divides the life cycle into
well defined phases.
The Software Management Program indicates the activities and tasks that should be
performed for each phase of the life cycle and the resulting deliverables. It also identifies what has
to be done, when it should be done and how it should be done.
The Software Engineering Program defines the Essential Elements of Information (EEIs) or
documentation that should be produced and/or updated. The baselines for each phase and reviews
necessary to approve the documentation are also defined in the Software Engineering Program.
The characteristics of an evolving system are defined and documented in increasing detail at
logical transition points, or baselines, of the software development life cycle. Approved
documentation and/or software products constitute a baseline. At any time in the system life cycle,
all previously established baselines, together with any approved changes to these baselines,
constitute the formal identification of the system and its components.
The type of system being developed will dictate the level of documentation necessary to
support that system. The diligent use of EEIs will resolve die conflicts that arise between the:
Cost of documentation
* Classical life cycle for system development
* Changes in computing capabilities and system development techniques.
The use of the EEIs defined in this volume represent a flexible approach to system
documentation. All systems require some form of documentation. However, the degree of
documentation needed is dependent on the nature of the system, constituency (who will use it), and
life cycle costs. Software systems that are used nationwide. Agency wide and support major
program initiatives require complete documentation and thoughtful consideration of options, life
cycle costs and mission needs.
2-6
-------
EPA System Design & Development
Guidance: Volume C
Key points to consider are:
A mission needs analysis and a requirements analysis which includes feasibility and
benefit-cost analyses must be conducted prior to embarking on a major agency
information system development effort
EEIs are required for both new systems and existing systems.
* The EEI outlines contained in Appendix A of this volume represent the basic EEI
requirements (see section 1.6 for the minimum EEI requirements for the different sizes
and types of systems). Information managers may want to increase the depth and
breadth of these PFT« based on the circumstances of the project For example:
- Elements not included in a particular EEI outline that are considered necessary
within . specific project may be added, thus tailoring the EEI for that specific
project .
Additional EEIs may have to be developed to meet the specific needs of a given
software system or project
2.5.1 Determining Documentation Requirements
Criteria for determining the minimum EEI documentation for a specific software system are
based on the nature and scope of the information system and its importance to EPA's mission.
Four types of systems are presented below along with guidance for determining the minimum level
of EEI documentation for each:
a. Type I
1 "Major Agency Information System: An information system that requires special
continuing management attention because of its importance to an agency mission, its
high development, operating, or maintenance costs or its significant impact on
administration of agency programs.
In this context, a system which requires obligations of more than $500,000 per year
to maintain or whose software component contains more than 500,000 lines of 3GL
source code or 100,000 lines of 4GL source code is considered a Major Agency
Information System.
2-7
-------
EPA System Design & Development
Guidance: Volume C
Accessed Infqpnarion System: An information system that is hot a Major
Agency Information System, (but significantly supports accepted program goals and
missions). It is widely accessed by a combination of EPA Headquarters, Regional
Offices and/or State and local users and other Federal agencies.
Exhibit 2-1 presents the EETs required for Type I information systems which include
both Major Agency Information Systems and Widely Accessed Information Systems.
b. Tvpen
Localized Information System: An information system that is not a Major Agency
Information System, but significantly supports accepted program goals and missions.
It is accessed primarily by users in one major area, e.g., EPA Headquarters, a single
agency program, or a Region.
Exhibit 2-2 presents the EEIs required for Type n, Localized Information Systems.
c. Tvpem
User Owned Informatiop System: Unique, stand-alone system developed to improve
the efficiency or effectiveness of operations for a single user or a small group of
users. . .
Exhibit 2-3 presents the
Systems.
2.5,2 Software Life Cvcle Reviews
required for Type IH, User Owned Information
Formal reviews are carried out at key points in the life cycle to ensure that the software
development activities are progressing consistent with user requirements and EPA standards. The
reviews used in the EPA System Development life cycle are described in detail in Chapter 4.
2-8
-------
EPA System Design & Development
Guidance: Volume C
Exhibit 2-1
EEI REQUIREMENTS FOR TYPE I SYSTEMS
Jl
iiij
A "S
1
Q
*
I
I
ill!
ill! i!
DOCUMENTATION
REQUIREMENTS (EEIs)
2-9
-------
EPA System Design & Development
Guidance: Volume C
Exhibit-2-2
EEI REQUIREMENTS FOR TYPE II SYSTEMS
1
1
2
1
i
,§
I
*I
ill
Is,
i,
DOCUMENTATION
REQUIREMENTS (EEIs)
2-10
-------
EPA System Design & Development
Guidance: Volume C
Exhibit 2-3
EEI REQUIREMENTS FOR TYPE III SYSTEMS
if
!
a
»
ii
1;
I!
DOCUMENTATION
REQUIREMENTS (EEIs)
2-11
-------
-------
Chapter Three
SOFTWARE DEVELOPMENT STANDARDS
This chapter addresses the software development standards that have been approved for use
in the development of EPA information systems. They include standard 3rd and 4th generation
programming languages, data base management systems, specialized software tools, graphics
packages and telecommunications support software.
3.1
STANDARD PROGRAMMING LANGUAGES
EPA standard programming languages have been established for developing software
systems for use within EPA. These include the 3rd generation programming languages (3GLs)
that have been standardized by the American National Standards Institute as national standards and
by the National Institute of Standards and Technology as Federal Information Processing
Standards.
In addition, EPA has internally standardized several 4th generation programming languages
(4GLs) in the interest of improving productivity and reducing the cost of software development
and maintenance within the agency. Development and maintenance requirements should be
evaluated in relationship to the costs and benefits of using 3GL and 4GL languages. This
evaluation will determine which language is most beneficial for system development based on total
system life-cycle considerations. Exhibit 3-1 presents the standard programming languages used
within EPA.
3.1.1 Programming Language
Guidelines
A number of factors go into deciding in which computer environment an application will
operate. After the computer hardware configuration has been identified, the application
programming language and associated support software tools must be selected. While there is no
"right" answer for each information system being developed, the use of common sense and the
guidelines presented in this volume can lead to a reasonable solution.
Software developers should consider the following questions:
* Is an off-the-shelf solution available?
3-1
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 3-1
EPA STANDARD APPLICATION
PROGRAMMING LANGUAGES
APPLICATION SOFTWARE
PROGRAMMING LANGUAGE
3GL
4GL
COBOL
FORTRAN
PL/I
PASCAL
INFO
NATURAL
FOCUS
dBASE III
SAS
STANDARD
EPA
Yes
Yes
Yes
Yes
Yes
Yes
Yes
5 Yes
Yes
FIPS
Yes
Yes
Yes
Yes
3-2
-------
EPA System Design & Development
Guidance: Volume C
* Has OIRM staff advice been solicited?
Can the application be satisfied by using an existing system or its software (e.g.,
software reuse, off-the-shelf software, consulting the EPA Information System
Inventory)? .
Some of the factors which should be addressed when determining the hardware/software
environment are:
Results of the requirements and feasibility studies
Potential life span of the application
Resources available now and in the future to support both the development and
maintenance of the application
Telecommunications and local communications facilities
» Location and size of the data base(s)
'v
Number of users / Number of simultaneous users
* Complexity of the data '
Information security needs such as access controls, backup, and recovery.
In an attempt to reduce the complexity of this effort, EPA has defined the computer
hardware/software environments available for use. As a guideline, a decision matrix approach to
identifying what software support tools are appropriate has been defined.
The decision matrices can be used to help determine the support tools appropriate to system
development in the absence of OIRM staff guidance. The matrices apply only to the general
systems which store and retrieve information and should not be construed as taking precedence
over existing EPA system plans, strategies and policies. Also they do not encompass statistical
systems, spread sheet systems, graphics systems and other specialized functional systems. With
3.3
-------
EPA System Design & Development
Guidance: Volume C
minor exceptions, they do not address hybrid systems - those which are developed using two or
more support tools (e.g., NaturaJ/VSAM for data entry and NaturaJ/ADABAS for data retrieval).
The Software Support Tool Selection Matrices, as depicted in Exhibits 3-2, 3-3 and 3-4,
address systems that are small, medium, and large. Size is defined by the number of records
processed or total storage requirement.
Small Systems - are generally programmed using 4GLs with or without data base
support, and they can run in either the mainframe, minicomputer or microcomputer
environments;
Medium Systems - are generally programmed using either 3GLs or 4GLs with or
without data base support, and they can run in either the mainframe or minicomputer
environments:
Large Systems - are generally programmed using either 3GLs or 4GLs with or without
data base support, and they run in the mainframe environment
The content of each matrix cell and the criteria of small, medium and large systems are
simplified to make them useful. There are several decision criteria along the legs of the matrices
and numbers in the intersections of the rows and columns which correspond to the software
support tools. The key for the software support tools is:
1 -Mainframe
2-Mainframe
3-Mainframe
4-Mainframe
5 - Minicomputer
6 - Minicomputer
7 - Microcomputer
8^ it :.*_» *M i, ... ..._
- iVucrocompuier
Q X>f: >._ ...
3GL
4GL
4GL
4GUDBMS
any
3GL/DBMS (COBOL, PL/I, FORTRAN)
4GL/DBMS (Natural/ADABAS)
4GL (FOCUS)
4GL (NATURAL/VSAM)
(COBOL, FORTRAN, PASCAL)
(FOCUS, INFO)
(INFO, FOCUS, dBASE HI)
(dBASE HI)
(FORTRAN, PASCAL)
3-4
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 3-2
SOFTWARE SUPPORT TOOL SELECTION MATRIX
SMALL SYSTEMS
SMALL SYSTEMS -f RECORDS <10K OR
Number of Simultaneous Users
Complex Random Retrievals?
Location
of Related
Data
s
None
Main-
Frame
Mini-
Computer
PC
I
YES
2.3.6,7
2.3
6
7.8.9
NO
2.3.4.6.7
2.3.4
6
7.8.9
. TOTAL SIZE < 10 1
1< n < 15
YES
2.3.6
2.3
5.6
2.3.6
NO
2.3.4.6
2.3.4
5.6
2.3.4.6
1
;;
dEGABTTES i
>15 j
YES
2 .
2
2
2
'.
A
NO |
s
:-
if
2.3.4 i
s
j
2.3.4 j
i
2,3,4 ' j
2.3.4 |
Notes:
1 - Mainframe
3 -Mainframe
4 - Mainframe
5 - Minicomputer
6 - Minicomputer
7 - Microcomputer
8 - Microcomputer
9 - Microcomputer
3GL/DBMS (COBOL, PL/I. FORTRAN)
4G1VDBMS (Natural/ADABAS)
4GL (FOCUS)
4GL (NATURAL/VSAM)
3GL (COBOL, FORTRAN. Pascal)
4GL (FOCUS. INFO)
4GL (INFO, FOCUS, dBASEffl)
4GUDBMS (dBASEffl)
3GL (FORTRAN. Pascal)
3.5
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 3-3
SOFTWARE SUPPORT TOOL SELECTION MATRIX
MEDIUM SYSTEMS
MEDIUM SYSTEMS-10K
-------
EPA System Design A Development
Guidance: Volume C
EXHIBIT 3-4
SOFTWARE SUPPORT TOOL SELECTION MATRIX
LARGE SYSTEMS
LARGB SSSTCUS-
Volatility
Number of
Simultaneous Uaen
Complex Random
Retrieval*?
File
Pass
Frequency
n« 1
per day
I 4O
per day
X9||^^i[
%
m 9 REOORD0 2
100K OR TOTAL SEE > 100 MEGABYTES
Almost Static
(Update Weekly or Leu)
S 15
YES
2.3
2
Hybrid
1.3
NO
2.3.4
2.4
4
jgMt&&&£j&&g^g&33&iftMg
> IS
YES
2
2
Hybrid
1.2
aa&gajBE
NO
2.4
2.4
4
Moderate Amount of
Change or Volatile
S IS
YES
2
2
Hybrid
1.2
> 15
NO
2.4
2.4
4
Highly
Volatile !
S IS
YES
1.2
1.2
Hybrid
1.2
> 15
NO
1.2
1.2
Hybrid
1.2
^f;fi1faWf'fff^ffl^^Mff:^
Notes:
1-Mainframe
2-Mainframe
3-Mainframe
4 Mainframe
3GUDBMS (COBOL. PUT, FORTRAN)
4GL/DBMS (Natural/ADABAS)
4OL (FOCUS)
4GL (NATURAIWSAM)
3-7
-------
EPA System Deftgn & Development
Guidance: Volume C
3.1.2 Soureq Program Design and Coding
EPA has a general set of mi"'*""*" program design and program coding standards which
promote productivity, source code maintainability and software sharing and reuse. These
standards are patterned after die standards used by the Department of Defense. The salient
characteristics of these standards are:
* Use of structured programming constructs to control the flow of execution
Elimination or significant reduction in the use of "GO TO" statements and complicated
negative Boolean expressions
tf
. Applicability to 3GL and 4GL programming
* Modularity in source program design and coding
Good documentation practices such as:
- Naming conventions
- Symbolic parameters
- Paragraphing
- Blocking .
- Indentation of source code
- Single statement per line
- Intelligent use of comments
Error messages
3.2 EPA STANDARD SPECTAT .T7FD SOFTWARE TOOLS
The EPA has a number of specialized tools for use on its various computer hardware
configurations. The standard specialized software packages that have been approved for use in the
development of EPA software systems are presented in Exhibit 3-5. For detailed information on
current software development standards contact OIRM or the National Data Processing Division
(NDPD).
3-8
-------
CPA System Design & Development
Guidance: Volume C
3.3 HARDWARE/SOFTWARE ENVIRONMENTS
The EPA hardware/software environments available for software development are
presented in Exhibit 3-6. This exhibit identifies the EPA software packages that are available and
the hardware environments in which each of the software packages is supported. The exhibit
provides a representative sample of available MS-DOS and Macintosh application software. The
Macintosh computer is included as a potential option for development of Localized (Type II) or
User Owned (Type El) information systems. Any software development effort which uses
software packages or hardware outside the EPA Hardware/Software Environments must have
approval from the Director, Office of Information Resources Management (OIRM).
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 3-5
EPA STANDARD SPECIALIZED SOFTWARE TOOLS
FUNCTION
Data Rase
Management
Graphics
Geographies
Spreadsheet
Word Processing
Text Processing
and Retrieval
Programmer Tools
Software
Maintenance Tools
Communications
Software
TOOL
ADABAS
DBASE HI PLUS
SASGRAPH
TELAGRAPH
VERSAGRAPH
ARC/INFO
UNIRAS
"S
LOTUS 1-2-3
20/20
SUPERCALC
LEXTTYPE
WORDSTAR
MULTI-MATE
TEXT
WORD MARC
BASIS
INFO-TEXT
ISPF
EMACS
LIBRARIAN
COBOL DEBUGGERS
PL/I DEBUGGERS
FORTRAN DEBUGGERS
SNA
DECNET
PRIMENET
GNcrn
PRfMEUNK
CROSSTALK
KERMIT
ARBITER
Bulk Data Transfer CBDT)
3270 PC FILE
TRANSFER (IND$FILE)
Data Transfer Facility (DTF)
INTEGRATED \
WITH
NATURAL !
SUPER. NATURAL
SAS 1
. s
INFO
INFO
,
J
^_
INFO-TEXT
INFO
i
|
!
1
1
- 'i
PRIME/PC Connection !
;
|
I
t
i
j
:
3-10
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 3-6
AGENCY-SUPPORTED HARDWARE AND SOFTWARE
TOOLS
3rd Generation:
COBOL
FORTRAN
PL/1
PASCAL
4th Generation!
INFO
FOCUS
NATURAL
SAS
DBASE in PLUS
EASYTRIEVE PLUS
fid fit Hair- Mt>yiarf«>im>i»«
ADABAS
Graphics Faculties:
TELL-A-GRAPH/Cuechart
VERSACRAPH
SASGRAPH
CRICKET DRAW
CRICKET GRAPH
MACDRAW
MACPAINT
Spreadsheet:
LOTUS 1-2-3
20/20
SUPERCALC
SAS/FSP
EXCEL
TARGET HARDWARE ENVIRONMENT
IBM
3090
IBM
43XX
DEC/
VAX
PRIME
.
'
MS
DOS
Mac-
Intoah
LAN
-
,
'
-
.
3-11
-------
EPA System Design & Development
Guidance: Volume C
EXHmiT3-6
AGENCY-SUPPORTED HARDWARE AND SOFTWARE
(CONTINUED)
TOOLS
ARC/INFO
UNIRAS (Pilot)
word ana Text software:
LEXTIYPE
WORDSTAR
MULTIMATE
WORDPERFECT
WORDMARC
BASIS
TEXTWP
INFO-TEXT
MACWRITE
MICROSOFT WORD
Project MaxHUtexneiit:
""
TELL-A-PLAN
MICROSOFT PROJECT
TIMELINE
Telecom Capabilities:
SNA(3270/RJE)
ASYNCH ASCn
X.25
PRIMENET
DECNET
CROSSTALK
KERMIT
GNET II
TARGET HARDWARE ENVIRONMENT
IBM -
3090
IBM
43XX
-
-
DEC/
VAX
1
-
PRIME
MS
DOS
Mac-
intosh
j
.
LAN
3.12
-------
EPA System Design & Development
Guidance: Volume C
EXHmiT 3-6
AGENCY-SUPPORTED HARDWARE AND SOFTWARE
(CONTINUED)
TOOLS
TARGET HARDWARE ENVIRONMENT
IBM
3090
IBM
43XX
DEC/
VAX
PRIME
MS
DOS
Mac-
intosh
LAN
Telecom Capabilities (Coot.):
PRIMELINK
NATURAL/CONNECTION
SAS/RLINK RTERM
3270 PC FILE TRANSFER (INDSFILE)
ARBITER
BULK DATA TRANSFER (EOT)
DATA TRANSFER FACILTTY (DTF)
NOVELL NETWARE
Electronic Mail;
DIALCOM SERVICE
LOCAL CAPABILITIES
I*mtrrninin«Mr P
-------
-------
Chapter Four
SYSTEM DESIGN, DEVELOPMENT, AND
IMPLEMENTATION OVERVIEW
This chapter addresses the third phase of the system development life cycle -r the System
Design, Development and Implementation phase and provides amplifying details on the three
stages which comprise this phase:
» System Design Stage» which comprises tasks and activities associated with System
Detailed Requirements Analysis; Preliminary Design and Detailed Design;
System Development Stage which comprises tasks and activities associated with
. System Production and Programming and System Integration, Test and Evaluation; and
System Implementation Stage - which comprises tasks and activities associated with
System Installation.
For each stage, this chapter presents the associated tasks and activities that must be accomplished
under each task. During each task, EEI documentation is prepared or revised. Also, indicated is
the status of EEI documentation that is affected during the task, Le., preliminary, update, final. At
the completion of each task, a review involving OIRM/SIRMO representation is accomplished.
Successful completion of the review establishes a baseline which becomes the foundation for
continued development under subsequent tasks. Exhibit 4-1, on the following page, overviews the
process.
EEI documentation requirements during the System Design, Development and
Implementation phase are discussed generally in this chapter. Detailed representative outlines for
each EEI (numbers 4 through 13) are contained in Appendix A. EEIs 1 through 3 were detailed
previously in Volumes A and B.
4.1 SYSTEM DESIGN STAGE
Associated tasks and activities include System Detailed Requirements Analysis, Preliminary
Design and Detailed Design.
4*1
-------
EPA System Design & Develop meat
Guidance: Volume C
Exhibit 4-1
EEI DOCUMENTATION
o
3
3
I
3
i
i
*
I
SYSTEM DESIGN, DEVELOPMENT AND IMPLEMENTATION
System Design
System
Detailed
Requirements
Analysis
EEI-4
EEI-5
EEI-6
System
Require-
ments
Review
Functional
Baseline
Preliminary
Design
EEI-7
EEI-8
Pre-
liminary
Design
Review
Pre-
liminary
Design
Baseline
Detailed
Design
EEI-8
Critical
Design
Review
Design
Baseline
System Development
System
, Production
and
Programming
EEI-9
EEMO
EEM1
Develop*
mentTest
And
Evaluation
Review
Product
Baseline
System
Integration,
Test and
Evaluation
EEM2
Opera-
tional Test
And Eval-
uation
Review
Opera-
tional
Baseline
System Implementation
System
Installation
User
Accept-
ance
System
Operation* and
Maintenance ,
4-2
-------
EPA System Design & Development
Guidance: Volume C
4.1.1 System Pe,TflJIc4 Requirements Analysis
The major inputs to this task are the: ,
Mission Needs Statement document produced during the Mission Needs Analysis
phase - defined in Volume A
Preliminary Design and Options Analysis Document and Project Management Plan
produced during the Preliminary Design and Options Analysis phase - defined in
Volume B.
These documents are used in performing the detailed requirements analysis for the software
system. The conclusions of these documents are confirmed by the software development staff that
will ultimately produce the software system.
This task entails further analysis of the problem, the definition of the functional
components of the major software and hardware elements of the system and association of
functional components to requirements. The scope of the software development project is revised,
if necessary, and further defined.
4.1.1.1 Activities
The activities associated with the System Detailed Requirements Analysis are:
Confirm the analysis of current systems that have been reviewed and their
adequacy/inadequacy for use in solving the problem
Confirm the alternative solutions that have been proposed and ensure that the selected
alternative is the one that should be used
Prepare die System Implementation Plan (EEI-4)
Identify events, actions and milestones
Identify resource requirements
- Review schedules and work plans
- Produce integrated project plan
4-3
-------
EPA System Design & Development
Guidance: Volume C
* Prepare the System Detailed Requirements Document (EEI-5)
Define major system functions
Define physical requirements
- Define security requirements
- Define quality requirements -
- Define life cycle resource requirements -.
Define testing and verification requirements
- Define project work schedule(s) and work plan(s)
x
Prepare the Software Management Plan (EEI-6)
Identify project resources
- Define review responsibilities
Identify organizational structure and required resources
- Establish project schedules, reviews and reporting controls
Implement risk management
- Implement software product assurance procedures
- Implement software development procedures for the project
While defining the System Detailed Requirements, a separate data dictionary document
should be prepared that lists and describes each data element to be referenced by the system.
Additional guidance on the content of the Data Dictionary Document is provided in OIRM's
Operations and Maintenance Manual.
4.1.1.2
Documentation
Documentation associated with the System Detailed Requirements Analysis includes;
System Implementation Plan
System Detailed Requirements
Document
Software Management Plan
EEI-4 (Final)
EEI-5 (Preliminary)
EEI-6 (Preliminary)
4-4
-------
EPA System Design & Development
Guidance: Volume C
4.1.1.3 System Requirements Review
The System Requirements Review is performed to ensure the adequacy of the system
requirements and approve formally the definition of the user's requirements. The System Detailed
Requirements Document is the primary subject of the review. The Software Management Plan and
the System Implementation Plan are also input to the review process.
The System Requirements Review takes place at the end of the System Detailed
Requirements Analysis task. A successful System Requirements Review results in the
establishment of the Functional Baseline. OIRM/SIRMO representatives should participate in the
System Requirements Review.
4.1.1.4 Functional Baseline
The Functional Baseline is established as the original baseline configuration and consists of
the functional system specifications contained in the System Detailed Requirements Document
(EEI-5). Once the System Detailed Requirements Document is basetined, any changes to that
document represent a change in the scope of the project and must have management approval. The
Functional Baseline is established after a successful System Requirements Review.
4.1.2 Preliminary Design
The Preliminary Design task represents the initial effort in producing a design that can be
used in developing an operational software product
v
4.1.2.1 Activities
The activities associated with Preliminary Design are:
Confirm that candidate packages/existing software can be used or integrated into the
new system
Prepare Software Design Document (EEI-8) . . .
- Identify each software design requirement
4-5
-------
EPA System Design & Development
Guidance: Volume C
- Identify the functional flow of the system, address each design requirement and
describe each requirement and associated software design functions (SDFs)
Detail each SDF by defining: _
- Inputs
Local Data
- Initiation, Timing and Sequencing
Interrupts
- Processing
.. Outputs
Adaptation
- Define Data Base and File Structures
-- Data Base Management System
-- Logical Design of the Data Structures /
Data Interrelationships
-- Characteristic/Requirements Traceability
Update Software Management Plan (EH-6)
Prepare preliminary Software Test and Acceptance Plan (EEI-7)
- Software Unit Test Plans
- Test Requirements
Test Management
- Test Schedule
-- Tests and Results
Integration Testing of Software Units, Modules and Software Functions - Test
Plans
- Integration Test Requirements
4-6
-------
EPA System Design & Development
Guidance: Volume C
Integration Test Management
-- Integration Test Categories
- Integration Test Methods
Integration Test Schedules
-- Integration Tests and Results
- Required Resources for Unit and Integration Testing
Facilities
Hardware Environment v
- Interface/Support Software
Personnel
- System Test Plans
~ System Test Requirements
-- System Test Management
System Test Categories
-- System Test Methods
System Test Schedules
- System Tests and Results
- User Acceptance Test Plans
- Test Team
. Pretest Procedures
Acceptance Test Procedures
Formal Acceptance
Address:
- Initial design of user procedures
- Conversion software and appropriate procedures
* Operations procedures.
4.7
-------
EPA System Design & Development
Guidance: Volume C
4.1.2.2
Documentation associated with the Preliminary Design task includes:
Software Management Plan
Software Test and
Acceptance Plan
Software Design Document
4.1.2.3
Preliminary Design Review
EEI-6" (Update)
EEI-7 (Preliminary)
EEI-8 (Final)
The Preliminary Design Review is performed for each system element to ensure the
adequacy of the preliminary design and the test plans for verifying the accuracy of the software
system. The Software Design Document and the Software Test and Acceptance Plan are the
primary subject of the review. The updated Software Management Plan is also input to the review
process.
The purpose of the Preliminary Design Review is to:
Evaluate the progress, technical adequacy and risk resolution (on a technical, cost and
schedule basis) of the selected design approach
* Determine the compatibility of the selected design approach with the requirements and
performance of the System Detailed Requirements Document
* Establish the existence and compatibility of the physical and functional interfaces
among the other elements (equipment, facilities, computer programs and personnel)
* Determine the adequacy of the test plans in accurately verifying the software system
against the design criteria.
The Preliminary Design Review takes place at the end of the Preliminary Design task. A
successful Preliminary Design Review results in the establishment of the Preliminary Design
Baseline. OIRM/SIRMO representatives should participate in the Preliminary Design Review.
4-t
-------
EPA System Design & Development
Guidance: Volume C
4.1.2.4 Preliminary Design Baseline
The Preliminary, Design Baseline is established after a successful Preliminary Design
Review. It consists of the initial design specifications - including data base specifications. The
Preliminary Design Baseline is made up of the Software Design Document (EEI-8) and the
Software Test and Acceptance Plan (EEI-7). Once these documents are baselined, any changes to
those documents represent a change -in the scope of the project and must have management
approval.
4.1.3 Detailed Design
The Detailed Design task represents the final effort in producing a detailed design that will
be used in developing an operational software product The Software Design Document is updated
with detailed design specifications. The additional detail is added to produce a detailed design
adequate for code production. The first draft of the Software User's Reference Guide should be
prepared. The Software Management Plan and Software Test and Acceptance Plan are updated as
necessary. The Project Management Plan and Benefit-Cost Analysis should be updated during this
task.
4.1.3.1 Activities
s_
The activities associated with Detailed Design include:
Update Software Design Document (EEI-8)
- Update/refine design information
- Decompose each Software Design Function
- Software Unit Formal Parameters
- Software Unit Inputs .
- Software Unit Local Data
- Software Unit Processing
- Software Unit Outputs
- Software Unit Limitations
Use of other software elements
4-9
-------
EPA System Design & Development
Guidance: Volume C
Data Base Physical Design
- File
- Record
- Field
- Item - \
Prepare initial draft of the Software User's Reference Guide (EEI-11) with at least
sections one through three completed and a detailed outline of the remainder of the
document
- Description of the system
- System access techniques
- User analysis/reporting options
- Data entry and update process
User support and training program/sources
- Security requirements
* Update the Preliminary Design and Options Analysis (EEI-2) with revised benefit-cost
analysis
Update Program Management Plan (EEI-3)
* Update Software Management Plan (EEI-6)
Update Software Test and Acceptance Plan (EEI-7).
4.1.3.2 Documentation
Documentation associated with the Detailed Design includes:
* Preliminary Design and Options
Analysis EEI-2 (Update)
* Project Management Plan EEI-3 (Update)
Software Management Plan EEI-6 (Update)
4-10
-------
EPA System Design & Development
Guidance: Volume C
Software Test and
Acceptance Plan
Software Design Document
Software User's
Reference Guide
EEI-7 (Final)
EEI-8 (Final)
EEM1 (Preliminary)
4.1.3.3
Critical Design Review
The Critical Design Review is conducted for each system element when the detailed design
is complete. The updated Software Design Document and the* updated Software Test and
Acceptance Plan are the primary subject of the review. The Software Management Plan and the
Software User's Reference Guide are also input to the review as necessary. The purpose is to
accomplish the following:
* Determine that the detailed design of the software system element under review satisfies
the performance requirements of the System Detailed Requirements Document
* Establish compatibility among system elements in the detailed design
* Assess the productivity and risk areas (on a technical, cost and schedule basis).
Review the preliminary product specifications.
A successful Critical Design Review establishes or updates the Design Baseline. The Design
Baseline is then used as the basis for the production and coding of the software system.
OIRM/SIRMO representatives should participate in the Critical Design Review.
4.1.3.4
Design Baseline
The Design Baseline is established after a successful Critical Design Review. It consists of
the final design specifications - including data base specifications and the test plans associated
with the software product The Detailed Design Baseline is made up of the Software Design
Document (EEI-8) and the final Software Test and Acceptance Plan (EEI-7). Once these
documents are baselined, any changes to the documents represent a change in the scope of the
project and must have management approval
4-11
-------
EPA System Design & Development
Guidance: Volume C
4.2 SYSTEM DEVELOPMENT STAGE
\
Associated tasks include System Production and Programming, and System Integration,
Test and Evaluation.
i
4.2.1 System Production and Programming
The specifications developed during the System Design stage are used to develop a system
that functions correctly in a controlled environment At the completion of the System Production
and Programming task, all programs, job streams, data bases, security controls, user procedures
and operations procedures will have been developed and thoroughly tested by the development
team.
4.2.1.1 Activities
The activities associated with System Production and Programming are:
Develop Software System
- Code software units
- Review software unit code
- Unit test software unit code '
- Produce unit test reports
Perform subsystem integration testing
- Prepare subsystem integration test reports
Prepare Software Maintenance Document (EEI-9)
Maintenance Procedures including:
- Source Code Standards <
- Documentation Update Procedures
- Coding and Review Process
- Change Control Process
Testing Standards and Procedures
Change Implementation Methods
4-11
-------
EPA System Design & Development
Guidance: Volume C
Maintenance Tools
- Technical tools
-. Management tools
Source code
.. Source listings or equivalent
Prepare Software Operations Document (EEI- 10)
System Initialization
System Restart by Functional Element
System Manager functions
- System Backup/Recovery Provisions and other Information Security Provisions
/
Update Software User's Reference Guide (EEM1).
4.2.1.2
Documentation
Documentation associated with the System Production and Programming task includes:
Software Maintenance Document
Software Operations Document
Software User's Reference
Guide
* Unit Tested Source Code
Unit Test Data.
1-9 (Preliminary)
MO (Preliminary)
I-11 (Update)
4-13
-------
EPA System Design & Development
Guidance: Volume C
4.2.1.3
Svstem Production and Programming Reviews
Preliminary Functional Configuration and Physical Configuration reviews are performed as
each piece of software is delivered for inclusion into the product baseline. They confirm that the
software product or component of the software product performs according to the requirements
and design specifications that have been prepared and baselined during System Design. The
results of the review are Input to the Development Test and Evaluation Review.
The Development Test and Evaluation Review ensures that the developmental testing of the
software is successful and that the system requirements are satisfied. The Software Maintenance
Document, the Software Operations Document, the updated User's Guide, the results of the
Functional Configuration Review and the results of the Physical Configuration Review are also
reviewed for completeness and accuracy. Upon completion of a successful review, these
documents are placed in the Product Baseline.
The Development Test and Evaluation Review is performed at the end of the System
Production and Programming task. A successful Development Test and Evaluation Review
establishes or updates the Product Baseline. OIRM/SIRMO representatives should participate in
the Development Test and Evaluation Review.
4.2.1.4
Product Baseline
The Product Baseline establishes a tested, operable version of the software system in its
operating environment. As each subsystem is successfully tested, the product baseline is updated.
The baseline of the completed and tested version of the software product ensures that any changes
or enhancements take place against a stable, controlled set of functional and technical components.
The Product Baseline will include the completed product specifications, the operation/maintenance
documents and the user's guide.
The Product Baseline is established/updated after a successful Development Test and
Evaluation Review at the end of the System'Production and Programming task.
4.2.2 Svstem Integration. Test and Evaluation *
The System Integration, Test and Evaluation task includes the testing of the fully integrated
software product in its operational environment This task is performed by a test team that does
4-14
-------
EPA System Design & Development
Guidance: Volume C
not include any of the software development team members. The purpose is -to provide a test and
evaluation environment that is independent of the development effort
The Software Maintenance Document, the Software Operations Document and the Software
User's Reference Guide are updated as necessary based on the testing process. The software
product and its related documents may have to be sent back to the development team if rework is
required based on the results of system integration testing.
t
4.2.2.1 Activities .
The activities associated with the System Integration, Test and Evaluation task are:
Install the working system using the installation procedures
* Execute the System Test portion of the Software Test and Acceptance Plan
* Document any discrepancies noted during testing for resolution with the development
team and user
Verify that discrepancies that require software modification have been modified
correctly .
Prepare System Integration Test Report (EEI-12)
Recommend disposition of the software and documentation
* Update Software Maintenance Document (EEI-9), Software Operations Document
(EEMO), and Software User's Reference Guide (EEI-11).
4.2.2.2 Documentation
Documentation associated with the System Integration, Test and Evaluation task includes:
Software Maintenance Document EEI-9 (Update)
Software Operations Document EEMO (Update)
4-15
-------
EPA System Design & Development
Guidance: Volume C
* Software User's Reference
Guide EEI-11 (Update)
System Integration Test Reports EEI-12 (Final)
System Integration Tested Software
* System Integration Test Data
4.2.2.3 System Integration. Test and Evaluation R$y|evyy
»
The final Functional Configuration and the Physical Configuration reviews are performed
when all the subsystems are delivered and integrated into the Product Baseline. They confirm that
the software product or component of the software product performs according to the requirements
and design specifications baselined in the Product Baseline. The results of the review are input to
the Operational Test and Evaluation Review.
The Operational Test and Evaluation Review ensures that the software system is viable in
_/
its intended environment. The Operational Test and Evaluation Review is performed at the end of
the System Integration, Test and Evaluation task.
The Software Maintenance Document, Software Operations Document and the User's
Guide are the major inputs to the review. The System Integration Test Reports drive the review in
that they contain the results of testing the software product All errors or incidents that were
encountered during formal testing are identified. The resolution of each incident is noted. Those
incidents that were determined to be errors are presented in two categories corrected and
unresolved. This information is used in determining if the software product is ready for formal
use. A successful Operational Test and Evaluation Review establishes or updates the Operational
Baseline. OIRM/SIRMO representatives should participate in the Operational Test and Evaluation
Review..
4.2.2.4 Operational Baseline.
i *
The Operational Baseline represents the completely implemented and tested software
system. It is the basis for future maintenance changes and enhancements. All documentation is
modified as required, validation and system testing is completed and the system is placed in
production and/or turned over to the user. The Operational Baseline is established and/or updated
t
after a successful Operational Test and Evaluation Review.
4-16
-------
EPA System Design & Development
Guidance: Volume C
4.3 SYSTEM IMPLEMENTATION STAGE
This stage comprises System Installation and System Operations and Maintenance.
4.3.1 System Installation
The System Installation task is primarily for formal user acceptance of the software
product. The software product is installed in a production environment, and the user exercises the
product to determine if it meets his/her needs and requirements.
4.3.1.1 Activities
The activities associated with System Installation are:
Install the software product in a production environment
Complete user acceptance of the software product in accordance with Software Test and
Acceptance Plan (EEI-7)
* Train users.
4.3.1.2 Documentation
The major milestones associated with System Installation are:
Operational software installed
Training completed
* User agreement to accept the software and documentation.
In addition, the final version of the following system documentation is delivered:
System Detailed Requirements EEI-5 (Final)
Document
Software Management Plan EEI-6 (Final)
Software Design Document EEI-8 (Final)
Software Maintenance Document EEI-9 (Final)
4.17
-------
EPA System Design .& Development
Guidance: Volume C
4.3.1.3
Software Operations Document
Software User's Reference Guide
System Integration Test Reports
System Implementation Review
I-10 (Final)
Ml (Final)
1-12 (Final)
The System Implementation Review ensures the new system has been accepted by its users
and is ready to begin full operation. During the implementation stage, problems, users likes and
dislikes, in addition to possible enhancements are identified. The procedures for addressing these
concerns are reviewed and software is enhanced following system operations and maintenance
procedures.
4.3.2 Systenfl Operations and Maintenance
Procedures for the operating and maintaining fully installed systems are important in
ensuring that the system continues to operate effectively throughout its life cycle and that
obsolescence is declared when the system no longer fulfills the requirement. Procedures for.
operating and maintaining an existing system are contained in OIRM's Operations and Maintenance
Manual. This manual has been created as the follow-on guidance for EPA's System Design and
Development Guidance. The manual will assist system managers in developing proper operating
procedures, defining staff responsibilities, documenting system requirements, designing follow-on
training programs and performing configuration management The Operations and Maintenance
Manual should be followed to ensure the resources dedicated to the system after implementation,
will be used in the most efficient and effective manner.
4-18
-------
EPA System Design & Development
Guidance: Volume C
Chapter Five
SUMMARY
5.1 SYSTEM DESIGN. DEVELOPMENT AND IMPLEMENTATION OUTPUTS,
The outputs, documents and results of the System Design, Development and
Implementation process are as follows:
*
EEI-4, System Implementation Plan*
EEI-5, System Detailed Requirements Document
EEI-6, Software Management Plan*
EEI-7. Software Test and Acceptance Plan*
EEI-8, Software Design Document*
EEI-9, Software Maintenance Document
* EEI-10, Software Operations Document
EEI-11. Software User's Reference Guide
* EEI-12, System Integration Test Reports*
;
* Working, tested and user accepted automated or partially automated solution to the
problem
\
Established Configuration Management or change control procedures
* Note: These EEI requirements are the basic requirements for User Owned Systems that DO NOT
involve OIRM.
5.2 NEXT STEPS
After the user has accepted the application system it begins the transition to the operation
and maintenance phase of the system life cycle. The application specific guidelines for conducting
this phase are outlined in the Software Maintenance Document (EEI-9), which is required for all
systems. Guidance concerning the maintenance and operation phase of the software life cycle is
contained in OIRM's Operations and Maintenance Manual
5-1
-------
-------
EPA System Design & Development
Guidance: Volume C
APPENDIX A
ESSENTIAL ELEMENTS OF INFORMATION
This appendix provides representative outlines of each of the system-level documents that
will be developed during the system design, development and implementation phase.
A.I INTRODUCTION
L
The documentation requirements contained in this appendix apply to all software
development projects, regardless of size, complexity or origin except as noted in subsection
1.6, "Determining Documentation Requirements" in Chapter 1 of this Volume. At a minimum,
these standards apply to all new software development projects. Maintenance and/or enhancements
to existing information systems must comply with the requirements set but in Chapter 1, section
1.5 of Volume C, System Design, Development and Implementation.
Compliance with the standards and conventions provided in this appendix will ensure thaj
adequate documentation is produced for all system development projects.
The documents defined in this appendix are:
EEI-4 System Implementation Plan
EEI-5 System Detailed Requirements Document
EEI-6 Software Management Plan
EEI-7 Software Test and Acceptance Plan
EEI-8 Software Design Document
EEI-9 Software Maintenance Document
EEI-10 Software Operations Document
EEI-11 Software User's Reference Guide
EEI-12 System Integration Test Reports
When an asterisk or alphanumeric appears within a section number in the outlines, it
represents a repetition of the element as many times as necessary to define multiple iterations of the
element
A.I
-------
EPA System Design & Develop meat
Guidance: Volume C
The following milestone chart illustrates the relative initiation and completion ot each
document with respect to the software development life cycle, its major phases, and the span and
scope of Volumes A, B, and C.
A-2
-------
EPA System Design & Development
Guidance: Volume C
DOCUMENTATION VERSUS LIFE CYCLE
u i
Ii
£.
Si
PI
t w C
OQ K
if!
73 B S
1
r
n
I-
3
2,
I-
c 5
o bJ
8
i
w«
S
,>.
E I*1??
!°
-
B3
P
tJUCd
bib)
bl
A-3
-------
EPA System Design & Development
Guidance: Volume. C
EH-4
SYSTEM IMPLEMENTATION PLAN
1. INTRODUCTION
1.1 Purpose
1.2 Background
1.3 Scope
1.4 System References
1.5 Tenns and Abbreviations
1.6 Organization of This Document '
2.1 Government Documents
2.2 Non-government Documents
3. IMPLEMENTATION PLAN
3.1 Plan Management
3.1.1 Policy Events and Actions
3.1.2 Program Management
3.1.3 Strategy for Acquiring Information/Data
3.1.3.1 Information Collection
3.1.3.2 Forms
3.1.3.3 Clearance
3.1.4 Strategy for Integrating with other EPA Information
Envii
italData
3.1.4.1
3.1.4.2 Administrative Data
3.1.5 Access Policy and Standards
3.1.6 Assessment of Existing Hardware/Software Alternatives
3.1.6.1 EPA
3.1.6.2 Other Government Agencies
3.1.6.3 Commercial Vendors
3.1.7 , Information Systems
3.1.7.1
3.1.7.2
Automated
Manual
3.2
3.1.8 Process and Procedure
Work Plans and Schedules
A-4
-------
EPA System Design & Development
Guidance: Volume C
SYSTEM IMPLEMENTATION PLAN
(Continued)
4.
5.
6.
3.3 Resource Requirements
3.3.1 Contractor
3.3.2 Personnel
3.3.3 Facilities -
3.3.4 Government Furnished Property
3.4 Integrated Project Plan
NOTES
APPENDICES
GLOSSARY
A-5
-------
EPA System Design & Development
Guidance: Volume C
1-5
SYSTEM DETAILED REQUIREMENTS DOCUMENT
INTRODUCTION
1.1 Purpose
1.2 Background
1.3 Scope
1.4 System References
1.5 Tenns and Abbreviations
1.6 Organization of This Document
REFERENCED DOCUMENTS
2.1 Government Documents
2.2 Non-government Documents
DETAILED CHARACTERISTICS AND REQUIREMENTS
3.1 System Definition Requirements
3.
3.
.1.1
.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.2
System Purpose
Concept of Operation
System Sizing and Timing Requirements
Design Standards
Design Constraints
Data Requirements
Subsystem Definition Requirements
3.2.1 Subsystem #1
3.2.1.1
3.2.1.2
Subsystem #1 Purpose/Definition
Subsystem #1 Interface Definition
3.2.1.2.1
3.2.1.2.2
3.2.1.2.3
3.2.1.2.4
Network
Software Systems
DataBase
Entity Relationships
3.2.1.3
3.2.1.4
Assumptions and Constraints
Subsystem #1 Level II Requirement 1
3.2.1.4.1 Level n Requirement 1 Description
3.2.1.4.1.1 Level m Detailed Functional
Requirement
A-6
-------
EPA System Design & Development
Guidance: Volume C
EH-5
SYSTEM DETAILED REQUIREMENTS DOCUMENT
(Continued)
3.2,1.4.1.1.1 Titleand
Description Of
Level m
Function 1
3.2.1.4.1.1.* Titleand
Description Of
Level m
Function *
3.2.1.4.1.* Level in Requirement *
Description
3.2.1.4.* Level n Requirement * Description
3.2.* Subsystem*
3.3 System Physical Requirements
3.3.1 HVAC and Electrical Requirements
3.3.2 Facilities Management .
3.3.3 Computer Hardware Requirements
3.3.4 Computer Operating System Requirements
3.3.5 Software Utilities and Tools
3.4 System Security Requirements
3.4.1 System Backup Procedures
3.4.2 Review/Activity Log Files
3.4.3 Disaster Recovery Procedures
3.5 Quality Requirements
3.5.1 Reliability
3.5.2 Maintainability
3.5.3 Flexibility and Expansion
3.5.4 Transportability
3.6 Life Cycle Requirements
3.6.1 Software Maintenance Personnel
3.6.2 User Support and Training
3.6.3 Hardware and Supplies
A-7
-------
EPA System Design & Development
Guidance: Volume C
1-5
SYSTEM DETAILED REQUIREMENTS DOCUMENT
(Continued)
4 . Testing and Verification Requirements
4. 1 Testing Requirements
4.1.1 Method
4.1.2 Responsibility
5 . Project Schedules and Work Plans
5.1 Schedules
5.2 Work Plan
5.2.1 Personnel
5.2.2 Milestones
5.2.3 Budget
6. NOTES
7. APPENDICES
>
8. GLOSSARY
-------
EPA System Design & Development
Guidance: Volume C
2.
SOFTWARE MANAGEMENT PLAN
1. INTRODUCTION
1.1 Purpose.
1.2 Background
1.3 Scope
1.4 System References
1.5 Terms and Abbreviations
1.6 Organization of This Document
2.1 Government Documents
2.2 Non-government Documents
3. PLANNING
3.1 Project Resources
3.1.1 Contractor Facilities
3.1.2 Government Furnished Equipment, Software and Services
3.1.3 Personnel
3.1.4 Organizations Responsible for Design, Implementation, Configuration
Management, Reliability and Quality Assurance
3.2 Review Responsibilities
3.3 Software Development
3.3.1 Organization Structure
3.3.2 Personnel
3.3.3 Resources
3.3.4 Software Development Tools, Techniques, Methodologies and Standards
3.3.5 Manual Procedures/Forms
4. MANAGEMENT CONTROLS
4.1 Project Schedule, Reviews and Report Controls
4.1.1 WorkPlan
4.1.2 Activity Network and Dependencies
4-t.3 Risk Areas
4.2 Risk Management
4.1.1 New Technologies '
4.1.2 Backup - Recovery
4.1.3 Manual Procedures/Forms
A-9
-------
EPA System Design & Development
Guidance: Volume C
SOFTWARE MANAGEMENT PLAN
(Continued)
5 SOFTWARE PRODUCT ASSURANCE
5.1 Software Configuration Management
5.2 Software Independent Verification and Validation
5.3 Software Security
5.4 Software Reliability and Quality Control
5.5 Software Interface Definition
5.6 Software Waivers to Policy and Procedures
5.6.1 Permanent Waivers
5.6.2 Temporary Waivers
5.6.3 Tools and Standards Waivers
5.7 Data Administration
5.8 Quality Assurance
5.8.1 Program Monitoring
5.8.2 Quality Reviews
5.8.3 Reporting and Control
5.8.4 Reviews
5.8.4.1 System Requirements Reviews
5.8.4.2 Preliminary Design Review
5.8.4.3 Critical Design Review
5.8.4.4 Code Reviews
5.8.4.5 Development Test and Evaluation Review
5.8.4.6 Operational Test and Evaluation Review
5.9 Testing
5.9.1 Software Test Plan
5.9.2 Software Test Description
5.9.3 Software Test Procedures
5.9.4 Conducting the Software Test
5.9.5 Software Test Reports
6. SOFTWARE DEVELOPMENT PROCEDURES
6.1 Software Standards and Procedures
6.1.1 Software Tools
6.1.2 Commercial and Reusable
6.1.2. i 5at^ Righc and Documentation
s.i.2.2
Certification
A-10
-------
EPA System Design & Development
Guidance: Volume C
SOFTWARE MANAGEMENT PLAN
(Continued)
6.1.3 Software Test Tools
6.1.4 Software Design
6.1 4.1
6.1.4.2
6.1.4.2
6.1.4.4
Software Desij
piN
MM
^ VJU CUAUA^UlK ' rftfUJ
Interface Methodo
fcthodology
juage
ogy
Network Methodology
6.1.5 Software Design and Coding Standards
6.1.6 Firmware
6.2 Software Configuration Management
6.2.1 Configuration Identification
6.2.1.1 Documentation Baselines
6.2.1.2 Methods and Approach to Standards Implementation
6.2.2 Configuration Control
6.2.2.1 Configuration Control Flow Diagram
6.2.2.2 Forms
6.2.2.3 Storage and Release of Master Copies
6.2.3 Configuration Reviews
7. NOTES
8. APPENDICES
9. GLOSSARY
A-ll
-------
EPA System Design & Development
Guidance: Volume C
1-7
SOFTWARE TEST AND ACCEPTANCE PLAN
INTRODUCTION
1.1 Purpose
1.2 Background
1.3 Scope
1.4 System References
l.S Terms and Abbreviations
1.6 Organization of This Document
2.1 Government Documents
2.2 Non-government Documents
UMTTATIONS/TRACEABILrrY
3.1
3.2
Limitations
Traceability
TEST PLANS
4.1 Software Unit Testing (includes Manual Procedures)
4.2
4.1.1
4.1.2
Test Requirements
Test Management
4.1.3
4.1.4
4.1.2.1
4.1.2.2
4.1.2.3
4.1.2.4
4.1.2.5
4.1.2.6
4.1.2.7
4.1.2.8
4.1.2.9
Test Schedule
Test Results
Integration Test Team
Responsibilities of Other
Product Control
Test Control
Evaluation and Retest Criteria
Test Reporting
Test Review
Test Identification
TestData Environment
ization and Responsibility
luxations
Integration Testing of Software Units, Modules and Software Functions/Risk
Management
4.2.1 Integration Test Requirements
4.2.2 Integration Test Management
4.2.3 Integration Test Categories
4.2.4 Integration Test Methods
4.2.5 Integration Test Schedules
4.2.6 Integration Test Results
A-12
-------
EPA System Design & Development
Guidance: Volume C
SOFTWARE TEST AND ACCEPTANCE PLAN
(Continued)
4.2.6.* (Insert Name) Integration Test
4.3 Required Resources
4.3.1 Facilities
4.3.2 Hardware
4.3.3 Interface/Support Software '
4.3.4 Personnel
4.4 System Test .
4.4.1 System Test Requirements
4.4.2 System Test Management
4.4.3 System Test Categories
4.4.4 System Test Methods
4.4.5 System Test Schedules
4.4.6 System Test Results
5. USER ACCEPTANCE
5.1 Test Team
5.2 Pretest Preparations
5.2.1 Development of Test Scenarios and Test Data
5.2.2 Development of Predicted Results
5.2.3 Development of Acceptance Procedures
5.3 Test Execution
5.3.1 Data Analysis
5.3.2 Test Evaluation
5.3.3 Problem Report and Problem Resolution Process
5.4 Formal Acceptance
5.4.1 Test Report
5.4.1.1 Detailed Test History
5.4.1.2 Detailed Test Results
5.4.1.2.* (Insert Test Name) Test Results
6. NOTES
7. APPENDICES
8. GLOSSARY
A-13
-------
EPA System Design & Development
Guidance: Volume C
1-8
SOFTWARE DESIGN DOCUMENT
4.
INTRODUCTION
1.1 Purpose
1.2 Background
1.3 Scope
1.4 System References
1.5 Terms and Abbreviations
1.6 Organization of This Document
2.1
2.2
Government Documents
Non-government Documents
SOFTWARE DESIGN REQUIREMENTS (SDR)
\
3.1 Concepts
3.2 Functional Flow
3.n (Insert Name) Requirement
3.*.1 Description of Requirements and Associated Software Design Functions
(SDFs), including Manual Procedures
SOFTWARE DESIGN FUNCTION (SDF)
4.* (Insert Name) Function
4.*.1 Inputs
4.*.2 Local Data
4. *.3 Initiation, Timing and Sequencing
4.*.4 Interrupts
4.*.5 Processing
4.*.5.1
4.*.5.2
4,*.5.3
4.*.6 Outputs
4.*.7 Adaption
Algorithms
Error Handling
Test Structures
Software Function Requirements (SFR)
5.1 SFR External Interfaces (including Manual Procedures)
5.1.* (Insert Name) Interfacer
5.1.*.* (Insert Name) Software Unit (SU)
A.14
-------
EPA System Design & Development
Guidance: Volume C
EEI-8
SOFTWARE DESIGN DOCUMENT
(Continued)
Detail Design
6.* (Insert Name) SFR
6.*.1 SFR Inputs
6.*.2 SFR Local Data
6.*.3 SFR Processing
6.*.3.1
6.*.3.2
6.*.3.3
6.*.3.4
6.*.3.5
6.*.3.6
Control
Algorithms
Error Handling
Data Conversion
Test Structure
Manual Procedures
6.*.4
6.*.5
SFR Outputs
SFR Decomposition
6A5.1
(Insert Name) Software Unit (SU)
6.*.5.*.1
6.*.5.*.2
6.*.5.*.3
6.*.5.*.4
6.*.5.*.5
6.*.5.*.6
6.*.5.*.7
6.*.5.*.8
SU Formal Parameters
SU Inputs
SU Local Data
SU Processing
SU Outputs
SU Limitations ,
Use of Other Elements
Manual Procedures
7. Data Base Design (If Applicable)
7.1
7.2
7.3
7.4
7.5
Data Base Management System
Data Structure (Logical Design)1
Interrelationships
Design Characteristic/Requirements Traceability
Physical Design2
7.5.* File (Insert Name)
7.5.*.* Record (Insert Name)
1 For ADAS AS refer to EPA/NCC ADAS AS Application Development Procedures Manual for CDBA
requirements
2 For ADABAS refer to EPA/NCC ADAB AS Application Development Procedures Manual for CDBA
requirements
A-15
-------
EPA System Design & Development
Guidance: Volume C
1-8
SOFTWARE DESIGN DOCUMENT
(Continued)
7.5.*.*.* Field (Insert Name)
7.5.*.*.*.* Item (Insert Name)
8. NOTES
9. APPENDICES
10. GLOSSARY
A-U
-------
EPA System Design St Development
Guidance: Volume C
SOFTWARE MAINTENANCE DOCUMENT
INTRODUCTION
i
1.1 Purpose
1.2 Background
1.3 Scope
1.4 System References .
1.5 Terms and Abbreviations
1.6 Organization of This Document
2.1 Government Documents
2.2 Non-government Documents
MAINTENANCE PROCEDURES
3.1 Source Code Standards
3.2 Documentation Update (including non-software elements)
3.3 Coding and Review Process
3.3.1 Top Down Approach
3.3.2 Peer Review
3.3.3 Walkthrough
3.3.4 Team Leader Review
3.4 Change Control Process
3.4.1 Change Request
3.4.2 Code Review
3.4.3 Review and Approval
3.4.3.1
3.4.3.2
Maintai
User
3.5 Testing Standards and Procedures
3.5.1 Test Plans
3.5.2 Test Data
3.5.3 Test Scenarios
3.5.4 Test Results
3.6 Change Implementation Methods
3.6.1 Test to Production Method
A-17
-------
\
EPA System Dcsigi & Development
Guidance: Volume C
SOFTWARE MAINTENANCE DOCUMENT
(Continued)
MAINTENANCE TOOLS
4.1 Technical Tools
4.1.1 Processing Tools
Compilers
Cross Reference
Hie Comparator
Traces/Dumps
Test Data Generator
Test Coverage Analyzer
Preprocessor
Verification/Validation
4.
4.
4.
4.
4.
4.
4.1
4.1
.1.1
.1.2
.1.3
.1.4
.1.5
.1.6
1.1.7
1.1.8
4.1.2 Clerical Tools
4.1.2.1
4.1.2.2
4.1.2.3
4.1.2.4
4,1.2.5
4.2 Management Tools
On-line Editor
Dccumentation Library
Archival Processor
Source Code Reformatter
Data Dictionary
4.2.1 Problem Reporting
4.2.2 Status Reporting
4.2.3 Scheduling
4.2.4 Configuration Management
5. SOURCE CODE
5. * (Insert Software Unit Name) Source Listing
6. NOTES
7. APPENDICES
8. GLOSSARY
A-IS
-------
EPA System Design & Development
Guidance: Volume C
SOFTWARE OPERATIONS DOCUMENT
1. INTRODUCTION
1.1 Purpose
1.2 Background
1.3 Scope
1.4 System References
1.5 Terms and Abbreviations
1.6 Organization of This Document
2. REFERENCED DOCUMENTS
2.1 Government Documents
2.2 Non-government Documents
3. OPERATIONS
3.1 System Initialization
3.2 System Restart
3.2.* (Insert Name) Function
3.2.*. 1
3.2.*.2
3.2.*.3 .
3.2.*.4
3.2.*.5
Execution
Inputs
3.2.*.2.1
3.2.*.2.2
User Inputs
System Inputs
Outputs
Termination
Error Messages
3.3 System Manager
3.3.1 Manager's Functions/Menu
3.3.1.* (Insert Name ) Function
3.4 System Backup/Recovery Provisions
3.5 System Security
4. NOTES
5. APPENDICES
6. GLOSSARY
A-19
-------
EPA System Design & Development
Guidance: Volume C
Ml
SOFTWARE USER'S REFERENCE GUIDE
INTRODUCTION
1 X
1.2
1.3
1.4
1 .5
1.6
Background
Scope
System References
Terms and Abbreviations
Organization of This Document
5.
2.1 Government Documents
2.2 Non-government Documents
DESCRIPTION OF THE SYSTEM
3.1 System Overview and Mission Based Activities
3.2 System Flow and Data Descriptions
3.3 System and Program Manager
3.4 Data Dictionary
SYSTEM ACCESS TECHNIQUE(S)
4.1 Hardware/Software Interface(s)
4.2 Menus and Other Methods of Access
4.3 Manual Procedures
USER ANALYSIS / REPORTING OPTIONS
5.1 Standard Reports
5.2 Ad-hoc Capabilities
5.3 Specialized Capabilities
5.3.1 Models, Algorithms, Etc.
5.3.2 Graphics
5.3.3 Expert Systems
5.3.4 Laser and Other Output Media
6. DATA ENTRY AND UPDATE PROCESSES
6.1 Methods and Descriptions of Processes
6.2 Data Responsibilities
7, USER SUPPORT AND TRAINING PROGRAM/SOURCES
7.1 User Support
7.2 , Training Sources/Schedules
A-20
-------
EPA System Design & Development
Guidance: Volume C
EEI-11
SOFTWARE USER-S REFERENCE GUIDE
(Continued)
8. NOTES
9. APPENDICES
10. GLOSSARY
A-21
-------
EPA System Design & Development
Guidance: Volume C
EEI-12
SYSTEM INTEGRATION TEST REPORT
1. INTRODUCTION
1.1 Purpose
1.2 Background
1.3 Scope
1.4 System References
1.5 Terms and Abbreviations
1.6 Assumptions and Constraints,
1.7 Organization of This Document
2. REFERENCED DOCUMENTS
2.1 Government Documents
2.2 Non-government Documents
3. SUMMARY OF TESTING
3.1 Test Environment
3.2 Chronology of the Testing
4. TEST RESULTS
4.1 Resolved Incidents
4.2 Outstanding Incidents
4.3 Evaluation and Recommended Disposition
5. NOTES
6. APPENDICES
7. GLOSSARY
A-22
------- |