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プラグイン: プログラマの思索
ソフトウェアメトリクスの中でも、コミットログはたくさんの可能性を秘めていると思う。
| 固定リンク
« 【告知】AgileJapan2012でチケット駆動開発の講演とパネルディスカッションやります #aj12 | トップページ | 「Redmineによるタスクマネジメント実践技法」の感想を集めてみたpart15 #tidd »
「Redmine」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
「ソフトウェア工学」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
「構成管理・Git」カテゴリの記事
- 「GitLabに学ぶ 世界最先端のリモート組織のつくりかた」の感想(2023.12.10)
- パッケージ設計の原則の意義は変化しているのか(2023.09.30)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ(2022.01.09)
「チケット駆動開発」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
コメント