Don’t Touch My Code! Examining the Effects of Ownership on Software Quality C. Bird (マイクロソフト・リサーチ) et al. 担当者：吉田（NAIST） 研究目的 Ownershipの定量化，およびOwnershipと欠陥との関係 を明らかにする Ownershipとは，以下のいずれの状態であるかを表す語 あるコンポーネントに対して，１人の開発者が責任を持っている あるコンポーネントに対して，誰も明確に責任を持っていない 関係が強いなら，Ownershipを明確にするポリシーで開 発を行うべき マネージャは，過去の経験からみて適切な開発者が開発して いるか管理すべき 調査に用いたメトリクス Minor Major コミット数が，コンポーネント全体の5%以上の開発者の数 Total コミット数が，コンポーネント全体の5%未満の開発者の数 コンポーネントにコミットしたり変更を加えた開発者数 Ownership コミット数が最多の開発者のコミット数を，全コミット数で割っ た値 欠陥との相関係数 リリース前，およびリリース後の欠陥数について，スピ アマンの順位相関係数を計測した 多くの場合，Minorメトリクスと欠陥数との間 に強い相関があった 欠陥予測への適用 欠陥予測のためのメトリクスとして，使用できるか調査 コードメトリクスとMinorメトリクスを組み合わ せた場合が最も優れていた ReLink: Recovering Links between Bugs 6 and Changes by Rongxin Wu, Hongyu Zhang, Sunghun Kim and Shing-Chi Cheung • バグ票と変更ログ間の従来手法では発見でき なかったリンクを自動的に復元するReLinkを 提案した – 平均精度89％，再現率78％ (6%-26%向上) • 従来手法で求められたリンクから３つの特徴 量を抽出し，それを基に未発見のリンクを復 元する • バグ予測手法とソフトウェア保守性メトリク スの計測に用いて精度改善を確認 7 背景と目的 変更ログ bug 325 を修正 バグ票 : #325 バグ報告者：○ ○ ○ ○ リンク 変更ログ中にあるバグ票の番号からバグ票と修正コミットと対応 付けを行う手法が提案されている 表．Bachmannらの手法による対応付け結果 プロジェクト 修正済みバグ数 リンクされたバグ数 リンク数 特定されたリンク数 ZXing 135 40.7% 143 48.2% OpenIntents 101 53.5% 129 67.4% 従来手法では多くのリンクが発見できていない バグ票と変更ログ間の未発見のリンク を自動的に復元するReLinkを提案 リンク復元処理の概要 8 リンク 復元 未発見の リンク バグ管理 システム 従来手法 バージョン 管理 システム 特徴量 発見された リンク リンク 3つの特徴量 9 • コミットからバグ票が修正済みになるまでの 時間 – 修正コミットが行われたらすぐに“修正済み”に変 更されたり，コメントが投稿される． • バグ修正責任者とコミッタ – 修正を行ったコミッタとバグ修正の責任者は同じ 人物である • テキストの類似度 (TFIDF) – 同じ事柄を扱っているため，変更ログとバグ票は 同じようなキーワードを共有する 10 実験結果 プロジェクト Zing OpenIntents Apache Apache Simulation Eclipse MAT Simulation 修正バグ数 135 101 686 686 108 手法 リンク発見率 精度 再現率 従来手法 42.2% 1.0 0.482 ReLink 70.4% 0.90 0.748 従来手法 69.3% 1.0 0.674 ReLink 73.3% 1.0 0.731 従来手法 77.1% 0.746 0.764 ReLink 89.8% 0.747 0.873 従来手法 77.1% 0.746 0.764 ReLink 89.8% 0.747 0.873 従来手法 77.1% 0.746 0.764 ReLink 89.8% 0.747 0.873 • すべてのプロジェクトにおいてリンク発見率が向上 • 誤検出も同時に増えている 11 バグ予測手法への適用 プロジェクト ZXing OpenIntents Apache 手法 精度 再現率 F値 従来手法 0.346 0.114 0.171 ReLink 0.432 0.261 0.352 従来手法 0.405 0.188 0.257 ReLink 0.779 0.645 0.706 従来手法 0.672 0.727 0.68 ReLink 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? 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 Linux 前処理 OpenSolaris 変更箇所の解析 バグ修正 コメントの解析 某OS 開発履歴 • 修正の修正を探す – 変更箇所の解析 • 同じ場所または周辺箇所を修正していないか – コメントの解析 • “this patch fixed a regression introduced by the fix in Bug 12476” • 最終的には著者ら自身が判別した 修正 成功 修正 失敗 Incorrect Fixesの重要性 • 各OSから500件ずつバグ修正を抽出し， Incorrect Fixか調査 • リリース後バグの2割近くが修正に失敗してい る OS リリース後バ Incorrect Fixes Ratio グの修正 A 189 39 20.6%±3.0% B C 309 267 46 41 14.8%±2.9% 15.3%±2.6% D 205 50 24.4%±3.7% • 全失敗の43%が致命的なバグ Incorrect Fixesのパターン • バグの種類で修正を分類して並行処理とメモリ に関するバグに着目 – 並行処理に関するバグ修正は4割近くが失敗してい た • 割合の高かった4種類についてパターンを分析 – 並行処理：data race, dead lock – メモリ:buffer overflow, memory leak • 全体的な傾向としてはif文における条件式の修 正ミスが目立ったらしい 修正者の知識不足 • 修正者のファイルまたは関数に対する知識を 定量化してIncorrect Fixesとの関係を調査 – 対象コードを書いた割合を計算 • 正常な修正と比べて約1.5倍知識量に差が あった（Table 7参照） • “first touches”は危ない 知識不足な人達 論文中Fig.13から引用
© Copyright 2024 ExpyDoc
