(57)【要約】【課題】不具合による手戻りと改善施策に要するコストとを評価の対象に組み込んだプロセス改善施策評価装置及び方法を提供する。【解決手段】プロジェクトの各工程について、不具合が無いとした場合の工数と、この工程で修正する不具合件数と、この工程で不具合１件当りに要する工数とが規定されるモデルを作成する工程フローモデル部１２と、過去に実績が記録された教師プロジェクトから前記各工程についての不具合件数及び工数を前記モデルに設定する設定部１４と、プロジェクトの計画値を変更したプロセス改善施策情報に基づいて前記モデルに設定した前記各工程の不具合件数を変更し、変更した前記不具合件数に基づいてプロセス改善施策後の前記各工程の前記工数を更新する施策影響推定部１７と、この更新した情報を含むプロセス改善施策評価値を出力する出力部１６とを備えたプロセス改善施策評価装置である。【選択図】図１
2011198300.tif 000002
【特許請求の範囲】
【請求項１】
プロジェクトの各工程について、不具合が無いとした場合の工数と、この工程で修正する不具合件数と、この工程で不具合１件当りに要する工数とが規定されるモデルを作成する工程フローモデル部と、
過去に実績が記録された教師プロジェクトから前記各工程についての不具合件数及び工数を前記モデルに設定する設定部と、
プロジェクトの計画値を変更したプロセス改善施策情報に基づいて前記モデルに設定した前記各工程の不具合件数を変更し、変更した前記不具合件数に基づいてプロセス改善施策後の前記各工程の前記工数を更新する施策影響推定部と、
この更新した情報を含むプロセス改善施策評価値を出力する出力部と
を備えたことを特徴とするプロセス改善施策評価装置。
【請求項２】
前記出力部が出力する前記プロセス改善施策評価値には、前記それぞれの工程の総工数の合計値を含むことを特徴とする請求項１に記載のプロセス改善施策評価装置。
【請求項３】
前記教師プロジェクトを、ソフトウェア開発プロジェクトにおけるデータ開発量とロジック開発量との比であるデータ・ロジック比に基づいて選定する選定部を更に備えたことを特徴とする請求項１に記載のプロセス改善施策評価装置。
【請求項４】
前記設定部は、
前記教師プロジェクトの工程に、前記不具合が無いとした場合の工数と不具合１件当りに要する工数とが記録されていない場合は、それぞれの工程について、総工数とそれぞれの不具合の発見から修正確認までの期間情報と発生不具合数とに基づいて前記不具合が無いとした場合の工数と不具合１件当りに要する工数とを算出することを特徴とする請求項２又は３に記載のプロセス改善施策評価装置。
【請求項５】
プロジェクトの各工程について、不具合が無いとした場合の工数と、この工程で修正する不具合件数と、この工程で不具合１件当りに要する工数とが規定されるモデルを作成し、
過去に実績が記録された教師プロジェクトから前記各工程についての不具合件数及び工数を前記モデルに設定し、
プロジェクトの計画値を変更したプロセス改善施策情報に基づいて前記モデルに設定した前記各工程の不具合件数を変更し、
変更した前記不具合件数に基づいてプロセス改善施策後の前記各工程の前記工数を更新し、
この更新した情報を含むプロセス改善施策評価値を出力すること
を特徴とするプロセス改善施策評価方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はプロセス改善施策評価装置及び方法に関する。
【背景技術】
【０００２】
プロジェクトとしてソフトウェアシステムを開発する場合には、システム設計〜ソフトウェア製作〜動作テストなどの一連の工程を経ることが必要である。一方、開発中の各工程において不具合が発生した場合には、手戻りが発生する。手戻りとは、不具合の原因に応じた前の工程にまで遡り、そこから再度工程を実行することをいう。
【０００３】
これまで、プロジェクトを効率的に運用する改善策を立案するために、開発プロジェクトの各工程に要した工数などの開発実績を収集して、プロジェクトを評価する各種手法が提案されている。
【０００４】
特許文献１に開示された発明では、プロジェクトの工程内の欠陥数を評価するだけでなく、下流工程への流出度合いを評価でき、その結果、設計工程及び早期に実施するテスト工程における検出能力の向上度合いを評価することができる手法を提案している。
【０００５】
特許文献２に記載の発明は、工程の変更に関する影響をシナリオ形式で保持し、各工程における計画の修正がプロジェクトに与える影響を評価する方法を開示している。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００７−３１６７２８号公報
【特許文献２】特開２００５−０３２０７９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１に記載の技術では、工程に手戻りによる影響が考慮されていないため、手戻りが多く発生することで工程が影響を受ける場合は、そのプロジェクト評価の精度が低下する。
【０００８】
また、特許文献２に開示された評価方法では、不具合数にのみ着目している。そのため、同じ評価がなされる場合であっても、実施するプロセス改善施策に要するコスト（例えば、工数）が大きく増加する場合とそうでない場合が存在することになる。従って、不具合数のみの評価では不十分である。
【０００９】
本発明は、かかる事情に鑑みてなされたものであって、不具合による手戻りと改善施策に要するコストとを評価の対象に組み込んだプロセス改善施策評価装置及び方法を提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するための本発明は、プロジェクトの各工程について、不具合が無いとした場合の工数と、この工程で修正する不具合件数と、この工程で不具合１件当りに要する工数とが規定されるモデルを作成する工程フローモデル部と、過去に実績が記録された教師プロジェクトから前記各工程についての不具合件数及び工数を前記モデルに設定する設定部と、プロジェクトの計画値を変更したプロセス改善施策情報に基づいて前記モデルに設定した前記各工程の不具合件数を変更し、変更した前記不具合件数に基づいてプロセス改善施策後の前記各工程の前記工数を更新する施策影響推定部と、この更新した情報を含むプロセス改善施策評価値を出力する出力部とを備えたプロセス改善施策評価装置である。
【００１１】
また本発明は、プロジェクトの各工程について、不具合が無いとした場合の工数と、この工程で修正する不具合件数と、この工程で不具合１件当りに要する工数とが規定されるモデルを作成し、過去に実績が記録された教師プロジェクトから前記各工程についての不具合件数及び工数を前記モデルに設定し、プロジェクトの計画値を変更したプロセス改善施策情報に基づいて前記モデルに設定した前記各工程の不具合件数を変更し、変更した前記不具合件数に基づいてプロセス改善施策後の前記各工程の前記工数を更新し、この更新した情報を含むプロセス改善施策評価値を出力するプロセス改善施策評価方法である。
【発明の効果】
【００１２】
この発明によれば、不具合による手戻りと改善施策に要するコストとを評価の対象に組み込んでプロセス改善施策を評価することができる。
【図面の簡単な説明】
【００１３】
【図１】プロセス改善施策評価システムの構成を示す図。
【図２】工数ＤＢの内容を示す図。
【図３】不具合ＤＢの内容を示す図。
【図４】プロジェクトＤＢの内容を示す図。
【図５】工程フローモデルを示す図。
【図６】手戻り分別モデルと異なるデータ修正分別モデルを示す図。
【図７】不具合情報抽出部の概略の動作手順を示すフロー図。
【図８】不具合マトリクスを示す図。
【図９】工数情報抽出部の概略の動作手順を示すフロー図。
【図１０】プロジェクトの工数データを示す図。
【図１１】総工数のみが登録されているプロジェクトの工数データを示す図。
【図１２】初期工数と手戻り工数が登録されているプロジェクトと総工数しか登録されていないプロジェクトが混在しているプロジェクトの工数データを示す図。
【図１３】総工数から手戻り工数と初期工数を算出する手順を示すフローチャート。
【図１４】作成した不具合マトリクスを例示する図。
【図１５】発見工程が総合試験、混入工程が詳細設計の不具合を抽出した図。
【図１６】発見日と確認日の減算結果を示した図。
【図１７】行列形式に登録する際の手順を示すフロー図。
【図１８】行列形式を示す図。
【図１９】行列形式を示す図。
【図２０】行列形式を示す図。
【図２１】行列形式を示す図。
【図２２】行列形式を示す図。
【図２３】行列形式を示す図。
【図２４】レビューテストデータの内容を示す図。
【図２５】施策影響推定部の処理手順を示すフロー図。
【図２６】網羅率と検出率の回帰分析を説明するための図。
【図２７】プロセス改善施策評価装置の概略の動作を示すフローチャート。
【発明を実施するための形態】
【００１４】
［第１の実施の形態］  
図１は、プロセス改善施策評価システムの構成を示す図である。プロセス改善施策評価システムは、本発明の第１の実施の形態のプロセス改善施策評価装置１と入出力装置２とを備えている。
【００１５】
プロセス改善施策評価装置１は、処理を実行する部として施策情報入力部１０、教師プロジェクト選出部１１、工程フローモデル部１２、不具合情報抽出部１３、工数情報抽出部１４、工数計算部１５、結果出力部１６、施策影響推定部１７及び制御部２０を備えている。  
また、プロセス改善施策評価装置１は、データを保存するデータベース（ＤＢ）として、工数ＤＢ２１、不具合ＤＢ２２、プロジェクトＤＢ２３及びレビューテストＤＢ２４を有している。  
入出力装置２は、プロセス改善施策評価装置１に対してユーザの指示を入力し、またプロセス改善施策評価装置１から出力される情報を表示する。
【００１６】
施策情報入力部１０は、評価を行うために必要な情報を入力する。教師プロジェクト選出部１１は、プロセス改善施策評価を行う際にベースとなる対象プロジェクトと類似するプロジェクトを選出する。工程フローモデル部１２は、工程の遷移と不具合発生時の手戻りの様子を工程フローモデルとしてモデル化する。  
不具合情報抽出部１３は、不具合に関するデータに基づいて工程フローモデルの不具合に関するパラメータを抽出する。工数情報抽出部１４は、工程フローモデルの工数に関するパラメータを抽出する。工数計算部１５は、プロジェクトに要した総工数の計算を行う。結果出力部１６は、評価結果を入出力装置２のモニタに出力する。施策影響推定部１７は、プロジェクトの計画値を変更したプロセス改善策を採用した場合の結果を表す評価値を算出する。制御部２０は、プロセス改善施策評価装置１の各部の動作を統括して制御する。
【００１７】
次に、プロセス改善施策評価装置１の動作を説明するための前提として、プロセス改善施策評価装置１において用いられる用語、データの内容について各ＤＢの構成を参照しつつ説明する。
【００１８】
図２は、工数ＤＢ２１の内容を示す図である。工数ＤＢ２１が保存する工数データは、各プロジェクトにつき、プロジェクトＩＤとデータ工数とロジック工数、各開発工程における総工数と初期工数と手戻り工数を記録したデータである。この工数データは、プロジェクトＩＤをキーワードとして検索が可能である。
【００１９】
プロジェクトＩＤとは、プロジェクトを識別するためのデータであり、異なるプロジェクトは異なるプロジェクトＩＤを持つ。データ工数、ロジック工数は、プロジェクトの内多量のデータを扱うソフトウェア開発プロジェクトのみが保持する値である。
【００２０】
例えば、駅務機器を対象とするシステムでは、駅、路線といった多量な情報（データ）を扱う。これらデータの開発に要する総工数がデータ工数である。また、システムの動作の開発に要する総工数がロジック工数である。  
また発券機の場合、切符に印字する表示情報や付加する情報の設計・実装・検証に要する総工数がデータ工数となる。また、ボタンの押下やコインの投入といったユーザ操作に対するシステム動作・応答の設計・実装・検証に要する総工数がロジック工数となる。ｉ番目のプロジェクトＩＤｉのデータ工数をＤｉ、ロジック工数をＬｉと表記する。
【００２１】
各開発工程における総工数とは、その工程で要した総工数である。手戻り工数とは、不具合発生した際に、一つの不具合を修正するのにその工程で要する工数である。初期工数とは、その工程に最初に要した工数であり、総工数から手戻りに要した工数の合計を引いたものである。  
プロジェクトＩＤｉの工程ｐへの総工数、手戻り工数、初期工数をそれぞれＳｉｐ、Ｔｉｐ、Ｉｉｐとする。プロジェクトＩＤｉの工程ｐへ手戻りした不具合数をＢｉｐとすると、Ｓｉｐ  ＝  Ｔｉｐ×Ｂｉｐ＋Ｉｉｐ  が成立する。
【００２２】
図３は、不具合ＤＢ２２の内容を示す図である。不具合ＤＢ２２が保存する不具合データは、各プロジェクトにつき、プロジェクトＩＤ、不具合ＩＤ、混入工程、発見工程、発見日、確認日及びデータ修正識別情報を含む。この不具合データは、プロジェクトＩＤにより検索が可能である。
【００２３】
不具合ＩＤとは、同じプロジェクト内の不具合を識別するためのデータである。従って、異なるプロジェクトであれば、同じ識別データを用いても構わない。混入工程とは不具合が混入した工程であり、発見工程とは不具合を見つけた工程である。発見日とは不具合を見つけた日であり、確認日とは不具合を修正し、その修正が正しく行われたことを確認した日である。また、データ修正識別情報は、多量のデータを扱うプロジェクトの場合、不具合がデータ修正のみで済むかどうかを識別する情報である。
【００２４】
図３に示すプロジェクトＩＤ１の不具合ＩＤ１では、混入工程が基本設計で発見工程が単体試験となり、発見日が２００８／１１／４、確認日が２００８／１１／１０である。そして、このプロジェクトＩＤ１の不具合ＩＤ１の場合は、データ修正のみで不具合の修正が可能である。
【００２５】
図４は、プロジェクトＤＢ２３の内容を示す図である。プロジェクトＤＢ２３が保存するプロジェクトデータは、プロジェクトＩＤとプロジェクトの種類を表す情報を含む。プロジェクトの種類を表す情報として、図４では、開発規模でプロジェクトをランク付けした開発ランクを用いている。なお、プロジェクトの種類を表す情報は開発ランクでなくても、プロジェクトの種類を離散的に表す情報であれば代用できる。
【００２６】
続いて、工程フローモデルについて説明する。  
工程フローモデルは、工程の遷移状態と不具合発生時の手戻り状態とをモデル化したものである。本実施例では、システム設計、詳細設計、基本設計、製造（実装）、単体試験、結合試験、総合試験の工程によるプロジェクトの工程フローモデルを考える。
【００２７】
図５に示す工程フローモデルでは、各工程に対し、同じ工程であっても初期時と手戻り時では別工程として扱っている。図５の白いブロックは各工程の初期工程を表し、ハッチを施したブロックは各工程の手戻り工程を表す。また、白いブロック内に記載したＴｉは工程ｉにおける初期工数、ハッチブロック内のｔｉは工程ｉの手戻り工数、ｂｉは工程ｉの手戻り工程に到達する不具合数を意味する。ブロックを結ぶ実線は工程の移行を表し、ブロックを結ぶ点線は不具合による手戻りを表している。
【００２８】
また、「以降の工程」と記載された白いブロックは、客先試験やリリース後の工程を表している。すなわち、本工程フローモデルでは、客先試験やリリース後において発見した不具合の手戻りも、考慮している。以降、この工程フローモデルを手戻り分別モデルと呼ぶ。
【００２９】
図６は、上述の手戻り分別モデルと異なるデータ修正分別モデルを示す図である。データ修正分別モデルでは、多量のデータを扱うソフトウェア開発において、データ修正のみで済む不具合は手戻りフローに戻らずデータ修正工程に移行する。データ修正工程とは、データの値に関する不具合を修正する工程であり、データの値の変更のみの修正を行う工程である。データ修正の不具合は、他の不具合と異なり極めて短時間で不具合を修正することができるため、他の不具合と区別することで、モデルの精度を高めることができる。
【００３０】
白いブロック内に記載したＴｉ、ハッチブロック内に記載したｔｉは手戻り分別モデルと同様、工程ｉの初期工数、手戻り工数である。ｂｉ（１≦ｉ≦７）はデータ修正で無い不具合の工程ｉの手戻り工程を通る不具合数である。「データ修正」と記載したハッチブロック内のｔｄはデータ修正に要する工数、ｂｄはデータ修正の不具合数である。ｔｄの値は、過去のプロジェクトの実績から一定値を設定する。
【００３１】
続いて本実施の形態のプロセス改善施策評価装置１の動作について説明する。  
図２７は、プロセス改善施策評価装置１の概略の動作を示すフローチャートである。
【００３２】
ステップＳ５０１において、利用者（ユーザ）は、施策情報入力部１０を用いて教師プロジェクト算出情報を入力する。  
教師プロジェクトとは、過去に実績が記録されたプロジェクトの内、今回のプロセス改善施策評価のベースデータとすることのできるプロジェクトのことである。利用者が入力する、教師プロジェクト算出に必要な情報としては、プロジェクトＩＤ、図４に示す開発ランクなどであり、多量のデータを扱うソフトウェア開発プロジェクトであればデータ・ロジック比が挙げられる。利用者は、この中から少なくとも一つの情報を入力する必要がある。
【００３３】
ここで、データ・ロジック比とは、ソフトウェア開発プロジェクトにおけるデータ開発量とロジック開発量の比の情報であり、同じドメインについてのソフトウェア開発の開発経験を積んだ者であれば、プロジェクト開始時に、その比を見積もることが可能である。
【００３４】
本実施の形態では、教師プロジェクト算出情報として、類似した過去のプロジェクトが判明している場合は、利用者は、プロジェクトＩＤを入力する。このプロジェクトＩＤは複数入力が可能である。一方、類似した過去のプロジェクトが判明していない場合は、利用者は、教師プロジェクト算出情報として、プロジェクトの特徴を現す開発ランクやデータ・ロジック比を入力する。
【００３５】
ステップＳ５０２において、施策情報入力部１０は、入力された情報がプロジェクトＩＤかどうかを調べる。ステップＳ５０２でＹｅｓの場合、即ち、入力した情報がプロジェクトＩＤの場合は、ステップＳ５０４に進む。  
ステップＳ５０２でＮｏの場合、すなわち、入力した情報がプロジェクトＩＤで無い場合、施策情報入力部１０は、教師プロジェクト算出情報を教師プロジェクト選出部１１に出力する。
【００３６】
ステップＳ５０３において、教師プロジェクト選出部１１は、教師プロジェクト算出情報として、開発ランクとデータ・ロジック比が入力されていれば、プロジェクトＤＢ２３と工数ＤＢ２１とを検索して同じ開発ランクのプロジェクトの工数データを抽出する。そして、データ工数とロジック工数の比を求め、入力したデータ・ロジック比に近い比をもつプロジェクトを教師プロジェクトとして選出し、そのプロジェクトＩＤを施策情報入力部１０に返す。近似する比をもつプロジェクトが複数ある場合は、それら全てのプロジェクトＩＤを施策情報入力部１０に返す。
【００３７】
一方、開発ランクのみ入力されている場合は、教師プロジェクト選出部１１は、同一の開発ランクのプロジェクトＩＤを全て施策情報入力部１０に返す。  
またデータ・ロジック比のみ入力されている場合は、全てのプロジェクトの工数データを参照し、データ工数とロジック工数の比を求める。そして、入力したデータ・ロジック比に近いプロジェクトを教師プロジェクトとして選出し、そのプロジェクトＩＤを施策情報入力部１０に返す。もし、近似する比をもつプロジェクトが複数ある場合は、それら全てのプロジェクトＩＤを施策情報入力部１０に返す。
【００３８】
プロジェクトＩＤが得られた場合は、施策情報入力部１０は、そのプロジェクトＩＤを不具合情報抽出部１３に出力する。ステップＳ５０４において、不具合情報抽出部１３は不具合ＤＢ２２を検索して、入力されたプロジェクトＩＤについての不具合データ（図３）を参照して、工程フローモデルの手戻り不具合ｂｉを算出する。そして、その値ｂｉを工程フローモデルに設定する。
【００３９】
この不具合情報抽出部１３の動作について詳細に説明する。
【００４０】
図７は、不具合情報抽出部１３の概略の動作手順を示すフロー図である。  
ステップＳ００１において、不具合情報抽出部１３は、施策情報入力部１０よりプロジェクトＩＤを受け取る。不具合情報抽出部１３は、ステップＳ００２において、受け取った各プロジェクトの不具合データを不具合ＤＢ２２を検索して参照し、ステップＳ００３において、不具合マトリクスを作成する。
【００４１】
図８は、不具合マトリクスを示す図である。不具合マトリクスは、縦軸に不具合を発見した工程、横軸に不具合が混入した工程、各欄には発見工程から混入工程へ手戻りした不具合数が記されたマトリクスである。
【００４２】
例えば、ｂ３１は詳細設計工程において実施されたレビューにおいて発見され、システム設計工程へ手戻りした不具合の総数である。ｂ６２は結合試験工程で発見され、基本設計工程へ手戻りした不具合の総数である。なお、後工程に戻る手戻りは無いため、この不具合マトリクスにおいて、ｂ１２、ｂ１３、ｂ１４、ｂ２３、ｂ２４、ｂ３４は常に０となる。また、試験工程において不具合が混入することはないため、横軸の混入工程は実装工程までとなる。
【００４３】
この不具合マトリクスの作成方法について説明する。上述のステップＳ００１の時点では、不具合マトリクスの各欄の値を０に設定する。工程フローモデルがデータ修正分別モデルの場合、修正工程の手戻り数ｂｄの値も０に設定する。上述のステップＳ００３の作成処理では、データ修正分別モデルの場合は、不具合ＤＢ２２のデータ修正識別情報を参照し、データ修正のみで済む不具合であればｂｄに１加算をする。データ修正のみで済む不具合でなければ、発見工程と混入工程を参照し、対応する不具合マトリクスの欄の値を１加算する。例えば、混入工程が詳細設計、発見工程が単体試験であれば、図８の不具合マトリクスのｂ５３の値を１加算して更新する。
【００４４】
１つのプロジェクトについて不具合マトリクスの作成が終わったら、ステップＳ００４において、未参照のプロジェクトについて不具合データがあるか調べる。ステップＳ００４でＹｅｓの場合、すなわち、未参照の不具合データがある場合、上述のステップＳ００２からＳ００３の処理を再度実行する。ステップＳ００４でＮｏの場合、すなわち、未参照の不具合データがない場合、ステップＳ００５において、不具合マトリクスの各値をプロジェクト数で割り、１プロジェクト辺りの平均値とする。工程フローモデルがデータ修正分別モデルの場合はｂｄの値も平均値とする。
【００４５】
ステップＳ００６において、ステップＳ００５で得られた不具合マトリクスから、工程フローモデルが必要とする工程ｉの手戻り工程に到達する不具合数ｂｉ（１≦ｉ≦７）の値を算出する。
【００４６】
システム設計の手戻り工程に戻る不具合は、混入工程がシステム設計の不具合である。そのため、ｂ１＝Σ（１≦ｊ≦８）ｂｊ１となる。基本設計の手戻り工程に戻る不具合は、混入工程と発見工程の間に基本設計のある手戻りの不具合となる。すなわち、一つ前の工程であるシステム設計の手戻り工程に戻る不具合数ｂ１から、システム設計で発見された不具合を除き、基本設計で混入した不具合を加えた値が、ｂ２となる。ゆえに、ｂ２＝ｂ１−ｂ１１＋Σ（１≦ｊ≦８）ｂｊ２となる。同様に、ｂ３＝ｂ２−ｂ２１−ｂ２２＋Σ（１≦ｊ≦８）ｂｊ３、ｂ４＝ｂ３−ｂ３１−ｂ３２−ｂ３３＋Σ（１≦ｊ≦８）ｂｊ４となる。
【００４７】
ｂ５以降は試験工程となり、混入工程にはならないため、一つ前の手戻り工程戻る不具合数から、一つ手前の工程で発見された不具合数となる。ゆえに、ｂ５＝ｂ４−Σ（１≦ｊ≦４）ｂ４ｊ、ｂ６＝ｂ５−Σ（１≦ｊ≦４）ｂ５ｊ、ｂ７＝ｂ６−Σ（１≦ｊ≦４）ｂ６ｊとなる。また、以降の工程へ残った不具合数はΣ（１≦ｊ≦４）ｂ８ｊで計算できる。
【００４８】
図２７に戻り、ステップＳ５０５において、工数情報抽出部１４は、工数ＤＢ２１を検索してプロジェクトＩＤの工数データ（図２）を参照する。そしてこの工数データを用い、工程フローモデルの初期工数Ｔｉと手戻り工数ｔｉを算出し、算出した値を工程フローモデルに設定する。
【００４９】
この工数情報抽出部１４の動作について詳細に説明する。
【００５０】
図９は、工数情報抽出部１４の概略の動作手順を示すフロー図である。  
ステップＳ１０１において、工数情報抽出部１４は、施策情報入力部１０から１以上のプロジェクトＩＤを受け取る。ステップＳ１０２において、工数ＤＢ２１を検索して受け取った各プロジェクトＩＤの工数データを参照する。ステップＳ１０３において、工数情報抽出部１４は、工数データに各工程における手戻り工数、初期工数の登録があるかどうかを調べる。
【００５１】
ステップＳ１０３でＹｅｓの場合、すなわち、手戻り工数、初期工数の登録があれば、ステップＳ１０４において、登録された値を入手する。ステップＳ１０３でＮｏの場合、すなわち、登録がなければ、ステップＳ１０５において、総工数から手戻り工数と初期工数を算出する。このステップＳ１０５の手順については後で詳細に説明する。
【００５２】
ステップＳ１０６において、受け取った全てのプロジェクトＩＤについて手戻り工数、初期工数を取得したかどうかを調べる。ステップＳ１０６でＮｏの場合、すなわち、受け取ったプロジェクトＩＤのうち手戻り工数、初期工数を取得していないプロジェクトがあれば、ステップＳ１０２に戻って再度工数データの参照を行う。ステップＳ１０６でＹｅｓの場合、すなわち、全てのプロジェクトの各工程の手戻り工数、初期工数を取得したときは、ステップＳ１０７において、取得した初期工数、手戻り工数のプロジェクトについての平均を求め、その平均値を対応する工程の工程フローモデルパラメータＴｉ、ｔｉに代入する。
【００５３】
具体例によってこの処理を説明する。  
例えば、受け取ったプロジェクトＩＤがａとｂであり、それらプロジェクトの工数データが図１０に示される値であったとする。この場合、図９のフローチャートの手順としては、ステップＳ１０３でＹｅｓ、ステップＳ１０６でＹｅｓとなる。その結果、工数情報抽出部１４は、Ｔｉ＝（Ｉａｉ＋Ｉｂｉ）／２、ｔｉ＝（Ｔａｉ＋Ｔｂｉ）／２を工程フローモデルに設定する。
【００５４】
一方、図１１に示すように、総工数しか工数データに登録されていない場合は、図９のフローチャートの手順としては、ステップＳ１０３でＮｏを２回通り、ステップＳ１０５の処理で、Ｔｉとｔｉの値を算出する。  
また、図１２に示すように、初期工数と手戻り工数が登録されているプロジェクトと総工数しか登録されていないプロジェクトが混在している場合は、登録されているものはその値を用い、登録されていないものは、ステップＳ１０５の処理で算出する。
【００５５】
続いて、ステップＳ１０５の処理を詳細に説明する。ステップＳ１０５の処理である総工数から手戻り工数と初期工数の算出は、不具合ＤＢ２２の不具合データを用いて行う。  
図１３は、総工数から手戻り工数と初期工数を算出する手順を示すフローチャートである。
【００５６】
ステップＳ２０１において、プロジェクトＩＤより、不具合データを参照し、そのプロジェクトにおける不具合マトリクスを作成する。不具合マトリクスの作成方法は既に説明しているため、詳細の説明は省略する。図１４は、作成した不具合マトリクスを例示する図である。ステップＳ２０２において、作成された不具合マトリクスの欄の内、最も大きい値を保持する欄を選択する。図１４では、発見工程が総合試験、混入工程が詳細設計の欄が最も大きい値（１０）であるため、この欄を選択する。最大値を与える欄が複数有る場合は、乱数を用い一つを選択する。
【００５７】
続いて、ステップＳ２０３において、選択した欄に該当する不具合データの確認日と発見日を用いて、工程フローモデルｔｉの方程式を作成する。図１５は、不具合データよりプロジェクトＩＤ１０における発見工程が総合試験、混入工程が詳細設計の不具合を抽出した図である。総合試験工程から詳細設計工程への手戻りに要する工数は、工程フローモデルによるとｔ３＋ｔ４＋ｔ５＋ｔ６である。ここで、手戻りに要する工数にｔ７を入れていないのは、ｔ７には、この原因以外の手直しも含まれた値だからである。一方、図１５に示す各不具合において、確認日から発見日を引いた値は不具合が修正までに要する時間であり、各不具合が手戻りに要する工数と見なすことができる。
【００５８】
図１６は、図１５を元に、発見日と確認日の減算結果を示した図である。この例では、不具合ＩＤ４のように、当日修正した不具合は手戻りに１日要したと見なしている。これを０と見なすこともできる。また、不具合ＩＤ７のように、休日（２００８／１１／８，１１／９）はカウントしていない。このように、同じ総合試験から詳細設計への手戻りでも不具合に応じ修正時間はばらついている。工程フローモデルの手戻り工数ｔｉは、このバラツキを低減するため平均値を採用する。図１６に示す例では、平均値＝７．８を得る。すなわち、ｔ３＋ｔ４＋ｔ５＋ｔ６＝７．８という方程式を得ることが出来る。但し、この方程式では、右辺は日数であり、左辺は工数（人×時間）であるため、適当な係数をかけて単位を調整する。以下では、係数は１であるとして説明する。
【００５９】
なお、平均値の算出においては、外れ値を除去しても良い。図１６に示す例では、不具合ＩＤ１７の発見日−確認日は他の不具合と比べ非常に大きい値になっている。値が外れているかどうかは、標準偏差を用いて検出することができる。例えば、標準偏差より３倍以上平均から離れた値を外れ値であると定義することができる。図１６のケースでは、平均が７．８、標準偏差が８．７１であるため、不具合ＩＤ１７は外れ値とみなすことができる。
【００６０】
しかし、上記のように検出した不具合が常に信頼性の低い外れ値であるとは限らない。修正の難しい不具合で時間を要したことも考えられる。そこで、不具合データに不具合の重要度を登録することにより、発見日−確認日が大きい方向に外れているデータに対し、重要度が低いものはデータの信頼性が低いと見なし除去する方法をとることができる。
【００６１】
以上のように、不具合データの確認日と発見日を用い、工程フローモデルのｔｉの方程式を作成する。このようにして得られた方程式は、図１８で示すように行列演算の形式で管理する。
【００６２】
続いて、ステップＳ２０４において、得られた方程式から全ての手戻り工数ｔｉが求まるか調べる。図１３のフローチャートによれば、図１８の行列では一つの式しか存在しないため、全ての手戻り工数ｔｉを求めることが出来ない（Ｓ２０４のＮｏ）。ステップＳ２０５において、不具合マトリクス（図１４）に未選択の１以上の欄がある場合（Ｓ２０５のＹｅｓ）は、再度ステップＳ２０２からの処理を繰り返して実行する。
【００６３】
上述の手順で複数の方程式を作成し、行列の形式で管理する。図１７は、行列形式に登録する際の手順を示すフロー図である。
【００６４】
ステップＳ３０１において、登録する行の左辺が既に登録されている行の左辺に包含されるケースがあるかどうかを調べる。ステップＳ３０１でＹｅｓの場合、すなわち、登録する行の左辺が既に登録されている行の左辺に包含されるケースがある場合、ステップＳ３０７において、包含する行の位置に、包含する行から登録しようとしている行を減算する。次に、ステップＳ３０８において、右辺が負になるか確認する。ステップＳ３０８でＹｅｓの場合、すなわち、負になる場合は、手戻り工数ｔｉは負でない数であるため、ステップＳ３０９において、方程式の登録を中止する。ここで登録を中止する際は、既に減算した結果は反映させず行列を減算前の状態に戻す。ステップＳ３０８でＮｏの場合、すなわち、右辺が負でない場合は、行列には減算した結果を反映させてステップＳ３０１に戻る。
【００６５】
ステップＳ３０１でＮｏの場合、すなわち、登録する行の左辺が既に登録されている行の左辺に包含されるケースが無い場合、ステップＳ３０２において、既に登録されている行の左辺が登録する行の左辺と等しいか調べる。ステップＳ３０２でＹｅｓの場合、すなわち、等しい場合は、ステップＳ３０９において、方程式の登録を中止する。ここで登録を中止する際は、既に減算した結果は反映させず行列を減算前の状態に戻す。
【００６６】
ステップＳ３０２でＮｏの場合、すなわち、等しくない場合、ステップＳ３０３において、既に登録されている行の左辺が登録する行の左辺に包含されるケースがあるか調べる。ステップＳ３０３でＮｏの場合、すなわち、そのようなケースが無い場合、ステップＳ３１０において、方程式の登録を行う。ステップＳ３０３でＹｅｓの場合、すなわち、そのようなケースがある場合、ステップＳ３０４において、登録する行を既に登録されている行で減算する。
【００６７】
ステップＳ３０５において、減算した結果の右辺の符合を調べる。ステップＳ３０５でＹｅｓの場合、すなわち、登録する行の右辺が負になった場合、ステップＳ３０９において、方程式の登録を中止する。ここで登録を中止する際は、既に減算した結果は反映させず行列を減算前の状態に戻す。ステップＳ３０５でＮｏの場合、すなわち、登録する行の右辺が負でない場合、ステップＳ３０６において、既に登録されている行の左辺が登録する行の左辺と等しいか調べる。ステップＳ３０６でＹｅｓの場合、すなわち、そのようなケースがある場合、ステップＳ３０４に戻る。ステップＳ３０６でＮｏの場合、すなわち、そうでない場合、ステップＳ３０１に戻る。
【００６８】
次に、具体的な行列を例として上述のフロー図に従った処理を説明する。
【００６９】
例えば、図１８で示す状態の行列形式にｔ４＋ｔ５＋ｔ６＝８．５と表される方程式を登録する場合、既に登録してある行に包含されている。すなわち、行列の第１行はｔ３＋ｔ４＋ｔ５＋ｔ６＝７．８を表しているため、上述の方程式の左辺の式を含んでいる。そこで、図１９に示すように第１行から減算を行う。すると、右辺が負の数となる。従って、方程式ｔ４＋ｔ５＋ｔ６＝８．５の登録は行わない。この例では、図１７のフローチャートに従うと、ステップＳ３０１でＹｅｓとなり、ステップＳ３０８でＹｅｓとなるため、ステップＳ３０９において登録を中止する例である。
【００７０】
一方、図１８で示す状態の行列形式にｔ４＋ｔ５＋ｔ６＝７．０と表される方程式を登録する場合、第１行との減算結果、右辺は正となる。従って、第１行を減算した後、次の行である第２行に方程式を登録する。その結果は、図２０で示される行例となる。この例では、図１７のフローチャートに従うと、ステップＳ３０１でＹｅｓとなり、ステップＳ３０８でＮｏとなるため、ステップＳ３０１に戻る。そしてステップＳ３０１でＮｏ、ステップＳ３０２でＮｏとなり、ステップＳ３０３でＮｏを通り登録をする例である。
【００７１】
また例えば、図１８で示す状態の行列形式にｔ２＋ｔ３＋ｔ４＋ｔ５＋ｔ６＝７．５と表される方程式を登録する場合、第１行との間で図２１で示す減算が行われ、右辺が負の値となる。そのため、方程式ｔ２＋ｔ３＋ｔ４＋ｔ５＋ｔ６＝７．５の登録は中止する。この例では、図１７のフローチャートに従うと、ステップＳ３０１でＮｏとなり、ステップＳ３０２でＮｏとなり、ステップＳ３０３でＹｅｓとなり、ステップＳ３０５でＹｅｓとなって登録を中止する。
【００７２】
一方、図２２で示される状態の行列形式にｔ１＋ｔ２＋ｔ３＋ｔ４＋ｔ５＋ｔ６＝９．０と表される方程式を登録する場合、第１行との間で図２３で示す減算が行われ、行列の第３行目と第２行目とが同じ値になる。そのため、登録は中止する。図１７のフローチャートに従うと、ステップＳ３０１でＮｏとなり、ステップＳ３０２でＮｏとなり、ステップＳ３０３でＹｅｓとなり、ステップＳ３０５でＮｏとなり、ステップＳ３０６でＮｏとなり、ステップＳ３０１のＮｏとなり、ステップＳ３０２でＹｅｓとなって登録を中止する例である。
【００７３】
図１３に戻り、以上説明したように、ステップＳ２０４では、作成した方程式が解けるかどうかの管理を行う。登録した方程式の数がｔｉの数と等しくなった時、全てのｔｉの値を求めることが出来る。従って、ステップＳ２０４でＹｅｓのときは、ステップＳ２０７において、方程式の解として求めたｔｉを用い、Ｔｉの算出を行う。なお、ステップＳ２０７では、既にｂｉが求められていることが前提となる。工数ＤＢ２１を検索して、プロジェクトＩＤより、各開発工程における総工数ＴＳｉを入手する。そうすると、ＴＳｉ＝Ｔｉ＋ｂｉ×ｔｉ  の関係が成立するため、この式よりＴｉの値を算出できる。
【００７４】
図２７に戻り、以上でステップＳ５０４とステップＳ５０５の処理を終了するが、ステップＳ５０４とステップＳ５０５を実行する順序は逆転しても構わない。
【００７５】
工程フローモデルのパラメータ設定が終わったら、ステップＳ５０６において、工数計算部１５で総工数を計算し、計算結果を結果出力部１６で表示する。
【００７６】
この工数計算部１５の動作について説明する。  
工数計算部１５は、プロジェクトに要した総工数の計算を行う。計算方法は、工程フローモデルによって異なるが、初期工数の総和と手戻り工数の総和から求めることは共通している。手戻り分別モデルでは、総工数は、Σ１≦ｉ≦７（Ｔｉ＋ｂｉ・ｔｉ）の計算で求める。データ修正分別モデルでは、総工数は、Σ１≦ｉ≦７（Ｔｉ＋ｂｉ・ｔｉ）＋ｂｄ・ｔｄの計算で求める。
【００７７】
この結果出力部１６の動作について説明する。  
結果出力部１６は計算結果などを入出力装置２のモニタに表示し、ユーザに通知する。通知する情報は、上述の計算結果の場合は、総工数、工程フローモデルのＴｉ、ｔｉの値、不具合マトリクス、以降の工程へ残った不具合数各工程の総工数の合計、各工程の総工数の合計値などである。
【００７８】
ユーザは、この出力結果を参照してプロジェクトの改善施策を検討する。  
プロセス改善施策内容としては、例えば、レビューテスト時間や試験工程の網羅率（後述する）を変更することで、工程フローモデルのＴｉ、ｔｉ、ｂｉの値の変化を推定し、総工数の変化を調べる。このようにプロセス改善施策評価装置１を用いて、総工数の低減を図るプロジェクトの推進方法を検討することができる。
【００７９】
なお、各設計・実装工程におけるレビューに要した時間、各試験工程のテスト網羅率、テスト実施工数、テスト設計工数などは、レビューテストＤＢ２４にレビューテストデータとして、プロジェクトごとに記録されている。図２４は、レビューテストデータの内容を示す図である。
【００８０】
プロセス改善施策として適用する網羅率は試験工程により異なる方が好ましい。単体試験ではコードカバレッジ、結合試験や総合試験ではシステムカバレッジや組み合わせ網羅を用いることができる。
【００８１】
コードカバレッジとは、ソースコードベースでテストがどれだけ実行したかを示す基準である。この基準には、全てのステイトメントの中で、テストで実行したステイトメントの割合を示すＣ０（命令網羅）、全ての分岐の中で、テストで実行した分岐の割合を示すＣ１（分岐網羅）などがある。  
システムカバレッジとは、テスト対象のモジュールベースでテストがどれだけ実行したかを示す基準である。この基準には、全てのモジュールの中で、テストで実行したモジュールの割合を示すＳ０、全てのモジュール呼び出し命令の中で、テストで実行したものの割合を示すＳ１などがある。
【００８２】
組み合わせ網羅とは、取りうる全組み合わせのうち、テストで検証した組み合わせの割合を示したテスト基準である。例えば、二機能間の組み合わせ網羅を見る場合、（テストで検証した二機能の組み合わせ数）／（全二機能間の組み合わせ数）が網羅率となる。
【００８３】
図２７のステップＳ５０８において、ユーザは、施策情報入力部１０からプロジェクトの計画値であるプロセス改善施策情報を入力する。プロセス改善施策情報として、以下では、レビュー時間または網羅率を取り扱う。ステップＳ５０９において、施策情報入力部１０はプロセス改善施策情報を施策影響推定部１７に出力する。
【００８４】
施策影響推定部１７は、プロセス改善施策情報として、レビュー時間、または網羅率を変更した際に、不具合数ｂｉやＴｉの時間の変化量を定量的に推定する。その推定の際、不具合検出率を用いる。不具合検出率とは（工程ｉで検出した不具合）／（工程ｉで検出すべき不具合）で計算され、工程ｉで検出すべき不具合をどれだけ検出したかを示す指標である。
【００８５】
不具合検出率は不具合マトリクス（図８）から算出することができる。設計・製造工程であれば、混入する不具合は同工程のレビューで見つけるべきであるため、工程ｉの不具合検出率＝Σｂｉｉ／｛Σ（ｉ＜ｊ≦８）ｂｊｉ）となる。  
試験工程では、単体試験は製造や詳細設計、結合試験は基本設計、総合試験ではシステム設計の不具合を検出すべきであることから、それぞれの試験における不具合検出率は次の式で定義される。単体試験の不具合検出率は（ｂ５３＋ｂ５４）／（ｂ５３＋ｂ５４＋ｂ６３＋ｂ６４＋ｂ７３＋ｂ７４＋ｂ８３＋ｂ８４）となる。結合試験の不具合検出率はｂ６２／（ｂ６２＋ｂ７２＋ｂ８２）となる。総合試験の不具合検出率はｂ７１／（ｂ７１＋ｂ８１）となる。
【００８６】
図２５は、施策影響推定部１７の処理手順を示すフロー図である。  
ステップＳ４０１において、レビューまたはテストのいずれを対象としてプロセス改善を行うかを調べる。
【００８７】
ステップＳ４０１でテストが対象となっている場合は、ステップＳ４０２において、網羅率とテスト設計工数、網羅率とテスト実施工数間で回帰分析を行う。ステップＳ４０３において、回帰分析結果を用いて、入力した網羅率をカバーするために必要となるテスト設計工数とテスト設計工数を見積もる。次に、ステップＳ４０４において、網羅率と不具合検出率とで回帰分析を行う。ステップＳ４０５において、この回帰分析結果を用いて、入力した網羅率でテストを行った場合に検出する不具合数を見積もる。
【００８８】
一方、ステップＳ４０１でレビューが対象となっている場合は、ステップＳ４０６において、レビュー時間と不具合検出率とで回帰分析を行う。ステップＳ４０７において、この回帰分析結果を用いて、入力したレビュー時間を適用した場合に検出する不具合数を見積もる。
【００８９】
回帰分析とは、結果となる変数と要因となる変数の関係を調べ、変数間の関係を推定する統計的手法である。本実施の形態では、レビュー時間と不具合検出率（ステップＳ４０６）、網羅率とテスト設計工数（ステップＳ４０２）、網羅率とテスト実施工数（ステップＳ４０２）、網羅率と不具合検出率（ステップＳ４０４）間の関係式を推定する。
【００９０】
続いて、回帰分析で用いられる上述の各変数間の関係について説明する。  
レビュー時間と不具合検出率（ステップＳ４０６）との関係では、レビューで見付けやすい不具合が短期間の内に多く見つかり、その後レビューで見つかりづらい不具合が散発的に見つかる傾向にある。従って、レビュー時間の増加分に対し、不具合検出率は減ることは無いが増加率は低下する。
【００９１】
網羅率とテスト設計工数（ステップＳ４０２）との関係では、網羅率が低い状態で網羅率を上げるようにテスト設計を行うのは容易であるが、網羅率が高い状態で網羅率をさらに上げるのは難しい傾向にある。従って、テスト設計工数の増加に対し、網羅率は減ることは無いが増加率は低下する。  
網羅率とテスト実施工数（ステップＳ４０２）との関係も同様に、テスト実施工数の増加に対し、網羅率は減ることは無いが増加率は低下する。一方、網羅率と不具合検出率（ステップＳ４０４）との関係では、不具合の存在に偏在する特性がないとすると、網羅率が増加すると不具合検出率も比例して増加すると考えられる。
【００９２】
このように、片方の数値の増加に対しもう片方の数値が比例して増加する関係にある網羅率と不具合検出率（ステップＳ４０４）との回帰分析では、線形回帰を適用することができる。そこで、ステップＳ４０４の回帰分析では、まず教師プロジェクトを複数選択する。この教師プロジェクトの選択は、開発ランクやデータ・ロジック比を用い、教師プロジェクト選出部１１により行う。
【００９３】
次に選択した教師プロジェクトの不具合データ（図３）を参照し、教師プロジェクトの不具合検出率を算出する。また、レビュー・テストデータ（図２４）を参照し、教師プロジェクトの網羅率を算出する。このようにして、プロジェクトごとに（網羅率、検出率）の組み合わせを求め、二次元座標にプロットする。
【００９４】
図２６は、網羅率と検出率の回帰分析を説明するための図である。  
図２６の左の図は、プロジェクトごとに求めた網羅率、検出率を二次元座標にプロットした図である。ここで、線形回帰分析により図２６の右図に示す回帰直線を求める。線形回帰分析の方法として、最小二乗法を用いる。最小二乗法は各点との距離の二乗の和が最小になるような直線を算出する方法である。この算出した回帰直線を用い、網羅率から検出率を推定できる。例えば、図２６の右図のように改善施策として８０％の網羅率を設定した場合の検出率ＦＲを求めることが出来る。
【００９５】
一方、片方の数値の増加に対しもう片方の数値は減ることは無いが増加率は低下する関係にあるレビュー時間と不具合検出率（ステップＳ４０６）、網羅率とテスト設計工数（ステップＳ４０２）、網羅率とテスト実施工数（ステップＳ４０２）の関係は、線形の関係でないため、上述の線形回帰を直接適用することができない。そこで、増加幅の大きい数値の対数を取った上で線形回帰を行う。
【００９６】
まず教師プロジェクトを複数選択する。この教師プロジェクトの選択は、開発ランクやデータ・ロジック比を用い、教師プロジェクト選出部１１により行う。次に各教師プロジェクトのデータを用いて各数値の組み合わせを求める。レビュー時間と不具合検出率であれば、レビュー時間はレビュー・テストデータ（図２４）を参照し、不具合検出率は不具合データ（図３）を参照し得る。網羅率とテスト設計工数であれば、レビュー・テストデータ（図２４）を参照し両値を得る。網羅率とテスト実施工数であれば、レビュー・テストデータ（図２４）を参照し両値を得る。次に、増加幅の大きい数値の対数をとり二次元座標にプロットする。
【００９７】
レビュー時間と不具合検出率であれば（ｌｏｇ（レビュー時間）、不具合検出率）となり、網羅率とテスト設計工数であれば、（ｌｏｇ（テスト設計工数）、網羅率）となり、網羅率とテスト実施工数であれば、（ｌｏｇ（テスト実施工数）、網羅率）となる。
【００９８】
この後は、図２６で示した方法と同様に、最小二乗法による線形回帰分析を行う。これにより、レビュー時間と不具合検出率であれば、レビュー時間より不具合検出率を推定できる。網羅率とテスト設計工数であれば、網羅率よりテスト設計工数が推定できる。網羅率とテスト実施工数であれば、網羅率よりテスト実施工数が推定できる。
【００９９】
図２７のステップＳ５０９において、このように算出した値を工程フローモデルに反映させる。これによって、施策実施後の総工数を評価できる。以下に、反映方法を記す。
【０１００】
レビューに対する改善施策であれば、レビュー時間の増加分と不具合検出率の増加分が分かる。詳細設計のレビュー施策を行った時を考える。まず、レビュー時間の時間の増加分をＴ３に加算する。次に不具合の影響を反映させる。不具合総数とレビュー工程以降の工程間の不具合発見割合が変わらないように、不具合検出率を推定した値（ＦＲとする）にする。すなわち、「’」が付いた不具合数ｂｉは改善施策反映後の不具合数とすると、ｂ３３’、ｂ４３’、ｂ５３’、ｂ６３’、ｂ７３’、ｂ８３’の値は以下の式を用いて算出できる。なお、以下の式は、詳細設計のレビュー施策の例である
b33’=FR×(b33+b43+b53+b63+b73+b83)
b43’={(b43)/(b43+b53+b63+b73+b83)}×{b33+b43+b53+b63+b73+b83-b33’}
b53’={(b53)/(b43+b53+b63+b73+b83)}×{b33+b43+b53+b63+b73+b83-b33’}
b63’={(b63)/(b43+b53+b63+b73+b83)}×{b33+b43+b53+b63+b73+b83-b33’}
b73’={(b63)/(b43+b53+b63+b73+b83)}×{b33+b43+b53+b63+b73+b83-b33’}
b83’={(b83)/(b43+b53+b63+b73+b83)}
この式によれば、b33’+b43’+b53’+b63’+b73’+b83’＝b33+b43+b53+b63+b73+b83が成立している。即ち、不具合総数は同じである。
【０１０１】
テストに対する改善施策であれば、テスト実施工数の増加分と、テスト設計工数の増加分と、不具合検出率の増加分が分かる。結合テストのテスト施策を行ったものとする。まず、テスト実施工数の増加分とテスト設計工数の増加分を反映させる。テスト実施工数は増加分をＴ６に加算する。結合試験のテスト設計を基本設計で行っているとすると、テスト設計工数の増加分をＴ２に加算する。
【０１０２】
次に不具合マトリクス（図８）を用い、不具合数への影響を反映させる。その際、不具合総数と結合テスト工程以降の工程間の不具合発見割合が変わらないように、不具合検出率を推定した値（ＦＲとする）にする。すなわち、「’」が付いた不具合数ｂｉは改善施策反映後の不具合数とすると、ｂ６２’、ｂ７２’、ｂ８２’の値は以下の式を用いて算出できる。なお、以下の式は、詳細設計のレビュー施策の例である。
【０１０３】
b62’=FR×(b62+b72+b82)
b72’={(b72)/(b72+b82)}×{b62+b72+b82-b62’}
b82’={(b82)/(b72+b82)}×{b62+b72+b82-b62’}
この式によれば、b62’+b72’+b82’＝b62+b72+b82が成立している。即ち、不具合総数は同じである。
【０１０４】
そして、この改善施策反映後の不具合数ｂｉ’を用いて、上述の手順によって工程フローモデルのＴｉ，ｔｉ，総工数をプロセス改善施策後の値に更新する。
【０１０５】
以上のように、レビュー時間や網羅率を設定することにより、過去プロジェクトのデータを参照し、プロセス改善施策を評価することができる。  
すなわち、ステップＳ５０６において、結果出力部１６は、入出力装置２のモニタに評価結果を表示する。ここで表示する内容は、総工数、工程フローモデルのＴｉ、ｔｉの値、不具合マトリクス、以降の工程へ残った不具合数、プロセス改善施策のレビュー時間、網羅率、テスト設計工数、テスト実施工数、各工程の総工数の合計値である。
【０１０６】
ユーザは、この評価結果から、例えば各工程の総工数の合計値が施策前と比べて減少しているか否か、またその減少の程度を確認する。もし、各工程の総工数の合計値が減少しているとすれば、テスト内容を充実し更に不具合発生数の減少が図れているため、より品質、精度の良い開発をより少ない工数で実現することが可能なる。
【０１０７】
ステップＳ５０７でＹｅｓの場合、すなわち、評価を終了する場合は、プロセス改善施策評価装置１の動作を終了する。ユーザは、ここで得られた各工程に配分する工数、レビュー時間などをプロジェクトを推進する際の計画値として採用する。ステップＳ５０７でＮｏの場合、すなわち、評価を続ける場合は、ステップＳ５０８、Ｓ５０９を実行した後、ステップＳ５０６に戻り再度評価を行う。
【０１０８】
［実施の形態の効果］  
以上説明した実施の形態では、プロジェクト開発工程に初期工程と手戻り工程とをそれぞれ別の工程として導入し、それぞれの工程に要する工数を把握したモデルを作成した。その結果、プロセス改善施策を実施した場合の影響を事前にかつ定量的に評価することが可能である。また、プロセス改善施策を評価する精度を高めることができる。
【０１０９】
なお、上述の各実施の形態で説明した機能は、ハードウエアを用いて構成するに留まらず、ソフトウェアを用いて各機能を記載したプログラムをコンピュータに読み込ませて実現することもできる。また、各機能は、適宜ソフトウェア、ハードウエアのいずれかを選択して構成するものであっても良い。
【０１１０】
尚、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。  
上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【符号の説明】
【０１１１】
１…プロセス改善施策評価装置、２…入出力装置、１０…施策情報入力部、１１…教師プロジェクト選出部、１２…工程フローモデル部、１３…不具合情報抽出部、１４…工数情報抽出部、１５…工数計算部、１６…結果出力部１７…施策影響推定部、２０…制御部、２１…工数ＤＢ、２２…不具合ＤＢ、２３…プロジェクトＤＢ、２４…レビューテストＤＢ。
【図１】
2011198300.tif 000003
【図２】
2011198300.tif 000004
【図３】
2011198300.tif 000005
【図４】
2011198300.tif 000006
【図５】
2011198300.tif 000007
【図６】
2011198300.tif 000008
【図７】
2011198300.tif 000009
【図８】
2011198300.tif 000010
【図９】
2011198300.tif 000011
【図１０】
2011198300.tif 000012
【図１１】
2011198300.tif 000013
【図１２】
2011198300.tif 000014
【図１３】
2011198300.tif 000015
【図１４】
2011198300.tif 000016
【図１５】
2011198300.tif 000017
【図１６】
2011198300.tif 000018
【図１７】
2011198300.tif 000019
【図１８】
2011198300.tif 000020
【図１９】
2011198300.tif 000021
【図２０】
2011198300.tif 000022
【図２１】
2011198300.tif 000023
【図２２】
2011198300.tif 000024
【図２３】
2011198300.tif 000025
【図２４】
2011198300.tif 000026
【図２５】
2011198300.tif 000027
【図２６】
2011198300.tif 000028
【図２７】
2011198300.tif 000029