Measuring Architectural Change for Defect Estimation and Localization

Steff, Maximilian; Russo, Barbara

doi:10.1109/esem.2011.31

Cited by 6 publications

(6 citation statements)

References 19 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In our previous work, we have presented and evaluated a measure for structural change as an indicator of faultproneness of classes [21]. We use a graph kernel, specifically the Neighborhood Hash Kernel (NHK) [8], to measure structural distance between the graph representations of consecutive releases of a software system.…”

Section: Methodsmentioning

confidence: 99%

“…Defects in issue trackers, for instance, might not be (correctly) reported for all code versions. In previous work, we presented a method to measure structural change in software systems and derived a metric for the fault-proneness of classes [21]. We represented software structure at the class-level and our timeline was given by the releases of the systems we examined.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Characterizing the roles of classes and their fault-proneness through change metrics

Steff

Russo

2012

Proceedings of the ACM-IEEE International Symposium on Empirical Software Engineering and Measurement

Self Cite

View full text Add to dashboard Cite

Many approaches to determine the fault-proneness of code artifacts rely on historical data of and about these artifacts. These data include the code and how it was changed over time, and information about the changes from version control systems. Each of these can be considered at different levels of granularity. The level of granularity can substantially influence the estimated fault-proneness of a code artifact. Typically, the level of detail oscillates between releases and commits on the one hand, and single lines of code and whole files on the other hand. Not every information may be readily available or feasible to collect at every level, though, nor does more detail necessarily improve the results. Our approach is based on time series of changes in method-level dependencies and churn on a commit-to-commit basis for two systems, Spring and Eclipse. We identify sets of classes with distinct properties of the time series of their change histories. We differentiate between classes based on temporal patterns of change. Based on this differentiation, we show that our measure of structural change in concert with its complement, churn, effectively indicates fault-proneness in classes. We also use windows on time series to select sets of commits and show that changes over short amounts of time do effectively indicate the fault-proneness of classes.

show abstract

Section: Methodsmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Characterizing the roles of classes and their fault-proneness through change metrics

Steff

Russo

2012

Proceedings of the ACM-IEEE International Symposium on Empirical Software Engineering and Measurement

Self Cite

View full text Add to dashboard Cite

show abstract

“…They also used network measures as an aid for developers in indicating important files and binaries. In our previous work (Steff, 2011), we added to this area of research by showing that the change of dependencies, i.e. structural change, was an even stronger indicator of faulty classes than static measures thus far presented in the literature.…”

Section: Defect Predictionmentioning

confidence: 99%

“…These labels allow us now to compare the neighborhood structure of nodes across releases. The number of distinct bit labels (NDBL) measure introduced in (Steff, 2011) reflects changes for each neighborhood size. However, we use it only pairwise on bit labels l for consecutive releases r-1 and r, such that we obtain for each class:…”

Section: Design Churn (Independent Variable)mentioning

confidence: 99%

See 1 more Smart Citation

Design Churn as Predictor of Vulnerabilities?

Hovsepyan

Scandariato

Steff

et al. 2014

International Journal of Secure Software Engineering

Self Cite

View full text Add to dashboard Cite

This paper evaluates a metric suite to predict vulnerable Java classes based on how much the design of an application has changed over time. We refer to this concept as design churn in analogy with code churn. Based on a validation on 10 Android applications, we show that several design churn metrics are in fact significantly associated with vulnerabilities. When used to build a prediction model, the metrics yield an average precision of 0.71 and an average recall of 0.27.

show abstract