IDAHO NATIONAL ENGINEERING LABORATORY
ENVIRONMENTAL RESTORATION INFORMATION SYSTEM
SYSTEM CONFIGURATION MANAGEMENT PLAN
November 1998, Revision 5
Idaho National Engineering and Environmental Laboratory
P. O. Box 1625, Idaho Falls, Idaho 83415
Prepared for the U.S. Department of Energy
Under DOE Idaho Field Office Contract
ABSTRACT
This report contains a description of the plan ensuring baselines,
control changes to these baselines, record and track status, and the audit
procedures corresponding to this plan. This plan will support all software
systems and products developed for the Environmental Restoration Information
System (ERIS). The ERIS is a computerized data management system that
supports the Environmental Restoration Program and its ongoing activities at
the Idaho National Engineering and Environmental Laboratory.
This document is developed using the American National Standards
Institute/Institute of Electrical and Electronics Engineers Standard 828-1983
for system configuration management plans and the EG&G Idaho, Inc., Quality
Manual, Section QP-21, "Computer Software Configuration Management," and
addresses the configuration management of critical software.
TABLE OF CONTENTS
ACRONYMS
- 1.1 Introduction
- 1.2 Scope
- 1.3 References
- 2.1 Organization
- 2.2 SCM Responsibilities
- 2.3 Interface Control
- 2.4 SCMP Implementation
- 2.5 Applicable Policies, Directives, and Procedures
- 2.6 Password Accountability
- 3.1 Configuration Identification
- 3.1.1 Requirements Phase
- 3.1.2 Design Phase
- 3.1.3 Implementation Phase
- 3.1.4 Integration Phase
- 3.1.5 Test Phase
- 3.2 Configuration Control
- 3.2.1 Design Phase
- 3.2.2 Implementation Phase
- 3.2.3 Integration Phase
- 3.2.4 Test Phase
- 3.2.5 Beta Test Phase
- 3.3 Configuration Status Accounting
- 3.4 Audits and Reviews
APPENDIX A - HARDWARE CONFIGURATION DIAGRAM
SOFTWARE CONFIGURATION DIAGRAM
APPENDIX B - VERSION CONTROL PROCEDURES
APPENDIX C - CONFIGURATION CONTROL PROCEDURES
APPENDIX D - ADMINISTRATIVE CONFIGURATION CONTROL PROCEDURES FOR TUTORIAL
APPENDIX E - DATA STRUCTURE IMPLEMENTATION PROCEDURES
APPENDIX F - DATA CHANGE CONTROL PROCEDURES
APPENDIX G - INTERNAL AUDIT REPORT FORMAT
APPENDIX H - DATABASE BACKUP AND RECOVERY PROCEDURES
ACRONYMS
- ANS American National Standard
- ANSI American National Standards Institute
- ARDC Administrative Record and Document Control
- ASME American Society of Mechanical Engineers
- ASCII American Standard Code for Information Interchange
- CASE computer aided software engineering
- CGM Computer Graphics Metafile
- DBA data base administrator
- DDIF digital data interchange format
- DFAD data flow analysis document
- ERIS Environmental Restoration Information System
- ER&WM Environmental Restoration & Waste Management
- E&WMCU Environmental and Waste Management Computing Unit
- GIS Geographic Information System
- IEEE Institute of Electrical and Electronics Engineers
- INEEL Idaho National Engineering and Environmental Laboratory
- RDBMS Relational Data Base Management System
- SCM software configuration management
- SCMP software configuration management plan
- STR software trouble report
- TBA task baseline agreement
- VCS version control system
1.1 Introduction
This document details the system configuration management plan (SCMP) for
the Environmental Restoration Information System (ERIS), a comprehensive data
management system for the Environmental Restoration & Waste Management program
(ER&WM) at the Idaho National Engineering and Environmental Laboratory.
1.2 Scope
The SCMP details the methods used to maintain the configuration
information concerning all application software and associated documentation.
User documentation, programmer documentation, management documents, and
associated documentation will be controlled. Applications developed using
third-party tools will also be controlled under this plan. The plan will
reference the method used to control associated hardware configuration
diagrams.
The software developers will maintain version control on the total system
configuration from the design phase to the completion of the acceptance
testing. After the acceptance testing is completed, the staff of the
ERIS will assume configuration control responsibility for associated software. This team consists of members of ER and members of IRM, working in a matrixed
relationship.
1.3 References
- VCS: A Networked Version Control System, EGG-CATT-8926, February 1990.
- EG&G Idaho, Inc., Company Procedures Manual, Section 9.7, "Inspection Nonconformances," May 31, 1991.
- EG&G Idaho, Inc., Environmental Restoration & Waste Management, Program Directives Manual, ER&WM-PD 2.2 "Internal and Independent Review of Documents." June 30, 1990.
- EG&G Idaho, Inc., Environmental Restoration & Waste Management, Program Directives Manual, ER&WM-PD 1.9, "Records Management."
- EG&G Idaho, Inc., Environmental Restoration & Waste Management Program Quality Program Plan, QPP-149, October 1990.
- Institute of Electrical and Electronics Engineers, Software Engineering Standards, ANSI/IEEE Standard 828-1983, May 1987.
- System Quality Assurance Plan For The Environmental Restoration Information System, latest revision.
- General Requirements for the Environmental Restoration Information System, EGG-WM-8615, July 1989.
- EG&G Idaho, Inc., Quality Manual, Section QP-21, "Computer Software Configuration Management," December 29, 1989.
This section of the SCMP describes the organization and associated
responsibilities of the development team for the ERIS.
2.1 Organization
The ERIS development team is divided into two components. The first
component acts as the umbrella for the total project. This component is the
project management group, responsible for the budget and for acting on behalf
of ER.
The other component consists of the development team, part of the
Information Resource Management Branch of LMITCO, Inc.
Prior to the ERIS passing the acceptance test, the responsibility for
configuration control will reside with the system engineers responsible
for each associated work area. Upon completion of the acceptance test, the
responsibility for maintaining configuration control will lie with the staff
of the ERIS Project.
The ERIS development team will establish the configuration control
procedures and practices for the system development. These procedures and
practices will be implemented and maintained by the ERIS staff after
acceptance of the system.
A configuration control board of not more than three members will be
established to monitor and approve system changes upon entry into the
integration phase of system development. This configuration control board
will consist of two peer engineers and one system engineer until testing is
complete, and then the board will consist of two ER&WM personnel and one
externam engineer. The members will be rotated through the panel based
on the interest of the participants. An engineer will not sit on the
board while changes involving that engineer's development are being
considered.
2.2 SCM Responsibilities
Identifying needed configuration changes will be the responsibility of
the individual development engineer until the software is shop tested and
turned to the system engineer for integration. After this point, and until
the system goes under configuration control, configuration changes will be the
responsibility of the system engineers. The ongoing responsibility for
identifying configuration changes after acceptance will reside with the system
data base administrator. The data base administrator will be responsible for
control of the configuration management system and will serve as chairman of
the configuration control board.
Once changes are identified, the changes will be scheduled for review by
the appropriate system engineer to the configuration control board (after the
implementation phase, or as needed for major changes during this phase). The
request for a meeting will be accomplished by an internal Company memorandum,
and tracked by the ERIS project office. The findings of the control board
will be recorded in an internal Company memorandum, and also tracked by the
ERIS project office. Nonconformance items will be reported, controlled, and
disposed of according to Section 9.7 "Inspection Nonconformances," of the
Company Procedures Manual (2).
Reviews and implementation of the configuration management system are the
responsibility of the ERIS Team. During development of the system, not more than
two informal configuration control reviews will be performed by the ERIS
project manager or his appointee. Results of these reviews will constitute an
informal Company report to be tracked by the ERIS project office. Reviews of
the configuration control system are expected to be performed by the
responsible system engineer and findings are to be filed as part of the
monthly progress report to the ERIS project manager.
2.3 Interface Control
The ERIS is expected to interface with many other data management
systems, and configuration control with these interfaces must be maintained.
A requirement of the engineer designing the interface to other systems is that
an information flow be established between the foreign data management system
and the ERIS project office. The ERIS project manager will maintain all
identified system interface specification documents and associated control
documents. In the event that the foreign system changes, the ERIS project
office will be notified and will initiate a meeting with the configuration
control board by means of an internal Company memorandum.
Changes to the system to accommodate the interface
changes will be documented with a letter to the configuration control board
chairman.
In the event that hardware changes are required, the initiating
individual will initiate a meeting of the configuration control board with an
internal company memorandum. The configuration control board will approve or
disapprove the requested change, and will check to ensure that the requested
change corrects the original problem and does not create new problems as a
result of the system modifications. This meeting normally takes place
during the regular weekly ERIS staff meeting.
2.4 SCMP Implementation
The configuration control board will be established during the
implementation phase of the system development effort. The control board will
be responsible for generating unique tracking numbers for each configuration
issue and these numbers will be assigned to all associated documentation and
letters.
The configuration control board will be responsible for developing and
implementing a configuration baseline numbering system and the changes that
demark minor and major baseline numbers. The procedures defining the baseline
numbering system will be developed by members of the ERIS staff. This
baseline will begin when the implemented software is entered into the
configuration management system during integration. When all associated items
are entered into configuration control, the baseline will be established as
version 0. During the initial meeting, the configuration control board will
establish the configuration baseline numbering and determine when the system
will come under a new baseline.
The ERIS project manager is expected to perform a review of the system
configuration management (SCM) system once during integration of the system,
and once during the acceptance testing. If findings are significant, the
review team will schedule a follow-up review to ensure that changes have been
implemented. Reviews are to be performed by the system engineers, as a
minimum, whenever the system baseline number changes. The principle
verification that the system is being correctly used will be the documentation
maintained by the ERIS project office.
The control board must approve all changes in software tools for
development and testing. The initiator of the change will request, during a weekly staff meeting , that the modification or substitution of a
tool be reviewed and approved by the configuration control board. Once the
system is in production, ongoing maintenance tasks will be software platform
upgrades.
2.5 Applicable Policies, Directives, and Procedures
The ERIS is constructed as a response to Environmental Protection Agency
and Department of Energy regulations. As such, the development of this system
must implement all appropriate regulations, such as those defined in the LITCO, Quality Manual, Section QP-21, "Computer Software Configuration
Management (5), and the LMITCO, Environmental Restoration Program,
Program Quality Plan, QPP-149 (4). It is the duty of the ERIS project manager to
inform the development team of changing regulations that may affect the
implementation and testing of the system.
The appropriate system engineer will develop the necessary procedures for
addressing the problems of configuration management in the appropriate area.
The minimum set of procedures are as follows:
- Configuration control procedures for maintaining the Oracle database and Oracle forms
- Configuration control procedures for upgrading the various software platforms, such as Oracle, Geographical Information System (GIS), compilers, and computer aided software engineering (CASE) tools.
- Code control procedures for source code developed in various programming languages.
- Document control procedures for controlling the documents and internal letters produced during the development of ERIS. Document release procedures for controlled documents shall also be described.
- Hardware configuration control procedures, describing the steps to be performed when changing the underlying hardware platform for the ERIS.
- Coding standards that describe the program and module naming conventions, comment standards, and associated code structures.
- SCM review procedures.
- Problem reporting procedures.
2.6 Password Accountability
Except under documented circumstances, sharing the password for a user
identification (ID) is prohibited. Individuals are responsible for their user
IDs and passwords, and maintain responsibility for transactions made with
their user IDs.
The password for Oracle application user IDs (pseudo-users that are
created to own all data structures for an application) will be assigned to the
lead engineer as the responsible individual. The backup for the lead engineer
may also be given the pseudo-user password. No casual users (nondesigners)
will be allowed to log into the Oracle database as the pseudo-user. Refer to
the LITCO Computer Security Manual, Password Usage, Section 3.3.3, for
more information.
3.1 Configuration Identification
3.1.1 Requirements Phase
The requirements phase baseline will consist of data flow models
implemented in CASE. The data flow document will be part of the requirements
baseline. If any prototype coding or Oracle forms are built as part of this
phase, they will become part of the requirements baseline. CASE tools must be
operational on a platform in order to complete this baseline. Project
management documentation, including the project plan, the system quality
assurance plani (7) and the system configuration management plan will be included
in this baseline. If any plan describes procedures to be used in
accomplishing the plan, then the baseline will also include the procedures. A
hardware configuration diagram showing the system as it is configured at the
end of the requirements phase is part of the baseline.
3.1.2 Design Phase
The elements that define the configuration at the design phase are those
elements that are needed to complete the software design and prototype
software. The initial baseline is defined by the presence of Oracle RDBMS
operating on a hardware platform useable by both a synchronous and Ethernet
users. The baseline must contain the completed design documents and CASE
tools, in-place compilers, and a functional GIS. At this baseline level, the
individual designs must contain shop test procedures. Development engineers
have complete responsibility for configuration control at this point.
Hardware modifications or platform changes must be shown on the baseline
number of the hardware configuration diagram.
3.1.3 Implementation Phase
The implementation phase baseline configuration consists of all
implemented designs, whether implemented in Oracle, FORTRAN, C, the GIS, or
AutoCad, etc. The source files for each implementation will be stored using
the Version Control System (VCS). The engineers responsible for design
implementation must have completed shop test procedures, developed as part of
the design phase, before placing the application under VCS. After the
applications come under the VCS, system engineers have the responsibility for
configuration control. If changes are needed to this baseline, the
configuration control board must approve the changes. The hardware
configuration diagram must be made current at this baseline level.
3.1.4 Integration Phase
The integration phase baseline will consist of fully integrated software
and associated documentation. The documentation is to include the user
documentation, training documentation, and programmers' manuals. These
documents will be identified with the associated baseline numbering. The test
procedures will also be part of this configuration baseline. The appropriate
hardware configuration diagram will be an element of the integration phase
baseline.
3.1.5 Test Phase
The test phase baseline will consist of all software after the system has
succeeded in answering all of the functional requirements of the system and
the requirements stated in Section QP-21, "Software Configuration Management,"
of the LITCO, Quality Manual (5), and testing of the system is
complete. The completed test procedures then become part of the configuration
baseline. The associated documentation will have incorporated all changes
required by the results of the acceptance testing. Hardware and system
software is frozen, and the current versions become part of the test phase
baseline. The hardware configuration diagram must be updated to reflect the
current and final configuration. The ERIS project manager assumes
configuration control responsibilities during this phase.
3.2 Configuration Control
3.2.1 Design Phase
The application engineers are responsible for control of the documents
and shop test procedures during the design phase of the ERIS development. At
completion of the design review, the ASCII images of the documents will be
baselined under the VCS by the system engineer. The associated review
documentation, including correspondence, will be controlled in the ERIS
project office and will be keyed with the appropriate baseline number. System
software tools and hardware will be controlled by the system engineers.
Original copies of all purchased software will be controlled in a fireproof
vault at the Willow Creek Building, away from the server or host computer
location.
During the design phase, prototype software may be developed to aid in
requirements gathering and design completeness. The system engineers and the
ERIS project manager may, at their discretion, distribute the prototype
software to a subset of the user community. The distribution and subsequent
user configuration must be tracked by the data base administrator. A special
application of the Oracle data base will be constructed (the user table and
form) to facilitate the data base administrator's job. These users must be
supported throughout implementation, integration, and testing, and must be
updated when the configuration control board makes changes to the system.
3.2.2 Implementation Phase
The engineers responsible for implementing the individual design modules
will be responsible for application development until the application has been
tested per the shop test procedures. The design documents themselves will be
controlled by the system engineers during the implementation phase. Changes
to designs must be approved by the configuration control board. Once
successfully shop tested, the application will be controlled under the VCS.
If the application consists of program language source code, the engineer will
submit the source code for the VCS. If the application consists of Oracle
forms and menus, the *.INP files and *.REX files will be controlled under the
VCS. If the application consists of Oracle tables and data, the *.DMP files
generated from the Oracle EXP utility will be the controlled source. Autocad
and GIS applications will be controlled as *.DWG files. As in the design
phase, the associated documents will be stored in VCS as ASCII files or as
controlled documents using Company distribution, and associated review, test,
and quality assurance documentation will be controlled at the ERIS project
office.
3.2.3 Integration Phase
As development enters the integration phase, all applications will be
controlled under the VCS. The integration phase consists of making all
applications operate as a total system. This phase is primarily a
troubleshooting phase. When a problem in operating two applications is
identified, the following process will be used to modify the configuration of
the system to facilitate this process.
- The appropriate engineers will work together to specify a correction for the problem, and alternatives if applicable.
- The engineers will submit a change request, in the form of an internal Company memorandum, to the chairman of the configuration control board.
- The chairman will schedule a meeting to review the changes and to discuss the alternatives. The meeting may cover many related changes.
- The board will authorize changes to the system to facilitate integration.
- The responsible system engineer will check out the applications from the VCS to implement the changes.
- The engineers will perform the modifications and will shop test the applications to ensure that the changes have affected the performance of the modules. They will issue a change report in the form of an internal Company memorandum to the chairman of the configuration control board.
- The appropriate system engineer will check the modified applications back into the VCS and record the request number in the VCS comment field.
3.2.4 Test Phase
Control of changes to the system will occur during acceptance testing in
exactly the same fashion as in the integration phase, except that the problem
identification is the responsibility of the appropriate system engineer or his
delegatee. Test exception reports will substitute the change requests in the
procedure listed in Section 3.2.3. Test data sets are to be provided by ER&WM
and will be stored under the VCS as part of the baseline.
3.2.5 Beta Test Phase
During this phase of system implementation, the user will report problems
to the data base administration staff. The staff will prepare a software
trouble report via the Automated Error Tracking System and will submit a copy
to the chairman of the configuration control board. The remaining steps in
the problem correction process will follow exactly the same procedure as that
in the implementation phase.
A modified system will be generated with a new appropriate baseline
number. Several STRs may be incorporated into a new system baseline. The
data base administrator will distribute necessary changes to the user
community and will prepare an accompanying report outlining the changes to the
software, special installation instructions, and any miscellaneous details.
The multi-user system users will only need to be notified that the new
baseline will be implemented. The data base administrator will keep a
complete backup of the previous version until users are satisfied that the new
baseline works.
The data base administrator will be responsible for tracking new users to
the system and modifying the associated hardware configuration diagram. See
Appendix A for the hardware configuration diagram and the software
configuration diagram.
3.3 Configuration Status Accounting
The status of change items beyond a certain baseline level will be
monitored by the data base administrator and will be accessible via an Oracle
table and form (or forms). The status of any given change item will be noted
by the project office based on correspondence received in the project file.
The data base administrator will be responsible for updating the change order
table and producing a periodic report for the control board chairman and the
ERIS project manager. The minimum data set reported on is baseline number,
item number, description of item, date reported, date reviewed, date
modified, date of new control, status, and description of modification. In
addition to this tabular report, the data base administrator will report on
special situations, such as new tools versions installed, new hardware, or new
baseline releases. See the following appendices for the necessary procedures:
- Appendix B: Version Control Procedures
- Appendix C: Configuration Control Procedures
- Appendix D: Administrative Configuration Procedures for the Tutorial
- Appendix E: Data Structure Implementation Procedures
- Appendix F: Data Change Control Procedures
- Appendix G: MapObjects and ArcView IMS Design and Implementation Procedures
3.4 Reviews
The configuration management reviews will take place as outlined in
Section 1.2, and will be performed by the technical coordinator or staff.
These reviews will ensure that the procedures outlined in Section 3.2 are
being followed by reviewing the documentation on file at the project office.
A comparison review of an implementation package chosen at random will be
performed. This review will ensure that the module complies with the design
requirements and that the module has not been inappropriately changed.
Applications must not deviate from the versions stored in the VCS, unless they
are checked out to the appropriate engineer for modification.
The technical coordinator must issue findings from the review to the
software developers and to the chairman of the control board. The system
engineers must fix the immediate deficiencies and respond to the technical
coordinator with an internal memorandum describing how a permanent change in
procedures will prevent recurrence of the problem.
The principal configuration management tool for controlling the
configuration of the ERIS during development will be the VCS. The specific procedures for submitting and extracting code from the VCS are described in the ERIS version control procedures.
Each release of the ERIS to a customer will originate from within the
VCS. The system administrator will maintain a UNIX script file that extracts
all associated codes and documents belonging to a particular version number.
This script file will also compile all associated codes and Oracle
applications, and will print the necessary documentation.
An Oracle application will be constructed to track changes in the
configuration of the software. This system will be used to prepare reports on
the status of any baseline and changes to that system. The changes
outstanding and completed will be recorded, allowing the system administrator
to construct previous versions from the VCS, if necessary.
The Oracle application and data, and all information in the VCS will be
backed up weekly and stored offsite, away from the host machine.
System software will be baselined at each step of the development of the
ERIS. The supplied software will be keyed to any particular ERIS baseline
number so that vendor software does not get ahead of application development.
During the integration phase, all system software and hardware will be frozen
and will not be upgraded except on an emergency basis. All changes to the
basic system software must be reviewed and approved by the configuration
control board.
Vendors, as related to this plan, will not be required to submit their
own configuration control plans. The only requirement imposed on a vendor is
that they release controlled versions of their software and keyed numbers for
their releases. The system engineers, data base administrator, and
configuration control board assume the responsibility for ensuring that the
applications developed are functional under a particular version of the
supplier software.
A software configuration change group consists of the following
documentation:
- A change request, a test exception report, or a software trouble report, issued as an internal Company memorandum from the ERIS customer service representative or the system administrator to the chairman of the change control board. The chairman has one week to respond.
- The chairman's response, issued as an internal Company memorandum to the originator of the change request. The chairman will indicate the date of the review meeting. The chairman will also forward a description of the problem to the board members before the review meeting.
- The review meeting minutes, describing the proposed solution to the problem and an associated schedule for the change to be put in place. This will be issued as an internal memorandum to the engineers and the associated system engineer expected to perform the work on the system.
- The problem resolution report, issued to the chairman of the board by the responsible engineer.
- The appropriate periodic report from the Oracle version monitoring system, relating the change to the baseline.
All of the documentation will be maintained in the ERIS project office
and all associated documentation will be copied and sent to the ERIS project
office. The control board will issue a change request number and this number,
along with the baseline number, will constitute the identifier for the
configuration change group. If other documents are generated during problem
resolution, they will be keyed with this number and will be forwarded to the
project office for inclusion in the change group file.
All change documentation will be retained from the start of the project
until the system is turned over to the ER&WM. At that time, the ERIS project
manager will determine a retention period for associated change group
documentation. This period should be sufficient for a maintenance engineer to
reconstruct changes to the system and back off to an older version number.
When ARDC becomes fully operable and is able to accept documents for the
optical disk system, the ERIS documentation will be transmitted there per
ER&WM PD 1.9 "Records Management" (4)
The data base administrator will develop procedures to ensure the
security of the documents associated with all change groups. The preferable
solution will be the establishment of a repository in a fireproof vault at the
INEEL Supercomputing Center, with copies of all documentation stored at this
location. The documents will be stored in a VCS library on the system server,
and the library will be backed up as part of the system backup procedures and
will be secured in this fashion as well.
See Appendix I for database backup and recovery procedures.
