Свежие записи

NOAA. Configuration Management Plan

GD Star Rating
GD Star Rating


National Environmental Satellite, Data, and Information Service (NESDIS)


National Environmental Satellite, Data, and Information Service (NESDIS)

Comprehensive Large Array-data

Stewardship System

Configuration Management Plan


February 1, 2005


Version Description of Version

Date Completed

0.1 Initial draft


1.0 Updated with QMO Review Comments – ready for CPMT review


1.0 Incorporated comments from CPMT – approved by CPMT


1.0 Cleanup non-printing characters


1.1 Updated to remove material documented in procedures


1.2 Incorporated QA review comments


1.3 Incorporated PM review comments – PM approved


1.4 Corrected section references – PM approved


1.5 Incorporated comments from SCE and new organization


1.6 Incorporated SEPG review comments


1.7 Added activities for ORR and data management, clarified requirements flow, corrected CM processes and procedures.


2.0 Approved by CPMT


Review & Approval

Project Plan Review History

Reviewer Version Reviewed Approval Date





Table of Contents

1 Introduction    1

1.1    Purpose    1

1.2    Scope    1

1.3    Applicable Documents    2

1.4    Acronyms    2

1.5    Definitions    3

2 Organization    5

2.1    Configuration Management Office    5

2.2    Configuration Control Board    5

2.3    Roles and Responsibilities    6

2.3.1    Responsibilities of the CCB    6

2.3.2    Responsibilities of the CCB Chair    6

2.3.3    Responsibilities of the Configuration Management Office (CMO)    7

2.3.4    Responsibilities of the CLASS System Engineer    7

2.3.5    Responsibilities of the CLASS Lead Integrator    7

2.3.6    Responsibilities of the NESDIS OSD Project Manager    7

2.3.7    Responsibilities of the CPMT    7

2.4    Tools    7

3 Configuration Control    9

3.1    Configuration Identification    9

3.2    Identification of Proposed Changes    9

3.3    Documentation of Proposed Changes    10

3.4    Evaluation of Proposed Changes    10

3.4.1    Processing Urgent Changes    11

3.5    Integration of Approved Changes    11

3.5.1    Requirement Baseline Changes    11

3.5.2    Production Baseline Changes    11

3.5.3    Process Baseline Changes    12

4 Document and Data Management    13

4.1    Identification    13

4.2    Document Management    13

4.3    Change Management    13

4.4    Data Management    13

4.4.1    Responsibilities    14

4.4.2    Data Acquistion    14

5 Configuration Status Accounting    16

5.1    Status Account Data    16

5.2    CLASS Configuration Management Database    16

6 Configuration Audits    17

6.1    CM Process Audits    17

6.2    CM Baseline Audit    17

6.3    Operational Readiness Reviews (ORR)    17



The purpose of this Configuration Management (CM) Plan is to provide an overview of the organization, activities, overall tasks, and objectives of Configuration Management for the Comprehensive Large Array-data Stewardship System (CLASS). It addresses configuration item (CI) identification, change control and configuration audits at a high level; additional details regarding CM activities, techniques, and tools are provided in the CM-related procedures (see CLASS Document Repository for the most current procedures). These procedures are listed in Section 1.3, and referenced where applicable in this document.


The CLASS project has established several levels of baseline, with appropriate levels of control for each, as summarized in the following table:



Control Level

Requirements System Requirements (CLASS requirements repository)

Allocated Requirements (CLASS requirements repository)

Detailed Requirements (approved Level III CCRs)




Production Operational software, hardware (including COTS) CCB
Process Documented processes, plans, and procedures CPMT
Test Integration environment

System Test environment

Deployment Test environment

System Integration & Test


Development Local development environment Local development team management

This document describes the CM approach for management of the Requirements, Production, and Process Baselines, which are controlled at the CLASS project level. The management and control of the Test baseline is described in the System Integration and Test Plan. The development environments are managed and controlled at the local level. The Configuration Management Office (CMO) maintains software baselines (development, integration, system test, and deployment test) for each release in the CLASS CM repository.

Changes to the Requirements and Production baselines are controlled by the CLASS Configuration Control Board (described in Section 2) via Configuration Change Requests (CCRs), Problem Reports (PRs), and Work Requests (WRs). Section 3 describes the CIs defined in these baselines and the process for managing changes to the CIs.

The Process baseline is controlled by the CPMT. Changes to CIs in this baseline are implemented via WRs, as described in the CLASS Process Baseline Management Procedure. Section 4 of this document describes CLASS document and data management.

The Integration and System Test baselines are controlled by System Integration and Test management, while the Deployment Test environment is controlled by CLASS CMO. Local development environments are controlled by site administrators.

Applicable Documents

The following related documents are stored in the CLASS Document Repository:

Document Number


Requirements Baseline
CLASS-1005-CLS-REQ-SRDOC System Requirements
CLASS-1017-CLS-REQ-AADS Archive, Access, and Distribution System Allocated Requirements
CLASS Process Baseline Plans
CLASS-1028-CLS-PLN-MPMP Master Project Management Plan
CLASS-1001-CLS-PLN-CM Configuration Management Plan
CLASS-1002-CLS-PRO-Guide Software Development Guide
CLASS-1006-CLS-PLN-QM Quality Management Plan
CLASS CM Procedures
CLASS-1000-CLS-PRO-DOCMT Document Management Procedure
CLASS-1024-CLS-PRO-CM Configuration Item Identification
CLASS-1025-CLS-PRO-CM Configuration Audits
CLASS-1026-CLS-PRO-CM Configuration Change Request
CLASS-1027-CLS-PRO-CM Database Configuration Management
CLASS-1029-CLS-PRO-CM Requirements Baseline Management
CLASS-1030-CLS-PRO-CM Process Baseline Document Management
CLASS-1031-CLS-PRO-CM Source Code Control
CLASS-1032-CLS-PRO-CM Software Change Promotion
CLASS-1034-CLS-PRO-CM Issues and Action Tracking
CLASS-1048-CLS-PRO-CM System Administration Change
CLASS-1056-CLS-PRO-CM Work Requests
CLASS-1064-CLS-PRO-CM Problem Reports
CM-Related Procedures
CLASS-1018-CLS-PRO-QM Peer Reviews
CLASS-1049-CLS-PRO-SIT Operational Readiness Review

The CLASS Document Control Numbers are maintained in the CLASS requirements repository, and a full list identifying the version and location of the current baseline documents is posted in CLASS Document Repository.


CCR        Configuration Change Request

CCB        Configuration Control Board

CI        Configuration Item

CLASS    Comprehensive Large Array-data Stewardship System

CM        Configuration Management

CMDB        Configuration Management Database

CMO        Configuration Management Office

COT        CLASS Operations Team

CPMT        CLASS Project Management Team

CSDPC    Central Satellite Data Processing Center

CVS        Concurrent Versions System

NCDC        National Climatic Data Center

NESDIS    National Environmental Satellite, Data, and Information Service

NGDC        National Geophysical Data Center

NOAA        National Oceanic and Atmospheric Administration

ORR        Operational Readiness Review

OSD        NOAA NESDIS Office of System Development

PR        Problem Report

QMO        Quality Management Office

SAA        Satellite Active Archive

SAT        System Administration Team

SEPG        Software Engineering Process Group (CLASS)

SET        System Engineering Team (CLASS)

TAL        Technical Area Lead

TBD        To Be Determined

TBW        To Be Written

WR        Work Request


Baseline                    A formal, approved document or product serving as a departure point for future releases. The CLASS baselines are described in Section 1.2 above.

CLASS Configuration Control Board        The board defining the disposition of Configuration Change Requests. The board is composed of CPMT members, SET members, and the CMO.

CLASS Oversight Group             A board consisting of representatives from each of NOAA’s data centers, who provide vision and overall direction for CLASS.

CLASS Project Management Team         The managing authority for the CLASS project. This team is defined in Section 2.

CLASS Systems Engineering Team        The technical advisory committee for CLASS. This team is defined in Section 2.

Configuration Change Request        A request for change to a baseline document or system.

Configuration Item                 An aggregation of hardware, software, or both, designated for configuration management and treated as a single entity in the configuration management process.

Level-I CCR                     A request for a change to the baselined CLASS System Requirements. A Level I CCR is directed from OSD.

Level-II CCR                    A request for change to the allocated requirements or interfaces. A Level II CCR is directed from the CPMT.

Level-III CCR                    A request for change to the Production baseline not requiring updates to the CLASS System or Allocated Requirements. This level of CCR constitutes a release-based change (discrepancy or enhancement) , as approved by the CLASS CCB.

Originator                    The person who submits a Configuration Change Request.

Problem Report                A request for a change submitted to the CLASS configuration management tool, documenting a problem identified during system integration and test.

Work Request                    A request for a changed submitted to the CLASS configuration management tool, documenting an activity that may be approved by the CLASS Technical Area Lead (TAL).


The CLASS project is being conducted in support of the mission of the National Environmental Satellite, Data, and Information Service (NESDIS) to acquire, archive, and disseminate environmental data. The development of CLASS is expected to be a long-term, evolutionary process, as current and new campaigns are incorporated into the CLASS architecture.

A distributed team including NOAA personnel at OSD, NCDC, and NGDC; and contractors in Suitland, MD, Fairmont, WV, and Boulder, CO, are developing the system. Development systems are located at the CSDPC site in Maryland, NGDC in Colorado, and the NCDC contractor site in Fairmont, WV. The integration system is located in Maryland. The system operates at both facilities in Suitland, MD, and the NCDC facility in Asheville, NC.

In such a distributed development environment, it is particularly important that changes to the baseline system be strictly controlled. This control is provided by the Configuration Management Office, described in Section 2.1, under the direction of the Configuration Control Board, described in Section 2.2.

Configuration Management Office

The Configuration Management Office (CMO) includes the personnel responsible for management of all components of the CLASS baselines: software, hardware, and documentation. The CMO manages changes to the CLASS Requirements and Production baselines with the review and approval of the CLASS Configuration Control Board (CCB).

The CMO includes the following roles:

  • Requirements Manager – responsible for maintenance and update of the CLASS requirements repository
  • Document Manager – responsible for tracking project documentation
  • Software Configuration Manager – responsible for tracking software components, and building and promoting software releases
  • System Administrator – responsible for tracking and maintenance of hardware components

Configuration Control Board

The CLASS Project Management Team (CPMT) is responsible for overall direction and coordination for CLASS. The Technical Area Lead (TAL) from each participating organization serves on the CPMT with NESDIS Office of Systems Development (OSD) project management leading the team. The NOAA CLASS Technical Lead has authority for technical decisions related to CLASS, while the NESDIS OSD Project Manager maintains Requirements Baseline direction, administrative and budget authority.

Similarly, each development team is represented on the CLASS System Engineering Team (SET). The SET oversees the technical direction of the development to ensure consistency and compatibility among the various components. The CLASS System Engineer and the CLASS Lead Integrator are members of the SET.

The CLASS CCB includes members of the CPMT, the SET, and the CMO. Figure 1 shows the organizations participating in CLASS development and represented on the CCB. This board reviews all CLASS configuration change requests (CCRs). The NOAA CLASS Technical Lead chairs the CCB, and has decision-making authority on the disposition of CCRs, with input from the other CCB members. The Configuration Change Request Procedure provides a detailed description of the CCR process.

Roles and Responsibilities

The major roles in configuration management activities are defined below.

Responsibilities of the CCB

  • Review all CCRs and provide the necessary input to determine the disposition, as described in Section 3.4 and in the CCR Procedure. If additional information is needed, assign the CCR to the appropriate group(s) for further analysis.
  • Assign approved CCRs to an implementation date and team.
  • Ensure action is taken on change requests in a timely fashion.

Responsibilities of the CCB Chair

  • Direct the CCB meetings.
  • Assign/approve disposition of each CCR, and implementation assignment for approved CCRs.
  • Manage escalation process when a CCR is referred for higher-level approval or input.
  • Ensure action is taken on change requests in a timely fashion.
  • Disposes recommendations from ORR on PRs to CCRs.
  • Disposes recommendations on release changes for identified CCRs.

Responsibilities of the Configuration Management Office (CMO)

  • Maintain the CLASS CM Plan.
  • Identify Configuration Items (CI) and document their characteristics.
  • Control and facilitate changes to the characteristics of a CI.
  • Perform audits to verify compliance with CLASS CM Plan.
  • Perform audits to verify release preparedness.
  • Manage the configuration management database.
  • Report to the CCB approval status of all proposed changes and implementation status of all approved changes.
  • Work with the CCB Chair and members to schedule regular CCB meetings, and prepare the agenda for each meeting.
  • Perform system builds and promotions.

Responsibilities of the CLASS System Engineer

With support from the SET, the CLASS System Engineer is responsible for the following:

  • Monitor development for technical integrity and consistency, and compliance with the system requirements and architecture.
  • Review change requests as they are received and provide technical assessment to the CCB.
  • Work with the CMO to ensure action is taken on change requests in a timely fashion.
  • Support the CCB in review and disposition of CCRs.
  • Review Problem Reports to resolve questions and priority.

Responsibilities of the CLASS Lead Integrator

  • Support the CCB in review and disposition of CCRs.
  • Lead system integration and test for each release.
  • Manage generation of CCRs from PRs as necessary.

Responsibilities of the NESDIS OSD Project Manager

  • Review and determine disposition of Level I CCRs (requested changes to the System Requirements) for presentation to the CCB.

Responsibilities of the CPMT

  • Review and determine disposition of Level II CCRs (requested changes to the Allocated Requirements) for presentation to the CCB.


The following tools are used to manage the CLASS baselines:

  • CLASS requirements repository – controlled repository for requirements (system and allocated); provides traceability between system and allocated requirements and between requirements and tests and releases; repository for document control data. The tool used for the requirements repository is DOORS.
  • CLASS configuration management repository – controlled repository for source code. The tool used for the configuration management repository is Concurrent Versions Control (CVS).
  • CLASS change management repository – repository for CCRs (track changes to the Requirements and Production baselines), PRs (track changes to the Test baseline), WRs (track changes to Process and Development baselines, and working documentation), and AIs (action tracking and disposition). The tool used for the change management repository is Remedy.
  • CLASS document repository – repository for CLASS process baseline and working documentation. The tool used for the document repository is KnowledgeTree.
  • CLASS online library – repository for CLASS design documentation. The intranet URL for this repository is: http://library.class.noaa.gov

Configuration Control

Configuration Control is the systematic proposal, justification, evaluation, coordination, approval or disapproval of proposed changes. Configuration control also includes the implementation of all approved changes to the baseline. The Configuration Control process includes: Identification of proposed changes, documentation of proposed changes, evaluation and disposition of proposed changes, and integration of approved changes. These processes are briefly described in the following paragraphs. The CCR Procedure provides the detailed workflow for managing changes to CLASS.

Configuration Identification

There are two CLASS baselines defining the deliverable system:

  • The Requirements baseline is maintained in the CLASS requirements repository; it defines the required functional, performance, and operational characteristics of the system.
  • The Production baseline includes the delivered software (custom application and third-party off-the-shelf (OTS) packages), hardware, data, and system documentation.

Configuration items (CIs) are the components of each baseline. All aspects of configuration management apply to these items

The CMO defines the CIs constituting the deliverable system. At the top level, CLASS is treated as a CI – changes are managed, tracked, and reported at the CLASS level. To provide greater visibility to the stability of the system and its components, the CMO defines lower level CIs such as subsystems, functional areas, hardware components, and, at the lowest level, individual code units. This allows version control and reporting at various levels within CLASS. The Configuration Management Database (CMDB), described in Section 5.2, maintains the key characteristics of each CI, as defined by the CMO (e.g., software unit version numbers, hardware model numbers, system release numbers).

The Configuration Item Identification Procedure defines the levels of controlled items, and the procedure and tools for tracking them.

Identification of Proposed Changes

Changes are permanent alterations to the established baseline (Requirements or Production). A change is proposed when a new requirement is received, an improvement is desired, or a problem requires solution. Changes may be requested by Government or contractor personnel.

Each change request is designated as either a Level I, Level II, or Level III Configuration Change Request (CCR). Requests for changes to the CLASS System Requirements document are classified as Level I CCRs. Requests requiring changes to the CLASS Allocated Requirements or CLASS interfaces are classified as Level II. All other changes (including software, hardware, and documentation) are classified as Level III CCRs.

An approved Level I CCR generally results in an update to the baselined System Requirements and is directed from the , and a Level II CCR to update the baselined Allocated Requirements to reflect a new or changed system requirement. Once the baselined Allocated Requirements are updated, one or more Level III CCRs may be generated to implement the change in the operational system based on recommendations included in the CCR. However, Level II requests may be submitted that do not relate to any Level I change as directed by the CPMT, and Level III changes may be requested that are not related to any requirements changes (e.g., discrepancies vs. enhancements). CCR-generated changes that affect documentation or plans include descriptions by the originator of the CCR discussing the impacts. As necessary, the originator of the CCR may be generated multiple CCRs to best describe a baseline change. Section 3.5 describes the implementation of approved changes.

Problems identified during system integration and test, and resolved prior to delivery of the system to operations, are handled by the development and test teams as Problem Reports, under the direction of the Lead Integrator (with CPMT oversight if necessary). The CLASS System Integration and Test Plan describes the management of PRs during testing. Problems identified during system integration and test not resolved prior to delivery become requests for changes to the Production baseline (i.e., the operational system), and are converted to Level 3 CCRs when the release is delivered, by decisions made in the Operational Readiness Review (ORR). These new CCRs are reviewed at the next CCB meeting, scheduled for implementation in future releases, and tracked in the same way as other CCRs.

Documentation of Proposed Changes

The CCR Procedure defines the form and workflow for documenting change requests to the system. For system administrative changes refer to the System Administration procedure to determine if a CCR or Work Request (WR) is required to document a proposed change. Errors found during system integration and test, generating changes to CLASS, will be documented on a Problem Report (PR) according to the Problem Reports procedure.

Evaluation of Proposed Changes

Each CCR submitted is directed to the CLASS System Engineer. The System Engineer reviews the CCR and works with the SET to classify it as a Level I, Level II, or Level III change, review or assign a priority, and provide an impact assessment (a rough estimate of the level of effort required for implementation, and impact to other current and planned activities). The System Engineer then notifies the CMO to schedule the CCR for CCB review.

A change priority is assigned to every change request when it is received, as defined in the CCR Procedure. The priority of a CCR is assigned either by the originator or by the System Engineer. The System Engineer has the authority to alter the priority of any CCR. A change required for operations as soon as possible, bypassing the regular release schedule, is assigned an Urgent priority. All changes, regardless of their priority, follow the same approval process, although Urgent CCRs are expedited as described below.

Upon receipt of a new change request, the CCB evaluates the change, contacts the originator of the change if needed, processes the request for a change, and recommends a schedule for implementation of approved changes. The CCB escalates Level I CCRs to the CLASS Archive Requirements Council (ARC) for disposition, since changes to the System Requirements require ARC approval. The detailed workflow for CCRs is defined in the Configuration Change Request Procedure.

Processing Urgent Changes

A CCR is assigned an Urgent priority when the originator or the System Engineer determines a delay in the implementation would impact operations or create software failures. Urgent CCRs are assigned to the System Integration and Test (SIT) TAL who will try to obtain approval out of board from the CCB within two hours. If the TAL is unable to contact the CCB members in a timely fashion, the SIT TAL is authorized to approve implementation of the request. This interim approval by the SIT TAL provides continuous operation of the system, often requiring an interim release. The CCR is formally presented at the next CCB meeting for disposition by the CCB Chair.

Integration of Approved Changes

The CMO supports the implementation of changes to the Requirements and Production baselines.

Requirement Baseline Changes

After the CCB approves a change to the Requirements Baseline (Level I or Level II CCR), the CCB may assign the change to an analysis team for implementation if the team has not first conducted the requirements review. The analysis team crafts the new requirements and submits them to the CPMT and stakeholders, as necessary, for review. After CCB approval of the new requirements, the Requirements Manager makes the appropriate changes to the Requirements Baseline. Once the Requirements Manager makes the changes and establishes the necessary traceability, the System Engineer verifies the change was correctly documented and the CMO closes the CCR. The Requirements Baseline Management Procedure provides details for this process.

Implementation for the new or changed requirement is tracked along with all other requirements. After the new requirement is approved and documented, the analysis team generates one or more Level III CCRs to implement the change. These CCRs are evaluated as described in Section 3.4, and implemented as described in Section 3.5.2, and in the CCR Procedure.

Production Baseline Changes

The CCB assigns each approved Level III CCR to an implementation date or release, and a functional group or subsystem when the CCR is approved. The assignment is reviewed by the CPMT during release planning to verify the scope of the release is acceptable and consistent with current priorities. The development teams implement the assigned CCRs, posting software updates into the source code control repository.

The Lead Integrator is responsible for verifying all scheduled changes are implemented, and for verifying the correct implementation of the changes. Software and database changes are promoted into the test environment after the CMO receives approval to proceed from the SIT TAL. Once the software and database changes are validated in the test environment, they are presented to the Operational Readiness Review (ORR), who determines when all required activities are completed to move the baseline into operations. Once this approval is made and appropriate audits are conducted, verified CCRs are assigned to the CLASS CMO, who is responsible for ensuring all change requests assigned to a software release are promoted into the operational system.

After the CMO has promoted the changes to the operational environment and verified the changes are functioning correctly in that environment, the CMO closes the CCR.

Details of the process for implementing changes to the Production Baseline are provided in the Source Code Control Procedure, the CLASS Database Configuration Management Procedure, the CCR Procedure, and the Software Change Promotion Procedure.

Process Baseline Changes

Changes proposed to the CLASS process baseline (plans and procedures) are documented on Work Request forms in the CLASS change management repository. The originator documents the proposed change and receives approval from the site TAL to proceed. Changes to the process baseline are reviewed by the SEPG membership, and then forwarded to the CPMT only when a recommended disposition is for approval.

Changes proposed to baselined documentation that affects the system are documented on a CCR and submitted to the CCB for review and approval before proceeding.

Document and Data Management

This section presents document and data management on CLASS.


Configuration items are described according to the CLASS Configuration Item Identification procedure.

Document Management

The primary repository for CLASS documents, reports, and other supporting assets for the project (i.e., data and documentation not part of the Requirements or Production baseline) is the CLASS Document Repository.

The CLASS Process Baseline consists of the plans and procedures posted under the CLASS Baseline Documentation folder. The CLASS SEPG is responsible for development and maintenance of the process baseline, with approval by the CPMT. The detailed procedure for baseline document changes is documented in the Process Baseline Management Procedure.

Individual CLASS personnel retain hardcopy assets. As needed, the CMO retains hardcopy assets in a central location. Specific electronic assets selected for their privacy, e.g., financial or earned value reporting, may be retained in discrete electronic libraries outside of the CLASS Document Repository. Each site is responsible for identifying and controlling these assets.

Other documentation on the project is working documentation that is not part of the deliverable system, and is therefore not included in baselines. This documentation, however, also needs to be managed and controlled to ensure changes are made in an organized manner and the current version is always known and available. Examples of such items are design documentation maintained by the SET, and local plans, policies, procedures, and reports. This documentation is tracked in the CLASS configuration management tool, as described in the Document Management Procedure, and managed by the owning team or organization.

Change Management

Version numbers are assigned by the originator and verified as needed, by the CMO. Version numbers are included in hardcopy assets and managed through the CMO. Entries are maintained in an online catalog.

Data Management

Data management is the discipline of identifying, scheduling, coordinating, validating, integrating, and controlling project data. Data management includes the timely and economically feasible acquisition of data, ensuring the adequacy of acquired data for its intended use, and managing data after its receipt.


The CMO is responsible for managing contract data. Data management includes:

  • Identifying, collecting, logging, and controlling project documents, records, and correspondence
  • Establishing and administering project libraries
  • Maintaining the project’s configuration management records
  • Ensuring a historical log of all changes integrated into software support libraries subject to project-level configuration control is conducted
  • Maintain the system development library under CM version and access control
  • Maintain records management

Data Acquisition

The CMO will ensure that CLASS-related data will be inventoried, categorized, and provided configuration identification according to the CLASS Configuration Item Identification procedure. The CMO will ensure that all critical project documentation, including system-related and project-specific assets will be identified.

All identified information will be retained in explicit CM-controlled repositories. Throughout all phases of CLASS, all acquired data, including all revisions to this information, will be maintained and controlled. The CMO will manage data based on the source and format depicted in the following table.



Action Item Management Remedy
Risk Management KnowledgeTree and CPMT
Control Records – CCR/WR/PR Remedy
Design Documentation CLASS Online Library
Documentation Control (assigned document control numbers)

  • Plans
  • Procedures
  • Concept of Operations
  • Guides
  • Requirements Reports and Documents
  • Charters
  • Design Documents
  • Studies
  • Interface Control Documents
Financial and Contractual Refer to site Activity Plans
Intergroup Assets KnowledgeTree
Electronic Project Documentation (storage)

  • Plans
  • Procedures
  • Technical Reference
  • Meeting Documentation
Measurements KnowledgeTree
Quality Records Lotus Notes, KnowledgeTree
Requirements DOORS
Software Files, Runtime Files Concurrent Versions System (CVS)
System Descriptions CLASS Online Library
Weekly and Monthly Status Reports Refer to site Activity Plan
Project Schedules Refer to site Activity Plan

Configuration Status Accounting

Configuration Status Accounting includes the collection, processing, maintaining and publishing data necessary to effectively manage the configuration.

Status Account Data

The CMO collects data necessary to produce reports useful to the CPMT, CCB, and Lead Integrator.

For change management, the CMO collects identifying information pertaining to each CCR received and its status in the CCR database, as defined in the CCR Procedure. The CMO prepares defined reports that are available online through the change management tool, in addition to the ad hoc reporting capability of the tool. The System Engineer works with the SET to prepare an assessment report on new CCRs for each CCB meeting. The assessment reports are posted in the CCB area of CLASS Document Repository along with the agendas and minutes from the CCB meetings.

For configuration item status, the CMO collects identifying information pertaining to each controlled configuration item, i.e. current revision, revision history, associated subsystem. At the end of each release, the configuration items are updated as defined in the Configuration Item Identification Procedure. The CMO prepares reports as requested on CI status, detailing new change requests, newly approved change requests, and closed change requests. Release reports are prepared by the CMO for input into release measurement reports.

CLASS Configuration Management Database

The CLASS configuration management database contains detailed information about every CLASS configuration item; it is used for status reporting as well as for moving new CLASS software releases to operations. The CMO is responsible for maintaining, supporting and updating the CLASS configuration management database.

Configuration Audits

Configuration audits consist of reviews where the CM process or a product configuration is compared to requirements to determine if those requirements are being met.

CM Process Audits

Process audits confirm the CM process is being followed. These audits focus on the processes being used rather than on the products being produced. They examine the manner in which the CM activities are performed against the documented procedures. The quality management office (QMO) conducts these audits on a regular basis during the course of the project to allow for problem identification and corrective action.

CM Baseline Audit

The CMO works with the Lead Integrator and the QMO to conduct a baseline audit for each release, as described in the CLASS CM Audits Procedure. This baseline audit verifies the release contents are complete, and all changes to be promoted to operations have been verified by the independent test team.

Operational Readiness Reviews (ORR)

The CMO works with Systems Integration and Test to participate in release Operational Readiness Reviews. The participation of the ORR includes CPMT, CLASS Operational Team (COT), CCB, QMO, and CMO members. The ORR membership determines the status of release activities and the approval when a release will be moved into the operational environment.

Связные и просто интересные записи:

Метки:activity, architect, change, chart, CM, configuration, it, loc, management, ms, package, plan, process, project, rational, req, request, software, tools

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Spam protection by WP Captcha-Free