Googleのバグ予測アルゴリズム

Googleのバグ予測アルゴリズムの記事があったのでメモ。

【元ネタ】
グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している － Publickey

グーグルのバグ予測アルゴリズムを実装したツール「bugspots」、オープンソースで公開 － Publickey

Googleのバグ予測アルゴリズムを実装した「bugspots」のSVN版を作ってみた - 現場のためのソフトウェア開発プロセス - たかのり日記

【1】バグの予測に関する研究は従来からたくさん行われてきた。
信頼度成長曲線もそうだし、クローンプログラムのメトリクスもそうだ。
上記の記事によれば、もっとシンプルにコミットログからバグの傾向分析を導くアルゴリズムのようだ。

(引用開始)
彼らが発見したのは、そのコードに対してこれまでバグフィックスのコミットが何回行われたかをランキングすることで、コードの中のホットスポットを見つけられるだろう、というものです。まさにシンプル！ そしてこれは私たちの直感、もしも何度もバグフィックスが必要なファイルはデベロッパーが苦労しているところだからホットスポットに違いない、というものにマッチするのです。
(中略)
つまり、より高頻度にバグを修正し、かつ最近になって集中的に直しているほど、スコアが大きくなります。そしてスコアが大きいほど、相対的に見てそのコードにはバグがある可能性が高い、というのがこのアルゴリズムが示すところです。
(引用終了)

面白い点は、直近に頻繁に修正しているほどバグが埋め込まれている可能性が高い、ということ。
バグを見つければ、普通はできるだけ早く直そうとする。
だが、バグ修正時に新たなバグを埋め込む危険性が高い事実は、従来から知られていた。
また、バグ修正時にコードレビューやデザインレビューの作業も含める時が多い。
でも、バグが頻発すれば、作業をShortcutするときも多く、バグを根治するのは難しい。

バグ予測できれば、現状の品質がどれくらいなのかを把握することができるし、後どれくらいテストすれば品質を担保出来るか、という見積りにも使えるだろう。

【2】チケット駆動開発の観点では、コミットログに必ずチケット番号が振られている特徴から、ソース修正のリビジョンがどんな変更理由で修正したのか、をチケットから追跡する仕組みがある。
この仕組みによって、ソース修正がバグ修正なのか機能追加なのか、を区別できるし、チケットの属性にある優先度や障害原因、影響度も分析の対象にすれば、より詳細なバグ予測情報を提供できるはずだ。

つまり、コミットログに紐づけられたチケットの情報を拾い出すことで、ソフトウェアメトリクスに関するいろんな情報を引き出すことができる。
そんなアイデアは、下記で一番最初に書いた。

BTSをBusiness Intelligenceとして使う: プログラマの思索

BTSに一元化されたデータ、SVNコミットログは、ソフトウェアメトリクスを研究する研究者にとって、一攫千金の宝物が秘められている。

【3】バグ予測に関しては、僕も別のアイデアを下記に書いた。

Redmineにお勧めソース機能が欲しい: プログラマの思索

SVNコミットログにあるチケット番号を収集して、ソース修正時に過去のチケット履歴から他のソースにも注意した方がいいよ、みたいなサジェストが行えるきのがあればいいな、というアイデア。
技術的には、レコメンドエンジンを使えば実装可能だと思う。

また、オープンソースのツール(Eclipse、Apache)のコミットログを対象に、金曜にバグを発生させるコミットが多い事実を指摘した論文についても下記に書いた。

金曜にバグを発生させるコミットが多い: プログラマの思索

プログラムは人間が書くものだから、人間の生活や特性に関係してくる点からそういう経験的事実が出てくるのだろうと思う。

Redmineでは、Redmine Graph Activitiesプラグインを使うと色んな観点でメトリクスを一覧表示してくれるのが面白い。

活動ログを解析するRedmine Graph Activitiesプラグイン: プログラマの思索

ソフトウェアメトリクスの中でも、コミットログはたくさんの可能性を秘めていると思う。