Change Impact Analysis in Maintenance Projects

Overview

The increasing complexity of software applications is leading to the increased complexity involved in the project design. In addition to code maintenance works, build configuration maintenance works are gaining prominence to ensure that unintended disruptions do not occur and slow down system functioning [64]. The researchers in [65] observed that poor build maintenance efforts result in the breakdown of the build configuration. The study in [66] reiterated the importance of build maintenance by studying the costs occurring due to building breakages. Any modifications in source or test codes also cause changes in build configuration files. In [67], Machine Learning techniques are proposed for training models to estimate build modifications on the basis of earlier changes in both sources and build files. The study in [68] further emphasized the feasibility of making these estimations across multiple projects.

This chapter attempts to improve the performance of these methods by modifying the source code and commit categories. The approaches suggested in [69,70] are utilized to extract source file modification features. A Change Distiller is a plugin that obtains code modifications on the basis of tree-differencing [71]. It extracts two versions of the source code and generates respective ASTs (Abstract Syntax Trees). By comparing these two ASTs and mapping the differences to respective code modification classes, Change Distiller obtains changes. To classify commit messages, [72] suggested the division of these messages into four classes according to the content.

Change Impact Analysis Techniques for Source Code Modifications

The following paragraphs depict multiple Change Impact Analysis techniques suggested in different studies. The approaches which were empirically verified are presented.

Most Change Impact Analysis approaches rely on conventional static analysis models based on the dependency map. For instance, an impact set is calculated based on reachability as depicted in a dependency map. To boost the accuracy of Change Impact Analysis approaches, a few studies suggested [27-29] Change Impact Analysis approaches on the basis of data obtained in the code execution phase. Some of such information can be trace data, coverage or associated data, used to create the impact set.

In addition, specific Change Impact Analysis approaches [35,40] function on the basis of coupling metrics like a structural or associated topic or dynamic working. The related impact sets are estimated based on code sections coupled with modifications.

Further, the studies [5,27,36] focused on the extension of existing Change Impact Analysis approaches. Of these, two studies [5,27] were extensions to other contemporary methods [27,36] with minimal time and space overheads than the original. The study outcome suggested almost the same accuracy for both online and original approaches. The study depicted the superior performance of fine-tuned Change Impact Analysis at code level regarding accuracy compared to the original approach. However, the extended model involved more complexity and thereby more time periods were required. The researchers in [36] compared hybrid techniques by mixing the ranking of association rules with Granger [43].

Analyzing different Change Impact Analysis approaches, we can observe that almost all of these fall into four categories - conventional dependency based, mining from storage based, coupling metrics based and execution data based. Evolution of these studies over multiple years is depicted in Figure 5.1. As can be observed from the figure, mining approaches are the most focused studies with increasing interest in the past few years. Mining from repositories enables Change Impact Analysis analysts to extract valuable dependency data between different artefacts. Maintenance engineers rely on this historical information to estimate modifications to associated artefacts. On the contrary, simply depending on conventional code dependencies can have the possibility of not obtaining key dependency data.

■ Software reposrtor es

■ Coupling measurement

a Execution information collection

■ Traditional dependency anatyss

Figure 5.1 Distribution of the Change Impact Analysis techniques from four perspectives.

For instance, any code modifications recorded in a file may need related modifications in the code to enable reading such data irrespective of whether the data flow exists between the two code sections. Accordingly, stored data emerges as vital support for Change Impact Analysis approaches based on conventional methods.

In addition to mining-based studies, dynamic Change Impact Analysis approaches are also studied largely in the recent period. This is largely due to their ability to enhance the accuracy rates of impact results compared to conventional static approaches.

Predicting modifications - several research studies can be found in contemporary literature, focusing on estimation tasks, specifically deploying ML algorithms to analyze different features of programming. The study in [73] evaluated if a programmer must participate in email communications, while the study in [74] predicted fault proneness of the source code. In [75], researchers detected modification-prone language interfaces, and in [76], future bugs are predicted.

Change Impact Analysis for Software Framework

Most of the Change Impact Analysis techniques suggested in the literature have relied mostly on source code files [77]. This resulted in not many studies focusing on different artefacts of the program.

However, in the recent past, researchers have been working on extending Change Impact Analysis for the framework and design tasks. The study in [78] and [42] focused on the understanding of modifications in the source code and UML design. It used the conventional dependency approach for establishing the impact of adding or removing options. Sharafat and Tahvildari used probability-based approaches for determining the same. However, given the similarity of both source and UML files, they fail to offer solutions for understanding other UML methods like component maps. Further, they also restrict the analysis of the source code. Accordingly, these techniques can be regarded as a single-perspective and not as a multi-perspective.

In addition, the studies in [79] and [80] observed the proliferation of modification among different framework segments and system requirements through dependency techniques. This remains a vital phase for understanding the total proliferation and connectivity to the different framework, and implementation artefacts are needed. This ensures the complete prediction of assessing modification effects. However, a large gap exists between framework components and design artefacts.

A detailed analysis of existing studies suggests that two techniques can be implemented for handling heterogeneous program artefacts. However, even these techniques have several limitations, leading to further scope of work in the area. The following paragraphs detail the shortcomings of these techniques.

The study in [47] suggested a Change Impact Analysis technique and regression analysis for evaluating test and use data, class and sequence diagrams. The researchers suggested a new technique for categorizing test data based on its ability to be re-used, further testing or outdated status. The proposed Change Impact Analysis technique can be categorized under dependency Change Impact Analysis. The method could not include key UML artefacts like frequently utilized components. It also does not cover activity diagrams, restricting the use of the technique in practice and its extension to assess multiperspective Change Impact Analysis. Further, the study also ignores artefacts included in the source code.

The techniques studied in [81,82] focused on dependency approaches for observing test data and classes, among others. Dependencies are extracted from three sources. From the static source, the call graph is obtained; test cases assist in obtaining interdependency among models and needs. Mining techniques are employed to obtain more dependencies. Information from these three approaches is saved as traceability links. These links enable researchers to establish a proliferation of modifications among different artefacts. Similar to earlier studies, this study also fails to address multi-perspective modification requests. It also does not handle all source artefacts or framework components. It also needs instrumentation and involves human interference, resulting in large overheads for implementing the technique over a reasonably complex application.

CHANGE REQUEST IMPACT

Change Request Impact Analysis Tools

Overview

Several researchers have identified that performing the analysis of the impact at the time of maintenance and improvement stages of the life cycle of software has many advantages [83,84]. Several tools are developed for researching, which summarize the Impact Analysis merits. However, there could be a lack of noticeable tools made accessible to commercial developers.

The objective of this chapter is to research distinct tools of Impact Analysis, which are present either commercially or academically, and classify them per improved architecture. The other aim is to detect the tool’s features, which are resourceful for the developers to execute maintenance. The consequence of the findings needs to offer a base for further enhancement of the tool of Impact Analysis, which developers might utilize for code maintenance and evolution.

With increasing popularity, incessant combining and scrum or agile development, the rapid, effective evolution of code is becoming more significant. The code is committed by the developers, and consequently, a server is built which tests the builds and analyzes the static code. In incessant integration, while each developer is committing towards a similar baseline, it could be enormously crucial that the developer evades bad code committing whenever possible. The poor committing might turn to damage the build that stops any further checking of the analysis of the static code or tests from running.

The responsibility of developers is to assure that their commitment would not damage the build; however, it might still occur and could possibly disturb the workflow of the team.

Locally, running the regression tests is one of the models which developers utilize for assuring that their commitment would not damage the build. The developers select to run total tests or choose manually the subset of the tests, which are visible to be associated to set change. One of the confines is that locally running the test might take more amount of time, specifically when the developer selects to run entire tests at a time. Besides, the developer also selects incorrect tests subset that might still result in damaging the build.

Moreover, there were several strategies for Impact Analysis which were explored and developed. However, some of the tools were perceived to offer these strategies for developers of software. These strategies have exhibited the ability to enhance the maintenance of software and lessen the quantity of the error established into the significant baseline. It stands for a reason, where these strategies need to be condensed into tools usable by developers. They also identified the requirement for the effective tool development of Impact Analysis to assure continuous utilization and widespread strategies related to Impact Analysis [85,86].

The objective of the effective maintenance of software is to provide developers tools for detecting the propagation extent of changes and enable the developer to make a decision as to whether it is secure for committing the code. By analyzing and cataloguing the abilities offered by the current tools of Impact Analysis, we introduce what is presented today and detect any possible scope or further tools of Impact Analysis.

There are several tools which are present to execute the analysis of the impact, and only the subsets of tools have been selected for analyzing. This contribution concentrates on tools which are aimed by the developer in the development of the pre-commit stage before modifications have been combined into the main baseline of the project. This chapter discovers the tools which assist developers in answering for the query: What might happen when I make this modification? And they need to possess a degree of confidence regarding the integrity of an outgoing set of changes.

It could be recorded that there were distinct tools available which aid the realm of maintenance of software for the analysis of the impact, like the analysis tools of the static code. The analysis tools of the static code like check style 2 or find bugs 1 might greatly enhance the effectiveness and stability of the code by developers, by warning the developer for violating the standards of coding. These tools need to be utilized in combination with the tools of Impact Analysis to assure that the code has been combined in greater quality and would not impact the current baseline negatively.

Moreover, there are also an number of tools which assist the developer in understanding the framework and the association of the code, and most of them comprise elements of visualization. These tools are deliberated; however, most of them were omitted when they could not implement an intelligent model or algorithm, including the analysis of the impact.

It could also be recorded that the analysis of the impact term could be an extensive term. The analysis of the impact might be performed at several levels from a level of code to component of a system and even at the level of conceptual. Several tools have discovered which covers these distinct analyses. However, several were signified to be out of scope. The objective of this chapter is to concentrate on an analysis of the impact at the level of code by utilizing algorithms, which are able to analyze or parse the languages of programming.