Studying volatility predictors in open source software

  • Authors:

  • Brandt Braunschweig;Neha Dhage;Maria Jose Viera;Carolyn Seaman;Sreedevi Sampath;Gunes A. Koru

  • Affiliations:

  • University of Maryland, Baltimore County, Baltimore, MD, USA;University of Maryland, Baltimore County, Baltimore, MD, USA;University of Maryland, Baltimore County, Baltimore, MD, USA;University of Maryland, Baltimore County, Baltimore, MD, USA;University of Maryland, Baltimore County, Baltimore, MD, USA;University of Maryland, Baltimore County, Baltimore, MD, USA

  • Venue:
  • Proceedings of the ACM-IEEE international symposium on Empirical software engineering and measurement
  • Year:
  • 2012

Quantified Score

Hi-index 0.00

Visualization

Abstract

Volatile software modules, for the purposes of this work, are defined as those that are significantly more change-prone than other modules in the same system or subsystem. There is significant literature investigating models for predicting which modules in a system will become volatile, and/or are defect-prone. Much of this work focuses on using source code-related characteristics (e.g., complexity metrics) and simple change metrics (e.g., number of past changes) as inputs to the predictive models. Our work attempts to broaden the array of factors considered in such prediction approaches. To this end, we collected data directly from development personnel about the factors they rely on to foresee what parts of a system are going to become volatile. In this paper, we describe a focus group study conducted with the development team of a small but active open source project, in which we asked this very question. The results of the focus group indicate, among other things, that a period of volatility in a particular area of the system is often predicted by a pattern characterized by inactivity in a certain area (resulting in that area becoming less mature than others), increased communication between developers regarding opportunities for improvement in that area, and then the emergence of a champion who takes the initiative to start working on those improvements. The initial changes lead to more changes (both to extend the improvements already made and to fix problems introduced), thus leading to volatility.