社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

メトリクス値の変遷に基づくソフトウェアの特性分析手法の提案と実装
村尾 憲治†

肥後 芳樹†

井上 克郎†† 大阪大学大学院情報科学研究科 〒 560-8531 大阪府豊中市待兼山町 1 番 3 号
E-mail: †{k-murao,higo,inoue}@ist.osaka-u.ac.jp
あらまし

本稿では，ソースコードにおけるソフトウェアメトリクスの値の変遷に基づき，ソフトウェアの特性を分析する手法の提案を行う．バージョン管理システムのリポジトリに蓄積されたソフトウェアの開発履歴に関する情報を用いてメトリクス値の変遷を分析することにより，注目すべきモジュールやメトリクス，変更など，ソフトウェアの様々な特性に関する情報を得ることができる．本手法によって得られる情報は，効率的なソフトウェアの開発や保守に役立つと期待される．実際に本手法を実装したツールをオープンソースソフトウェアに対して適用し，期待した通り有益なソフトウェアの特性が分析できることを確認した．
キーワード

バージョン管理システム，ソフトウェアメトリクス

Software Characteristic Analysis Based on History of Software Metrics
Kenji MURAO† , Yoshiki HIGO† , and Katsuro INOUE†† Graduate School of Information Science and Technology, Osaka University
1-3, Machikaneyama–cho, Toyonaka–shi, Osaka, 560–8351 Japan
E-mail: †{k-murao,higo,inoue}@ist.osaka-u.ac.jp
Abstract This paper proposes a method for software characteristic analysis based on software metrics transitions. Software
metrics transitions can be measured from development historical information archived by version control system, and they
can be used for identifying peculiar modules, metrics, and changes of the software system. Identification of those elements isuseful for efficient software development and maintenance. We have implemented a software tool based on the proposal, andconducted case studies with open source software systems. The results of the case studies show that the proposal is helpful.
Key words Version Control System, Software Metrics

1. ま え が き
ソフトウェアに関する深い知識は，その開発や保守を行うにあたり有益である．例えば，問題が発生しやすいモジュールを

管理システムのリポジトリというアーカイブに蓄積されている．
このリポジトリに蓄積された開発履歴を閲覧することによって，ソフトウェアの開発過程についてより深い理解が得られることが知られている [3]．

知っていればそのモジュールに労力を注ぐことで効率的な開発

一方，ソフトウェアのソースコードそのものを基に知識を提や保守が行え，またソフトウェアがどういった過程を経て開発供する研究がある．これに関しては，CK メトリクス [4] に代表されてきたかを知っていれば今後の開発の見通しも立てやすい．

されるソフトウェアメトリクスが有名であろう．特に，CK メ

しかし，開発者がこのような知識を新たに得ようと思い，自力

トリクスは多くの研究において問題の発生しやすいモジュール

で対象ソフトウェアについて調査を行えば，ソフトウェアの規を特定するのに有効であると示されている [5]．

模に応じて膨大な時間を費やすことになる．そこで，開発者に

本稿ではバージョン管理システムとソフトウェアメトリクス

ソフトウェアに関する知識を提供するため，数多くの研究がなに基づいてソフトウェアの特性を分析する手法を提案する．具されている．

体的には，バージョン管理システムに蓄積された開発履歴情報

ソフトウェアの開発履歴を基に知識を提供する研究がある．

を用いてソフトウェアメトリクスの値の変遷を求めることによ多くのものは CVS [1] や Subversion [2] などのバージョン管理

り，変動度というソフトウェアの特性を分析する指標を導出すシステムを情報源としている．バージョン管理システムは本来る．この手法により様々な観点からソフトウェアの傾向や性質

ソフトウェアの開発を効率よく管理するために用いられる．管を知ることができる．

理されるソフトウェアの開発履歴に関する情報は，バージョン

以降，2. 節では本稿における用語と変動度の計測手段につい—1—

て述べ，3. 節では提案手法の説明を行う．4. 節では手法を実装

刻の集合を表す．ただし，z は変更時刻の総数である．添字のしたツールについて触れ，5. 節では手法を実装したツールを用

値が小さいほど古い変更の時刻を表し，ct1 を最初の変更時刻，

いて行った適用事例について述べる．最後にまとめと今後の課

ctz を最新の変更時刻とする．

題を 6. 節に記す．

vmdi ,mtj ,ctk ： 変更時刻 ctk におけるモジュール mdi のメトリ

2. 準

備

本節では，本稿における用語の意味や手法で用いる変動度の計測手段を定義する．

2. 1 用語

クス mtj の値を表す．ただし，変更時刻 ctk においてモジュー
ル mdi が存在しない場合，vmdi ,mtj ,ctk = null とする．

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

2. 1. 1 スナップショット

をメトリクス値の不確かさと捉えることによって，エントロ

スナップショットとは，ある時点でのソフトウェアの状態にピーを変動度の指標として用いることができる．エントロピー

おけるソースコードの集合である．ソフトウェアのソースコー

H は対象モジュールの各メトリクスに対して導出される．メドに対して何らかの変更が加わると，その時点で今までのス

トリクス値 vmdi ,mtj ,ct1 , vmdi ,mtj ,ct2 , · · · , vmdi ,mtj ,ctz におい

ナップショットとは異なる新しいスナップショットが生まれる．

て値が null でないものの数を z ′ とし，z ′ 個のそれぞれの値

スナップショットは CVS [1] や Subversion [2] といったバージョ

を v1′ , v2′ , · · · , vz′ ′ と表すことにする．さらにその z ′ 個の値のン管理システムのリポジトリに蓄積される情報，すなわち変更

うち，異なる値の種類数を z ′′ とする．z ′′ 種類の値をそれぞれの日時や変更を行った開発者名，変更の前後における差分など

v1′′ , v2′′ , · · · , vz′′′′ とおくと，エントロピー Hmdi ,mtj の計算式はの情報から得ることができる．

以下のようになる．
′′

2. 1. 2 変 動 度
Hmdi ,mtj = −変動度とは，それぞれのスナップショットを通じたメトリク
ス値の変動の激しさを表す指標である．変動度の計測手段については 2. 2 節および 2. 3 節で述べる．

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

pl =

発者の人数，用いるプログラミング言語，コーディング規約や開発者の士気の高さなどもその言葉の意味に含めることができ

equal(vl′′ , vk′ )

k=1

z ′′
(

らかの傾向や性質である．様々なものがソフトウェアの特性として挙げられる．例えば，ソースコードの規模や開発日数，開pl log2 pl

l=1

2. 1. 3 ソフトウェアの特性
ソフトウェアの特性とは，対象のソフトウェアに存在する何zXequal(α, β) =

′′
(1 <
=l<
=z )

1

(α = β のとき)

0(α =| β のとき)z ′′ = z ′ となるとき，エントロピーは Hmdi ,mtj = − log2 z1′

る．もちろん，最新の状態のソースコードのメトリクス値もソと な り 最 大 で あ る ．z ′′ = 1 と な る と き ，エ ン ト ロ ピ ー はフトウェアの特性として挙げることができる．本手法は，特にHmdi ,mtj = − log2 1 = 0 となり最小である．

以下の項目を明らかにすることを目的としている．

•

メトリクス値の安定しないモジュール•

対象ソフトウェアにおいて値の安定しないメトリクス•

各変更がソフトウェアに与えた影響の程度•

各開発者がソフトウェアに与えた影響の程度

これらの特性を知ることは，ソフトウェア理解や開発管理，開発者の評価など幅広い分野で役立つと期待される [6] [7]．

2. 2 変動度の計測手段
対象データのばらつきを表す指標として散布度，不確かさを表す指標としてエントロピー，変化を表す指標として距離など

2. 2. 2 正規化エントロピー
エントロピー H の最大値は変更が行われた回数に依存するため，異なるソフトウェア間では正しく値を比較することが難しい．この問題を解決するため，新たに正規化エントロピーを定義する．正規化エントロピー H ′ はエントロピー H と同様に対象モジュールの各メトリクスに対して値が得られる．上記のエントロピー H で用いた設定に準じると，正規化エントロ′
ピー Hmdの計算式は以下のようになる．
i ,mtj′Hmd=
i ,mtjが挙げられる．これらは主として数学や統計学で用いられる指Hmdi ,mtj− log2 z1′標である．本手法では，これらのばらつきや不確かさ，変化のエントロピー Hmdi ,mtj をその最大値で除算するため，正規化

指標を変動度の計測手段として用いる．以降，これらの指標を′
エントロピーは必ず 0 <= Hmdi ,mtj <= 1 となる．

用いた変動度の計測手段について説明する．説明にあたり，以2. 2. 3 四分位偏差下の設定を用いる．

統計分野で用いられる散布度は，データのばらつきの程度をM D = {md1 , md2 , · · · , mdx }： 対象ソフトウェアにおける表現するものである [9]．メトリクス値の変動の激しさをメトリ

モジュールの集合を表す．ただし，x は総モジュール数である．

クス値のばらつきの程度と捉えることで，変動度の指標として

M T = {mt1 , mt2 , · · · , mty }： 用いるメトリクスの集合を表

散布度を用いることができる．一般にメトリクス値が正規分布にす．ただし，y は用いるメトリクスの数である．

従うとは言えないので，散布度としては四分位偏差を用いる．四CT = {ct1 , ct2 , · · · , ctz }： 対象ソフトウェアにおける変更時

分位偏差 Q は対象モジュールの各メトリクスに対して値が得ら—2—

れる．メトリクス値 vmdi ,mtj ,ct1 , vmdi ,mtj ,ct2 , · · · , vmdi ,mtj ,ctz

⃗vmdi ,ctk = [vmdi ,mt1 ,ctk , vmdi ,mt2 ,ctk , · · · , vmdi ,mty ,ctk ]Tにおける第 1 四分位数を q1 ，第 3 四分位数を q3 とすると，四ハミング距離 DH と同様に，計算式が成り立つの条件は ∀k((1 <分位偏差 Qmdi ,mtj の計算式は以下のようになる．

q3 − q1
Qmdi ,mtj =2k <| null) ∧ (vmdi ,mtj ,ctk =| null)) と= z) ∧ (vmdi ,mtj ,ctk−1 =なる．この条件が成り立たない場合は，DEmdi ,ctk = null とする．

2. 2. 4 四分位分散係数

2. 2. 7 マハラノビス距離

四分位偏差 Q の値は絶対値であり，用いるメトリクスのス

ユークリッド距離を用いた変動度は，メトリクス間に相関がケール差に影響されてしまう．このため，異なるメトリクス間でなく，かつスケール差もないと見なした状態での値となっていは正しく値を比較することが難しい．そこでこの問題への対処る．しかし，実際にはメトリクス間に相関やスケール差の存在として四分位分散係数を用いる．四分位分散係数 Q′ は四分位偏することが多い．例えば，異なる定義によりモジュールの結合

差 Q と同様に対象モジュールの各メトリクスに対して値が得ら度を求める 2 つのメトリクスがあった場合，目的を同じくする

れる．メトリクス値 vmdi ,mtj ,ct1 , vmdi ,mtj ,ct2 , · · · , vmdi ,mtj ,ctz

この 2 つのメトリクスには強い正の相関関係があると考えられにおける中位数を m とすると，四分位分散係数 Q′mdi ,mtj の計算式は以下のようになる．

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

Qmdi ,mtj
Q′mdi ,mtj =mスの数を表すメトリクスなどは変更によって変化する絶対値があまり大きくなることは少ないと考えられる．そこで，相関や

ただし m = 0 の場合は，Qmdi ,mtj = 0 ならば Q′mdi ,mtj = 0，
| 0 ならば Q′mdi ,mtj = ∞ とする．
Qmdi ,mtj =スケール差を考慮した値を求めることのできるマハラノビス距離も利用する．マハラノビス距離は多変量解析など統計学でよ

2. 2. 5 ハミング距離

く用いられる距離の一種であり，情報分野においてもクラスタ

情報理論 [8] においてハミング距離は，等しい文字数を持つリング手法などにしばしば利用される [11] [12] [13]．ハミング

2 つの文字列の中で対応する位置にある異なった文字の個数を距離 DH やユークリッド距離 DE と同様に，マハラノビス距意味する．文字列をメトリクス値の列に置き換えることで，ハ離 DM は対象モジュールの連続する 2 つの変更間について導ミング距離を 2 つの変更間における変動の激しさを示す指標と出される．また，マハラノビス距離 DM はその計測に対象のして用いることができる．ハミング距離 DH は対象モジュー

ソフトウェア全体でのメトリクスの共分散行列 Σ を必要とす

ルの連続する 2 つの変更間について導出される．ハミング距離る．この共分散行列は y × y の正方行列である．ユークリッド

DHmdi ,ctk は以下の計算式で表される．

距離 DE における設定を用いて，要素に null を含まないベクyトル ⃗vmdi ,ctk の個数を n (1 <=n<
= (x × z)) とする．この n 個

DHmdi ,ctk =X

different(vmdi ,mtj ,ctk−1 , vmdi ,mtj ,ctk )j=1

different(α, β) =(のベクトルをそれぞれ ⃗v1′ , ⃗v2′ , · · · , ⃗vn′ とおくと，メトリクスの共分散行列 Σ は以下の式で表すことができる．

1
0

(α =
| β のとき)nΣ=(α = β のとき)

1X ′(⃗vl − µ⃗ ) · (⃗vl′ − µ
⃗ )T
n
l=1

この計算式が示すように，ハミング距離 DHmdi ,ctk は変更時

n

刻 ctk−1 と ctk 間において値が変化したメトリクスの数を表µ⃗=している．したがって計算式が成り立つ条件は ∀k((1 < k <
=

1X ′
⃗vl
n
l=1

z) ∧ (vmdi ,mtj ,ctk−1 =| null) ∧ (vmdi ,mtj ,ctk =| null)) となる．

この共分散行列 Σ を用いて，マハラノビス距離 DMmdi ,ctk は

この条件が成り立たない場合は，DHmdi ,ctk = null とする．

以下の計算式で表される．

2. 2. 6 ユークリッド距離

DMmdi ,ctk =ハミング距離 DH は変更前と変更後でメトリクス値が変化しq⃗TV

mdi ,ctk Σ−1 V⃗md ,ctik

たかどうかのみを考慮しており，値がどの程度変化したかとい計算式が示すように，マハラノビス距離はメトリクスの共分散行

うことは反映されない．ハミング距離 DH に対し，ユークリッ

列 Σ の逆行列を計算に用いる．したがって，共分散行列 Σ が特

ド距離 DE はメトリクス値の変化の大きさを反映した変動度を異行列（非正則行列）となる場合はマハラノビス距離の計測自体表す．変動度としてのユークリッド距離 DE は，用いるメトリを行わないものとする．また，ハミング距離 DH やユークリッド

クスの数 y 次元ユークリッド空間上の距離を表す [10]．ハミン

距離 DE と同様に，上記の計算式が成り立つの条件は ∀k((1 <グ距離 DH と同様に，ユークリッド距離 DE は対象モジューk <| null) ∧ (vmdi ,mtj ,ctk =| null)) と= z) ∧ (vmdi ,mtj ,ctk−1 =ルの連続する 2 つの変更間について導出される．ユークリッドなる．この条件が成り立たない場合は，DMmdi ,ctk = null と距離 DEmdi ,ctk は以下の計算式で表される．
q⃗md ,ct⃗T
DEmd ,ct = V
·V

する．

i

k

mdi ,ctki

2. 3 変動度の計測手段の拡張

k

2. 2 節で述べた各計測手段によって導かれる変動度は，2 つ⃗md ,ct = ⃗vmd ,ct − ⃗vmd ,ct
V
i
i
i
k−1
k
k

の次元を持つ．例えばエントロピー H はモジュールとメトリ

—3—

ct1

バージョン管理システム

リポジトリ

過去のスナップショットの
取得

ct1

変更時刻

ct 2

ct z

L

F1

F1,ver.1

F2

F2,ver .1

F3

L
スナップショット

変更時刻

[

] [
L

ct z

vmd1 ,mt1 ,ct1 L vmd1 ,mt y ,ct1
vmd1 ,mt1 ,ct z L vmd1 ,mt y ,ct z
それぞれのモジュールに
L
O
O
M
M
M
M
対する各メトリクスの値
vmd x ,mt1 ,ct1 L vmd x ,mt y ,ct1
vmd x ,mt1 ,ct z L vmd x ,mt y ,ct z

]

ct3

ct4

F1,ver.2

変更時刻

F1,ver.3

F2,ver .2
F3,ver .2

F3,ver.1

F4

スナップショットに対するメトリクス値の
計測

ct1

ct 2

F4,ver .1

F4,ver .2

F4,ver.3

ソース
ファイル

図 2 ソフトウェアの変更履歴の例

変動度の計測ぞれのメトリクスについて 1 つの値を持つ．この変動度を用モジュールの変動度 FMD

メトリクスの変動度 FMT

変更の変動度 FMT

いれば，対象のソフトウェアにおいてどのメトリクスの値が変化しやすく，どのメトリクスの値が変化しにくいか，というソ

変動度を用いたソフトウェアの特性分析

フトウェアの特性を知ることができる．メトリクスの変動度

F M T の計算式は以下のようになる．
L

F M T (ω)mtj =xXωmdi ,mtj

i=1
ユーザ

グラフによる変動度の可視化など

ただし，ω は H, H ′ , Q, Q′ のいずれかである．

2. 3. 3 変更の変動度
図1

提案手法の概要

変更の変動度（fluctuation of change time, F CT ）は，それぞれの変更時刻について 1 つの値を持つものである．この変動度

クスの 2 つの次元を持ち，ハミング距離 DH はモジュールと変更時刻の 2 つの次元を持つ．これらの変動度を用いて，以下に述べるモジュールの変動度，メトリクスの変動度，変更の変動度を導出できる．

を用いれば，対象のソフトウェアにおいていつどのような変更が行われたのか，というソフトウェアの特性を知ることができる．この特性はソフトウェアの開発履歴を理解するのに有効である．変更の変動度 F CT の計算式は以下のようになる．

2. 3. 1 モジュールの変動度
モジュールの変動度（fluctuation of module, F M D）は，それF CT (ω)ctk =ぞれのモジュールについて 1 つの値を持つ．この変動度を用いれば，対象のソフトウェアにおいて注目すべきモジュールを知ることができる．変動度の大きいモジュールはメトリクス値がxXωmdi ,ctk

i=1

ただし，ω は DH, DE, DM のいずれかである．

変化しやすいので，他のモジュールに影響を与えやすい，ある3. 提 案 手 法

いは逆に影響を受けやすい，または頻繁に変更が行われている

提案手法の概要を図 1 に示す．前提となるのは，対象のソフと考えられる．この変動度の大きさに応じて力を割くモジュー

トウェアの開発にバージョン管理システムが利用されているこルを決定すれば，効率的な開発や保守が期待できる．モジューとである．本手法は次の手順から構成される．

ルの変動度 F M D の計算式は以下のようになる．
8 y
P
>
>
ωmdi ,mtj (ω = H, H ′ , Q′ )<j=1
F M D(ω)mdi =zP>>ωmdi ,ctk (ω = DH, DE, DM ):手順 1：過去のスナップショットの取得

k=1

手順 2：スナップショットに対するメトリクス値の計測
手順 3：変動度の計測
手順 4：変動度を用いたソフトウェアの特性分析
以下では，これらの手順についてそれぞれ説明する．

ただし，ω は H, H ′ , Q′ , DH, DE, DM のいずれかである．四3. 1 過去のスナップショットの取得

分位偏差 Q についても同様の計算は可能だが，用いるメトリク

バージョン管理システムに保存された分析対象のソフトウェ

ス間にスケール差が存在する場合，四分位偏差 Q を上記の計

アの変更履歴情報を利用し，過去全てのソースコードのスナッ

算式に当てはめるのは適切でないため，四分位偏差 Q は用い

プショットを取得する．

ない．

図 2 はソフトウェアの変更履歴の例を示したものである．図2. 3. 2 メトリクスの変動度

2 では，このソフトウェアに存在する 4 つのソースファイル

メトリクスの変動度（fluctuation of metric, F M T ）は，それF1 , F2 , F3 , F4 が縦軸に配置されている．横軸は時刻を表し，時—4—

刻 ct1 , ct2 , ct3 , ct4 において変更が行われている．また，F1,ver.1
や F4,ver.3 などはソースファイルとそのバージョンを示してい

5. 適 用 事 例る．図 2 に示すようなソフトウェアの変更履歴があったとき，

本節では，4. 節で述べたツールを用い，実存するオープン

それぞれの変更時刻におけるスナップショットは表 1 の通りに

ソースソフトウェアに手法を適用した事例について述べる．複なる．

数のソフトウェアに対し手法を適用したが，紙面の都合上，こ3. 2 スナップショットに対するメトリクス値の計測

こでは FreeMind [14] というオープンソースソフトウェアに対全ての変更時に対応するスナップショットを対象にメトリク

して手法を適用した結果の内，モジュールの変動度についてのス値の計測を行う．これにより，任意のモジュールに対するメ

み述べることにする．対象ソフトウェア FreeMind についてのトリクス値の変遷が得られる．

概要を表 2 に示す．提案手法を実装したツールの実行時間は用いるメトリクスはモジュールの単位や目的に合わせて選ぶ必要がある．例えば，モジュールの単位をクラスとしたいので

CPU 1.86GHz，メモリ 2GB の Windows マシン上でおよそ 28分であった．

あればクラスを対象としたメトリクスを，ファイルとしたいの

2. 3. 1 節で述べたように，モジュールの変動度が高いクラス

であればファイルを対象としたメトリクスを用いる．あるいは，は一般に問題が発生しやすい状態にあると考えられる．した結合度に注目したいのであれば結合度を表すメトリクスを，凝がって，モジュールの変動度が高いクラスに注意して開発を進

集度に注目したいのであれば凝集度を表すメトリクスを用いめれば，効率的な開発が行えると期待できる．このことを確かる．後述の適用事例では，モジュールの単位をクラスとし，主めるため，変動度の高いモジュールとバグとの関係を調べる実に CK メトリクス [4] を用いる．

験を行った．実験は次に示す手順で実行した．以降では，バグ

3. 3 変動度の計測を修正するための変更をバグ修正変更，バグ修正変更の対象とメトリクス値の変遷を用い，2. 3 節で述べたモジュールの変なったファイルの延べ数をバグ修正数と呼ぶ．

動度，メトリクスの変動度，変更の変動度をそれぞれ計測する．

（ 1 ） FreeMind のスナップショットを前半と後半に分割する．

3. 4 変動度を用いたソフトウェアの特性分析（ 2 ） 前半のスナップショットを用いてモジュールの変動度

3. 3 節で求めた変動度を用いてソフトウェアの特性分析を行を計測する．このとき，内部クラスは除く．

う．ソフトウェアの特性分析は，変動度の値やそれをグラフな（ 3 ） CVS リポジトリに含まれる開発者による変更時のメッどの形式で可視化したものを用いてユーザが実行する．例えば，セージログを用いて，後半のスナップショットにおけるバグ修モジュールの変動度からどのモジュールのメトリクス値が変化

正変更を特定し，各スナップショットにおけるバグ修正数を計しやすいのか判断したり，メトリクスの変動度から対象のソフ測する．

トウェアにおいてどのメトリクスの値が変化しやすいのか把握（ 4 ） 変動度の高いクラスのランキングによる，バグ修正数したりする．

に対する被覆率を求める．

4. 実

FreeMind の開発においては，バグ修正変更の際のメッセージ装

ログには，その先頭に「Bug fix: 」と記載する習慣がある．し3. 節で述べた提案手法の手順 1〜3 を自動で行うツールを実たがってバグ修正変更を特定する際には，開発者による変更時装した．このツールは現在のところ，Java で開発されたソフトのメッセージログに「bug」と「fix」の文字列（大文字小文字

ウェアを対象とし，バージョン管理システム CVS のリポジトは区別しない）が含まれているかどうかを判定する．このようリを用いてスナップショットを取得し，CK メトリクス [4] を計にして特定されたバグ修正数は 36 となった．

測し，それぞれの変動度を求めるものとなっている．CK メト

モジュールの変動度が高いクラスのランキングによる，バグ

リクスは対象とするモジュールの粒度がクラスであるので，本修正数に対する被覆率を図 3 に示す．図 3 を見れば，どのモ

ツールにおいてもクラスをモジュールの単位として扱う．

ジュールの変動度の指標を用いても，ランキングの上位 20%

本ツールは CVS のリポジトリを入力とし，2. 3 節で述べたモジュールの変動度，メトリクスの変動度，変更の変動度をそれぞれ CSV 形式のファイルとして出力する．ユーザは，この出力された変動度をグラフなどの形で可視化し，ソフトウェアの特性を分析する．

表 1 図 2 に対応するスナップショット
変更時刻

スナップショット

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 )表 2 FreeMind の概要
ソフトウェア名

FreeMind

種別

ダイアグラム生成ツール

開発言語

Java

開発者数

12

総スナップショット数 z

225

最初の変更時刻 ct1

2000/08/01 19:56:09

最後の変更時刻 ctz

2008/01/13 20:55:35

ct1 におけるソースファイル数67

ctz におけるソースファイル数

221

ct1 におけるソースコードの総行数

3,882

ctz におけるソースコードの総行数

39,350—5—

バグ修正被覆率（％）
100

6. ま と め90

本稿では，バージョン管理システムのリポジトリに蓄積され80た開発履歴情報を用いてメトリクス値の変遷を求め，モジュー
70

ルの変動度，メトリクスの変動度，変更の変動度を導出するこ60とによりソフトウェアの特性を分析する手法を提案した．さら50に，提案手法を実装し，実存するソフトウェアに対して手法を40
FMD(H)FMD(H')FMD(Q')FMD(DH)
FMD(DE)FMD(DM)3020
10

適用したところ，変動度から得られるソフトウェアの特性の有効性が確認された．
今後の課題として重要なのは，手法を実装したツールの拡張である．現状では制限が多く，以下にあげるような機能が望ま

0
0

10

20

30

40

50

60

70

80
90
100
ランキング被覆率（％）

れる．

•

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

Subversion など，他のバージョン管理システムへの対応

バグ修正被覆率（％）
100•

他の様々なソフトウェアメトリクスへの対応

90•

変動度を可視化する作業の自動化

80

謝辞 本研究は一部，文部科学省「次世代 IT 基盤構築のた70めの研究開発」（研究開発領域名：ソフトウェア構築状況の可視60化技術の開発普及）の委託に基づいて行われた．

図3モジュールの変動度のランキングによるバグ修正数の被覆率

文

50
FMD（最大）FMD（平均）
FMD（最小）メトリクス（最大）メトリクス（平均）
メトリクス（最小）

40
30
20
10
0
0

10

図4

20

30

40

50

60

70

80
90
100
ランキング被覆率（％）

モジュールの変動度と CK メトリクスの比較（図 3 の点線で示された箇所）におよそ 97% 〜100% もの後のバグ修正変更が含まれていることが分かる．

CK メトリクスはバグの予測に有効であるとの報告がなされている [5]．そこで，このモジュールの変動度の比較対象として，FreeMind の前半のスナップショットにおける最後のスナッ
プショットに対する CK メトリクスの値をそれぞれ求め，各 CK
メトリクスの値のランキングによるバグ修正数の被覆率を求める．図 3 で示した被覆率の平均値，最大値，および最小値と，各 CK メトリクスの値のランキングによるバグ修正数の被覆率の平均値，最大値，および最小値を示したグラフを図 4 に示す．
図 4 から，次のことが言える．

•

モジュールの変動度のどの指標を用いても，後のバグ修正の予測に極めて有効であり，また指標毎の差異もそれほど大きくはない．

•

メトリクス値を用いた後のバグ修正の予測は有効であるが，用いるメトリクスによる差異が極めて大きい．

•

後のバグ修正を最も有効に予測できるメトリクスを用いた場合でも，モジュールの変動度を用いた後のバグ修正の予測の方が一般に有効である．
以上のことより，ソフトウェアの開発においてモジュールの変動度が高いモジュールに力を割くことは，効率的な開発の実現に繋がると大きく期待できる．

献[1] CVS. http://ximbiot.com/cvs/wiki/.
[2] Subversion. http://subversion.tigris.org/.
[3] Peter H. Feiler. Configuration Management Models in Commercial
Environments. CMU/SEI-91-TR-7 ESD-9-TR-7, 1991.
[4] Shyam R. Chidamber and Chris F. Kemerer. A Metrics Suite for Object Oriented Design. In IEEE Transactions on Software Engineering, Vol.20, No.6, pp.476-493, 1994.
[5] Victor R. Basili, Lionel C. Briand, and Walcelio L. Melo. A Validation of Object-Oriented Design Metrics as Quality Indicators. In
IEEE Transactions on Software Engineering, Vol.22, No.10, pp.751761, 1996.
[6] Ahmed E. Hassan and Richard C. Holt. Studying the Chaos of CodeDevelopment. In Proceedings of 10th Working Conference on Reverse Engineering (WCRE ’03), pp.123-133, 2003.
[7] Nachiappan Nagappan, Thomas Ball, and Andreas Zeller. Mining
Metrics to Predict Component Failures. In Proceeding of the 28th International Conference on Software Engineering (ICSE ’06), pp.452461, 2006.
[8] Claud E. Shannon. The Mathematical Theory of Communication. In
Bell System Technical Journal, Vol.27, pp.379-423 & 623-656, Jul &Oct 1948.
[9] 宮川 公男. 基本統計学. 有斐閣, 1999.
[10] 中村 幸四郎, 寺阪 英孝, 伊東 俊太郎, 池田 美恵 (翻訳). ユークリッ
ド原論. 共立出版, 1996.
[11] Francoise Fessant, Patrice Aknin, Latifa Oukhellou, and Sophie
Midenet. Comparison of Supervised Self-Organizing Maps Using
Euclidian or Mahalanobis Distance in Classification Context. In
Proceedings of the 6th International Work-Conference on Artificial
and Natural Neural Networks (IWANN ’01): Connectionist Models of Neurons, Learning Processes and Artificial Intelligence-PartI, pp.637-644, 2001.
[12] Camilo P. Tenorio, Francisco de A. T. de Carvalho, and Julio T. Pimentel. A Partitioning Fuzzy Clustering Algorithm for Symbolic Interval Data based on Adaptive Mahalanobis Distances. In Proceedings of the 7th International Conference on Hybrid Intelligent Systems (HIS ’07), pp.174-179, 2007.
[13] 村上 正憲, 松島 正直, 山田 博章. Mahalanobis’ 特徴平面による識別. 電子情報通信学会総合大会講演論文集, Vol.1995 情報・シス
テム, No.2. p.213, 1995.
[14] FreeMind. http://freemind.sourceforge.net/wiki/.

—6—