thesis - Faculty of Information and Communication Technologies ...

Chapter 3. Data Selection Methodology
History
Release History
Revision History
Project History
Description
Source code, binaries, release notes, and release
documentation
Version control logs, issue/defect records, Modification
history of documentation, Wiki logs
Messages (email, Instant message logs), Project
documentation (plans, methodology, process)
Table 3.1: The different types of histories that typically provide input
data for studies into software evolution.
composition of the actual software system. The other categories of information
tend to provide a supporting, indirect view and can help fill in
the gaps in understanding the evolution of a software system. However,
the information derived from the revision history and project history is
reliable only if the development team was disciplined enough to record
and archive it carefully. For instance, if most of the discussions in the
project happen on personal e-mail or verbally, then that category of information
is hard to obtain. Similarly, for version control logs and defect
repository data to be useful, developers must properly and regularly use
the appropriate tools and record information accurately.
Research work that focuses on analysing the release history studies the
actual outcome of changes, in most cases the source code over time.
The Laws of Software Evolution as defined by Lehman [167, 168, 174]
were built pre-dominantly from the analysis of release histories.
Researchers
that have focused on this area have been able to identify typical
patterns of evolution and change [27], construct statistical models
of growth and change [21,127,132,152,193,264,269,270,283,310], develop
methods to identify change prone components [109,149,253,281],
and have proposed methods to visualise evolution [1, 65, 79, 95, 163,
164,298]. An interesting contribution from studies of release history is
that modular architectures style can allow for rate of growth beyond
the sub-linear growth rate expected by the Laws of Software Evolution
[100, 200]. This insight provides some level of empirical support
for the recommendation from software engineering to build software as
loosely coupled modules [218, 302].
42