+------------------------------------------------+
| **U. S. Department of Energy**                 |
|                                                |
| ** (DOE)**                                     |
+------------------------------------------------+
|                                                |
+------------------------------------------------+
| **CUSTOMER **                                  |
|                                                |
| **INFORMATION TECHNOLOGY (IT) SUPPORT SYSTEM** |
|                                                |
| **(CITSS)**                                    |
|                                                |
| **Configuration Management Plan**              |
|                                                |
| **December 1997**                              |
|                                                |
| **U. S. DEPARTMENT OF ENERGY**                 |
|                                                |
| ** Office of the Chief Information Officer**   |
|                                                |
| **and Headquarters Collaboration Group**       |
+------------------------------------------------+

**Change Control Page**

The change control page will be used to record information for
controlling and tracking modifications made to this document.

Revision Date: 12/09/97

Author: Brian Field

a\. Section(s): 2.0

Page Number(s): 2.1 - 2.2

Summary of Change(s): Members of the new configuration control board
were identified.

b\. Section(s): 3.0

Page Number(s): Throughout the section

Summary of Change(s): The configuration control board is defined and
it\'s role is outlined.

c\. Section(s):

Page Number(s):

Summary of Change(s):

d\. Section(s):

Page Number(s):

Summary of Change(s):

Revision Date: mm/dd/yy

Author: Author Name

Section(s):

Page Number(s):

Summary of Change(s):

Revision Date: mm/dd/yy

Author: Author Name

a\. Section(s):

Page Number(s):

Summary of Change(s):

b\. Section(s):

Page Number(s):

Summary of Change(s):

**Title Page**

Document Name: Customer IT Support System

Configuration Management Plan

Publication Date: September, 26, 1997

Revision Date: December 15, 1997

Contract Number: DE-AC01-95AD34277

Project Number: Task #: 25-044-07-7-07

CDSI #: 4012

Prepared by: Brian Field

Approval: [ ]{.underline}

Patrick Hargett, HR-441

**THIS IS A WORKING DOCUMENT THAT WILL BE UPDATED AS THE PROJECT
PROGRESSES. COMMENTS RECEIVED FROM THE CITSS PROJECT TEAM, CUSTOMERS,
AND STAKEHOLDERS SHOULD ONLY BE CIRCULATED AFTER COORDINATION WITH THE
PROJECT MANAGER.**

**Table of Contents**

**1.0 Introduction**

**1.1 Purpose **

The Configuration Management Plan (CMP) defines the guidelines to be
used to manage changes to the Customer Information Technology Support
System (CITSS) production and test bed environments. CITSS will be
implemented in major version releases, with each release containing
additional system features, until all specified functionality is in
place in the production environment. The CITSS software architecture is
composed of Commercial Off The Shelf (COTS) software, including Applix
Enterprise, network operating systems, data base management systems,
desktop operating systems, and other COTS such as WinBeep and NetCensus.
With COTS packages, version releases and updates are routinely expected.
Similarly, the hardware architecture is varied and includes, file
servers, data base servers, desktop PCs, and modems. Also, Applix
Enterprise can be modified by CITSS Project staff to meet the
requirements of the customer. This document details how the CITSS
Project Team will manage the expected changes to the components of the
system.

**1.2 Scope **

**1.2.1 System Overview **

The office of the Chief Information Officer (CIO) and members of the
Headquarters Collaboration Group need a reliable, up-to-date, automated
IT support system that will improve support services delivered to their
collective customers. CITSS will be the hub in the CDSI support service
cycle, and can be used and accessed by other IT service providers.

The major functional objectives of CITSS are:

· Enable customer-focused services

· Facilitate single customer point-of-entry

· Support service-provider ownership of requests

· Integrate IT support functions with other business processes

· Empower seamless service delivery

· Reduce service response and resolution times

· Reduce support costs

· Increase customer satisfaction

CITSS will be implemented for the benefit and use by all IT related
service providers throughout the DOE Headquarters. As our IT
architecture becomes more and more integrated, the root cause of our
problems become more difficult to determine. Often we must peel off
layers of possibilities to get at the root of the problem. These layers
of possibilities very frequently cross organizational and technical
support boundaries. Without a common IT support system for most service
providers, the initial definition of the problem and subsequent audit
trails of tests and analyses are not available and must be continually
rediscovered. The process, without a common repository for the collected
information, results in inefficiency and poor customer service. To that
end, the more IT service providers that use CITSS, the broader the scope
for improving our efficiency and customer satisfaction.

CITSS will be configured based on the best practices derived from a
review of the support processes in use by all organizations today as
well as those we can identify from sources such as the Gartner Group. A
number of these practices and supporting processes are pre-loaded in
Applix Enterprise. Tied to the processes and the successful installation
of CITSS will be the determination of the business rules that control
staff, user, and manager notification; escalation rules that will most
likely be tied to service level agreements; interfacing systems design
and business process re-engineering to support CallUp and PAMS
integration; and the integrated support processes for actions such as
new IT installs, moves, retirements, and customer-related actions such
as adding or removing customers from LAN's.

**1.2.2 Applicable Configuration Items **

The CITSS project is being managed by adhering to the Department of
Energy (DOE) Software Engineering Methodology (SEM), therefore, all
appropriate SEM project deliverables will be included in the scope of
this plan.

CITSS will be comprised of many software and hardware components, both
in a test bed and production environment. This will encompass the
following areas:

· All hardware and accompanying documentation contained in the CITSS
test bed and production environments

· All Applix Enterprise software releases and documentation

· All Network Operating System releases and documentation

· All Desktop Operating System releases (i.e. Windows 95 or NT) and
documentation in the test bed and production environments

· All Data Base Management System (DBMS) releases and documentation

· All other related COTS software releases and documentation

**1.3 References **

This document was prepared using the following documents as guidelines
or for input.

a\. IEEE Standard for Software Configuration Management Plans (IEEE Std
828-1990), The Institute of Electrical and Electronics Engineers, Inc.
New York, NY 1990

b\. CITSS Project Plan, September, 1997

**2.0 Configuration Management**

**2.1 Organization **

The following table identifies all personnel and/or groups who have
responsibilities with regard to configuration management for CITSS.

+----------+----------+----------+----------+----------+----------+
| **Role** | **Name** | **Organi |          |          |          |
|          |          | zation** |          |          |          |
+----------+----------+----------+----------+----------+----------+
| System   | Bill     | HR-44    |          |          |          |
| Owner or | S        |          |          |          |          |
| De       | ylvester |          |          |          |          |
| signated |          |          |          |          |          |
| Repres   | Patrick  |          |          |          |          |
| entative | Hargett  |          |          |          |          |
+----------+----------+----------+----------+----------+----------+
| Pilot    | Penny    | HR-4/    |          |          |          |
| Group    | Gardner  | ER/NN/EE |          |          |          |
| POCs &   |          |          |          |          |          |
| Group    | Richard  |          |          |          |          |
| Members  | Yockman  |          |          |          |          |
|          |          |          |          |          |          |
|          | Ted      |          |          |          |          |
|          | K        |          |          |          |          |
|          | urkowski |          |          |          |          |
+----------+----------+----------+----------+----------+----------+
| Project  | Brian    | O        | Senior   | Kim      | AOSS     |
| Manager  | Field    | versight | Analyst  | W        | Sys.     |
|          |          | Ac       | & Senior | andersee | Engr.    |
|          |          | tivities | Pr       |          | Svcs.    |
|          |          |          | ogrammer | David    |          |
|          |          |          |          | Ensign   |          |
|          |          |          |          |          |          |
|          |          |          |          | Trish    |          |
|          |          |          |          | Fuchs    |          |
+----------+----------+----------+----------+----------+----------+
| Confi    | TBD      | TBD      |          |          |          |
| guration |          |          |          |          |          |
|          |          |          |          |          |          |
| Manager  |          |          |          |          |          |
+----------+----------+----------+----------+----------+----------+
| Confi    | Brian    | O        |          |          |          |
| guration | Field    | versight |          |          |          |
| Control  |          | Ac       |          |          |          |
| Board    | David    | tivities |          |          |          |
|          | Ensign   |          |          |          |          |
|          |          | AOSS     |          |          |          |
|          | Trish    | Sys.     |          |          |          |
|          | Fuchs    | Eng.     |          |          |          |
|          |          | Svcs.    |          |          |          |
|          | Kim      |          |          |          |          |
|          | W        |          |          |          |          |
|          | andersee |          |          |          |          |
|          |          |          |          |          |          |
|          | Other    |          |          |          |          |
|          | Members  |          |          |          |          |
|          | TBD      |          |          |          |          |
+----------+----------+----------+----------+----------+----------+

**2.2 Responsibilities **

Each of the roles identified in the earlier table have specific
configuration management responsibilities. The responsibilities are
defined below.

**System Owner or Designated Representative**

· Advises Pilot Group POC's and the CITSS Project Team (through the
Project Manager).

· Signs off on major CITSS deliverables.

· Concurs/Non-concurs at stage exits with the successful completion of
each phase.

· Concurs/Non-concurs upon any substantive project issues that impact
resources, schedules, and other operational considerations.

· Advises Pilot Group POCs and Project Manager on approving and
prioritizing CITSS changes.

· Initiates Change Requests during project reviews by identifying new or
previously unidentified requirements.

· Provides budgetary resources for the project.

**Pilot Group POCs & Pilot Group Members**

· Approves/disapproves system functionality proposed.

· Signs off on major CITSS deliverables.

· Concurs/Non-concurs at stage exits with the successful completion of
each phase.

· Concurs/Non-concurs upon any substantive CITSS issues which impact
resources, schedules, and other operational considerations.

· Initiates Change Requests when reviewing the project by perceiving new
or previously unidentified requirements.

· Approves and prioritizes CITSS changes with the System Owner and
Project Manager.

**Project Manager**

· Interfaces with the System Owner and the Pilot Group POCs to ensure
that the configuration management plan procedures are followed and that
CITSS meets or exceeds the customer's expectations.

· Consults with the System Owner and the Pilot Group POCs for approval
and prioritization of CITSS changes.

· Makes Project Team assignments for preliminary investigation of change
requests (analysis, feasibility and impact study, resource estimates),
and the assignments to make, test, and implement the change.

· Reviews analysis and resource estimates.

· Monitors schedules and status items to ensure timely delivery.

· Reviews CITSS release plans with the Configuration Manager.

· Coordinates CITSS releases with the Configuration Manager and the
System Owner.

· Responsible for the release of documentation.

**Systems Analysts and Programmers**

· Identifies new or previously unidentified Configuration Items during
design, customization, testing, and processing changes.

· Initiates Change Requests when encountering system problems or when
recognizing performance improvements during design, customization,
testing, and processing changes.

· Performs preliminary investigation of change requests (analysis,
feasibility and impact study, resource estimates).

· Makes, tests, and implements the approved changes.

**Configuration Manager**

· Coordinates with the Project Team in identifying Configuration Items.

· Determines the areas affected by each Configuration Item.

· Maintains an inventory of all Configuration Items.

· Responsible for providing status reports on the configuration effort.

· Maintains the CMP.

· Ensures that the configuration management process is executed
according to the plan.

· Interfaces with the Project Manager and the Project Team.

· Plans CITSS releases with the Project Manager.

· Coordinates documentation changes.

· Develops and implements CM procedures and necessary forms.

· Provides CM technical advice and training as needed.

**Configuration Control Board**

· Reviews COTS, hardware, or CITSS customer change requests and impact
findings, in terms of project schedule, cost, and impact on the
customers.

· Recommends change approval or disapproval.

· Meets within five days to resolve change requests.

· Forwards the change approval or disapproval decision to CITSS Project
Manager for implementation.

· Informs the customer of the change decision in writing.

**2.3 Applicable Policies, Directives, and Procedures**

During CITSS' life cycle, DOE may issue guidelines or directives with
regard to Headquarters-wide recommended hardware and software
configurations. Working groups, such as the Headquarters Collaboration
Group, may take the lead in this area. We will manage the CITSS
configuration in accordance with the guidelines stated by this group or
any other DOE information management team.

We will also conform to the Information Architecture Principles
identified in the DOE Information Architecture document, originally
published in 1995.

**3.0 Configuration Management Activities**

CM guidelines provide a structure to ensure that all CITSS components
are documented and managed throughout the system's life cycle. CITSS is
comprised of a series of COTS packages, operating systems, and hardware
platforms. Improvements in each of these areas are released with
relative frequency. As a result, the system's configuration must be
controlled effectively to ensure that the integrity, continuity, and
availability of the mission critical CITSS application is maintained.

The term "current production version" is used throughout this section.
"Current production version" is used to define the entire CITSS
configuration to include all COTS, hardware, and Applix Enterprise
components.

Activities necessary to achieve the CM objective include:

· Configuration Identification

· Configuration Control

· Configuration Status Accounting

· Configuration Audits and Reviews

**3.1 Configuration Identification **

There are four major CITSS configuration areas:

· Project Documentation

· COTS Software

· Hardware

· Applix Enterprise Customization & Integration

Specific items in each of these areas may be added or deleted during the
CITSS life cycle. This document will be modified to reflect any changes.

**3.1.1 Project Documentation**

During the CITSS life cycle, SEM and other project documentation will be
developed and updated. In most cases, documents will be issued in draft
and final forms. The Project Manager will be responsible for the release
of the documents.

All project documentation, as defined in the project plan, is subject to
this guideline. The project documentation includes, but is not limited
to:

· Project Plan

· Quality Assurance Plan

· User Documentation

· Test Plans

The following information is to be provided for each document
deliverable. The document name and publication date will be used in
combination to identify unique documents.

· Document Name

· Publication Date

· System Title

· Contract Number

· Author(s)

· Concurrence Organization Signature(s)

A copy of all major project documentation will be forwarded to DOE's
Technical Research Library. Copies of the documents may be obtained from
the Configuration Manager, the Project Manager, or the Technical
Research Library.

**3.1.2 COTS Software**

CITSS is comprised of a number of COTS packages and operating systems.
These packages include, but may not be limited to:

· Applix Enterprise Helpdesk

· WinBeep

· Tally NetCensus

· ServiceWare's Knowledge Paks

· Reach Out

· Oracle

· Digital Unix

· Windows NT Server

· Novell

We will identify the COTS packages by product name and version release
number.

The COTS, with documentation, will be stored in the test bed location at
656 Quince Orchard Road, Gaithersburg, MD, or in the production location
at the DOE Germantown facility.

**3.1.3 Hardware**

CITSS is also comprised of several hardware components. They include,
but may not be limited to:

· Digital AlphaServer 4100

· Novell Server(s)

· U.S. Robotics Modems

· VIP Process Servers

· Testing & Configuration Servers & Workstations

Unique DOE Tag numbers, assigned by DOE property management personnel,
affixed to the hardware will be used to uniquely identify each
component. If a DOE Tag number is unavailable for a component, the
component's serial number will be used in it's place.

A record of the component's detailed specification will be maintained.
For example, we will record items such as available RAM and hard disk
space, Network Operating System, Network Interface Card, and Processor
Type for each file server in the production and test bed environments.

It is anticipated that the hardware will be located in two locations,
DOE's Germantown Facility (production components) and 656 Quince Orchard
Road, Gaithersburg, MD (test bed components). All associated
documentation will be stored where the specific component is located.

**3.1.4 Applix Enterprise Customization & Integration**

Applix Enterprise may be customized, or integrated with other software
and applications, to meet the specific needs of it's users. The CITSS
project team intends to release major production versions of the
application after significant system enhancement or modification.
Interim versions may be released to correct minor flaws or to
accommodate customer requested changes that have a relatively small
impact on the system.

Major production versions are primary baseline releases, while minor
releases will reflect updates to the current production baseline. The
version numbering scheme will start with 1.00 and increment decimally
for minor version releases and by 1 for major production version
releases.

Copies of the customized software will be maintained at 656 Quince
Orchard Road, Gaithersburg, MD and will be backed up using DOE's
Mainframe backup software technology, ADSM.

**3.2 Configuration Control **

In a COTS integration project like CITSS, software and hardware
components can be updated and released to the general public very
frequently. It is anticipated that these upgrades will be handled
through the configuration control process, or configuration control
board (CCB), and will be initiated by members of the project team. The
introduction of new modules and functionality through Applix
customization will be controlled through the change control process or
CCB as well. These changes can be initiated by project team members or
CITSS customers.

The CCB will meet as necessary to review COTS, hardware, or CITSS
customer change requests.

The CCB will:

· Approve specific procedures for encouraging CITSS customers to
identify improvements and submit change requests

· Agree on criteria for prioritizing, evaluating, and approving or
disapproving change requests

· Approve a prioritized list of changes to be made on the CITSS current
production version

· Set schedules for issuing each new version and ensure that each new
version is adequately tested and documented before issuance.

**3.2.1 Requesting Changes **

Any CITSS project team member or any CITSS customer may request a change
or correction to the system. A CITSS Change Request form must be
submitted the CITSS Project Manager to initiate the process or a request
may be submitted to the CITSS support team through CITSS logged as an
incident. This form, or the incident in CITSS, will be used to report
problems, identify new or changed requirements, and log suggestions for
improvement. A CITSS project team member is expected to complete the
CITSS Change Request form and present it to the Project Manager. A CITSS
customer may contact a member of the project team and take one of two
steps to initiate the process. They may request a CITSS Change Request
form, complete it, and return it to the Project Manager, or they may
contact the Project Manager directly and ask that the Project Manager
submit the CITSS Change Request form on their behalf. A copy of the
CITSS Change Request form is attached in Appendix A.

**3.2.2 Evaluating & Approving/Disapproving Changes **

Upon receipt of a CITSS Change Request form, the Project Manager will
review the form for completeness, clarity, and applicability. If the
form is incomplete in any way, the Project Manager will contact the
submitter for clarifications. Assuming that the form is complete, the
Project Manager will make an impact assessment of the change. The
following is a list of impact definitions.

**Emergency -** If the change is not made as soon as possible, CITSS
operation may be severely hampered or terminated. An emergency change
request should be resolved within 24 hours.

**Critical -** The impact of not making the change would significantly
impact CITSS, but would not suspend it's operation. A critical change
request should be resolved in 5 working days or less.

**Routine -** A normal change request that can be planned, included in a
current schedule or plan, and ranked among other normal actions.

**Deferred -** A reasonable change request, and one that is beneficial
to the system, but is delayed because of other project schedules or
tasks.

For Emergency or Critical impact change requests, the Project Manager
will assign the appropriate staff to the task and will inform the
remainder of the project team of the situation immediately. For Routine
or Deferred impact change requests, the Project Manager will present
them at the next CCB meeting for discussion. The CCB may decide to
approve or disapprove of the change request during the meeting, or, a
project team member or members may be assigned the responsibility of
researching the proposed change and reporting on system impacts. Impacts
should be addressed in terms of those on the project schedule, project
costs, and impact on the customers.

**3.2.3 Implementing Changes **

After a CITSS Change Request form is approved, the Project Manager will
assign the appropriate technical personnel to the task. All changes to
CITSS will be made in the test bed environment located at 656 Quince
Orchard Rd. When a change has been fully tested in the test bed
environment, a schedule will be developed to implement the change in the
production environment. In most cases, the change to the production
environment will be completed outside of normal working hours in order
to minimize the impact to the customers. The CITSS Change Request form
will be updated to reflect the completed status of the request.

**3.3 Configuration Status Accounting **

Each configuration item, COTS, hardware, and Applix Enterprise, will be
tracked in detail. COTS packages will be tracked, at a minimum, by
product name, version number, and release date. Hardware items will be
tracked, at a minimum, by vendor, product name, DOE Tag \# (if
applicable), serial number, list of installed components, and physical
location. Applix Enterprise customization will be tracked, at a minimum,
by version number, release date, and capability.

The tracking will be done by the Project and Configuration Managers. The
use of an automated system is likely, but it is not completely defined
at this time.

Paper records of the CITSS Change Request forms will be maintained in a
project notebook.

All change request activity will be recorded in the monthly Technical
Status Report (TSR) required of all task assignments. They will also be
discussed and distributed at regular project meetings.

**3.4 Configuration Audit and Reviews **

Auditing verifies that configuration items reflect operational
objectives, meet DOE standards, and satisfy customer requirements. The
CITSS project team will follow a technical review process. This will
include Structured Walkthroughs, In-Stage Assessments, Stage Exits, and
System Acceptance.

Each of these processes are described below.

**Structured Walkthroughs** are informal meetings among the CITSS
project team to review and evaluate technical aspects of the
application.

**In-Stage Assessments** will be conducted with a Quality Assurance (QA)
consultant near the end of each project stage. This is a technical
review to assure that the established project management processes are
being followed effectively.

**Stage Exits** are formal meetings with a group of selected individuals
to review and evaluate the current status of the project. When a stage
has been successfully \"exited\", it indicates that all deliverables due
to date have been completed, all outstanding issues have an acceptable
action plan, and there is a sound plan for the remainder of the project.
All approvers must provide a written position of concur/non-concur at
the Stage Exit.

**System Acceptance** provides a formal basis for determining whether
the system is fully operational and has satisfied customer requirements.

**4.0 Configuration Management Resources**

At this time, no decisions have been made regarding an automated
configuration management tool. It is likely that a common software
package will be used and there will be no costs incurred on a specific
tool. As a result, no additional training, personnel, or equipment will
be required. Until an automated solution is put in place, the manual
methods mentioned in Section 3 will be employed.

**5.0 Configuration Management Plan Maintenance**

The Project and Configuration Managers are responsible for maintaining
this plan. The plan is subject to the procedures specified in the CITSS
Software Quality Assurance Plan (SQAP). Under the terms of the SQAP, the
CM plan is subject to review throughout the CITSS life cycle,
particularly during the In-Stage Assessment and Stage Exit processes.
Significant changes will be made through a new version release of the
plan. Minimal changes may be made through the use of page updates.

**Appendix A - CITSS Change Request (CCR) Form**

** CITSS Change Request (CCR) CCR#**\_\_\_\_\_\_\_\_\_

** Originator:**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
**Date:**\_\_\_\_\_\_\_\_\_\_\_\_\_\_** Release#**\_\_\_\_\_\_\_\_\_

Please attach supporting documentation for the requested change

(screen/report printouts, document pages affected, etc.)

  ---------------------- ---------- ----------------------- --------- -- -- ---------- -- -- --------------------- -- -- ---------------- -- -- ----------------------- -- --
  **Status**             **Date**   **Initials/Comments**                                                                                                                  
  Reviewed & Estimated                                      On Hold         Canceled         Approved for Change         System Updated         Documentation Updated      
  Completed                                                                                                                                                                
  ---------------------- ---------- ----------------------- --------- -- -- ---------- -- -- --------------------- -- -- ---------------- -- -- ----------------------- -- --

**New Release#**\_\_\_\_\_\_\_\_\_

( ) Critical

( )Routine

( )Deferral