A number of reasons for the difficulty of software change management can be found in the literature. These include: age of software, loss of design knowl- edge, loss of original requirements, accumulation of problems and change needs, lack of design for change, time pressure, diversity of tools and informa- tion, poor image of change function, poor maintainability of just released soft- ware, code decay, few tools and methods, verification across several product versions, and focusing on developing new software instead of managing existing systems. The problems are examined in detail in the following subsections. The problems found during the literature study will be complemented in chapter 4 by an analysis of the problems identified by studying the change processes in com- panies developing embedded software.
Many software systems are old (Osborne & Chikofsky 1990). They have been designed and implemented using outdated methods and tools (Schneidewind 1987). The original developers of the system have seldom even known how long the system will be used. Examples can be found in systems which were not de-
signed to be able to operate beyond the year 2000 because the original develop- ers could not anticipate such a long lifetime for the system.
The design knowledge and the rationale behind the design decisions have disap- peared (Rugaber et al. 1990). No-one knows precisely what the software actu- ally does and why. The person changing the software often has to deal with incomplete or outdated documentation. In the best case the design decisions used are documented, but the design rationale behind the design decisions is very seldom recorded (Abbattista et al. 1994).
The original requirements have been lost. Software requirements are forgotten, and therefore often violated when the changes are implemented (Parnas 1996). The original requirement specification documents may have been incomplete to start with, often leaving out requirements which seem trivial at the time of de- fining the software requirements. Moreover, the requirement specification document may have become inconsistent with the actual system implementation during the evolution of the system, when new requirements have arisen or re- quirement changes have been made, and the related requirement specifications have not been updated.
The problems and change needs tend to accumulate. An implemented change prepares the way for the introduction of another (Pressman 1995). The error fixes create new errors. The error fix may be done in a hurry and with inade- quate resources, causing deficiencies in impact analysis and regression testing. Also, the quality of the system may deteriorate because of changes over time, resulting in more problems in understanding and modifying the system in the future (Brown 1993).
The software is not designed to be easily maintained or modified (Capretz & Munro 1994) (Brown et al. 1995). The quality requirements set for a system rarely have specific requirements concerning maintainability issues. As the pri- mary goal of the development phase is to release the system fulfilling the user requirements, the maintainability requirements are often considered to be of secondary importance.
Often the modification has to be done as quickly as possible. There is no time to think about the quality or the impacts of the change (Brown et al. 1995). The
modification activities interrupt the development work, and if they are not planned, they also cause delays in project schedules (Genuchten et al. 1992). During the software life cycle many different tools are used, and usually each tool manages only a subset of software-related information (Cutillo et al. 1996). This results in problems for software engineers in finding relevant information when managing changes to the system, and keeping the system consistent when developing and changing the system (Ketabchi & Sadeghi 1996).
The image of software change activity is not highly valued (Lano & Haughton 1993) (Kellner 1993). Often new programmers are assigned to maintenance tasks to ‘learn’ about the application domain and how to program. The changes are regarded as unplanned and unwanted tasks.
The maintainability of just released software is poor (Brown et al. 1995), and it gets worse during the maintenance history of the system (Jones 1989). It is too late to think about maintainability only after the software has been designed and delivered (Schneidewind 1987, Capretz & Munro 1994). Maintainability must be built into the system when the initial design and implementation decisions are made. Maintainability and modifiability should be planned and designed right from the beginning of the development work. The early design decisions are found to have more impact on software maintainability than the implemen- tation algorithms (Rombach 1987). Also, often the changes made to the system over time gradually degrade the system, decreasing its maintainability (Jones 1989) (Schneidewind 1987). Without proper management and attention to the quality of the software modification activities, the quality of the software dete- riorates over time. For example, the complexity of the source code may increase (Bennet 1993) and the documentation may become inconsistent with the source code (Briand et al. 1994, Brown et al.1995).
Few methods or tools for supporting software modification and change man- agement are in active use in companies (Layzell & Macaulay 1994). Several critical and laborious tasks, such as impact analysis and consistency checking, lack advanced tool support and usually have to be performed manually. During the last decade a lot of tool support from the research community has emerged (Kellner 1993), but it has not yet been effectively adopted by the industry (Chapin 1993, Brown et al. 1995).
The verification of a change is complicated, when the changed software part is shared by several products or product versions. The change has to work in all products in which the new software will be used. (Bergey et al. 1998) This problem is typical in companies who use the product line approach, where core components are used by several product projects. Propagation of changes made to core parts to multiple deployed products in the product line is challenging. (Bergey et al. 1998)
The main focus of software engineering research has been in software develop- ment (Ward 1993). Most of the research done in the field of software engineer- ing deals with methods, processes and tools for the development of new soft- ware, and largely ignores the software evolution and maintenance viewpoint (Schneidewind 1987). Advanced techniques exist for designing new software systems and forward engineering activities, but these techniques often neglect important aspects affecting the maintainability of the system, for example maintaining consistency between work products, defining and updating links between semantically related items, etc.