Change Management

Scope

The requirements for change appear at all stages during the project life cycle. This document provides the mechanisms for managing change throughout the development phases and could form the basis of a long term change management process.

Sources of Change

The following sections identify some of the major sources of change request. By identifying these sources, procedures for managing the change can be adopted.

Bugs

Development: Errors inevitably creep in during coding. It is the job of unit and package testing to eliminate obvious sources of error. Thereafter it is the job of code review to locate and remove more obscure / hidden errors, perhaps stemming from design or usage problems.

Alpha test: Most if not all configuration and integration errors should be eliminated in this phase. No new development bugs should appear during this testing stage.

Beta test: This is where the functionality is stress tested in a working environment. It is important to focus the beta testers on the functionality released and away from functionality yet to be included. The materials that accompany the beta test must state clearly the objectives and success/failure criteria of the test programme. See [Testing] document.

FCS: Any errors that appear from here onwards need to be handled by the maintenance team tasked with supporting AstroGrid during its operational lifetime.

Missing Functionality

Requirements capture incomplete: Unless the missing functionality is trivial, this requires very careful management to address. It represents a fundamental breakdown in the problem analysis phase. Unfortunately it is all too easy for requirements that are obvious to domain experts but completely unknown to the analyst to fall into this category. During design it is important to remember that, from a user perspective, functionality falls into one of three types:

Given:	So obvious the user may not even state it as a requirement
Needed:	The functionality that solves the problem currently exercising the users imagination
Delighter:	Functionality the user hadn't even considered but once seen elevates the solution above the ordinary

Design flaw: the requirement was identified but didn't make it into the design. Again, unless trivial, this requires very careful management to address. A full understanding of the impact the addition will have both on timescales and resources needs to be determined. Final decisions will be taken by the Technical Support Panel (TSP) and project sponsors.

Code review failure: The specification for the current iteration included the requirement but it failed to materialise. This should be prevented by the code review process and omissions of this kind require an investigation into the code review practices currently in operation. The technical Lead will be responsible for initiating such investigations.

Change of requirements: The original requirements are no longer valid or new opportunities have been identified. Changes at this level once again need careful management as they potentially threaten the completion of the project either through over burdening the project or because they call into question the original premise upon which the project was based. This type of change requires the attention of the TSP.

Usage

Usability issue: The solution as designed is cumbersome or inelegant and needs revision. Problems of this type should be minimised during the design phase through use of mock ups and prototypes. Where they get through, careful consideration needs to be given to the impact of the usage problem versus the resource required to change.

New technology: New methods of using the base functionality have appeared which need to be incorporated into the project. Typically there is a steep learning curve (and consequent adverse impact on productivity) associated with new technology. Should this change be deferred to a later release/ version?

Changed community: The original user base has expanded. Perhaps the new users are not as expert and therefore require a different style of interface or perhaps the interfaces need translating into other languages. The impact of such changes can be minimised during design provided the possibility of this type of change is identified early. If not, postponing the change to a later version is often the only safe course of action.

Tracking Change

Various tools exist to track and manage change requests. These include GForge , Bugzilla and Teacup to name just a few. Following the current round of reviews, a change management system will be implemented. In many respects deciding upon the actual system is less critical than ensuring it provides the basic functions needed namely:

• Distributed
• Easy to use
• Supports escalation / problem reassignment
• Flexible categories (problems vs suggestions etc)
• Supports filtered views
• Flexible status (see below)

Managing Change

How is “Change” identified, categorised and completed?

These are the fundamentals of the process:

Categorising

When any Change Request is received it must first be categorised into one of the following types:

Bug:	A problem with the system which requires a code or system level alteration to fix
Enhancement:	The addition (or removal) of a new piece of functionality, either within the existing system or as a wholly new sub-system.

Prioritising

Next the change request must be prioritised:

Priority 1	BUG	Catastrophic failure leading to loss of service to all users
	ENHANCEMENT	New functionality without which the entire project is rendered useless
Priority 2	BUG	Failure affecting some but not all users resulting in total loss of service to those users
		Loss of one or more data sources
		Network breakdown preventing some users access to applications or data
	ENHANCEMENT	Functionality which greatly enhances the utility and value of the project
Priority 3	BUG	Major problem affecting a single user
		Degraded service affecting more than one user
		Loss of connectivity with a user
		User unable to access data sources
	ENHANCEMENT	Functionality which greatly enhances the utility and value of one or more aspects of the project
Priority 4	BUG	Slow or degraded service affecting one user
		Slow response or excessive latency affecting one user
		Network or data source down with alternates available
	ENHANCEMENT	Functionality which improves the utility of one aspect of the project
Priority 5	BUG	Non-user affecting outages or network problems
		Problems registering new users
	ENHANCEMENT	“Nice to have” improvement

Clearly not all of these can be addressed by a single support or development team. It is therefore imperative that links to other support teams (e.g. Systems and network management) be forged to ensure continuity of service.

Escalation

Where escalation is necessary (a fix requires considerable resources, users not happy with proposed solution etc), change requests will escalate from developers to team leaders to Technical Lead through to the TSP. Escalation will also be necessary when difficulty is encountered in categorising and/or prioritising a change request. Typically this will include the grey areas of “is it a bug or an enhancement?” and “it's a critical problem, make it a priority 1!” when perhaps it's not.

Process Management

Some of the sources of change request identified above are process related rather than design or development. These include process failures during design as well as development quality control. If these occur, in the first instance the Technical Lead will investigate and if necessary amend or replace the faulty process. Where there has been a failure to administer the process, this will be addressed either through further education or changes to working practices.

Project Expansion

Inevitably some change requests will not be addressed in the current release of the project. Where this occurs the change must be planned for a future release or removed as unnecessary. This will be the responsibility of the Technical Lead and will happen immediately after each release. In the case of enhancements, the full impact must be uncovered and a decision taken as to when (indeed “if”) the change will ever happen. Again, this is a role for the Technical Lead. Further escalation to the TSP may also be required. If the change is approved (this will probably involve returning to the project sponsors), plans must then be made to provide the resource and commitment to effect the change. These plans will be integrated into the release cycle as described in the “Coding Standards and Procedures” document.

-- KeithNoddle - 04 Dec 2002