de l’information
This leads us to conclude that, potentially, previous validation studies have overestimated the impact of
object oriented metrics on fault-proneness due to the confounding effect of size.
2.3 Summary
In this section the theoretical basis for object-oriented product metrics was presented. This states that
cognitive complexity is an intervening variable between the structural properties of classes and fault-
proneness. Furthermore, the empirical evidence supporting the validity of the object oriented metrics that
we study was presented, and this indicates that some of the metrics are strongly associated with fault-
proneness or the number of faults. We have also demonstrated that there is potentially a strong size
confounding effect in empirical studies to date that validate object oriented product metrics. This makes it
of paramount importance to determine whether such a strong confounding effect really exists.
If a size confounding effect is found, this means that previous validation studies have a positive bias and
may have exaggerated the impact of product metrics on fault-proneness. The reason is that studies to
date relied exclusively on univariate analysis to test the hypothesis that the product metrics are
associated with fault-proneness or the number of faults. The objective of the study below then is to
directly test the existence of this confounding effect and its magnitude.
3 Research Method
3.1 Data Source
Our data set comes from a telecommunications framework written in C++ [102]. The framework
implements many core design patterns for concurrent communication software. The communication
software tasks provided by this framework include event demultiplexing and event handler dispatching,
signal handling, service initialization, interprocess communication, shared memory management,
message routing, dynamic (re)configuration of distributed services, and concurrent execution and
synchronization. The framework has been used in applications such as electronic medical imaging
systems, configurable telecommunications systems, high-performance real-time CORBA, and web
servers. Examples of its application include in the Motorola Iridium global personal communications
system [101] and in network monitoring applications for telecommunications switches at Ericsson [100]. A
total of 174 classes from the framework that were being reused in the development of commercial
switching software constitute the system that we study. A total of 14 different programmers were involved16in the development of this set of classes.
3.2 Measurement
3.2.1 Product Metrics
All product metrics are defined on the class, and constitute design metrics, and they have been presented
in Section 2.1.2. In our study the size variable was measured as non-comment source LOC for the class.
Measurement of product metrics used a commercial metrics collection tool that is currently being used by
a number of large telecommunications software development organizations.
3.2.2 Dependent Variable
17For this product, we obtained data on the faults found in the library from actual field usage. Each fault
was due to a unique field failure and represents a defect in the program that caused the failure. Failures
were reported by the users of the framework. The developers of the framework documented the reasons
for each delta in the version control system, and it was from this that we extracted information on whether
a class was faulty.16
17 This number was obtained from the different login names of the version control system associated with each class. It has been argued that considering faults causing field failures is a more important question to address than faults found during
testing [9]. In fact, it has been argued that it is the ultimate aim of quality modeling to predict post-release fault-proness [50]. In at
least one study it was found that pre-release fault-proneness is not a good surrogate measure for post-release fault-proness, the
reason posited being that pre-release fault-proness is a function of testing effort [51].