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

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

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

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

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

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

P1: Does Bug Prediction Support Human Developers? 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?

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

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

Transfer Defect Learning Proceedings of the 2013 International Conference on Software Engineering (ICSE '13), pp. 382-391, 2013 Transfer Defect Learning 和歌山大学の柏祐太郎です． Transfer defect learningの紹介をさせていただきます． この論文の目的はcross-project欠陥予測の精度を上げることです Jaechang Nam， Sinno Jialin Pan， Sunghun Kim 担当：和歌山大学 柏 祐太郎 山谷 陽亮

cross-project欠陥予測 データの分散を小さくすることで cross-project欠陥予測の精度を上げる 大規模 プロジェクト 不具合 予測モデル 不具合の場所を予測 予測精度が低い データ分布の違い cross-project欠陥予測について説明します． 新規プロジェクトなど小さいプロジェクトでは不具合予測がデータ量が少ないためできないことがあります． そのため大規模プロジェクトの予測モデルを新規プロジェクトにつかおうとするのがcross-project欠陥予測です しかし，現状では予測精度が低い状態となっています． その主な原因はデータ分布の違いがあります． 新規 プロジェクト 不具合 予測モデル 不具合の場所を予測 データの分散を小さくすることで cross-project欠陥予測の精度を上げる

目的とアプローチ 目的 プロジェクト間のデータの分散を小さくすることで cross-project欠陥予測の精度を上げる アプローチ 予測の前にTCAまたはTCA+を実施 TCA：Transfer Component Analysis そのためこの論文の目的はデータの分散を小さくすることで予測精度をあげることを目指します． アプローチにtransfer learningの一つであるTCAを欠陥予測に応用します． TCAはプロジェクト間の共通性を明らかにすることでデータの分散を小さくする方法です また，本論文ではTCAを拡張したTCA＋も提案されています． TCAを用いる前には前処理としてデータの正規化を行います． データの正規化方法は複数存在しているため，この中から１つの正規化方法を選ばなくてはいけません． TCA＋ではこのデータ分布の類似度から正規化方法を柔軟に対応させます． 例としてこれらの方法があります． P. Bug Prediction P2

TCA・TCA+ TCA(Transfer Component Analysis) 教師なしデータによるTransfer Learning 共通性を見つけ分布の違いを吸収 TCA+ TCAにおける正しい正規化を見つける 1. データセットの特徴を捉える 2. プロジェクトの類似度を測定 3. 正規化の方法を決める * *http://www.slideshare.net/hunkim/transfer-defectlearningnew-completed P. Bug Prediction P2

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

結果 TCAおよびTCA+を用いた場合との比較 TCA TCA+ within-project欠陥予測との比較 適切な正規化方法が選ばれ，全ての予測精度が上がった within-project欠陥予測との比較 TCA+はwithin-project欠陥予測に匹敵する精度が得られた 次に評価方法と結果ですが． TCAを使うことで一部の正規化方法によっては予測精度が上がりましたが，予測精度がさがった場合も存在しました． 実験２ではTCA+を使うことで適切な正規化方法を選べるかを実験しました． 結果は適切な正規化方法が選ばれ， P. Bug Prediction P2

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

Kim Herzig, Sascha Just, Andreas Zeller 担当：和歌山大学 松本 明 吉行 勇人 Proceedings of the 2013 International Conference on Software Engineering (ICSE '13), pp. 392-401, 2013 It’s not a Bug, It’s a Feature: How　Misclassification Impacts Bug Prediction 本論文では、不具合報告において、誤分類がどれほどなされているか、また、そういった誤分類がバグ予測にどれほどの影響を与えるかを調べています Kim Herzig, Sascha Just, Andreas Zeller 担当：和歌山大学 　松本 明 吉行 勇人

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

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

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

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

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