Identifying Reasons for Software Changes Using Historic Databases

TLDR

Large‑scale software must continually evolve, and historic data show that changes arise mainly from adding features, fixing faults, or restructuring code for future maintenance. The study tests whether the textual description of a change is essential for understanding its purpose and whether difficulty, size, and interval differ across change types. An automated classifier was built to categorize maintenance activities based solely on the textual change description. The classifier matched developer judgments, revealed that size and interval did not differ across products, showed strong links between change type, size, and effort, identified many perfective changes, and yielded recommendations for leveraging version‑control data without adding developer overhead.

Abstract

Large-scale software products must constantly change in order to adapt to a changing environment. Studies of historic data from legacy software systems have identified three specific causes of this change: adding new features; correcting faults; and restructuring code to accommodate future changes. Our hypothesis is that a textual description field of a change is essential to understanding why that change was performed. In addition, we expect that difficulty, size, and interval would vary strongly across different types of changes. To test these hypotheses we have designed a program, which automatically classifies maintenance activity based on a textual description of changes. Developer surveys showed that the automatic classification was in agreement with developer opinions. Tests of the classifier on a different product found that size and interval for different types of changes did not vary across two products. We have found strong relationships between the type and size of a change and the time required to carry it out. We also discovered a relatively large amount of perfective changes in the system we examined. From the study we have arrived at several suggestions on how to make version control data useful in diagnosing the state of a software project, without significantly increasing the overhead for the developer using the change management system.