DOC

InnoInco - Change Management Guidelines

By Tiffany Cook,2014-05-13 06:44
9 views 0
InnoInco - Change Management Guidelines

     308-885 W16 Street, North Vancouver, BC V7P 1R2 Canada E-mail: info@innoinco.com Web: http://www.innoinco.com

    CHANGE MANAGEMENT GUIDELINES

    ____________________________________________________________________________________________

    InnoInco

    Revisions’ History

V1.0.0 12.04.2004 Alexander Zhemdinsky (AZH) Creation of the document

    V.2.0.0 20.07.2005 Oksana Schatnaya (OSC) Defect Tracking review

    V.2.1.0 25.07.2005 Oksana Schatnaya (OSC) Change request review

    V.2.2.0 04.08.2006 Alexander Zhemdinsky (AZH) Process scope review

    ____________________________________________________________________________________________

    InnoInco Page 2

    Table of Contents 1 GLOSSARY ..................................................................................................... 4 2 GENERAL ........................................................................................................ 5 2.1 PRODUCT QUALITY CRITERIA ............................................................................... 5 2.2 RULES OF CQ SYSTEM USERS NAMING .................................................................... 5 2.3 CORRESPONDENCE RULES ................................................................................... 5 3 CHANGE REQUEST MANAGEMENT ................................................................... 6 3.1 PURPOSE. ....................................................................................................... 6 3.2 EVALUATION OF CHANGE REQUEST PRIORITY. .......................................................... 6 3.3 CHANGE REQUEST LIFE CYCLE .............................................................................. 6 3.4 CHANGE REQUEST SUBMISSION ............................................................................ 7 3.5 TRANSITION MATRIX......................................................................................... 8 3.6 THE PROCESS OF INTERACTION BETWEEN A CUSTOMER PRODUCT MANAGER AND A PROJECT

    MANAGER. ........................................................................................................... 11 4 DEFECT TRACKING. ...................................................................................... 12 4.1 SEVERITY LEVEL EVALUATION. ........................................................................... 12 4.2 DEFECTS PRIORITY EVALUATION. ...................................................................... 12 4.3 DEFECTS LIFE CYCLE ....................................................................................... 12 4.4 DEFECT SUBMISSION ....................................................................................... 13 4.5 TRANSITION MATRIX ....................................................................................... 14 4.6 THE PROCESS OF INTERACTION BETWEEN TEST AND SOFTWARE DEVELOPMENT TEAMS. .... 16

    ____________________________________________________________________________________________

    InnoInco Page 3

1 GLOSSARY

    CQ Clear Quest

    ____________________________________________________________________________________________

    InnoInco Page 4

2 GENERAL

    2.1 Product quality criteria

    ; Software product must be developed according to the technical specifications;

    ; Product’s functionality must completely cover all functional requirements stated in User

    Guide/Functional specifications/Use-Cases;

    ; Release build must not have known defects with Critical, Major and Average severities.

2.2 Rules of CQ system users naming

    Naming of users in CQ takes place according to the following scheme: short name = the first letter of the name + two first letters of the surname. For example the short name for Alexandr Zhendinsky will be indicated in the system as: AZH.

2.3 Correspondence rules

    During the project there is a necessity for development and test teams to be in close contact with a customer. As a rule there are several contact persons (contacts) from the customer’s side:

    - Project manager to decide on project questions;

    - System analyst for solving the problems with the system’s correct functioning;

    Test team addresses project questions to a test team leader or to a project manager from the executive side, defect connected issues are discussed either with a test team leader or with the tester, who has submitted the defect.

    So, it is necessary to determine the correspondence rules to be followed by all project participants:

    ; Letter layout must include ”The Headline”, which describes the subject of the

    letter, and the body of the letter with the request. All persons that are interested

    in the issue are included in the Copy of the letter.

    ; The answer on the letter must be given not later than 4 hours from the entry

    point (the moment of its receiving). In case there is no possibility to give a

    proper answer on the formulated questions, the message addressee must send a

    notification on the receiving of the letter and presumable date of letter with the

    detailed answer on the inquiry. In case the answer was not received in the

    mentioned time, the letter is sent again with the project manager in the Copy,

    who will control the subordinate’s performance.

    ____________________________________________________________________________________________

    InnoInco Page 5

3 CHANGE REQUEST MANAGEMENT

    Change Request is a formally submitted artifact that is used to track all participants’ request’s (including new features, enhancement requests, defects, changed requirements, etc.) along with related status information throughout the project lifecycle. All change history will be maintained with the Change Request, 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.

3.1 Purpose.

    The purpose is to manage the life cycle of the change requests that are required to maintain artifacts: vision documents, Use-Cases, models, source code, test assets, etc. A workflow is available (in ClearQuest) to first submit new change requests and then process them (estimation, approval, resolution, validation) until closure.

    The purpose of this document is to describe the overall management of change requests:

    ; how change requests are proposed

    ; who can submit a change request in ClearQuest

    ; change request estimation and approval

    ; change request implementation and validation

3.2 Evaluation of change request priority.

    Change request priority is evaluated for the correct estimation of implementation urgency for change request.

    Priority must be based on:

    ; priority level

    ; function necessity for the end user.

    There are several priority types:

    ; Must have” – the highest priority, change request should be implemented in few

    hours, implementation must be delivered with patch or new build version at once;

    ; High” – no necessity to resolve change request immediately but it should be done in

    the first place;

    ; Medium” – default priority for change request (routine);

    ; Low” – change request’s implementation with such priority take place after all others;

3.3 Change request life cycle

    Change request life cycle is presented on the following diagram:

    ____________________________________________________________________________________________

    InnoInco Page 6

    Close

    PostponeDeclinedPostponed

    Close

    OpenDeclineOpenPostponeReject

    Postpone

    SubmitSubmittedOpenOpenedApproveApprovedResolveResolvedCompleteCompletedValidateClosed

    DuplicateOpen

    RejectDuplicate

    Close

    Open

    Close

    SubmissionApprovalImplementationValidation

3.4 Change request submission

    The list of fields for data entry during the change request submission looks as follows:

    Field name Description

    ID Change request identification number, filled in

    automatically by the system

    State Change request’s current state

    Headline Change request’s name

    Owner Project manager

    Priority Is defined to indicate a project manager the urgency of

    change request implementation

    Description Full change request description, methods of it reproduction,

    influence on other fields and functions

    New note The field is used for entry of additional information on a

    change request, to make interaction between the customer

    and the project manager easier

    Notes log Not applicable

    Attachments Attached files for more detailed change request’s

    description (screen shots, log files)

    ____________________________________________________________________________________________

    InnoInco Page 7

Field name Description

    Request type Describes the type of change request (is it an Enhancement

    or a New Feature)

    Target release Version number of the target release, in which

    implemented change request should be delivered

    Product Product identifier (Pocket PC or Smart phone or what else)

    After the submission of the change request the following fields must be filled in during

    the process of its estimation and implementation:

    Field name Description

    Estimated Project

    management efforts in Approximate period of time that is needed for the

    implementation of change request hours Development

    Test

     Actual Project

    efforts in management A period of time during which the change request hours was implemented Development

    Test

    Delivery date The date of change request delivery

3.5 Transition Matrix

    Transition matrix is presented in the following table:

    During the testing the following scheme for interaction of the project manager with the

    customer and cooperative process of change requests implementation will be used:

    Action New state Producer Comments Previous Responsible ? state person

    ____________________________________________________________________________________________

    InnoInco Page 8

    Action New state Producer Comments Previous Responsible ? state person

    No Submit Submitted Customer Project All mandatory

    product manager attributes must be

    manager filled in,

    1 attachments with

    additional

    information

    supplied

    Submitted Open Opened Project Customer Estimation of

    manager product efforts required

    manager for

    implementation, 2 entering the

    phase of

    estimations

    approval

    Submitted Close Closed No Customer Change request is

    product either irrelevant

    3 manager/ or is already

    project implemented and

    manager validated

    Submitted Duplicate Duplicated Customer Customer Change request

    product product duplicates

    manager/ manager/ previously

    project project submitted one, 4 manager manager indicate the

    number of the

    duplicating

    change request Opened Close Closed No Customer Change request is

    product either irrelevant or

    5 manager/ is already

    project implemented and

    manager validated

    Opened Decline Declined Customer Project Change request’s

    product manager implementation

    manager needs additional 6 investigation or

    large temporal

    costs

    Opened Postpone Postponed Customer Customer Change request

    product product implementation is

    7 manager/ manager/ postponed on any

    project project reasons

    manager manager

    Opened Approve Approved Customer Project Change request is

    8 product manager approved and ready

    manager for implementation Postponed Open Opened Customer Customer Change request is 9 product product in process again

    ____________________________________________________________________________________________

    InnoInco Page 9

    Action New state Producer Comments Previous Responsible ? state person

    manager/ manager/

    project project

    manager manager

    Postponed Close Closed No Customer Change request is

    product either irrelevant or 10 manager/ is already

    project implemented and

    manager validated

    Declined Open Opened Project Customer Change request is

    manager product re-estimated is in 11 manager approval process

    again

    Declined Postpone Postponed Customer Customer Change request

    product product implementation is 12 manager/ manager/ postponed on any

    project project reasons

    manager manager

    Approved Postpone Postponed Customer Customer Change request

    product product implementation is 13 manager/ manager/ postponed on any

    project project reasons

    manager manager

    Approved Resolve Resolved Developer Tester Change request is 14 implemented and

    ready for testing

    Resolved Complete Completed Tester Customer Change request is 15 product tested and ready

    manager for validation

    Resolved Reject Approved Tester Developer Change request is

    not implemented, 16 the reasons of

    rejection are

    indicated

    Completed Reject Approved Developer Customer Change request is

    product not implemented, 17 manager the reasons of

    rejection are

    indicated

    Completed Validate Closed No Customer Change request is 18 product validated and

    manager closed

    Duplicated Open Opened Customer Project Change request is

    product manager transmitted in the 19 manager/ state “Duplicated”

    project by mistake, sent for

    manager implementing

    Duplicated Close Closed No Customer Change request is 20 product duplicated and

    ____________________________________________________________________________________________

    InnoInco Page 10

Report this document

For any questions or suggestions please email
cust-service@docsford.com