Elaine Weyueker and Thomas Ostrand and Robert Bell

1. Using Developer Information as a Factor for Fault Prediction May 20, 2007 Elaine Weyuker Tom Ostrand Bob Bell AT&T Labs – Research

2. GOAL : To determine which files of a software system with multiple releases are particularly likely to contain large numbers of faults.

3. Because this should allow us to build highly dependable software systems more economically by allowing us to better allocate testing effort and resources, including personnel. Prioritize testing. Why is this important?

4. Infrastructure Projects use an integrated change management/version control system. Any change to the software requires that a modification request (MR) be opened. MRs include information such as the reason that the change is to be made, a description of the change, a severity rating, the actual change, development stage during which the MR was initiated.

6. Systems Studied 84% 9 years Maintenance Support 75% 2.25 years Voice Resp 83% 2 years Provisioning 83% 4 years Inventory 20% Files Period Covered System Type

9. Cumulative Number of Developers After 20 Releases (526 Files, Mean 3.54)

10. Mean Cumulative Number of Developers by File Age (Age 20 = 3.54)

11. Proportion of Changed Files with Multiple Developers by File Age

12. Proportion of Changed Files with at Least 1 New Developer by File Age

13. Percentage Faults in Identified 20% Files 84.9 83.9 Mean Rel 6-35 92 92 31-35 91 90 26-30 88 89 21-25 86 84 16-20 73 71 11-15 79 78 6-10 With Developers W/O Developers Release Number