Author: Valued Gateway Customer
Company: CDSI

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:	                                 
		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.  INTRODUCTION					1-1
1.1  Purpose					1-1
1.2  Scope					1-1
1.2.1  System Overview					1-1
1.2.2  Applicable Configuration Items			1-2
1.3  References					1-2

2.  CONFIGURATION MANAGEMENT				2-1
2.1  Organization					2-1
2.2  Responsibilities					2-1

3.  CONFIGURATION MANAGEMENT ACTIVITIES		3-1
3.1  Configuration Identification				3-1
3.2  Configuration Control					3-3
3.2.1  Requesting Changes					3-4
3.2.2  Evaluating & Approving/Disapproving Changes	3-4
3.2.3  Implementing Changes					3-5
3.3  Configuration Status Accounting				3-5
3.4  Configuration Audit and Reviews			3-5

4.  CONFIGURATION MANAGEMENT RESOURCES		4-1

5.  CONFIGURATION MANAGEMENT PLAN MAINTENANCE5-1

APPENDIX A - CITSS CHANGE REQUEST (CCR) FORM	A-1

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 | Organization

System Owner or Designated Representative

Bill Sylvester
Patrick Hargett

HR-44

Pilot Group POCs & Group Members

Penny Gardner
Richard Yockman
Ted Kurkowski

HR-4/ER/NN/EE

Project Manager | Brian Field | Oversight Activities

Senior Analyst & Senior Programmer

Kim Wandersee
David Ensign
Trish Fuchs

AOSS Sys. Engr. Svcs.

Configuration
Manager

TBD

TBD

Configuration Control Board

Brian Field
David Ensign
Trish Fuchs
Kim Wandersee
Other Members TBD

Oversight Activities
AOSS Sys. Eng. Svcs.

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

CITSS CMP					-	December 1997