ソフトウェア・シンポジウム 2015 in 和歌山

スパムフィルタに基づく即時バグ予測ツールの試作
森 啓太

水野 修

京都工芸繊維大学 大学院工芸科学研究科 情報工学専攻

京都工芸繊維大学 大学院工芸科学研究科 情報工学部門

k-mori@se.is.kit.ac.jp

o-mizuno@kit.ac.jp

要旨

数を削減する手段として Fault-prone モジュール (バグを含むかもしれないモジュール) を予測する手法の研究

ソフトウェア工学において，Fault-prone モジュールのが数多く行われている [1, 2, 3, 4]．この手法は，バグの予測モデルの研究は数多く行われてきた．これらの研究含む可能性が高いと予測されたモジュールから重点的にの最終的な課題は，Fault-prone モジュール予測を実際処理できること，さらに早期にバグを発見し除去できるのソフトウェア開発の現場に適用していくことである．

ことから，品質確保活動の工数を削減する効果や，ソフ

そこで本稿では，その中でも構築が簡単で高い予測性

トウェア自身の品質向上への効果が期待されている．ま能をもつ「Fault-prone フィルタリング」という予測モ

た Kamei らは，モジュールの粒度を変更レベルとした予デルを利用して，Fault-prone モジュール予測ツールの測モデル [5] を提案し，テストすべき変更を順序付ける試作を行う．本試作ツールでは，ソフトウェアリポジトことにより工数を削減することができたと述べている．

リを監視して新しい変更があるごとにモジュールがバグ

さらに Kamei らの予測モデルでは，変更レベルで予測を含む確率を予測し，結果をツール使用者に Web ペーをするため，バグの早期発見やバグの混入者の特定も可ジ上で提示する．変更ごとに予測するため，バグを含む能であった．そして，こういった予測モデルを実際に開ファイルを変更した開発者を特定でき，さらにその時の発支援のためのツールとして現場に適用させていくこと

コード片を特定することで，ソフトウェアの品質確保活が Fault-prone モジュール予測の研究の最終的な課題と動にかかる工数の削減とソフトウェア自身の品質の向上なっている．

が期待される．

そこで本研究では，構築が簡単で高い予測性能をもつ

また，ツールの性能評価のため，3 つのソフトウェア「Fault-prone フィルタリング」[6] という予測モデルをリポジトリを対象に評価実験を行ったところ，ある程度利用して Fault-prone モジュール予測ツールの試作を行の予測性能を伴って予測結果をツールの利用者に Webう．この予測モデルは，その他の予測モデルが構築に様々ページで提示することが可能であるとわかった．

なメトリクスの収集環境を必要とするのに対し，ソースコードのみで構築が可能である．また，試作するバグ予測ツールでは，Kamei らの提案した変更レベルの予測の1. はじめに利点に注目し，ソフトウェアリポジトリからコミットごとに即時的にバグを予測する．本ツールの性能の評価実

ソフトウェア開発において，品質確保活動であるテス

験は，学習で用いた Git リポジトリの履歴を参照するこトやレビューといったソフトウェアのメンテナンスは重とで，バグが含まれるかどうかがわかっているモジュー要であり，かつ工数をかけすぎず効率的に行うことが期

ルと変更情報を関連付け，それらを新しい変更があった待されている．そのため，現在のソフトウェア開発ではと想定してツールに与えることで行う．

バージョン管理システム，バグトラッキングシステム，さらに工数見積りツールなどといった様々な開発支援のためのツールが開発され利用されている．
上記で述べた開発支援方法以外に，品質確保活動の工37

SEAソフトウェア・シンポジウム 2015 in 和歌山

2. 目的

メール内の単語群を学習してスパムメールかハムメールかを分類するための識別辞書を作成する．そして新しい本研究の目的は「Fault-prone フィルタリング」といメールについて，識別辞書とベイズ識別を利用してスパう予測モデルを用いて，Git リポジトリから変更ごとにムメールかどうかの分類を行う．これをソフトウェアに即時的にバグを予測するツールを試作し，「Fault-prone関しても，バグが存在するところには特定のコード片がフィルタリング」を用いたバグ予測ツールの有効性を考存在するという類推のもと適用する．テキスト情報のみ察することである．

で予測を行うため，複雑なソフトウェアメトリクスを使用した従来の予測モデルよりも容易にプロジェクトに適

この目的のため，以下の研究設問を設定し，ツールの用することができる．

有効性について考察する．本研究における研究設問は次の通りである．

3.3. 欠陥の変更時の即時予測
RQ1: Fault-prone フィルタリングによる即時バグ予測
ツールは構築できるか．

従来の Fault-prone モジュールの予測モデルはファイルやパッケージレベルでの予測のものがほとんどであっ

RQ2: 提案する即時バグ予測ツールによるバグ予測では，どの程度の精度が得られるのか．

た．それらの欠点として以下のことが挙げられる．

• 予測の粒度が粗い

RQ3: 提案する即時バグ予測ツールは開発に有用な情報を提供できるか．

• 予測が出たとしても，バグを混入した開発者が特定できない

3. 試作の準備• 予測が遅すぎて，開発サイクルと咬み合わない3.1. SZZ アルゴリズム

これらの欠点のため，変更 (git などにおけるコミット)レベルでの即時予測を行える予測モデルが注目されていSZZ アルゴリズム [7] とは，バグトラッキングシステ
ムのバグデータベースとバージョン管理システムのバーる．それらの利点として以下のことが上げられる．

ジョンアーカイブを相互に結びつけて解析することでバ• 予測の粒度が細かいグを混入したモジュールを特定するアルゴリズムである．

• バグを混入した開発者は，変更を行った開発者であ本研究では，研究室において開発・保守されているると簡単に特定できるツール (szz tools) を利用した．このツールは，バージョとしてバグ情報の記述された csv ファイルを用いて SZZ• 予測が早いので，開発サイクルへのフィードバックが容易

アルゴリズムを適用し，バグが含まれるモジュールとバ「予測の粒度が細かい」というのは，変更はファイルのグの含まれないモジュールを特定してその情報をリポジ差分の集合であると考えられるからである．本研究では，トリにタグとして添付するものである．このツールでのこの変更レベルでの即時予測の利点に注目する．

ンアーカイブとして Git リポジトリ，バグデータベース

モジュールの粒度は一つのファイルである．

しかし，本研究で使用する Fault-prone フィルタリン
グ自体の予測粒度は第 3.1 節で述べたツールの粒度から，3.2. Fault-prone フィルタリング

ファイルレベルである．そこで本研究では新しい変更ごとにその変更で修正されたファイルに対して Fault-prone

Fault-prone フィルタリングとは，スパムメールの判別を行うスパムフィルタ (CRM114) の技術をソフトウェアのソースコードに適用し，コードのテキスト情報のみフィルタリングを実行することで変更レベルでの予測とする．これを実装した本ツールに期待される利点は次の通りである．

から Fault-prone モジュールの予測を行うものである．

• 新しい変更に対して即時的にファイルのバグの確率を提示できる．

スパムフィルタは，スパムメールには特定の単語群や頻繁に含まれているという事実に基づき，過去に受信した38SEA

ソフトウェア・シンポジウム 2015 in 和歌山• コミット情報を保持しているのでバグの確率を上げた開発者及び日付などを特定できる．

4.2. 予測の手順
本実験のツールでは，前節で用意した Git リポジトリ• 確率はファイルごとに予測されるが，Git を用いてへの新しい変更に対して継続的に予測を行っていく．予

バグの確率が変動した前後で差分を取ることによ測の手順は，以下の項の通りである．

り，どういったコード片がバグの確率を上げているのかがわかる．

4.2.1

4. 即時バグ予測ツールの試作実験

学習

新しい変更に対して予測を行うためには，Fault-proneフィルタリングによる初期学習が必要である．前節で用本章では，本試作ツールが特定の Git リポジトリを継意したバグ情報を統合した各 Git リポジトリに対して次続的に監視して即時的にバグを予測していく際のツールの手順で学習を実行し，識別辞書を作成する．

内部の動作ついて説明する．また，ツールとしてのユー

1. FAULT タグと INNOCENT タグをリポジトリからザインタフェース部分である Web ページ部分の表示に取得する．

関する内部動作，操作方法ついてもこの章で述べる．最後に，予測性能の評価手法について説明する．

2. これらのタグを用いて，リポジトリからモジュールのソースコードを読み出し，FAULT であるか IN-

4.1. 予測の準備
4.1.1

NOCENT であるかの情報と共に記録していく．

リポジトリとバグ情報の取得

3. それらすべてをトレーニングセットとしてテキストフィルタを用いて学習させ，FAULT と INNOCENT

本実験ではツールでの予測対象として次の 3 つの Javaの識別辞書をそれぞれ作成する．

で開発されているオープンソースプロジェクトのリポジトリとそのバグ情報を取得した．

本実験のツールは試作であるため，スパムフィルタリン
グで用いられる手法である「誤判定時のみ学習」による• Apache OpenJPA

学習の強化を実装していないので，この学習の処理は予• Apache James

測を開始する前の 1 回のみ行われる．

• Eclipse Birt
4.2.2
4.1.2

バグ情報との統合

変更の取得

変更の取得と解析の手順は次の通りである．

本実験ではリポジトリをバグを予測するための学習のに対して研究室で開発・保守されている SZZ アルゴリズ

1. git fetch コマンドを使用して差分を取得する．
このコマンドにより，Git はリモートリポジトリからローカルリポジトリとの差分を取得する．このとムを用いたツール (szz tools) を適用してリポジトリにバき，フェッチしてきたコミットの中で最新のものはグ情報を与える．このツールを用いると，Git の tag コ

Git 内で FETCH HEAD という名前で参照できる．

データセットとして用いるために，これらのリポジトリマンドを利用してバグ除去時点のコミットには FIX タグ

2. git log HEAD..FETCH HEAD –name-status コマンドを使用して差分に対するログを取得する．
「HEAD..FETCH HEAD」という引数を指定をすを，バグの混入時点のコミットには BUG タグを添付することができ，さらにバグが含まれるモジュール (ファイル) を特定し，FAULT タグを添付した後，それ以外ることにより，HEAD(ローカルリポジトリの最新に INNOCENT タグを添付することができる．のコミット) から FETCH HEAD(リモートリポジトリの最新のコミット) までの範囲を指定して Gitからログを取り出す．さらに「–name-status」とい39SEAソフトウェア・シンポジウム 2015 in 和歌山

う引数を指定することにより，各コミットで変更さグラムを利用する．cron に前節の第 4.2.2 項から第れたファイルのファイル名とその変更情報を加えて4.2.3 項までの処理を行うプログラムを指定し，任意の時間間隔で自動的に実行させる．これにより，取得することが出来る．

定期的に変更があったかどうかを確認し，即時的な3. ログを解析する．
得られたログから各コミットごとにそのコミットのFault-prone モジュールの予測を行うことが出来る．

情報と，予測する対象のモジュールとして追加，変4.4. Web ページヘの表示

更，コピー，または修正のあったファイルの名前を記録していく．

それぞれのページについての出力や操作方法について以下に説明する．

4. git merge FETCH HEAD コマンドを使用してローカルリポジトリを更新する．
このコマンドにより，差分のログの解析が終わった• main.cgi
本ツールのメインページであり，図 1 で示すようにローカルリポジトリをリモートリポジトリと同じ状予測結果の検索フォームによる検索と，cron での実態にする．つまり HEAD が FETCH HEAD の指す行のログの確認ができる．検索フォームで入力できものとなる．これにより次回の変更の取得に備えるるものは次の通りである．

ことができる．

– Repository’s name (セレクトボックス)
結果を表示したいリポジトリの名前を指定する．

4.2.3

分類

– Omit commits which have no java files (ラジオボタン)

前節でログを解析して得られた各モジュールをスパムフィルタによる分類にかけ，得られた確率，ファイル名，Java ファイルを持っていないコミットを表示

及びコミットの情報をデータベースに格納していく．

するかどうかを指定する．

– Order of commit’s date (ラジオボタン)
コミットの日付が新しい順番で表示するか古い順番で表示するかを指定する．

4.3. リポジトリの監視
本実験のツールで，リポジトリの監視をしていくため– Date (日付入力欄)には以下の操作を行う．

コミットの期間を指定する．

• 登録用プログラムによるツールへのリポジトリの登録
前節第 4.2.1 項で述べたように，予測をする前には– Commit ID (テキストボックス)
コミットの ID(40 桁の SHA-1 ハッシュ) を指定する．

学習が必要である．しかしこの学習には時間が大き– Author (テキストボックス)

くかかるため，リポジトリ登録用プログラムをツーコミットした開発者名を指定する．

ルの一部として作成した．このプログラムは，学習– Commit message (テキストボックス)
コミットメッセージを指定する．

が終わった時にツールへとリポジトリの情報の登録を行う．新しいリポジトリを監視したい時は，この登録用プログラムの引数として新しいリポジトリを– File name (テキストボックス)
ファイル名を指定する．

指定することによってツールへ監視対象として登録ができる．

– show (ボタン)• cron によるリポジトリの監視の設定
本実験ではリポジトリの動きを監視するために，上記の条件で検索を開始する．検索結果はUnix 系 OS においてコマンドの定時実行のスケジュール管理を行うために用いられる cron というプロ• show result.cgi
main.cgi の検索フォームからの入力を受け取り，そshow result.cgi で表示する．

40SEA

ソフトウェア・シンポジウム 2015 in 和歌山

れらを条件としてデータベースから予測結果を検索かどうか予めわかっているものを，Git リポジトリし，Web ページにコミットごとに予測結果をまとの履歴を参照し変更と関連付け，それらの変更を新めて図 2 のように表示する．

しい変更があったと想定してツールに与えることで評価する．また，ただデータを集計するだけでなく• about.html
本ツールの使い方について記述されているページ．

ツールとして Web ページ上で，どの程度予測の精度があるのかを確認できるようにする．

• setting.cgi
監視しているリポジトリに対して，データの削除などの設定を行う．

以下の手順で評価実験を行う．

1. テストデータの準備• setting apply.cgi
setting.cgi からの入力を受け取り，実際にデータ本ツールで行う予測では，テストのために利用すベースやデータファイルの内容を変更し，設定結連付けられていているモジュールでなければならな果の旨を表示する．

い．しかし，モジュールに添付された FAULT タグ

るデータはコミットごとにそのコミットの情報と関と INNOCENT タグにはコミットの情報が入っていないため，リポジトリの履歴を参照し，タグを逆算することによりコミットごとのモジュールを取得する．取得するコミットは，バグを含むモジュールと含まないモジュールの数のバランスを考え，BUGタグがついているコミットを選択する．SZZ アルゴ
リズムの特性上，これをしなければバグを含まないモジュールの数が多くなってしまうためである．取得したコミットとモジュールを関連付けたものをテストデータとする．

2. 分類テスト
前述で準備したテストデータを用いて，分類テストを以下の手順で行う．
• 各モジュールに対してバグである確率を予測して，モジュールが実際にバグであるかの情報と共に予測した確率をデータベースに登録する．
図 1. ツールのメインページ• データベースから前述で登録した情報を取り出し，閾値を 0.5 として分類して結果を集計する．

4.5. 予測性能の評価実験

5. 予測の結果

評価実験の概要
最後に，本研究において本ツールの性能・信頼性の5.1. 対象とした Git リポジトリの学習時のデータ評価の実験は，研究設問に回答し，ツールの有効性を考察するために必要不可欠なものである．

前章で述べたように 3 つの実験対象としたリポジトリ

この実験では，実際のツールの使用を想定して，学に対して，SZZ アルゴリズムを利用したタグの添付によ習時に用いた第 4.1.2 節で FAULT，または INNO-りモジュールがバグを含むかどうかを特定した．その結CENT タグを添付されたモジュール，つまりバグ果の集計を表 1 に示す．

41

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

図 2. 予測結果表示ページ (対象は Apache OpenJPA)

これらのモジュールは，ツールでの即時予測と評価実表 2. 分類結果の凡例験を行うための学習でデータセットとして用いた．

実測
バグを含まないバグを含む

表 1. 各 Git リポジトリの学習時のモジュール数
コミット数
バグを含まないモジュール
バグを含むモジュール
合計

Apache OpenJPA
4383
9273
12518
21791

Apache James
11866
21600
3794
25394

Eclipse Birt
29501
41794
35398
77192

予測
バグを含まないバグを含む
TNFP
FNTP

• TN (True Negative): バグでないと分類したもの
で，実際にバグでなかったモジュールの数．

• FN (False Negative): バグでないと分類したもの
で，実際はバグであったモジュールの数．

5.2. 評価実験

精度 (Accuracy)

5.2.1

評価指標

精度は，分類結果全体の中で分類成功であった割合を示す．よって以下のように定義される．

試作したツールの評価実験で得られた結果の評価指標
として精度 (Accuracy)，再現率 (Recall)，適合率 (Pre-Accuracy =cision)，F1 値を用いる．分類結果の凡例を表 2 に示す．

TP + TNTP + FP + TN + FN

(1)

全体的な傾向を把握することができるがデータの隔• TP (True Positive): バグと分類したもので，実際にバグであったモジュールの数．

たりなどに大きく影響を受けるので，再現率と適合率を併用する．

• FP (False Positeve): バグと分類したもので，実際はバグでなかったモジュールの数．

再現率 (Recall)
再現率は，実際にバグであったモジュールの中でバ42

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

グであると分類したものの割合，つまり網羅率を示

またツールとして，Web ページでは，図 3 に示す

す． よって以下のように定義される．

ようにファイル名の右側に実際にバグを含む ([B])

Recall =TP
TP + FN

か含まないか ([N]) という情報を加えて表示するこ(2)とで，どの程度予測が正しいかツール上でもおおまかに確認することが出来た．また，計算した評価指適合率 (Precison)

標を Web ページ上でも示すことによって，ツール適合率は，バグであると分類したモジュールの中の予測性能の状態を把握できるようにした．

で実際にバグであったものの割合，つまり無駄なモジュールをどれだけ調べる必要があるかというテス
表 4. 分類結果 (Apache OpenJPA)

トのコストを示す．よって以下のように定義される．

TPP recision =TP + FP

実測バグを含まないバグを含む(3)

予測バグを含まないバグを含む
4559
1816
14427467

F1 値
F1 値は，再現率と適合率がトレードオフの関係にあるため，両者を総合的に判断するための指標であ

表 5. 分類結果 (Apache James)

り，再現率と適合率の調和平均によって示される．
実測バグを含まないバグを含む

よって以下のように定義される．

F1 =

5.2.2

2 × Recall × P recision
Recall + P recision

予測
バグを含まないバグを含む
3657
5824
2334714(4)評価結果

表 6. 分類結果 (Eclipse Birt)

第 4.5 節の手順の通りに結果を示す．

実測
バグを含まないバグを含む

1. 用意したテストデータ
用意したテストデータの集計を表 3 に示す．この

予測バグを含まないバグを含む
6498
12234
2519
21734

表で示すデータには，本研究の変更ごとの即時バグ予測を行うという特性上から，複数のコミットが同

6. 考察

じ状態のモジュールを指すことがあるため，テストセットとして同じモジュールがいくらか含まれてい6.1. 本ツールの有効性る．そのため独立したモジュールの数も集計した．
表 4 から表 7 に示した評価実験の結果を踏まえて，第2 章で定めた研究設問に答えることで本ツールの有効性について考察する．

表 3. 評価実験で用いたテストデータ
コミット数
バグを含まないモジュール
独立したモジュールバグを含むモジュール
独立したモジュールモジュールの合計

Apache OpenJPA
1828
6375
6160
8909
8811
15284

Apache James15139481
5812
4947
2347
14428

Eclipse Birt
7098
18732
18489
24253
24049
42985

RQ1: Fault-prone フィルタリングによる即時バグ予測
ツールは構築できるか．
本予測モデルの構築に必要となるのはソースコードのみであるので，ツールとしての実装は容易である．
この点に関しては，様々なメトリクスを要求する予2. 分類テストの結果

測モデルを用いたツールよりも優れていると考えら

各リポジトリの分類結果を表 4 から表 6 に示す．次れる．しかし，FindBugs[8] のような静的コード解に前節で定義した評価指標を用いた分類テストの評析ツールと比較すると，機械学習のコストが構築の価を表 7 に示す．

際にかかってしまう．

43

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

図 3. ツール上での評価結果の表示 (対象は Apache James)なければならないことになる．しかし，この表 7. 分類テストの評価
Apache OpenJPA
Apache JamesEclipse Birt

精度
0.78680.58020.6568

再現率
0.8381
0.95290.8961

適合率0.80440.44730.6398

ツールではバグの確率を変更ごとに予測する

F1 値
0.82090.60880.7466

ことができるため，Git を用いてバグの確率が変動した前後で差分を取り，その差分のみをレビューするなどの工夫をすることで，工数を削減できる．また，予測のタイミングが早く，開発者の特定も可能なこともコードのメ

RQ2: 提案する即時バグ予測ツールによるバグ予測では，どの程度の精度が得られるのか．
評価実験により，表 7 に示すような精度が得られた．

ンテナンスにかかる工数を減らす要因となるだろう．

この結果に対して以下のことが考察できる．

RQ3: 提案する即時バグ予測ツールは開発に有用な情報• このツールでのバグの網羅性を提供できるか．

得られた再現率は 8 割から 9 割であり，これは本ツールは，変更ごとにモジュールがバグを含む確本ツールでチェックしたコミットに属するファ率の情報を与えることでコストをかけるべきファイイルのうち，実際にバグであるもののほとんルを選択することが出来る．評価実験では，バグでどを網羅できていることを示す．

あると判断する閾値を 0.5 としたが，この値を変更• このツールでの確率の提示による品質確保活動のコスト得られた適合率は，4 割から 8 割とかなりばらすることで品質確保活動のコストの調整がある程度つきがあった．4 割であった場合，1 つのバグを厳しくし，レビューするモジュールを減らすことを含むモジュールを発見するためには，1 つかができる．

2 つの実際はバグを含まないモジュールを調べまた，開発者へ開発のフィードバックを与えること可能となるだろう．例えば，本実験結果では再現率が十分に高いので，閾値を上げることでバグの判断

44

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

6.3. 今後の課題が出来る．本ツールで実際にリポジトリを監視していたところ，図 4 のように「Refactor code.」とい本研究で試作したツールにおける今後の課題は以下のうメッセージを持つ変更の前後でファイルに対する通りである．

バグである確率の変動が見られた．この図のように確率が下がった場合は，達成度を開発者に与えられ• 継続的な学習の実装
本ツールを実際の現場へと適用するためには，予測るだろう．また，このようなときに Git を用いて差分を取ればどういったコード片がバグの可能性を高した結果が正しかったかどうかの情報を後から入力めているのかを知ることが出来る．

することにより，誤判定ならば学習するという「誤判定時のみ学習」による状況に合わせた学習の強化

6.2. 妥当性の検証は必須である．また，そのたびに Web ページ上で提示する精度などの評価指標も更新すると良いと思

本研究の妥当性について以下に示す．

われる．

• オープンソースプロジェクトに対する実験実験で用いたのは，全てオープンソースのプロジェ• 予測結果の Web ページヘの表示速度の改善
予測結果の絞込をする際，データベースの検索に時クトである．このため商業のプロジェクトに今回の間が掛かる場合があった．このためデータベースの実験と同じ手法を適用しても，同様の結果が得られスキーマやプログラムを改善する必要がある．

るとは限らない．

• SZZ アルゴリズム
本研究でモジュールにバグを含むかどうかのタグを7. 結言添付するのに用いた SZZ アルゴリズムは，完全に

本稿では，「Fault-prone フィルタリング」という予測バージョン管理システムとバグ情報を結び付けられモデルを利用して Fault-prone モジュール予測ツールのるものではない．

試作を行い，このツールの理論，内部動作，操作方法，また，最近のコミットで変更されたファイルについ評価手法およびその結果，考察を述べてきた．3 つのソては，バグ情報が不足しているのでほとんどのもの

フトウェアリポジトリを対象にした評価実験の結果をもに INNOCENT タグがつけられてしまう．とに考察を行った結果，「Fault-prone フィルタリング」を用いたバグ予測ツールは構築可能であり，本ツールは• 評価実験におけるテストデータの偏り
本実験では，上述した SZZ アルゴリズムの特性から，INNOCENT タグが添付されたモジュールが多ある程度の予測性能を伴って予測結果をツールの利用者に Web ページで提示することが可能であるとわかった．

くならないように，BUG タグのついているコミッ

参考文献

トのみを実験時のツールの入力として使用した．しかし，BUG タグが付けられているコミットの期間，[1] 畑 秀明, 水野 修, 菊野 亨, “不具合予測に関するメトリクスについての研究論文の系統的レビュー “, コン
ピュータソフトウェア, vol.29, no.1, pp.106-117, Feb.
2012.

つまりバグ情報が存在している期間を抽出し，その期間での BUG タグがついていないコミットもテストデータとして含めた方が実験における評価の妥当[2] P. Bellini, I. Bruno, P. Nesi, and D. Rogai, “Comparing Fault-Proneness Estimation Models“, Proc. of
10th IEEE International Conference on Engineeringof Complex Computer Systems, pp.205-214, 2005.

性が上がる可能性がある．
また，結果の表 3 に示すように Apahce James においては，独立したモジュールの数が全体のモジュー[3] Tim Menzies, Jeremy Greenwald, and Art Frank,“Data Mining Static Code Attributes to Learn Defect Predictors“, IEEE Trans. on Software Engineering, vol.33, no.1, pp.2-13, Jan. 2007.

ルに対して半分ほどであったため，本実験の評価の妥当性は低い可能性がある．

45

SEA

ソフトウェア・シンポジウム 2015 in 和歌山

図 4. バグである確率の変動 (対象は Eclipse Birt)[4] Naeem Seliya, Taghi M. Khoshgoftaar, and Shi Zhong,“Analyzing Software Quality with Limited FaultProneness Defect Data“, Proc. of 9th IEEE International Symposium on High-Assurance Systems Engineering, pp.89-98, 2005.
[5] Yasutaka Kamei, Emad Shihab and Bram Adams,Ahmed E. Hassan, Audris Mockus, Anand Sinha, andNaoyasu Ubayashi, “A Large-Scale Empirical Study ofJust-in-Time Quality Assurance“, IEEE Trans. Softw.
Eng, vol.39, no.6, pp.757-770, June 2013.
[6] O. Mizuno and T. Kikuno, “Training on Errors Experiment to Detect Fault-Prone Software Modules bySpam Filter”, The 6th joint meeting of the European
Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE2007), pp.405-414, 2007.
[7] J. Śliwerski, T. Zimmermann, and A. Zeller, “Whendo changes induce fixes?”, Proceedings of the 2005 international workshop on Mining software repositories,
pp.1-5, 2005.
[8] (2015, Mar.) FindbugsTM - find bugs in java programs.
[Online]. Available: http://findbugs.sourceforge.
net/46SEA