We have seen that code churn and complexity are good predictors of failures. This led us to look at tying together these two pieces of information to effectively quantify the relationship between different pieces of code. In general, in any large-scale software development effort, a good software architecture enables teams to work independently on different components in the architecture. A software dependency is a relationship between two pieces of code, such as a data dependency (component A uses a variable defined by component B) or call dependency (component A calls a function defined by component B). Suppose that component A has many dependencies on component B. If the code of component B changes (churns) a lot between versions, we may expect that component A will need to undergo a certain amount of churn in order to keep it in sync with component B. That is, churn often will propagate across dependencies. Together, a high degree of dependence plus churn can cause errors that will propagate through a system, reducing its reliability.

In order to study the effectiveness of dependencies to predict failures, we studied the dependencies between binaries in Windows Vista. The dependencies are computed at the function level, including caller-callee dependencies, imports, exports, RPC, COM, Registry access, etc. The system-wide dependency graph can be viewed as the low-level architecture of Windows Vista. Dependencies are classified into incoming and outgoing dependencies with the binaries. Further classifications include the total number of dependencies between binaries and the span of binaries across different components. The prediction models built using the dependency metrics to predict failures in Windows Vista have a precision and recall of 74.4% and 69.9%, respectively. This is as good as the precision and recall results obtained from code complexity metrics but does not compare to the results obtained from code churn. Further reading on the ability of dependencies and code churn to predict failures on the Microsoft case study can be found in [Nagappan and Ball 2007].

In related work, Schröter et al. showed that import dependencies can predict defects [Schröter et al. 2006]. They proposed an alternate way of predicting failures for Java classes. Rather than looking at the complexity of a class, they looked exclusively at the components that a class uses. For Eclipse, an open source IDE, they found that using compiler packages results in a significantly higher failure-proneness (71%) than using GUI packages (14%). Von Mayrhauser et al. investigated the relationship of the decay of software architectures with faults using a bottom-up approach of constructing a fault-architecture model [von Mayrhauser et al. 1999]. A fault-architecture model was constructed incorporating the degree of fault-coupling between components and how often these two components are involved in a defect fix. Their results indicated the most fault-prone relationships for each release and showed that the same relationships between components are repeatedly fault-prone, indicating underlying architectural problems.