Deriving Change Architectures from RCS History

As software systems evolve over a series of releases, it becomes important to know which components show repeated need for maintenance. Deterioration of a single component manifests itself in repeated and increasing problems that are local to the component. A second type of deterioration is related to interactions between components, that is, components are repeatedly change-prone in their relationships with each other. The latter requires changes to code in multiple components and is a sign of problems with the software architecture of the system. Software architecture problems are by far more costly to fix and thus it is very desirable to identify potential architectural problems early and to track them across multiple releases. This paper uses Revision Control System (RCS) change history to determine which system parts are the most change-prone, both locally and in their interactions with other parts of the systems. Relationships among system components are identified based on whether they are involved in the same group of changes, and how many lines of code are changed. The resulting change architecture figures show what the system’s most change-prone components and relationships are. We illustrate our technique on a large commercial system consisting of over 800 KLOC of C, C++, and microcode. KEY WORDS software architecture, reverse architecting, software maintenance