Size, Inheritance, Change and Fault-proneness in C# software.

Abstract

P u b l i s h e d b y E T H Z u r i c h , C h a i r o f S o f t w a r e E n g i n e e r i n g © J o t , 2 0 1 0 O n l i n e a t h t t p : / / w w w . Abstract This paper documents a study of change in commercial, proprietary C# software and attempts to determine whether a relationship exists between class changes and faults and the design context of a class, namely its size and inheritance relationships.Results showed a strong positive correlation between the size of a class and change-proneness but not for all the class features studied. Classes within a specific range of a) inheritance depth and b) number of children were found to be relatively more prone to change. For the fault data and for the same class features, similar results were found. The most striking result to emerge however was the existence of an inheritance depth 'interval' between which change (and faultproneness) were at their highest. Below and above that interval, both features were less prominent. The results thus add weight to the claims of other previous studies which suggest that there is an optimal level of inheritance, beyond which maintenance may become problematic from both a change and fault perspective.

The effect of refactoring on change and fault-proneness in commercial C# software

“…New areas have applied refactoring to useful effect, for example the different languages that many applications embody [20], to refactoring and non-functional properties [23], agile team activities [24] and search-based software engineering [28]. Finally, the work presented in this paper builds on several studies by the authors into refactoring [13][14][15]. This paper is an extension to these studies to determine if refactoring impacts change and fault-proneness.…”

“…An important research and practical, industry-relevant question remains unanswered: can the benefits of refactoring be quantified and, if so, is it worth doing refactoring? Second, to our knowledge, there has been only limited research to determine how refactoring is applied in evolving commercial software and little research that we know of to show a relationship between refactored code and subsequent change or fault-proneness [3,15,39]. Software practitioners need to be able to decide on a refactoring strategy that results in suitable rewards, i.e., gains in the long-term maintenance of software in return for the initial investment of refactoring.…”

“…Research in [13] showed that refactorings were commonly applied in commercial software, although the majority of refactorings were simple rather than the more complex inheritance-based refactorings. A number of characteristics of a class' design context were shown to impact the fault and change-proneness of software, including size and inheritance [15].…”

“…Replication of this study over other systems would reduce this threat, but we feel that as this system has been shown to have refactorings applied consistently with several other studied systems there is commonality in refactoring behaviour. Second, we have only looked at a subset (15) of the refactoring types that may have been applied and it is probable that many other types of refactoring had been applied to the code studied; in defence of this threat, the refactorings were selected by ex-industry developers as the most likely-to-be applied refactorings and represent a broad cross-section of refactorings. Additionally, these 15 refactorings are consistent with previous refactoring studies by Advani et al [1], Counsell et al [4] and Gatrell et al [13].…”

“…The implication of the research is that direct benefits can therefore be ascribed to the refactoring process. While some work has explored the relationship between refactoring and fault-proneness [3,15,39], the authors know of no other work that has made the link between reduced fault-proneness and refactoring over an evolutionary period in proprietary or open-source software.…”