担当者:吉田( naist )
DESCRIPTION
Don’t Touch My Code! Examining the Effects of Ownership on Software Quality C. Bird ( マイクロソフト・リサーチ ) et al. 担当者:吉田( NAIST ). 研究 目的. Ownership の定量化,および Ownership と欠陥との関係を明らかにする Ownership とは,以下のいずれの状態であるかを表す語 あるコンポーネントに対して, 1人の開発者が 責任を持っている あるコンポーネントに対して,誰も明確に責任を持っていない - PowerPoint PPT PresentationTRANSCRIPT
Don’t Touch My Code!Examining the Effects of Ownership on Software Quality
C. Bird (マイクロソフト・リサーチ ) et al.
担当者:吉田( NAIST)
研究目的 Ownershipの定量化,および Ownershipと欠陥との関係を明らかにする Ownershipとは,以下のいずれの状態であるかを表す語
あるコンポーネントに対して,1人の開発者が責任を持っている
あるコンポーネントに対して,誰も明確に責任を持っていない
関係が強いなら, Ownershipを明確にするポリシーで開発を行うべき マネージャは,過去の経験からみて適切な開発者が開発しているか管理すべき
調査に用いたメトリクス Minor
コミット数が,コンポーネント全体の 5%未満の開発者の数
Major コミット数が,コンポーネント全体の 5%以上の開発者の数
Total コンポーネントにコミットしたり変更を加えた開発者数
Ownership コミット数が最多の開発者のコミット数を,全コミット数で割った値
6ReLink: Recovering Links between Bugs and Changes
• バグ票と変更ログ間の従来手法では発見できなかったリンクを自動的に復元する ReLinkを提案した– 平均精度 89 %,再現率 78 % (6%-26% 向上 )
• 従来手法で求められたリンクから3つの特徴量を抽出し,それを基に未発見のリンクを復元する
• バグ予測手法とソフトウェア保守性メトリクスの計測に用いて精度改善を確認
by Rongxin Wu, Hongyu Zhang, Sunghun Kim and Shing-Chi Cheung
7背景と目的
プロジェクト 修正済みバグ数 リンクされたバグ数 リンク数 特定されたリンク数
ZXing 135 40.7% 143 48.2%
OpenIntents 101 53.5% 129 67.4%
従来手法では多くのリンクが発見できていない
バグ票 : #325バグ報告者:○ ○ ○ ○
変更ログbug 325 を修正 リンク
変更ログ中にあるバグ票の番号からバグ票と修正コミットと対応付けを行う手法が提案されている
表. Bachmann らの手法による対応付け結果
バグ票と変更ログ間の未発見のリンクを自動的に復元する ReLink を提案
93 つの特徴量
• コミットからバグ票が修正済みになるまでの時間– 修正コミットが行われたらすぐに“修正済み”に変
更されたり,コメントが投稿される.• バグ修正責任者とコミッタ– 修正を行ったコミッタとバグ修正の責任者は同
じ人物である• テキストの類似度 (TFIDF)– 同じ事柄を扱っているため,変更ログとバグ票
は同じようなキーワードを共有する
10実験結果
プロジェクト 修正バグ数 手法 リンク発見率 精度 再現率
Zing 135従来手法 42.2% 1.0 0.482
ReLink 70.4% 0.90 0.748
OpenIntents 101従来手法 69.3% 1.0 0.674
ReLink 73.3% 1.0 0.731
Apache 686従来手法 77.1% 0.746 0.764
ReLink 89.8% 0.747 0.873
ApacheSimulation 686
従来手法 77.1% 0.746 0.764
ReLink 89.8% 0.747 0.873
Eclipse MATSimulation 108
従来手法 77.1% 0.746 0.764
ReLink 89.8% 0.747 0.873
• すべてのプロジェクトにおいてリンク発見率が向上• 誤検出も同時に増えている
11バグ予測手法への適用
プロジェクト 手法 精度 再現率 F 値
ZXing従来手法 0.346 0.114 0.171
ReLink 0.432 0.261 0.352
OpenIntents従来手法 0.405 0.188 0.257
ReLink 0.779 0.645 0.706
Apache従来手法 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
保守性メトリクスの計測
• バグ修正の失敗( Incorrect Fixes)について調査した– 4種類の出自が違う OSを対象
• OSは間違ったパッチを出すと信用問題になる• 商用 OS, Linux, OpenSolaris, FreeBSD
• Findings– Incorrect Fixesが重大な問題を引き起こした事例が多く見つかった
– 並行処理(デッドロックなど)に関するバグ修正は難しい
– 修正対象に関する知識不足が Incorrect Fixesを引き起こしている
How Do Fixes Become Bugs?A Comprehensive Characteristic Study on Incorrect Fixes in
Commercial and Open Source Operating SystemsZuoning Yin, Ding Yuan, Yuanyuan Zhou, Shankar Pasupathy, Lakshmi Bairavasundaram
紹介者 :NAIST M2 藤原 賢二
Incorrect Fixesの抽出
• 修正の修正を探す– 変更箇所の解析
• 同じ場所または周辺箇所を修正していないか– コメントの解析
• “this patch fixed a regression introduced by the fix in Bug 12476”
• 最終的には著者ら自身が判別した
FreeBSD
Linux
某 OS
OpenSolaris
開発履歴
バグ修正
変更箇所の解析
コメントの解析
前処理修正成功
修正失敗
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文における条件式の修正ミスが目立ったらしい