1 / 16

担当者：吉田（ NAIST ）

Don’t Touch My Code! Examining the Effects of Ownership on Software Quality C. Bird ( マイクロソフト・リサーチ ) et al. 担当者：吉田（ NAIST ）. 研究 目的. Ownership の定量化，および Ownership と欠陥との関係を明らかにする Ownership とは，以下のいずれの状態であるかを表す語 あるコンポーネントに対して， １人の開発者が 責任を持っている あるコンポーネントに対して，誰も明確に責任を持っていない

jescie-moore
Download Presentation

担当者：吉田（ NAIST ）

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

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

  7. 背景と目的 変更ログ bug 325 を修正 バグ票 : #325 バグ報告者：○○○ ○ リンク 変更ログ中にあるバグ票の番号からバグ票と修正コミットと対応付けを行う手法が提案されている 表．Bachmannらの手法による対応付け結果 従来手法では多くのリンクが発見できていない バグ票と変更ログ間の未発見のリンクを自動的に復元するReLinkを提案

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

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

  10. 実験結果 • すべてのプロジェクトにおいてリンク発見率が向上 • 誤検出も同時に増えている

  11. バグ予測手法への適用 保守性メトリクスの計測

  12. 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を引き起こしている 紹介者:NAISTM2 藤原 賢二

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

  14. Incorrect Fixesの重要性 • 各OSから500件ずつバグ修正を抽出し，Incorrect Fixか調査 • リリース後バグの2割近くが修正に失敗している • 全失敗の43%が致命的なバグ

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

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

More Related