Design Issues for Software Analysis and Maintenance Tools

An empirical study of software maintenance tasks was carried out in a large Norwegian organization in the period 1992–93. More than one hundred randomly selected maintenance tasks were studied through interviews with the maintainers performing the tasks immediately before they started the tasks and immediately after they had completed the tasks. The collected data is used to develop distributions and to test 33 hypotheses about software maintenance. The findings from the study indicate, for example, that Application system documentation plays only a minor role as maintenance information source. The maintenance productivity, measured in LOC/effort, is predicted by the size of the task and type of change in the source code, but seems rather independent of language level, maintainer experience, application age and application size. There is an economy of scale for software maintenance tasks. The type of programming language does not correlate with proportion of unexpected maintenance problems, task complexity or task size. The proportion of corrective maintenance decreases with increasing age of the application.

Computer-aided software engineering (CASE) tools have been advocated for improving maintainer productivity and the quality of maintained software. While there is evidence that such benefits can accrue to organizations adopting maintenance-oriented CASE tools, a key problem in achieving the desired benefits from CASE tools is low usage of these tools by programmers. The previously tested Maintenance Tool Utilization Model was a first step in investigating the factors that affect whether maintainers choose to use CASE tools during maintenance projects. We test the addition of experience with software maintenance tools and with the software maintenance task to the Maintenance Tool Utilization Model. The role of experience is important because managers can provide training to increase experience and they can ensure that project teams have some members experienced with the tools or with the task. Data for the test are collected from software maintainers working on their organization’s normal maintenance project backlog. Tool experience is significant as both a main and interaction effect, but task experience adds little to the explanatory power of the Maintenance Tool Utilization Model. These results support the value of improved CASE tool training programs.

Computer-Aided Software Engineering (CASE) tools have been advocated for improving maintainer productivity and the quality of maintained software. While there is evidence that such benefits can accrue to organizations adopting maintenance-oriented CASE tools, a key problem in achieving the desired benefits from CASE tools is low usage of these tools by programmers. The previously tested Maintenance Tool Utilization Model was a first step in investigating the factors that affect whether maintainers choose to use CASE tools during maintenance projects. We test the addition of experience with software maintenance tools and with the software maintenance task to the Maintenance Tool Utilization Model. The role of experience is important because managers can provide training to increase experience and they can ensure that project teams have some members experienced with the tools or with the task. Data for the test are collected from software maintainers working on their organization’s normal maintenance project backlog. Tool experience is significant as both a main and interaction effect, but task experience adds little to the explanatory power of the Maintenance Tool Utilization Model. These results support the value of improved CASE tool training programs.

Bug reports are widely employed to facilitate software tasks in software maintenance. Since bug reports are contributed by people, the authorship characteristics of contributors may heavily impact the performance of resolving software tasks. Poorly written bug reports may delay developers when fixing bugs. However, no in-depth investigation has been conducted over the authorship characteristics. In this study, we first leverage byte-level $N$-grams to model the authorship characteristics and employ Normalized Simplified Profile Intersection (NSPI) to identify the similarity of the authorship characteristics. Then, we investigate a series of properties related to contributors authorship characteristics, including the evolvement over time and the variation among distinct products in open source projects. Moreover, we show how to leverage the authorship characteristics to facilitate a well-known task in software maintenance, namely Bug Report Summarization (BRS). Experiments on open source projects validate that incorporating the authorship characteristics can effectively improve a state-of-the-art method in BRS. Our findings suggest that contributors should retain stable authorship characteristics and the authorship characteristics can assist in resolving software tasks.

One of the most frequent problems faced by software maintainers is to find the location of the code related with specific features. This is a costly task because features tend to be scattered in the code. Considering this problem, several approaches for locating features using dynamic analysis have been developed. Nonetheless, the use of dynamic analysis is not fully incorporated in the daily practice of software maintainers. Empirical studies that reveal strengths and weaknesses of the use dynamic analysis in maintenance tasks can bring better understanding of this problem. This study contributes with an empirical assessment of the use of execution traces on software maintenance. We report on a controlled experiment performed with developers when they were performing actualmaintenance activities on systems of different sizes. There are benefits related with a systematic use of execution traces by reducing the execution time and increasing the correction of the developer task during software maintenance. Also, a lower level of difficulty of the tasks was perceived by the participants using dynamic information. Another conclusion is that the approach seems to be useless in maintenance activities where the problem of feature scattering does not occur clearly. This study also reveals that there are still some challenges related to false negatives.

Software maintenance is an important phase in the software life cycle. It focuses on keeping the software fully functional and up to date. Maintenance engineers used different approaches and methods to gain understanding of software systems so maintenance tasks can be performed effectively. A lot of efforts have been put into finding a way to measure maintainability of software. It is a common opinion that software maintainability should be described using a set of measurable software attributes. This paper looks at the issue of rule-based description of attributes of software with different levels of maintainability. Varieties of rules are extracted from a data set that represents human evaluation of maintainability of software objects. Rule similarity and rule inclusion measures are used to identify the most diverse sets of rules representing human evaluation criteria. Additionally, the rules representing all evaluators are analyzed using a rule similarity concept in order to learn more about common evaluation criteria

Most of today's industries, from engineering to agriculture to health, are run on software. In such a context, ensuring software quality play an important role in most of current working environment and have a direct impact in any scientific and technical discipline. Software maintenance and testing have the crucial goal to find or discover possible software bugs (or defects) as early as possible, enabling software quality assurance. However, software maintenance and testing are very expensive and time-consuming activities for developers. For this reason, in the last years, several researchers in the field of Software Engineering (SE) devoted their effort in conceiving tools for boosting developers productivity during such development, maintenance and testing tasks. In this talk, I will first discuss some empirical work we performed to understand the main socio-technical challenges developers face when joining a new software project. I will discuss how to address them with the use of appropriate recommender systems aimed at supporting developers during program comprehension and maintenance tasks. Then, I'll show how Summarization Techniques are an ideal technology for supporting developers when performing testing and debugging activities. Finally, I will summarize the main research advances, the current open challenges/problems and possible future directions to exploit for boosting developers productivity.

Software maintenance seen as a knowledge management issue

Unit testing represents a key activity in software development and maintenance. Test suites with high internal quality facilitate maintenance activities, such as code comprehension and regression testing. Several guidelines have been proposed to help developers write good test suites. Unfortunately, such rules are not always followed resulting in the presence of bad test code smells (or simply test smells). Test smells have been defined as poorly designed tests and their presence may negatively affect the maintainability of test suites and production code. Despite the many studies that address code smells in general, until now there has been no empirical evidence regarding test smells (i) distribution in software systems nor (ii) their impact on the maintainability of software systems. This paper fills this gap by presenting two empirical studies. The first study is an exploratory analysis of 18 software systems (two industrial and 16 open source) aimed at analyzing the distribution of test smells in source code. The second study, a controlled experiment involving twenty master students, is aimed at analyzing whether the presence of test smells affects the comprehension of source code during software maintenance. The results show that (i) test smells are widely spread throughout the software systems studied and (ii) most of the test smells have a strong negative impact on the comprehensibility of test suites and production code.

A software is developed to satisfy some requirements that could change with respect to technology progress or new clients needs. That is why a software evolves continually in order to fit with occurring requirements. Software evolution or maintenance represents a non-trivial issue that should be treated seriously. In fact, according to some studies software maintenance could consume about 80% of software development total cost. In most of works, such issue was treated in a source code level by proposing new techniques and tools that could optimize maintenance cost. In this paper, we treat the same issue but in an earlier phase of software development and exactly in software design. We propose here an UML profile that allows to software developers and designers to carry about maintenance tasks at the design phase in order to predict handling maintenance tasks before happening, to get an historical trace of these tasks and to express explicitly on models some design patterns helping to resolve software maintenance problems in order to make maintenance easier and cheaper.

How to identify class comment types? A multi-language approach for class comment classification

Software maintenance is an expensive activity that consumes a major portion of the cost of the total project. Various activities carried out during maintenance include the addition of new features, deletion of obsolete code, correction of errors, etc. Software maintainability means the ease with which these operations can be carried out. If the maintainability can be measured in early phases of the software development, it helps in better planning and optimum resource utilization. Measurement of design properties such as coupling, cohesion, etc. in early phases of development often leads us to derive the corresponding maintainability with the help of prediction models. In this paper, we performed a systematic review of the existing studies related to software maintainability from January 1991 to October 2015. In total, 96 primary studies were identified out of which 47 studies were from journals, 36 from conference proceedings and 13 from others. All studies were compiled in structured form and analyzed through numerous perspectives such as the use of design metrics, prediction model, tools, data sources, prediction accuracy, etc. According to the review results, we found that the use of machine learning algorithms in predicting maintainability has increased since 2005. The use of evolutionary algorithms has also begun in related sub-fields since 2010. We have observed that design metrics is still the most favored option to capture the characteristics of any given software before deploying it further in prediction model for determining the corresponding software maintainability. A significant increase in the use of public dataset for making the prediction models has also been observed and in this regard two public datasets User Interface Management System (UIMS) and Quality Evaluation System (QUES) proposed by Li and Henry is quite popular among researchers. Although machine learning algorithms are still the most popular methods, however, we suggest that researchers working on software maintainability area should experiment on the use of open source datasets with hybrid algorithms. In this regard, more empirical studies are also required to be conducted on a large number of datasets so that a generalized theory could be made. The current paper will be beneficial for practitioners, researchers and developers as they can use these models and metrics for creating benchmark and standards. Findings of this extensive review would also be useful for novices in the field of software maintainability as it not only provides explicit definitions, but also lays a foundation for further research by providing a quick link to all important studies in the said field. Finally, this study also compiles current trends, emerging sub-fields and identifies various opportunities of future research in the field of software maintainability.

An improving approach to analyzing change impact of C programs

Program comprehension is a required activity for many software development and maintenance tasks. A common means of understanding software is though UML diagrams. UML diagrams model the design and implementation of an application, describing both its structure and behaviour. However with rapid software development life cycles, UML diagrams often become inconsistent with the implementation of an application. This limits their effectiveness in program comprehension activities. This paper presents a program analysis framework to reverse engineer sequence diagrams from application source code. Part of this framework is the ability to filter out irrelevant operations from a sequence diagram in order to simplify the representation of an application. This is achieved by identifying important data, and following its use in the application. The purpose of this framework is to aid in program comprehension activities by providing up to date representations of an application; while also enabling developers to identify the logical operation of a program without interference from irrelevant or supporting operations.

Most of our current understanding of how programmers perform various software maintenance and evolution tasks is based on controlled studies or interviews, which are inherently limited in size, scope, and realism. Replicating controlled studies in the field can both explore the findings of these studies in wider contexts and study new factors that have not been previously encountered in the laboratory setting. While replicating controlled studies in the field seems like an obvious next step in scientific progress, it is a step that has rarely been attempted, in part due to its complexity, which requires not only the industrial knowhow to implement a robust, scalable system, but the academic knowledge of how to design rigorous studies. In this talk, I will describe a few examples of successfully scaled studies, contrast them with less successful cases (including our own), and provide lessons learned. I will share the importance of collecting targeted information instead of generic logs, the insight that automated data collection paired with followup surveys is a powerful tool, and the nuances around what researchers can and cannot expect working developers to tolerate for the sake of research.