構成管理ツール、リリース履歴、不具合管理票のMiningに関するワークショップ（MSR 2007)
5/19, 20に開催されたInternational Workshop on Mining Software Repositoriesに参加、発表した。今年は70名弱の参加者があり、当初予定されていた会議室を変更しなければならないくらいの盛況だった。今年は12ヶ国からの投稿があり、採択率は36%だったそうだ。ほとんどの研究テーマはオープンソースソフトウェアのCVSやメールやバグ管理ツールを対象として、法則や特徴を抽出(モデル化)することを目的としたテーマが集まっている。
ソフトウェアリポジトリに対するマイニングという共通テーマが世界レベルで通じることと、自分のテーマと非常に近いところにあるテーマを見聞きできて非常に有意義だったと感じている。私の発表での対象は商用開発で収集されたデータだったので、対象データは少しずれていた。場所はミネアポリスでInternational Conference on Software Engineeringの併設開催である。
ワークショップの特徴は以下のとおり。
- 多くのテーマはオープンソースで蓄積されているリポジトリを対象とする。たとえばLinuxのカーネル、apache、MySQLなど。
- 得られた規則性や特徴は予測に使う。たとえば、バグを含んで いる可能性が最も高いソースコードファイルの特定など。
- bに加え、得られた知見が商用の開発にも流用できるかどうかを議論する。
モデル化の対象として、以下があった。
- Javaで書かれたソフトウェアでimportされているクラスがリリース後のバグにどれくらい影響を与えているかを調べる(bの例)。
- 特定のGUIライブラリをimportすると14%程度のソースコードでリリース後のバグが発生する。特定のコンパイル用のクラスライブラリで71%の割合でリリース後のバグが発生する、等の結果を得る。
- Bで作成したモデルに基づき、EclipseのIDEを通じ、変更しようとしているソースコードがどの程度の変更リスクを抱えているかをユーザに提示する。
私の今回の発表は、結論部に平均値と標準偏差を持つ相関ルール分析を商用開発のバグ票に適用してみた結果をまとめたものである。おなじみの「AかつBならば、C」というルールの結論部分（C）を数値として扱えるようにしてある。これをバグ票から得られる修正にかかった時間としてあり、たとえば、「（機能=A）かつ（修正フェーズ=総合テスト）ならば（修正工数の平均は20時間、標準偏差は18.2」のようなルールが得られる。
詳しくは、こちらを参照されたいが、抽出されたルールから、(a) 修正工数が大きなルール（修正工数の平均が大きいルール）、(b) 修正工数がばらつくルール（修正工数の標準偏差が大きいルール）、(c) 修正工数の小さなルール（修正工数の平均が小さいルール）の3種類の上位3つをあげ、考察している。
対象は典型的分散開発型ウォータフォール開発であり、(a)として、製造（コーディング）工程で混入され、総合テストまで発見されなかった重大な不具合、(b)として、再現性が低い不具合、(c)としてロジックが単純な機能から発見された不具合で、製造で混入され、製造で除去されたもの、という結果が得られた。(a)も(c)も比較的当たり前のルールではあるが、修正工数の具体的な値と出現頻度がわかるので、レビュー工数との配分を勘案することができる。