Work Product (Artifact): Change Request
var defaultQueryStr = '?proc={659D51DD-DF1F-465E-9F3A-2FC6F9BC7C34}&path={659D51DD-DF1F-465E-9F3A-2FC6F9BC7C34},{A550E1F1-D779-4B1A-9E2C-A364E521A091},_uFD6gEoeEdqrjq4i3fchvA';
var backPath = './../../';
var imgPath = './../../images/';
var nodeInfo=null;
contentPage.preload(imgPath, backPath, nodeInfo, defaultQueryStr, false, true, false);
Work Product (Artifact): Change Request
These artifacts are used to document and track requests for a change to the product. This provides a record of decisions and, with an appropriate assessment process, ensures that the change impact of the request is considered.
Purpose
To Formulate and track
Changes and Defects
Relationships
RolesResponsible:
Modified By:
Process Engineer
Output From
Launch Development Process
Description
Main Description
The necessity for change is inherent in developing a software system as it evolves during its initial creation and as
it is subsequently used and maintained in day-to-day operation in an live environment. Change Requests provide a record
of decisions and, with an appropriate assessment process, ensures that their change impacts are considered.
Change Request are also known by various names such as CR's, defects,
bugs, incidents, enhancement requests. Capturing and managing these requests appropriately ensures that changes to a
system are made in a controlled way so their effect on the system can be predicted. Some import types of Change Request include:
Enhancement Requests are used by various stakeholders to request future features they desire to have included in
the product. These are a type of Stakeholder Request that capture and articulate an understanding of
the stakeholders needs.
Defects are reports of anomalies or failures in a delivered work product. Defects include such things as
omissions and imperfections found during early lifecycle phases, or symptoms of faults (failures) that need to be
isolated and corrected within the software. Defects may also include deviations from what can be reasonably expected of
the software behavior (such as usability issues).
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 CR's:
Role Set: Analysts uses CR's define significant changes to high-level
requirements and to determine requirements from, especially from those CR's identified as Enhancement Requests.
Role Set: Managers uses CR's to manage and control work assignment.
Role Set: Testers use CR's to describe failures (defects), omissions and
quality issues found during software testing.
Role Set: Developers uses defect CR's to analyze failures and find the
underlying faults or causes of the failure so as to resolve the CR.
Role: Test Analyst uses CR's to plan the tests that will
verify resolved CR's and to evaluate the test effort by analyzing sets of defects to measure trends in the quality
of the software and the software engineering process.
Brief Outline
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 (Originator)
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
Properties
Optional
Planned
Tailoring
Representation Options
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.
It is generally more efficient to store change requests in a database or change request management system, so that
change requests can be more easily managed (for example, sorting by priority, tracking assignment and completion
status). On a small project, a spreadsheet may be sufficient.
On a small project you can manage the defects as a simple list. You can also use a spreadsheet with a separate column
for each attribute of the change request. This is only manageable for small systems. When the number of people involved
and the amount of defects grow beyond a certain point you will need to use a more flexible defect-tracking system.
More Information
Concepts
Change Request Management
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
contentPage.onload();
contentPage.processPage.fixDescriptorLinks();
Wyszukiwarka
Podobne podstrony:
rup change request?B12C3Crup change request?777940rup change request?E6419rup change requesta03690Crup change request?A427EBmanage change requests8544ABmanage change requests?A11348review change request?D91346submit change request93BB55Crup change managerQE43456więcej podobnych podstron