本発明は、ソフトウェア開発において生じる欠陥の数を予測するソフトウェア欠陥予測装置,ソフトウェア欠陥予測方法,およびソフトウェア欠陥予測プログラムに関する。

従来より、ソフトウェアシステムに関して、開発中あるいは開発後に、「不具合」,「バグ」などと呼ばれる欠陥が生じることが多々ある。このような欠陥が検出(発見)されると、欠陥を修正するための作業が必要となる。特に開発初期の段階で混入した欠陥がユーザリリース(開発したシステムをユーザのコンピュータに導入すること)後に検出されると、その欠陥を修正するために開発作業に大きな手戻りが生じてしまう。従って、システム(ソフトウェア)に混入した欠陥については、大きな手戻りが生じることのないよう、できるだけ早期に検出されることが好ましい。

欠陥を少なくしてソフトウェアの品質を高めるためには、理想的には、ソフトウェア開発の各開発工程において工程改善(例えば、レビューを充分に行うことや開発者を多く投入すること等)を実施することが好ましい。しかしながら、コストや時間などの制約があるために、多くの場合、対象工程を絞って工程改善が実施されている。改善対象工程の絞り込みは、開発工程毎の品質に関する定量的なデータに基づいて行われることが好ましい。品質に関する定量的なデータとしては、例えば欠陥数が挙げられる。なお、本明細書では、「混入欠陥数」および「検出欠陥数」という用語を用いる。「混入欠陥数」とは、ソフトウェア開発の各開発工程において実際に成果物に混入した欠陥の数のことである。「検出欠陥数」とは、混入欠陥数のうち開発者やユーザによって検出(発見)された欠陥の数のことである。従って、検出欠陥数が混入欠陥数を超えることはない。

上述したように、改善対象工程の絞り込みは、開発工程毎の品質に関する定量的なデータに基づいて行われることが好ましい。そこで、ソフトウェア開発の各開発工程の成果物についての検出欠陥数を予測することが従来より行われている。例えば、以下の特許文献1に記載されている情報処理装置では、累積指標という概念を用いた回帰分析によって、ソフトウェア開発の開発工程毎の検出欠陥密度の予測が行われている。また、以下の特許文献2に記載されている予測値算出装置では、協調フィルタリングの手法を用いて、ソフトウェア開発に関する各種評価項目(例えば工数)の評価値の予測が行われている。なお、協調フィルタリングの手法を用いてソフトウェア開発におけるプロジェクトの工数を予測する方法については、以下の非特許文献1に記載されている。

特開2011−76411号公報

特開2011−197839号公報

角田雅照ら著 「協調フィルタリングを用いたソフトウェア開発工数予測方法」、情報処理学会論文誌、2005年5月、Vol.46 No.5、p.1155−1164

ところが、検出欠陥数は実際にシステムに混入している欠陥の数(混入欠陥数)とは異なるため、検出欠陥数に基づいて改善対象工程の絞り込みが行われても、欠陥が効率的に除去されるとは限らない。また、ソフトウェア開発については開発工程毎に例えば開発会社や作業者が異なるという特性を有しているが、従来技術によれば、欠陥数などの評価項目の評価値を予測する際にソフトウェア開発の特性が考慮されていない。従って、予測値の精度が充分ではない。

そこで本発明は、ソフトウェア開発の各開発工程で生じる欠陥の数を高い精度で予測し、より効率的な改善対象工程の絞り込みを行うための情報を提示できるシステムを実現することを目的とする。

第1の発明は、ソフトウェア開発において生じる欠陥の数を予測するソフトウェア欠陥予測装置であって、 各プロジェクトについての開発工程毎の混入欠陥数を保持する混入欠陥数保持手段と、 各プロジェクトについての開発工程毎の検出欠陥数を保持する検出欠陥数保持手段と、 各プロジェクトについての開発工程毎の規模を表す規模値を保持する規模値保持手段と、 前記規模値保持手段に保持されている各プロジェクトについての開発工程毎の規模値を用いて、混入欠陥数および検出欠陥数を予測する対象である予測対象プロジェクトと該予測対象プロジェクト以外のプロジェクトとの類似度を算出する類似度算出手段と、 前記予測対象プロジェクトとの類似度が比較的高いプロジェクトである高類似プロジェクトについての、前記混入欠陥数保持手段に保持されている開発工程毎の混入欠陥数および前記検出欠陥数保持手段に保持されている開発工程毎の検出欠陥数と、前記予測対象プロジェクトと前記高類似プロジェクトとの類似度とに基づいて、前記予測対象プロジェクトについての開発工程毎の混入欠陥数および検出欠陥数の予測値を算出する予測値算出手段と を備えることを特徴とする。

第2の発明は、第1の発明において、 前記類似度算出手段は、前記類似度を算出する際、前記混入欠陥数保持手段に保持されている各プロジェクトについての開発工程毎の混入欠陥数および前記検出欠陥数保持手段に保持されている各プロジェクトについての開発工程毎の検出欠陥数を更に用いることを特徴とする。

第3の発明は、第2の発明において、 前記類似度算出手段は、前記類似度を算出する際、前記混入欠陥数保持手段に保持されている前記予測対象プロジェクトについての実施済みの開発工程の混入欠陥数および前記検出欠陥数保持手段に保持されている前記予測対象プロジェクトについての実施済みの開発工程の検出欠陥数を更に用いることを特徴とする。

第4の発明は、第1から第3までのいずれかの発明において、 前記予測値算出手段は、更に、前記予測対象プロジェクトについての開発工程毎の規模値の予測値を算出することを特徴とする。

第5の発明は、第1から第4までのいずれかの発明において、 各プロジェクトについての開発工程毎の技術的指標に基づいて得られる評価値および環境的指標に基づいて得られる評価値を保持する技術要因・環境要因保持手段を更に備え、 前記類似度算出手段は、前記類似度を算出する際、前記技術要因・環境要因保持手段に保持されている各プロジェクトについての開発工程毎の技術的指標に基づいて得られる評価値および環境的指標に基づいて得られる評価値を更に用いることを特徴とする。

第6の発明は、第1から第5までのいずれかの発明において、 各プロジェクトについての開発工程毎の難易度を保持する難易度保持手段を更に備え、 前記類似度算出手段は、前記類似度を算出する際、前記難易度保持手段に保持されている各プロジェクトについての開発工程毎の難易度を更に用いることを特徴とする。

第7の発明は、第6の発明において、 前記難易度保持手段は、前記難易度として、ソフトウェア開発で作成されたソースコードの難易度を表す指標であるソースコードメトリクス値を保持し、 前記予測値算出手段は、更に、前記難易度保持手段に保持されている前記高類似プロジェクトについてのソースコードメトリクス値に基づいて、前記予測対象プロジェクトについてのソースコードメトリクス値の予測値を算出することを特徴とする。

第8の発明は、第6または第7の発明において、 前記難易度保持手段は、前記難易度として、ソフトウェア開発で作成されたドキュメントのあいまい度を保持していることを特徴とする。

第9の発明は、第1から第8までのいずれかの発明において、 各プロジェクトについての開発工程毎の開発工数を保持する開発工数保持手段を更に備え、 前記類似度算出手段は、前記類似度を算出する際、前記開発工数保持手段に保持されている各プロジェクトについての開発工程毎の開発工数を更に用いることを特徴とする。

第10の発明は、第9の発明において、 前記予測値算出手段は、更に、前記開発工数保持手段に保持されている前記高類似プロジェクトについての開発工程毎の開発工数に基づいて、前記予測対象プロジェクトについての開発工程毎の開発工数の予測値を算出することを特徴とする。

第11の発明は、ソフトウェア開発において生じる欠陥の数を予測するソフトウェア欠陥予測方法であって、 各プロジェクトについての開発工程毎の混入欠陥数を予め用意された混入欠陥数保持手段に格納する混入欠陥数格納ステップと、 各プロジェクトについての開発工程毎の検出欠陥数を予め用意された検出欠陥数保持手段に格納する検出欠陥数格納ステップと、 各プロジェクトについての開発工程毎の規模を表す規模値を予め用意された規模値保持手段に格納する規模値格納ステップと、 前記規模値保持手段に保持されている各プロジェクトについての開発工程毎の規模値を用いて、混入欠陥数および検出欠陥数を予測する対象である予測対象プロジェクトと該予測対象プロジェクト以外のプロジェクトとの類似度を算出する類似度算出ステップと、 前記予測対象プロジェクトとの類似度が比較的高いプロジェクトである高類似プロジェクトについての、前記混入欠陥数保持手段に保持されている開発工程毎の混入欠陥数および前記検出欠陥数保持手段に保持されている開発工程毎の検出欠陥数と、前記予測対象プロジェクトと前記高類似プロジェクトとの類似度とに基づいて、前記予測対象プロジェクトについての開発工程毎の混入欠陥数および検出欠陥数の予測値を算出する予測値算出ステップと を含むことを特徴とする。

第12の発明は、ソフトウェア開発において生じる欠陥の数を予測するソフトウェア欠陥予測プログラムであって、 各プロジェクトについての開発工程毎の混入欠陥数を予め用意された混入欠陥数保持手段に格納する混入欠陥数格納ステップと、 各プロジェクトについての開発工程毎の検出欠陥数を予め用意された検出欠陥数保持手段に格納する検出欠陥数格納ステップと、 各プロジェクトについての開発工程毎の規模を表す規模値を予め用意された規模値保持手段に格納する規模値格納ステップと、 前記規模値保持手段に保持されている各プロジェクトについての開発工程毎の規模値を用いて、混入欠陥数および検出欠陥数を予測する対象である予測対象プロジェクトと該予測対象プロジェクト以外のプロジェクトとの類似度を算出する類似度算出ステップと、 前記予測対象プロジェクトとの類似度が比較的高いプロジェクトである高類似プロジェクトについての、前記混入欠陥数保持手段に保持されている開発工程毎の混入欠陥数および前記検出欠陥数保持手段に保持されている開発工程毎の検出欠陥数と、前記予測対象プロジェクトと前記高類似プロジェクトとの類似度とに基づいて、前記予測対象プロジェクトについての開発工程毎の混入欠陥数および検出欠陥数の予測値を算出する予測値算出ステップと をコンピュータのCPUがメモリを利用して実行することを特徴とする。

第13の発明は、第12の発明において、 前記類似度算出ステップでは、前記類似度を算出する際、前記混入欠陥数保持手段に保持されている各プロジェクトについての開発工程毎の混入欠陥数および前記検出欠陥数保持手段に保持されている各プロジェクトについての開発工程毎の検出欠陥数が更に用いられることを特徴とする。

第14の発明は、第13の発明において、 前記類似度算出ステップでは、前記類似度を算出する際、前記混入欠陥数保持手段に保持されている前記予測対象プロジェクトについての実施済みの開発工程の混入欠陥数および前記検出欠陥数保持手段に保持されている前記予測対象プロジェクトについての実施済みの開発工程の検出欠陥数が更に用いられることを特徴とする。

第15の発明は、第12から第14までのいずれかの発明において、 前記予測値算出ステップは、更に、前記予測対象プロジェクトについての開発工程毎の規模値の予測値が算出されることを特徴とする。

第16の発明は、第12から第15までのいずれかの発明において、 各プロジェクトについての開発工程毎の技術的指標に基づいて得られる評価値および環境的指標に基づいて得られる評価値を予め用意された技術要因・環境要因保持手段に格納する技術要因・環境要因格納ステップを更に含み、 前記類似度算出ステップでは、前記類似度を算出する際、前記技術要因・環境要因保持手段に保持されている各プロジェクトについての開発工程毎の技術的指標に基づいて得られる評価値および環境的指標に基づいて得られる評価値が更に用いられることを特徴とする。

第17の発明は、第12から第16までのいずれかの発明において、 各プロジェクトについての開発工程毎の難易度を予め用意された難易度保持手段に格納する難易度格納ステップを更に含み、 前記類似度算出ステップでは、前記類似度を算出する際、前記難易度保持手段に保持されている各プロジェクトについての開発工程毎の難易度が更に用いられることを特徴とする。

第18の発明は、第17の発明において、 前記難易度格納ステップでは、前記難易度として、ソフトウェア開発で作成されたソースコードの難易度を表す指標であるソースコードメトリクス値が前記難易度保持手段に格納され、 前記予測値算出ステップでは、更に、前記難易度保持手段に保持されている前記高類似プロジェクトについてのソースコードメトリクス値に基づいて、前記予測対象プロジェクトについてのソースコードメトリクス値の予測値が算出されることを特徴とする。

第19の発明は、第17または第18の発明において、 前記難易度格納ステップでは、前記難易度として、ソフトウェア開発で作成されたドキュメントのあいまい度が前記難易度保持手段に格納されることを特徴とする。

第20の発明は、第12から第19までのいずれかの発明において、 各プロジェクトについての開発工程毎の開発工数を予め用意された開発工数保持手段に格納する開発工数格納ステップを更に含み、 前記類似度算出ステップでは、前記類似度を算出する際、前記開発工数保持手段に保持されている各プロジェクトについての開発工程毎の開発工数が更に用いられることを特徴とする。

第21の発明は、第20の発明において、 前記予測値算出ステップでは、更に、前記開発工数保持手段に保持されている前記高類似プロジェクトについての開発工程毎の開発工数に基づいて、前記予測対象プロジェクトについての開発工程毎の開発工数の予測値が算出されることを特徴とする。

上記第1の発明によれば、ソフトウェア欠陥予測装置には、予測対象のデータを保持する手段として、開発工程毎の検出欠陥数を保持する検出欠陥数保持手段に加えて開発工程毎の混入欠陥数を保持する混入欠陥数保持手段が設けられている。このため、ソフトウェア開発の各開発工程における検出欠陥数を予測するだけでなく各開発工程における混入欠陥数を予測することが可能となる。このように各開発工程で実際にシステムに混入する欠陥の数を予測することが可能となるので、ソフトウェア開発のプロジェクトを進めるにあたって、より的確に改善対象工程の絞り込みを行うことが可能となる。

上記第2の発明によれば、規模値のデータだけでなく欠陥数のデータも用いて、予測対象プロジェクトと他のプロジェクトとの類似度が算出される。これにより、予測対象プロジェクトと他のプロジェクトとの類似度がより正確に求められる。このように正確に求められた類似度に基づく予測が行われるので、欠陥の数(混入欠陥数,検出欠陥数)の予測値が高い精度で得られる。

上記第3の発明によれば、欠陥の数に関し、実施済みの開発工程の実績値を用いて未実施の開発工程の予測値が求められる。このため、各開発工程で生じる欠陥の数を従来よりも高い精度で予測することが可能となる。これにより、ソフトウェア開発のプロジェクトを進めるにあたって、より的確に改善対象工程の絞り込みを行うことが可能となる。

上記第4の発明によれば、各開発工程における規模値が予測される。これにより、改善対象工程を決定するための判断材料が多くなるので、より的確に改善対象工程の絞り込みを行うことが可能となる。

上記第5の発明によれば、予測対象プロジェクトと他のプロジェクトとの類似度を算出する際、技術要因および環境要因のデータが用いられる。このように技術要因および環境要因のデータが用いられることにより、ソフトウェア開発の各開発工程で生じる欠陥の数が、ソフトウェア開発の特性を考慮して予測される。これにより、ソフトウェア開発のプロジェクトを進めるにあたって、きわめて効果的に改善対象工程の絞り込みを行うことが可能となる。

上記第6の発明によれば、開発工程毎の難易度を考慮して予測対象プロジェクトと他のプロジェクトとの類似度が算出され、その類似度に基づいて、予測対象プロジェクトの各開発工程における欠陥の数が予測される。これにより、より効果的に改善対象工程の絞り込みを行うことが可能となる。

上記第7の発明によれば、ソースコードの難易度を表す指標であるソースコードメトリクス値の予測が行われる。これにより、実装工程を改善対象工程とすべきか否かをより的確に判断することが可能となる。

上記第8の発明によれば、ソフトウェア開発の各開発工程で作成されるドキュメントのあいまい度のデータを用いて予測対象プロジェクトと他のプロジェクトとの類似度が算出され、その類似度に基づいて、予測対象プロジェクトの各開発工程における欠陥の数が予測される。一般にドキュメントのあいまい度と欠陥の数との間には比較的高い相関があるので、あいまい度のデータを用いることによって、より高い精度で欠陥の数を予測することが可能となる。これにより、より効果的に改善対象工程の絞り込みを行うことが可能となる。

上記第9の発明によれば、予測対象プロジェクトと他のプロジェクトとの類似度を算出する際、開発工程毎の開発工数のデータが用いられる。一般に、或る一定の規模のプロジェクトに着目したとき、開発工数を多くするほどソフトウェアの品質は向上する。すなわち、規模が一定であれば、開発工数が多いほど欠陥の数は少なくなる傾向にある。このように開発工数と欠陥の数との間には比較的高い相関があるので、開発工数のデータを用いることによって、より高い精度で欠陥の数を予測することが可能となる。これにより、より効果的に改善対象工程の絞り込みを行うことが可能となる。

上記第10の発明によれば、各開発工程における開発工数が予測される。これにより、改善対象工程を決定するための判断材料が多くなるので、より的確に改善対象工程の絞り込みを行うことが可能となる。

上記第11の発明によれば、上記第1の発明と同様の効果をソフトウェア欠陥予測方法の発明において奏することができる。

上記第12から上記第21までの発明によれば、それぞれ上記第1から上記第10までの発明と同様の効果をソフトウェア欠陥予測プログラムの発明において奏することができる。

本発明の第1の実施形態に係るソフトウェア欠陥予測装置を含むシステム全体の概略構成図である。

上記第1の実施形態において、ソフトウェア欠陥予測装置のハードウェア構成を示すブロック図である。

上記第1の実施形態において、混入欠陥数テーブルのレコードフォーマットの一例を示す図である。

上記第1の実施形態において、検出欠陥数テーブルのレコードフォーマットの一例を示す図である。

上記第1の実施形態において、規模値テーブルのレコードフォーマットの一例を示す図である。

上記第1の実施形態におけるソフトウェア欠陥予測装置の機能構成を示す機能ブロック図である。

上記第1の実施形態において、各テーブルへのデータの登録の手順を示すフローチャートである。

上記第1の実施形態において、協調フィルタリングの手法を用いて欠陥予測処理を行う際の入力データについて説明するための図である。

上記第1の実施形態において、ソフトウェア欠陥予測装置で行われる欠陥予測処理の処理手順を示すフローチャートである。

上記第1の実施形態において、高類似プロジェクトの個数について説明するための図である。

上記第1の実施形態において、高類似プロジェクトの個数について説明するための図である。

上記第1の実施形態におけるプロジェクト−メトリクステーブルの構成を示す図である。

上記第1の実施形態において、欠陥予測処理について説明するための、規模値テーブル内のレコードの内容を示す図である。

上記第1の実施形態において、欠陥予測処理について説明するための、規模値テーブル内のレコードの内容を示す図である。

上記第1の実施形態において、欠陥予測処理について説明するための、プロジェクト−メトリクステーブルの内容を示す図である。

上記第1の実施形態において、欠陥予測処理について説明するための、検出欠陥数テーブル内のレコードの内容を示す図である。

上記第1の実施形態において、欠陥予測処理について説明するための、検出欠陥数テーブル内のレコードの内容を示す図である。

上記第1の実施形態において、欠陥予測処理について説明するための、検出欠陥数テーブル内のレコードの内容を示す図である。

上記第1の実施形態において、欠陥予測処理について説明するための、検出欠陥数テーブル内のレコードの内容を示す図である。

上記第1の実施形態において、欠陥予測処理について説明するための、検出欠陥数テーブル内のレコードの内容を示す図である。

本発明の第2の実施形態に係るソフトウェア欠陥予測装置のハードウェア構成を示すブロック図である。

上記第2の実施形態において、開発工数テーブルのレコードフォーマットの一例を示す図である。

上記第2の実施形態において、ソースコードメトリクステーブルのレコードフォーマットの一例を示す図である。

上記第2の実施形態において、技術要因・環境要因テーブルのレコードフォーマットの一例を示す図である。

上記第2の実施形態におけるソフトウェア欠陥予測装置の機能構成を示す機能ブロック図である。

上記第2の実施形態において、各テーブルへのデータの登録の手順を示すフローチャートである。

上記第2の実施形態におけるプロジェクト−メトリクステーブルの構成を示す図である。

上記第2の実施形態の変形例において、あいまい度テーブルのレコードフォーマットの一例を示す図である。

以下、添付図面を参照しつつ本発明の実施形態について説明する。なお、ソフトウェア開発の開発工程は、一例を挙げると、「要求定義」,「基本設計」,「詳細設計」,「実装(プログラミング等)」,「単体テスト」,「結合テスト」,および「総合テスト」の7つの工程から成っている。しかしながら、以下においては、説明を簡単にするため、各実施形態におけるソフトウェア開発の開発工程は「要求定義」,「設計」,「実装」,および「テスト」の4つの工程から成るものと仮定する。また、それらの4つの工程の終了後に、開発したシステムをユーザのコンピュータに導入する「ユーザリリース」と呼ばれるフェーズがあるものとする。

<1.第1の実施形態> <1.1 概略構成> 図1は、本発明の第1の実施形態に係るソフトウェア欠陥予測装置を含むシステム全体の概略構成図である。このシステムは、サーバ機7と複数のパソコン8とによって構成されている。サーバ機7および各パソコン8は、LAN9によって互いに接続されている。サーバ機7は、各パソコン8からの要求に応じた処理の実行や複数のパソコン8が共用するためのファイル,データベースの格納などを行う。また、サーバ機7は、ソフトウェア開発の各開発工程で生じる欠陥数などを予測する処理を行う。従って、以下においては、このサーバ機7のことを「ソフトウェア欠陥予測装置」という。

図2は、ソフトウェア欠陥予測装置7のハードウェア構成を示すブロック図である。このソフトウェア欠陥予測装置7は、CPU10と補助記憶装置20と表示部30と入力部40とメモリ50とネットワークインタフェース部60とを備えている。CPU10は、与えられた命令に従い演算処理を行う。補助記憶装置20は、各種データを記憶する。この補助記憶装置20には、プログラム格納部21とデータベース22とが含まれている。プログラム格納部21には、ソフトウェア欠陥予測プログラム210が格納されている。データベース22には、混入欠陥数テーブル221,検出欠陥数テーブル222,および規模値テーブル223が格納されている。表示部30は、例えば、オペレータが作業を行うための各種画面を表示する。入力部40は、マウスやキーボードによるオペレータからの入力を受け付ける。メモリ50には、CPU10の演算処理に必要なデータが一時的に格納される。ネットワークインタフェース部60は、LAN9を介してこのソフトウェア欠陥予測装置7とパソコン8との間でのデータ通信が可能となるように機能する。

ソフトウェア欠陥予測プログラム210の実行が指示されると、補助記憶装置20に格納されているソフトウェア欠陥予測プログラム210がメモリ50に読み出され、そのメモリ50に読み出されたソフトウェア欠陥予測プログラム210をCPU10が実行することにより、ソフトウェア開発の各開発工程で生じる欠陥数などを予測する処理(以下、「欠陥予測処理」という。)が実行される。なお、ソフトウェア欠陥予測プログラム210は、CD−ROM,DVD−ROM,フラッシュメモリ等の記録媒体に記録された形態あるいはネットワークを介したダウンロードの形態で提供される。

ところで、欠陥予測処理では、欠陥数(混入欠陥数、検出欠陥数)の予測が行われるのみならず、ソフトウェア開発に関する各種評価項目の値の予測が行われる。なお、以下においては、欠陥数を含む各種評価項目のことを「メトリクス」という。本実施形態においては、欠陥予測処理によって予測対象プロジェクト(典型的には、開発中のプロジェクト)の各開発工程における各メトリクスの値の予測が行われる際、協調フィルタリングの手法が採用される。一般に協調フィルタリングはユーザ(消費者)の嗜好を推測する際に用いられる手法であり、この手法によれば、或るユーザの嗜好は当該ユーザに類似するユーザの情報に基づいて推測される。従って、本実施形態においては、予測対象プロジェクトについての各メトリクスの値(予測値)は、当該予測対象プロジェクトに類似する他のプロジェクトの情報を用いて予測される。

<1.2 テーブル> 次に、補助記憶装置20内のデータベース22に保持されているテーブル(混入欠陥数テーブル221,検出欠陥数テーブル222,および規模値テーブル223)について説明する。

図3は、混入欠陥数テーブル221のレコードフォーマットの一例を示す図である。混入欠陥数テーブル221には、項目名をそれぞれ「名称」,「バージョン」,「予測工程」,「要求定義混入欠陥数」,「予実フラグ(a1)」,「設計混入欠陥数」,「予実フラグ(a2)」,「実装混入欠陥数」,および「予実フラグ(a3)」とする複数の項目が含まれている。なお、各予実フラグには、他の予実フラグと区別するための符号を付している。

混入欠陥数テーブル221の各項目のフィールド(個々のデータが格納される領域)には、それぞれ以下のような内容のデータが格納される。「名称」には、ソフトウェア開発のプロジェクトの名称が格納される。「バージョン」には、プロジェクトのバージョン値が格納される。「予測工程」には、混入欠陥数の予測が行われた工程を示す名称が格納される。例えば、実装が開始される際に混入欠陥数の予測が行われた場合、それによって得られたレコードの「予測工程」のフィールドには「実装」という名称が格納される。「要求定義混入欠陥数」には、要求定義工程でシステムに混入した欠陥の数(実績値)もしくは要求定義工程でシステムに混入すると予測される欠陥の数(予測値)が格納される。「予実フラグ(a1)」には、「要求定義混入欠陥数」に格納されている値が実績値であるのか予測値であるのかを示すフラグが格納される。「設計混入欠陥数」には、設計工程でシステムに混入した欠陥の数(実績値)もしくは設計工程でシステムに混入すると予測される欠陥の数(予測値)が格納される。「予実フラグ(a2)」には、「設計混入欠陥数」に格納されている値が実績値であるのか予測値であるのかを示すフラグが格納される。「実装混入欠陥数」には、実装工程でシステムに混入した欠陥の数(実績値)もしくは実装工程でシステムに混入すると予測される欠陥の数(予測値)が格納される。「予実フラグ(a3)」には、「実装混入欠陥数」に格納されている値が実績値であるのか予測値であるのかを示すフラグが格納される。

なお、混入欠陥数テーブル221以外のテーブルにおいても、「名称」にはソフトウェア開発のプロジェクトの名称が格納され、「バージョン」にはプロジェクトのバージョン値が格納され、「予測工程」にはテーブル内の項目の値の予測が行われた工程を示す名称が格納され、「予実フラグ」には、直前の項目のフィールドに格納されている値が実績値であるのか予測値であるのかを示すフラグが格納される。従って、混入欠陥数テーブル221以外の後述するテーブルに関しては、これらの項目に関する説明を省略する。また、予実フラグに関し、後述する図13〜図20では、説明の便宜上、フラグに代えて「実績」という文字もしくは「予測」という文字を記している。

図4は、検出欠陥数テーブル222のレコードフォーマットの一例を示す図である。検出欠陥数テーブル222には、項目名をそれぞれ「名称」,「バージョン」,「予測工程」,「要求定義検出欠陥数」,「予実フラグ(b1)」,「設計検出欠陥数」,「予実フラグ(b2)」,「実装検出欠陥数」,および「予実フラグ(b3)」とする複数の項目が含まれている。

検出欠陥数テーブル222の各項目(「名称」などの上記で説明した項目を除く)のフィールドには、それぞれ以下のような内容のデータが格納される。「要求定義検出欠陥数」には、要求定義工程で検出された欠陥の数(実績値)もしくは要求定義工程で検出されると予測される欠陥の数(予測値)が格納される。「設計検出欠陥数」には、設計工程で検出された欠陥の数(実績値)もしくは設計工程で検出されると予測される欠陥の数(予測値)が格納される。「実装検出欠陥数」には、実装工程で検出された欠陥の数(実績値)もしくは実装工程で検出されると予測される欠陥の数(予測値)が格納される。

図5は、規模値テーブル223のレコードフォーマットの一例を示す図である。規模値テーブル223には、項目名をそれぞれ「名称」,「バージョン」,「予測工程」,「要求定義規模」,「予実フラグ(c1)」,「設計規模」,「予実フラグ(c2)」,「実装規模」,「予実フラグ(c3)」,「テスト規模」,および「予実フラグ(c4)」とする複数の項目が含まれている。

規模値テーブル223の各項目(「名称」などの上記で説明した項目を除く)のフィールドには、それぞれ以下のような内容のデータが格納される。「要求定義規模」には、要求定義工程の規模の大きさを特定する値(実績値もしくは予測値)が格納される。「設計規模」には、設計工程の規模の大きさを特定する値(実績値もしくは予測値)が格納される。「実装規模」には、実装工程の規模の大きさを特定する値(実績値もしくは予測値)が格納される。「テスト規模」には、テスト工程の規模の大きさを特定する値(実績値もしくは予測値)が格納される。

<1.3 機能構成> 図6は、本実施形態におけるソフトウェア欠陥予測装置7の機能構成を示す機能ブロック図である。このソフトウェア欠陥予測装置7には、データ登録手段71,類似度算出手段72,予測値算出手段73,混入欠陥数保持手段として機能する混入欠陥数テーブル221,検出欠陥数保持手段として機能する検出欠陥数テーブル222,および規模値保持手段として機能する規模値テーブル223が含まれている。類似度算出手段72には、正規化手段721と類似度計算手段722とが含まれている。

データ登録手段71は、混入欠陥数テーブル221,検出欠陥数テーブル222,および規模値テーブル223に対して、データの登録(レコードの追加・変更・削除)を行う。後述する欠陥予測処理を行うために、例えば各開発工程の開始前や終了後に、このデータ登録手段71によって各テーブルへのデータの登録が行われる。本実施形態においては、図7に示すように、混入欠陥数の登録(ステップS110),検出欠陥数の登録(ステップS120),および規模値の登録(ステップS130)が順次に行われる。

類似度算出手段72および予測値算出手段73は、協調フィルタリングの手法を用いた欠陥予測処理が行われる際に、それぞれ以下のような処理を行う。類似度算出手段72は、混入欠陥数テーブル221,検出欠陥数テーブル222,および規模値テーブル223に格納されているデータに基づいて、予測対象プロジェクトと他のプロジェクトとの類似度を算出する。その際、正規化手段721は、各メトリクスの値(一例を挙げると、規模値テーブル223に格納されている要求定義規模の値)の正規化を行う。また、類似度計算手段722は、後述する所定の計算式を用いて、予測対象プロジェクトと他のプロジェクトとの類似度を求める。予測値算出手段73は、混入欠陥数テーブル221,検出欠陥数テーブル222,および規模値テーブル223に格納されているデータと類似度算出手段72によって算出された類似度とに基づいて、後述する所定の計算式を用いて、各メトリクスの予測値を算出する。

<1.4 欠陥予測処理> <1.4.1 処理の流れ> 本実施形態における欠陥予測処理について説明する。欠陥予測処理が行われる際、すなわち、各開発工程における各メトリクスの値の予測が行われる際、図8に示すようなm行×n列(mはプロジェクトの数、nはメトリクスの数)の仮想的なテーブルのデータが入力データとして用いられる。図8に関し、p_i(iは1以上m以下の整数)はi番目のプロジェクトを表し、m_j(jは1以上n以下の整数)はj番目のメトリクスを表し、v_i,jはプロジェクトp_iにおけるメトリクスm_jの値を表している。なお、以下においては、説明の便宜上、図8に示す仮想的なテーブルのことを「プロジェクト−メトリクステーブル」という。プロジェクト−メトリクステーブルには符号230を付す。

以下、予測対象プロジェクトをp_aとし、当該予測対象プロジェクトp_aにおけるb番目のメトリクスm_bの値(予測値)v_a,bの求め方について図9を参照しつつ説明する。図9は、本実施形態に係るソフトウェア欠陥予測装置7で行われる欠陥予測処理の処理手順を示すフローチャートである。ソフトウェア欠陥予測装置7では、まず、パソコン(クライアント)8からの予測値の算出の要求が受け付けられる(ステップS210)。以下、このステップS210で予測値の算出が要求されたメトリクスのことを「予測対象メトリクス」という。

次に、予測対象メトリクスm_bに関して、測定値を持つプロジェクトが存在するか否かの判定が行われる(ステップS220)。その際、予測対象メトリクスm_bのデータを保持しているテーブルが参照される。例えば、予測対象メトリクスm_bが実装混入欠陥数であれば、混入欠陥数テーブル221が参照される。また、例えば、予測対象メトリクスm_bが要求定義検出欠陥数であれば、検出欠陥数テーブル222が参照される。ステップS220での判定の結果、測定値を持つプロジェクトが存在していれば、処理はステップS230に進む。一方、測定値を持つプロジェクトが存在していなければ、予測対象メトリクスm_bの予測値を求めることなく処理は終了する。

図8に示す例ではソフトウェア開発の各プロジェクトを評価するための指標としてn個のメトリクスが設けられているが、それらメトリクス毎に値の範囲が異なっている。例えば「或るメトリクスについては、最小値が0かつ最大値が10であって、別のメトリクスについては、最小値が0かつ最大値が1000である」というケースがある。このような場合、メトリクス値をそのまま用いてプロジェクト間の類似度を求めると、正しい類似度が求められないことがある。そこで、全てのメトリクス値が0から1までの範囲内の値となるように、メトリクス値の正規化が行われる(ステップS230)。具体的には、メトリクス値v_i,j(i番目のプロジェクトp_iのj番目のメトリクスm_jの値)の正規化後の値nrm(v_i,j)は、次式(1)によって求められる。

上式(1)において、max(P_j)はj番目のメトリクスm_jの値の最大値を表し、min(P_j)はj番目のメトリクスm_jの値の最小値を表す。但し、最大値および最小値は、j番目のメトリクスm_jについての測定値を持つプロジェクトのデータの中から抽出される。

メトリクス値の正規化が行われた後、類似度の計算が行われる(ステップS240)。詳しくは、ステップS230で求められた正規化後のメトリクス値を用いて、予測対象プロジェクトp_aと他のプロジェクトp_iとの間の類似度sim(P_a,P_i)が求められる。具体的には、類似度sim(P_a,P_i)は、次式(2)によって求められる。

上式(2)において、j∈Ma∩Miは、プロジェクトp_aとプロジェクトp_iの双方が測定値を持つメトリクスのデータを用いることを表している。

ステップS240で予測対象プロジェクトp_aと他のプロジェクトp_iとの間の類似度sim(P_a,P_i)が求められた後、予測対象メトリクスm_bの予測値の算出が行われる(ステップS250)。この予測値の算出は、予測対象プロジェクトp_aとの間の類似度が高いプロジェクト(以下、「高類似プロジェクト」という。)のデータを用いて行われる。なお、高類似プロジェクトについては、1つのプロジェクトとは限らず、複数のプロジェクトの場合もある。高類似プロジェクトの個数についての説明は後述する。予測対象プロジェクトp_aについての予測対象メトリクスm_bの予測値v_a,bは、具体的には、次式(3)によって求められる。

上式(3)において、j∈k−nearestProjectsは高類似プロジェクトについての予測対象メトリクスm_bのデータを用いることを表し、amp(P_a,P_i)は次式(4)で算出される補正係数を表す。

上式(4)において、hは予測対象プロジェクトp_aとプロジェクトp_iの双方が測定値を持つメトリクスの数を表し、r_jはnrm(v_a,j)/nrm(v_i,j)で定義される値を表す。

以上のようにして予測対象プロジェクトp_aについての予測対象メトリクスm_bの予測値v_a,bが算出されると、欠陥予測処理は終了する。なお、本実施形態においては、ステップS230およびステップS240によって類似度算出ステップが実現され、ステップS250によって予測値算出ステップが実現されている。

<1.4.2 高類似プロジェクトの個数> ここで、本実施形態における高類似プロジェクトの個数について説明する。本実施形態においては、予測対象プロジェクトとそれ以外の各プロジェクトとの間の類似度が算出された後、高類似プロジェクトとして扱うプロジェクトの個数を変化させながら、それぞれの個数での予測値の算出が行われる。そして、「予測値」と「高類似プロジェクトについての実績値」との残差平方和の平均値が最小となる個数(高類似プロジェクトの個数)での予測値が、上述したステップS250での算出結果として提示される。

例えば、予測対象プロジェクトとの間の類似度が高いプロジェクトとして、図10に示すような3つのプロジェクト(「PRJ−1」,「PRJ−2」,および「PRJ−3」とする)が存在していると仮定する。このような場合、高類似プロジェクトのデータとしてPRJ−1のみのデータを用いたケース(最も類似度が高いプロジェクトのデータのみを用いたケース)(図11のケースA),高類似プロジェクトのデータとしてPRJ−1とPRJ−2のデータを用いたケース(最も類似度が高いプロジェクトのデータと2番目に類似度が高いプロジェクトのデータとを用いたケース)(図11のケースB),および高類似プロジェクトのデータとしてPRJ−1とPRJ−2とPRJ−3のデータを用いたケース(最も類似度が高いプロジェクトのデータ,2番目に類似度が高いプロジェクトのデータ,および3番目に類似度が高いプロジェクトのデータを用いたケース)(図11のケースC)のそれぞれについて、予測値が求められる。更に、それぞれのケースについて、上述した残差平方和の平均値が求められる。例えば、図11においてケースCに着目すると、予測値は6.0となっている。図10より、PRJ−1についての実績値は5.0となっており、PRJ−2についての実績値は4.0となっており、PRJ−3についての実績値は10.0となっている。残差平方和は、「6.0と5.0との差の2乗」と「6.0と4.0との差の2乗」と「6.0と10.0との差の2乗」との和であるので、21.0となる。ケースCでは高類似プロジェクトの個数は3であるので、残差平方和の平均値は7.0となる。以上のようにして、それぞれのケースについて、残差平方和の平均値が求められる。図11に示す例では、「実績値と予測値との残差平方和の平均値」は、ケースBが最も低くなっている。従って、予測対象プロジェクトについての予測対象メトリクスの予測値は、ケースBの予測値である3.0となる。

<1.4.3 各テーブルのデータの使用のされ方> 次に、本実施形態において、欠陥予測処理の際に各テーブルのデータがどのように使用されるのかについて説明する。本実施形態においては、上述したように協調フィルタリングの手法を用いて各メトリクス(ソフトウェア開発に関する各種評価項目)の予測値が求められるところ、各テーブル(混入欠陥数テーブル221,検出欠陥数テーブル222,および規模値テーブル223)における「名称」と「バージョン」との結合が1つのプロジェクトとみなされる。従って、プロジェクトの名称が同じであっても、バージョンが異なれば、欠陥予測処理においては異なるプロジェクトとして扱われる。

また、本実施形態においては、混入欠陥数テーブル221に含まれる「要求定義混入欠陥数」,「設計混入欠陥数」,「実装混入欠陥数」、検出欠陥数テーブル222に含まれる「要求定義検出欠陥数」,「設計検出欠陥数」,「実装検出欠陥数」、および規模値テーブル223に含まれる「要求定義規模」,「設計規模」,「実装規模」,「テスト規模」がメトリクスとして扱われる。従って、仮想的なテーブルとして図12に示すようなプロジェクト−メトリクステーブル230を用いた欠陥予測処理が行われる。

ところで、或るプロジェクトについての欠陥予測処理を行うためには、当該プロジェクトに関する何らかのデータがテーブルに登録されていなければならない。そこで、本実施形態においては、各プロジェクトの要求定義工程の開始時において、規模値テーブル223に対して各開発工程における規模の予測値が登録される。なお、ここでは、「名称=“E−PRJ”」かつ「バージョン=“1.0”」で特定されるプロジェクトが予測対象プロジェクトであると仮定する。予測対象プロジェクトの要求定義工程の開始時には、ユーザがデータ登録手段71を用いて規模値テーブル223へのデータの登録を行うことにより、規模値テーブル223内のレコードの内容が図13に示すような内容から図14に示すような内容に変化する。この例では、予測対象プロジェクトについての「要求定義規模」,「設計規模」,「実装規模」,および「テスト規模」の予測値としてそれぞれ「10」,「65」,「55」,および「15」という値が登録されている。このようにして予測対象プロジェクトについての規模値のデータが登録されることにより、プロジェクト−メトリクステーブル230の内容は例えば図15に示すようなものとなる。これにより、予測対象プロジェクトと他のプロジェクトとの間の類似度を求めることが可能となる。

なお、図15に示すプロジェクト−メトリクステーブル230には、メトリクス値の欄が空欄になっている部分がある。このような空欄部分はメトリクス値が欠損値であることを意味しているが、協調フィルタリングにおいては未欠損の値のみを用いて計算が行われる。従って、一部のデータが欠損していても、欠陥予測処理は行われる。このように協調フィルタリングにおいては2つのプロジェクトの双方が値を持つメトリクスのデータのみを用いて類似度の計算が行われるので、多くの欠損値が含まれている場合にも予測値を求めることが可能である。

予測対象プロジェクトの要求定義工程の開始時には、検出欠陥数テーブル222内のレコードの内容は、例えば図16に示すような内容となっている。すなわち、検出欠陥数テーブル222には、予測対象プロジェクトのレコードは含まれていない。このような状態において、上述したように規模値のデータを用いて予測対象プロジェクトと他のプロジェクトとの間の類似度が算出される。そして、予測対象プロジェクトと高類似プロジェクトとの類似度および検出欠陥数テーブル222に保持されている高類似プロジェクトについてのデータに基づいて、予測対象プロジェクトについての各開発工程における検出欠陥数の予測値が求められる。その後、ユーザは、その予測値のデータをデータ登録手段71を用いて検出欠陥数テーブル222に登録する。これにより、検出欠陥数テーブル222内のレコードの内容は、例えば図17に示すような内容となる。同様にして、予測対象プロジェクトについての各開発工程における混入欠陥数の予測値が求められ、その予測値のデータが混入欠陥数テーブル221に登録される。すなわち、本実施形態においては、欠陥予測処理によって、各開発工程における検出欠陥数の予測が行われるのみならず各開発工程における混入欠陥数の予測が行われる。

要求定義工程が終了すると、要求定義に関するメトリクス(例えば、検出欠陥数テーブル222内の要求定義検出欠陥数)の実績値が得られる。ユーザは、この実績値を各テーブルに登録する。これにより、要求定義工程の次の工程である設計工程の開始時には、例えば、検出欠陥数テーブル222内のレコードの内容は図18に示すような内容となる。図18に示す検出欠陥数テーブル222には、予測対象プロジェクトについての要求定義検出欠陥数の実績値のデータが格納されている。この図18に示す例からは、予測対象プロジェクトに関し、「要求定義工程開始時には要求定義検出欠陥数は“100”と予測されていたが、実際には要求定義検出欠陥数は“90”であった」ということが把握される。このように、設計工程の開始時は、予測対象プロジェクトについての要求定義検出欠陥数の実績値のデータが既に検出欠陥数テーブル222に登録されている。従って、設計工程の開始時には、規模値のデータだけでなく要求定義検出欠陥数の実績値のデータも用いて、予測対象プロジェクトと他のプロジェクトとの類似度を求めることが可能となる。このようにして求められた類似度に基づいて未実施の開発工程に関する各メトリクスの値を予測することにより、従来よりも高い精度で予測値が求められる。

設計工程の開始時に行われた欠陥予測処理の結果に基づいて検出欠陥数テーブル222にデータの登録が行われると、検出欠陥数テーブル222内のレコードの内容は例えば図19に示すような内容となる。この図19に示す例からは、予測対象プロジェクトに関し、「要求定義工程開始時には設計検出欠陥数は“65”と予測されていたが、設計工程開始時には設計検出欠陥数は“55”と予測されている」ということが把握される。このように、各開発工程が終了する毎に未実施の開発工程に関するメトリクスの値を予測し直すことが可能となる。

予測対象プロジェクトに関してユーザリリースまで終了すると、検出欠陥数テーブル222内のレコードの内容は例えば図20に示すような内容となる。この図20より、各開発工程が終了する毎に実施済みの開発工程についての実績値の登録が行われるとともに未実施の開発工程についての予測値の算出が行われていることが把握される。

<1.5 効果> 本実施形態によれば、ソフトウェア欠陥予測装置7には、協調フィルタリングの手法を用いた予測値算出対象のメトリクスの値を格納するテーブルとして、開発工程毎の検出欠陥数を保持する検出欠陥数テーブル222に加えて開発工程毎の混入欠陥数を保持する混入欠陥数テーブル221が設けられている。このため、ソフトウェア開発の各開発工程における検出欠陥数を予測するだけでなく各開発工程における混入欠陥数を予測することが可能となる。このように各開発工程で実際にシステムに混入する欠陥の数を予測することが可能となるので、ソフトウェア開発のプロジェクトを進めるにあたって、より的確に改善対象工程の絞り込みを行うことが可能となる。

また、本実施形態によれば、混入欠陥数テーブル221や検出欠陥数テーブル222には、プロジェクト単位の欠陥数のデータではなく開発工程毎の欠陥数のデータが保持されている。このため、ソフトウェア開発の途中において、実施済みの開発工程の実績値を用いて未実施の開発工程の予測値を求めることが可能となる。これにより、各開発工程で生じる欠陥の数を従来よりも高い精度で予測することが可能となる。この観点からも、ソフトウェア開発のプロジェクトを進めるにあたって、より的確に改善対象工程の絞り込みを行うことが可能となる。

以上のように、本実施形態によれば、ソフトウェア開発の各開発工程で生じる欠陥の数を高い精度で予測し、より効率的な改善対象工程の絞り込みを行うための情報を提示できるシステムが実現される。

<2.第2の実施形態> <2.1 概略構成> 本発明の第2の実施形態に係るソフトウェア欠陥予測装置を含むシステム全体の構成については、上記第1の実施形態(図1参照)と同様であるので説明を省略する。図21は、本実施形態に係るソフトウェア欠陥予測装置7のハードウェア構成を示すブロック図である。図2および図21から把握されるように、本実施形態と上記第1の実施形態とでは、ハードウェアそのものの構成については同じである。但し、本実施形態においては、補助記憶装置20内のデータベース22に、上記第1の実施形態で設けられているテーブルに加えて、開発工数テーブル224,ソースコードメトリクステーブル225,および技術要因・環境要因テーブル226が設けられている。

<2.2 テーブル> 次に、補助記憶装置20内のデータベース22に保持されているテーブルについて説明する。なお、混入欠陥数テーブル221,検出欠陥数テーブル222,および規模値テーブル223については、上記第1の実施形態と同様であるので、説明を省略する。

図22は、開発工数テーブル224のレコードフォーマットの一例を示す図である。開発工数テーブル224には、項目名をそれぞれ「名称」,「バージョン」,「予測工程」,「要求定義工数」,「予実フラグ(d1)」,「設計工数」,「予実フラグ(d2)」,「実装工数」,「予実フラグ(d3)」,「テスト工数」,および「予実フラグ(d4)」とする複数の項目が含まれている。

開発工数テーブル224の各項目(「名称」などの上記で説明した項目を除く)のフィールドには、それぞれ以下のような内容のデータが格納される。「要求定義工数」には、要求定義工程に要した開発工数(実績値)もしくは要求定義工程に要すると予測される開発工数(予測値)が格納される。「設計工数」には、設計工程に要した開発工数(実績値)もしくは設計工程に要すると予測される開発工数(予測値)が格納される。「実装工数」には、実装工程に要した開発工数(実績値)もしくは実装工程に要すると予測される開発工数(予測値)が格納される。「テスト工数」には、テスト工程に要した開発工数(実績値)もしくはテスト工程に要すると予測される開発工数(予測値)が格納される。

図23は、ソースコードメトリクステーブル225のレコードフォーマットの一例を示す図である。ソースコードメトリクステーブル225には、項目名をそれぞれ「名称」,「バージョン」,「予測工程」,「制御文数」,「予実フラグ(e1)」,「複雑度」,および「予実フラグ(e2)」とする複数の項目が含まれている。なお、ソースコードメトリクスとは、コンピュータに実行させるプログラムのソースコードの品質を定量的に評価するための指標のことである。本実施形態においては、ソースコードメトリクスとして、制御文数および複雑度が用いられる。

ソースコードメトリクステーブル225の各項目(「名称」などの上記で説明した項目を除く)のフィールドには、それぞれ以下のような内容のデータが格納される。「制御文数」には、ソースコードに含まれている制御文(例えば、GOTO文)の数(実績値)もしくはソースコードに含まれると予測される制御文の数(予測値)が格納される。「複雑度」には、ソースコードの複雑さ(例えば、分岐やループの多さ)を特定する値(実績値もしくは予測値)が格納される。

図24は、技術要因・環境要因テーブル226のレコードフォーマットの一例を示す図である。技術要因・環境要因テーブル226には、項目名をそれぞれ「名称」,「バージョン」,「予測工程」,「技術要因」,および「環境要因」とする複数の項目が含まれている。

技術要因・環境要因テーブル226の各項目(「名称」などの上記で説明した項目を除く)のフィールドには、それぞれ以下のような内容のデータが格納される。「技術要因」には、ソフトウェア開発の技術的な難しさに関する複数の指標の評価値に基づいて得られる値が格納される。「環境要因」には、ソフトウェア開発に関わる要員(作業者)の経験や能力に関する指標の評価値に基づいて得られる値が格納される。

技術要因としては、例えば、「ソースコードの再利用のしやすさ」,「内部処理の複雑さ」,「移植性の高さ」などが挙げられる。これら各要因にはそれぞれ重み付け用の係数が定められている。そして、各要因の評価値と重み付け用の係数との積の総和が、技術要因・環境要因テーブル226の「技術要因」のフィールドに格納される。

環境要因としては、例えば、「開発経験の有無」,「モチベーション」,「リーダーの能力」などが挙げられる。これら各要因にはそれぞれ重み付け用の係数が定められている。そして、各要因の評価値と重み付け用の係数との積の総和が、技術要因・環境要因テーブル226の「環境要因」のフィールドに格納される。

<2.3 機能構成> 図25は、本実施形態におけるソフトウェア欠陥予測装置7の機能構成を示す機能ブロック図である。このソフトウェア欠陥予測装置7には、データ登録手段71,類似度算出手段72,予測値算出手段73,混入欠陥数保持手段として機能する混入欠陥数テーブル221,検出欠陥数保持手段として機能する検出欠陥数テーブル222,規模値保持手段として機能する規模値テーブル223,開発工数保持手段として機能する開発工数テーブル224,難易度保持手段として機能するソースコードメトリクステーブル225,および技術要因・環境要因保持手段として機能する技術要因・環境要因テーブル226が含まれている。類似度算出手段72には、正規化手段721と類似度計算手段722とが含まれている。

データ登録手段71は、混入欠陥数テーブル221,検出欠陥数テーブル222,規模値テーブル223,開発工数テーブル224,ソースコードメトリクステーブル225,および技術要因・環境要因テーブル226に対して、データの登録(レコードの追加・変更・削除)を行う。上記第1の実施形態と同様、例えば各開発工程の開始前や終了後に、このデータ登録手段71によって各テーブルへのデータの登録が行われる。本実施形態においては、図26に示すように、混入欠陥数の登録(ステップS310),検出欠陥数の登録(ステップS320),規模値の登録(ステップS330),開発工数の登録(ステップS340),ソースコードメトリクスの登録(ステップS350),技術要因・環境要因の登録(ステップS360)が順次に行われる。

類似度算出手段72および予測値算出手段73は、協調フィルタリングの手法を用いた欠陥予測処理が行われる際に、それぞれ以下のような処理を行う。類似度算出手段72は、混入欠陥数テーブル221,検出欠陥数テーブル222,規模値テーブル223,開発工数テーブル224,ソースコードメトリクステーブル225,および技術要因・環境要因テーブル226に格納されているデータに基づいて、予測対象プロジェクトと他のプロジェクトとの類似度を算出する。その際、正規化手段721は、各メトリクスの値の正規化を行う。また、類似度計算手段722は、上記第1の実施形態と同様の計算式を用いて、予測対象プロジェクトと他のプロジェクトとの類似度を求める。予測値算出手段73は、混入欠陥数テーブル221,検出欠陥数テーブル222,規模値テーブル223,開発工数テーブル224,およびソースコードメトリクステーブル225に格納されているデータと類似度算出手段72によって算出された類似度とに基づいて、上記第1の実施形態と同様の計算式を用いて、各メトリクスの予測値を算出する。

<2.4 欠陥予測処理> 欠陥予測処理の流れおよび高類似プロジェクトの個数については、上記第1の実施形態と同様であるので、説明を省略する。以下、本実施形態において、欠陥予測処理の際に各テーブルのデータがどのように使用されるのかについて説明する。

本実施形態においては、混入欠陥数テーブル221に含まれる「要求定義混入欠陥数」,「設計混入欠陥数」,「実装混入欠陥数」、検出欠陥数テーブル222に含まれる「要求定義検出欠陥数」,「設計検出欠陥数」,「実装検出欠陥数」、規模値テーブル223に含まれる「要求定義規模」,「設計規模」,「実装規模」,「テスト規模」、開発工数テーブル224に含まれる「要求定義工数」,「設計工数」,「実装工数」,「テスト工数」、ソースコードメトリクステーブル225に含まれる「制御文数」,「複雑度」、および技術要因・環境要因テーブル226に含まれる「技術要因」,「環境要因」がメトリクスとみなされる。従って、仮想的なテーブルとして図27に示すようなプロジェクト−メトリクステーブル230を用いた欠陥予測処理が行われる。

本実施形態においては、各プロジェクトの要求定義工程の開始時に、規模値テーブル223および技術要因・環境要因テーブル226へのデータの登録が行われる。予測対象プロジェクトの要求定義工程の開始時には、混入欠陥数テーブル221,検出欠陥数テーブル222,開発工数テーブル224,およびソースコードメトリクステーブル225には、予測対象プロジェクトのレコードは含まれていない。このような状態において、規模値のデータおよび技術要因・環境要因のデータを用いて予測対象プロジェクトと他のプロジェクトとの間の類似度が算出される。このようにして求められた類似度に基づいて、混入欠陥数テーブル221,検出欠陥数テーブル222,開発工数テーブル224,およびソースコードメトリクステーブル225内の各メトリクスの値が予測される。

要求定義工程が終了すると、要求定義に関するメトリクスの実績値が得られる。ユーザは、この実績値を各テーブルに登録する。これにより、設計工程の開始時には、要求定義に関する各メトリクスの実績値のデータがそれぞれ対応するテーブルに既に格納されている。従って、設計工程の開始時には、規模値および技術要因・環境要因のデータだけでなく、要求定義に関する各メトリクスの実績値のデータも用いて、予測対象プロジェクトと他のプロジェクトとの類似度が求められる。そして、その類似度に基づいて、各メトリクスの値が予測される。このようにして、各開発工程の開始時において、実施済みの開発工程の実績値を用いて未実施の開発工程の予測値が求められる。

なお、予測対象プロジェクトとユーザリリース済みのプロジェクトとの類似度を求める際、ユーザリリース済みのプロジェクトについては各メトリクスの最終の実績値のデータが用いられる。但し、技術要因・環境要因のデータについては、ソフトウェア開発の特性上(例えば、開発工程毎に開発会社や作業者が異なるという特性上)、開発工程毎に値が大きく異なることがある。従って、ユーザリリース済みのプロジェクトのデータに関し、例えば、「要求定義に関するメトリクスの値を予測する際には要求定義工程における実績値のデータを用い、設計に関するメトリクスの値を予測する際には設計工程における実績値のデータを用いる」というようにしても良い。

<2.5 効果> 本実施形態によれば、上記第1の実施形態と同様の効果が得られるのに加えて、開発工数テーブル224,ソースコードメトリクステーブル225,および技術要因・環境要因テーブル226が設けられていることにより以下のような効果が得られる。

本実施形態によれば、予測対象プロジェクトと他のプロジェクトとの類似度を求める際に、開発工数,ソースコードメトリクス,技術要因・環境要因が考慮される。このように様々な指標を用いて類似度が算出され、その類似度に基づいて各メトリクスの値が予測される。このため、各開発工程における各メトリクスの値が顕著に高い精度で予測される。特に、技術要因および環境要因のデータが用いられることにより、ソフトウェア開発の特性を考慮した予測が行われる。従って、ソフトウェア開発の各開発工程で生じる欠陥の数(混入欠陥数,検出欠陥数)がソフトウェア開発の特性を考慮して予測されるので、ソフトウェア開発のプロジェクトを進めるにあたって、きわめて効果的に改善対象工程の絞り込みを行うことが可能となる。

また、本実施形態によれば、各開発工程における開発工数が予測される。これにより、改善対象工程を決定するための判断材料が多くなるので、より的確に改善対象工程の絞り込みを行うことが可能となる。また、一般に、或る一定の規模のプロジェクトに着目したとき、開発工数を多くするほどソフトウェアの品質は向上する。すなわち、規模が一定であれば、開発工数が多いほど欠陥数は少なくなる傾向にある。このように開発工数と欠陥数との間には比較的高い相関があるので、開発工数のデータを用いて算出された類似度に基づいて欠陥数の予測を行うことによって、より高い精度で欠陥数を予測することが可能となる。

さらに、本実施形態によれば、ソースコードメトリクスが予測される。ソースコードメトリクスは実装工程で作成されるソースコードの品質を定量的に評価するための指標であるので、ソースコードメトリクスを予測することにより、実装工程を改善対象工程とすべきか否かをより的確に判断することが可能となる。

<2.6 変形例> 上記第2の実施形態の変形例について説明する。上記第2の実施形態においては、難易度保持手段として機能するテーブルとしてソースコードメトリクステーブル225が設けられていたが、本変形例においては、難易度保持手段として機能するテーブルとして、あいまい度テーブル227が設けられている。なお、ソースコードメトリクステーブル225およびあいまい度テーブル227の双方が設けられる構成を採用することもできる。

ここで、「あいまい度」について説明する。一般に、ソフトウェア開発においては、各開発工程でドキュメントが作成される。ドキュメントは複数の作業者によって参照されるところ、或る作業者によって作成されたドキュメント内に難しい語彙や複雑な構文が用いられていると、他の作業者が意味を誤解することがある。簡単な例を挙げると、ドキュメント内に「AおよびBまたはC」という表現が用いられている場合、当該表現は、「“AおよびB”または“C”」の意味で理解されることもあれば、「“A”および“BまたはC”」の意味で理解されることもある。ドキュメント内で用いられているこのような表現のあいまいさは、システムの欠陥を引き起こす要因となる。すなわち、ドキュメント内にあいまいな表現が多く用いられているほど、システムに生じる欠陥の数が多くなると考えられる。そこで、近年、ドキュメント内の表現のあいまいさに起因する欠陥を少なくするため、ドキュメントのあいまいさの度合いを表す「あいまい度」を測定するソフトウェアも開発されている。本変形例においては、ソフトウェア開発の各開発工程で作成されるドキュメントのあいまい度のデータが、あいまい度テーブル227に保持される。そして、そのあいまい度のデータに基づいて、類似度算出手段72による類似度の算出および予測値算出手段73による予測値の算出が行われる。

図28は、あいまい度テーブル227のレコードフォーマットの一例を示す図である。あいまい度テーブル227には、項目名をそれぞれ「名称」,「バージョン」,「予測工程」,「要求定義書あいまい度」,「予実フラグ(f1)」,「設計書あいまい度」,「予実フラグ(f2)」,「プログラム仕様書あいまい度」,「予実フラグ(f3)」,「テスト仕様書あいまい度」,および「予実フラグ(f4)」とする複数の項目が含まれている。

あいまい度テーブル227の各項目(「名称」などの上記で説明した項目を除く)のフィールドには、それぞれ以下のような内容のデータが格納される。「要求定義書あいまい度」には、要求定義工程で作成される要求定義書のあいまい度(実績値もしくは予測値)が格納される。「設計書あいまい度」には、設計工程で作成される設計書のあいまい度(実績値もしくは予測値)が格納される。「プログラム仕様書あいまい度」には、実装工程で作成されるプログラム仕様書のあいまい度(実績値もしくは予測値)が格納される。「テスト仕様書あいまい度」には、テスト工程で作成されるテスト仕様書のあいまい度(実績値もしくは予測値)が格納される。

本変形例においては、上述したあいまい度テーブル227に保持されているあいまい度のデータを用いて予測対象プロジェクトと他のプロジェクトとの類似度が算出され、その類似度に基づいて、予測対象プロジェクトの各開発工程における欠陥の数(混入欠陥数,検出欠陥数)が予測される。一般にドキュメントのあいまい度と欠陥の数との間には比較的高い相関があるので、あいまい度のデータを用いることによって、より高い精度で欠陥の数を予測することが可能となる。これにより、さらに的確に改善対象工程の絞り込みを行うことが可能となる。

<3.その他> 上記各実施形態における各テーブルの構成は一例であって、本発明はこれに限定されない。例えば、各テーブルに上記各実施形態で説明した以外の項目が含まれていても良い。また、例えば、混入欠陥数テーブル221と検出欠陥数テーブル222とが1つのテーブルになっていても良い。また、類似度や予測値の算出に関し、上記で説明した計算式以外の計算式を用いても良い。

7…サーバ機(ソフトウェア欠陥予測装置) 8…パソコン 20…補助記憶装置 21…プログラム格納部 22…データベース 71…データ登録手段 72…類似度算出手段 73…予測値算出手段 210…ソフトウェア欠陥予測プログラム 221…混入欠陥数テーブル 222…検出欠陥数テーブル 223…規模値テーブル 224…開発工数テーブル 225…ソースコードメトリクステーブル 226…技術要因・環境要因テーブル 227…あいまい度テーブル 230…プロジェクト−メトリクステーブル 721…正規化手段 722…類似度計算手段