1

Identify Team Project Configuration Management Objectives

• The objectives can simply state that the team project will meet the company’s configuration management standards or they may be unique to the team project. For example, a partnering relationship may require stricter configuration management practices than normally used. Or maybe the components required for a specific project may dictate special configuration management practices. Possibly the team project is setting new levels of configuration management standards for the company.

2

Describe Roles and Responsibilities

• Identify the roles and skill sets required to perform the configuration management related activities. Some roles, such as the release manager and the change control manager, are dedicated to configuration management activities. Other roles, such as developers, must have sufficient configuration management skills to identify, submit and retrieve configuration items. Identify who can create baselines and who can approve changes to baselines. Identify who is responsible for creating and distributing reports. Identify who is responsible for auditing the configuration management process.

3

Describe Tools, Procedures, and Supporting Infrastructure

• Identify the components of the configuration management system including hardware, software tools, and paper procedures. Consider any unique needs for the team project. Large projects generally require good coordination of version control, monitoring of database size, and avoidance of access bottlenecks. Secure projects generally require controled access to the repository. A team project that is spread across distributed work sites needs to share work products in a safe manner.

4

Identify Configuration Items

• Identify the configuration items, components, and related work products that will be placed under configuration management.<Ref: CMMI> Provide clear guidelines about which kinds of work products are configuration items, and which are not. For example, source files and any transformation tools are configuration items. Intermediate files such as object files are not. Candidates for identification include documents (such as plans and designs), code, tools (such as compilers), and any other items that are used in creating and describing the work products. <Ref: CMMI>

5

Describe Configuration Item and Baseline Identification Scheme

• Define the method of uniquely identifying every configuration item and each baseline. The scheme must include every type of configuration item comprising the project including hardware, and off-the-shelf products

6

Describe Baselining Strategy

• Define what is included in baselines. Will only one system baseline be used or are some components complex enough to warrant their own baselines? Describe how component baselines are integrated into a system baseline. Determine if the system baseline contains each individual configuration item or if it is an aggregation of the component baselines.

7

Identify Baselines

• Identify different types of baselines to be used such as:
• Functional baseline. Created independent of project milestones in order to capture a specific level of functionality. This is useful for a variety of reasons such as splitting concurrent work or capturing a desirable level of behavior.
• Development baseline. Created to allow developers to get back in sync after a pre-determined amount of code has changed, especially interfaces. The baseline does not necessarily have to be functional.
• Review baseline. Created to allow inspection and analysis of changes made since a previous baseline. Use this to determine things like level of churn or quality of submissions.
• Release baseline. Created to capture the state of the product for a specific external release. Final test and bug fixing would have occurred against a previous, release-candidate baseline.
• Identify which level of control and configuration management policies apply to each type of baseline. Presumably, a release baseline will require much tighter control than a development baseline

8

Describe Change Control Process

• Define the process used to make changes to a baseline. The process steps include submitting a change request, reviewing and approving the request, and delivering the changed code into a build. The level of control demanded by the process will vary depending on the maturity of the configuration item. Early development can be loosely controlled, while later functional and review baselines should be more tightly controlled.

9

Describe Configuration Data Safe-keeping Processes

• Define the approach to safe guarding the configuration management servers. Include reliance on and descriptions of mechanisms such as uninterruptible power supplies, periodic backups, and off-site storage. Typically both disaster recovery and data security must be considered. The disaster recovery plan should be tested before it is actually put into use.

10

Describe Configuration Item Release Processes

• Define the steps required to release a configuration item from the configuration management system for each type. The word "release" in this sense indicates that a set of criteria is met and a consumer may begin to use the configuration item. Some situations include:
• Distributing review material. The configuration item must be at a specific maturity level and must remain stable until the review and resulting actions are finished; wholesale changes to the item before this would invalidate the review.
• Releasing a component to system integration or test team. The component must be at a specific functional and quality level.
• Releasing the product for external general availability. All development, verification and quality assurance activities must be complete, reviewed and signed off.

11

Describe Configuration Management Audit Plan

• Identify the number and types of audits to perform. Audits are used to ensure completeness of the baseline in that all necessary configuration items are included, and traceability in that configuration management records exist to describe all changes to the baseline.For each type of audit, specify:
• Purpose. For example, the purpose can be an intermediate integrity check, policy adherence monitoring, or a final and complete inspection.
• Baseline criteria.
• What will be audited.
• What actions all roles have to perform to make the audit successful.

12

Describe Configuration Management Status Reports

• Define the types and frequencies of reports that must be extracted from the configuration management system. In general, the roles drive the report content:
• Project managers. They must monitor the progress and state of the development activities.
• Change control managers. They must monitor that only approved changes are made.
• Development managers. They must monitor progress and code churn.
• Quality assurance managers. They must monitor process adherence and configuration item maturity.
• Developers and testers. They must be aware of when baseline changes are coming and what the impact will be.

13

Describe Configuration Management Milestones

• Describe the relation between the configuration management milestones and the software development milestones. Creating baselines and auditing baseline integrity are essential to achieving the software development activities. The configuration management activities must be fully integrated with the software development activities.

14

Describe Configuration Management Training Plan

• Describe the training necessary to give all direct and indirect participants the configuration management skills necessary to perform the roles identified in configuration management plan.

15

Review Configuration Management Plan

• Document all decisions in the configuration management plan and submit it for review to the project management team. Capture any feedback in the plan.

The configuration management plan has been reviewed and approved by the project management team.