The purpose of this workflow detail is to establish an appropriate plan for managing and controlling change to the artifacts that are developed as work products of the software development process.


Topics

Configuration Management Plan Write CM Plan Establish CM Policies Establish Change COntrol Process Change Control Manager Configuration Manager


Description To top of page

The workflow detail focuses on:

  • Establishing project configuration management policies
  • Establishing policies and processes for controlling product change
  • Documenting this information in the Configuration Management Plan (included in Software Development Plan)

CM policies refer to the ability to identify, safeguard and report on the artifacts that have been approved for use in a project. Identification is simplified and enabled through the use of proper tools to control project artifacts, and the systematic labeling of those artifacts over time to identify their relative maturity and their relationships with each other at given points in time. Systematic identification practices are a key enabler for the safeguarding of project artifacts through archiving and baselining techniques.

Standard, documented change control processes help to ensure that changes are made within a project in a consistent manner, and the appropriate stakeholders are informed of the current state of the product, requested changes to it and the impact of these changes on cost, schedule and so forth.

The CM Plan documents how product related CM activities are to be planned, implemented controlled and organized.

Related Information To top of page

This section provides links to additional information related to this workflow detail.

Timing To top of page

This work is primarily performed in the first iterations in each phase. While most important in the Construction and Transition phases, this work may be important in the Elaboration and even Inception phase, depending on project culture.

Optionality To top of page

This work is not considered optional, although it will differ in format, style and level of ceremony to suit the project context. Note also that the rigidity and formality of the change process tend to change increase over the life of the project, typically becoming most formal and rigid in the Transition phase.

How to Staff To top of page

A person playing the Configuration Manager role needs to be organized by nature, yet flexible enough to plan configuration and change control to suit the needs of the project team. The Configuration Manager role supports the team by ensuring that the project change policies are reflected within the projects change management tools, enabling software developers to easily transition artifacts through state changes in accordance with the defined development and approval practices. The Configuration Manager role is required to put measures in place to monitor that the CM Plan is being followed as intended, that audit reporting is occurring on a regular basis, and to work with the System Administrator role to ensure that backups of CM assets are in safekeeping (e.g. fireproof safe for backup sets on-site, weekly backup sets stored off-site).

The Change Control Manager is a key arbitration role. In this capacity, the decision for the inclusion of any given change in a software build is ultimately made by the Change Control Manager on a project. In practice, only those changes of significant potential impact typically warrant monitoring, and any potential impact on the inclusion-or exclusion-of changes to the product should be carefully considered with regard to project factors such as the political climate, the need to establish trust between developer and customer and so forth.

Work Guidelines To top of page

See the Related Information section for additional guidance that will help you in performing this work.



Rational Unified Process   2003.06.13