保守性・再利用性が低いファイルの予測：産業データを用い
た研究
津田 直彦
1,a)高田 正樹
1鷲崎 弘宜
1,b)深澤 良彰
1,c)杉村 俊輔
2保田 裕一朗
2二上 将直
2概要：再利用性の高い資産を蓄積するためには，保守性・再利用性の低いソースコードファイル（Unacceptable Files:FS）とそうでないファイル(Acceptable Files:Fs)を見分け，早い段階でUFsを発見し修正する必要 がある．人手レビューには時間がかかるため，自動でUFsを検出するための研究がこれまでされてきた． しかし，言語や開発形態の違いなどからソフトウェアプロジェクト毎にメトリクス傾向は異なることが多 い．そのため，GQM法などを用いてあるプロジェクトに対して自動評価式を作成しても，他のプロジェク トに対しては適切でない評価をしてしまう場合がある．そこで，我々はGQMモデルを共通のドメインで 再利用しつつ，メトリクスの値を解釈する評価式のパラメタ（閾値）変更によってプロジェクトに合わせ た自動評価をする仕組みを考えた．そして，可変部分である閾値を経験的に決めるのでなく，実際の人手 レビュー結果に基づいて決めるための枠組みを考案した．本稿では建機メーカーの実プロダクト（C++） を用いて，提案する枠組みの有効性を実験的に確認した．その結果，評価する項目によってはファイルの 自動評価を人手レビューに十分近似させることが可能とわかった（カッパ係数0.7以上の一致度）．
1.
はじめに
新規開発のコストの高さから，産業でのソフトウェア開 発ではしばしば既存のシステムを再利用する．そのため， ソースコードなどの成果物は保守性・再利用性が高められ ているのが望ましい．コードの品質特性を評価する手法と しては目視によるコードレビューが一般的であるが，コー ドメトリクスを用いた自動評価も研究されている．図1の ように，人間が行うレビューは時間がかかり大規模なシス テムに対してはコストが高く，一方で自動評価は高速に結 果が得られる．しかし，ソフトウェアプロジェクトには通 常プロジェクト特有のルールや実践，特徴があり，その違 いがメトリクスの分布に影響する[1]．もしその違いを考 慮せずに自動評価をすれば，開発者の観点やドメイン特性 から離れた結果になってしまう可能性がある． ソフトウェアの品質をメトリクスを用いて取り扱う手法 としてはGoal-Question-Metric法（GQM法）[2]がある． GQM法を使えば品質目標の達成度を測定するためのメト リクスを導くことができる．このメトリクスの値に対して 満たすべき条件を指定することで，ソースコードの品質が 1 早稲田大学 2 株式会社 小松製作所 a) [email protected] b) [email protected] c) [email protected] 図1 プロジェクト内のサブシステムsの保守性・再利用性評価 許容可能なものかどうか自動評価できる． GQMモデルは専門家などの合議によって作成されるの が一般的であり，これをプロジェクト毎に一から作るのは コストの面から現実的ではない．そこで我々は同一ドメイ ンでは共通のGQMモデルを再利用しつつ，解釈部分をプ ロジェクトごとに変更する仕組みを考えた．本稿ではそれ を実現する枠組みを提案する．評価式はメトリクス閾値を 用いた条件式の組み合わせで表現したものに限定するが， パラメタ（閾値）をプロジェクトに合わせて変更できる． このパラメタの最適化には機械学習を利用し，学習データ としては開発の過程で得られる一部のサブシステムに対す る人手レビュー結果を用いる．この枠組みを用いることで， 図2のように一部のサブシステムを人手レビューし終えた 段階で，他のサブシステムへプロジェクト特性を考慮した 自動評価を行うことができる．早期にプロジェクト全体に 対してレビューを行えるようになり，また人手レビュー結果と自動評価結果を比較することで自動評価の精度の向上 を図ることもできる．また，この枠組みはレビュー担当者 に対しては人手レビュー結果の形式を指定しメトリクス測 定ツールの利用も強制するが，ソースコード開発者には特 定のエディタや変更管理ツールの使用を強制しない．その ため，開発者の数が多い現場やレガシーな開発をしている 現場に対してもこの枠組みは導入しやすい， 我々はまず始めのResearch Questionとして，そもそも 評価式の閾値を変更するだけで人手レビュー結果に近似し た自動評価ができるようになるのかを調べることにした． そのため提案した枠組みを用い，ある建機メーカーが作 成したソフトウェアプロジェクト用に保守性・再利用性が 低いファイル（Unacceptable Files:FS）を検出するための GQMモデルと評価式を作成した．そして同企業の開発エ キスパートに人手レビューをしてもらい，その結果を学習 とテストのためのデータとした．そして実験の結果，評価 項目によっては人手レビューに近似した自動評価ができる ことを確認した，本研究の貢献は三点で，（1）プロジェク ト特性に合わせたメトリクス解釈を評価式のパラメタ変更 のみで実現する仕組みを提案することで，（2）GQMモデ ルと評価式を共通のドメイン内で再利用を可能とし，（3） さらに実際の産業データへの適用を通して手法の実現可能 性を確認したことである． 図2 サブシステムsに対する目視レビュー結果rを用いて，自動評 価用のパラメタをプロジェクトに合わせる枠組み
2.
背景
本章では提案手法で用いる要素技術の説明をする． 2.1 GQMモデル ソフトウェアの品質をメトリクスを用いて取り扱う手法 としてはGoal-Question-Metric法（GQM法）[2]がある． GQM法では図3のような三階層モデルを作成することで， 品質目標の達成確認で使用すべき質問（Qustions）とメト リクスを決めることができる．GQMモデルを作成すれば， なぜメトリクスを見る必要があるのかが明文化されるた め，後々になってメトリクスの利用目的が不明確になって しまう可能性を下げられる．さらに，注目すべきメトリク スが限定され，また品質評価をする際の観点が細分化され るため，問題個所と原因の追跡が行いやすくなる． 図3 GQMモデルの例 2.2 二分類の正解と予測結果の一致度指標 本稿の実験時に我々が扱う評価式はソースコードファイルをUFsとAFs（Acceptable Files）の二つに分類す
る．なので，その性能を評価するために，複数の二分類性 能評価指標を以下に挙げる：正解率（Accuracy），適合率 （Precision），再現率（Recall），F1値（F1-measure），カッ
パ係数（Cohen’s kappa）（注釈，カッパ係数は二つ以上の
分類の一致度評価にも使える）．これらの指標は表1に示す 4つの項，true positive（TP），false positive（FP），true negative（TN），negative（FN）をもとに計算できる．今 回我々の手法では主にカッパ係数を扱う，カッパ係数では 二人の評価者間の評価の一致度を表せるので，正解ラベル と予測結果を二者の評価結果とみなせばその一致度を測れ る．また適合率，再現率，F1値がFNの大きさを無視する が，カッパ係数ではその影響を考慮できる．そのため，FN の相対的な大きさや重要度が不明なケースでの一致度測定 にはカッパ係数が適していると考えたためである．Landis らによると[3]，カッパ係数で表される二者間の分類の一致 度を以下のようになる： 一致しない(kappa < 0.00)，かな り弱い一致度(0.00∼0.20)，弱い一致度(0.21∼0.40)，中程 度一致度(0.41∼0.60)，高い一致度(0.61∼0.80)，ほぼ一致 する(0.81∼1.00) . カッパ係数の導出式は(ACC - RA)/(1 - RA)である．RAは偶然による分類の一致度を表してい る．カッパ係数は見かけ上の一致率を排した，偶然によら ない一致率を表す指標として知られている． RA = N P A T OT AL∗ N P P T OT AL+ N N A T OT AL∗ N N P T OT AL(1) 表1 二項分類の真の結果（Answer）と予測結果（Predicted）の分 割表
Answer/Predicted Positive(Prd) Negative(Prd) Sum
Positive(Ans) TP FN NPA
Negative(Ans) FP TN NNA
3.
提案手法
我々は同一ドメインでは共通のGQMモデルを再利用し つつ，解釈部分をプロジェクトごとに変更する仕組みを考 えた．本稿ではそれを実現する枠組みを提案する．我々は 建機メーカーの開発者らと産学連携し，保守性・再利用性 の低いファイル（UFs）を自動検出するための評価式を現 場の観点を組み込みやすい（カスタマイズしやすい）形で 提供するための研究をしている．本章で提案する枠組みは その研究の中で開発されたものである． GQM法では達成したいゴールに関連する質問とメトリ クスを明示的に示し，それらを用いて品質評価をする．ま た，メトリクス値の解釈の仕方をInterpretation層として 定義する拡張版も提案されている．しかし，ソフトウェア プロジェクトには通常プロジェクト特有のルールや実践， 特徴があり，その違いがメトリクスの分布に影響する[1]． 他にも使用言語やコード自動生成ツール利用の有無も影 響するため，汎用的でかつメトリクス目標値が具体的な Interpretation層を用意するのは難しい．そこで我々は解 釈部分をプロジェクトごとに変更する仕組みを考えた．本 稿ではそれを実現する枠組みを提案する．図4のように Interpretation層の評価式はメトリクス閾値を用いた条件 式の組み合わせで表現したものに限定する．そして機械学 習を通して，このパラメタ（閾値）をプロジェクトに合わせ て最適化する．その際，開発の過程で得られる一部のサブ システムに対する人手レビュー結果を学習データとして用 いる．尚，メトリクスデータの測定は既存のツールによっ て行う． 図4 GQM+Interpretation層による許容可能性評価 3.1 メトリクス閾値の条件式を組み合わせた評価式 ファイルの保守性・再利用性の改善は，メトリクスを徹底 して小さくすることではない．例えば関数の数やステート メント数など全てを厳密に小さく抑えずとも，いずれかひ とつが十分に小さければ運用上問題ない場合もある．コー ド修正自体にもコストはかかるため，人手レビューでは上 記のようなファイルを許容する場合がある．そこで我々は より精度の高い自動UFs検出を目標として，AND節を用 いた異常判定と，OR節を用いた正常判定の組み合わせか ら成るファイル評価式を提案する． 本研究で扱う評価式はAND節とOR節の両方がTRUE のファイルはAFs，ひとつでもFALSEのファイルはUFs と判定する．異常判定（AND節）では各メトリクス値に大 きすぎるものがないかを調べており，正常判定（OR節）で は各メトリクス値が十分小さく抑えられているかを調べて いる．本稿の提案手法では主に望小特性（小さい方が望ま しい）のメトリクスを扱う．一般的なメトリクスでは複雑 度や規約違反件数などがこれにあたる．もし望大特性（大 きい方が望ましい）のメトリクスを扱いたければ，そのメ トリクスに-1を掛けて正負を逆転すれば望小特性のメトリ クスとして扱えるので，提案手法の枠内で扱うことが可能 である． 条件式booli= (Mi≤ Ti) (2)AND節: (booland1&&booland2&&...) (3)
OR節: (boolor1||boolor2||...) (4)
節を構成する条件式は式2のように，ファイルのあるメト リクス値Miと閾値Tiの大小関係で表されており，Miの
方が小さければTRUEとなる．AND節は式3で表され，
boolandのいずれかひとつでもFALSEであればAND節全
体もFALSEとなる．一方OR節は式4で表され，boolorの いずれかひとつでもTRUEであればOR節全体もTRUE となる． メトリクスの値を異常値（極端に大きい），準正常値（中 程度），正常値（十分に小さい）の三つに分けて考える．こ の際，各メトリクスには異常∼準正常間と準正常∼正常 間の二つの閾値を設ける．AFsと判定されるのは，ひと つ以上のメトリクスが正常値で残りが準正常値のファイ ルで，これ以上の改善が不要としている．UFsと判定さ れるのは，いずれかのメトリクスが異常値をとるファイ ル（AND-FALSE-Files：F F sAN D）か，全てのメトリクス が準正常値のファイル（OR-FALSE-Files：F F sOR）のど ちらかである．F F sAN Dには明らかに改善の余地がある． 一方，F F sORは異常ではないものの，まだ改善の余地が あるためUFsとして扱っている． 異常判定と正常判定は互いに補う関係にある．異常判定 （AND節）だけの評価式では，F F sORの検出ができない ので，まだ改善の余地があるファイルもAFs扱いしてし まうので望ましくない．一方正常判定（OR節）だけでは， 正常値のメトリクスがひとつでもあれば他のメトリクスが 異常値でも節全体がTRUEになってしまい一部の異常な ファイルもAFs扱いしてしまうので望ましくない． 3.2 評価式の作成方法 GQMモデルの各Questionには複数のメトリクスが対応 するので，Questionごとに評価式を作成することができる．
例えばあるQuestionXに三つのメトリクスM1，M2，M3が 関連していれば，AND節：(M 1≤ Tand1)&&(M 2≤ Tand2)，
OR節：(M 1≤ Tor1)||(M3 ≤ Tor3)のような評価式を作成 することができる．AND節とOR節の形の決め方は指定 しないが，本研究の実験準備では専門家複数がソフトウェ アのメトリクス値の分布を見ながら合議を通して節の形を 決めた．評価式の形が決まれば，次は使用する閾値の組み 合わせを決める必要がある．経験的に定めた閾値でも自動 評価を実施することはできるが，より高精度な自動UFs検 出を実現するために，次節にて最適な閾値を自動的に導出 する手法を提案する． 3.3 評価式のカスタマイズ 本節では，評価式の閾値をプロジェクトに合わせて変更 する手法を提案する．この提案手法では機械学習を利用し て最適な閾値の組み合わせを暫定解として導出し，その後 学習データに対する判別結果に合わせて暫定解を変形させ る．学習データはファイル単位の情報を複数ファイル分含 む．ファイルメトリクスデータとファイル種別（UFs or AFs）である．メトリクス測定は既存のツールで測定すれ ばよいが，ファイル種別はあらかじめ何らかの形で用意し なければならず人手レビューの実施や変更理履歴の解析な どをする必要がある．機械学習ではこのファイル種別を正 解ラベルとして用いる．また，本稿では主に人手レビュー を正解ラベルとする手法を扱う．
では次に，自動UFs検出の結果（UFs or AFs）が正解ラ ベルに対して最も高い一致度をとるようにすることを考え る．教師あり学習を用れば，そのようになる閾値の組み合 わせの最適解を探索的に導出することができる．そこで， 本節では焼きなまし法を用いて探索する手法を提案する． 焼きなまし法ではパラメタ（ここでは閾値の組み合わせ） をランダムに変更しながら最適解を探索することで，解が 局所最適に陥ることを防いでいる．貪欲法による探索では 一度局所最適に陥れば抜け出せないが，焼きなまし法では 一定確率でランダムなパラメタも試すので局所最適に陥り にくい，一致度の指標としては2.2節で挙げた指標のいず れかを使用すればよいが，本研究ではよりロバストなカッ パ係数を用いる．尚，焼きなまし法で各メトリクスの閾値 を変動させる際，その上限と下限を決める必要があるが， これは学習データが含む各メトリクスデータの最大値や最 小値に微小な値を加減したものを用いればよい（（M1の最 大値+0.01）や（M1の最小値-1））. 学習データを用いた焼きなまし法で暫定解を得たら，次 は暫定解を変形する．焼きなまし法で導出した暫定解はラ ンダムにパラメタを変動させて作ったものなので，探索ご とに結果が大きく違うことがありうる．例えば，あるメト リクスMとファイル種別を並べた学習データ｛（1,AF）， （2,AF），（20,UF），（25,UF）｝を考える．この場合，条件節
(M ≤ Tand1)の閾値Tを3にしても10にしても学習デー タに対しては条件節は同一の結果となる．同様の現象が評 価式内の全ての条件節で起こりうる．そこで，暫定解を用 いた場合と同じ評価結果を学習データに対して与えるよう な閾値の組み合わせで，かつ一意に決まるような解を得る ための変形規則を提案する．この変形規則は評価式ごとに 個別に適用する． 変形規則を適用するためにまず，学習データに対して暫 定解を用いた評価式で自動UFs検出を行う．その際，自動 検出したF F sAN DとF F sORも記録する．このとき，学 習データは自動検出結果が全件AFsにならないように選 ぶ．最後に，評価式に対して以下の二つの変形規則を適用 する． • AND節用の閾値変形規則：自動でF F sAN Dと判定されなかった ファイル群を見て，各メトリクスの最大値を新しいAND節用の閾値 とする． • OR節用の閾値変形規則：自動でF F sORと判定されたファイル 群がある場合と無い場合で異なる変形をする．群がある場合，各メ トリクスの最小値を新しいOR節用の閾値とする．そして，OR節 (M 1≤ Tor1)||...の二項演算子≤を<に変える．群が無い場合は， OR節を除去してAND節のみの評価式とする．
4.
実験
4.1 実験データ 4.1.1 保守性・再利用性の低いファイルを検出するため のGQMモデル 我々は共同研究先の企業との合議を経て我々は保守性・ 再利用性の低いファイル（UFs）を検出するためのGQM モデルを構築した．取り扱う質問とメトリクスは表2と表 3に示した．表2の質問はファイルの理解性，変更性，再利 用性を問うている．表3のメトリクスはコードサイズ，複 雑度，結合度，コードクローンなどと関係したものである． 我々のGQMモデルはAdquaのGQMモデルを参考に している．Adqua[4]とは既存のソフトウェア品質診断ツー ル（コードメトリクス利用）である．Adquaの100以上 ある質問とそれに対応する数百のメトリクスの中から保守 性・再利用性に関係するものを抽出し修正を加えることで 我々のGQMモデルを作成した． また，Adquaにはメトリクス集計機能もあり，静的解析 ツールQAC/QAC++で測定したメトリクスをcsv形式でま とめることができた*1．表3のMFl004∼MFl732はAdqua の出力の「 cppfile metrics value1.csv」などに書き出される． またMFl004K∼MFl007Kは「func metrics value1.csv」に ある関数単位のメトリクスMFn066とMFn072をファイ ル単位に集約するなどして得られる． 4.1.2 保守性・再利用性の低いファイルを検出するため の評価式 表4のCE01-10は表2のQ01-10に基づいて作成した10 *1 現在はC++の取り扱いは停止されている．表2 保守性・再利用性の低いファイル（UFs）を検出するための 質問
Q Description Related Metrics
Q01 不要な引数をそのまま残してい ないか MFl097, MFl732 Q02 責務量（ステートメント数や関 数数）は適切か MFl004, MFl019, MFl477 Q03 意図を明確にしていないマジッ クナンバを不必要に用いていな いか MFl497 Q04 Private-Publicの使い分けは 適切か MFl002K Q05 関数の処理が複雑すぎないか MFl004K, MFl005K, MFl006K, MFl007K Q06 演算の順序をわかりやすくして いるか MFl232 Q07 コードクローンは多すぎないか MFl062 Q08 外部結合の数が異常でないか、 また外部結合である必要がある か MFl061, MFl152, MFl316, MFl317 Q09 自ファイルを依存している外部 要素は限定されているか（…外 部に変更の影響を与えないか） MFl590, MFl591, MFl599 Q10 自ファイルが依存している外部 要素は限定されているか（…外 部の変更の影響を受けないか） MFl026, MFl588, MFl589 表3 保守性・再利用性の低いファイル（UFs）を検出するための ファイルメトリクス Metrics Description MFl004 ステートメント数 MFl019 関数の数 MFl026 外部結合グローバル変数使用・関数呼び出しにより使用する他 ファイルの種類数 MFl061 外部結合グローバル変数の定義数 MFl062 コードクローン率 MFl097 未使用の実引数の数 MFl152 ソースファイルで宣言された外部結合を持つ変数や関数の数 MFl232 演算の順序がわかりにくいものの数 MFl316 一つの翻訳単位でのみ使用される外部結合を持つ関数の数 MFl317 一つの翻訳単位でのみ使用される外部結合を持つオブジェクト の数 MFl477 実行コード行数 MFl497 マジックナンバの使用数 MFl588 他ファイルの外部結合グローバル変数を使用する関数の種類数 MFl589 使用する他ファイルの外部結合グローバル変数の種類数 MFl590 他ファイルから使用される自ファイルの外部結合グローバル変 数の種類数 MFl591 自ファイルの外部結合グローバル変数を使用する他ファイルの 関数の種類数 MFl599 外部結合グローバル変数使用・関数呼び出しにより、自ファイ ルを使用する他ファイルの種類数 MFl732 仮想関数内で使用されない引数の数 MFl002K ファイル内部からしか呼び出されていないpublic関数の定義 数 MFl004K 各関数の制御フローネストのファイル内平均値 MFl005K 各関数の制御フローネストのファイル内最大値 MFl006K 各関数のサイクロマチック複雑度のファイル内平均値 MFl007K 各関数のサイクロマチック複雑度のファイル内最大値 個の評価式（CE）であり，それぞれファイルを評価する観 点が異なる．評価式の形は建機メーカーとの合議によって 定めた． 表4 保守性・再利用性の低いファイル（UFs）を検出するための評 価式(略記: MFl004− >M004, MFl005K− >05K) CE Q AND節 OR節 CE01 Q01 M097<Ta101 &&
M732<Ta201
—
CE02 Q02 M004<Ta102 && M019<Ta202 && M477<Ta302 M004<To102 || M019<To202 || M477<To302 CE03 Q03 M497<Ta103 — CE04 Q04 002K<Ta104 — CE05 Q05 04K<Ta105 &&
05K<Ta205 && 06K<Ta305 && 07K<Ta405 04K<To105 || 05K<To205 || 06K<To305 || 07K<To405 CE06 Q06 M232<Ta106 — CE07 Q07 M062<Ta107 — CE08 Q08 M152<Ta108 &&
M61<Ta208
M316<To108 || M317<To208 CE09 Q09 M599<Ta109 &&
M590<Ta209 && M591<Ta309
M599<To109 || M590<To209 || M591<To209 CE10 Q10 M026<Ta110 &&
M588<Ta210 && M589<Ta310 M026<To110 || M588<To210 || M589<To210 4.1.3 実験対象のソフトウェアプロジェクト 提案手法の効果を実験的に確認するために，実験対象と して建機メーカーで作成されたソフトウェアを用いる．対 象となったのは中型パワーショベルを制御するためのシス テムでCとC++で記述されていた．そのシステムが含む C++で記述された三つの重要なサブシステムを今回の実 験対象としてもらった．三つのサブシステムsub01-03の 規模は表5に示した． 表 5 実験対象のサブシステム（C++）の規模（略記：ファイル 数-¿FiN）
subsys FiN 関数の数 SLOC LLOC
Sum Med Sum Med Sum Med sub01 55 363 6 8875 135 1963 26 sub02 31 351 9 6926 144 2157 39 sub03 58 683 8 13962 125 3665 24.5 4.1.4 一部のサブシステムに対する人手レビュー結果 人手レビューは共同研究先の企業の開発専門家一名に 行ってもらった．この専門家は10年以上のソフトウェア 開発経験があり，ソフトウェアアーキテクトをしている． レビュー者はソースコードファイルを目視し，それぞれの ファイルに対して10個の得点（表2の10個のQuestion に対応）を与えた．またレビュー者には0∼100点の範囲で
75点未満のファイルがUFsになるものとして，本人の主 観と経験に基づいて採点するよう依頼した．得点の大小を 決める際にはファイル間の相対評価を意識してもらった． レビュー者にはメトリクスデータは与えられておらず，ま たレビュー者は自動UFｓ検出ツールを用いていない．レ ビュー者に与えられたのは，表2に示した質問の説明文の みである． レビューの機会は二回設けられ，一回目ではsub01に 対するレビュー，二回目ではsub02とsub03に対するレ ビューが行われた．レビュー者はどの回も同一の一名で あった．一回目のレビューでは約一時間で55個のファイ ルのQ01-10が採点された．二回目のレビューでは約一時 間で89個（sub02，sub03）のファイルのQ02とQ05が採 点された．二回目のレビューで採点項目が少なくなってい るのは，後述の実験1の結果が先に得られたためである． レビュー者の時間が限られていたため，実験1で良い成果 が出ていたQ02とQ05を優先して行ってもらった．最後 に，表6に人手レビュー結果を要約する． 表6 保守性・再利用性に問題のないファイル（AFs）とあるファイ ル(UFs)の人手レビュー結果（ファイル件数）
Q sub01 sub02 sub03
AFｓ UFs AFs UFs AFs UFs
Q01 52 3 - - -Q02 23 32 20 11 40 17 Q03 55 0 - - -Q04 49 6 - - -Q05 35 20 20 11 43 14 Q06 49 6 - - -Q07 21 34 - - -Q08 48 7 - - -Q09 48 7 - - -Q10 30 25 - - -4.2 実験内容
Research Questionに答えるために，自動UFs検出の性
能を調査する二回の実験を実施した．実験1ではCE01-10 で用いる閾値の最適値を導出し，それを用いた場合にそ れぞれのCEがどこまで人手レビューに近い予測が可能に なるかを調べた．学習データとテストデータは同じもの （sub01の55個のファイル）を用いた．尚，ひとつのCEに 対して行う焼きなまし法による閾値探索は20秒間とした． 実験2では実験1で導出した閾値を使い，CE02とCE05 による自動UFs検出をsub02とsub03のファイルに対し て行った．つまり学習データがsub01でテストデータが sub02とsub03になっている． 4.3 実験結果と考察 4.3.1 実験1 表7は実験1の結果である．学習・テスト対象はsub01 である．カッパ係数を一致度指標として，人手レビュー結 果に最も一致する自動評価ができるようにした場合で，各 一致度指標がどのようになったかを表している．カッパ 係数が0.61以上の評価式CE02，CE05，CE09は人手レ ビューによく近似した自動評価ができるている． 表6を見ると，Q01，Q03，Q04，Q06，Q08では55個 のファイルに対して人手レビューでUFsと検出された数 が少ないことがわかる，この学習データの偏りが対応す るCEのカッパ係数の低さに繋がったと考えられる．また Q08とQ10は「そのファイルの外部への結合度合」と関連 した質問であるが，実験後に確認したところsub01は外部 への機能提供を主としているが，逆にsub01が外部の機能 を使うことは少ないことがわかった．このため，sub01は Q08とQ10の学習データとして適切ではなかったと考え られる．実験1の結果，このように質問・評価式ごとに学 習データとすべきサブシステムやファイルに違いがあるこ とがわかった． 表 7 実験1の結果：sub01を学習・テスト対象とした際の人手レ ビュー結果と自動評価で検出されたUFsの一致度
Q Pre Rec F1 Kap Q01 0.06 1.00 0.12 0.01 Q02 0.94 0.91 0.92 0.79 Q03 0.00 NaN NaN 0.00 Q04 NaN 0.00 NaN 0.00 Q05 0.87 1.00 0.93 0.88 Q06 NaN 0.00 NaN 0.00 Q07 0.85 0.50 0.63 0.25 Q08 NaN 0.00 NaN 0.00 Q09 1.00 0.57 0.73 0.70 Q10 0.89 0.36 0.52 0.35
実験1ではCE02，CE05，CE09に対して下記の閾値・ 評価式が導出された．
• CE02:(MF l004 ≤ 25)&&(MF l019 ≤ 12)&&(MF l477 ≤ 37) • CE05:((MF l004K ≤ 2.33)&&(M F l005K ≤
4)&&(M F l006K ≤ 3.40)&&(M F l007K ≤ 11))&&((M F l004K < 1.00)||(MF l005K <
3)||(MF l006K < 2.17)||(MF l007K < 7))
• CE09:(MF l599 ≤ 20)&&(MF l590 == 0)&&(MF l591 ==
0) CE02とCE09は変形規則によってOR節が除去されてい る．CE02の閾値を見ると，1ファイルあたりのステート メント数が25以下であるべきという厳しい基準になって いる．そのため，我々は実際のコードを見て実態を確認し た．すると，物理行数が100行以上のファイルであっても， 空行や括弧のみの行や，include文やusing文を除けばス テートメント数が20以下になる場合があった．今回の実 験対象のシステムを作成した建機メーカーでは，設計駆動 開発によりコードの雛形を自動生成しており，場当たり的 にファイルや関数内のステートメントを膨らませることが 避けられていたために，機能分割が適切に行われ，結果1
ファイルあたりのステートメント数が少なく収まったもの と考えられる． 4.3.2 実験2 実験2で用いるsub02とsub03に対する人手レビューは 実験1でカッパ係数が大きかった上位二つの評価式に対応 する質問に限定して行われた．さて，表8は実験2の結果 である．評価式は実験1で得たものを使用し，テストデー タとしてはsub02とsub03を用いた．CE05の自動評価で
はsub02とsub05どちらにおいてもカッパ係数が0.81以 上で，人手レビューの結果とほぼ一致する．一方，CE02の 自動評価ではカッパ係数が0.40近傍であり，多く見積もっ ても中程度の一致度しかない．このことから，プロジェク ト毎にメトリクスの分布傾向の違いがあるように，同一プ ロジェクト内のサブシステム同士にもメトリクス分布傾向 が違う場合があることが確認できた．CE05の自動評価の 良好さからすると，関数の複雑度はサブシステム間での傾 向の違いが少ないと考えられる．逆に，ステートメント数 や関数の数はサブシステム間での違いが出やすいと考えら れる．
表8 実験2の結果：sub01で学習し，sub02とsub03でテストした 際の人手レビュー結果と自動評価で検出されたUFsの一致度
subsys&Q Acc Pre Rec F1 Kap sub02:Q02 0.68 0.53 0.91 0.67 0.39 sub02:Q05 0.94 0.91 0.91 0.91 0.86 sub03:Q02 0.70 0.50 0.88 0.64 0.42 sub03:Q05 0.94 0.87 0.93 0.90 0.86
5.
関連研究
Alvesらは統計的に意味のあるメトリクスの閾値を導出 する手法を提案している[5] Alvesらの手法では機械学習 をせずに，%quantileを利用して閾値を導出している．一 方，我々の手法ではUFsを判定用の学習データを用いた機 械学習を通して閾値を導出している．また，Alvesらの手 法ではあるメトリクスの閾値を導出する際に別のメトリク スとの相互作用を考慮しないが，我々の手法では相互作用 が学習結果に反映される． 門田らはプロジェクトモニタリング用にGQMモデルを カスタマイズしている[6]．彼らのモデルを利用するにはプ ロジェクトがEPM[7]を利用している必要がある．一方， 我々の枠組みはレビュー担当者に対しては人手レビュー結 果の形式を指定しメトリクス測定ツールの利用も強制す るが，ソースコード開発者には特定のエディタや変更管理 ツールの使用を強制しない．そのため，開発者の数が多い 現場やレガシーな開発をしている現場に対してもこの枠組 みは導入しやすい，また，門田らは同論文で具体的な閾値 を指定しない形でInterpretation層を定義している．我々 の枠組みでは，人手レビュー結果を得る手間はかかるが， プロジェクト毎に評価式の具体的な閾値を決めることがで きる． Jacekらはプロジェクトの履歴データを用いて修正すべ き箇所を予測するモデルを提案している[8]．一方，我々の 枠組みではメトリクス閾値を組み合わせた評価式によって UFsを予測するモデルを扱っており，予測の最適化のため の学習用正解データとしてシステムの一部に対する人手レ ビュー結果を利用している． Rahmanらはクロスプロジェクトの欠陥予測よりも単一 プロジェクト内の欠陥予測の方がパフォーマンスが高いと 述べている[9]．我々の手法では単一プロジェクト内での UFs予測を扱っており，同様の傾向があると考えられる．6.
おわりに
我々は保守性・再利用性が低いファイル（Unacceptable Files：UFs）の自動検出を効率的に実施するための研究を 手がけ，その過程で，自動UFs検出を効果的に行うための 枠組みを考案した． 本稿では建機メーカーの実プロダクトを用いて，我々の 枠組みの有効性を実験的に確認した．その結果，ファイル の自動評価を人手レビューに近似させることが可能である ことがわかった．そして評価式ごと学習データとして選ぶ サブシステムやファイルの向き不向きがあることがわかっ た．また，プロジェクトと同様サブシステム同士でもメト リクス傾向が違う場合があることをがわかった． 今後の研究では，学習対象のサブシステムやファイルの 効果的な選び方を調べたい．それにはどのメトリクスがど んなサブシステム間で同じ傾向になるのかが関係すると考 えられる． 参考文献[1] Zhang, F. and et al.: How Does Context Affect the Dis-tribution of Software Maintainability Metrics?, Proc. of
the 2013 IEEE Int. Conf. on Soft. Maintenance, ICSM
’13, Washington, DC, USA, IEEE Computer Society, pp. 350–359 (online), DOI: 10.1109/ICSM.2013.46 (2013). [2] Basili, V. R. and et al.: A Methodology for
Col-lecting Valid Software Engineering Data, IEEE Trans.
Softw. Eng., Vol. 10, No. 6, pp. 728–738 (online), DOI:
10.1109/TSE.1984.5010301 (1984).
[3] Landis, R. and et al.: The measurement of observer agree-ment for categorical data, Biometrics, Vol. 33, No. 1, pp. 159 – 174 (1977).
[4] Hironori, W. and et al.: A Framework for Measuring and Evaluating Program Source Code Quality, Proc. of the 8th
Int. Conf. on PROFES, PROFES’07, Berlin, Heidelberg,
Springer-Verlag, pp. 284–299 (2007).
[5] Alves, T. and et al.: Deriving Metric Thresholds from Benchmark Data, Proc. of the 2010 IEEE Int. Conf. on
Soft. Maintenance, ICSM ’10, Washington, DC, USA,
IEEE Computer Society, pp. 1–10 (2010).
[6] MONDEN, A. and et al.: Customizing GQM Models for Software Project Monitoring, IEICE Trans. on
Informa-tion and Systems, Vol. 95, No. 9, pp. 2169–2182 (2012).
[7] Masao, O. and et al.: Empirical project monitor: A tool for mining multiple project data, Project Data, Proc. Int.
Wksp. on Mining Soft. Repositories, pp. 42–46 (2004).
[8] Ratzinger, J. and et al.: Mining Software Evolution to Predict Refactoring, Proc. of the First Int. Symp. on
Em-pirical Soft. Eng. and Measurement, ESEM ’07,
Wash-ington, DC, USA, IEEE Computer Society, pp. 354–363 (2007).
[9] Rahman, F. and et al.: Recalling the ”Imprecision” of Cross-project Defect Prediction, Proc. of the ACM
SIG-SOFT 20th Int. Symp. on the Foundations of Soft. Eng.,
FSE ’12, New York, NY, USA, ACM, pp. 61:1–61:11 (2012).
