• No results found

Software change management – Technological dimension

Change management support has to involve all of the following facets: the groups involved with the change and change activity have to be co-ordinated and managed, the change must be supported by organisational change manage- ment process models, and technical support for change activities has to be pro-

vided (Michelis et al. 1997). Software change management tools and systems do not aim at reducing the rate of change, but they aim to reduce the overall costs of change management by facilitating the speed with which changes can be processed (Jones 1996).

The techniques used for supporting change management can be categorised into generic software engineering techniques and change management specific tech- niques (Mäkäräinen 1996). Generic software engineering techniques have been designed or are used in general for software development, but are vital in soft- ware change management, as well. These techniques include, for example, soft- ware configuration management environments (Ince 1994) and basic develop- ment tools, such as compilers, debuggers and editors.

However, special techniques for supporting software change management exist. These include, for example:

• Impact analysis techniques for analysing and modelling the impacts of the modification in the system. These techniques are useful, for example, in project schedule estimation, consistency checking and risk analysis (Arnold 1993, Arnold & Shawn 1996, Queille et al. 1994).

• Change request tracking to support management of change requests. The change requests are triggers for change. Their purpose is to (1) express a need for a change, and (2) to document change activities by providing change histories for individual changes and the software entities. The bene- fits of change request tracking systems usually are in documenting and communicating the changes.

• Reverse engineering techniques for deriving higher level descriptions from lower level presentations to help in understanding the software and im- proving its quality by the terms of understandability and consistency by up- dating outdated documentation (Chikofsky & Cross 1990, Sneed 1995, McClure 1989). Examples of such techniques are tools generating graphical design descriptions from source code, for example the ReverseNICE tool by Intecs Sistemi for generating HOOD descriptions from Ada source code.

• Regression testing for assuring that the modification has not created unde- sirable side effects in the system. Regression testing tools usually repeat old test cases and compare the new test results with the old ones in order to find out deviations.

One of the greatest challenges of change management is to keep the system parts and several abstraction levels of the system consistent with each others. This can be supported by an integrated software development and maintenance envi- ronment, where the tools used for creating and managing the software systems are able to communicate with each other and can share common parts (Cutillo et al. 1996).

Figure 12 presents an example of an integrated software change management environment, where the tools used for software modifications and development are able to communicate with each other and share knowledge. The environment was developed in the AMES project (AMES 1993). The tool environment pre- sented here was constructed to support change activities defined by the V model for software change. The technical dimension of change management is there- fore defined by the selected process model. The change process (adapted from Harjani & Queille 1992) is presented in the upper part of the diagram and the individual tools used in change management are linked with the process via a process support tool. In this example, change request tracking is performed by the process support tool. The interoperability service provides a link between the tools. All software related items are stored in one archive, which is used by all the tools through software configuration management. Links between se- mantically related software parts, different abstraction levels, composition structures, etc. are stored in a traceability database.

Problem understanding

Location

Solution analysis

Impact analysis & choice of solution Implementation Regression testing Acceptance testing Re-insertion Trigger

Process support tool

Ot h er c h an ge ma na g e m ent t o o ls A p p licatio n u n d er st a n d ing to ol Rev erse en gin eerin g too l N av igatio n & d ispla y to o l Im pact ana lysis to ol T esting to ols SCM Dev elop m e n t to ol s Software archive Traceability infromation Interoperability service Maintenance platform

Change management environment PROCESS

PLATFORM

Figure 12. An example of an integrated change management environment (Mäkäräinen 1996).

An integrated change management environment was developed in the AMES project using the requirements elicited from the case studies (the case studies

presented in appendices A and B were done within the context of the AMES project). The project delivered a set of methods and tools for managing software changes.

3.7 Summary

This chapter presented the results of the literature study focusing on the research related to software change management and its relationships to other related concepts. The typical change management problems presented in the literature were discussed. The special features of the domain of embedded software which create special needs and requirements for software change management were presented. The process and technology dimensions for improving software change management were discussed.

4 Analysis of the state of the practice

4.1 Overview

In order to get an understanding of the state of the practice viewpoint to soft- ware change management, three case studies were conducted to study the change management processes in companies developing embedded software. The goal was to characterise, describe and analyse the change management pro- cesses identified in the companies, and learn what the problems in change man- agement in software development and maintenance work in practice are. As a result, descriptions of the current status of change management in companies, and a list of problems identified and initial requirements for improvement were derived. The problem list was derived directly from the interview notes, or from the discussions and brainstorming sessions arranged to analyse the interview findings. The problems and requirements were directly stated by the interview- ees or attendees of the brainstorming sessions.

The analysis of problems in the organisations studied aims at complementing the general change management problems presented in the literature and dis- cussed in chapter 3.3. The problems identified in the case studies are related to the generic problems discussed in chapter 3.3. This shows what kind of practical problems can be caused by the generic change management problems discussed in the literature.