thesis - Faculty of Information and Communication Technologies ...

Chapter 6. Change Dynamics
A recent study into change by Gîrba et al. showed that classes that have
changed in the past are also those most likely to change in the future.
They also showed that these classes were the minority [92]. In related
and earlier work, Gîrba et al. have tested the hypothesis that classes
that have changed in the past are likely to change in the future [94].
The reliability of this measure of “yesterday’s weather” seems to vary
according to the “climate” of a software project. Gîrba et al. have also
studied the relationship between change and developers [95]. Additionally,
Girba et al. in their studies tag a class as having changed if methods
were added or removed. They also identify change at the method
level by observing a change in the number of statement and the cyclomatic
complexity. In our study, we used a larger set of properties to
detect change and hence are able to identify more fine grained changes.
Rather than modeling and understanding the nature of change, their
goal was to understand which developers are most knowledgeable about
different parts of an evolving system.
Another arc in the study of change has been the area of understanding
co-change, where the assumption is made that certain groups of
classes or modules change together [85] because related features are
grouped together. This assumption was supported by research undertaken
by Hassan and Holt who analyzed many Open Source projects
and concluded that historical co-change is a better predictor of change
propagation [113]. This observation is also supported by Zimmerman et
al. [319,320] which led to the development of tools [315] that can guide
developers to consider a group of classes when they modify one class.
Our study however, aims at understanding the statistical properties of
post-release change and inherent properties of a class that might lead
them to change. The properties that we identified can improve project
plans and help during iteration retrospectives, rather than being able
to directly guide developers about potential co-changing classes. Furthermore,
Gall et al., Hassan et al., and Zimmerman et al. relied on the
revision history in their studies, and identify change during the development
phase. We however, investigated the release history and hence
are able to provide a post-release change perspective.
175