担当者：吉田（ NAIST ）

Don’t Touch My Code!Examining the Effects of Ownership on Software Quality

C. Bird (マイクロソフト・リサーチ ) et al.

担当者：吉田（ NAIST）

研究目的 Ownershipの定量化，および Ownershipと欠陥との関係を明らかにする Ownershipとは，以下のいずれの状態であるかを表す語

あるコンポーネントに対して，１人の開発者が責任を持っている

あるコンポーネントに対して，誰も明確に責任を持っていない

関係が強いなら， Ownershipを明確にするポリシーで開発を行うべき マネージャは，過去の経験からみて適切な開発者が開発しているか管理すべき

調査に用いたメトリクス Minor

コミット数が，コンポーネント全体の 5%未満の開発者の数

Major コミット数が，コンポーネント全体の 5%以上の開発者の数

Total コンポーネントにコミットしたり変更を加えた開発者数

Ownership コミット数が最多の開発者のコミット数を，全コミット数で割った値

欠陥との相関係数 リリース前，およびリリース後の欠陥数について，スピアマンの順位相関係数を計測した

多くの場合，Minorメトリクスと欠陥数との間に強い相関があった

欠陥予測への適用 欠陥予測のためのメトリクスとして，使用できるか調査

コードメトリクスとMinorメトリクスを組み合わせた場合が最も優れていた

6ReLink: Recovering Links between Bugs and Changes

• バグ票と変更ログ間の従来手法では発見できなかったリンクを自動的に復元する ReLinkを提案した– 平均精度 89 ％，再現率 78 ％ (6%-26% 向上 )

• 従来手法で求められたリンクから３つの特徴量を抽出し，それを基に未発見のリンクを復元する

• バグ予測手法とソフトウェア保守性メトリクスの計測に用いて精度改善を確認

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 を提案

8リンク復元処理の概要

バージョン管理

システム

バグ管理システム

発見されたリンク

未発見のリンク

リンク復元

特徴量 リンク従来手法

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文における条件式の修正ミスが目立ったらしい

修正者の知識不足• 修正者のファイルまたは関数に対する知識を定量化して Incorrect Fixesとの関係を調査–対象コードを書いた割合を計算

• 正常な修正と比べて約 1.5倍知識量に差があった（ Table 7参照）

• “first touches”は危ない

論文中 Fig.13 から引用

知識不足な人達