要旨

1.はじめに
近年，大規模で複雑なソフトウェアを，高品質に素早く開発することが求められている．短い期間の中で品質の高いソフトウェアを作るためには，早期に効率よくフォールトを見つけ，修正による手戻りを最小限にすることが重要となる．このようなニーズに対して，潜在的なフォールトの場所を予測する，Fault-Prediction技術に注目が集まっており，実プロジェクトでの利用も進んでいる． Fault-Prediction技術は，ソフトウェアの中から，潜在的なフォールトが存在する可能性が高い部分（モジュール・ファイル・クラス・メソッド・行など）を予測する技術[1]である．具体的には，モジュールやファイルなどのソフトウェアの部分ごとに，潜在的なフォールトの存在確率を表す「潜在フォールト率」を算出する. Fault- Prediction技術で算出した潜在フォールト率が高い部分を重点的にレビューやテストすることで，効率よくフォールトを見つけられる.近年特に利用が進んでいるFault-Prediction技術には,既知のフォールトや静的解析ツール[2][3]で検出できるコーディング規約造反[4][5]などの指摘を利用したものがある．これらの技術では，予測対象のプロジェクトにおける既知のフォールトや指摘を基に潜在フォールト率を算出する.そのため,開発立ち上げ直後のプロジェクトなどで，既知のフォールトや指摘が少ない場合，潜在フォールト率を算出できないという課題がある.この課題を解決するため，本研究では，ソフトウェアの品質に影響を与える「開発者」に着目し，開発者が過去に携わった既存のプロジェクトで作り込んだフォールトや指摘などの情報を基にしたFault-Prediction技術を提案する．提案手法は，既存のプロジェクトにおけるフォールトや指摘を利用するため，立ち上げ直後のプロジェクトであっても利用可能である.以降，2.では，関連する研究について説明する．3.では，提案手法について説明する．4.では，評価方法，評価対象，及び，結果を説明し，5.で考察を述べる．最後に， 6.でまとめと今後の課題について述べる.
2.関連研究
2.1. Fault-Prediction技術
1971年には，ソースコードの行数を指標とするFault- Prediction技術の研究[6]が始まっており，以降，循環的複雑度[7]などの指標を複数組み合わせた研究[8]がおこなわれてきた．また，1990年ごろからは，オプジェクト指向言語を対象とした研究[9]なども行われている.近年では，フォールトの分布や修正頻度を利用した研究[10][11][12]で成果が出ており，実プロジェクトでの活用が進んでいる．代表的な方法は，「既知のフォールトがより多く存在するファイルに，より多くの潜在的なフォールトがある」と予測するものである．この方法では，ファイルごとに，「当該ファイルが原因になったフォールトの数」を集計して潜在フォールト率とする.さらに，フォールトと静的解析ツールの指摘の関係があるという研究成果[13][14]に基づき，指摘の分布や修正頻度を利用した研究[15][16][17]もある．代表的な方法は， 「指摘をより多く受けたファイルに，より多くのフォールトがある」と予測するものである．この方法では，まず，開発中のファイルにcheckstyle[2]やFindBugs™*1[3]などの静的解析ツールを適用して指摘を取得する．次に，ファイルごとの指摘数を集計して潜在フォールト率とする.
2.2.開発者の特徴
ソースコードなどの成果物の品質には，開発者の影響があることが知られている．例えば，Avgustinovら[18]は，開発者ごとに受ける指摘に違いがあることを示した． Matsumotoら[19]は，開発者の特徴を表すメトリクスを提案し，開発者ごとに違いがあることを示した.
3.提案手法
提案手法である「開発者に着目したFault-Prediction技術」は，開発の立ち上げ直後であっても利用できるFault-Prediction技術である．本手法は，ソフトウェアの開発者に着目し，開発者が過去に携わった既存のプロジェクトで作り込んだフォールトや指摘などの実績情報を基に，予測対象プロジェクトのファイルごとにフォールトが含まれる可能性を潜在フォールト率として算出することを特徴とする.以降，3.1にて実績情報を定義したのち，3.2で開発者に着目したFault-Prediction技術について説明する.
3.1.実績情報
本研究では，実績情報を「開発者のフォールトの作り込みやすさを直接的／間接的に表すメトリクス」と定義する．例えば，「開発行あたりの平均フォールト数」や「開発行あたりの平均指摘数」は，実績情報である．他にも， Matsumotoら[19]が提案した「コミットあたりの平均フォールト混入率」など，開発者ごとに測定可能で，かつ，Fault-Prediction技術で利用可能なメトリクスも実親情報である.ここで，本論文で実績情報として利用した開発行あたりの平均フォールト数と開発行あたりの平均指摘数の定義を示す.定義.開発者dの開発行あたりの平均フォールト数:Pf(d) Pf( d ) =開発者dの開発行あたりの平均フォールト数FL(d) = DL( d )
定義、開発者dの開発行あたりの平均指摘数:Pv(d)

3.2.開発者に着目したFault-Prediction技術
提案手法である開発者に着目したFault-Prediction技術では，以下に示す定義に基づいて潜在フォールト率を算出する．算出した潜在フォールト率が高いファイルを順にレビューやテストすることで，開発の早い段階でフォールトを見つけて修正することが可能となる.定義、実績情報に基づく潜在フォールト率:FR(f)
尚,  P( d )は,  3.1で定義したPf( d ),  Pv( d )等を表す.
4.評価
開発の立ち上げ直後において，提案手法で算出した潜在フォールト率が高いファイルを重点的にレビューやテストすることで，フォールトを効率的に見つけられるか評価した.
4.1.評価方法
具体的な評価方法は以下の通りである. 1.開発がある程度進んでおり，尚且つ，同じ開発者が従事しているプロジェクトを2つ用意し，一方を開発者が過去に関わった既存のプロジェクト，もう一方
を開発の立ち上げ直後である予測対象のプロジェクトとみなす. 2.既存のプロジェクトを基に開発者の実績情報を取得し，その実績情報を基にして予測対象のプロジェクトの開発の立ち上げ直後における各ファイルの潜在フォールト率FR(f)を算出する. 3. FR(f)が高い順にファイルをレビューやテストした時に発見可能なフォールト数を算出する. 4.ランダムにファイルをレビューやテストした時に発見可能なフォールト数を算出し，3.と比較する．尚，評価は，3.2で示した開発者の実績情報に基づく潜在フォールト率算出において，P( d )としてPf( d )を用いた方法と，Pv( d )を用いた方法の2通りで行った．以降，前者をFPf,後者をFPvと呼ぶ.
4.2.評価対象
企業内のJavaソフトウェアのプロジェクトを対象に,提案手法を評価した．評価対象ソフトウェアの概要は，表1の通りである．尚，フォールトには，単体テストで見つけたフォールトと，結合テストで見つけたフォールトが含まれている.本評価では，1つのプログラムを機能の観点で2つに分割し，2つのプロジェクトに見立てて評価した．両モジュールの概要は，表2，表3の通りである．以降，両モジュールを，それぞれ「モジュールA」「モジュールB」と呼ぶ。 FPf, FPv双方に対して,モジュールAを既存のプロジェクト,モジュールBを予測対象のプロジェクトとみなした評価と，その逆の評価を実施した（表4）、以降，各

4.3.評価結果
B→A@FPf及びB→A@FPvの結果を図１に, A→B@FPf及びA→B@FPvの結果を図2に示した.両グラフの横軸は，提案手法で算出した潜在フォールトが高い順にファイルを並べたものであり，縦軸は，累穣フォールト率を表している．累積フォールト率は，全フォールト数に対する，潜在フォールト率が高い順にテストやレビューを行った際に発見可能なフォールトの割合である．つまり，「潜在フォールト率が高いファイル上位ェ個の中に，全フォールトのy%のフォールトが含まれているか」を表している．例えば，図１では，潜在フォールト率が高いファイル上位40個をテストやレビューすることで，最大で，全フォールトの約６割のフォールトを発見できることを表している．また，図１と図２における，潜在フォールト率が高いファイル上位25%，50%，75%までの累積フォールト率を表5に示した．尚，理論上の最大値は，既知のフォールトが多い順にファイルを並べたものであり，また，ランダムサンプリングは，10回ファイルをランダムに並べた際の，累積フォールト率の平均である．図1,図2,及び,表5をもとに, FPf及びFPvの結果について述べる. FPfでは，潜在フォールト率が上位25%のファイルに， B→A@FPfで64%,  A→B@FPfで55%のフォールトが含まれていた．どちらも，25%のファイルをランダムに選んだ場合と比較すると，倍以上のフォールトを含んでいる．また，潜在フォールト率が上位50%，75%の場合においても，ファイルをランダムに選んだ場合より，多くのフォールトが含まれていた. FPvでは，潜在フォールト率が上位25%のファイルに，B→A®FPvで63%，A→B®FPvで68%のフォールトが含まれていた．どちらも，25％のファイルをランダムに選んだ場合と比較すると，俗以上のフォールトを含んでいる．また，潜在フォールト率が上位50%，75%の場合においても，ファイルをランダムに選んだ場合より，多くのフォールトが含まれていた． FPfとFPvを比較すると，潜在フォールト率が上位
75%の場合においては，FPfの方が多くのフォールトを含んでいるが，それ以外の場合では，一定の傾向はみられなかった.
5.考察
5.1.提案手法の有用性
4.3で示した通り，立ち上げ直後のプロジェクトであっても，提案手法を利用し，潜在フォールト率が上位25%のファイルを重点的にレビューやテストすることで，約６割のフォールトを発見できる可能性がある.大規模で複雑なソフトウェアを商品質に茶早く開発するためには，早期に効率的にフォールトを発見することが重要となる．しかしながら，従来手法は，立ち上げ直後のプロジェクトでの利用が難しい．一方，提案手法では，立ち上げ直後のプロジェクトであっても，効率的なフォールト発見を実現できると言える.
5.2. FPfとFPvの比較
4.3で示した通り，本評価では，FPfとFPvの間に優位な差を見出すことはできなかった．但し，特にモジュールBは，ファイル数が50ファイルとそれ程多くないため，測定誤差による影響が大きくでている可能性がある．
5.3.従来手法との比較
従来手法と提案手法を比較しながら，提案手法であれば，開発の立ち上げ直後であっても潜在フォールト率を算出できる理由を考察する.図3は，時間経過に伴う，既知フォールト，指摘，実績情報の変化と，従来手法及び提案手法での潜在フォールト率の算出可否を表している．既存のプロジェクトも予測対象のプロジェクトも，立ち上げ直後には既知のフォールトが存在しておらず，また，指摘も少ない．開発が進むと，まず指摘が多くなり，さらに開発が進むと，既知のフォールトも多くなる．尚，図中の網掛け部分は，従来手法，提案手法で潜在フォールト率を算出できる部分を表している.従来手法，提案手法ともに，予測に利用する既知のフォールトや指摘の情報（「予測基情報」と呼ぶ）が少ないと，潜在フォールト率の算出ができない．一方で，従来手法と提案手法には，既存のプロジェクトの予測基情報を利用できるか否かの点で差がある.従来手法は，予測対象のファイルにおけるフォールトや指摘の情報を予測基情報として利用する．既存のプロジェクトで作成したファイルと予測対象のプロジェクトで作成したファイルは異なるため，既存のプロジェクトの予測基情報を予測対象のプロジェクトで利用することができない．それに対し，提案手法では，予測対象の開発者における実績情報を予測基情報として利用する．そのため，同じ開発者が既存のプロジェクトと予測対象のプロジェクトを担当していれば，既存のプロジェクトで得られる予測基情報を予測対象のプロジェクトで利用できる可能性がある.本評価より，既存のプロジェクトで得られる予測基情報を予測対象のプロジェクトで利用できることが分かった.
6.まとめと今後の課題
近年，ソフトウェアに存在するフォールトの発見を支授できるFault-Prediction技術に注目が集まり，実プロジェクトでの利用が進んでいる．しかしながら，従来のFault-Prediction技術では，フォールトの予測の基になる情報が少ない立ち上げ直後のプロジェクトでは，利用が難しいという課題がある．そこで本研究では，開発者が過去に関わった既存のプロジェクトを分析し，開発者ごとの実績情報を得たうえで予測の基になる情報として利用し,開発の立ち上げ直後でも利用できるFault-Prediction技術を提案した.提案手法を企業内のある1プロジェクトで評価したところ，実績情報として「開発行あたりの平均フォールト数」と「開発行あたりの平均指摘数」を利用した場合,フォールトが存在する確率が高いと予測した上位25%のファイルに全フォールトの約6割が含まれるという結果を得られた．この結果は，ランダムに25%のファイルを選択した際に含まれるフォールトの割合（20%～30%）と比較すると，2倍程度大きい．つまり，提案手法により算出したフォールトの存在確率が高いファイルを重点的にレビューやテストすることで，立ち上げ直後のプロジェクトであっても，早期のフォールト発見を支援できると言える.尚，本研究では１プロジェクトのみを利用して評価したため，他のプロジェクトを含めた評価が今後の課題である．また，今回利用した2つの実績情報以外の実績情報でも評価し，予測精度向上の可能性を探る．