ソフトウェア・シンポジウム2018 in 札幌

不具合混入コミットの推定手法間での整合性比較と考察
北村 紗也加水野 修

京都工芸繊維大学 大学院工芸科学研究科 博士前期課程 情報工学専攻

京都工芸繊維大学 情報工学・人間科学系

s-kitamura@se.is.kit.ac.jp

o-mizuno@kit.ac.jp

要旨

れる [2]．
ソフトウェア工学における品質予測の研究を活性化さ

ソフトウェアの複雑さと重要性は日々増してきており，せたものとして，S̀liwerski，Zimmermann，Zeller によっ

ソフトウェアの品質を高い水準で保つことが重要視されて提案された，ソースコードやリポジトリデータを用ている．このような現状においてはソフトウェアの品質

いて不具合を混入したと推定されるコミットを発見する

予測は重要な研究テーマであり，どのような手法で品質

SZZ アルゴリズム [3] がある．SZZ アルゴリズムはバージョン管理システムにおいて変更履歴を辿り，不具合を混入したコミットを特定する．この SZZ アルゴリズムとはまた別のアルゴリズムで不具合コミットを特定するツールを公的に入手可能にしたものとして，Commit
Guru [4] 等が存在する．
Commit Guru は，登録された Git リポジトリにおける全てのコミットに対し分析を行い，13 のメトリクスを計算し，不具合を混入したコミットを推定する．また，その分析結果を利用者らに無償で提供している．
Commit Guru による不具合混入コミット（以降，不具合コミットと呼称）の情報は，昨今の研究において不具合の正解データとして利用されることが多い．しかしながら，Commit Guru が推定する不具合コミットは簡易的な手法を用いており，正解データとしての信頼性は不明である．そこで，本研究では Commit Guru および SZZ アル
ゴリズムを用いて，分析結果の整合性を比較し，Commit
Guru の正解データとしての信頼性について考察を行う．

予測を行うかに注力されてきた．不具合混入コミットを推定する手法では，その評価を行うためには正解データが必要であり，不具合の正解データ (真値) として Commit

Guru による不具合混入コミットの情報が多く利用されている．しかしながら，Commit Guru の不具合混入コミッ
トの情報の正解データとしての信頼性は不明である．
本研究では，その信頼性に対する検証を行った．不具合混入コミット推定手法である SZZ アルゴリズムを用いて，同じ不具合データに対する結果の整合性を比較し，その結果を考察した．Commit Guru，および SZZ アルゴ
リズムを用いた不具合コミット推定結果の差異において検証を行った結果，Commit Guru の方がより優れた不具
合コミット推定の結果を示し，正解データとしての可能性を示すものとなったが，その信頼性は十分であるとは
言い難い．

1

はじめに

2

近年，ソフトウェアの重要性と複雑さは増しつつある．
このような現状におかれたソフトウェア開発の現場では，

準備

2.1 バージョン管理システム

ソフトウェアに混入した不具合を修正するために膨大な時間とエフォートが割かれており，またそれに伴うコスバージョン管理システムとは，コンピュータ上で作成・トも膨大であるため [1]，ソフトウェアの品質を高い水編集されるファイルの変更履歴を管理するためのシステ

準で保つことが重要視されている．したがって，最近のムである．本研究で用いた SZZ アルゴリズム，およびソフトウェア工学の研究ではソフトウェアの分析とソフ

Commit Guru はバージョン管理システムの情報を用いて不具合コミットを推定しており，バージョン管理システ

トウェアの品質予測に焦点を当てたものが多く見受けら

38

SEA

ソフトウェア・シンポジウム2018 in 札幌

ムとして分散型バージョン管理システムである Git を使

2.3.2 不具合が混入された箇所の特定用した．

FIX タグがつけられたコミットを取得する．このコミットにおいて変更されたファイルに対し，バージョン管理システムの diﬀ コマンドを用いてコミットにおける変更箇所を抽出する．
もし変更箇所が見つからなければ FIX タグの削除を行
い，変更箇所が見つかれば，その変更はどのコミットにおいて行われたのかを特定する．変更箇所に対してバー
ジョン管理システムの blame コマンドと正規表現を用いて，その変更を行ったコミットの日時を抽出する．抽出されたデータから不具合を混入したと予測されるコミッ
トに対し，不具合コミットであることを示す BUG タグをつける．

2.2 バグトラッキングシステム
バグトラッキングシステムとはプロジェクトのバグを登録し，そのバグの修正状況を追跡するシステムであり，バグの履歴管理や検索を行うことができる．本研究で用いた SZZ アルゴリズムは，バグトラッキングシステム
から取得した対象プロジェクトの不具合データを用いて不具合コミットを推定しており，バグトラッキングシス
テムとして Bugzilla と Apache’s JIRA issue tracker を使用した（表 1）．

2.3 SZZ アルゴリズム
2.4 Commit Guru
SZZ アルゴリズムは不具合混入コミット推定手法の中で最もよく知られている手法である．
本研究で使用した SZZ アルゴリズムは，バージョン管理システムのバージョンアーカイブとバグトラッキングシステムの不具合データを用いて，次の 2.3.1 節，2.3.2
節で述べる 2 つのステップを経ることにより不具合コ
ミットの推定を行う．

Commit Guru は Kamei らの変更レベルの不具合予測
モデル [6] を Web アプリケーションとして実装したものであり，Rosen らによって公開されている．本研究において，Commit Guru での不具合混入ラベル，メトリクス
を分析データの整合性比較に用いる．Commit Guru の機能である (1) 不具合コミットのラベル付け，(2) メトリク
スの測定，および (3) ダンプデータの提供について次に述べる．

2.3.1 修正された箇所の特定バージョン管理システムのバージョンアーカイブには，変更に関する情報が含まれている．バージョン間におい2.4.1 不具合コミットのラベル付けて同じ意図で行われてた変更を特定するため，バージョCommit Guru はコミットに対し，不具合を混入したコ
ミット (Buggy) とそれ以外のコミット (Clean) を不具合
混入ラベルにおいて TRUE/FALSE でラベル付けを行う．
不具合コミットは不具合を修正したコミットから推定できる．
始めに，Commit Guru は Hindle らの研究 [7] におけるコミットを分類するためのキーワードリストを元に，コ
ミットメッセージの解析を行い，各カテゴリに分類する．
ここでは， bug , fix , wrong , error , fail ,problem , patch といったワードを含むコミットが不具合を修正しているであろうコミットとし，Correctiveに分類する．
次に，修正を行ったコミットから不具合を混入したであろうコミットを特定する．まずバージョン管理システムのdiﬀ コマンドを用いて，どの行が修正を行ったコミットによって変更されたのかを特定する．ここで変更された行ンアーカイブから不具合が混入されたコミットの日時，
不具合を最後に修正されたコミットの日時を抽出し，バグトラッキングシステムの不具合データと照らし合わせ
る．抽出されたデータが不具合の修正と予測されるのであれば，この不具合を修正したであろうコミットに対し，修正したことを示す FIX タグをつける．
バージョン管理システムのバージョンアーカイブには変更の目的が欠けており，行われた修正が不具合を修正したのか，機能追加であるか判断することができない．
ログメッセージのみから目的を予測することは出来る [5]が，不具合に関する簡単なレポート，不具合のステータ
スや解決策が格納されている不具合データを組み合わせることで，不具合予測の精度向上を図る．
1 問題とは不具合，機能要求，改善，タスクなど不具合以外にも様々なものを指すが，本研究においては不具合のみを対象としたバグトラッ
キングシステムとして用いている．

39

SEA

ソフトウェア・シンポジウム2018 in 札幌

表 1. 使用したバグトラッキングシステムとそのメトリクス
システム

システム概要メトリクス

メトリクス概要

Bugzilla

Mozilla Foundation によって開発されたウェブ
ベースのバグトラッキングシステム

Bug ID
OpenedChanged

不具合に対して一意に与えられる ID
不具合が発見された日付
不具合が最終的に修正された日付

Apache’s JIRA issue tracker

Atlassian によって開発された商用の問題
トラッキングシステム1

Issue key
CreatedResolved問題に対して一意に与えられるキー問題が作成された日付問題が解決された日付に対して，バージョン管理システムの annotate/blame コ

位和の合計は次のようになる．

マンドを用いることで，それらの修正されたソースコー

N(N + 1)
(1)
2
これより，両郡のデータサイズ，順位和を用いて，次の式を用いて統計量を求める．
R1 + R2 =ドがどのコミットで追加されたのかを特定する．ここで見つかったソースコードを組み込んだコミットを，不具合を混入したであろうコミットとしてラベル付けする．

2.4.2 メトリクスの測定

U1= R1 − n1 (n21 +1)

(2)

U2

= R2 − n2 (n22 +1)(3)測定されるメトリクスを表 2 に示す．Kamei らの不具

式 (2)，式 (3) によって求めた U1 , U2 において小さい

合予測モデルで利用されているものと同様の数値メトリ方の値を U とする．U は有意性を調べるときに用いらクス 13 個，および論理メトリクス 1 個から成る変更にれる．サンプルサイズが大きい場合，U は正規分布に近関するメトリクスである．

似できる．このとき，z は次式で表される．

z=2.4.3 ダンプデータの提供

U − mUσU(4)

ここで，mU および σU は U の平均および標準偏差であ分析した Git リポジトリのダンプデータは CSV 形式

り，有意性を調べることができる標準正規偏差である．

mU および σU は次の式で表される．

で提供されている．このダンプデータには，2.4.2 節において述べた 14 個の計測したメトリクスに加え，コミッmUトハッシュやそのコミットの分類カテゴリなどが格納さσUれている．本研究では，このダンプデータを用いて分析を行っている．

=√= n12n2(5)

n1 n2 (n1 +n2 +1)
12(6)

タイ値が存在した場合，次の式で σ の補正を行う．
v
u


t
k
∑
n1 n2 ti 3 − ti (n + 1) −σcorr =(7)12 n(n − 1) i=1

2.5 マン・ホイットニーの U 検定
マン・ホイットニーの U 検定 (MannWhitney U test) とここで，n = n1 + n2 であり，ti はランク i を共有するタは，ノンパラメトリック検定のひとつであり，『対応のなイ値の数であり，k はランクの数である。

い 2 群が同じ分布の母集団から構成されている』とする

本研究においては，Python の scipy パッケージを用い

帰無仮説に基づいて検定する．

てこのマン・ホイットニーの U 検定を使用した．

データサイズ n1 のデータ D1 ，およびデータサイズ n2のデータ D2 (n1 ≤ n2 ) から成る 2 つのサンプルデータ群

3に対し，両郡のデータの値が小さい順に順位を割り当て，

D1 , D2 のそれぞれの順位和 R1 , R2 を求める．同じ値のデータが存在した場合には，それらが異なると考えた場
合の順位の平均値を割り当てる．このとき，D1 , D2 の順

実験

3.1 研究設問
先に述べたとおり，不具合混入の正解データ (真値) を作成する手法として，SZZ アルゴリズムや Commit Guru

40

SEA

ソフトウェア・シンポジウム2018 in 札幌

表 2. メトリクス一覧
名前

定義

説明

関連研究

la

変更によって追加されたコード行数

追加されるコード行数が多いほど不具合が混入しやすい．

ld

変更によって削除されたコード行数

削除されるコード行数が多いほど不具合が混入しやすい．

コード行数の相対的なメトリクスは欠陥
モジュールにおいて効果の高い指標である [8, 9]．

lt

変更前の総コード行数

大きいファイルほど，そのファイル内の変更は不具合を混入している可能性が高い．

ns

変更されたサブシステム数修正したサブシステム数が多い変更ほど， 変更における不具合の確率はサブシステム
不具合が多くなりやすい．
数が増えるにつれ高くなる [11]．

nd

変更されたディレクトリ数修正したディレクトリ数が多い変更ほど， 変更されたディレクトリの数が多いほど，不具合が多くなりやすい．
不具合を混入する機会が増える [11]．

nf

変更されたファイル数

関係するファイル数が多い変更ほど，不具合が多くなりやすい．

ndev

修正されたファイルを変更したことがある人数

コーディングデザインの違いの観点から， ファイルに携わった人数が多いほど多くのファイルの開発に携わった人数が多いほど不具合を含んでいる [13]．
不具合が混入しやすい．

age

修正された全てのファイルにおいて前回の変更から経過した平均日数

直近の変更ほど，不具合を混入する原因になりやすい．

昔の変更より最近の変更の方がより不具合に寄与する [14]．

nuc

修正されたファイルにおける変更の個数

以前の変更を探し出す必要があるため，nucが大きいほど不具合を混入しやすい．

修正したファイルの範囲が広いほど，複雑さが増す [15]．

exp

変更を行った開発者の総コミット数

経験豊富な開発者ほど不具合を混入しにく
い．

rexp

age によって重み付けされた exp

最近そのファイルに対しよく変更を行なっている人物はそのファイルに対しての知識が深いと考えられるため，不具合を混入し
にくい．

sexp

変更されたサブシステムに対するこれまでの変更の数

サブシステムについてよく知っている人物
は不具合を混入しにくい．

entrophy

変更が多くのファイルに渡って行われているほど大きくなる値

ファイルに跨って分散している多くの変更を探し出す必要があるため，高いエントロ
ピーを持つ変更は不具合が多くなりやすい．

分散した変更は不具合を混入しやすい [15,
16]．

fix

変更が不具合を修正したかどうか (TRUE / FALSE)

不具合修正は初期実装における欠陥を意味するため，その近辺で欠陥が存在する可能性が高い．

不具合を修正した変更は新機能を実装した
変更よりも不具合を混入しやすい [17, 18]．

大きいファイルほど不具合を多く含む [10]．

モジュール内のクラス数はリリース後における欠陥が現れやすい特徴である [12]．

プログラマの経験は不具合の確率を著しく低下させる [11]．

3.2 対象プロジェクトが知られているものの，手法間ので正解データの違いについては検証が進んでいない．

本実験では，表 3 に示すプロジェクトを対象に分析を本研究では次に示す研究設問（Research Question）を行った．

設け，検証を行う．

• RQ1: Commit Guru と SZZ アルゴリズムにおいて，それぞれの不具合混入コミット推定の結果にはどのような特徴が存在するか．

3.3 準備
使用したバグトラッキングシステムの不具合データを
表 4，Commit Guru より得られた対象プロジェクトのダ• RQ2: Commit Guru と SZZ アルゴリズムにおいて，不具合混入コミット推定性能の差はどの程度か．

ンプデータの詳細を表 5 に示す．
以降において，指定したコミット群を表 6，表 7 のように呼称する．また，(BUGszz , CLEANszz )，(BUGguru ，

CLEANguru ) のペアを，それぞれ CFszz ，CFguru と呼称す

41

SEA

ソフトウェア・シンポジウム2018 in 札幌

表 3. 対象プロジェクト
Project

機能

リポジトリ URL

Log4j
OpenJPA
Camel
HBase

Java のロギングツール
Java Persistance API 仕様のオープンソース実装
Java ベースのオープンソース統合フレームワーク
列指向データベース管理システム

https://github.com/apache/log4j
https://github.com/apache/openjpa.git
https://github.com/apache/camel
https://github.com/apache/hbase.git

表 4. 使用した不具合データ
Project

Bug-tracking System

Resloved

Resolution

Issue Typestatus# of bugs

Log4j

Bugzilla≤ 2018-01-22

FIXED

−

RESOLVED, VERIFIED, CLOSED305

OpenJPA
Camel
HBase

JIRA

≤ 2018-01-17≤ 2018-01-22≤ 2018-01-29−

bug

closed

1162
1457
5466

表 5. 得られたダンプデータ
Project# of Total Data

Log4j
OpenJPA
Camel
HBase

3275
4864
30739
14745

Buggy rate
45.6%
11.1%
20.7%
31.9%

表 7. 推定結果に基づくコミット群 (2 手法)

Date dumped

MethodClassify as

2018/01/17
2018/01/10
2018/01/10
2018/01/23

SZZ

Classify as
Buggy
Clean

SZZ
Commit Guru

BUGszzBUGguru

DIFFguru

DIFFszz
BOTHclean

表 8. SZZ アルゴリズムから得られた結果

表 6. 推定結果に基づくコミット群 (1 手法)
Method

Buggy
Clean

Commit Guru
Buggy
Clean

Project
Log4j
OpenJPA
Camel
HBase

CLEANszz
CLEANguru

る．

BUG tags (commits)

Buggy rate (Weighting)

531 (296)
3156 (1301)
4473 (2171)
4257 (2408)

9.0% (16.2%)
26.8% (64.9%)
7.1% (14.6%)
16.5% (28.9%)

えに，不具合コミット推定手法においても，推定された不具合コミットとそれ以外のコミットには差が生じている

4

結果と思われる．ここでは，Commit Guru，および SZZ アル
ゴリズムの不具合コミットの推定結果，すなわち BUGszz ,SZZ アルゴリズムの実行結果を表 8 に示す．SZZ アル

BUGguru において，それらを比較した際にどのような特徴が得られるかについて考察する．
各メトリクスの傾向 Commit Guru によって測定されたメトリクスは，表 2 において示した通り，そのコミットが不具合コミットとなるリスクの減少要因または増加要因と考えられている．ここでは，CFszz ，CFguru において，Clean とされたコミットの中央値に対する Buggy な
コミットの大小関係を各メトリクスごとにオッズを用いて評価し，各メトリクスがリスクの減少要因，増加要因のどちらとして働く傾向があるかを分析した．
その結果，オッズそのものの値に差はあるものの，ほとんどのメトリクスに対し両手法を通じて同様の働きが得られ，それは Buggy と推定されたコミットに対し期待されるものであった．

ゴリズムは 1 つのコミットに対し複数の BUG タグを付けるため，Buggy rate として BUG タグが付けられたコ
ミット数と，コミットについた BUG タグ数で重み付けしたコミット数の 2 つを算出した．

5

考察

5.1 RQ1: Commit Guru と SZZ アルゴリズムにおいて，それぞれの不具合混入コミット推定の結果にはどのような特徴が存在するか．
不具合コミットはなんらかの形で不具合を混入していないコミットとの間に差が生じていると考えられる．ゆ

42

SEA

ソフトウェア・シンポジウム2018 in 札幌

5.2 RQ2: Commit Guru と SZZ アルゴリズムにおいて，不具合混入コミット推定性能の差はどの程度か．

表 9. 外れ値検出の結果
LOF

methodisolationForest

oneClassSVM

Log4j# of commits
BUGguru
BUGszz
DIFFguru
DIFFszz

29
0.40%
0.18%
0.21%
0.00%

33
0.70%
0.34%
0.37%
0.00%

42
0.64%
0.24%
0.40%
0.00%

OpenJPA# of commits
BUGguru
BUGszz
DIFFguru
DIFFszz

41
0.29%
0.35%
0.062%
0.12%

49
0.56%
0.66%
0.041%
0.14%

50
0.29%
0.43%
0.021%
0.16%

Camel

# of commits
BUGguru
BUGszz
DIFFguru
DIFFszz

271
0.09%
0.07%
0.06%
0.04%

308
0.27%
0.16%
0.14%
0.03%

309
0.28%
0.19%
0.12%
0.03%

HBase

# of commits
BUGguru
BUGszz
DIFFguru
DIFFszz

128
0.27%
0.11%
0.20%
0.03%

148
0.75%
0.38%
0.38%
0.01%

151
0.49%
0.27%
0.24%
0.02%

project

外れ値 先述した通り，不具合コミットはなんらかの形
で不具合を混入していないコミットとの間に差が生じていると考えられるため，1 クラス SVM (One Class SVM), ア
イソレーションフォレスト (Isolation Forest), LOF (Local

Outlier Factor) の 3 手法を用いて外れ値検出を行った．
各コミット群において，検出された外れ値をどの程度含んでいるか，その結果を表 9 に示す．全手法において，
BUGguru の方が BUGszz よりも外れ値と判断されたコミッ
トを含んでいた．
分類カテゴリ 不具合コミットの分類カテゴリの観点から，Commit Guru と SZZ アルゴリズムはどのような傾向があるかを分析した．結果を表 10 に示す．
その結果，BUGszz は’Merge’ に分類されたコミットを含まなかったことに対し，BUGguru はわずかではあるが，’Merge’ に分類されたコミットを含んでいた．また，
BUGszz と BUGguru には Corrective’ に分類されたコミッ
トに対して顕著な差が見られた．DIFFszz において Feature
Addition に分類されたコミットの割合が高くなっている
プロジェクトも存在するが，そもそもの不具合コミット
推定の数量が違うため，ここにおいて比較するには疑念の余地が残る．

43

全コミットは，表 7 のように分類される．不具合コ
ミット推定性能の差を調べるため，ここでは手法間で推定結果が異なるコミット DIFFguru および DIFFszz の比較を行った．また，それとともに Clean と推定されたコミッ
ト群にどれだけ差がないかを分析するため，BOTHcleanに対して，CLEANguru , CLEANszz の比較を行った．
メトリクスの傾向 DIFFguru ，DIFFszz ともに，RQ1 より判断された Buggy と推定されたコミットに期待される傾向に対して，おおよそ沿った傾向を持っていた．また，Buggy と推定されたコミットに期待される傾向により近い傾向をもつコミット群は DIFFszz であった．
有意差 BOTHclean に対して，CLEANguru , CLEANszz それぞれをマン・ホイットニーの U 検定を用いて比較した結果，Log4j, Camel, HBase は CLEANguru , OpenJPA は
CLEANszz の方がより多くのメトリクスにおいて有意差が存在しなかった．
外れ値 全手法において，外れ値と推定されたコミッ
トをより含んでいるのは Log4j, Camel, HBase においては DIFFguru ，OpenJPA においては DIFFszz であった．
また，箱ひげ図を用いて DIFFszz ，DIFFguru における各メトリクスごとの値の分布を評価したとき（図 1），
DIFFguru の方が外れ値が明らかに多く，第一四分位点，第三四分位点の間が大きく開いていることがわかる．Buggyと推定されるコミットは，Clean と推定されるコミットと比較すると何らかの異常な特徴が現われると考えられる．
そのため，比較的まとまりがある DIFFszz は DIFFguru よ
りも Buggy であるコミットが含まれている可能性は低いと考えられる．ここではページ数の関係より，コミット数が少ない Log4j のみを示したが，コミット数が比較的多い他のプロジェクトにおいても同様の結果が得られた．
以上より，推定コミット数の多さにも関わらず，Buggyと推定されたコミットに期待される傾向におおよそ沿っており，外れ値をより含んでいる DIFFszz の方が不具合
コミット推定結果において優れていると考えられる．また，Clean と推定されたコミット間にほとんどのプロジェ
クトにおいて有意差が存在しなかったことから，Cleanと推定されたコミット群はある程度似通っていると考えられる．このため，その中に含んでいる Buggy と推定されるコミット数は少ないと考えられる．以上より，不具合コミットである可能性が高いものをより推定できSEA

ソフトウェア・シンポジウム2018 in 札幌(a) ns(b) nd(c) nf(d) entrophy(e) la(f) sexp(g) rexp(h) age(i) ld(j) lt(k) ndev(l) exp(m) nuc

図 1. SZZ アルゴリズムと CommitGuru の間でバグ推定の結果が異なるものにおけるメトリクス値の分布の比較 (Log4j プロジェクト)

44

SEA

ソフトウェア・シンポジウム2018 in 札幌

表 10. 各コミット群における分類カテゴリの割合
project

commits group# of commits

None

Feature Addition

Corrective

Non Functional

Preventative

Perfective

Merge

Log4j

BUGguru
BUGszz
DIFFguru
DIFFszz

1495
297
1218
20

29.70%
28.62%
29.72%
15.00%

23.08%
25.93%
22.82%
50.00%

34.45%
30.64%
35.06%
15.00%

6.76%
6.73%
6.90%
15.00%

4.62%
7.41%
3.94%
5.00%

1.40%
0.67%
1.56%
0.00%

0.00%
0.00%
0.00%
0.00%

OpneJPA

BUGguru
BUGszz
DIFFguru
DIFFszz

540
1301
216
977

58.89%
62.18%
50.93%
61.51%

15.19%
14.60%
12.96%
13.92%

14.63%
11.84%
23.15%
12.79%

1.11%
4.53%
1.39%
5.73%

7.96%
5.30%
10.65%
5.02%

2.22%
1.54%
0.93%
1.02%

0.00%
0.00%
0.00%
0.00%

Camel

BUGguru
BUGszz
DIFFguru
DIFFszz

6360
2171
4970
781

57.89%
61.72%
57.32%
64.92%

19.47%
20.68%
18.71%
18.05%

16.84%
12.76%
17.85%
11.91%

1.18%
1.01%
1.27%
1.28%

3.57%
2.49%
3.86%
2.43%

1.02%
1.34%
0.95%
1.41%

0.03%
0.00%
0.04%
0.00%

HBase

BUGguru
BUGszz
DIFFguru
DIFFszz

4698
2408
3072
782

56.85%
60.09%
54.33%
56.91%

15.11%
15.49%
15.66%
18.41%

18.69%
15.49%
20.21%
14.83%

1.60%
2.12%
1.43%
2.56%

5.26%
4.44%
5.86%
5.12%

2.38%
2.37%
2.34%
2.17%

0.11%
0.00%
0.16%
0.00%

るのは Commit Guru であると考えられる．しかしながNational Institute of Standards and Technology, 2002.

ら，プロジェクトによって結果が非常に左右されており[2] E. Shihub, “An exploration of challenges limiting
pragmatic software defect prediction,” PhD thesis,
Queen’s University, 2012.

（OpenJPA プロジェクト），表 10 より Commit Guru はMerge と推定されるコミットを Buggy として推定している．このため，Commit Guru の情報を正解データとして利用するとしても，そのデータのみを十二分に信頼するのではなく，様々な手法を用いて検証を行った方が良いと考えられる．

6[3] 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, Proc. of 2nd International workshop on
Mining software repositories, ACM, New York, NY,
USA, 2005.

結言
ソフトウェアの複雑さと重要性が日々増してきている[4] C. Rosen, B. Grawi, and E. Shihab, “Commit guru:
Analytics and risk prediction of software commits,”
Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering, pp.966–969, ESEC/FSE 2015, ACM, New York, NY, USA, 2015.

昨今，ソフトウェアの品質予測は重要な研究テーマであり，その研究は活発化している．その中で，不具合の正解データとして用いられることの多い Commit Guru の不具合混入コミットの情報に対する信頼性は不確かなものであった．そこで，本研究では Commit Guru の不具[5] A. Mockus and L.G. Votta, “Identifying reasonsfor software changes using historic databases,” Proceedings of the International Conference on Software Maintenance (ICSM’00), pp.120–130, ICSM
’00, IEEE Computer Society, Washington, DC, USA,
2000.

合混入コミットの情報における正解データとしての信頼性検証のため，不具合混入コミット推定手法である SZZ
アルゴリズムとの結果の整合性を比較し，考察を行なった．その結果，Commit Guru の不具合混入コミットの情報は不具合の正解データとして可能性を示すものの，その信頼性は十分であるとは言い難い．

[6] Y. Kamei, E. Shihab, B. Adams, A.E. Hassan, A.
Mockus, A. Sinha, and N. Ubayashi, “A large-scale
empirical study of just-in-time quality assurance,”
IEEE Trans. Softw. Eng., vol.39, no.6, pp.757–773,
June 2013.

参考文献[1] G. Tassey, “The economic impacts of inadequate infrastructure for software testing,” Technical report,

45

SEA

ソフトウェア・シンポジウム2018 in 札幌

tory,” IEEE Trans. Software Eng., vol.26, pp.653–661,
2000.

[7] A. Hindle, D.M. German, and R. Holt, “What do largecommits tell us?: A taxonomical study of large commits,” Proceedings of the 2008 International Working
Conference on Mining Software Repositories, pp.99–
108, Proc. of 5th International workshop on Mining
software repositories, ACM, New York, NY, USA,2008.

[15] A.E. Hassan, “Predicting faults using the complexity of code changes,” Proceedings of the 31st International Conference on Software Engineering, pp.78–
88, Proc. of 31st International Conference on Software Engineering, IEEE Computer Society, Washington, DC, USA, 2009.

[8] R. Moser, W. Pedrycz, and G. Succi, “A comparative
analysis of the eﬃciency of change metrics and static
code attributes for defect prediction,” Proceedings ofthe 30th International Conference on Software Engineering, pp.181–190, Proc. of 30th International Conference on Software Engineering, ACM, New York,NY, USA, 2008.

[16] M. D’Ambros, M. Lanza, and R. Robbes, “An extensive comparison of bug prediction approaches,” 2010
7th IEEE Working Conference on Mining Software
Repositories (MSR 2010), pp.31–41, 2010.

[9] N. Nagappan and T. Ball, “Use of relative code churnmeasures to predict system defect density,” Proceedings of the 27th International Conference on Software Engineering, pp.284–292, ACM, New York, NY,
USA, 2005.

[17] P.J. Guo, T. Zimmermann, N. Nagappan, and B. Murphy, “Characterizing and predicting which bugs get
fixed: An empirical study of microsoft windows,” Proceedings of the 32th International Conference on Software Engineering (ICSE), pp.495–504, ACM, May
2010.

[10] A.G. Koru, D. Zhang, K.E. Emam, and H. Liu, “An investigation into the functional form of the size-defectrelationship for software modules,” IEEE Transactions
on Software Engineering, vol.35, pp.293–304, 2009.

[18] R. Purushothaman and D.E. Perry, “Toward understanding the rhetoric of small source code changes,”
IEEE Transactions on Software Engineering, vol.31,
pp.511–526, 2005.

[11] A. Mockus and D.M. Weiss, “Predicting risk of software changes,” Bell Labs Technical Journal, vol.5,
no.2, pp.169–180, aug 2002.
[12] N. Nagappan, T. Ball, and A. Zeller, “Mining metrics to predict component failures,” Proceedings of the
28th International Conference on Software Engineering, pp.452–461, Proc. of 28th International Conference on Software Engineering, ACM, New York, NY,
USA, 2006.
[13] S. Matsumoto, Y. Kamei, A. Monden, K.-i. Matsumoto, and M. Nakamura, “An analysis of developer metrics for fault prediction,” Proceedings of the
6th International Conference on Predictive Models in
Software Engineering, pp.18:1–18:9, PROMISE ’10,
ACM, New York, NY, USA, 2010.
[14] T.L. Graves, A.F. Karr, J.S. Marron, and H.P. Siy,
“Predicting fault incidence using software change his-

46

SEA