National Environmental Satellite, Data, and Information Service (NESDIS)
National Environmental Satellite, Data, and Information Service (NESDIS)
Comprehensive Large Array-data
February 1, 2005
|Version||Description of Version||
|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
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:
|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|
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.
The following related documents are stored in the CLASS Document Repository:
|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-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-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 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.
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.
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.
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 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
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)
|Financial and Contractual||Refer to site Activity Plans|
|Electronic Project Documentation (storage)
|Quality Records||Lotus Notes, KnowledgeTree|
|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 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.