Configuration Change Management

Maintenance is the most expensive component of the software life cycle. IT departments often spend from 75 to 80 percent of their budgets [Guimaraes 1983] and time on the maintenance process of system development. In addition, the cost of fixing an error rises dramatically as the software progresses through the life cycle. Maintaining systems in a nonsystematic, measurable way is counterproductive. Changes made but not properly documented can be detrimental to the system and to the people using that system. This chapter discusses the concept of configuration change management.

WHAT IS CONFIGURATION CHANGE MANAGEMENT?

Configuration change management is an organized process that provides a standardized framework for managing change. The EIA-649 standard defines the purpose and benefits of the change management process as follows :

• Change decisions should be based on detailed knowledge of the impact of that change.
• Changes should be limited to those that are necessary or that offer significant benefit.
• Ensure that customer perspectives and interests are considered .
• Enable orderly communication of change information.
• Preserve configuration control at product interfaces.
• Maintain consistency between the product and its documentation.
• Maintain the configuration baseline for the product.

THE MAINTENANCE PROCESS

Once a new system is implemented, the real work begins for most IT departments. As users utilize the system, errors are discovered and changes are requested . As systems have become more widely used within critical departments of the organization, the maintenance process has taken on a more important role. The management of systems maintenance has perhaps become the most critical phase of systems development because change is now considered an opportunity for improvement. Change can be initiated for a wide variety of reasons, including:

• Add new capabilities
• Enhance product support
• Replace worn technology with more modern technology
• Fix bugs
• Implement preplanned product improvement
• Reduce costs

Just as in the development of a new system, maintenance requires that steps be carefully taken in making changes or fixing errors. In the event of an error, this can be even more critical. Each step of the maintenance process is similar to steps in the systems development life cycle [Curtis et al. 2000], as seen in Figure 11.1. This is a logical extension of the development process as changes being made to the system can affect the whole system and therefore need to be carefully controlled.

Figure 11.1: The Maintenance Life Cycle Compared to the Development Life Cycle

Configuration management depends on orderly record keeping. From the moment a system is proposed, a paper trail ” that is, configuration status accounting ” needs to be initiated and maintained (see Appendix T for a sample Software Configuration Management Plan and Appendix S for a sample Maintenance Plan). All systems eventually wind up in maintenance mode. It is critically important to capture proper documentation for all requests for changes as well as for the change itself. Maintenance can come in many forms ” for example, the software requires change for new functionality, end users notice problems, and even the documentation might require modification. The first step in the process is to obtain a maintenance request from a user . Appendices B, and I through R are examples of a wide variety of change request forms, trouble reports , library baseline change requests, and specification change requests. Once the request has been received, the requests can be transformed into changes that can then be used to make design changes. Once the changes are designed and tested , they can be implemented.

Figure 11.2 is an overview of system maintenance. Both the customer and maintainer are interacting with their own documentation (i.e., user manual and maintainer manual). The customer poses questions, problems, and suggestions to the maintainer, and the maintainer, in turn , gives the answers and they are filtered through a change control process and back into the system.

Figure 11.2: An Overview of System Maintenance

The maintenance process should provide for documenting:

• The need for the change
• Documentation of the impact of the proposed change
• Evaluation of the proposed change
• Coordinating the change process, including whether it has been approved or not approved
• Making the change to the product
• Making the change to appropriate documentation, including user manuals
• Maintaining the product's configuration baseline; any change that modifies the baseline from that which the customer expects needs to be approved by the customer
• Verifying the change

THE PRODUCT BASELINE

To accomplish the change systematically, the configuration baseline of the product must be known. The baseline usually consists, at a minimum, of the approved detail design specification. As the product is modified by approved changes, the configuration baseline must also be changed. Configuration management cannot be accomplished if the product baseline is not continually kept up-to-date.

TYPES OF MAINTENANCE

Categorizing the types of maintenance required is helpful in organizing and prioritizing user requests . Software maintenance is more than fixing mistakes. Maintenance activities can be broken down into four subactivities.

1. Corrective maintenance
2. Adaptive maintenance
3. Perfective maintenance or enhancement
4. Preventive maintenance or reengineering

Corrective Maintenance

Corrective maintenance involves fixing bugs or errors in the system as they are discovered . Corrective maintenance is the type most users are familiar with because they are the most aggravating to users. These usually receive top priority as they can be paralyzing to the organization if not identified and fixed. Corrective maintenance consumes approximately 17 percent of the maintainer's time [Lientz and Swanson 1978].

The major skills required for corrective maintenance include:

• Good diagnostic skills
• Good testing skills
• Good documentation skills

Adaptive Maintenance

Adaptive software maintenance is performed to make a computer program usable in a changed environment. For example, the computer on which the software runs is going to use a new operating system; thus, the system requires some adaptive tweaking. Adaptive maintenance is typically part of a new release of the code or part of a larger development effort. Approximately 18 percent of software maintenance is adaptive [Lientz and Swanson 1978].

Perfective Maintenance

Perfective maintenance is the act of improving the software's functionality as a result of end-user requests to improve product effectiveness. It includes:

• Adding additional functionality
• Making the product run faster
• Improving maintainability

This is the biggest maintenance time consumer. Approximately 60 percent of software maintenance time is spent on perfective maintenance [Lientz and Swanson 1978].

Preventive Maintenance

Preventive maintenance refers to performing "pre-maintenance" in order to prevent system problems. This is different from corrective maintenance, which is performed to correct an existing problem. This is similar to maintaining a car in which you change the oil and air filter not in response to some problem, but to prevent a problem from occurring in the first place.

MAINTENANCE COSTS

As computers and their systems become more widely used, the need for maintenance grows. As these same systems age, maintenance becomes more critical and time consuming. Since the early 1980s it is estimated that maintenance costs have skyrocketed from 40 percent of the IT budget to 75 to 80 percent (see Figure 11.1). The reason for these increases stems from the once newly designed systems aging. This shift from development to maintenance is a natural occurrence as organizations avoid the high cost of new systems and struggle to maintain their current systems.

Many factors affect the cost in time and money expended on system maintenance. One of the most costly is design defects. The more defects in a system, the more time is spent identifying them and fixing them. If a system is designed and tested properly, most defects should have been eliminated; but in the case of poor design or limited testing, defects can cause system downtimes, and downtimes cost the organization in terms of lost efficiency and perhaps lost sales.

The number of users can also affect the cost of system maintenance. The more users, the more time will be spent on changes to the system. More importantly, the greater the number of platforms the system is installed on, the higher the cost of maintenance. If a single system needs a change, then the time it takes to change the system is limited; but if that system resides on platforms across the country, such as is the case in many branch offices of corporations, then the cost increases significantly.

The quality of the documentation can also affect the overall cost of maintenance. Poor documentation can result in many lost hours searching for an answer that should have been explained in the documentation. Managing change using a configuration change management approach ensures that the documentation will be consistent with the current version of the product.

The quality of the people and their skill level can also cost an IT department many wasted hours. Inexperienced or overloaded programmers can increase the cost of maintenance in two ways. First, they can waste hours learning on the job at the IT department's expense. Second, if the programmers are overwhelmed with projects, they may skip steps in the maintenance process and, in turn , make mistakes that cost time and money to fix.

The tools available to maintenance personnel can save many hours of work. Using automation tools, such as CASE tools, debuggers , and other automation tools, can help programmers pinpoint problems faster or make changes more easily.

The structure of the software can also contribute to maintenance costs [Gibson and Senn 1989]. If software is built in a rational and easy-to-follow manner, making changes will be much easier and thus much faster, thereby saving time and resources. Software maintenance costs can be reduced significantly if the software architecture is well-defined , clearly documented, and creates an environment that promotes design consistency through the use of guidelines and design patterns [Hulse et al. 1999].

A MODEL FOR MAINTENANCE

Harrison and Cook [not dated] have developed a software maintenance model based on an objective decision rule that determines whether a given software module can be effectively modified, or if it should instead be rewritten. Their take is that completely rewriting a module can be expensive. However, it can be even more expensive if the module's structure has been severely degraded over successive maintenance activities. A module that is likely to experience significant maintenance activity is called change-prone. Their paper suggests that early identification of change-prone modules through the use of change measures across release cycles can be an effective technique in efficiently allocating maintenance resources.

In maintenance requests for non-change-prone modules, the process flow is as follows :

• Analyze code and identify change ’ Implement change and update documentation ’ Apply metric analysis ’ Compare with baseline ’ Check to see if it exceeds the threshold ’ If yes, then declare module to be "change-prone"; otherwise , declare module to be "non-change-prone"

The process for maintenance requests for a change-prone module is as follows:

• Identify the highest-level artifact affected by the request ’ Regenerate artifact ’ Identify artifacts that can be reused ’ Iterate through "development" ’ Declare module to be "nonchange-prone"

CONFIGURATION MANAGEMENT STEPS

The generic change management model consists of the following steps:

1. Change identification process. The change is visualized, described, assessed, classified , and approved.
2. Evaluation and coordination process. The cost, scope, and effects are evaluated.
3. Incorporation and verification process. Change is planned, scheduled, implemented, documented, and verified .

Change Identification

Each and every change needs to be uniquely identified. The premise behind configuration management is that every component of every system carries with it a unique identification number.

Rather than using a random numbering scheme, it is best to create a nomenclature system that is meaningful. An important component of the identification number is its classification. Most configuration management systems classify changes as "major" or "minor." A change is considered major if it has one or more of the following attributes:

• Affects baseline
• Affects one or more of the following: how the product behaves, safety, interface with other products, instructions, user skills, training
• Requires a retrofit or recall of products out in the field
• Affects cost, guarantees , or warranties

Minor changes do not impact customer requirements but usually affect configuration documentation or system processes not considered major, as itemized above.

Documentation of proposed major changes should include the following information so that an informed decision can be made as to whether or not to make the change:

• Change identifier
• Change effectivity (e.g., this is commonly done using a serial number and date of manufacture)
• Individual requesting change
• Class of change
• Products affected
• Interfaces affected
• Documents affected
• Description of change
• Effects of change (i.e., performance, training, etc.)
• Justification for change
• What would happen if change were not done
• Requested approval date
• Schedule
• Costs and savings
• Alternatives

Minor changes require, at minimum, the following information:

• Change identifier
• Change effectivity (e.g., this is commonly done using a serial number and date of manufacture)
• Individual requesting change
• Class of change
• Products affected
• Documents affected
• Description of change
• Justification for change

Evaluation and Coordination

The vast majority of organizations launch into their maintenance efforts without first ascertaining the effect of the desired change on the system as well as on the organization.

The proper methodology is to consider the cost, schedules, and impacts of all requested changes, garner approval, and then implement the change. But how can this be done effectively?

Traditional change requests filter up through the company via many sources. In general, however, changes are requested by end users who work on discrete systems. Change requests are then sent to the IT department for prioritization and implementation.

As problems arise or the need for change is discovered , the flow of these requests must be handled in a methodical way. Because each request is not equal to any other and they arrive at the project manager's desk at various times, a system has been developed by most IT departments. This system provides a logical path for the approval of requests, and prioritizes and organizes those that are approved. The project manager has the job of categorizing the requests and passing them on to the "priority board," which decides if the request is within the business model and what, if any, priority should be given to the change request. As decisions are made by the board, they are passed back to the project manager for action. It is the project manager who then reports back to the user regarding the decision and acts on the change based on the priority given.

The type of change and severity help decide what priority to give the change. If the change is important enough, it can be placed at the top of the queue for immediate action. If several changes occur in a single module, a batch change can be requested. A batch change involves making changes to an entire module at once to avoid working on the same module several times. This also allows users to view the changes as a single update that may change the use of a module through screen changes or functionality.

The queue of changes (see Figure 11.3) is a valuable tool in controlling the work that needs to be done. Items high in the queue receive the immediate attention they deserve, and those of lesser importance may never be acted on due to a change in needs or a new system that solves the problem.

Figure 11.3: Change Request Flow

Configuration management "change evaluation and coordination" adds a level of standardization to this process. The priority board should:

• Have as its chairperson someone with signatory authority (i.e., this person should be able to sign off on the requested change)
• Have a diversity of board members representing the major functional areas of the organization
• Be provided with an agenda of what will be discussed prior to each board meeting
• Be provided with all documentation (e.g., costs, schedules, alternatives, etc.) prior to each board meeting. The board needs to be fully informed as to all cost factors involved in the decision-making process. This should include cost of development, cost of implementation, and expected future costs.
• Document all decisions and then disseminate them to all affected departmental units

The change priority board should be provided with full documentation that includes a discussion of the lead-times associated with changing the product as well as whatever changes need to be made to affected associated areas. One of the problems with maintenance is that it often fails to assess the impact of change on peripheral but associated departments (e.g., is the sales department ready to sell the product; is the training department ready to train on the new product; are the required interfaces ready?) Effectivity is used to provide a clear and precise designation of what is going to be changed. Effectivity can be designated by serial number, date code, product group , version number, lot number, batch number, etc. Effectivity is a critical component of configuration management because it clearly distinguishes one product from another. For example, if a piece of software has both version 2 and version 3 implementations being used by end users, then a change to version 2 needs to be clearly distinguished from version 3.

A variation of the priority board discussed above is a series of tiered boards or committees . In this variation, priority boards are appointed at the unit level. Once changes have been approved at this level, they are passed to a priority board at the departmental level, and then finally to the organization-wide priority board.

Change Implementation and Verification

Change must be carefully planned. Planning should be done prior to making any changes. Implementation of a change requires the release of the following documentation:

• Requirements information
• Design information
• Operation instructions
• Build and test information
• Sales and marketing change information

The usual method of disseminating document changes is through a document change request (DCR) (see Appendix J).

Once the change has been proposed, approved, implemented, and documented, it is important that it be verified. Appendix E contains a sample test plan. Test plans should be created prior to the development of the original product. When the product is maintained , the test plan must be updated to reflect any changes to system functionality.

Handling Variances

There are always exceptions. In the case of change management, it is important that a product, whose change varies from the system requirements, not be delivered to the end user unless the variance has been fully documented and fully authorized.

MANAGING MAINTENANCE PERSONNEL

As systems age and demand increases for maintenance personnel, there has been loud debate over just who should be doing the maintaining. Should it be the original developers? Or should it be a separate maintenance department? Many have argued that the people who developed the system should maintain it. The logic here is that they will best understand the system and be better able to change the system [Swanson 1990]. This logic is correct but difficult to fulfill because developers want to keep building new stuff and consider maintenance a less desirable function. IT professionals view maintenance as fixing someone else's mistakes. One solution to this problem has been tried recently; it involves rotating IT personnel from development to maintenance and back to allow everyone to share in the desirable as well as undesirable functions of the department.

MEASURING EFFECTIVENESS

An important part of configuration management is to understand and measure the effectiveness of the maintenance process. As a system is implemented, service requests may be quite high as bugs are still being worked out and needs for change are discovered . If the maintenance process is operating properly, an immediate decrease in failures should be seen (Figure 11.4). Good management of maintenance should include the recording of failures over time and analyzing these for effectiveness. If a decrease is not noticed, the problem should be identified and resolved.

Figure 11.4: Normal Distribution of Failures Following Implementation

Another measure of the success of the maintenance process is the time between failures. The longer the time between failures, the more time can be spent on improving the system and not just fixing the existing system [Lientz 1983]. Failures will happen, but more costly is the time taken to fix even the simplest failure.

Recording the type of failure is important in understanding how the failure happened and can assist in avoiding failures in the future. As this information is recorded and maintained as a permanent record of the system, solutions can be developed that fix the root cause of a variety of failures.

SUMMARY

Managing system maintenance requires that steps be taken similar to the development of new systems. System maintenance is, in many ways, an extension of the system development life cycle and involves similar steps to ensure that the system is properly maintained . As a new system is implemented, system maintenance is required to fix the inevitable errors and track them for future use. As a system ages and changes are requested , system maintenance has the job of categorizing, prioritizing, and implementing changes to the system. A configuration management approach ensures systematic, organized changes.

The proper management of system maintenance is vital to the continued success of the system. A well-managed systems maintenance department can save time and money by providing an error-free system that meets the needs of the users it serves.

REFERENCES

Curtis, G., J. Hoffer, J. George, and S. Valacich, Introduction to Business Systems Analysis , Pearson Custom Publishing, Boston, MA, 2000 .

Electronic Industries Alliance, EIA-649, National Consensus Standard for Configuration Management, 1998 .

Gibson, V. and J. Senn, "System Structure and Software Maintenance Performance," ACM Press, New York, 1989 .

Guimaraes, T., "Managing Application Program Maintenance Expenditures," ACM Press, New York, 1983 .

Harrison, W. and C. Cook, "Insights on Improving the Maintenance Process through Software Measurement," no data http://www.cs.pdx.edu/~warren/Papers/CSM.htm

Hulse, C., S. Edgerton, M. Ubnoske, and L. Vazquez, "Reducing Maintenance Costs through the Application of Modern Software Architecture Principles," ACM Press, New York, 1999 .

Lientz, B., "Issues in Software Maintenance," ACM Press, New York, 1983 .

Lientz, B.P. and E.B. Swanson, "Characteristics of Application Software Maintenance," Communications of the ACM , 21 (6), 466 “481, June 1978 .

Lientz, B.P. and E.B. Swanson, "Problems in Application Software Maintenance," ACM Press, New York, 1981 .

Swanson, E.B., "Departmentalization in Software Development and Maintenance," ACM Press, New York, 1990 .

Unknown, "How to Increase Uptime," Cognizant Applications Maintenance Solution Series, Cognizant Technology Solutions Corporation, 2000 .

Unknown, "16 Critical Software Practices for Performance-Based Management," QSM, Inc., 1999 , http://www.techrepublic.com