Change Management in Software Development Projects

Introduction

CRs head on with a Change Management process. This paper describes such a process, in brief. Change in software development can be a change in specifications, user requirements, design change, code change or so on.

Origination of changes

Changes can originate from various sources including customers, end users, the project team or the test team. Changes from customers and end users would normally be changes in their requirements; from the project team could come design changes; and the testing team could request code changes. Changes are communicated to the Software Project Manager (SPM) using a Change Request (CR) form. The CR would contain details of the project, module and component which are likely to be affected by the CR and may include reasons for the CR.

Procedure for CR resolution

Normally when a CR is received, the first activity is to record it in a CR Register. The CR register could be an Excel Sheet or a software like PMPal that facilitates CR Register functionality. The CR Register is the main tool for tracking all CRs to resolution- which may be rejection of the CR or implementation. All CRs received would be entered in the CR Register and would be tracked through to closure.Then the CR is analyzed by the SPM or a person designated by them. Sometimes, especially in large projects, there would be a CCB (Change Control Board) that would analyze the CR and approve or reject it. The analysis would determine:

1. Whether implementation of CR would be feasible
2. The amount of effort and calendar time it would take to implement the CR
3. The impact of the CR on the overall project – especially in terms of effort, schedule and cost

Once the analysis is completed, the Impact Analysis would be submitted to CCB or the SPM who would approve or reject the CR. In case of rejection, the decision along with the reasons would be communicated to the originator of the CR and the CR is closed in the CR Register. Once a CR is approved for implementation, it would be implemented in accordance with the CR implementation strategy decided and recorded in the Software Configuration Management Plan (SCMP). Various strategies are:

1. Implement CRs as and when received, immediately on receipt
2. Collate all CRs and retrofit them at the end of development
3. Situational implementation – that is
   • If the component which is affected by the CR yet to be coded or is being coded, then implement it when it is coded
   • If the coding of the component which is affected by the CR is completed, keep the CR pending and retrofit it at the end

Once this is decided, the CR would be implemented in line with the analysis and implementation strategy decided by CCB or the SPM. Implementation for the CR would be carried out as follows:

1. The CR would be allocated for resolution to one or more team members as necessary by the SPM
2. The team members would carry out necessary coding and modification of existing code as necessary. This activity would be governed by the coding guidelines for the project.
3. The CR would them be allocated for Peer Review. Peers would review the code to ensure that the:
   • Implementation fulfills the requirements of the CR
   • The implementation conforms to the defined coding guidelines and other software engineering standards of the organization
   • There is no trash code or malicious code left in the software
   • The changed code ensures efficiency of execution and response times
4. Once the CR is approved in the Peer Review, it would be submitted for Regression Testing to the testing team
5. The testing team would carry out regression testing to ensure that all functionalities requested in the CR are correctly working and that no other original functionality is affected by the implementation
6. Once regression testing is completed, and all defects pointed out in peer review or regression testing are resolved and closed, then the CR is closed in the CR register and further action is only taken as needed.

Acronyms Used

Software Project Manager (SPM)

Change Request (CR) form

CCB (Change Control Board)

Software Configuration Management Plan (SCMP)

The CR would normally contain the following entries:

1. The CR Id, which could be a serial number
2. The CR description
3. Date on which the CR is received
4. Allocation details for Analysis including date of allocation, completion date, to whom it is allocated
5. Allocation details for Approval of CR including date of allocation, completion date, to whom it is allocated
6. Allocation details for Resolution of CR including date of allocation, completion date, to whom it is allocated
7. Allocation details for peer review including date of allocation, completion date, to whom it is allocated
8. Allocation details for regression testing including date of allocation, completion date, to whom it is allocated
9. Status – open, closed or under analysis / approval / resolution / peer review / regression testing
10. Date on which CR is closed

CR metrics normally define the Requirements Stability. The following formula is used to compute Requirements Stability –

(Total number of requirements – number of CRs) / Total number of requirements

Another metric normally derived is the amount of relative effort (as a percentage) spent on resolving CRs using the formula below:

(Total effort spent on resolving CRs / Total effort spent on the project) X 100

Other metrics analysis that is carried out is the categorization of changes into various categories so that the origin of changes can be determined and draw inferences to find if any trend is emerging. Look at these possibilities:

Suppose that the bulk of CRs show that coding is the reason; then the organization realizes that additional training for coders is necessary

Suppose that bulk of CRs show that understanding of customer requirements was not satisfactory; the organization realizes that Analysts need to be trained in effective requirements for solicitation / elicitation / development

Suppose the bulk of CRs resulted due to defective design; then the organization realizes that software designers / architects should be improved.

And so on.

The resolution of analysis findings from CR Categorization, could be improved through:

Better software development process and procedures

Better standards and guidelines for coding, design, architecture, review etc.

More rigorous implementation of conformance and investigative audits

Progress / status reporting of CRs

Normally the status of implementation, progress of CR resolution and CR metrics are normally reported through Weekly Status Reports to the concerned executives for the purpose of records; and senior management intervention, where necessary or warranted.