-------
-------
EPA Operations & Maintenance Manual
TABLE OF CONTENTS
Tide Page
1. INTRODUCTION 1-1
1.1 BACKGROUND 1-1
1.2 OBJECTIVES 1-4
1.3 AUTHORITY 1-5
1.4 APPLICABILITY OF THE GUIDANCE 1-5
1.5 ASSISTANCE AND SUPPORT AVAILABLE 1-6
1.6 ORGANIZATION 1-6
1.7 SUMMARY 1-7
2. SYSTEM OPERATION 2-1
2.1 ADMINISTRATIVE CONTROL PROCEDURES 2-1
2.1.1 Control of System Access 2-3
2.1.2 Parameter and Table Specification 2-3
2.1.3 User Support 2-4
2.1.4 Supervisory Control of the Production Process 2-6
2.1.5 Archiving 2-6
2.2 COMPUTER CENTER SUPPORT 2-7
2.2.1 Computer Operations 2-7
2.2.2 Production Control 2-9
2.2.3 Backup and Recovery 2-9
2.2.4 Disaster Planning and Recovery 2-10
2.3 USER INTERACTION 2-12
2.3.1 System Access Techniques 2-12
2.3.2 Data Entry and Update Procedures 2-13
2.3.3 Analysis/Reporting Options 2-13
2.3.4 Training 2-15
2.4 APPLICATION SOFTWARE OPERATION 2-16
2.4.1 Systembitialization/Re-initialization 2-17
2.4.2 Error Detection and Recovery 2-17
2.4.3 System Interfacing 2-18
2.5 DOCUMENTATION 2-19
n
-------
EPA Operation; & Maintenance Manual
Tjfle. Page
2.5.1 Software Operations Document 2-19
2.5.2 Software User's Reference Guide 2-19
2.6 OPERATIONAL BASELINE 2-20
2.7 SUMMARY 2-20
3.1 DEFTNlTIONSANDRESPONSIBILrnES 3-1
3.1.1 System Maintenance 3-1
3.1.1.1 Conective Maintenance 3-2
3.1.1.2 Functional Maintenance 3-2
3.1.1.3 Adaptive Maintenance 3-3
3.1.2 Configuration Management Responsibilities 3-3
3.1.2.1 Review of System Functionality 3-5
3.1.2.2 Coding Standards Enforcement and
System Testing 3-5
3.2 CONFIGURATION MANAGEMENT PROCESS 3-6
3.2.1 System Change Requests/Problem Reports 3-7
3.2.2 Analysis of Problem Reports and Change Requests 3-7
3.2.3 Benefit-Cost Analysis 3-9
3.2.4 Change Approval and Action Plan Development 3-10
3.2.5 Software Improvement Increment 3-11
3.2.6 Maintenance Cycles 3-11
3.2.7 Return to a Prior Software Version 3-12
3.2.8 Documentation 3-12
3.3 SUMMARY 3-13
4. SOFTWARE MAINTENANCE 4-1
4.1 MAINTENANCE PROCEDURES 4-2
4.1.1 Documentation Update 4-2
4.1.2 Source Code Standards 4-3
4.1.3 Coding and Review Process 4-3
4.1.4 Testing Standards and Procedures 4-4
in
-------
EPA Operations & Maintenance Mani^d
Title Page
4.2 MAINTENANCE TOOLS 4-5
4.3 DOCUMENTATION 4-5
4.3.1 Software Maintenance Document 4-5
4.3.2 Data Dictionary 4-6
4.3.3 Source Code 4-7
4.4 SUMMARY 4-7
Appendix A
Essential Elements of Information A-l
Appendix B
Glossary B-l
IV
-------
EPA Operations & Maintenance Manual
LIST OF EXHIBITS
1-1 Complete Software Life Cycle 1-2
1-2 EPA System Development Life Cycle
and Decision Process 1-3
1-3 Life Cycle Costs 1-4
2-1 Administrative Responsibilities 2-2
2-2 Disaster Recovery Plan 2-11
3-1 Configuration Management Responsibilities 3-4
3-2 Software Change Request/Problem Report 3-8
-------
Chapter One
INTRODUCTION
There is a recognition throughout the Environmental Protection Agency (EPA) that
a sizable amount of money is being dedicated to support its automated systems. This
guidance was developed in order to help control expenditures for operations and
maintenance activities and to ensure that the resources expended on these activities are used
in the most effective and efficient manner. As a companion to the System Design and
Development (rllidance,, Volumes A, B and C, EPA has prepared this document addressing
the maintenance and operation phase of the software life cycle.
1.1 BACKGROUND
Maintenance is playing an increasingly important role in systems operations. The
Agency is currently spending millions of dollars annually on the design, development,
implementation, operation and maintenance of information systems to support its mission.
The Agency's System Design and Development Guidance was developed by the Office of
Information Resources Management (OIRM) to assist managers in developing the most
productive and efficient system possible to satisfy an information need. That guidance
addresses the following phases of the software life cycle:
Volume A - Mission Needs Analysis
Volume B - Preliminary Design and Options Analysis
Volume C - System Design, Development and Implementation
This Operations and Maintenance Manual completes the guidance for managing the
software life cycle. This document was developed in response to the recognized need for
formal guidance that addresses the day-to-day performance of system operations and
maintenance activities. Exhibit 1-1 graphically highlights the portion of the system life
cycle that is addressed by this guidance. This guidance was designed to apply to all types
of automated systems, including those using standalone and networked (LAN) personal
computers, minicomputers and mainframe systems. Exhibit 1-2 displays the relationship
between the Operations and Maintenance Manual and the three volumes of the EPA System
Design and Develooment Guidance.
1-1
-------
Volume A
Volume B
Mission
Needs
Analysis
Preliminary
Design A
Options
Analysis
Improvement
Increment
Volume C
Operations and Maintenance Manua
-------
EXHIBIT 1-2
EPA SYSTEM DEVELOPMENT LIFE CYCLE
AND DECISION PROCESS
DEVELOPMENT STAGE
DECISION/RESULT
REAL WORLD
MISSION NEED
VOLUME A
MISSION NEEDS
ANALYSIS
SYSTEM REQUIREMENT
AND OPERATIONAL
CONCEPT DEFINITION
VOLUME B
PRELIMINARY DESIGN
& OPTIONS ANALYSIS
SYSTEM OPTION DESIGN,
BENEFIT/COST ANALYSIS,
AND OPTION SELECTION
VOLUME c
SYSTEM DESIGN,
DEVELOPMENT
A IMPLEMENTATION
FULLY
IMPLEMENTED
SYSTEM
QAM MAMIIAL
OPERATIONS
AND
MAINTENANCE
OPERATIONAL SYSTEM
1-3
-------
EPA Operations & Maintenance Manual
1.2 OBJECTIVES
The three phases of the software life cycle, that are discussed in Volumes A, B and
C of the System Design and Development Guidance, represent approximately 55% of the
total life cycle cost for a software application. Exhibit 1-3 illustrates industry average
percentages of the total cost for each phase. It should be noted the operations and
maintenance phase alone consumes 45% of the resources, which is by far the highest
percentage consumed by any one phase. This guidance was prepared to assist managers in
expending their resources in the most efficient manner possible in support of operational
systems.
EXHIBIT 1-3
Life Cycle Costs
Mission Needs Analysis /
Preliminary Design &
Options Analysis 5.0%
Detailed Design
15.0%
Software Operations a I iJJUHIl mrt 5.0%
Maintenance 45.0%
Software Testing,
Integration, Verification, &
Validation 30.0%
These figures are a graphic illustration from Controlling Software Products by
Tom DeMarco, 1982, based on industry averages.
In some instances, the concept of performing system maintenance carries a negative
connotation. Maintenance has been viewed as a response to a system deficiency;
1-4
-------
EPA Operations & Maintenance Manual
something is wrong and therefore needs fixing. Fortunately, the efforts required in
responding to poorly designed systems are only a pan of the overall maintenance function.
Maintenance efforts for any system application can be initiated by several conditions. They
include:
• A new set of mission functions have been mandated by Congress or Senior
Officials causing a modification to an existing system.
• Management has decided to perform a new function on the current system.
• An existing application has been evaluated as being inefficient or ineffective.
• Users have requested enhancements to a current system by requesting new
functions or outputs.
• Operational or data problems have been reported by system users.
• Enhancements to the operating system have necessitated modifications to
applications software.
This manual addresses the process that should be undertaken in response to an occurrence
of any of the above instances.
1.3 AUTHORITY
This document is part of OIRM's Software Management Guidance series. This
series derives its authority from Chapter 4 of the IRM Policy Manual, entitled "Software
Management" This document will serve as the primary guidance for directing Agency
systems operations and maintenance efforts.
1.4 APPLICABILITY OF THE GUIDANCE
This document is intended to assist managers in developing operating procedures,
defining staff responsibilities, documenting system requirements, establishing user support
and performing configuration management While this document does address system
considerations of operations and maintenance, it does not address the task management
1-5
-------
EPA Operations & Maintenance Manual
issues of planning, budgeting and staffing which are subject to the style and constraints of
individual managers. Utilization of this guidance for the many systems throughout the
Agency will promote a uniform approach to the development of operating and maintenance
procedures.
Agency managers, responsible staff and contractor support staff should reference
this guidance both during and after system development and implementation. They are
responsible for developing procedures that control operations and maintenance activities as
well as for ensuring the preparation of adequate system manuals to support these activities.
1.5 ASSISTANCE AND SUPPORT AVATT .ART .F.
Agency managers responsible for oversight of system operations and maintenance
should be aware that there are at least two sources available for assistance and support
during this phase of the software life cycle:
• OIRM, with its general IRM support functions, has staff readily available to
assist managers responsible for maintaining Agency systems.
• Staff from the National Data Processing Division (NDPD) are also available for
assistance, support and guidance relative to operations and maintenance
activities.
OIRM and NDPD officials, working with System Managers, will assure a complete
understanding of operations and maintenance concerns.
1.6 ORGANIZATION
This guidance consists of three chapters which address the various aspects of
operations and maintenance functions:
• Chapter 2 - System Operation — addresses the day-to-day management and
control requirements. These include: 1) administrative controls which detail
activities associated with the control and administration of a system application,
2) computer center support which discusses the various tasks and activities
provided by the computer center, 3) user interaction which defines access
1-6
-------
EPA Operations & Maintenance Manual
techniques and the operating procedures utilized by the user, and 4) applications
software operation which describes the activities associated with maintaining the
stability of applications software.
• Chapter 3 - Configuration Management — addresses procedures for analyzing
and implementing system changes following system implementation. These
include: 1) maintenance definitions and responsibilities of individuals for
configuration management activities, and 2) the configuration management
process which includes the activities concerned with controlling the change
process.
• Chapter 4 - Software Maintenance ~ refers to the actual modification of
software and its associated system manuals. This includes: 1) maintenance
procedures which discuss the procedures and tools to facilitate any software
modifications or enhancements, 2) maintenance tools which describe the special
automated tools available for making source code changes and 3) documentation
which describes the necessary system manuals which should be reviewed or
modified during the maintenance phase of the software life cycle.
1.7 SUMMARY
This chapter introduces the Operations and Maintenance Manual with a presentation
of the need for and objectives of the manual. This manual is intended to complete the
OIRM guidance addressing software management through a presentation of operations and
maintenance activities. The chapter also defines die target audience and the organization of
the document
1-7
-------
Chapter Two
SYSTEM OPERATION
This chapter addresses system operations requiring management and control on a
day-to-day basis in four functional areas:
• Administrative Control - details the responsibilities and activities associated
with the overall control and administration of a system application.
• Computer Center Support ~ describes the various tasks and activities which are
provided by the computer center to ensure the daily operation of a system.
• User Interaction ~ defines the access techniques and operating procedures that
should be followed by a user of a system.
• Application Software Operation - describes the activities associated with
maintaining the stability of the application software for the user community.
Each of these areas will be presented and discussed in this chapter.
2.1 ADMINISTRATIVE CONTROL PROCEDURES
Administrative control procedures are necessary to ensure correct operation of the
system from a managerial standpoint These procedures include:
• Designation of authorized system users
• Specification of system parameters and tables
• User support
• Supervisory control of system operation and report production
• Archiving.
Responsibility for administrative control procedures is typically shared by the System
Manager and Database Administrator as shown in Exhibit 2-1. This division of
responsibilities is not absolute. For small systems, a single person may be charged with all
of these responsibilities. For very large systems, supplemental staff may be utilized to
2-1
-------
EXHIBIT 2-1
ADMINISTRATIVE RESPONSIBILITIES
SYSTEM MANAGER RESPONSIBILITIES
• Provide an interface between the system and its users
• Control system access through the continual evaluation and
determination of current and prospective users and the
assessment or revocation of user IDs accordingly
• Respond to user inquiries
• Update system tables and parameter files
• Establish training
• Promote open communications with the users through
newsletters and user groups
• Evaluate functional system performance.
DATABASE ADMINISTRATOR RESPONSIBILITIES
• Ensure the proper operation of the database management
system (DBMS)
• Supervise data entry, update, and deletion procedures
• Maintain data quality
• Maintain the system data dictionary
• Evaluate technical system performance
• Archive historical data.
2-2
-------
EPA Operations & Maintenance Manual
handle specific responsibilities, such as responding to user inquiries or controlling system
access.
These responsibilities are generally delegated to staff based upon the size and
utilization of a particular system. The responsibilities for the administrative control
procedures for smaller or less active systems may be assigned to a single individual. A
large or very active system may have two staff members involved, one to carry out the
system management functions and one to support the database management requirements.
In the case of larger systems with split responsibilities, the individuals involved are
typically referred to as the System Manager and Database Administrator respectively.
2.1.1 Control of System Access
A primary system management responsibility is the control of procedures for
system access in order to maintain data integrity, availability and confidentiality. The
person in charge of system access should assign access capabilities based on an individual
user's authority to perform specific application functions. System access should be granted
or revoked based on job requirements and security clearances. Some users may have
authority only to enter or look at data while others may need to update and delete data.
Access to system outputs, such as reports or statistical information, may also need to be
controlled.
A more detailed discussion concerning system access controls is contained in the
EPA Information Securit
2.1.2 Parameter and Table Specification
An important area of system control involves parameter specification and table
maintenance. A parameter is defined as an individual variable or constant stored in a file
while a table is a file containing multiple parameters having similar characteristics.
Parameters and tables that are external to individual programs are often used to vary a
system's operation. These may also be used to control a user's functional access authority.
Without the use of these parameters and tables, program source code would require
modification every time a variable needed to be changed.
2-3
-------
EPA Operations & Maintenance Manual
The EPA Payroll System is an example of a system that uses external parameters to
control system operating characteristics. Periodically, information is loaded into the
parameters, specifying the fiscal year, pay period, accounting period and accrual increment
to be used for payroll processing. These parameters are read by the computer program at
the time of execution. Thus, the software can be aligned with real world events without the
necessity of programming changes.
The EPA Combined Payroll Redistribution and Reporting System (CPARS) is an
example of a system that uses an external table file to establish a user profile for control of
functional access. As one of the CPARS administration functions, individual users are
granted or denied access to functional portions of the system, such as report generation or
database modification. This is done by establishing a table file containing functional access
authorities associated with individual user IDs. CPARS uses this table file to supplement
the computer and file access security provided by the Resource Access Control Facility
(RACF) on the mainframe computer. In this way, functional access to the system is
controlled in addition to system and file access.
There are four benefits to using parameters and table files to control system
performance:
• The authority to specify and control these flexible system attributes can be a
tightly controlled system administration function.
• Changes can be made universally for all users by the modification of a single
item of information.
• Programs can be developed independent of the data and do not need to be
modified to change system operational characteristics.
• A host of user-specific information does not need to be entered by the users
each time the software is accessed.
2.1.3 User Support
The growth of user computing and the resulting high investment in computing
resources has identified the need to ensure proper user support in order to maximize
2-4
-------
EPA Operations & Maintenance Manual
productivity and the overall return from this investment. The primary purpose of any
support service is to raise the users' productivity by making them more comfortable with
available technology and improving their skill at using the software to update, access and
manipulate information. In this regard, the person tasked with the administrative system
management responsibilities, the System Manager, should generally become the first point
of contact concerning user-support issues. For very large systems where the number of
calls is great, the first point of contact may be a member of a user-support team. For most
smaller systems, the System Manager or his designee, will become the user's interface with
a specific system or application. This will promote consistency and coordination of
resources.
In order to provide effective user support, the System Manager should be
responsible for:
• Responding to and tracking user inquiries about system operation (via mail, E-
mail, phone)
• Dealing with system access procedures
• Addressing software and hardware problems
• Hosting user conferences
• Providing appropriate training.
In the case of national systems, the supporting OIRM organization should be cognizant of
the mechanics of the system since in many instances the System Manager may not be able
to accommodate the large number of inquiries from users. OIRM may be able to assist
with the overflow of inquiries.
The System Manager may also assist users by providing necessary system
manuals, publishing a newsletter or using a bulletin board to disseminate system
information and moderating user groups. The System Manager should also assist the user
in acquiring appropriate training in such areas as use of the reporting functions of the
system. This eliminates the need for users to contact the System Manager or OIRM
organization for assistance each time an ad-hoc report is needed. For many systems at
EPA, hot lines are available to provide additional support to the users.
2-5
-------
EPA Operations & Maintenance Manual
2.1.4 Superyisorv Control of the Production Process
Supervisory control of the production process refers to a system of administrative
checks which ensure proper utilization and operation of the system. Supervisory controls
are established to assist in monitoring the day-to-day operation of a system. They assure
valid, proper entry and maintenance of data, accurate performance of input/output
procedures, authorized user interaction and special processing requests. They are
constructed to ensure that maintenance transactions are handled properly, verification and
approval procedures are in place and, if necessary, monitor disaster recovery. These
controls help prevent the occurrence of a "garbage in, garbage out" problem. They act as
the checks and balances for smoothly operating systems.
Supervisory controls can either be built-in functions of the software itself or
documents designed for this use. Examples of these include job request forms, system
manuals, procedural checklists, audit trails and system performance/exception reports.
2.1.5 Archiving
Archiving refers to the creation of copies of data for historical reference purposes.
Unlike the philosophy that governs the backing up of files, where a copy of a master,
transaction, or table file is made to ensure a copy is available daily, if anything should
happen to the original, the philosophy of archiving is to ensure that copies are created for
long-term storage of data. Archiving procedures should be designed for systems of all
sizes.
The storage medium for the long-term storage of a specific application is an
important decision made during the system design phase. The most popular types of
storage media include magnetic tape or disk. The archival medium decision should be
reevaluated periodically in light of changing technology. The decision must also be made
whether to store the data on-site or off-site. The need to readily access the archived data,
the size of the storage capabilities on-site and the security needs will determine if a
dedicated storage location must be established off-site.
2-6
-------
EPA Operations & Maintenance Manual
2.2 COMPUTER CENTER SUPPORT
Since individual system operation is often impacted by computer center operations,
it is important to understand the activities and controls provided by the computer center. In
the context of this guidance, the concept of a "computer center" relates to the hardware and
software necessary to support a system application. Computer center support refers to the
activities performed by the technical support staff within the computer center environment
which help ensure each system will operate properly on a daily basis. This concept is
normally associated with the operations of a major computer center, such as the National
Computer Center (NCC) or the center located in Cincinnati, but is also valid when
discussing mini-computers, such as those operated by the EPA research and development
laboratories or local end-user computing workstations. The essential elements of computer
center support include:
• Computer Operations
• Production Control
• Backup and Recovery
• Disaster Planning and Recovery.
2.2.1 Computer Operations
Computer operations encompass those activities that are carried out to maintain a
viable system environment. The system environment is comprised of computer hardware,
system software and communication devices. Computer hardware consists of the computer
and an array of input and output devices including printers, plotters, scanners, tape drives,
terminals and disk drives. System software includes the operating system and other
required software, whether a traditional third-generation language (COBOL, FORTRAN,
PASCAL), a package (LOTUS, SAS) or database management system (ADABAS,
dBASE). Communication devices include the modems and communication lines that allow
access between computers for sharing data and processing capabilities.
The usefs responsibility for maintenance of the system environment is dependent
on the size of the system used. Personal Computer (PC) users are directly responsible for
maintaining a viable computer environment All PC-based system components generally
reside on or near the user's workstation and are under his/her direct control. The individual
2-7
-------
EPA Operations & Maintenance Manual
user is usually responsible for supporting the system environment which may include the
following tasks:
• Starting the system each day
• Loading appropriate software
• Initiating the required application software
• Storing floppy disks properly
• Maintaining all appropriate security measures
• Ordering and controlling supplies.
In a Local Area Network (LAN) environment, a LAN Administrator is assigned the
responsibility of operating and maintaining the LAN. The LAN Administrator's
responsibilities include overseeing or performing the following:
• Installing the LAN
• Training users
• Maintaining die hardware and software
• Performing system backups
• Managing network security.
Mainframe and most mini-computer operations are generally geographically
removed from the user and centralized within a computer center. These large-scale
computer environments require both a means for the user to communicate with the
computer resources and a staff dedicated to making these resources available to each user as
needed. Typical system environment support performed by the computer center staff
includes:
• Initialising the system each day
• Mounting tapes and di$fr$
• Re-allocating processing resources to correspond to job requirements
• Adjusting the proportion of shared computer resources allocated to each user
• Distributing reports
• Maintaining a computer tape library
• Ordering and controlling supplies
• Ensuring proper system software licensing.
2-8
-------
EPA Operations & Maintenance Mnoal
2.2.2 Production Control
Production control operations refer to the activities that support the implementation
and periodic processing of various systems. Typical production control activities include:
• Job scheduling
• Backup and recovery
• Disaster planning and recovery
• Job Control Language Maintenance
• Routine submission of batch jobs
• Maintenance of all appropriate security measures.
Responsibilities for the individual production control activities vary with the size of
the computer center. Individual users are directly responsible for die processing activities
associated with their PC-based applications. Mini and mainfrqmf. based applications, such
as payroll, accounting and national program systems are generally serviced by computer
center staff.
Two production control activities mat stand out in terms of their significance to the
protection of an application system are backup and recovery and disaster planning and
recovery. These are discussed in Sections 22.3 and 2.2.4 respectively.
2.2.3 Backup and Recovery
Backup procedures should be designed to protect against any possible loss of data.
Duplicate copies of data are made periodically to ensure that a copy of the generated work
will always exist even if the master copy of the data are damaged or destroyed. There is
always a chance data can be lost either by human error, hardware or software failure or by
catastrophic disaster (discussed in Section 2.2.4, Disaster Planning and Recovery). For
smaller PC-based systems residing on individual workstations, it is the individual's
responsibility for data backup. In most instances, simply creating a backup floppy disk for
data and storing the backup in a location removed from die workstation is sufficient
For larger systems (mini and mainframe), system developers should always assume
the worst-case scenario when designing any backup system. This backup system will
2-9
-------
EPA Operations & Maintenance Manual
consist of procedures which are established to maintain and store recent versions of the
information residing within a system.
A more detailed discussion of specific data backup and recovery methods for the
various types of systems can be found in the EPA Information Security Manual.
2.2.4 Disaster Planning and Recovery
Disaster planning and recovery refers to the plan or set of procedures that is
designed to counter any physical destruction or damage of the hardware resources or to the
building in which the computer center is located. The subject of disaster planning and
recovery is primarily concerned with mainframe or mini-computers. Individual PC-based
systems should consider standard data and system backup and recovery procedures
sufficient for disaster planning. Data that have been properly backed up onto another
floppy disk and stored in a location removed from the PC would be readily available for
use on another PC.
The computer center has the primary responsibility for developing any disaster
recovery plan to cover mini and mainframe systems. These plans should contain
procedures for dealing with various aspects of emergency response, immediate backup and
long-term backup. The procedures should be as specific as possible and all appropriate
responsibilities clearly defined. Exhibit 2-2 identifies die areas which should be addressed
in designing a disaster recovery plan.
As with the recovery plans which address data recovery, each computer center
should have a separate restoration plan which will assist in restoring die physical computer
center site. This plan should establish responsibilities for die following activities:
• Assessing the time required to restore die damaged facility or to locate, obtain
and set up a new processing facility
• Physically restoring die damaged site
• Reestablishing die original data processing environment by moving from the
backup facility to die restored site or a new processing facility.
2-10
-------
EXHIBIT 2-2
DISASTER RECOVERY PLAN
Conduct a risk analysis to identify specific potential
dangers to the computer center and computer-related
operations
Determine which systems/applications are mission
critical and must be restored immediately in the case
of failure
Develop a detailed, systematic plan, based on the above,
to guide disaster response activities:
Order and install any necessary additional hardware at the
backup facility to establish full processing capacity for
long-term backup
Assess the possible damage to the computer center
and salvage useable equipment and data
- Recover critical programs and data
- Restore communications networks
Resume critical application processing in the immediate
backup and die long-term backup phases of the recovery
process
Resume processing of noncritical applications
as additional resources become available.
2-11
-------
EPA Operations & Maintenance Manual
Once the risks are identified and the recovery procedures are detailed in the disaster
recovery plan, the plan must be tested and periodically reviewed to ensure that time and
events do not change the situation and that all procedures are still applicable.
A further discussion of disaster planning and recovery is located in the EPA
Information Security Manual. Appendix D, Contingency Planning.
2.3 USER INTERACTION
The third area of daily system operation involves user interaction which consists of
access techniques and operating procedures to be followed by a user of the system. The
specific topics addressed in this section are:
• System access techniques
• Data entry and update procedures
• Analysis/reporting options
• Training.
2.3.1 System Access Techniques
System access techniques are the means by which a user interacts with an
automated system. These techniques vary depending on the type of system, the type of
terminal and the input and output required. In order to ensure that users are able to utilize
systems with ease, system access techniques must be developed and clearly and simply
documented for users.
Step-by-step procedures for gaining access to a system must be developed and
made available to the user. If several communications or machine access methods are
available, the user must be given instruction in their use. For example, if a number of
different types of terminals, workstations or personal computers may access a system,
procedures for system access using each machine must be delineated since each machine
may have a unique function for each key. In particular, specific instructions for using
programmable function (PF) keys, the escape key, the enter key and the return key are
necessary to ensure that users of each machine type have a complete understanding of the
operation of the system.
2-12
-------
EPA Operations & Maintenance Manual
System access techniques may vary among systems due to differing levels of
sophistication of the intended system users. A system designed for infrequent or less
technically oriented users often relies on extensive use of menus. Where the user is more
technically oriented, a more detailed, and therefore more complicated, system interface
utilizing direct system commands allows the user more control over system operation.
The procedures for system access are defined during the system design phase of the
software life cycle and must be described in the Software User's Reference Guide (EEI-1 1)
for use during normal system operations. Security concerns relating to access techniques
for mainframe, mini-computer and personal computer systems are described in the EPA
Information Security Manual.
2.3.2 Data Entry and Update Procedures
Interaction with an automated system for data entry and update may vary depending
on the type and function of the system. Data input and update schedules, procedures and
security requirements are governed by the volatility and sensitivity of the data being
processed.
The timing of data input is tied directly to the nature of the system. For example,
payroll system updates are driven by the bi-weekly payroll processing cycle. In this case,
the timing of the update is critical. On the other hand, maintenance of archival and
reference information may not be tied to a specific processing cycle. This allows the
designated System Manager to establish an appropriate archival schedule.
Systems can have several levels of data entry or update approval. Some users may
have authority only to enter or look at data; other users may be able to update and delete
data. The System Manager controls procedures for each type of access in order to maintain
data integrity, availability and confidentiality. These procedures are described in Section
2.1.1, Control of System Access.
2.3.3 Anflfypfr I Repotting Options
A system's analytical and report products are developed during the system design
phase to support the user in performing his/her job and to meet organizational record
keeping requirements. The Software User's Reference Guide should describe these
2-13
-------
EPA Operations & Maintenance Manual
capabilities in such a way that the user can easily see the utility in the provided capabilities
as well as the direct correlation between the system's tools and the user's task
requirements. Failure to make this link readily apparent will result in the underutilization or
non-utilization of the system. The timing, options, media and delivery process for the
system outputs are important issues which should be addressed in the Guide and fine-tuned
periodically to ensure that they meet the needs of users.
The timing of system outputs is relevant to the nature of the output formats. For
example, outputs of systems which are event-driven usually generate periodic reports.
Systems supporting less time-critical functions may have a more flexible reporting
schedule.
Systems often provide a number of options for obtaining information upon request.
These ad hoc requests may allow the user to specify fixed or variable report formats and the
characteristics of selected data. The more flexibility a system has in this regard, the more
utility the system generally has for the informed user. The flexibility allows the user to
create a focused analysis rather than having to glean desired information from a voluminous
report
The utility of a system is enhanced by having system output available on a variety
of media, including paper, magnetic tape or floppy disk. Flexibility in providing output
enables a system to support multiple organizations, management levels or equipment types.
The additional availability of machine-readable output will enable users to incorporate
information electronically into affiliated systems for further detailed analysis or
aggregation.
The delivery process by which users receive outputs is important for all but single-
user PC applications. The opportunity to specify the output location, such as a local or
remote printer or terminal screen, is a useful system function. Many systems have a wide
range of options of this type, including transmission of system output either within EPA
Headquarters or nationwide, which is helpful for transmitting administrative data between
Headquarters program offices or between Headquarters program offices and field
locations. Procedures for performing this type of operation should be documented in the
Software User's Reference Guide (EEI-11).
2-14
-------
EPA Operations & Maintenance Manual
2.3.4 Training
Training is a critical element for the effective operation of any application. A variety
of training options are available, from traditional classroom instruction to multimedia
courses and computer-based training. The System Manager must determine which
methods are most applicable to meet different user requirements. Users with varying
degrees of skill and experience as well as the frequency of staff turnover may determine the
extent to which the organization can provide effective initial and follow-up training. This
acknowledgement of varying skill levels will allow the training program to more accurately
meet user needs.
To develop an effective training program, the person or group responsible for user
training will need to establish guidelines and determine who needs to be trained, what
applications or systems will be taught and what training methods will be used. The
following procedures will help maximize the benefits of any user training program:
• Survey managers and supervisors to identify the organization's goals,
objectives, programs and projects. This uncovers potential needs and provides a
strong direction for and commitment to the training.
• Identify and analyze the primary user group. This information will strongly
influence training content
• Survey the potential participants to determine existing skills.
• Conduct a task analysis. This crucial step will ensure the trainee's newly
acquired skill matches his/her job requirement
• Define training results. By documenting the results of training in terms of
trainee performance, a baseline is established which will influence all future
training decisions.
There are a variety of training options available. These include classroom or student-paced
training; Agency or vendor-developed programs; workshops; or individualized training
using multimedia courses and computer-based approaches. The best training method
depends on users' needs and available resources.
2-15
-------
EPA Operations & Maintenance Manual
Users are primarily concerned with what they will need to know in order to perform
their jobs. They are often unwilling to invest long study hours, preferring to focus on
training that directly relates to their day-to-day experience. Any training program should
address this perspective in order to provide effective user training.
One efficient way to design a user training program is to categorize users by
organizational or skill level. The four organizational levels of users are executive,
managerial, technical and administrative. Each level of user requires a different focus and
approach to training. Executives and managers usually have little time available for
training. Courses for these users should emphasize payback and results from a
management perspective. Technical users typically adapt to new technology readily and
welcome the introduction of new tools and methods. This category of user is usually more
receptive to experimentation and is willing to explore new techniques during a training
program. Administrative users are interested primarily in developing skills for their
specific work applications. This may involve training on specific applications, such as
word processing, presentation graphics, spreadsheets and the applicable computer
equipment Another important aspect of training is the need for staff retraining precipitated
by extensive changes made to the system software during a maintenance cycle.
Follow-up after training is essential. Success is measured by whether users
continue to employ and expand the concepts and skills acquired during the training
sessions. An analysis should be made to determine which users are benefiting most from
the training, which are not benefiting and most importantly, why not This information can
then be factored into restructuring the future training curriculum.
2.4 APPLICATION SOFTWARE OPERATION
The operation of the application software is the responsibility of the System
Operator or operations personnel, either within the computer center or in a program office.
These personnel are responsible for systems operation activities, including operating the
hardware and maintaining the stability of die application software for the user community.
2-16
-------
EPA Operation & Mvnfcnaocc Manuri
The following specific activities of application software operation are described in
this section:
• System inirialiyatinn/re-initialirarinn
• Error detection and recovery
• System interfacing.
The activities likely to be associated with system operations should be fully described in the
Software Operations Document (EEI-10).
2.4.1 System Tnitializa.ti.fln/Re,-initi8]i73tint1
During system implementation, internal files and tables are initialized with a
baseline of data and operational parameters. (Definition of parameters and description of
table specifications are contained in Section 2.1.2 of this document) In some cases, this
initial implementation is sufficient to establish and support operations for the life of the
system. In other cases, it may be necessary to re-initialize the system files and tables at the
stan of a new operating interval (e.g., day, pay period, month, quarter, fiscal year). A
step-by-step process for initialization, including a list of the required input parameters and a
description of the update procedures, must be developed and documented in the Software
Operations Document (EEI-10).
The System Manager will have the responsibility for defining and specifying
system parameters and re-initialization requirements to the System Operator. Procedures
and standard practices for initialization/re-initialization should be documented in detail in the
System Manager's guide. The System Manager's guide is that portion of the Software
Operations Document (EEI-10) which delineates the System Manager's function. It is
often developed as a separate document for ease of use and to minimize confusion of
responsibilities.
2.4.2 HjTftr Detection and Recovery
Among the responsibilities of the software operations personnel are error detection
and recovery procedures. A variety of system failures can result in system malfunction.
Such failures occur as a result of data errors, program errors or equipment malfunctions.
The System Operator can determine the type and seriousness of errors, if any, that have
2-17
-------
EPA Operations & Maintenance Manual
occurred as a result of a system failure by reference to system error messages and other
diagnostics.
Each part of the system which can fail should have specific, documented error
messages designed to explain the error and its proper resolution. For example:
• Program or data errors — program error messages are displayed on the
operator's terminal screen or user's screen; these are developed as part of the
detailed system design phase of the software life cycle and are documented in
the Software Operations Document (EEI-10).
• Equipment errors/failures — hardware malfunctions produce error messages
either displayed by the hardware itself or by the mainframe operating system, if
applicable. These are described in the operating guide supplied with the
hardware at time of purchase and are often reiterated in the Software Operations
Document (EEI-10) for reference purposes.
Effective system restart procedures in response to application software or hardware failures
should be documented in the Software Operations Document (EEI-10).
To the extent that data are lost or damaged as the result of a software and/or
hardware failure, the provisions outlined in Section 2.2.3, Backup and Recovery, should
be utilized.
2.4.3 System Interfacing
System interfacing procedures become more critical in system operations as
increasing numbers of systems interface for data exchange and storage purposes.
Procedures for performing or maintaining system interfaces should be documented in the
Software Operations Document (EEI-10) and the System Manager's Guide. Where system
interfaces impact on or provide additional capability to system users, these should be
described in the Software User's Reference Guide (EEI-11).
2-18
-------
EPA Operations & Maintenance Manoal
2.5 DOCUMENTATION
The specifics of die system operation activities described above must be thoroughly
documented in the Software Operations Document (EEI-10) and the Software User's
Reference Guide (EEI-11). These documents are extremely important references for
system users and operators, regardless of whether the system runs on a mainframe, mini-
computer, or microcomputer. The formats of these documents may vary between systems
and organizations, due to the size and complexity of the system, but information
requirements are, on the whole, fairly similar for most systems. The major topics that need
to be considered during the preparation of operating manuals of any system are presented
as essential elements of information (EEIs) in Appendix A. These documents are prepared
during System Design, Development and Implementation and updated during System
Operations and Maintenance, as needed. Suggested outlines of these EEIs are presented in
Appendix A for reference during the System Operations and Maintenance phase.
Managers may use their professional judgement in substituting, combining or
reducing the content of the EEIs to meet the unique requirements of a particular system.
Additionally, the EEIs are not meant to conflict with or add more burden to documentation
requirements set out in other manuals, such as the EPA/NCC ADABAS Application
Development Procedures Manual. Documentation produced according to such other
detailed procedures will invariably satisfy, either partially or fully, most EEI requirements.
2.5.1 Software Operations Document
EEI-10 presents the basic elements considered for inclusion in a Software
Operations Document This document should provide the System Operator or operations
staff with the detailed procedures required to maintain a stable and viable system.
2.5.2 Software User's Reference Guide
EEI-11 presents the basic elements considered for inclusion in a Software User's
Reference Guide. This guide is intended to provide users with die information necessary to
effectively utilize die system.
2-19
-------
EPA Operations & Maintenance Manual
2.6 OPERATIONAL BASELINE
The Operational Baseline represents the completely implemented and tested
software system including system manuals and database file designs. It is the basis for
future maintenance changes and enhancements and is established following a successful
Operational Test and Evaluation Review and after it has been placed in production and/or
turned over to the user.
2.7 SUMMARY
Chapter 2 presents four major functional operations that are necessary for the
effective and efficient day-to-day management and control of a system. First, the
administrative control procedures which are performed by a System Manager or a Database
Administrator include authorizing users to access the system, specifying system variables
through parameters and tables, supporting users by responding to inquiries and supervising
the production process. Second, additional operational responsibilities which support the
system are performed by technical personnel at the appropriate computer center. These
functions should be understood and supplemented for each system, as needed. Third, the
system must be responsive to user needs through proper user interaction allowing sufficient
system access means, ensuring accurate data through controlled data entry and update
procedures, providing useful analysis and reporting products and structuring effective
training for users. Finally, the software must be operated properly, ensuring initialization
of the system, error detection and recovery and proper interfacing with other systems.
Procedures for operating the software and reference information for users are contained in
system documents developed during system design, development and implementation.
Representative outlines of these documents are presented in the appendix.
The next chapter discusses configuration management which is the first step in
ensuring proper maintenance of a system. Configuration management ensures that changes
to the system are controlled through established procedures for evaluating system
maintenance and enhancements.
2-20
-------
Chapter Three
CONFIGURATION MANAGEMENT
Configuration management involves system maintenance or enhancement
performed following initial system implementation. Configuration management includes
the evaluation methodology and approach to be followed when considering a partial system
redesign or determining software obsolescence. Generally speaking, configuration
management must apply die same evaluation criteria to the system maintenance function as
were applied to the original system design (See the EPA System Design and Development
e,- Volume A).
This chapter contains configuration management definitions and responsibilities and
describes the activities which comprise the configuration management process. It includes
information on the management structure, decisions and tools to support the evaluation and
the determination and implementation of changes to an operational software application.
The first section defines types of system maintenance and their respective responsibilities.
The second section addresses the procedures necessary for proper configuration
management
3.1 DEFINITIONS AND RESPONSIBILITIES
This section includes configuration management definitions, as well as the
responsibilities of those individuals who implement system maintenance.
3.1.1 System Maintenance
System maintenance can be divided into three categories of software changes:
corrective, functional and adaptive maintenance. Corrective and functional maintenance
result primarily from the experience of users with the system and relate to the functionality
and ease of use of the system. Adaptive maintenance is a result of changes outside the
system over which the System Manager has no control. The categories are useful in that
they indicate the reason for maintenance, which can have direct bearing on the timing,
necessity or urgency of changes.
3-1
-------
EPA Operatic & Maintenance Manual
3.1.1.1 Corrective
Corrective maintenance is performed to correct abnormal and/or debilitating system
performance that was not detected during system testing. This can happen because the
system testing process is generally designed to verify system performance under "normal"
operating conditions. Once a system has been put into production, it undergoes the stress
of both expected and unexpected user interaction and activity which can precipitate
previously undetected system problems.
The users may be able to adapt to inconveniences, such as report labeling
inaccuracies, peculiarities of report sequencing or unsatisfactory data display formats.
Other problems, such as incorrect calculations and acceptance of invalid data inputs, are of
a more critical nature as they affect the accuracy of the information processed and result in
incorrect system operation. The user community or managers may be the first to notice
inaccurate data or functions, and they should be encouraged to submit problem reports.
These types of problems tend to receive intensive attention, resulting in
management pressure for rapid implementation of changes. Nevertheless, corrective
maintenance tactics need to be evaluated, planned and controlled to ensure that the
ramifications of changes are known and accepted, the changes perform as required and
users are informed of the changed implementation schedule.
3.1.1.2 Functional
Functional maintenance addresses proposed system changes that will provide users
with enhanced system performance and capabilities that were not specified in the system
design phase of the software life cycle. Enhancements may be proposed through
submission of change requests by any of the following:
• Active users who want changes to increase efficiency or to expand the scope of
system function
• EPA managers who recognize a change in the mission needs of the Agency or a
sub-organization
3-2
-------
EPA Operations & Maintenance Manual
• System designers and managers who recognize operating inefficiencies based
on actual svstem utilization
on actual system utilization.
Unlike changes that are forced by corrective and adaptive conditions, proposed
functional maintenance is discretionary and should undergo thorough benefit-cost analysis
prior to implementation. This will ensure that the most cost-effective course of action is
undertaken. Due to the discretionary nature of functional changes, the speed of
implementation is subordinate to the cost and functionality factors involved.
3.1.1.3 Ariapn'vq Maintenance
Adaptive maintenance refers to system modifications imposed upon the system by
external forces. For example, the computer center may install an upgraded computer or
operating system, or an affiliated system may be re-written with accompanying changes in
system interfaces. These modifications could easily apply to personal computers as well,
such as an upgraded PC operating system or a new version of commercial software that
requires modification of in-house systems or data input procedures. In these cases, there is
no prerogative to accept or reject the required changes. Instead, the pending operating
environment should be examined to determine if there are opportunities for upgrading the
functionality and efficiency of the system at the time the system is being adapted. The
implementation schedule for adaptive maintenance is often defined by the system or
installation that is initiating the change in processing environment
3.1.2 Configuration Management Responsibilities
For smaller or less active systems a person should be designated to establish and
execute system change control procedures. This person is referred to as the Change
Control Administrator and is generally recognized to be the System Manager. For large
integrated systems, the implementation of system changes may be the responsibility of the
Change Control Administrator while change evaluation and final decision-making authority
is embodied in a Change Control Board composed of representatives from the system's
functional areas or oversight organizations. The responsibilities of configuration
management are typically shared by the Change Control Administrator and Change Control
Board as shown in Exhibit 3-1. This division of responsibilities is not absolute and can
vary depending on system size, organizations involved and management preference.
3-3
-------
EXHIBIT 3-1
CONFIGURATION MANAGEMENT RESPONSIBILITIES
CHANGE CONTROL BOARD RESPONSIBILITIES
• Periodically evaluating the adequacy of the system in meeting
its support role with regard to evolving user/Agency needs
• Establishing procedures for documenting, evaluating, and
controlling proposed system changes
• Organizing change request reports according to the three
maintenance categories described in Section 3.1.1
• Performing benefit-cost analyses for proposed modifications
• Approving and ranking all proposed system modifications
• Determining whether identified problems and approved
enhancement requests justify a new version of the system
or indicate software obsolescence
• Enforcing documentation and coding standards through
reviews and audits of modifications
• Evaluating the results of system maintenance and determining
when a return to a prior software version is indicated
• Notifying system users of any system changes.
CHANGE CONTROL ADMINISTRATOR RESPONSIBILITIES
• Assuring compliance by the System Manager and technical
support personnel with established maintenance
documentation described in Section 3.1.1
• Obtaining technical assistance as needed to determine the
level of effort, interdependencies and ramifications of the
proposed system changes
• Assembling the proposed system changes into a software
improvement increment
• Overseeing the performance of software quality assurance.
3-4
-------
EPA Operations & Maintenance Manual
3.1.2.1 Review of System Functionality
Periodically, the Change Control Administrator in consultation with the System
Manager and program management should review system functionality to ensure that the
system is meeting current user/Agency needs. EPA policy and procedures may change
over time to reflect a change in overall Agency mission, shift in programmatic emphasis or
modification of job tasks. Because of this, the alignment of the system with the goals and
job tasks it was designed to support may deteriorate. The Change Control Administrator
must determine when the system is not providing adequate support or is obsolete and
initiate a study to define options which include:
• No change to the system
• Partial system redesign (new version of the system)
• Complete system redesign (new system)
• System termination.
The study could include:
• Evaluation of the continuing need for the functions provided by the system
• Assessment of successful execution of system functions
• Analysis of workload and utilization of the system for comparison to estimates
made at the time the system was designed.
Depending on the size of the system and the user community, this type of study could be
accomplished through an individual's observation, a user survey or interviews with
managers.
3.1.2.2 Coding StanHatds Enforcement and System Testing
The Change Control Administrator has oversight responsibility for ensuring that the
coding standards and system testing procedures established during the initial system design
phase are observed by the System Manager, Database Administrator and technical support
staff during subsequent maintenance cycles. The coding standards and testing procedures
were established to promote software quality and maintainability and overall system
3-5
-------
EPA Operations & Maintenance Manual
integrity. The applicability of these standards and procedures to the software maintenance
process is addressed in Chapter 4. Circumventing die established procedures could lead to
degradation of the system due to undetected errors, undocumented coding changes or
inconsistent operating or processing procedures.
3.2 CONFIGURATION MANAGEMENT TqnnffiS
This section addresses the following activities which comprise configuration
management:
• System change requests and problem reports
• Analysis of problem reports and change requests
• Benefit-cost analysis
• Change approval and action plan development
• Software improvement increment
• Maintenance cycles
• Return to prior software version
• Documentation.
The Change Control Administrator (or Change Control Board) has the
responsibility to evaluate, plan and control the required system changes through this
process to ensure that they perform as required and to assess the ramifications of such
changes. The user community must also be notified of the implementation schedule, any
procedural changes and actual implementation. Throughout the system maintenance
process, the System Manager must be aware of the impact that proposed software changes
may have on the entire system and their eventual effects on the user community.
Provisions should be made in the configuration management process to
accommodate the rapid system changes required to respond to detected errors. These
provisions may include lessening the degree and formality of the benefit-cost analysis or
reducing die change request review and approval requirements, if appropriate. However,
error corrections should still be verified, tested and documented. Abbreviated procedures
should not be used to circumvent the normal functioning of the formal change process,
though they may be used to speed it up.
3-6
-------
EPA Operations & Maintenance Manual
3.2.1 System Change Requests/Problem Reports
Requests for changes to the software may originate from any of the users of the
system. A formal procedure should be established to process and document requests for
system changes and reports of system problems. The procedure should include
submission and tracking of problem reports and change requests to ensure that all
reports/requests are addressed in a standard manner, and that none are overlooked by
mistake. Problem reports and change requests should consist of at least the following
information:
• For problem or change, a functional description of the problem or the requested
change
• For a problem, a description of the conditions under which it occurs
• For a change request, the benefit(s) to the user/organization/Agency of the
change.
Problem reports and change requests should be logged by the Change Control
Administrator upon receipt for tracking purposes and categorized as corrective or functional
maintenance. (Although adaptive maintenance is usually not initiated through a problem
report or a change request, it is important to manage and track the adaptive maintenance
process in the same manner that system problems and changes are handled.) One purpose
of tracking problem reports and change requests is to ensure that the defined action plans
are followed and scheduled maintenance is correctly performed as planned and on time.
The actual content and format of the problem report/change request form should be
determined by management in order to correspond to standard local procedures. An
example of a suggested format for problem reports/change requests is shown in Exhibit 3-
2.
3.2.2 Analysis of Problem Reports and Change Requests
Problem reports and change requests must be analyzed to determine the action to be
taken in response. Problem reports must be analyzed to determine the severity of the
problem and to prioritize problems if several are awaiting correction. Problem reports
3-7
-------
EXHIBIT 3-2
SOFTWARE CHANGE REQUEST/PROBLEM
REPORT
ORIGINATOR
ORGANIZATION
PHONE
MAIL CODE
LOG
NUMBER
DATE
TIME
CATEGORY
DESCRIPTION OF THE PROBLEM, CONDITIONS UNDER WHICH IT
OCCURED, AND ITS IMPACT ON THE USER, ORGANIZATION,
OR AGENCY
STATUS DATE
REVIEW — •
ANALYSIS — -
BENEFIT/COST — •
APPROVAL — -
IMPROVEMENT
INCREMENT — -
MAINTENANCE
CYCLE
TESTING — -
IMPLEMENTATION — -
REVIEWER'S NOTES
3-8
-------
EPA Operations & Maintenance Manual
usually indicate system corrections which must be made as soon as possible in order to
ensure proper system operation. System change requests do not always require immediate
resolution. Instead, they must be subjected to additional discussion and analysis, including
benefit-cost analysis, before specific action is taken.
When a change request is received, the Change Control Administrator consults with
the System Manager, Database Administrator and technical support staff, as appropriate, to
refine the definition, necessity and consequences of each proposed functional change. The
outcome of these discussions may be several software options for achieving the desired
performance goals. Each option is then assessed to determine:
• The expected level-of-effort required to implement the change
• The relationships between die programs, modules and interfaces affected by the
change
• The impact on the user community.
For both functional and corrective maintenance, system changes must be fully
evaluated. The impact of the changes must be viewed in terms of the total cost of a
proposed change and any adverse effects on overall system quality. As noted above, the
decision to perform adaptive maintenance does not usually reside with a local system
administrator or manager, so this evaluation is not necessary in such cases. However,
adaptive maintenance may require evaluation of various options for performing the
maintenance.
3.2.3 Benefit-Ore* Analysis
Proposed system modifications an subject to the life cycle benefit-cost analysis
techniques described in the EPA System Design and Development Guidance. Volume B.
Functional maintenance changes in particular must be thoroughly analyzed because they are
optional in die sense that failure to implement them will not adversely affect system
performance, as with corrective and adaptive maintenance changes. Attention should be
paid to assessing the benefits of functional changes since these benefits may be either small
or large in relation to the cost of implementation. Because corrective and adaptive
maintenance is not optional, benefit-cost analysis is most appropriately used to determine
3-9
-------
EPA Operations & Maintenance Manual
the best option for applying required changes. The depth and formality of the benefit-cost
analysis should be determined by the size of the system and the complexity of the proposed
modifications.
3.2.4 Change Approval and Action Plan Development
Changes in all maintenance categories must be approved by the Change Control
Administrator in consultation with the System Manager and program management where
appropriate. Even though changes in the corrective and adaptive maintenance categories are
usually not elective, the Change Control Administrator should determine the approach and
timing of changes.
Some requested changes will be rejected because they are trivial or not worth the
cost and system disruption caused by their implementation. Other changes which are more
fundamental may be rejected on the principle that it would be more cost effective and
functional to totally re-design the system than to adapt the desired functions to the current
software.
The Change Control Administrator is responsible for evaluating the proposed
software changes with regard to the following:
• The total cost of the proposed modifications
• The maintenance burden of the current and proposed systems
• The functional requirements of the organization/Agency
• The overall effectiveness of the system
• The efficiency and productivity gained from a re-designed system
• The effects on system security.
The result of this analysis is a determination to complete the proposed functional
aintenance, to develop a new version of die software or to declare software obsolescence.
Once the approval decision has been made, the Change Control Administrator or
Change Control Board must develop an action plan for effecting the change. The action
plan is based on the information developed in the decision-making process and includes a
schedule for implementation, design documents and staff assignments. Throughout the
maintenance process, the action plan should be monitored for timeliness and accuracy.
3-10
-------
EPA Operations & Maintenance Manual
If it is determined that a new version of the system is warranted, a software
improvement increment and an accompanying maintenance schedule is defined.
Declaration of system obsolescence will begin a new software life cycle for the total system
redesign. Procedures for initiating this system redesign are similar to those utilized during
the system design phase and can be found in the EPA System Design and Development
Guidance. Volume C
Although adaptive maintenance is not initiated through use of either a problem
report or a change request, the procedures for analyzing such maintenance are quite similar.
An action plan must be developed, scheduled and implemented, and maintenance progress
must be monitored for corrective and functional maintenance.
3.2.5 Software Improvement Increment
The software improvement increment groups a finite number of enhancements and
modifications to be incorporated into the system software. This refers to a group of
proposed system changes that has successfully passed through the formal change request
review and approval process. Definition of the scope of the software improvement
increment is based on the projected level of effort, expected utility gains, budgetary
constraints and organizational pressures to improve the system. The documented and
communicated release of a new version of the system concludes the software improvement
increment.
3.2.6 Maintenance Cycles
One goal of configuration management is to provide a stable system for the user
community. Systems that are in a continual state of flux, due to a constant flow of
changes, will precipitate user frustration, anger and ultimately, rejection of the system. In
order to confine system changes to orderly schedules, a formal maintenance cycle should
be established. The maintenance cycle does not necessarily refer to routinely scheduled
maintenance but rather controlled maintenance. For example, a cycle could be established
in which maintenance is performed only after a threshold of demand for system
modification, such as a specific number of problems or requests for one change or a
specific number of changes, has been reached. Another alternative is to establish a
maintenance cycle in which changes are made to only one module or program of a system
3-11
-------
EPA OparatkasA Maintenance Manual
at a time. In any case, pending system changes should be grouped together and
accomplished at one time as part of a software improvement increment The intention is to
provide users with periods of stable operation and known performance characteristics.
This also allows the Change Control Administrator time to inform the users of pending
changes and instruct them in new operating procedures and/or functional capabilities.
3.2.7 Return to a Prior Software Version
Problems with newly implemented versions of the system occur occasionally. In
most cases, additional problem reports are submitted which begin the software maintenance
process again. However, in rare cases, a change that has been implemented has an
extremely adverse operational effect on the users and the system output In such a case, the
new version may need to be removed and replaced with the prior version of the system.
This return procedure should be performed as soon as possible after a problem has been
identified. The Change Control Administrator should make the final decision concerning
the need for and timing of the procedure.
3.2.8
The analysis and decision-making process that precedes system software
modification must be supported by adequate documentation which includes the following
items:
• Software Change Request/Problem Report
• Notification of adaptive maintenance, if applicable
• History of analysis and relevant decisions
• Level-of-effoct estimates
• Action plan and maintenance schedule
• Evaluation of maintenance effects on system security
• Approval signature
• Statement of Strategy for Software Improvement Increment, which may include
the following items:
- A summary of the analysis undertaken to determine that a new version
of die system is warranted
3-12
-------
EPA Operations & Maintenance Manual
- An evaluation and benefit-cost analysis of alternative implementations
- An overview of the required hardware, software and file changes for the
increment
This documentation should be maintained by the Change Control Administrator and made
available to the System Manager, Database Administrator and computer center manager or
staff.
Documentation of system maintenance is an important pan of the configuration
management process since it ensures that correct information on use and operation of the
system is available to system users and operators at all times. The documents which are
prepared during system maintenance are the tools for ensuring an orderly software
maintenance process. This maintenance documentation, as described above, also becomes
pan of the total accumulation of system documentation since details of changes must be
appended to (and in some cases, must replace) the existing documentation to form a
complete documentation package for the system. In addition, this documentation is an
important means for justifying maintenance costs to internal and external auditors.
3.3 SUMMARY
Chapter 3 presents die important elements of configuration management and defines
the three types of system maintenance: corrective, functional and adaptive. The main
responsibilities of a Change Control Adnrinistrator/Change Control Board are reviewing the
system functionality, ensuring coding standards are enforced and system testing procedures
are followed and performing configuration management procedures. These procedures
involve systematic evaluation of change requests and problem reports, approval of
changes, definition of the software changes to be made, establishment of maintenance
cycles and documentation of the decision process.
The next chapter presents the important considerations in implementing the changes
that have been evaluated, approved and scheduled through configuration management
procedures.
3-13
-------
Chapter Four
SOFTWARE MAINTENANCE
Software maintenance refers to the actual modification of software and related
system manuals. This occurs during the final phases of the system life cycle and is often
precipitated by:
• Identification of program "bugs"
• Demand for additional capabilities/features
• Changing functional requirements
• Increase/decrease in scope of a system.
System modifications are often especially difficult to implement because of the constraints
imposed by the operational characteristics of the existing system and the need for continuity
of system operations.
Orderly modification of a system is necessary to maintain a stable operational
environment for its users. When changes are made to a system, they must undergo testing
and acceptance in a non-production environment to determine whether they do in fact
perform as desired. Once thorough testing is completed, a pre-production quality
assurance step is required to ensure that the results of the changes do not adversely affect
other parts of the system and that the changes correctly address the original problem. Strict
adherence to the procedures described in Section 4.1 will ensure that modifications are
implemented in a correct, predictable and orderly manner with minimal adverse effects on
the users of the system.
This chapter will discuss the following topics:
• Maintenance Procedures — discusses the relationship of the various procedures
and standards established during initial system development and their use
during system enhancement
• Maintenance Tools — describes the special automated tools available to systems
analysts and programmers that can assist in working with source code.
4-1
-------
EPA Operations & Maintenance Manual
Documentation — highlights the different system documents that either must be
changed with a system modification or at least must be reviewed for accuracy.
4.1 MAINTENANCE PRQTmT TRFS
This section discusses the maintenance procedures and tools established at the time
of system development and installation which also facilitate implementation of any new
software modifications or enhancements. Management of the maintenance process will be
carried out by the Change Control Administrator/Board and will be concerned with the
following areas:
• Documentation update
• Source code standards
• Coding and review process
• Testing standards and procedures.
4.1.1 Documentgfin^ Update
Maintenance should focus on modification of the entire application, including
system manuals and not on the source code modification alone. System documentation
problems arise when changes to source code are not reflected in the design documents or
user-oriented manuals.
Whenever a change to data flow, software structure, module procedure or any other
related characteristic is made, supporting technical manuals including the security manual
must be updated. System documentation that does not accurately reflect the current state of
the software is probably worse than no documentation at all. Major problems occur when
innocent use of unchanged system manuals lead to incorrect assessments of software
characteristics.
The side effects from documentation shortfalls can be reduced substantially if all
applicable system manuals are reviewed prior to any further release of the software. In
some instances, maintenance requests may require no change in software design or source
code but indicate a lack of clarity in user-oriented manuals. In such cases, the maintenance
effort should focus on redefining and clarifying existing system manuals.
4-2
-------
EPA Operations & Maintenance Manual
4.1.2 Source Cofl^ Sftijriymfo
The same set of coding standards used during the initial design and development of
the system application should be applied to maintenance activities. As discussed in the
EPA System Design and Development Guidance. Volume C, EPA has a general set of
minimum program design and coding standards which should be used either when
designing a new system application or modifying an existing one. These standards
promote productivity and maintainability as well as software sharing and reuse. The
important characteristics of the standards are:
• Use of structured programming constructs to control die flow of execution
• Elimination or significant reduction in the use of "branching" statements
• Modularity in source program design and coding
• Good coding practices such as:
- Naming conventions
- Symbolic parameters
Paragraphing
- Blocking
- Indentation of source code
- Single statement per line
- Intelligent use of comments
- Annotation of author and date of any program modifications
- Error messages.
Source code standards should be reviewed prior to beginning programming of any
modifications.
4.1.3 Coding and Review Process
Before the actual coding can begin, a detailed design of what the modified
application will look like must be completed. If a major system overhaul is being
undertaken, men the detailed design should be formulated using the procedures outlined in
Volume C of the EPA System Design and Development Guidance. If the planned changes
are smaller in scope, such as adding a new function or correcting a "bug" in the system,
then the changes can occur without a large amount of analysis and design documentation.
Managers should be aware that ANY change might have a rippling effect through the entire
4-3
-------
EPA Operations & Maintenance Manual
application. It is particularly important to review the effects these changes may have on
system security.
Once the detailed design of the modification is completed, then the production and
programming functions can be accomplished. At die completion of this task, all of the
changes in coding, controls, databases, user procedures and operations procedures will
have been developed. Some of the major activities in developing a software modification
include:
• Code new software units
• Review software unit codes
• Unit test new software
• Produce unit test reports
• Perform subsystem integration testing
• Prepare subsystem test reports.
Preliminary reviews are accomplished as each piece of new software is added to the
original application. These reviews will confirm that the new software product performs
according to all requirements and specifications.
4.1.4 Testing Standards Slid Procedures
The use of testing standards and procedures during the maintenance phase of the
system life cycle should be consistent with the standards and procedures set forth during
the initial system development A test plan should be developed for each system and used
as a guide to ensure that any modification made to the application is tested thoroughly and
the results properly documented
An example of a detailed outline of a Software Test and Acceptance Plan (EEI-7),
reproduced from EPA's System Design and Development Guidance is included in
Appendix A. The testing team must be aware of any "rippling effects" which newly
developed software will have on related applications. Testing should not be limited only to
the new piece of software; ALL software even remotely related to the modified software
should be identified and included in the testing.
4-4
-------
EPA Operations & Maintenance Manual
4.2 MAINTENANCE TOOLS
If the system was originally designed using special automated tools, such as
Computer- Aided Software Engineering (CASE), then it is recommended that these tools be
used by the systems analysts and programmers for identifying critical elements of code,
making source code changes and identifying and correcting problems. The EPA has
approved a number of standard specialized software tools to be used during a system's
development and maintenance effort Further information on approved tools can be
obtained by contacting OIRM or the National Data Processing Division (NDPD).
4.3 DOCUMENTATION
This section discusses the system manuals and documents prepared during initial
system development Several documents should be reviewed periodically or when
software is modified in order to determine if they need to be changed and updated during
the maintenance phase of the system life cycle. At the very minimum, the following should
be reviewed for accuracy:
• Software Maintenance Manual
• Data Dictionary
• Source Code.
Other examples of system documents which may require update, such as a Software
Operations Document (EEI-10) and a User's Reference Guide (EEM 1), were discussed in
Section 2.5 of this manual.
4.3.1 Software
The object of the Software Maintenance Document (EEI-9) is to provide program
maintenance staff with both general and specific information on the system configuration
and application software. This manual should present guidelines and procedures for
performing maintenance. Some areas which should be addressed include:
• Source code standards
• System manual update
• Change control process
4-5
-------
EPA Operations & Maintenance Manual
• Testing standards and procedures
• Maintenance tools
• Security.
A detailed outline of a Software Maintenance Document (EEI-9) is presented in Appendix
A.
4.3.2 Data Dictionary
A data dictionary is a collection of information about the data used in a system.
Although in some cases a data dictionary must be developed manually, the term itself
usually refers to a dictionary maintained by special data dictionary software. It is very
important during the maintenance phase of a system life cycle that the data dictionary be
updated if changes are made to the structure or definition of data in the system. If updated
properly, the data dictionary will provide a consistent official description of data as well as
maintain consistent data names required for programming and retrieval. The dictionary
should contain such information as the following:
• Name
• Description
• Source
• Users of the data, including screens, reports, programs and organizations that
access and use the data
• Key words used for categorizing and searching for data item descriptions
• Format
• Quality
• Precision
• Defaults
• Edit criteria
• Security requirements.
Data dictionaries may be used by the Database Administrator to enforce standards for
names and descriptions, ensuring that those who create data follow the standards.
4-6
-------
EPA Operations & Maintenance Manual
4.3.3 Source Code
The final element of system documentation which should be revised at the
conclusion of any maintenance effort should be the complete listing of the application
system source code. For large systems, storing voluminous source code listings could
prove to be unwieldy. In this case, the System Maintenance Document (EEI-9) should
provide instructions for obtaining source code printouts on an as needed basis.
4.4 SUMMARY
This chapter defines the software modification process and the associated change
analysis and system manual documentation. The software maintenance procedures are
concerned with the important activities of updating system manuals during system
maintenance and ensuring that standards for source code development and systematic
procedures for developing, reviewing and testing source code are followed. Important
system documents required to ensure proper maintenance of a system includes the Software
Test and Acceptance Plan (EEI-7), Software Maintenance Document (EEI-9), Software
Operations Document (EEI-10) and Usefs Reference Guide (EEI-11).
4-7
-------
EPA Operations & Maintenance Manual
APPENDIX A
ESSENTIAL ELEMENTS OF INFORMATION
A. ESSENTIAI. FT .FMRMTS OF INFORMATION
The EEIs associated with the design, development, operations, and maintenance of
a computer system are listed below and are outlined within Volumes A, B and C of the
EPA System Design and Development Guidance. Those EEIs which are useful as
guidelines during system operation and maintenance are proceeded by an asterisk (*) and
are outlined in this appendix.
EEI-1 • • Mission Needs Statement
EEI-2 • • Preliminary Design and Options Analysis
EEI-3 • • Project Management Plan
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
A-l
-------
EPA Operations & Maintenance Manual
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/rRACEABILnY
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.S 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 Test Data Environment
4.1.3 Test Schedule
4.1.4 Test Results
A-2
-------
EPA Operations & Maintenance Manual
EEI-7
SOFTWARE TEST AND ACCEPTANCE PLAN
(Continued)
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.S Integration Test Schedules
4.2.6 Integration Test Results
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
A-3
-------
EPA Operations & Maintenance Manual
SOFTWARE TEST AND ACCEPTANCE PLAN
(Continued)
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-4
-------
EPA Operations & Maintenance Manual
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-5
-------
EPA Operations & Maintenance Manual
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.12.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-6
-------
EPA Operations & Maintenance Manual
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 ofThisDocument
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 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-7
-------
EPA Operations & Maintenance Manual
SOFTWARE USER'S REFERENCE GUIDE
1. INTRODUCTION
1.1 Purpose
1.2 Background
1.3 Scope
1.4 System References
1.5 Terms and Abbreviations
1.6 Organization of This Document
2.1 Government Documents
2.2 Non-government Documents
3. DESCRIPTION OF THE SYSTEM
3.1 System Overview and Mission Based Activities
3.2 System Flow and Data Descriptions
3.3 System and Program Manager
3.4 Data Dictionary
4. SYSTEM ACCESS TECHNIQUE(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
A-8
-------
EPA Operations & Maintenance Manual
SOFTWARE USER'S REFERENCE GUIDE
(Continued)
7. USER SUPPORT AND TRAINING PROGRAM/SOURCES
7.1 User Support
7.2 Training Sources/Schedules
8. NOTES
9. APPENDICES
10. GLOSSARY
A-9
-------
EPA Operations & Maintenance Mama!
APPENDIX B
GLOSSARY
Adaptive Maintenance - Software changes that are made in response to forces from outside
the system environment
Application Software - Computer program(s) designed to perform the automated data
processing operations associated with specific application requirements.
Archiving - Permanently storing system data as an historical record of system activity for
the purpose of performing time series comparisons and projections.
Change Control Administrator - The person tasked with the responsibility of evaluating,
planning and controlling required system changes as part of the configuration management
process. For smaller systems, one person is often sufficient to accomplish all of these
tasks.
Change Control Board - For larger systems, that group of managers appointed the
responsibility for evaluating, planning and controlling required system changes as pan of
the configuration management process.
Computer Center - The concept of a "computer center" relates to the hardware and software
environment necessary to support a system application, usually associated with the
operations of a major computer center, but is also just as valid when discussing
minicomputers or local end-user computing workstations.
Configuration Management - Management and implementation methodologies associated
with increasing or correcting system capabilities, a partial system redesign, or determining
software obsolescence.
Corrective Maintenance - System changes made in response to abnormal and/or debilitating
system performance.
Data Dictionary - Collection of information about the data used in a system. This includes
names and descriptions of data elements, and data source and format
B-l
-------
EPA Operations & Maintenance Manual
Database Administrator - That person primarily responsible for managing the data within a
system. This includes supervising data entry, update, and deletion procedures.
Functional Maintenance - System changes performed in response to user requests for
enhanced system performance.
Maintenance Cycle - The periodic identification, evaluation, selection, implementation and
testing of system changes.
Modularity - The separating of system functions and program source code into independent
but related groups to facilitate system development and maintenance.
Parameters - Individual variables used by software developers as a mechanism for altering
the performance characteristics of an application system by varying baseline criteria rather
than reprogramming.
Software Improvement Increment - A finite grouping of enhancements and modifications to
be incorporated into the system software at one time.
Software Maintenance Manual - A programmer's technical reference guide used as a tool
for implementing software changes.
Software Operations Manual - A manual providing the system operations staff with a
procedural reference for maintaining a stable and viable system.
Software Users Reference Guide - A guide to provide users with die information necessary
to effectively utilize all system functions.
Source Code - Internally documented computer-generated program listings.
Supervisory Controls - Controls established to assist in monitoring the daily operation of a
system.
System Access Techniques - The means by which a user interacts with an automated
system.
B-2
-------
EPA Operations & Maintenance Manual
System Life Cycle - The complete evolution of an application system through its various
phases: initial needs analysis, design, development, implementation, operations and
maintenance, and eventual obsolescence.
System Manager - The person tasked with the responsibility of ensuring a good interface
between the system and the user community.
System Manager's Guide - A detailed procedural guide to the performance of administrative
activities associated with a system.
System Operator - The person(s) responsible for system operation activities, including
operating the hardware and maintaining the stability of the application software for the user
community.
Table File - A group of variables or constants with like attributes, used by software
developers as a mechanism for altering the performance characteristics of an application
system by varying baseline criteria rather than reprogramming.
B-3
------- |