A typical procedure for handling Change Requests is shown in the following activity diagram. (Click anywhere on the diagram to go to a complete description of Concept: Change Request Management)

Sample Tasks for Managing CRs 

Complete Change Request Form

The Change Request Form is a formally submitted artifact that is used to track all requests (including new features, enhancement requests, defects, changed requirements, etc.). This should include related status information throughout the project lifecycle. All change history will be maintained with the CR, including all state changes along with dates and reasons for the change. This information will be available for any repeat reviews and for final closing. An example Change Request Form is provided in Work Product: Change Requests.

Typical states that a Change Request may pass through are shown in the following state diagram. (Click anywhere on the diagram to go to a complete description of Concept: Change Request Management)

Sample States and Transitions for a CR

Analyze the Change Request

Once a Change Request is submitted, it is analyzed to ensure that it is indeed valid, and that appropriate technical and management staff get to review to the Change Request to assess its validity. Change Requests need to be reviewed at various levels within the development team. A team leader will often review and approve Change Requests submitted by any of his staff. If, however, the scope of a change is beyond the responsibilities of the team it is escalated for the next level of review. If the impact of the change spans several different development teams, it is reviewed by the Change Control Board. In the Rational Unified Process, the Change Control Manager role is used to represent the role of the Change Control Board (CCB).

Occasionally, a reported system malfunction may be due more to its usage rather than being linked to system implementation. It might also be the case that the 'problem' has already been reported and is being addressed.

The outcome of the analysis step is either to accept the Change Request or to reject it on the basis that it is invalid, duplicate or 'out of scope' given the current project vision or mandate.

Assess Cost of Change Request

For valid changes, the next step is to assess and cost the change based on the impact it has on the overall system, and how easily it can be implemented.

Input from the costing step is provided to the CCB for assessment. The CCB reviews the Change Request and its impact from a strategic, organizational as well as the technical point of view. The CCB has to decide whether the Change Request can be economically justified.

Apply the Change Request

Once a Change Request has been approved it can be applied to the software. The revised software then undergoes quality assurance checks to make sure that changes were made in accordance with project adopted practices, and that it does not adversely affect other parts of the existing software.

Once the changes have been made the new version of the software is verified in a test build of the product and then incorporated into and verified in a 'release' version of the overall software.

Maintain the Change History

As software changes are made, it is important that a record of all of the changes is maintained.

An effective way to maintain a change history is at the beginning of each software component, and within the change requests.

An example of the kind of change data to maintain in a component header could be the following:

Modification History

Version Modifier Date Change Reason

1.1 Bruce Bogtrotter 98.05.01 Test Ranges CR#232

1.2 Maria Mussolini 98.06.02 Requirements CR#454

The CCB meets on a regular, and as required basis.

The basic tasks of the CCB are to declare product baselines, and review changes to the baseline, and approve, disapprove, or defer their implementation.

Select Members

The purpose of this step is to set up a CCB that consists of the 'right people' with real authority amongst their peers, and sufficient expertise to avert unwise or costly change proposals. The CCB needs to be composed of representatives from all affected organizations or stakeholders such as:

• Users
• Developers
• Test Group
• Project Management

Appoint CCB Chair

The chair of the CCB must be from the Project Management office. The chair should be able to unambiguously resolve conflicts within the team, and enforce the team's decisions on the project.

Decisions by the CCB should be reached by consensus whenever possible. The group dynamic reflects the cooperative nature of the development project. The role of the chair is to nurture this cooperative vision, and take unilateral action if necessary.

Meet to Assess Change Proposals

The CCB must meet on a regular, and an as required, basis to ensure that Change Proposals are reviewed and dispositioned in a timely manner. The development team must see this group as a reliable body for the resolution of issues that could otherwise deadlock progress on the project.

Input to this step is the list of work products to be developed during the course of the project.

Members of staff need to review product related work products to decide on whether they meet defined project quality standards to be passed on to the next stage of development. If a product fails a review, it is subject to re-work, change and re-review.

For a review to be 'effective' the product has to be assessed by the right people who understand the scope and impact of a proposed change or enhancement. Furthermore, reviews need to be 'cost effective' such that staff time of key implementers and integrators is not being wasted on yielding 'low impact' defects.

Members of staff who need to be involved in a review are representatives from the 'product' producer, recipient and management sides. This is to ensure that all stakeholders with a vested interest in the product quality can decide on whether the product can progress to the next level of development.

In team environment, the overall project is broken down into activities. Activities are allocated to responsible individuals for implementation and integration. For example, the overall system is divided into subsystems, and then into individual packages. Team members responsible for implementing a package need to be sure that their changes are reviewed by peers within the subsystem, and anyone else in other subsystems who may be impacted by the changes.

The review and change notification principle is to communicate to peers and team leaders, and recipients of the proposed changes, and to give them an opportunity to review and comment on the proposals.

Further guidance on this subject is provided in Concept: Change Request Management.