CMMI and Configuration Management

Configuration Management is a discipline that is unique to the business of developing software so is not specifically addressed anywhere in the PMBOK®. The purpose of this article is to offer suggestions on how this discipline can be incorporated into your project management plans for a software development project with the least amount of disruption. Although none of the elements of configuration management are directly addressed in the PMBOK®you’ll find that developing a software application of any size is impossible without some elements of configuration management. The source library used to version and release the software is a good example. CMM also specifies that the purpose of configuration management is to maintain the integrity of the software throughout the project’s software life cycle. Configuration management will benefit the organization throughout the entire life cycle of the software product, lasting well beyond the end of the project which introduces it.

Beyond helping in the CMM/CMMI certification process, adhering to the criteria set for level 2 certification in the area of configuration management will benefit your software project and also benefit future projects as well as help the support organization maintain the software products produced. The areas discussed in this series previously (requirements management, project planning, project tracking and oversight,subcontract management, and quality assurance) all align with some knowledge area from the PMBOK so compliance with those criteria should not add significantly to the project scope. The activities required to comply with CMM/CMMI criteria in this area might add significant overhead to your project. You should compare the needs of the project for configuration management work against the work required to meet CMM/CMMI level 2 criteria, identify the work and tools required to address the delta and ensure that your project is adequately funded and resourced to undertake the additional work.

As with the other Key Process Areas (KPAs), Software Configuration Management is organized into goals, commitments, abilities, activities, measurements, and verifications.

Goals

1. Software configuration management activities are planned.
2. Software products under configuration management are identified, controlled, and available.
3. Changes to identified products are controlled.
4. Affected groups and individuals are informed of the status and content of software baselines.

These goals will all align well with a well managed software development project. Configuration management work, like all the work of the project is planned, staffed, and scheduled, changes are controlled by the Integrated Change Control System and the content of baselines is communicated to the stakeholders in accordance with the Communications Management plan. Keep in mind that the context in which CMM/CMMI uses the term change control is specific to the software products under management and will require a tool to manage version control.

Commitment to Perform

Commitment is demonstrated by the written organizational policy for software configuration management (SCM). This policy must state who is responsible for SCM, how SCM is implemented through each project life cycle, a source library tool is used, and that baselines are established and regularly audited. The policy will be up to the organization to define unless it is specified in the scope for your project.

Ability to Perform

Ability to perform is demonstrated by the establishment of a Software Configuration Control Board (SCCB) and a Software Configuration Management (SCM) group. The SCCB is responsible for establishing software baselines, authorizing changes to the baselines, and releasing the software. The SCM group is responsible for the implementation and management of the source library and all SCM processes, procedures, standards, and plans. In addition to the implementation of these 2 groups, the organization is responsible for providing resources and funding for their activities and for training the SCCB, SCM group, and the software engineering group in SCM activities.

The creation of the SCCB, SCM group, and all the processes, procedures, plans and standards called for here will be in addition to work required to establish a source library tool and a librarian which are minimal needs for the average software project. These groups and documentation will take considerable work to implement and should be specified as part of the project scope if they are to be undertaken.

Activities Performed

1. An SCM plan is prepared for the project (and for every project) in accordance with a documented procedure. This plan will be part of the project plan and will be used as part of that plan to control SCM activities for the project.
2. A source library system is established.The criteria CMM/CMMI has for the library are pretty much what any good tool will offer, with these possible exceptions: that it support archival and recovery of configuration items and that it store SCM records and create SCM reports.
3. The software work products to be placed under configuration management are identified. "Software work products” include such ancillary items as Business Requirements Documents, Functional Specifications, Detail Design Documents, test plans, etc. Identification also includes a unique identifier for each item (this will be enforced by the library tool), the baseline it belongs to, and the owner (developer, analyst, or tester).
4. Change requests and bug reports are recorded, reviewed, decided upon, and tracked according to a documented procedure. The Integrated Change Control System has overall responsibility for managing changes to the project, including configurable items, and the system should be described in your Change Management plan.
5. Changes to baselines are controlled according to a documented procedure. The procedure should ensure that software is properly tested when it is changed, the SCCB approves changes to configurable items, and that check-outs and check-ins are performed properly (i.e. controlled by the source library). The procedure should also identify a change request or bug report with each change or fix. One way of facilitating this activity is by integrating your SCCB and Integrated Change Control Boards (ICCB).
6. Products from the source library are created and their release is controlled by a documented procedure. The procedure referred to here is the build process. The librarian or build master should have a documented procedure which they follow to build and release a product. The procedure should include such things as when and how the library is frozen, how a build is authorized (by the SCCB), and when builds are to occur.
7. The status of configurable items is recorded according to a documented procedure. This means that the source library tool is capable of reporting the current version of each item, retrieving archived versions, and the composition of each release is known (the items included and the version of each item). The source library tool should also be capable of reporting on the reason for each new version/update. Reasons will include new features, approved changes, and bug fixes.
8. Standard reports on SCM activities, baseline contents, etc. are developed and made available to all affected groups. The reports referred to are non-technical and include such information as change requests, bug reports, as well as summary reports of changes to each baseline and audit results. These reports should be described in your Communications Management plan.
9. Software baseline audits are conducted according to a documented procedure. The audits should include assessments of baseline integrity, source library structure, baseline contents (for completeness and correctness), and SCM standards and procedures compliance. The audit results must be reported to the project manager and audit points tracked to closure. Audits should be conducted by an external body but if the identification of this body is an issue; make the SCCB responsible for the audit.

Measurement and Analysis

You are required to measure your SCM activities. The measurements include progress to plan for configuration management activities, performance to budget for these items, as well as metrics for change requests. By assigning the various team members working on SCM or SCCB activities to an SCM or SCCB group you will facilitate using your MS Project file to report on only those activities. By dividing the work in the MS Project file into different areas including one for software development, and identifying change requests with the area they effect you can isolate SCM related changes and report on those.

Verification and Implementation

SCM activities should be reviewed by senior management periodically. For the purposes of the project these reviews can occur at Gate Review meetings or Steering Committee meetings, or in separate meetings scheduled for the purpose. SCM activities should also be reviewed with the project manager. This criterion will be met if you organize these meetings and are in attendance. The SCM group periodically audits software baselines to verify content and correctness. It is unclear to me exactly what the difference is between this audit and the one described in Activity #9, other than who performs the audit. Verification also calls for the SQA group to review and/or audit the work products and report the results. The SQA audit should assess the adherence of the SCM, SCCB, software engineering group, and testers to the SCM procedures and standards.

A great deal of the criteria for CMM/CMMI Level 2 certification will be met by a project manager following best practices for software development projects. There is no better way that I know of to demonstrate a grasp of project management best practices than certification as a Project Management Professional (PMP®). Project managers who meet PMI’s criteria can attain the certification by taking a PMP® Course or similar PMP® Exam preparation training and then writing the certification exam. Criteria that fall outside the realm of project best practices have been identified here and should for part of your project plan.