thesis - Faculty of Information and Communication Technologies ...

Chapter 6. Change Dynamics
changes [26], so we cannot conclude that defects are the main reason
for change.
A class that changes is likely to have higher In-Degree Count and higher
Branch Count. Simply put, complex classes have a higher probability of
change. Furthermore, this probability increases with the complexity of
the class.
6.3.6 Development Strategy and its Impact on Change
In our data set, three systems stand out as clear outliers: Saxon XML
processor, Axis web services library and iText PDF generation library.
All of these systems exhibited above average change both in terms of
the frequency as well as the magnitude. But, why should this be the
case? Is there a common shared trait?
It turns out that all three systems have one common attribute — they
were all built to satisfy well defined industry standards. Saxon and
Axis implement W3C (World Wide Web Consortium) standards for XML
and Web services, respectively. The iText library attempts to satisfy
the Adobe PDF specification. Saxon and iText are currently supported
by commercial (for-profit) organisations, while the Apache consortium
handles the Axis project (Apache is a non-profit organisation that manages
a large number of open source projects, including the popular
Apache Web server).
An inspection of the architecture documentation, discussion boards as
well as release notes revealed a consistent theme in all three systems.
In these systems developers made a choice early in the life cycle to incrementally
satisfy the specifications, rather than define a software system
that completely implements the standards as elaborated in the specifications.
In addition, the developers enhanced their software systems
as the specifications themselves were expanded and amended. Interestingly,
in these three systems developers did not create well defined
functional components early in the life cycle. The functional components
gained coherence and a clear responsibility over time. For in-
171