Changes to
development artifacts are proposed through Change Requests (CRs). Change
Requests are used to document and track defects, enhancement requests and
any other type of request for a change to the product. The benefit of CRs is that they provide a record of
decisions and, due to their
assessment process, ensure that change impacts are understood across the
project.
Role:
Change Control Manager is responsible for Change Requests.
The Word template can be bought through a template package. Case studies and reports are freely available in the table below.
Word Template
Case Study
Report
---
Purpose
The necessity for change seems to be inherent in evolving and existing
software systems. The Change Control Manager
is responsible for defining Change
Request Management procedures and maintaining CRs, ensuring
that changes to a system are made in a controlled way so that their effect on
the system can be predicted. CRs may be used to document and track
all types of requests for changes to the system, including enhancement requests
and defects.
Enhancement requests are used by the Analyst to determine future features to include in the product. These will
be used as input when collecting Stakeholder Requests
in order to Understand the Problem.
A defect is an anomaly, or flaw, in a delivered work
product. Defects include such things as omissions and imperfections found during
early lifecycle phases, and or symptoms (flaws) of faults contained in software
that is sufficiently mature for test and operation. Defects may also include
deviations from expectation or any kind of issue that needs to be tracked and
resolved.
The purpose of a defect is to communicate the details of the issue, enabling
corrective action, resolution, and tracking to occur. The following people use
the CRs:
The Analyst uses CRs identified as Enhancement Requests for determining new
features of the product.
The Project Manager uses CRs
to assign work.
The Testers use CRs to identify and
describe defects found in testing; and to plan test for verifying resolved CRs and analyzing a collection
of defects to measure the quality of the software and process.
The Implementer
uses CRs to
analyze the defect and find the faults or causes of the CR.
Brief Outline
The following attributes are useful in coming to a decision about any submitted
CR:
Size
How much existing work will have to change?
How much new work will need to be added?
Alternatives
Are there any?
Complexity
Is the proposed change easy to make?
What are the possible ramifications of making this change?
Severity
What is the impact of not implementing this request?
Is there any loss of work or data involved?
Is this an enhancement request?
Is it a minor annoyance?
Schedule
When is the change required?
Is that feasible?
Impact
What are the consequences of making the change?
What are the consequences of not making the change?
Cost
What is the cost of saving from making this change?
Relationship to Other Changes
Will other changes supersede or invalidate this one or does it depend on
other changes?
Test
Are there any special test requirements?
Sample Change Request Form
Identification
Project:
Change Request Number:
Change Request Type: (Problem or Enhancement)
Title:
Date Submitted:
Originator:
Change Request Priority:
Current Problem
Description of the current problem:
Critical Failure:
Nuisance:
Enhancement:
New Requirement:
Conditions under which the problem was observed:
Current Environment: Hardware
Operating System
Compiler
Source of the current problem:
Cost or Savings Impact of the current problem:
Proposed Change (Submitter)
Description of the proposed change:
Estimated cost to implement the proposed change:
Proposed Change (Change Review Team)
Action:
Approved:
Disapproved:
Deferred:
Description of the proposed change:
Affected Configuration Items:
Category:
Error Fix:
Enhancement:
New Feature:
Other:
Resolution
Estimated cost to implement the proposed change:
Implementer:
Actual time to implement change:
Analysis:
Implementation:
Test:
Documentation:
Affected Number of Lines of Code:
Assessment
Test Methods:
Inspection
Analysis
Demonstration
Test:
Test Platforms:
Test Cases:
Change Review Team Disposition
Changes Approved and Accepted:
Timing
Change Management practices are often institutionalized or established early on in the
project lifecycle. As such, CRs, which are integral to the change process, can be raised at any time during the course of the project.
The main source of defects is the results of executing the tests—integration, system, and
performance. However, defects can appear at any point during the software development lifecycle and include
identifying missing or incomplete use cases, test cases, or documentation.
Responsibility
Anyone on the project staff should be able to raise a CR.
However, CRs need to be reviewed and approved to be valid by the
supervisor of the person raising the Change Request. The final arbitration on a
Change Request is done by a Review Team or a Change Control Board (CCB).
The Change Control Manager is
responsible for the integrity of the defect, ensuring that:
All information identifying the defect, and describing it and how it was
discovered, is accurate.
The defect is unique or is not another occurrence of an already identified
defect.
Tailoring
The actual fields and data necessary to accurately identify, describe, and
track defects vary and are dependent upon the standards, guidelines, and change
control system implemented.
Artifacts >
Configuration & Change Management Artifact Set >
Change Request
