20.01.2014 Views

thesis - Faculty of Information and Communication Technologies ...

thesis - Faculty of Information and Communication Technologies ...

thesis - Faculty of Information and Communication Technologies ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Chapter 6. Change Dynamics<br />

portion <strong>of</strong> the code from the previous versions. The second re-write<br />

ab<strong>and</strong>oned much <strong>of</strong> the code base <strong>and</strong> started on top <strong>of</strong> another opensource<br />

project. This level <strong>of</strong> fluctuation, <strong>and</strong> continuous change effectively<br />

meant that developers did not have sufficient time to increase the<br />

maturity <strong>of</strong> the project as it was consistently undergoing substantive<br />

changes.<br />

Although a higher degree <strong>of</strong> violations <strong>of</strong> these change properties does<br />

not imply a poor quality s<strong>of</strong>tware system, consistent <strong>and</strong> repeated violations<br />

can indicate an unusual phase within the project which may<br />

required additional attention or appropriate documentation to properly<br />

communicate the state <strong>of</strong> the project to all stakeholders. This type <strong>of</strong><br />

summarised information is <strong>of</strong>ten masked in s<strong>of</strong>tware project due to the<br />

large volume <strong>of</strong> changes that take place, <strong>and</strong> because <strong>of</strong> a lack <strong>of</strong> empirically<br />

derived heuristics.<br />

6.3.2 Rate <strong>and</strong> Distribution <strong>of</strong> Change<br />

Modifications are unavoidable as systems are maintained. However,<br />

very few <strong>of</strong> the classes tend to experience a high level <strong>of</strong> modification.<br />

Of the classes that have changed, most have been touched a few times –<br />

only a small proportion is modified several times. This modification pr<strong>of</strong>ile<br />

is very similar in all systems under analysis, suggesting that most<br />

classes in a system tend to reach a stable state very quickly. Combined<br />

with our earlier observation that a good proportion <strong>of</strong> code is never<br />

touched between releases, this suggests that development teams tend<br />

to create a stable set <strong>of</strong> abstractions very quickly. Our findings provide<br />

further support to a similar conclusion reached by Kemerer et al. [148]<br />

based on an analysis <strong>of</strong> maintenance logs.<br />

Although our approach does not reveal the actual amount <strong>of</strong> code that<br />

has changed, it provides us with a broad indicator. One <strong>of</strong> the systems<br />

that has resisted changes was Wicket, a web application development<br />

framework. Interestingly, the rate <strong>of</strong> modification in Wicket was close to<br />

many other systems. However, the observed distribution <strong>of</strong> these modifications<br />

suggests that most <strong>of</strong> the changes were minor fixes. At the<br />

167

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!