Don’t Touch My Code! Examining the Effects of Ownership on Software Quality C. Bird (マイクロソフト・リサーチ) et al. 担当者：吉田（NAIST）

研究目的 Ownershipの定量化，およびOwnershipと欠陥との関係 を明らかにする あるコンポーネントに対して，１人の開発者が責任を持っている あるコンポーネントに対して，誰も明確に責任を持っていない 関係が強いなら，Ownershipを明確にするポリシーで開 発を行うべき マネージャは，過去の経験からみて適切な開発者が開発して いるか管理すべき

調査に用いたメトリクス Minor Major Total Ownership コミット数が，コンポーネント全体の5%未満の開発者の数 コミット数が，コンポーネント全体の5%以上の開発者の数 Total コンポーネントにコミットしたり変更を加えた開発者数 Ownership コミット数が最多の開発者のコミット数を，全コミット数で割っ た値

欠陥との相関係数 リリース前，およびリリース後の欠陥数について，スピ アマンの順位相関係数を計測した 多くの場合，Minorメトリクスと欠陥数との間に強い相関があった

欠陥予測への適用 欠陥予測のためのメトリクスとして，使用できるか調査 コードメトリクスとMinorメトリクスを組み合わせた場合が最も優れていた

ReLink: Recovering Links between Bugs and Changes by Rongxin Wu, Hongyu Zhang, Sunghun Kim and Shing-Chi Cheung バグ票と変更ログ間の従来手法では発見できなかったリンクを自動的に復元するReLinkを提案した 平均精度89％，再現率78％ (6%-26%向上) 従来手法で求められたリンクから３つの特徴量を抽出し，それを基に未発見のリンクを復元する バグ予測手法とソフトウェア保守性メトリクスの計測に用いて精度改善を確認

背景と目的 バグ票と変更ログ間の未発見のリンクを自動的に復元するReLinkを提案 bug 325 を修正 バグ票 : #325 バグ報告者：○ ○ ○ ○ リンク 変更ログ中にあるバグ票の番号からバグ票と修正コミットと対応付けを行う手法が提案されている 表．Bachmannらの手法による対応付け結果 プロジェクト 修正済みバグ数 リンクされたバグ数 リンク数 特定されたリンク数 ZXing 135 40.7% 143 48.2% OpenIntents 101 53.5% 129 67.4% 従来手法では多くのリンクが発見できていない バグ票と変更ログ間の未発見のリンクを自動的に復元するReLinkを提案

リンク復元処理の概要 未発見のリンク リンク 特徴量 発見されたリンク リンク 復元 従来手法 バグ管理 システム バージョン 管理

3つの特徴量 コミットからバグ票が修正済みになるまでの時間 バグ修正責任者とコミッタ テキストの類似度 (TFIDF) 修正コミットが行われたらすぐに“修正済み”に変更されたり，コメントが投稿される． バグ修正責任者とコミッタ 修正を行ったコミッタとバグ修正の責任者は同じ人物である テキストの類似度 (TFIDF) 同じ事柄を扱っているため，変更ログとバグ票は同じようなキーワードを共有する

実験結果 すべてのプロジェクトにおいてリンク発見率が向上 誤検出も同時に増えている プロジェクト 修正バグ数 手法 リンク発見率 精度 再現率 Zing 135 従来手法 42.2% 1.0 0.482 ReLink 70.4% 0.90 0.748 OpenIntents 101 69.3% 0.674 73.3% 0.731 Apache 686 77.1% 0.746 0.764 89.8% 0.747 0.873 Simulation Eclipse MAT 108 すべてのプロジェクトにおいてリンク発見率が向上 誤検出も同時に増えている

バグ予測手法への適用 保守性メトリクスの計測 プロジェクト 手法 精度 再現率 F値 ZXing 従来手法 0.346 0.114 0.171 ReLink 0.432 0.261 0.352 OpenIntents 0.405 0.188 0.257 0.779 0.645 0.706 Apache 0.672 0.727 0.68 0.716 0.748 0.731 保守性メトリクスの計測 プロジェクト 手法 バグ修正率 バグ含有率 平均修正時間 ZXing 従来手法 4.0% 14.8% 10.2 ReLink 6.3% 20.8% 7.3 正解集合 8.1％ 29.6% 7.5

How Do Fixes Become Bugs How Do Fixes Become Bugs? A Comprehensive Characteristic Study on Incorrect Fixes in Commercial and Open Source Operating Systems Zuoning Yin, Ding Yuan, Yuanyuan Zhou, Shankar Pasupathy, Lakshmi Bairavasundaram バグ修正の失敗（Incorrect Fixes）について調査した 4種類の出自が違うOSを対象 OSは間違ったパッチを出すと信用問題になる 商用OS, Linux, OpenSolaris, FreeBSD Findings Incorrect Fixesが重大な問題を引き起こした事例が多く見つかった 並行処理（デッドロックなど）に関するバグ修正は難しい 修正対象に関する知識不足がIncorrect Fixesを引き起こしている 紹介者:NAIST M2 藤原 賢二

Incorrect Fixesの抽出 修正の修正を探す 最終的には著者ら自身が判別した 変更箇所の解析 コメントの解析 FreeBSD 修正成功 FreeBSD 前処理 バグ修正 変更箇所の解析 Linux 修正失敗 OpenSolaris コメントの解析 某OS 開発履歴 修正の修正を探す 変更箇所の解析 同じ場所または周辺箇所を修正していないか コメントの解析 “this patch fixed a regression introduced by the fix in Bug 12476” 最終的には著者ら自身が判別した

Incorrect Fixesの重要性 各OSから500件ずつバグ修正を抽出し，Incorrect Fixか調査 リリース後バグの2割近くが修正に失敗している 全失敗の43%が致命的なバグ OS リリース後バグの修正 Incorrect Fixes Ratio A 189 39 20.6%±3.0% B 309 46 14.8%±2.9% C 267 41 15.3%±2.6% D 205 50 24.4%±3.7%

Incorrect Fixesのパターン バグの種類で修正を分類して並行処理とメモリに関するバグに着目 並行処理に関するバグ修正は4割近くが失敗していた 割合の高かった4種類についてパターンを分析 並行処理：data race, dead lock メモリ:buffer overflow, memory leak 全体的な傾向としてはif文における条件式の修正ミスが目立ったらしい

修正者の知識不足 修正者のファイルまたは関数に対する知識を定量化してIncorrect Fixesとの関係を調査 対象コードを書いた割合を計算 正常な修正と比べて約1.5倍知識量に差があった（Table 7参照） “first touches”は危ない 知識不足な人達 論文中Fig.13から引用