-------
EPA System Design and Development
Guidance: Volume C
TABLE OF CONTENTS
Tide Page
1. INTRODUCTION 1-1
1.1 Background 1-1
1.2 Objectives of the System Design and Development
Guidance 1-3
1.3 Authority 1-4
1.4 Applicability of the Guidance 1-4
1.5 Documentation Requirements 1-6
1.6 Assistance and Support Available 1-8
2. SOFTWARE MANAGEMENT AND ENGINEERING
COMPONENTS PROGRAM 2-1
2.1 Applicability to Small and Large Projects 2-1
2.2 Quality Software 2-2
2.3 Software Management Program Overview 2-3
2.4 Software Engineering Components 2-4
2.4.1 Standards 2-4
2.4.2 Procedures/Methodologies 2-5
2.4.3 Computer-Aided Software Engineering Tools 2-5
2.4.4 Quality Assurance 2-5
2.5 Software Engineering Principles 2-5
2.5.1 Determining Documentation Requirements 2-7
2.5.2 Software Life Cycle Reviews 2-8
iii
-------
EPA System Design antf Development
Guidance: Volume C
3. SOFTWARE DEVELOPMENT STANDARDS 3-1
3.1 Standard Programming Languages 3-1
3.1.1 Programming Language Selection Guidelines 3-1
3.1.2 Source Program Design and Coding Conventions 3-8
3.2 EPA Standard Specialized Software Tools 3-8
3.3 Hardware/Software Environments 3-9
4. SYSTEM DESIGN, DEVELOPMENT AND
IMPLEMENTATION OVERVIEW 4 -1
4.1 System Design Stage .....4-1
4.1.1 System Detailed Requirements Analysis ...4-3
4.1.1.1 Activities 4-3
4.1.1.2 Documentation 4-4
4.1.1.3 System Requirements Review 4-5
4.1.1.4 Functional Baseline v 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.y Detailed Design 4-9
4.1.3.1 Activities , 4-9
4.1.3.2 Docuxrentation 4-10
4.1.3.3 Critical Design Review 4-11
4.1.3.4 Design Baseline
* 11
X
-------
EPA System Design and Development
Guidance: Volume C
4.2 System Development Stage 4-12
4.2.1 System Production and Programming 4-12
4.2.1.1 Activities 4-12
4.2.1.2 Documentation 4-13
4.2.1.3 System Production and Programming
Reviews 4-14
4.2.1.4 Product Baseline 4-14
4.2.2 System Integration, Test and Evaluation 4-14
4.2.2.1 Activities 4-15
4.2.2.2 Documentation 4-15
4.2.2.3 System Integration, Test and
Evaluation Reviews 4-16
4.2.2.4 Operational Baseline 4-16
4.3 System Implementation Stage 4-17
•4.3.1 System Installation 4-17
4.3.1.1 Activities 4-17
4.3.1.2 Documentation 4-17
4.3.1.3 System Implementation Review 4-18
4.3.2 System Operations and Maintenance 4-18
5. SUMMARY 5-1
5.1 System Design, Development and Implementation Outputs 5-1
5.2 Next Steps 5-1
Appendix A
Essential Elements of Information A-1
-------
EPA System Design and Development
Guidance: Volume C
LIST OF EXHIBITS
1-1 Guidance Audience 1-2
1 -2 EPA System Development Life Cycle and Decision Process 1-5
1-3 System Category/EEI Matrix 1-9
2-1 EEI Requirements for Type I Systems 2-9
2-2 EEI Requirements for Type n Systems 2-10
2-3 EEI Requirements for Type? HI Systems 2-11
3-1 EPA Standard Application Programming Languages 3-2
3-2 Software Support Tool Selection Matrix: Small Systems 3-5
3-3 Software Support Tool Selection Matrix: Medium Systems 3-6
3-4 Software Support Tool Selection Matrix: Large Systems 3-7
3-5 EPA Standard Specialized Software Tools 3-10
3-6 Agency-Supported Hardware and Software 3-11
4-1 EEI Documentation 4-2
vi
-------
Chapter One
INTRODUCTION
Pursuant to the Environmental Protection Agency's IRM Policy Manual, this-volume is the
last of three volumes which provide guidance for Agency system design and development efforts.
This volume provides guidance for the last phase of the EPA system development process — The
System Design, Development and Implementation.
Volume C is intended for use by system developers, including Agency staff and
contractors, who are actually responsible for system development It therefore provides detailed
guidance for conducting automated system development activities to help insure compatibility and
uniformity EPA-wide. Exhibit 1-1 on the next page identifies the intended audience of this
volume.
1.1 BACKGROUND
The Environmental Protection Agency expends millions of dollars each year on the design,
development, implementation and maintenance of major environmental and administrative systems
vital to EPA's programs and administrative functioning. Management of these resources is
becoming increasingly complex, since the rapid development of information technology in recent
years has dramatically increased computer capacity and user accessibility. The result has been two-
fold:
• An increasing number of system development efforts by managers and staff at all
organizational levels who, because of access to their own equipment, develop their own
systems independently of Agency system's staff
• A wide range of hardware/software options for implementation of any specific system
concept or design.
Therefore, there has been a proliferation of system development efforts by a broad range of users
with varying levels of sophistication in making development decisions and conducting
development efforts.
1-1
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 1-1
GUIDANCE AUDIENCE
PROJECT
DIRECTOR
PROJECT
MANAGER
CONTRACTOR
SYSTEM
MANAGER
SENIOR
ANALYST
MfD-LEVEL
ANALYST
JUNIOR
ANALYST
1-2
-------
EPA System Design & Development
Guidance: Volume C
1.2 OBJECTIVES OF THE SYSTEM DESIGN AND DEVELOPMENT CT TTDANCE
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. Pevelocment and Implementation is intended for use
primarily by system developers and provides specific guidance and standards which must
be adhered to when undertaking automated system design and development efforts.
Together these three volumes provide comprehensive guidance and standards for the orderly and
cost-effective development of automated systems. Exhibit 1-2 depicts the flow of the development
life cycle and decision process for the three volumes.
1-3
-------
EPA System Design & Development
Guidance: Volume C
In addition to the System Design and Development Guidance, OIRM is currently drafting
the EPA Information Security Manual. As security issues are raised and addressed throughout the
system development life cycle, the security manual should be consulted for proper Agency policy
and guidance.
1.3 AUTHORITY
The EPA System Design and Development Guidance derives its authority from Chapter 4
of the IRM Policy Manual, entitled "Software Management," which establishes the Agency
Software Management Program. The guidance serves as the primary guidance for Agency system
design and development efforts.
1.4 APPLICABILITY OF THE GUIDANCE
Senior Agency managers and responsible staff should read the guidance and become
familiar with the decision-making process involved with system design and development efforts.
They are responsible for ensuring adequate analysis and documentation to support all critical
decision points. The full documentation requirements for automated system development efforts,
which must be followed to conform to OARM policy, are fully discussed in Volume C
In general. Volumes A and B are intended to assist program offices and/or users in
conducting their own initial studies of system requirements, needs, option feasibility and cost-
effectiveness. In this context, the term "system" in Volumes A and B refers to a systematic set of
processes and/or procedures which can be used to meet the information needs of a user. It does
not imply that the "system" will be an automated system.
Volume C, however, presumes that an automated or partially automated solution has been
selected as a result of the Volume B options analysis. Volume C provides guidance and standards
for automated system development efforts. If the automated system is a relatively small application
on a microcomputer targeted for use within a single office (a "user owned information system"),
Volume C provides simplified requirements for system design, development and implementation.
If the proposed system is a larger application (mainframe or minicomputer), which is mission
critical or involves multiple offices and organizations, Volume C provides the full set of guidance
and standards which rn,us{ be followed by system developers. This will assure uniform, cost
effective system development in accordance with EPA policies, guidelines and standards.
1-4
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 1-2
EPA SYSTEM DEVELOPMENT LIFE CYCLE
AND DECISION PROCESS
DEVELOPMENT STAGE
DECISION /RESULT
C
Real World
Mission Need
J
. Volume A
REQUIREMENT AND
OPERATIONAL CONCEPT
DEFINITION
. Volume B.
Preliminary Design 6L
Options Analysis
OPTION DESIGN, BENEFIT/
COST ANALYSIS. AND
OPTION SELECTION
System Design,
Development &,
Implementation
FULLY IMPLEMENTED
SYSTEM
1-5
-------
EPA System Design & Development
Guidance: Volume C
1.5 DOCUMENTATION Iffiffl fTREMENTS
In general, the intent of the three volume System Design and Development Guidance is to
provide a consistent'focus for system development efforts which will allow both EPA program
managers and OARM managers to cost-effectively develop and maintain the Agency's systems.
To achieve this goal, certain documentation requirements termed "Essential Elements of
Information" (EEI) documents, must be met Observance of this guidance in preparing EEFs
should 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 EFJ documentation.
For certain system development efforts OERM 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 OERM/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 — —- tc protect ihc ccnf*u£imaiiiy, iiiicgiiiy 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 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. The review cycle
could include several stages, such as a series of status briefings for management, focus groups,
and/or distribution of the EEI in draft form. Throughout the review cycle, the managers and users
involved should be informed of the process and content of the EEI. When the final document is
completed, a consensus among management should be reached before developing the next EEL
It is not OERM'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 the EEIs to meet the unique requirements of their project.
Criteria for determining the minimum EEI documentation for a specific process during the
design, development and implementation phase is based on the nature and scope of the information
process and its importance to EPA's mission. Three types of categories describing various
systems with differing levels of EEI documentation requirements are identified as follows:
• TYPE I: Major Agency /Widely Accessed Information System: An information process
that requires special attention because of its importance to an Agency mission; its high
development, operating, or maintenance costs or its significant impact on administration
of Agency programs or, is widely accessed by a combination of EPA Headquarters,
Regional Offices, state and local users and/or Federal agencies.
• TYPE II: Localized Information System: An information process that is not a Major
Agency Information System but significantly supports accepted program goals and
missions and is accessed primarily by users in one major area, e.g., EPA
Headquarters, a single Agency program, or a Region.
• TYPE HI: User Owned Information System: Unique, stand-alone process developed to
improve the efficiency or effectiveness of operations for a single user or a small group
of users.
1-7
-------
EPA System Design & Development
Guidance: Volume 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). The form, which is under development and will be issued as pan of the forthcoming
EPA Information Security Manual, will capture basic information on system sensitivity, security
requirements, security design, reviews, test scenarios, results and safeguards.
1.6 ASSISTANCE AND SUPPORT AVAILABLE
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 C
EXHIBIT 1-3
SYSTEM CATEGORY
EEI MATRIX
"^v^ System
^x.^ Category
EEI ^"X^
Requirements ^^^
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 Malnt
Document
EEI-10
Software Operations
Document
EEI- 11
Software User's
Reference Guide
EEI- 12
System Integration
Test Report
Type
•
•
•
•
•
•
•
•
•
•
•
•
Type
II
•
•
•
•
•
•
•
•
•
•
Type
III
•
•
•
•
•
•
1-9
-------
EPA System Design & Development
Guidance: Volume 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 APPLICARTMTY 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 piogiammer productivity
Fewer problems (errors) with delivered product
- 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 and techniques for the
software development life cycle.
2.3 SOFTWARE MANAGEMENT PROGRAM OVERVTEW
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:
• Phase 3 - System Design, Development and Implementation
• Phase 4 - Operations and Maintenance.
2-3
-------
EPA System Design & Development
Guidance: Volume C
Detailed discussions of the System Design, Development and Implementation phase are contained
in Chapter 4 of this document The Operations and Maintenance phase of the system life cycle is
discussed in OERM's Operations and Maintenance Manual.
2.4 SOFTWARE ENGINFFRTNn 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.4.1 Stqpdarfls,
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
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 the conflicts that arise between the:
• Cost of documentation
• Classical life cycle for system development
• Changes in computing capabilities and system development techniques.
The use of the EEIs defined in this volume represent a flexible approach to system
documentation. All systems require some form of documentation. However, the degree of
documentation needed is dependent on the nature of the system, constituency (who will use it), and
life cycle costs. Software systems that are used nationwide, Agency wide and support major
program initiatives require complete documentation and thoughtful consideration of options, life
cycle costs and mission needs.
-------
EPA System Design & Development
Guidance: Volume C
Key points to consider are:
• A mission needs analysis and a requirements analysis which includes feasibility and
benefit-cost analyses must be conducted prior to embarking on a major agency
information system development effort
• 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 EEIs 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
Major Agency Information System! An information system that requires special
continuing management attention because of its importance to an agency mission, its
high development, operating, or maintenance costs or its significant impact on
administration of agency programs.
In this context, a system which requires obligations of more than $500,000 per year
to maintain or whose software component contains more than 500,000 lines of 3GL
source code or 100,000 lines of 4GL source code is considered a Major Agency
Information System.
2-7
-------
EPA System Design & Development
Guidance: Volume C
Widely Accessed Information System: An information system that is not a Major
Agency Information System, (but significantly supports accepted program goals and
missions). It is widely accessed by a combination of EPA Headquarters, Regional
Offices and/or State and local users and other Federal agencies.
Exhibit 2-1 presents the EEIs required for Type I Information systems which include
both Major Agency Information Systems and Widely Accessed Information Systems.
b. TvpeEI
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 Information System: Unique, stand-alone system developed to improve
the efficiency or effectiveness of operations for a single user or a small group of
users.
Exhibit 2-3 presents the EEIs required for Type in, User Owned Information
Systems.
2.5.2 Software Life Cvcle Reviews
Formal reviews are carried out at key points in the life cycle to ensure that the software
development activities are progressing consistent wirh user requirements sni UFA aianuarus. Tne
reviews used in the EPA System Development life cycle are described in detail in Chapter 4.
2-8
-------
Ctn
B IS
UfsCycb
Phase
Stafes
Ta*k*a*4
ActivitiM
DOCUMENTATION
REQUIREMENTS (EEIs)
SYSTEM DESIGN. DEVELOPMENT AND IMPLEMENTATION
System Design
System
Detailed
Requirements
Analysis
EH -4:
System
liiiuli i|M|i>»tttfM*
PUn
EH 5:
System Detailed
Requirement*
Document
EEI-&
Software
Preliminary
Design
EEt-7:
Software Teat
and Aonrntam ,t
PUn
Detailed
Design
EH -ft
Software Design
Document
System Development
System
Production
And
Programming
EH 9:
Softwuc
Matnlenutoe
Document
EEl-lft
Softwuc Operation*
Document
EEI II:
Software Uta't
System
Integration.
Test And
Evaluation
EH- 12:
System
InbgraUon Teat
Report
System Implementation
System
Installation
System
Operations
and
Maintenance
EEI- 7:
Software Test
•nd Acceptance
Plan
EH-fe
Softmwe
Maintenance
Oocuawnt
EEI 10:
Software Opendons
Document
EEI II:
•Software {ten's
Mtference Guide
w
w
w
o
w
2
w
2:
OKJ
» ~
w
CO
H
W
a c/i
rt v<
«• ui
Is
B 2.
(• M
0°
O
A
<
a
5"
•o
9
i»
B
-------
om
C T3
u
a
Life Cycle
Phase
Stages
Task* and
Ardvitle*
gl
J
1
11 8
a. t ^ ^
fciq
Rig
B'W
ft 2
yj 3
™5 ^*1
ri^
C0 *"J
I-H
«— » O
W 2
w
^H
jj^
SYSTEM DESIGN. DEVELOPMENT AND IMPLEMENTATION
System Design
System
Detail.*!
Requirements
Analysis
EEl-4:
System
Plan
EEI-S:
System Detailed
Btftfll 1 1 MVIUtffk 1 A
Document
Preliminary
Design
Detailed
Design
EH-&
Software Design
Document
System Development
System
Production
And
Programming
EEI-9:
Software
Maintenance
Document
EEl-lft
Software Operations
Document
EEI-II:
Software User's
Reference Guide
System
Integration.
Test And
Evaluation
EEI-12:
Syatem
Integration Test
Report
System Implementation
System
Installation
System
Operations
and
Maintenance
EEI-9:
Software
Maintenance
Document
EEI Ifc
Software Operations
uocuaMm
EEI-II:
Software User's
Reference Guide
Kl
H
W
B 2.
•3
n
O
B
<*
D
-------
19
a c/i
^
Uf • Cydtt
PitAA£
Btaje*
Taakcaad
(OO
1
CDH
S
SYSTEM DESIGN. DEVELOPMENT AND IMPLEMENTATION
System Design
System
Detailed
Requirements
Analysis
EEI-5:
System Detailed
Requirement*
Document
Preliminary
Design
Detailed
Design
EEI-&
Software Design
Document
System Development
System
Production
And
Programming
EEI-9:
Software
Maintenance
Document
EEI-IO:
Software Operation*
Document
EEI-II:
Software User1*
Reference Guide
System
Integration.
Test And
Evaluation
N/A
System Implementation
System
Installation
System
Operations
and
Maintenance
EH 8:
Software
Maintenance
Document
EEI-IO:
Software Operation*
Document
EEI-II:
Software User1*
Reference Guide
I?
SI-
a
n
o
a
o
•o
B
Cfl
-------
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 Selection Guidelines
A number of factors go into deciding in which computer environment an application will
operate. After the computer hardware configuration has been identified, the application
programming language and associated support software tools must be selected. While there is no
"right" answer for each information system being developed, the use of common sense and the
guidelines presented in this volume can lead to a reasonable solution.
Software developers should consider the following questions:
• Is an off-the-shelf solution available?
3-1
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 3-1
EPA STANDARD APPLICATION
PROGRAMMING LANGUAGES
APPLICATION SOFTWARE
PROGRAMMING LANGUAGE
3GL
4GL
COBOL
FORTRAN
PL/I
PASCAL
INFO
NATURAL
FOCUS
dBASE III
SAS
STANDARD
EPA
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
FIPS
Yes
Yes
Yes
Yes
3-2
-------
EPA System Design & Development
Guidance: Volume C
• Has OIRM staff advice been solicited?
• Can the application be satisfied by using an existing system or its software (e.g.,
software reuse, off-the-shelf software, consulting the EPA Information System
Inventory)?
Some of the factors which should be addressed when determining the hardware/software
environment 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)
• 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 Natural/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 and;
• Large Systems - are generally programmed using either 3GLs or 4GLs with or without
data base support, and they run in the mainframe environment.
The content of each matrix cell and the criteria of small, medium and large systems are
simplified to make them useful. There are several decision criteria along the legs of the matrices
and numbers in the intersections of the rows and columns which correspond to the software
support tools. The key for the software support tools is:
1 - Mainframe
2-Mainframe
3 -Mainframe
4- Mainframe
5 - Minicomputer
6 - Minicomputer
7 - Microcomputer
8 - Microcomputer
9 - Microcomputer
3GL/DBMS (COBOL, PL/I, FORTRAN)
4GL/DBMS (Natural/ADABAS)
4GL (FOCUS)
4GL (NATURAL/VSAM)
3GL (COBOL, FORTRAN, PASCAL)
4GL (FOCUS, INFO)
4GL (INFO, FOCUS, dBASE IH)
4GL/DBMS (dBASE HI)
3GL (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 TOTAL SIZE < 10 MEGABYTES \
Number of Simultaneous Users
Complex Random Retrievals?
Location
of Related
Data
None
Main-
Frame
Mini-
Computer
PC
1
YES
2.3.8.7
2.3
6
7.8.9
NO
2.3.4.6.7
2.3.4
6
7.8.9
l 13 |
YES
2
2
2
2
NO j
2.3.4 :|
2.3.4
2.3.4
2.3.4 j
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)
4GUDBMS (Natural/ADABAS)
4GL (FOCUS)
4GL (NATURAL/VSAM)
3GL (COBOL, FORTRAN, Pascal)
4GL (FOCUS. INFO)
4GL (INFO. FOCUS, dBASE HI)
4GUD8MS (dBASE D3)
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<§ 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
u, ...^^mmmmmmiim
Moderate Amount
of Change per Day
& 15
YES
2.3.6
6
2.3
mm
NO
2.3.
4.6
6
2.3.4
L
> 15
YES
2
2
2
••
NO
2.4
2.4
2.4
.
Volatile
* 15
YES
2.6
5.6
2
-
NO
2.3.
4.6
5.6
2.3.4
mm
> 15
YES
2.3
2.3
2.3
am
NO
2.4
2.4
2.4
-
Highly
Volatile
S 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
H^^RBJ
Notes:
1 - Mainframe
2-Mainframe
3 - Mainframe
4 - Mainframe
5 - Minicomputer
6 - Minicomputer
3GL/DBMS (COBOL. PL/I, FORTRAN)
4GL/DBMS (Namral/ADABAS)
4GL (FOCUS)
4GL (NATURAL/VSAM)
3GL (COBOL, FORTRAN. Pascal)
4GL (FOCUS, INFO)
3-6
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 3-4
SOFTWARE SUPPORT TOOL SELECTION MATRIX
LARGE SYSTEMS
LARGE SYSTEMS -i RECORDS > 100K OR TOTAL SOB > 10O MEGABYTES
Volatility
Number of
Simultaneous Users
Complex Random
Retrieval*?
File
Pass
Frequency
n« 1
per day
1 4O
per day
Almost Static
(Update Weekly or Less)
S IS
YES
2.3
2
Hybrid
1.2
NO
2.3.4
2.4
I
> IS
YES
2
2
Hybrid
1.2
NO
2.4
2.4
4
Moderate Amount of
Change or Volatile
S 15
YES
2
2
Hybrid
1.2
> 15
NO
2.4
2.4
4
Highly 1
Volatile ;!
S IS
YES
1.2
1.2
Hybrid
1.2
> 15 I
NO 1
1.2 :
1.2 :
Hybrid
1.2 ;
Notes:
1 -Mainframe
2- Mainframe
3 - Mainframe
4-Mainframe
3GL/DBMS
4GL/DBMS
4GL
4OL
(COBOL, PUI, FORTRAN)
(Naural/ADABAS)
(FOCUS)
(NATURAL/VSAM)
3-7
-------
EPA System Design & Development
Guidance: Volume C
3.1.2 Source Program Design and Coding Conventions
EPA has a general set of minimum program design and program coding standards which
promote productivity, source code maintainability and software sharing and reuse. These
standards are patterned after the standards used by the Department of Defense. The salient
characteristics of these standards are:
• Use of structured programming constructs to control the flow of execution
• Elimination or significant reduction in the use of "GO TO" statements and complicated
negative Boolean expressions
• 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 SPFrTAT 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
(NDFD).
3-8
-------
EPA System Design & Development
Guidance: Volume C
3.3 HARDWARE/SOFTWARE ENVIRONMENTS
The EPA hardware/software environments available for software development are
presented in Exhibit 3-6. This exhibit identifies the EPA software packages that are available and
the hardware environments in which each of the software packages is supported. The exhibit
provides a representative sample of available MS-DOS and Macintosh application software. The
Macintosh computer is included as a potential option for development of Localized (Type II) or
User Owned (Type HI) information systems. Any software development effort which uses
software packages or hardware outside the EPA Hardware/Software Environments must have
approval from the Director, Office of Information Resources Management (OERM).
3-9
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 3-5
EPA STANDARD SPECIALIZED SOFTWARE TOOLS
FUNCTION
TOOL
INTEGRATED
WITH
DataBase
Management
Graphics
Geographies
Spreadsheet
Word Processing
Text Processing
and Retrieval
Programmer Tools
Software
Maintenance Tools
Communications
Software
ADABAS
DBASE m PLUS
SASGRAPH
TELAGRAPH
VERSAGRAPH
ARC/INFO
UNIRAS
LOTUS 1-2-3
20/20
SUPERCALC
LEXTTYPE
WORDSTAR
MULTI-MATE
TEXT
WORD MARC
BASIS
INFO-TEXT
ISPF
EMACS
LIBRARIAN
COBOL DEBUGGERS
PL/I DEBUGGERS
FORTRAN DEBUGGERS
SNA
DECNET
NATURAL
SUPER NATURAL
SAS
INFO
INFO
INFO-TEXT
INFO
GNETH
PRIMELJNK
CROSSTALK
KERMIT
ARBITER
Bulk Data Transfer (BDT)
3270 FC FILE
TRANSFER (IND$FILE)
Data Transfer Facility (DTF)
PRIME/PC Connection
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 III PLUS
EASYTRIEVE PLUS
Data flatM 'Mmnmtt+mientl
"*" ^n^ir ^ m~**mmm*
AOABAS
Graphic* Facilities:
*"
TELL-A-GRAPH/Cuechart
VERSAGRAPH
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-
intosh
LAN
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
3-11
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 3-6
AGENCY-SUPPORTED HARDWARE AND SOFTWARE
(CONTINUED)
TOOLS
TARGET HARDWARE ENVIRONMENT
IBM
3090
IBM
43XX
Geographic Information Systems:
ARC /INFO
UNIRAS (Pilot)
Word and Text Software:
LEXITYPE
WORDSTAR
MULTIMATE
WORDPERFECT
WORDMARC
BASIS
TEXTWP
INFO-TEXT
MACWRJTE
MICROSOFT WORD
Project Management:
TELL-A-PLAN
MICROSOFT PROJECT
TIMELINE
•
•
•
Telecom Capabilities:
SNA (3270/RJE)
ASYNCH ASCII
X.25
PRIMENET
DECNET
CROSSTALK
KERMIT
UNETII
•
•
•
•
•
•
•
DEC/
VAX
PRIME
MS
DOS
Mac-
intosh
•
•
•
•
•
•
«
•
•
•
•
•
•
•
•
•
•
•
•
•
•
LAN
•
•
•
•
•
•
•
•
•
*
•
•
•
•
•
•
•
•
•
3
•
•
•
•
3-12
-------
EPA System Design & Development
Guidance: Volume C
EXHIBIT 3-6
AGENCY-SUPPORTED HARDWARE AND SOFTWARE
(CONTINUED)
TOOLS
TARGET HARDWARE ENVIRONMENT
IBM
309O
IBM
43XX
DEC/
VAX
Telecom Capabilities (Cent.):
PRJMELINK
NATURAL/CONNECTION
SAS/RLJNK RTERM
3270 PC FILE TRANSFER (IND»FILE)
ARBITER
BULK DATA TRANSFER (BDT)
DATA TRANSFER FACILITY (DTF)
NOVELL NETWARE
Electronic Mail:
DIALCOM SERVICE
LOCAL CAPABILITIES
**«*gni*Ti»i(i*r Productivity Aidn/Fa
ISPF
LIBRARIAN
EMACS
COBOL DEBUGGER
FORTRAN DEBUGGER
EVE^TPU
VAXSET
TVffkTop Publiffhing:
PAGEMAKER
VENTURA PUBLISHER
•
•
•
•
•
PRIME
•
MS
DOS
•
•
•
•
•
Mac-
intosh
LAN
•
•
•
cilities:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
3-13
-------
Chapter Four
SYSTEM DESIGN, DEVELOPMENT, AND
IMPLEMENTATION OVERVIEW
This chapter addresses the third phase of the system development life cycle - the System
Design, Development and Implementation phase and provides amplifying details on the three
stages which comprise this phase:
• System Design Stage * which comprises tasks and activities associated with System
Detailed Requirements Analysis, Preliminary Design and Detailed Design;
• System Development Stage - which comprises tasks and activities associated with
System Production and Programming and System Integration, Test and Evaluation; and
• System Implementation Stage - which comprises tasks and activities associated with
System Installation.
For each stage, this chapter presents the associated tasks and activities that must be accomplished
under each task. During each task, EEI documentation is prepared or revised. Also, indicated is
the status of 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 <&
Guidance: Volume C
Development
Exhibit 4-1
EEI DOCUMENTATION
Documentation
Keviews
Baselines
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
EEI-10
EEI-11
Develop-
ment Test
And
Evaluation
Review
Product
Baseline
System
Integration.
Test and
Evaluation
EEI-12
Opera-
tional Test
And Eval-
uation
Review
Opera-
tional
Baseline
System Implementation
System
Installation
User
Accept-
ance
System
Operations and
Maintenance
4-2
-------
EPA System Design & Development
Guidance: Volume C
4.1.1 System Detailed Requirements Analysis
The major inputs to this task are the:
• Mission Needs Statement document produced during the Mission Needs Analysis
phase ~ defined in Volume A
• Preliminary Design and Options Analysis Document and Project Management Plan
produced during the Preliminary Design and Options Analysis phase ~ defined in
Volume B.
These documents are used in performing the detailed requirements analysis for the software
system. The conclusions of these documents are confirmed by the software development staff that
will ultimately produce the software system.
This task entails further analysis of the problem, the definition of the functional
components of the major software and hardware elements of the system and association of
functional components to requirements. The scope of the software development project is revised,
if necessary, and further defined.
4.1.1.1 Activities
The activities associated with the System Detailed Requirements Analysis are:
• Confirm the analysis of current systems that have been reviewed and their
adequacy/inadequacy for use in solving the problem
• Confirm the alternative solutions that have been proposed and ensure that the selected
alternative is the one that should be used
• Prepare the System Implementation Plan (EEI-4)
Identify events, actions and milestones
Identify resource requirements
• Review schedules and work plans
• Produce integrated project plan
4- 3
-------
EPA System Design & Development
Guidance: Volume C
• Prepare 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)
• 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 EEI-4 (Fnal)
• System Detailed Requirements
Document EEI-5 (Preliminary)
• Software Management Plan EEI-6 (Preliminary)
4-4
-------
EPA System Design & Development
Guidance: Volume C
4.1.1.3 System ^pgujrements 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 baselined, any changes to that
document represent a change in the scope of the project and must have management approval. The
Functional Baseline is established after a successful System Requirements Review.
4.1.2 Preliminary Design
The Preliminary Design task represents the initial effort in producing a design that can be
used in developing an operational software product
4.1.2.1 Activities
The activities associated with Preliminary Design are:
Confirm that candidate packages/existing software can be used or integrated into the
new system
• Prepare Software Design Document (EEI-8)
- Identify each software design requirement
4-5
-------
EPA System Design & Development
Guidance: Volume C
- Identify the functional flow of the system, address each design requirement and
describe each requirement and associated software design functions (SDFs)
Detail each SDF by defining:
-- Inputs
-- Local Data
— Initiation, liming 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 (EEI-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
— 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
Documentation associated with the Preliminary Design task includes:
• Software Management Plan EEI-6 (Update)
• Software Test and
Acceptance Plan EEI-7 (Preliminary)
• Software Design Document EEI-8 (Final)
4.1.2.3 Preliminary Design Review
The Preliminary Design Review is performed for each system element to ensure the
adequacy of the preliminary design and the test plans for verifying the accuracy of the software
system. The Software Design Document and the Software Test and Acceptance Plan are the
primary subject of the review. The updated Software Management Plan is also input to the review
process.
The purpose of the Preliminary Design Review is to:
• Evaluate the progress, technical adequacy and risk resolution (on a technical, cost and
schedule basis) of the selected design approach
• Determine the compatibility of the selected design approach with the requirements and
performance of the System Detailed Requirements Document
• Establish the existence and compatibility of the physical and functional interfaces
among the other elements (equipment, facilities, computer programs and personnel)
• Determine the adequacy of the test plans in accurately verifying the software system
against the design criteria.
The Preliminary Design Review takes place at the end of the Preliminary Design task. A
successful Preliminary Design Review results in the establishment of the Preliminary Design
Baseline. OIRM/SIRMO representatives should participate in the Preliminary Design Review.
4-1
-------
EPA System Design & Development
Guidance: Volume C
4.1.2.4 Preliminary Design Baseline
The Preliminary Design 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 (EEJ-7). Once these documents are baselined, any changes to
those documents represent a change in the scope of the project and must have management
approval.
4.1.3 Detailed Design
The Detailed Design task represents the final effort in producing a detailed design that will
be used in developing an operational software product The Software Design Document is updated
with detailed design specifications. The additional detail is added to produce a detailed design
adequate for code production. The first draft of the Software User's Reference Guide should be
prepared. The Software Management Plan and Software Test and Acceptance Plan are updated as
necessary. The Project Management Plan and Benefit-Cost Analysis should be updated during this
task.
4.1.3.1 Activities
The activities associated with Detailed Design include:
• Update Software Design Document (EEI-8)
- Update/refine design information
- Decompose each Software Design Function
- Software Unit Formal Parameters
- Software Unit Inputs
- Software Unit Local Data
— Software Unit Processing
-- Software Unit Outputs
- Software Unit Limitations
~ Use of other software elements
4-9
-------
EPA System Design & Development
Guidance: Volume C
Data Base Physical Design
-- File
-- Record
-- Field
~ Item
• Prepare initial draft of the Software User's Reference Guide (EEI-11) with at least
sections one through three completed and a detailed outline of the remainder of the
document
Description of the system
System access techniques
User analysis/reporting options
- Data entry and update process
- User support and training program/sources
Security requirements
• Update the Preliminary Design and Options Analysis (EEI-2) with revised benefit-cost
analysis
• Update Program Management Plan (EEI-3)
• Update Software Management Plan (EEI-6)
• Update Software Test and Acceptance Plan (EEI-7).
4.1.3.2 Documentation
Documentation associated with 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 EEI-7 (Final)
• Software Design Document EEI-8 (Final)
• Software User's
Reference Guide EEI-11 (Preliminary)
4.1.3.3 Critical Design Review
The Critical Design Review is conducted for each system element when the detailed design
is complete. The updated Software Design Document and the updated Software Test and
Acceptance Plan are the primary subject of the review. The Software Management Plan and the
Software User's Reference Guide are also input to the review as necessary. The purpose is to
accomplish the following:
• Determine that the detailed design of the software system element under review satisfies
the performance requirements of the System Detailed Requirements Document
• Establish compatibility among system elements in the detailed design
• Assess the productivity and risk areas (on a technical, cost and schedule basis).
• Review the preliminary product specifications.
A successful Critical Design Review establishes or updates the Design Baseline. The Design
Baseline is then used as the basis for the production and coding of the software system.
OIRM/SIRMO representatives should participate in the Critical Design Review.
4.1.3.4 Design Baseline
The Design Baseline is established after a successful Critical Design Review. It consists of
the final design specifications — including data base specifications and the test plans associated
with the software product The Detailed Design Baseline is made up of the Software Design
Document (EEI-8) and the final Software Test and Acceptance Plan (EEI-7). Once these
documents are baselined, any changes to the documents represent a change in the scope of the
project and must have management approval
4-11
-------
EPA System Design & Development
Guidance: Volume C
4.2 SYSTEM DEVELOPMENT STAGE
Associated tasks include System Production and Programming, and System Integration,
Test and Evaluation.
4.2.1 System Production and Programming
The specifications developed during the System Design stage 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-12
-------
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 (EEI-11).
4.2.1.2 Documentation
Documentation associated with the System Production and Programming task includes:
• Software Maintenance Document EEI-9 (Preliminary)
• Software Operations Document EEI-10 (Preliminary)
• Software User's Reference
Guide EH-11 (Update)
• Unit Tested Source Code
• Unit Test Data.
4-13
-------
EPA System Design & Development
Guidance: Volume C
4.2.1.3 System Production and Programming Reviews
Preliminary Functional Configuration and Physical Configuration reviews are performed as
each piece of software is delivered for inclusion into the product baseline. They confirm that the
software product or component of the software product performs according to the requirements
and design specifications that have been prepared and baselined during System Design. The
results of the review are input to the Development Test and Evaluation Review.
The Development Test and Evaluation Review ensures that the developmental testing of the
software is successful and that the system requirements are satisfied. The Software Maintenance
Document, the Software Operations Document, the updated User's Guide, the results of the
Functional Configuration Review and the results of the Physical Configuration Review are also
reviewed for completeness and accuracy. Upon completion of a successful review, these
documents are placed in the Product Baseline.
The Development Test and Evaluation Review is performed at the end of the System
Production and Programming task. A successful Development Test and Evaluation Review
establishes or updates the Product Baseline. OIRM/SIRMO representatives should participate in
the Development Test and Evaluation Review.
4.2.1.4 Product Baseline
The Product Baseline establishes a tested, operable version of the software system in its
operating environment. As each subsystem is successfully tested, the product baseline is updated.
The baseline of the completed and tested version of the software product ensures that any changes
or enhancements take place against a stable, controlled set of functional and technical components.
The Product Baseline will include the completed product specifications, the on«r«i*icn/niainienance
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 Svstem 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.
4.2.2.1 Activities
The activities associated with the System Integration, Test and Evaluation task are:
• Install the working system using the installation procedures
• Execute the System Test portion of the Software Test and Acceptance Plan
• Document any discrepancies noted during testing for resolution with the development
team and user
• Verify that discrepancies that require software modification have been modified
correctly
• Prepare System Integration Test Report (EEI-12)
• Recommend disposition of the software and documentation
• Update Software Maintenance Document (EEI-9), Software Operations Document
(EEI-10), and Software User's Reference Guide (EEM1).
4.2.2.2 Documentation
Documentation associated with the System Integration, Test and Evaluation task includes:
• Software Maintenance Document EEI-9 (Update)
• Software Operations Document EEI-10 (Update)
4.15
-------
EPA System Design & Development
Guidance: Volume C
• Software User's Reference
Guide EEI-11 (Update)
• System Integration Test Reports EEI-12 (Final)
• System Integration Tested Software
• System Integration Test Data
4.2.2.3 System Integration. Test and Evaluation Reviews
The final Functional Configuration and the Physical Configuration reviews are performed
when all the subsystems are delivered and integrated into 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. OERM/SIRMO representatives should participate in the Operational Test and Evaluation
Review.
4.2.2.4 Operational Baseline
The Operational baseline represents the completely implemented and tested software
system. It is the basis for future maintenance changes and enhancements. All documentation is
modified, as required, validation and system testing is completed and the system is placed in
production and/or turned over to the user. The Operational Baseline is established and/or updated
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 RequL^ments EEI-5 (Final)
Document
• Software Management Plan EEI-6 (Final)
• Software Design Document EEI-8 (Final)
• Software Maintenance Document EEI-9 (Final)
4-17
-------
EPA System Design & Development
Guidance: Volume C
• Software Operations Document EEI-10 (Final)
• Software User's Reference Guide EEI-11 (Final)
• System Integration Test Reports EEI-12 (Final)
4.3.1.3 System Implementation Review
The System Implementation Review ensures the new system has been accepted by its users
and is ready to begin full operation. During the implementation stage, problems, users likes and
dislikes, in addition to possible enhancements are identified. The procedures for addressing these
concerns are reviewed and software is enhanced following system operations and maintenance
procedures.
4.3.2 System Operations and Maintenance
Procedures for the operating and maintaining fully installed systems are important in
ensuring that the system continues to operate effectively throughout its life cycle and that
obsolescence is declared when the system no longer fulfills the requirement. Procedures for
operating and maintaining an existing system are contained in OIRM's Operations and Maintenance
Manual. This manual has been created as the follow-on guidance for EPA's System Design and
Development Guidance. The manual will assist system managers in developing proper operating
procedures, defining staff responsibilities, documenting system requirements, designing follow-on
training programs and performing configuration management The Operations and Maintenance
Manual should be followed to ensure the resources dedicated to the system after implementation,
will be used in the most efficient and effective manner.
4-IS
-------
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
• EEM1. 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
The documentation requirements contained in this appendix apply to all software
development projects, regardless of size, complexity or origin - except as noted in subsection
1.6, "Determining Documentation Requirements" in Chapter 1 of this Volume. At a minimum,
these standards apply to all new software development projects. Maintenance and/or enhancements
to existing information systems must comply with the requirements set out in Chapter 1, section
1.5 of Volume C, System Design, Development and Implementation.
Compliance with the standards and conventions provided in this appendix will ensure that
adequate documentation is produced for all system development projects.
The documents defined in this appendix are:
EEI-4 • • System Implementation Plan
EEI-5 • • System Detailed Requirements Document
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
EEM1 • • 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-l
-------
EPA System Design & Development
Guidance: Volume C
The following milestone chart illustrates the relative initiation and completion o, each
document w,,h respect to the software development life cycle, its major phases, and the span and
scope of Volumes A, B, and C.
A-2
-------
Mission Needs Analysis
EEI-1
Preliminary Design/
Options Analysis
EEI-2
EEI-3
System Detailed
Requirements Analysis
EEI-4
EEi-5
EEI-6
Preliminary Design
EEI-7
EEI-8
Detailed Design
EEI-8
System Production
and Programming
EEI-9
EEI-10
EEI-11
System Integration
Testing & Evaluation
EEI-12
System Installation
Volume C
System Preliminary Critical
Requirement Design Design DT&E
Review Review Review Review
OT&E
Review
Ac -.tftiiuttst
o
o
n
w
2:
H
O
2!
PI
50
C
r
*-«
w
n
n
r
w
on
c -o
Z>
ta
a in
n •<
I?
9 £.
O
T3
B
-------
EPA System Design & Development
Guidance: Volume C
EEI-4
SYSTEM IMPLEMENTATION PLAN
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
REFERENCED DOCUMENTS
2.1 Government Documents
2.2 Non-government Documents
IMPLEMENTATION PLAN
3.1 Plan Management
3.1.1 Policy Events and Actions
3.1.2 Program Management
3.1.3 Strategy for Acquiring 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
3.1.4.1 Environmental Data
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. i.6.3 Commercial Vendors
3.1.7 Information Systems
3.1.7.1 Automated
3.1.7.2 Manual
3.18 Process and Procedure
3.2 Work Plans and Schedules
A-4
-------
EPA System Design & Development
Guidance: Volume C
EEI-4
SYSTEM IMPLEMENTATION PLAN
(Continued)
3.3 Resource Requirements
3.3.1 Contractor
3.3.2 Personnel
3.3.3 Facilities
3.3.4 Government Furnished Property
3.4 Integrated Project Plan
4. NOTES
5. APPENDICES
6. GLOSSARY
A-5
-------
EPA System Design & Development
Guidance: Volume C
EEI-5
SYSTEM DETAILED REQUIREMENTS DOCUMENT
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. DETAILED CHARACTERISTICS AND REQUIREMENTS
3.1 System Definition Requirements
3.1.1 System Purpose
3.1.2 Concept of Operation
3.1.3 System Sizing and Timing Requirements
3.1.4 Design Standards
3.1.5 Design Constraints
3.1.6 Data Requirements
3.2 Subsystem Definition Requirements
3.2.1 Subsystem #1
3.2.1.1 Subsystem #1 Purpose/Definition
3.2.1.2 Subsystem #1 Interface Definition
3.2.1.2.1 Network
3.2.1.2.2 Software Systems
3.2.1.2.3 DataBase
3.2.1.2.4 Entity Relationships
3.2.1.3 Assumptions and Constraints
3.2.1.4 Subsystem f 1 Level II Requirement 1
3.2.1.4.1 Level n Requirement 1 Description
3.2.1.4.1.1 Level in Detailed Functional
Requirement
A-6
-------
EPA Svstern Design & Development
Guidance: Volume C
EEI-5
SYSTEM DETAILED REQUIREMENTS DOCUMENT
(Continued)
3.2.1.4.1.1.1 Tide and
Description Of
Level m
Function 1
3.2.1.4.1.1.* Title and
Description Of
Levelm
Function *
3.2.1.4.1.* Level 03 Requirement *
Description
3.2.1.4.* Levein Requirement * Description
3.2.* Subsystem*
3.3 System Physical Requirements
3.3.1 HVAC and Electrical Requirements
3.3.2 Facilities Management
3.3.3 Computer Hardware Requirements
3.3.4 Computer Operating System Requirements
3.3.5 Software Utilities and Tools
3.4 System Security Requirements
3.4.1 System Backup Procedures
3.4.2 Review/Activity Log Files
3.4.3 Disaster Recovery Procedures
3.5 Quality Requirements
3.5.1 Reliability
3.5.2 Maintainability
3.5.3 Flexibility and Expansion
3.5.4 Transportability
3.6 Life Cycle Requirements
3.6.1 Software Maintenance Personnel
3.6.2 User Support and Training
3.6.3 Hardware and Supplies
A-7
-------
EPA System Design & Development
Guidance: Volume C
SYSTEM DETAILED REQUIREMENTS DOCUMENT
(Continued)
4. Testing and Verification Requirements
4.1 Testing Requirements
4.1.1 Method
4.1.2 Responsibility
5. Project Schedules and Work Plans
5.1 Schedules
5.2 Work Plan
5.2.1 Personnel
5.2.2 Milestones
5.2.3 Budget
6. NOTES
7. APPENDICES
8. GLOSSARY
A-t
-------
EPA System Design & Development
Guidance: Volume C
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. REFERENCED DOCUMENTS
2.1 Government Documents
2.2 Non-government Documents
3. PLANNING
3.1 Project Resources
3.1.1 Contractor Facilities
3.1.2 Government Furnished Equipment, Software and Services
3.1.3 Personnel
3.1.4 Organizations Responsible for Design, Implementation, Configuration
Management, Reliability and Quality Assurance
3.2 Review Responsibilities
3.3 Software Development
3.3.1 Organization Structure
3.3.2 Personnel
3.3.3 Resources
3.3.4 Software Development Tools, Techniques, Methodologies and Standards
3.3.5 Manual Procedures/Forms
4. MANAGEMENT CONTROLS
4.1 Project Schedule, Reviews and Report Controls
4.1.1 Work Plan
4.1.2 Activity Network and Dependencies
4-1.3 Risk Areas
4.2 Risk Management
4.1.1 New Technologies
4.1.2 Backup - Recovery
4.1.3 Manual Procedures/Forms
A-9
-------
EPA System Design & Development
Guidance: Volume C
EEI-6
SOFTWARE MANAGEMENT PLAN
(Continued)
5 SOFTWARE PRODUCT ASSURANCE
5.1 Software Configuration Management
5.2 Software Independent Verification and Validation
5.3 Software Security
5.4 Software Reliability and Quality Control
5.5 Software Interface Definition
5.6 Software Waivers to Policy and Procedures
5.6.1 Permanent Waivers
5.6.2 Temporary Waivers
5.6.3 Tools and S tandards 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 Repents
6. SOFTWARE DEVELOPMENT PROCEDURES
6.1 Software Standards and Procedures
6.1.1 Software Tools
6.1.2 Commercial and Reusable
6.1.2.1
<*. 1-2..L
Data Rights and Docunsentation
Certification
A-10
-------
EPA System Design & Development
Guidance: Volume C
Ee-6
SOFTWARE MANAGEMENT PLAN
(Continued)
6.1.3 Software Test Tools
6.1.4 Software Design
6.1 +.1 Software Design Methodology
6.1.4.2 Programming Language
6.1.4.2 Interface Methodology
6.1.4.4 Network Methodology
6.1.5 Software Design and Coding Standards
6.1.6 Firmware
6.2 Software Configuration Management
6.2.1 Configuration Identification
6.2.1.1 Documentation Baselines
6.2.1.2 Methods and Approach to Standards Implementation
6.2.2 Configuration Control
6.2.2.1 Configuration Control Flow Diagram
6.2.2.2 Forms
6.2.2.3 Storage and Release of Master Copies
6.2.3 Configuration Reviews
7. NOTES
8. APPENDICES
9. GLOSSARY
A-11
-------
EPA System Design & Development
Guidance: Volume C
EEI-7
SOFTWARE TEST AND ACCEPTANCE 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. REFERENCED DOCUMENTS
2.1 Government Documents
2.2 Non-government Documents
3. LIMITATIONS/TRACEABILITY
3.1 Limitations
3.2 Traceability
4. TEST PLANS
4.1 Software Unit Testing (includes Manual Procedures)
4.1.1 Test Requirements
4.1.2 Test Management
4.1.2.1 Integration Test Team Organization and Responsibility
4.1.2.2 Responsibilities of Other Organizations
4.1.2.3 Product Control
4.1.2.4 Test Control
4.1.2.5 Evaluation and Retest Criteria
4.1.2.6 Test Reporting
4.1.2.7 Test Review
4.1.2.8 Test Identification
4.1.2.9 TestData Environment
4.1.3 Test Schedule
4.1.4 Test Results
4.2 Integration Testing of Software Units, Modules and Software Functions/Risk
Management
4.2.1 Integration Test Requirements
4.2.2 Integration Test Management
4.2.3 Integration Test Categories
4.2.4 integration Test Methods
4.2.5 Integration Test Schedules
4.2.6 Integration Test Results
A-12
-------
EPA System Design & Development
Guidance: Volume C
EEI-7
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
EEI-8
SOFTWARE DESIGN DOCUMENT
1. INTRODUCTION
1.1 Purpose
1.2 Background
1.3 Scope
1.4 System References
1.5 Terms and Abbreviations
1.6 Organization of This Document
2. REFERENCED DOCUMENTS
2.1 Government Documents
2.2 Non-government Documents
3. SOFTWARE DESIGN REQUIREMENTS (SDR)
3.1 Concepts
3.2 Functional Flow
3. n (Insert Name) Requirement
3. *. 1 Description of Requirements and Associated Software Design Functions
(SDFs), including Manual Procedures
4. 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 Algorithms
4.*.5.2 Error Handling
4. *. 5.3 Test S truciures
4.*.6 Outputs
4.*.7 Adaption
5. Software Function Requirements (SFR)
5.1 SFR External Interfaces (including Manual Procedures)
5.1.* (Insert Name) Interfacer
5.1.*.* (Insert Name) Software Unit (SU)
A-14
-------
EPA System Design & Development
Guidance: Volume C
EEI-8
SOFTWARE DESIGN DOCUMENT
(Continued)
6. Detail Design
6.* (Insert Name) SFR
6.M SFR Inputs
6.*.2 SFR Local Data
6.*.3 SFR Processing
6.*.3.1 Control
6.*.3.2 Algorithms
6.*.3.3 Error Handling
6. *. 3.4 Data Conversion
6.*.3.5 Test Structure
6. *. 3.6 Manual Procedures
6.*.4 SFR Outputs
6.*.5 SFR Decomposition
6.*.5.1 (Insert Name) Software Unit (SU)
6.*.5.*.1 SU Formal Parameters
6.*.5.*.2 SU Inputs
6.*.5.*.3 SU Local Data
6.*.5.*.4 SU Processing
6.*.5.*.5 SU Outputs
6.*.5.*.6 SU Limitations
6.*.5.*.7 Use of Other Elements
6.*.5.*.8 Manual Procedures
7. Data Base Design (If Applicable)
7.1 Data Base Management System
7.2 Data Structure (Logical Design)1
7.3 Interrelationships
7.4 Design Characteristic/Requirements Traceability
7.5 Physical Design2
7.5.* File (Insert Name)
7.5.*.* Record (Insert Name)
1 For ADABAS refer to EPA/NCC ADABAS Application Development Procedures Manual for CDB A
requirements
2 For ADABAS refer to EPA/NCC ADABAS Application Development Procedures Manual for CDB A
requirements
A-15
-------
EPA System Design & Development
Guidance: Volume C
EEI-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 & Development
Guidance: Volume C
EEI-9
SOFTWARE MAINTENANCE DOCUMENT
1. INTRODUCTION
1.1 Purpose
1.2 Background
1.3 Scope
1.4 System References
1.5 Terms and Abbreviations
1.6 Organization of This Document
2. REFERENCED DOCUMENTS
2.1 Government Documents
2.2 Non-government Documents
3. MAINTENANCE PROCEDURES
3.1 Source Code Standards
3.2 Documentation Update (including non-software elements)
3.3 Coding and Review Process
3.3.1 Top Down Approach
3.3.2 Peer Review
3.3.3 Walkthrough
3.3.4 Team Leader Review
3.4 Change Control Process
3.4.1 Change Request
3.4.2 Code Review
3.4.3 Review and Approval
3.4.3.1 Maintainer
3.4.3.2 User
3.5 Testing Standards and Procedures
3.5.1 Test Plans
3.5.2 Test Data
3.5.3 Test Scenarios
3.5.4 Test Results
3.6 Change Implementation Methods
3.6.1 Test to Production Method
A.17
-------
EPA System Design <& Development
Guidance: Volume C
SOFTWARE MAINTENANCE DOCUMENT
(Continued)
4. MAINTENANCE TOOLS
4.1 Technical Tools
4.1.1 Processing Tools
4.1.1.1 Compilers
4.1.1.2 Cross Reference
4.1.1.3 File Comparator
4.1.1.4 Traces/Dumps
4.1.1.5 Test Data Generator
4.1.1.6 Test Coverage Analyzer
4.1.1.7 Preprocessor
4.1.1.8 Verification/Validation
4.1.2 Clerical Tools
4.1.2.1 On-line Editor
4.1.2.2 Documentation Library
4.1.2.3 Archival Processor
4.1.2.4 Source Code Reformatter
4.1.2.5 Data Dictionary
4.2 Management Tools
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-18
-------
EPA System Design & Development
Guidance: Volume C
EEI-10
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.M Execution
3.2.*.2 Inputs
3.2.*.2.1 User Inputs
3.2.*.2.2 System Inputs
3.2.*.3 Outputs
3.2.*.4 Termination
3.2.*.5 Error Messages
3.3 System Manager
3.3.1 Manager's Functions/Menu
3.3.1.* (Insert Name) Function
3.4 System Backup/Recovery Provisions
3.5 System Security
4. NOTES
5. APPENDICES
6. GLOSSARY
A-19
-------
EPA System Design & Development
Guidance: Volume C
EEI-11
SOFTWARE USER'S REFERENCE GUIDE
1. INTRODUCTION
1.1 Purpose
1.2 Background
1.3 Scope
1.4 System References
1.5 Terms and Abbreviations
1.6 Organization of This Document
2. REFERENCED DOCUMENTS
2.1 Government Documents
2.2 Non-government Documents
3. DESCRIPTION OF THE SYSTEM
3.1 System Overview and Mission Based Activities
3.2 System Flow and Data Descriptions
3.3 System and Program Manager
3.4 Data Dictionary
4. SYSTEM ACCESS TECHNTQUE(S)
4.1 Hardware/Software Interface(s)
4.2 Menus and Other Methods of Access
4.3 Manual Procedures
5. USER ANALYSIS / REPORTING OPTIONS
5.1 Standard Reports
5.2 Ad-hoc Capabilities
5.3 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
U.S. Environmental Protection Agency
Eovion 5, Library (5PL-16)
230 S. Dearborn Street, Room 1670
Ohicago, IL 60604
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
-------