Table of Contents | Appendix C-6 | Appendix C-8
1.0 INTRODUCTION
Provide a brief statement that introduces the Configuration Management (CM) plan and describes, in general terms, its use in managing the configuration of the specific project, or system. Configuration Management is a uniform practice for managing system software, hardware and documetnation changes throughout the development project.
1.1 Purpose
Describe why this CM plan was created, what it accomplishes, and how it is used.
1.2 Scope
Define the scope of CM planning. Identify items that will be placed under configuration control.
1.3 System Description
Briefly describe the system, its history, and the environment in which the project operates (mainframe, client/server, or stand alone). Describe the system architecture, operating system, and application languages. Identify other legacy or new systems with which this system interfaces. List the number of sites that are using the system.
1.4 Definitions
Define the terms that appear in the CM plan.
1.5 Reference Documents
List the documents that are referenced to support the CM process including any project or standards documents referenced in the body of the CM plan.
2.0 ORGANIZATION
Identify the organization in which CM resides and all organization units that participate in the project. Define the functional roles of these organizational units within the project structure. Describe any Internal Review Boards and Configuration Control Boards that will be established for the project. For each board, discuss the members who will participate (and their functional representatives), the Chair, the Secretariat, and the responsibilities of the board and of each member to the board.
2.1 CM Activities
Identify all CM functions required to manage the configuration of the system.
2.2 CM Responsibilities
List CM responsibilities in supporting this project.
3.0 CONFIGURATION IDENTIFICATION
Explain that Configuration Identification is the basis on which the configuration items (CIs) are defined and verified; CIs and documents are labeled; changes are managed; and accountability is maintained. Define the automated tools that will be used to track and control the configuration baselines. Describe the methods for controlling, tracking, implementing and reporting changes.
3.1 Configuration Item Identification
Identify the CIs to be controlled and specify a means of identifying changes to the CIs and related baselines. At a minimum, the system itself, all COTS software and hardware for the system (or application) to function, and any support software developed in-house or by contractor should be a CI.
3.2 Identification Conventions
Describe the identification (numbering) criteria for the software and hardware structure, and for each document or document set.
3.3 Naming Conventions
Provide details of the file naming convention to be used on the project and how file configuration integrity will be maintained.
3.4 Labels
Describe the requirements for labeling media and application software.
3.5 Configuration Baseline Management
Describe what baselines are to be established. Explain when and how they will be defined and controlled. A configuration baseline document includes both SDLC documents and any other user support documents subject to change when the project changes. The standard baselines are functional baseline (FBL), which describes the system functional characteristics; allocated baseline (ABL), which describes the design of the functional and interface characteristics, and product baseline (PBL), which consists of completed and accepted system components and documentation that identifies these products.
4.0 CONFIGURATION CONTROL
Explain that configuration change management is a process for managing configuration changes and variances in configurations. Configuration control is the systematic proposal, justification, evaluation, coordination, approval and implementation of changes after formal establishment of a configuration baseline.
4.1 Change Management
Define the process for controlling changes to the system baselines and for tracking the implementation of those changes. Usually a system change request (SCR) is used to provide information concerning the need to change a baseline system or system component (hardware, software, or documentation).
4.2 Interface Management
Identify the interfaces to be managed and describe the procedures for identification of interface requirements, establishment of interface agreements, and participation in any Interface Control Working Groups.
5.0 CONFIGURATION STATUS ACCOUNTING
Explain that Configuration Status Accounting (CSA) is the process to record, store, maintain, coordinate and report the status of CIs throughout the system life. All software and related documentation should be carefully tracked from initial development to request for change, through the approval or disapproval of changes, to the implementation of changes.
6.0 CONFIGURATION AUDITS
Describe how peer review audits and formal audits will be accomplished for the purpose of assessing compliance with the CM Plan. These could include baseline audit, functional configuration audit, physical configuration audit, software and hardware physical configuration audit, and subcontractor configuration audits. .
7.0 REVIEWS
Describe how the technical reviews relate to the establishment of baselines and explain the role of CM in these reviews.
8.0 CM PLAN MAINTENANCE
Describe the activities and responsibilities necessary to ensure continued CM planning during the life cycle of the project. State who is responsible for monitoring the CM plan. Describe how frequently updates are to be performed; how changes to the CM plan are to be evaluated and approved; and how changes to the CM plan are to be made and communicated.
9.0 DATA MANAGEMENT
9.1 Libraries.
Identify the libraries and the media under control, the requirements for the control of documentation, and how access control is to be managed.
9.2 Automated Tools
Describe any automated tools used.
9.3 Version Control
Describe the processes in place to control the amount and number of versions documented by this CM Plan.
9.4 Work Space Management
Describe the processes used for automated software source case control tools.
9.5 Build Management
Describe the controls in place to manage the building of executable code.
9.6 Documentation Management
Describe the processes in place for documentation management and who is responsible for them.
10.0 SUBCONTRACTOR CONTROL
Subcontractors will be required to meet the CM requirements that have been levied by the plan on the contractor. The requirements for the subcontractor may be modified to fit the scope and magnitude of the subcontract task. A complete CM plan should be required of the subcontractor if an extensive contract is envisioned. If the contract is minor in content a plan should not be requested. However, provisions must be made for continuous communication and monitoring of CM activities, review and disposition of subcontractor supplied documents and subsequent changes, and the final audits. Subcontractors will provide status accounting reports reflecting the development of software, hardware, and COTS Configuration Item data.
Configuration Management Plan Outline
Cover Page
Approval/Signatures
Change History Page
Table of Contents
1.0 INTRODUCTION
1.1 Purpose
1.2 Scope
1.3 System
Description
1.4 Definitions
1.5 Reference
Documents
2.0 ORGANIZATION
2.1 Configuration
Management Activities
2.2 Configuration
Management Responsibilities
3.0 CONFIGURATION
IDENTIFICATION
3.1 Configuration
Item Identification
3.2 Identification
Conventions
3.3 Naming
Conventions
3.4 Labels
3.5 Configuration
Baseline Management
4.0 CONFIGURATION
CONTROL
4.1 Change
Management
4.2 Interface
Management
5.0 CONFIGURATION STATUS ACCOUNTING
6.0 CONFIGURATION AUDITS
7.0 REVIEWS
8.0 CONFIGURATION PLAN MAINTENANCE
9.0 DATA
MANAGEMENT
9.1 Libraries
9.2 Automated
Tools
9.3 Version
Control
9.4 Work
Space Management
9.5 Build
Management
9.6 Documentation
Management
10.0 SUBCONTRACTOR CONTROL