TY - GEN
T1 - Predicting re-opened bugs
T2 - 17th Working Conference on Reverse Engineering, WCRE 2010
AU - Shihab, Emad
AU - Ihara, Akinori
AU - Kamei, Yasutaka
AU - Ibrahim, Walid M.
AU - Ohira, Masao
AU - Adams, Bram
AU - Hassan, Ahmed E.
AU - Matsumoto, Ken Ichi
PY - 2010
Y1 - 2010
N2 - Bug fixing accounts for a large amount of the software maintenance resources. Generally, bugs are reported, fixed, verified and closed. However, in some cases bugs have to be re-opened. Re-opened bugs increase maintenance costs, degrade the overall user-perceived quality of the software and lead to unnecessary rework by busy practitioners. In this paper, we study and predict re-opened bugs through a case study on the Eclipse project. We structure our study along 4 dimensions: 1) the work habits dimension (e.g., the weekday on which the bug was initially closed on), 2) the bug report dimension (e.g., the component in which the bug was found) 3) the bug fix dimension (e.g., the amount of time it took to perform the initial fix) and 4) the team dimension (e.g., the experience of the bug fixer). Our case study on the Eclipse Platform 3.0 project shows that the comment and description text, the time it took to fix the bug, and the component the bug was found in are the most important factors in determining whether a bug will be re-opened. Based on these dimensions we create decision trees that predict whether a bug will be re-opened after its closure. Using a combination of our dimensions, we can build explainable prediction models that can achieve 62.9% precision and 84.5% recall when predicting whether a bug will be re-opened.
AB - Bug fixing accounts for a large amount of the software maintenance resources. Generally, bugs are reported, fixed, verified and closed. However, in some cases bugs have to be re-opened. Re-opened bugs increase maintenance costs, degrade the overall user-perceived quality of the software and lead to unnecessary rework by busy practitioners. In this paper, we study and predict re-opened bugs through a case study on the Eclipse project. We structure our study along 4 dimensions: 1) the work habits dimension (e.g., the weekday on which the bug was initially closed on), 2) the bug report dimension (e.g., the component in which the bug was found) 3) the bug fix dimension (e.g., the amount of time it took to perform the initial fix) and 4) the team dimension (e.g., the experience of the bug fixer). Our case study on the Eclipse Platform 3.0 project shows that the comment and description text, the time it took to fix the bug, and the component the bug was found in are the most important factors in determining whether a bug will be re-opened. Based on these dimensions we create decision trees that predict whether a bug will be re-opened after its closure. Using a combination of our dimensions, we can build explainable prediction models that can achieve 62.9% precision and 84.5% recall when predicting whether a bug will be re-opened.
UR - http://www.scopus.com/inward/record.url?scp=78650665730&partnerID=8YFLogxK
UR - http://www.scopus.com/inward/citedby.url?scp=78650665730&partnerID=8YFLogxK
U2 - 10.1109/WCRE.2010.36
DO - 10.1109/WCRE.2010.36
M3 - Conference contribution
AN - SCOPUS:78650665730
SN - 9780769541235
T3 - Proceedings - Working Conference on Reverse Engineering, WCRE
SP - 249
EP - 258
BT - Proceedings - 17th Working Conference on Reverse Engineering, WCRE 2010
Y2 - 13 October 2010 through 16 October 2010
ER -