論文

ソフトウェアメトリックス値の変遷に基づいた注力すべきモジュールを特定する手法の提案
村尾 憲治†

肥後 芳樹†

井上 克郎†

Identifying Problematic Modules Based on Metrics Transitions
Kenji MURAO† , Yoshiki HIGO† , and Katsuro INOUE†

あらまし ソフトウェアの大規模化及び開発期間の短縮化により，ソフトウェアのすべてのモジュールに同様に力を注ぐことが難しくなってきている．特定のモジュールに力を注ぐ場合は，力を注ぐべきモジュールを特定しなければらないが，手動で行うと対象ソフトウェアの規模に応じて膨大な時間と労力を費やすことになる．そのため，開発者に負担をかけずに力を注ぐべきモジュールを特定することが求められる．本論文では，ソフト
ウェアメトリックス値の変遷を用いてソフトウェアの開発履歴を定量化することにより，力を注ぐべきモジュールを特定する手法の提案を行う．実際に提案手法を複数のオープンソースソフトウェアに対して適用した結果，将来問題の発生しやすいモジュールを，既存手法に比べて高い精度で特定することに成功した．
キーワード

バージョン管理システム，ソフトウェアメトリックス，バグ予測，品質評価

1. ま え が きアの開発を効率良く管理するために用いられる．管理

ソフトウェアの大規模化，及び開発期間の短縮化に

ジョン管理システムのリポジトリというアーカイブにより，ソフトウェアのすべてのモジュールに同様の力蓄積されている．このリポジトリに蓄積された開発履を注ぐことは現実的ではなくなってきている．例えば，歴を閲覧することによって，ソフトウェアの開発過程問題が発生しやすいモジュールを知っていれば，そのについてより深い理解が得られることが知られていモジュールに力を注ぐことで効率的な開発や保守が行る [3]．

されるソフトウェアの開発履歴に関する情報は，バーえ，またソフトウェアがどのような過程を経て開発さ一方，ソフトウェアのソースコードそのものをもとれてきたのかを知っていれば，今後の開発の見通しもに知識を提供する研究も行われている．これに関して

立てやすい．開発者がこのような知識を得るには，対は，CK メトリックス [4] に代表されるソフトウェアメ

象ソフトウェアについての調査が必要となるが，これトリックスが有名である．特に，CK メトリックスはを手動で行う場合は対象とするソフトウェアの規模に多くの研究において問題の発生しやすいモジュールを応じて膨大な時間と労力を費やすことになる．そこで，特定するのに有効であると示されている [5], [6]．

開発者にソフトウェアに関する知識を提供するための本論文では，メトリックス値の恒常性という，開発及び保守過程においてどの程度ソフトウェアメトリッ

数多くの研究がなされている．
ソフトウェアの開発履歴をもとに知識を提供する

クスの値が安定しているかを表す概念を用いて，力を研究が既に行われている．多くのものは CVS [1] や注ぐべきモジュールを特定する手法を提案する．提案

Subversion [2] などのバージョン管理システムを情報手法は，各モジュールにおけるメトリックス値の恒常源としている．バージョン管理システムは，ソフトウェ

性を定量化しており，自動的に力を注ぐべきモジュールを特定することができる．また，提案手法を，将来†

大阪大学大学院情報科学研究科，豊中市

バグ修正が多く行われるモジュールの特定に用いた結Graduate School of Information Science and Technology,

果についても記載する．

Osaka University, 1–3 Machikaneyama–cho, Toyonaka–shi,
560–8351 Japan

電子情報通信学会論文誌 D Vol. J91–D

以降，2. では研究の動機について触れ，3. では本

c （社）電子情報通信学会 2008
No. 12 pp. 2915–2925 

2915

電子情報通信学会論文誌 2008/12 Vol. J91–D No. 12

論文における用語とメトリックス値の恒常性の計測手段について述べ，4. では提案手法の手順を説明する．

5. では手法を実装したツールについて触れ，6. では
そのツールを用いて行った適用実験について述べる．
更に，7. で関連する研究を挙げ，最後にまとめと今後の課題を 8. に記す．

2. 動

機

3. 準

備

ここでは，提案手法で用いる用語と，提案手法を読み進めるにあたり必要な知識を紹介する．

3. 1 提案手法で用いる用語
3. 1. 1 メトリックス値の恒常性
メトリックス値の恒常性とは，開発及び保守過程において，ソフトウェアメトリックスの値がどの程度安

ソフトウェアのモジュールの性質や状態を表す指標

定しているのかを表す概念である．
「恒常性が高い」ととしてソフトウェアメトリックスがある．これまでに，いうのはメトリックス値が安定しており，「恒常性が低ソフトウェアの成果物を計測するための様々なメト

い」というのはメトリックス値が激しく変化している

リックスが提案されており，それらはいずれも最新のことを意味する．

成果物（あるいは，過去のある時点における成果物）

3. 1. 2 スナップショットを計測する．つまり，既存のメトリックスは，ある時スナップショットとは，ある時点においてソフトウェ

点における成果物の性質や状態を表しているが，それアを構成しているソースコードの集合である．ソフ

らがどのような過程を経て開発されたのかは表していトウェアのソースコードに対して何らかの変更が加わない．筆者らは，成果物の現在の状態を表す情報と同ると，新しいスナップショットが生成される．スナッ

様にそれらの進化の過程を表す情報が，今後の開発及プショットは，CVS [1] や Subversion [2] などのバー

び保守作業に有益であると考えている．

ジョン管理システムのリポジトリに蓄積される情報，

ソフトウェアのあるモジュールについて，複雑度メ

すなわち変更の日時や変更を行った開発者名，変更のトリックスを計測した場合について考える．最新の成前後における差分などを用いて生成することができる．

果物から複雑度メトリックスを計測した場合，最新の3. 2 メトリックス値の恒常性を計測する方法

成果物がどの程度複雑であるかを把握することができ

対象データのばらつきを表す指標として散布度，不る．しかし，そのモジュールが，開発当初より一定し確かさを表す指標としてエントロピー，変化を表す指て複雑な状態にあるのか，開発が進むに従って複雑度標として距離などが挙げられる．これらは主として数が増しているのか，若しくは，変更が加わるたびに複学や統計学で用いられる指標である．提案手法では，雑度が増減しているのかは不明である．一般に複雑度

これらの指標を用いてメトリックス値の恒常性を計測が高いと，そのモジュールの理解や変更に大きな労力する．以降，これらの指標を用いた恒常性の計測手を要するといわれているが，一定して複雑な状態が維段について説明する．説明にあたり，以下の設定を用持されているのであれば，そのモジュールには大きないる．

変更が加わっておらず，開発や保守のボトルネックになっているとは限らないといえよう．複雑度が単調に

M D = {md1 , md2 , · · · , mdα }: 対象ソフトウェアにおけるモジュールの集合を表す．ただし，α は総モ増加している場合は，改版のたびに新しい機能が加えジュール数である．

られているのかもしれない．複雑度が増減している場

M T = {mt1 , mt2 , · · · , mtβ }: 用いるメトリックスの合は，改版のたびに機能が削除・追加されたり，構造集合を表す．ただし，β はメトリックスの総数である．
CT = {ct1 , ct2 , · · · , ctγ }: 対象ソフトウェアにおける変更時刻の集合を表す．ただし，γ は変更発生回数が変更されたりしていることを表しており，何か問題があるのかもしれない．
このように，モジュールのある時点における性質やである．添字の値が小さいほど古い変更時刻を表す，

状態だけでなく，その進化の過程を表現することによつまり ct1 は最初の変更時刻，ctγ は最新の変更時刻

り，これまでは得ることができなかった新たな情報をを表す．

得ることができるのではないかと考え，本提案手法を

v(i, j, k): 変更時刻 k におけるモジュール i のメト
リックス j の値を表す．ただし，変更時刻 k においてモジュール i が存在しない場合はメトリックス値は，提案する．

v(i, j, k) = null とする．
2916

論文／ソフトウェアメトリックス値の変遷に基づいた注力すべきモジュールを特定する手法の提案

3. 2. 1 エントロピー
Shannon の提唱した情報理論 [7] に依れば，エント
ロピーとは不確かさを表す指標である．メトリックス

エントロピー H(i, j) をその最大値で除算するため，正規化エントロピーは必ず 0 ≤ H  (i, j) ≤ 1 となる．

3. 2. 3 四分位偏差

値の恒常性をメトリックス値の不確かさととらえるこ

統計分野で用いられる散布度は，データのばらつきとにより，エントロピーを恒常性の指標として用いるの程度を表現するものである [8]．メトリックス値の恒ことができる．

常性をメトリックス値のばらつきの程度ととらえるこ

エ ン ト ロ ピ ー H は 対 象 モ ジュー ル の 各 メ トとで，恒常性の指標として散布度を用いることができ

リック ス か ら 導 出 さ れ る ．モ ジュー ル i に おる．一般にメトリックス値が正規分布に従うとはいえ

け る メ ト リック ス j の メ ト リック ス 値 の 集 合 ，{v(i, j, 1), v(i, j, 2), · · · , v(i, j, γ)} に お い て ，値 がnull でないものの数を γ  とし，γ  個のそれぞれの値を v1 , v2 , · · · , vγ  と表すことにする．更にその γ  個ないので，標準偏差を散布度として使うのは不適である．本論文では，代替として四分位偏差を用いる．
四 分 位 偏 差 Q は ，対 象 モ ジュー ル の 各 メ ト リ
ック ス に 対 し て 値 が 得 ら れ る ．モ ジュー ル i にの値のうち，異なる値の種類数を γ  とする．γ  種類

お け る メ ト リック ス j の メ ト リック ス 値 の 集 合 ，の値をそれぞれ v1 , v2 , · · · , vγ とおくと，エントロ{v(i, j, 1), v(i, j, 2), · · · , v(i, j, γ)} における第 1 四分
位数を q1 ，第 3 四分位数を q3 とすると，四分位偏差ピー H(i, j) の以下の式で定義される．

Q(i, j) は以下の式で定義される．



H(i, j) = −γ

pl log2 pl

(1)

l=1

ここで pl は値 vl の出現頻度を表し，次の式で定義さ
れる．

pl =

k=1

q3 − q1
2(3)

3. 2. 4 四分位分散係数
四分位偏差 Q の値は絶対値であり，用いるメトリッ
クスのスケール差に影響されてしまう．このため，異γQ(i, j) =equal(vl , vk )γ なるメトリックス間では正しく値を比較することが難(1 ≤ l ≤ γ )しい．この問題への対処として四分位分散係数を用いる．
四分位分散係数 Q は四分位偏差 Q と同様に対象モ

ただし，

equal(s, t) =10ジュールの各メトリックスから導出される．モジュー(s = t)(s = t)ル i におけるメトリックス j のメトリックス値の集合，

γ  = γ  ，つまりすべてのメトリックス値が異なる場
合，エントロピーは H(i, j) = − log2 γ1 となり最大である．γ  = 1，つまりすべてのメトリックス値が同じ場合，エントロピーは H(i, j) = − log 2 1 = 0 とな
り最小である．

3. 2. 2 正規化エントロピー
エントロピー H の最大値は変更が行われた回数に依存するため，異なるソフトウェア間では正しく値を比較することが難しい．この問題を解決するため，新たに正規化エントロピーを定義する．

{v(i, j, 1), v(i, j, 2), · · · , v(i, j, γ)} における中位数をm とすると，四分位分散係数 Q (i, j) は以下の式で定義される．

Q (i, j) =Q(i, j)m(4)

ただし m = 0 の場合は，



Q (i, j) =0∞

(Q(i, j) = 0)
(Q(i, j) = 0)

(5)

となる．

正規化エントロピー H  は，エントロピー H と同3. 2. 5 ハミング距離
情報理論 [7] においてハミング距離は，等しい文字

様に対象モジュールの各メトリックスから導出される．

数をもつ二つの文字列の中で対応する位置にある異上記のエントロピー H で用いた設定に準じると，正なった文字の個数を意味する．文字列をメトリックス

規化エントロピー H  (i, j) の以下の式で定義される．

H(i, j)H  (i, j) =− log2 γ1(2)値の列に置き換えることで，ハミング距離を二つの変更間におけるメトリックス値の恒常性を示す指標として用いることができる．
2917

電子情報通信学会論文誌 2008/12 Vol. J91–D No. 12

ハミング距離 DH は対象モジュールの連続する二際にはメトリックス間に相関やスケール差の存在する

つの変更から導出される．ハミング距離 DH(i, k) はことが多い．例えば，異なる定義によりモジュールの

以下の式で定義される．

結合度を求める二つのメトリックスがあった場合，目的を同じくするこの二つのメトリックスには強い正のβDH(i, k) =diﬀ(v(i, j, k − 1), v(i, j, k)) (6)j=1

相関関係があると考えられる．また，ソースコードの行数を表すメトリックスなどは変更によって絶対値が大きく変化することも珍しくないが，サブクラスの数

ただし，


diﬀ(s, t) =10を表すメトリックスなどは変更によって変化する絶対(s = t)(s = t))値があまり大きくなることは少ないと考えられる．そこで，相関やスケール差を考慮した値を求めることのこの式が示すように，ハミング距離 DH(i, k) は変できるマハラノビス距離も利用する．マハラノビス距

更 時 刻 ctk−1 と ctk 間に お い て 値 が 変 化 し た メ ト

離は多変量解析など統計学でよく用いられる距離の一リックスの数を表している．したがってこの式が成種であり，情報分野においてもクラスタリング手法なり立つ条件は ∀k((1 < k ≤ γ) ∧ (v(i, j, k − 1) =null) ∧ (v(i, j, k) = null)) となる．この条件が成り立たない場合は，DH(i, k) = null とする．
3. 2. 6 ユークリッド距離
ハミング距離 DH は変更前と変更後でメトリック

どにしばしば利用される [10], [11]．

ス値が変化したかどうかのみを考慮しており，値がど

メトリックスの共分散行列 Σ を必要とする．この共分の程度変化したかということは反映されない．それにの恒常性としてのユークリッド距離 DE は，用いるメ散行列は β × β の正方行列である．ユークリッド距離
DE における設定を用いて，要素に null を含まないベクトル v (i, k) の個数を n (1 ≤ n ≤ (α × γ)) とする．この n 個のベクトルをそれぞれ v1 , v2 , · · · , vn とトリックスの数，β 次元ユークリッド空間上の距離をおくと，メトリックスの共分散行列 Σ は以下の式で表表す [9]．ハミング距離 DH と同様に，ユークリッド

すことができる．

対して，ユークリッド距離 DE はメトリックス値の変化の大きさを反映した恒常性を表す．メトリックス値

距離 DE は対象モジュールの連続する二つの変更から導出される．
ユークリッド距離 DE(i, k) は以下の 式で定義される．

する二つの変更から導出される．また，マハラノビス
距離 DM はその計測に対象のソフトウェア全体での1 (vl − μ) · (vl − 
μ)T
n
n

Σ=

l=1

ただし，

1 
vl
n
n


DE(i, k) =ハミング距離 DH やユークリッド距離 DE と同様に，マハラノビス距離 DM は対象モジュールの連続 (i, k)
 T (i, k) · V
V

(7)

ただし，

 (i, k) = v (i, k) − v (i, k − 1),Vv (i, k) = [v(i, 1, k), v(i, 2, k), · · · , v(i, β, k)]T
ハミング距離 DH と同様に，この式が成り立つの条件は∀k((1 < k ≤ γ) ∧ (v(i, j, k − 1) = null) ∧ (v(i, j, k) =null)) と な る ．こ の 条 件 が 成 り 立 た な い 場 合 は ，DE(i, k) = null とする．
3. 2. 7 マハラノビス距離

μ
=

l=1

こ の 共 分 散 行 列 Σ を 用 い て ，マ ハ ラ ノ ビ ス 距 離DM (i, k) は以下の式で定義される．
 (i, k)T Σ−1 V
 (i, k)DM (i, k) = V(8)

この式が示すように，マハラノビス距離はメトリック
スの共分散行列 Σ の逆行列を計算に用いる．したがって，共分散行列 Σ が特異行列（非正則行列）となる場
合はマハラノビス距離の計測自体を行わないものとする．また，ハミング距離 DH やユークリッド距離 DE

は，メトリックス間に相関がなく，かつスケール差もと同様に，この式が成り立つの条件は ∀k((1 < k ≤γ) ∧ (v(i, j, k − 1) = null) ∧ (v(i, j, k) = null)) とな
る．この条件が成り立たない場合は，DM (i, k) = null

ないとみなした状態での値となっている．しかし，実とする．

ユークリッド距離を用いたメトリックス値の恒常性

2918

論文／ソフトウェアメトリックス値の変遷に基づいた注力すべきモジュールを特定する手法の提案

4. メトリックス値の恒常性を算出する手順
以下の手順により，メトリックス値の恒常性を計測

計測手順 2：メトリックス値の計測
手順 1 で取得したすべてのスナップショットを対象にメトリックス値の計測を行う．

する．なお，恒常性を計測するためには，対象ソフト用いるメトリックスはモジュールの単位や目的に合ウェアがバージョン管理システムを利用して開発されわせて選ぶ必要がある．例えば，モジュールの単位をていなければならない．

クラスとしたいのであればクラスを対象としたメト

計測手順 1：過去のスナップショットの取得

リックスを，ファイルとしたいのであればファイルを計測手順 2：メトリックス値の計測対象としたメトリックスを用いる．あるいは，結合度計測手順 3：メトリックス値の恒常性の算出に注目したいのであれば結合度を表すメトリックスを，

以下では，各手順について詳しく説明する．

凝集度に注目したいのであれば凝集度を表すメトリッ

計測手順 1：過去のスナップショットの取得

クスを用いる．後述の適用事例では，モジュールの単バージョン管理システムに保存された分析対象のソ

位をクラスとし，主に CK メトリックス [4] を用いてフトウェアの変更履歴情報を利用し，過去すべての変
更時刻におけるスナップショットを取得する．

いる．
計測手順 3：メトリックス値の恒常性の算出

図 1 は，ソフトウェアの変更履歴の例を示したもの

手順 2 で計測したメトリックスに対して，3. 2 で紹である．この図では，ソフトウェアを構成する四つの介した各計測手段を適用することにより，各モジュー

ソースファイル F1 ，F2 ，F3 ，F4 が縦軸に配置されてルにおけるメトリックス値の恒常性を求める．3. 2 でいる．横軸は時刻を表し，時刻 ct1 ，ct2 ，ct3 ，ct4 に紹介した計測手段は，モジュールとメトリックス，若おいて変更が行われている．また，F1,ver.1 や F4,ver.3

しくはモジュールと変更時刻の二つの次元をもってなどはソースファイルとそのバージョンを示している．

いる．提案手法では，これらの値をモジュールではな

図 1 に示すようなソフトウェアの変更履歴があったとい次元に対して和をとったものを，そのモジュールのき，各変更時刻におけるスナップショットは表 1 のよメトリックス値の恒常性として定義する．モジュール

うになる．

mdi の恒常性 ω(i) は，以下の式で表される．
⎧ β

⎪
⎪
ω(i, j) (ω = H, H  , Q, Q )
⎨
j=1
(9)
ω(i) =γ⎪⎪⎩ω(i, k) (ω = DH, DE, DM )k=1

ただし，ω は H ，H  ，Q，Q ，DH ，DE ，DM のいずれかである．また，四分位偏差はメトリックス値の絶対値をもとに算出されるため，用いるメトリック
ス間にスケール差が存在する場合は，上記の式を用いてモジュールの恒常性を求めることは適切ではない．

5. 実

装

4. で述べた計測手順を自動で行うツールを実装した．実装したツールの特徴は以下のとおりである．
図 1 ソフトウェアの変更履歴の例
Fig. 1 Example of a software development history.

表 1 図 1 に対応するスナップショット
Table 1 Snapshots for Fig. 1.
変更時刻
スナップショット
ct1{F1,ver.1 , F2,ver.1 , F3,ver.1 }ct2{F1,ver.2 , F2,ver.2 , F3,ver.1 , F4,ver.1 }ct3{F1,ver.2 , F3,ver.2 , F4,ver.2 }ct4{F1,ver.3 , F3,ver.2 , F4,ver.3 }•••対象は Java 言語で記述されたソフトウェア．

対応しているバージョン管理システムは CVS．
CK メトリックスをもとにして，恒常性を計測する．CK メトリックスは対象とするモジュールがクラスであるので，実装したツールでもクラスをモジュールの単位として扱う．

•

実装したツールは，CVS のリポジトリを入力とし，モジュールの恒常性を CSV 形式のファイルと2919

電子情報通信学会論文誌 2008/12 Vol. J91–D No. 12

Table 2表 2 対象ソフトウェアの概要
Overview of the target software systems.

ソフトウェア名
FreeMind
JHotDraw
HelpSetMaker
種別
ダイアグラム生成ツール
ドローツールドキュメント生成ツール
開発言語
Java
Java
Java
開発者数
12
24
2
総スナップショット数 γ
104
196
260
最初の変更時刻 ct1
2000/08/01 19:56:09 2000/10/12 14:57:10
2003/10/20 13:05:47
最後の変更時刻 ctγ
2004/02/06 06:04:25 2005/04/25 22:35:57
2006/01/07 15:08:41
ct1 におけるソースファイル数
67
144
14
ctγ におけるソースファイル数
80
484
36
ct1 におけるソースコードの総行数
3,882
12,781797
ctγ におけるソースコードの総行数
14,07660,4309,167

して出力する．

トリックスはバグの予測に有効であるとの報告がなさ

6. 適 用 実 験

れており [5], [6]，CK メトリックスによる予測とメト

ここでは，5. で述べたツールを用いて行った実験

案手法の有効性が示される．

について述べる．

6. 1 実 験 目 的

リックス値の恒常性による予測を比較することで，提6. 4 実 験 方 法
実験は，次に示す手順で行った．なお，これ以降，実験の目的は，提案手法を用いることにより，力をバグを修正するための変更をバグ修正変更，バグ修正

注ぐべきモジュールを特定できるかを調査することで変更の対象となったファイルの延べ数をバグ修正数とある．2. で述べたように，メトリックス値の恒常性が呼ぶ．また，この実験では，内部クラスは測定の対象

低いクラスでは，そうでないクラスに比べて問題が発外である．

生しやすいと考えられる．この実験では，力を注ぐべ実験手順 1：対象ソフトウェアのスナップショット群

きモジュールを「将来多数のバグが発生するモジューを，学習用データと調査用データに分割する．分割はル」として，そのようなモジュールを特定することが変更回数に基づいて行われ，古いスナップショット群

できるかを調査した．
この実験は，特に以下の点において調査することにが学習用データに，新しいスナップショット群が調査用データに分類される．

より，提案手法の汎用性を示すことに重点をおく．

実験手順 2：学習用データのスナップショット群から，（ 1 ） 単一のソフトウェアだけでなく，複数のソフ

メトリックスを計測し，恒常性を算出する．

トウェアに対しても力を注ぐべきモジュールを特定す

実験手順 3：調査用データのスナップショット群から，ることができるか．

バグ修正変更を特定する．この実験では，バグ修正（ 2 ） 開発の特定の期間だけでなく，様々な期間に変更の特定は，CVS リポジトリに記録されているロ

適用しても力を注ぐべきモジュールを特定することがグメッセージをもとに行った．例えば FreeMind の場

できるか．

合，バグ修正変更の際のメッセージログには，文頭に以降，項目 1 を調査するための実験を「実験 1」と呼「Bug ﬁx:」と記載する習慣がある．この実験では，ロび，項目 2 を調査するための実験を「実験 2」と呼ぶ．

グメッセージに「bug」と「ﬁx」の両文字列（大文字6. 2 実 験 対 象

小文字は区別しない）が含まれているかどうかでバグ

実 験 対 象 は ，FreeMind [12]，JHotDraw [13]，修正変更かどうかを判断した．

HelpSetMaker [14] の三つのオープンソースソフト
ウェアである．これらのソフトウェアの概要を表 2 に実験手順 4：学習用データから得たメトリックス値の示す．

わせる．具体的には，対象クラスをメトリックス値の6. 3 利用したメトリックス

恒常性と調査用データから得たバグ修正変更を突き合
恒常性の降順に並べ，上位 x%のクラスにおけるバグ

この実験で用いたソフトウェアメトリックスは，CK

修正の被覆率（y%）を調査する．同様に，対象クラス

メトリックス（RFC，CBO，LCOM，NOC，DIT）

を学習用データの最後のスナップショットにおけるメとクラスの行数（LOC）の計六つである．特に CK メ

トリックス値の降順に並べ，上位 x%のクラスにおけ2920

論文／ソフトウェアメトリックス値の変遷に基づいた注力すべきモジュールを特定する手法の提案

図 3 異なる分割点における学習メトリックスと恒常性のバグ予測比較結果（対象は FreeMind）
Fig. 3 Comparison result between metrics constancy
and raw metrics for diﬀerent application timings for FreeMind.

ト群とした．実装したツールを用いて，4. で述べた計測手順 1〜3 を実行するのに要した時間は，FreeMindが約 28 分，JHotDraw は約 40 分，HelpSetMaker は
約 18 分であった（注 1）．
図 2 は，各対象ソフトウェアにおける実験手順 4 の結果を示している．この図では，恒常性のグラフが実線で表され，メトリックスのグラフが点線で表されて
図 2 複数ソフトウェアにおける学習メトリックスと恒常性のバグ予測比較結果（学習用データ 1/3・調査用
データ 2/3 での分割）
Fig. 2 Comparison result between metrics constancy
and raw metrics for multiple software systems.
(The leaning data is anterior one third, andthe investigating data is posterior two third)

いる．例えば，FreeMind の場合（図 2 (a)）では，どの恒常性の指標を用いても，上位 20%のクラスにおいて，調査用データのバグ修正変更のうちのおよそ 97〜

100%が行われていることが分かる．一方，メトリックスの場合は，上位 20%のクラスにおいて，およそ 22〜

89% のバグ修正変更が行われている．この図より，するバグ修正の被覆率（y%）も調査する．

6. 5 結果

実験 1 では，学習用データは前 1/3 のスナップショッ（注 1）：実験は，CPU：1.86 GHz，メモリ：2 GByte を搭載した Windows マシン上で行った．なお，対象ソフトウェアの CVS リポジトリ
は，あらかじめ実験マシンのローカルストレージに複製した上でツールを実行した．

2921

電子情報通信学会論文誌 2008/12 Vol. J91–D No. 12

べての対象ソフトウェアにおいて，ソフトウェアメト

Subramanyam らは，産業界で開発された八つのソフ

リックスそのものを用いるよりもメトリックス値の恒トウェアに対して CK メトリックスの有効性を調査し常性を用いた方が，力を注ぐべきモジュールを精度良た [6]．その結果，Basili らと同様，CK メトリックス

く特定できていることが分かる．

とソフトウェアの欠陥に大きな関係があることを見出

実験 2 では，前 1/2，1/3，1/4 をそれぞれ学習用
データとして用いた．図 3 は，FreeMind に対する実した．同時に，ソフトウェアによってメトリックスの有効性が異なることも示した．

験手順 4 の結果を表している（注 2）．図 3 と図 2 (a) よNagappan らはソフトウェアのバグを予測する最もり，適用時期にあまり依存することなく，力を注ぐべ

良いメトリックスがソフトウェアによって異なること

きモジュールを精度良く特定できていることが分かる．

を発見し，対象ソフトウェアにおける過去のバグに関一方，ソフトウェアメトリックスは，適用時期が早い

する情報からソフトウェアメトリックスによってバグほど（古いスナップショットのメトリックス値を用いを予測する回帰モデルを構築した [15]．彼らはいくつるほど），精度が落ちているのが分かる．

かの大規模な商用ソフトウェアに手法を適用し，その実験 1 と実験 2 より，以下に示す結論を導くことが有効性を評価している．

できる．

本提案手法とこれらの手法との違いは，情報源が異•なることである．本提案手法ではバージョン管理シス

すべての恒常性がバグ予測に有効であり，指標間の差異もそれほど大きくなかった．

•

テムを情報源としているが，上記の手法の情報源はソフトウェアメトリックスは，メトリックス間

ソースコードである．ただし，Nagappan らの手法はで予測の差が大きかった．つまりメトリックスにもバ

ソースコードに加えてバグに関する情報が管理されてグ修正に有効なものがあった．

いる必要がある．そのため，正確にバグに関する情報

この実験より，メトリックス値が激しく変化していを管理しているソフトウェアが少ないのが問題となっるクラス（メトリックス値の恒常性が低いクラス）は，ている．適用可能なソフトウェアが多いという点では，そうでないクラスに比べて将来多くのバグが発生してソースコードのみを必要とする CK メトリックスが最いるといえる．また，メトリックス値の恒常性を用いも優れているといえる．しかし，近年バージョン管理ることにより，そのようなクラスを自動的に特定できシステムを用いているソフトウェア開発は非常に多い

ることを示した．

ため，本提案手法が適用できるソフトウェアも多い．

7. 関 連 研 究
本研究の関連としてソフトウェアメトリックスを用いた研究とバージョン管理システムを利用した研究をいくつか紹介する．

また，本論文は，本提案手法は CK メトリックスよりも有効なバグ修正の予測が可能であることを実験で確かめた．

7. 2 バージョン管理システムを用いた研究
近年では，バージョン管理システムなどの開発履歴

7. 1 ソフトウェアメトリックスを用いた研究に関する情報を利用してソフトウェアの特性を把握す

メトリックス値の恒常性と同様に，ソフトウェアメる試みも増えている．

トリックスそのも力を注ぐべきモジュールの特定に用いられている．
本論文の実験において用いた CK メトリックスは，Williams らは Apache ウェブサーバにおける過去のバグに関する情報を調べ，メソッドの戻り値をチェッ
クすることがバグの発生を予測するのに有効であると

Chidamber ら [4] によって生み出されたオブジェク

考えた [16]．そこで，メソッドの戻り値チェックに基ト指向プログラムを対象としたメトリックスである．

づいた将来のバグの発生を予測する手法について，最Basili らは，八つの学生チームによるオブジェクト指新のソースコードだけを用いる手法と，それに加え向プログラミング言語 C++を用いて開発された情報てバージョン管理システムから得られる履歴情報も利管理システムを対象とし，CK メトリックスと他のメ用する手法の比較を行った．その結果，最新のソース

トリックスとの比較実験を行った [5]．その実験結果

コードだけでなくバージョン管理システムの情報を併から，他のメトリックスに比べ，CK メトリックスはより多くのソフトウェアの欠陥を，よりソフトウェア
開発の早期において予測できることを示した．また，
2922（注 2）：前 1/3 を学習データとして用いた場合のグラフは図 2 で示しているので，図 3 からは省いている．

論文／ソフトウェアメトリックス値の変遷に基づいた注力すべきモジュールを特定する手法の提案

用した手法の方がより優れた予測を導き出すことがで手法と同じくバージョン管理システムを情報源としてき，バージョン管理システムに含まれる情報を有用性いるが，本提案手法ではモジュールに関する情報が得を示した．

られるのに比べ，彼らの手法で得られる情報は対象のHassan らは情報理論 [7] によるエントロピーをソフ

ソフトウェア全体についてのものである点が異なる．

トウェアの開発過程に当てはめ，ソフトウェアの開発

また，Śliwerski らによる手法と Ostrand らによる手履歴に含まれる情報量の計測を試みた [17]．彼らはこ法はバグに関する情報が管理されているソフトウェアの情報によりソフトウェアの開発過程の監視が行えるを対象とするため，手法を適用できるソフトウェアがとし，特にプロジェクトマネージャにとって有益な手少ないのが問題となっている．花川による手法と Vasa

法であることを述べた．

らによる手法は，本提案手法と同じ情報源を用い，得Śliwerski らはバージョン管理システムと過去のバ

られるソフトウェアの特性の対象も本提案手法に近い．

グに関する情報とを関連づけ，バグを発生させる原因

しかし，花川による手法ではソフトウェアの特性の対となった変更の特定を行っている [18]．このような変象となるメトリックスは結合度のみであり，Vasa らに更が頻繁に行われるモジュールは，今後もバグを発生よる手法でも対象となるメトリックスは利用数，被利させやすいと考えられる．開発者このモジュールを提用数という一種の結合度のみである．本提案手法では，示することで，将来の開発や保守を効率的に行うこと

適用事例においては CK メトリックスを中心としたメが望めるとしている．

トリックスを用いたが，手法としてはソースコードを

Ostrand らはバージョン管理システムと過去のバグ対象とする定量的なメトリックスであればどんなメトに関する情報から負の二項回帰モデルを構築し，対象リックスであっても用いることができる．また，本提ソフトウェアの次のリリース時にバグを発生するファ案手法ではメトリックス値の恒常性を数値として出力

イルの予測を試みた [19]．彼らはいくつかの適用事例する点も既存の研究には見られない特徴である．

から負の二項回帰モデルに基づく予測結果が単にコードの行数に基づく予測よりも有効であることを示し，
この手法によってテスト時に注意すべきソースファイ
ルの提示が可能であるとした．

8. む す び
本論文では，バージョン管理システムのリポジト
リに蓄積された開発管理情報から，力を注ぐべきモ

花川はソフトウェアメトリックスを用いたモジュー

ジュールを特定する手法を提案した．提案手法は，ソル間の結合度と論理的なモジュール間の結合，すなわ

フトウェアメトリックスを用いているが，メトリック

ち同時に変更が施されるモジュール群に着目し，新たス値そのものではなく，メトリックスの値がどのような複雑度の指標を定義した [20]．また，ソフトウェアに変化してきたかに着目することにより，力を注ぐべの開発過程におけるこの複雑度の変化を可視化し，ソきモジュールの特定を行う．

フトウェアの複雑さの変化を視覚的に把握するツールを作成している．

更に提案手法を実装し，複数のオープンソースソフ
トウェアに対して，将来バグを多数発生させるモジュー

Vasa らはソフトウェアの開発過程におけるリリー

ルの特定を行う実験を行った．その結果，CK メトリッ

ス間でのモジュールごとの利用数，被利用数の変化をクスに比べ，より高い精度でそのようなモジュールの調査している [21]．彼らは複数のオープンソースソフ

特定を行えることが確認された．

トウェアに対して実験を行い，利用数，被利用数の変提案手法を応用することにより，バグ修正の実効的化から得られるソフトウェアの特性の取得を試みた．

な予測が行えると期待される．例えば，以下のようなその結果，ほとんどのモジュールは開発が経過するに応用が考えられる．

つれ利用数，被利用数の変化が見られなくなってくる•

プロジェクトの途中でモジュールの変動度やメが，利用数，被利用数が非常に多い一部のモジュール

トリックス値の時系列値の計測結果からバグを多数含

は開発が経過しても利用数，被利用数が変化し続ける，

むモジュールを検出する．

などといったソフトウェアの特性を分析した．

Willams らの研究は，本提案手法との立場が近いが，•プロジェクト自体の失敗の可能性を分析し，ソフトウェア開発のリスク管理を行う．

彼らの手法は関数の戻り値に関するバグに特化してい今後の課題として重要なのは，手法を実装したツーるという点で異なる．Hassan らによる手法は本提案

ルの拡張である．現状では制限が多く，以下に挙げる
2923

電子情報通信学会論文誌 2008/12 Vol. J91–D No. 12

ような機能が望まれる．

•

[15]

tional Conference on Software Engineering, pp.452–の対応•

N. Nagappan, T. Ball, and A. Zeller, “Mining metrics
to predict component failures,” Proc. 28th Interna-

C++や C# など，他のプログラミング言語へ

461, May 2006.

Subversion など，他のバージョン管理システム[16]

C.C. Williams and J.K. Hollingsworth, “Automaticへの対応

mining of source code repositories to improve bug••

ﬁnding techniques,” IEEE Trans. Softw. Eng., vol.31,

他の様々なソフトウェアメトリックスへの対応
他のバグ修正の予測手法との比較

no.6, pp.466–480, June 2005.
[17]

謝辞 本研究は一部，文部科学省「次世代 IT 基盤

code development,” Proc. 10th Working Conference
on Reverse Engineering, pp.123–133, Nov. 2003.

構築のための研究開発」（研究開発領域名：ソフトウェ
ア構築状況の可視化技術の開発普及）の委託に基づい[18]

Śliweski,T.

Zimmermann,

and

A.

Zeller,pean Software Engineering Conference, pp.107–110,

文

Sept. 2005.

献[1]“CVS,” http://ximbiot.com/cvs/wiki/[2]“Subversion,” http://subversion.tigris.org/[3]

P.H. Feiler,[19]

Technical Report

CMU/SEI-91-TR-7 ESD-9-TR-7, Software Engineer-software systems,” IEEE Trans. Softw. Eng., vol.31,
no.4, pp.340–355, April 2005.
[20]

S. Chidamber and C. Kemerer, “A metric suite forvol.25, no.5, pp.476–493, June 1994.
V.R. Basili, L.C. Briand, and W.L. Melo, “A validation of object-oriented design metrics as quality
indicators,” IEEE Trans. Softw. Eng., vol.22, no.10,

花川典子，“論理結合とモジュール結合による複雑度を用いたソフトウェア進化の可視化，” 第 14 回ソフトウェア工学の基礎ワークショップ，pp.65–74, Nov. 2007.

ing Institute, Carnegie Mellon University, 1991.
object-oriented design,” IEEE Trans. Softw. Eng.,

T.J. Ostrand, E.J. Weyuker, and R.M. Bell, “Predicting the location and number of faults in large“Conﬁguration management models

in commercial environments,”

[5]

J.

“HATARI: Raising risk awareness,” Proc. 10th Euro-て行われた．

[4]

A.E. Hassan and R.C. Holt, “Studying the chaos of[21]

R. Vesa, J.G. Schneider, and O. Nierstrasz, “Theinevitable stability of software change,” Proc. 23rdIEEE International Conference on Software Maintenance, pp.4–13, Oct. 2007.

（平成 20 年 4 月 2 日受付，7 月 6 日再受付）

pp.751–761, Oct. 1996.
[6]

R. Subramanyam and M.S. Krishnan, “Empiricalanalysis of CK metrics for object-oriented design
complexity: Implications for software defects,” IEEE

村尾

Trans. Softw. Eng., vol.29, no.4, pp.297–310, April
2003.
[7]

平 18 阪大・基礎工・情報卒．平 20 同大

C.E. Shannon, “The mathematical theory of com-

大学院博士前期課程了．現在，大阪府総務

munication,” Bell Syst. Tech. J., vol.27, pp.379–423,

部に勤務．在学時，ソフトウェア保守支援
及びリポジトリマイニングに関する研究に623–656, July 1948.
[9]

宮川公男，基本統計学，有斐閣，1999.
中村幸四郎，寺阪英孝，伊東俊太郎，池田美恵，ユーク[10]

F. Fessant, P. Aknin, L. Oukhellou, and S. Midenet,

[8]

憲治

従事．

リッド原論，共立出版，1996.

肥後“Comparison of supervised self-organizing maps us-

平 14 阪大・基礎工・情報中退．平 18 同

context,” Proc. 6th International Work-Conference

大大学院博士後期課程了．日本学術振興会

on Artiﬁcial and Natural Neural Networks, pp.637–

特別研究員を経て，平 19 阪大・情報・コンピュータサイエンス・助教．博士（情報644, June 2001.
[11]

芳樹 （正員）ing euclidian or mahalanobis distance in classiﬁcation

C.P. Tenorio, F. de A. T. de Carvalho, and J.T.

科学）．コードクローン分析・リファクタ
リングに関する研究に従事．情報処理学会，

Pimentel, “A partitioning fuzzy clustering algorithm
for symbolic interval data based on adaptive mahalanobis distances,” Proc. 7th International Conference on Hybrid Intelligent Systems, pp.174–179,
Sept. 2007.
[12]“FreeMind,” http://freemind.sourceforge.net/wiki/[13]“JHotDraw,” http://www.jhotdraw.org/[14]“HelpSetMaker,” http://www.cantamen.com/
helpsetmaker.php

2924IEEE 各会員．

論文／ソフトウェアメトリックス値の変遷に基づいた注力すべきモジュールを特定する手法の提案

井上克郎 （正員）昭 54 阪大・基礎工・情報卒．昭 59 同大
大学院博士課程了．同年同大・基礎工・情報・助手．昭 59〜61 ハワイ大マノア校・情報工学科・助教授．平元阪大・基礎工・情報・講師．平 3 同学科・助教授．平 7 同学科・教授．博士（工学）．平 14 阪大・情報・コンピュータサイエンス・教授．ソフトウェア工学の研究に従事．情報処理学会，日本ソフトウェア科学会，IEEE，ACM
各会員．

2925