1. Introduction
The most costly process during the whole Software Development Life Cycle (SDLC) is Software maintenance [1] and according to a recent study [2], it has been observed that almost 90% effort and cost in a software project is spent on the maintenance of the software systems. The major effort in software maintenance goes into understanding and bringing changes in the software code. Modifications to the software keep on coming due to various reasons like error correction, adapting to a different environment and for adding new functionality etc. Analyzing these changes, implementing the necessary ones and ensuring the consistency of software with other interacting entities is a very challenging task. To make sure that the software functions as desired, even after the introduction of changes, a systematic and careful Software Change Impact Analysis (CIA) is required, so that the effects of the change can be predicted and accordingly, further actions can be initiated. It includes a variety of techniques that are used to find out the possible effects a change may have on other software elements known as ripple effects.
A small change in a module may ripple through and may create adverse effects in the software. Therefore CIA is very essential before making any changes in the software. Even the decision to undergo changes during maintenance depends on the result of Change Impact Analysis. Any change during the maintenance causes retesting of not only the changed module but also those modules which are directly or indirectly related to it. i.e. regression testing. Planning for regression testing needs accurate Change Impact Analysis because unnecessary retesting increases the cost of maintenance and delay the delivery of the software to the client. CIA can also be used to determine what all other entities (other than code), for example, design, is required to be changed to maintain the consistency of code with other entities.
Several definitions of CIA exist in the literature. However, the most widely recognized and quoted definition proposed by Bohner et al. [3] in 1996 is “CIA is the process of identifying the potential consequences of a change, or estimate what needs to be modified to accomplish a change [3]”. Prior to them, Pfleeger et al. [4], in 1990 defined CIA as “the evaluation of the many risks associated with the change, including estimates of the effects on resources, effort, and the schedule [4]”. Before that, Horowitz et al. [5], in1986 defined CIA as “an examination of an impact to determine its parts or elements [5]”. Over the past 30 years, so many definitions and techniques have been proposed by various researchers.
1.1 CIA Process
The most widely used systematic CIA process [6] is given below in Figure 1.
Figure 1: Systematic CIA Process
Step 1: Analyze change request and the software
CIA process begins by analysis of change requests and identification of areas in source code that may be affected due to the introduction of change. Here, a set called Change Set is prepared which includes the initial impacted areas due to change introduction. This identification of an initial location for change in source code is referred to as “feature location” [7]. Various techniques for identifying feature location are available in literature which are discussed in Section 3.
Step 2: Estimate change effects
In the second step, the impact of the changes on other elements in the software are estimated using various change impact analysis techniques and a set known as Estimated Impact Set (EIS) is created.
Step 3: Implement change request
Here, the actual implementation of changes is done to fulfill the change request and the components are actually modified. The Actual Impact Set (AIS) includes all locations where actual changes have been implemented.
FNIS is a set of extra elements impacted by CIA process that were not estimated by EIS. It means that during change implementation, developers may come across some parts in software that were initially not considered to be part of EIS. Thus FNIS denotes an underestimation of impacts.
FPIS is a set of extra elements included in EIS that don’t require any modifications. It means that during change implementation, developers realize that some areas that were considered as requiring changes don’t need to be modified at all. Thus, FPIS denotes the over-estimation of impacts.
The ultimate objective of carrying out CIA is to make sure that the difference between EIS and AIS is zero. The relationship among all these sets can be represented as:
(EIS+FNIS)-FPIS=AIS
Eq 1: Relationships among various Sets
The objective of the whole CIA process is about generating an Estimated Impact Set that is equal to the Actual Impact Set but it’s seldom achieved. This objective can be achieved only through a careful selection of apt CIA techniques. To check the accuracy of CIA techniques, various metrics exist; however, the most accepted are Precision and Recall [8] where Precision refers to the extent to which estimated impacts (EIS) coincide with the actual impacts brought up by changes; Recall is to what extent the Estimated Impact Set covers the actual changes.
Precision= |EIS ⋂ AIS| / |EIS|
Eq 2: Formula to calculate Precision
Recall= | EIS ⋂ AIS | / |AIS|
Eq 3: Formula to calculate Recall
EIS with high precision is an indicator of less time spent in identifying the location of changes and implementing those changes. EIS with high recall means all the impacts of those proposed changes will be taken into consideration.
1.2 Techniques for Generating Estimated Impact Set (EIS)
A lot of work on CIA has been done in recent past [10-16] and researchers have proposed numerous techniques and approaches for generating EIS in CIA process. Broadly, CIA techniques can be categorized into three types: Traceability CIA, Dependence Based CIA and Experiential Based CIA [8, 18].
Fig. 2: Types of CIA
Verlag: BookRix GmbH & Co. KG
Tag der Veröffentlichung: 19.05.2020
ISBN: 978-3-7487-4193-0
Alle Rechte vorbehalten