Does Bug Prediction Support Human Developers? Findings from a Google Case Study

1. P1 Does Bug Prediction Support Human Developers?Findings from a Google Case Study Chris Lewis, Zhongpeng Lin, Caitlin Sadowski, Xiaoyan Zhu, RongOu,and E. James Whitehead Jr. (Univ. of California, USA; Google Inc., USA; Xi’an Jiaotong Univ., China) 担当：山下 一寛（九州大学）

2. GoalとResearch Question Goal: バグ予測アルゴリズムに対し，開発者がどのように行動するのかを知りたい． RQ1: バグ予測のアルゴリズムはバグを含んだファイルをいくつ予測できるか？また，どのアルゴリズムが好ましいか？ RQ2: バグ予測アルゴリズムが持つべき特徴とは？ RQ3: RQ1,2で得た知見からより良いアルゴリズムを設計し，利用したとき開発者の行動は変わるのか？ P1: Does Bug Prediction Support Human Developers?

3. User Study 1 FileA FileB … 予測結果 Bug Prediction Project このファイルはバグを含んでいそうですか？ Developer of Project P1: Does Bug Prediction Support Human Developers?

4. User Study 2 バグ予測のアルゴリズムに必要なことって・・・？ P1: Does Bug Prediction Support Human Developers?

5. User Study 3 Mondrian (Review System) 違いは出るのか？ Reviewer Action Source Code Report Bug Prediction P1: Does Bug Prediction Support Human Developers?

6. Results of User Study 1 Rahmanのアルゴリズムが一番良かった 図はp.376 Fig.1,2より引用 P1: Does Bug Prediction Support Human Developers?

7. Results of User Study 2 • Desirable Characteristics • Actionable Messages • Obvious Reasoning • Bias Towards the New • Parallelizable • Effectiveness Scaling ５つの望ましい点が見つかった P1: Does Bug Prediction Support Human Developers?

8. Results of User Study 3 顕著な変化は見られなかった 図，表はp.379 Fig.3，p.380 Table IIIより引用 P1: Does Bug Prediction Support Human Developers?

9. 所感 • 開発者がどう思うかという観点は必要だと思う． • また，Googleのエンジニアに協力してもらい，実際にこのような観点で実験を行った． • 論文の構成が分り易い． • 特に実験の部分 P1: Does Bug Prediction Support Human Developers?

10. Proceedings of the 2013 International Conference on Software Engineering (ICSE '13), pp. 382-391, 2013 Transfer Defect Learning Jaechang Nam，SinnoJialin Pan，Sunghun Kim 担当：和歌山大学 柏 祐太郎 山谷 陽亮

11. cross-project欠陥予測 大規模 プロジェクト 不具合 予測モデル 不具合の場所を予測 予測精度が低い データ分布の違い 不具合 予測モデル 新規 プロジェクト 不具合の場所を予測 データの分散を小さくすることで cross-project欠陥予測の精度を上げる

12. 目的とアプローチ 目的 • プロジェクト間のデータの分散を小さくすることでcross-project欠陥予測の精度を上げる アプローチ • 予測の前にTCAまたはTCA+を実施 • TCA：Transfer Component Analysis P. Bug Prediction P2

13. TCA・TCA+ * *http://www.slideshare.net/hunkim/transfer-defectlearningnew-completed P. Bug Prediction P2

14. 評価方法 • 評価尺度：不具合の位置を予測する精度（F値） TCAなし TCA・TCA+ cross-project欠陥予測 within-project欠陥予測 小さいプロジェクトの十分でないデータ量で作られた予測モデル P. Bug Prediction P2

15. 結果 • TCAおよびTCA+を用いた場合との比較 TCA • 一部の正規化方法ではTCAなしより予測精度が上がった • 正規化方法によってはTCAなしより予測精度が下がった TCA+ • 適切な正規化方法が選ばれ，全ての予測精度が上がった • within-project欠陥予測との比較 • TCA+はwithin-project欠陥予測に匹敵する精度が得られた P. Bug Prediction P2

16. 所感 • １章で良くまとめられていて全体像を掴みやすい • cross-project欠陥予測の必要性や現状 • データの分散を小さくできる点でTCAは応用の幅が広いと感じた • cross-project欠陥予測するにはまだ精度が足りない • within-project予測の精度と変わらない場合も P. Bug Prediction P2

17. Proceedings of the 2013 International Conference on Software Engineering (ICSE '13), pp. 392-401, 2013 It’s not a Bug, It’s a Feature:HowMisclassification Impacts Bug Prediction Kim Herzig, Sascha Just, Andreas Zeller 担当：和歌山大学 　松本 明 吉行 勇人

18. 背景 • 不具合報告には、「バグ」と「バグでないもの」がある • プロジェクトの管理者が不具合報告を分類した際に、誤分類が含まれている可能性がある • 多くの予測モデルは、管理者による分類が正しいものとして構築されており、もし誤分類があれば予測モデルの精度を脅かす問題となる P. Bug Prediction P3

19. 評価方法 • ５つのオープンソースプロジェクト（HTTPClient, Jackrabbit, Lucene-Java, Rhino, Tomcat5）の計7,401件の不具合報告を一定のルールの下で再分類する • 例）「バグ」と判別されるルール • NullpointerExceptionに関する報告があるもの • コードを変更する必要があるもの • ランタイムエラーやメモリリークを修正するもの P. Bug Prediction P3

20. 分類方法 • 著者の１人が全ての不具合報告を確認し、誤分類があれば分類し直してタグをつける • 別の著者がタグ付けされてある不具合報告を確認し、再分類する • 二人の分類結果を比較してマージする 図は当該論文より引用 P. Bug Prediction P3

21. 結果 • 誤分類 • 全ての不具合報告のうち、42.6%が誤って分類されていた • 全てのバグ報告のうち、33.8%はバグではなかった • 誤分類の影響 • defect-proneであるとされたファイルのうち、39%はバグが存在していなかった • 元のデータセットでdefect-proneであるとされたファイルのうち16%～40%は、再分類後のデータセットではdefect-proneではなかった P. Bug Prediction P3

22. まとめと所感 • まとめ • 定量分析に用いるデータセットを機械的に整理するだけでなく、人の手でもチェックする必要がある • 不具合報告の分類は管理者の主観によって左右されるため、予測モデルの妥当性が脅かされる可能性がある • 所感 • 今後、誤分類をどう処理すればよいのか？ • 7000件以上の不具合を目で見て確認するという、手間と時間のかかる作業を行った著書らの研究熱意に感動した P. Bug Prediction P3