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

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Chapter 6. Change Dynamics<br />

ing a loosely coupled modular architecture has been considered ideal<br />

in the literature on s<strong>of</strong>tware design [257], <strong>and</strong> our observations provide<br />

further empirical evidence to support the benefits <strong>of</strong> this strategy.<br />

6.4 Related work<br />

Change in s<strong>of</strong>tware has been a subject <strong>of</strong> study by a number <strong>of</strong> other<br />

researchers <strong>and</strong> in this section we present key related work to place our<br />

own work in context.<br />

Kemerer <strong>and</strong> Slaughter studied the pr<strong>of</strong>ile <strong>of</strong> s<strong>of</strong>tware maintenance in<br />

five business systems at the granularity <strong>of</strong> modules by analysing maintenance<br />

log data. The business systems were closed source <strong>and</strong> not<br />

developed using object oriented programming languages. Kemerer et<br />

al. conclude that very few modules change frequently, <strong>and</strong> those that<br />

do are considered to be strategic [148]. Interestingly, our findings are<br />

similar, even though our analysis is based on release history <strong>and</strong> Open<br />

Source Systems developed using an object oriented programming language.<br />

The commonality in finding suggests that developers approach<br />

s<strong>of</strong>tware change carefully <strong>and</strong> tend to minimise them as much as possible,<br />

independent <strong>of</strong> the licensing <strong>and</strong> development method used.<br />

Similar to our work, Capiluppi et al. have analyzed the release history<br />

<strong>of</strong> a number <strong>of</strong> Open Source Systems [35, 39–41] with an intention <strong>of</strong><br />

underst<strong>and</strong>ing if developers will undertake anti-regressive work, i.e.,<br />

make changes to reduce the complexity <strong>of</strong> a certain module <strong>and</strong> hence<br />

improve maintainability. Their studies mainly focused at a macro-level,<br />

in particular on relative changes in the code size <strong>and</strong> on complexity at a<br />

module level [41] as well as the influence <strong>of</strong> the number <strong>of</strong> developers on<br />

the release frequency [39]. Their conclusions were that in Open Source<br />

Projects, relatively little effort is invested in anti-regressive work. In our<br />

study we found that developers minimize the frequency <strong>and</strong> magnitude<br />

<strong>of</strong> change, <strong>and</strong> the abstractions that do change tend to be popular or<br />

complex. Interestingly, if developers spend little effort on anti-regressive<br />

work, then it implies that the typical modification is to create new features<br />

or correct defects.<br />

174

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

Saved successfully!

Ooh no, something went wrong!