As companies strive to manage their Software Development Lifecycle (SDLC) projects, they are inundated with requirements, software and data changes, and defects. In order to manage costs, customer expectations and priorities, a Change Request Management methodology must be developed early in the process.
Like sailing a boat in a true straight line, continuous course corrections are needed. In software development organizations, knowing how to triage, prioritize, organize, and manage change allows the boat (the SDLC) to stay on course.
Since change is inevitable, it would be insane to know it was going to happen and to do nothing to manage it. The Change Request Management (CRM) System is a tool to be used throughout the SDLC.
Here are just three benefits of a Change Request Management System:
A solid risk management program requires detailed information from the CRM.
Metrics from the CRM allow a project manager to evaluate the efficiency of and the effectiveness of the SDLC process.
Triaging and prioritization of issues and resources are determined by reviewing the details of the CRM.
1. How Does Change Request Management Work
Change Request Management is the process of tracking all of the changes that come from different sources and become part of a product. These Change Requests are tracked from the first awareness of need until the final disposition.
To define “How” with respect to Change Request Management requires a definition of actions and workflow. Actions are described below. A discussion of workflow requires more in depth knowledge of the specific situation and an assessment of the gaps that need to be bridged.
Identification
This is the point at which a change request is recognized. It is an important step in the process. Changes may be initiated from many interactions. Discussions, analysis and use of the product are very common initiation points for change requests. It is important to capture the context of the discussion, analysis or use accurately so that the change request can be evaluated from the appropriate perspective. Identification is part of the Submitting Phase.
Instantiation
This is the point where the change request is documented. It can be referred to as the creation, entering or inserting of a CR into the Change Request system. We recommend that the CR be documented in an on-line system. For the purposes of this document, all potential change requesters are provided access to the Change Request Management System for the purpose of instantiating new change requests. We understand that some organizations limit this access and perform Triage (see below) before instantiation. On-line submission is facilitated with a form designed to enter critical data for triage.
The form has key fields like a Description, Title, Reference Number, Assignee, Submitter, Severity, Priority, etc.
Triage
If all change requestors are able to enter Change Requests, an efficient and effective means of disseminating work and defining the disposition of each change is needed. We suggest that a team be created. The team is called the Software (or System) Configuration Control Board (SCCB). This group’s members typically include the following: QA, Development, Test, Product Management and Business Analysis.
There are two primary concerns for this group. The first concern is to review the fields entered by the requester with the following question in mind, “Is the CR properly categorized \ classified?” This means that the SCCB is tasked with maintaining consistency in the content of the CR as well as overall enforcement of a common standard for the assignment of severity and priority. The second major concern is to define the next step in the life of the CR.
The CR record tracks each step in the life of the Change Request. An online system has a form to record updates. Permissions vary by user, group, type of field and state of the CR. Because permissions vary by user, group, type of field and state of the CR, the forms for updating vary in the fields that are displayed.
The update form invariably contains many of the fields that are on the submit form. Permissions determine the user’s capability with any given field on any given form.
Some reasons to update a CR are:
A new assignee is needed
More requirements are needed
More information is needed
A comment is needed
The change is ready for testing
The change is completed
Closure
This is the act of setting a CR to the closed state. There is special processing and meaning associated with the process. “Closed” means the CR is ready for deployment. It has successfully completed testing.
When a CR is closed, the following fields are typically set:
State (gets set to “Closed”)
Date Closed
Version Resolved
Release Name
RELATED POST
DAY 1 MICROSOFT DOT NET FRAME WORK
DAY 2 MICROSOFT DOT NET BASE CLASS LIBRARY
DAY 3 MICROSOFT DOT NET CLASSES AND STRECTURES
DAY 4 METHODS IN FRAME WORK
DAY 5 INPUT VALIDATIONS IN DOT NET PART ONE
DAY 6 INPUT VALIDATIONS IN DOT NET PART TWO
DAY 7 DATA TYPES IN DOT NET
DAY 8 DATA TYPES IN DOT NET PART TWO
DAY 9 IMPLEMENTING PROPERTIES IN DOT NET
DAY 10 DELEGATES AND EVENTS
DAY 11 OOPS INTRODUCTION
DAY 12 POLYMORPHISM
DAY 13 INHERITANCE AND POLYMORPHISM
DAY 14 EBUGGING TOOLS IN DOT NET
DAY 15 DEBUG AND TRACE IN CLASSES
DAY 16 UNIT TEST PLAN
DAY 17 EXCEPTIONS IN VISUAL STUDIO
DAY 19 ADO.NET INTRODUCTION
DAY 20 DATA ACCESSING IN DOT NET
DAY 21 DATA BASE OBJECTS
No comments:
Post a Comment