(57)【要約】【課題】プロジェクトの開発対象である開発対象システム（プログラム群）の品質指標と比較しての品質評価（バグ収束時期の評価）の可能な装置を提供する。【解決手段】障害収束予測装置１０００は、複数のプログラムから構成されるシステムに発生したバグのバグ発生件数と、前記システムに発生したバグのバグ発生時期とを含むバグ発生実績データを入力する実績データ入力部１ａと、前記システムに要求される品質を示す品質指標を入力するプロジェクト品質指標入力部１ｂと、実績データ入力部１ａが入力した前記バグ発生実績データから前記システムに将来発生するバグ件数を予測し、予測したバグ件数と品質指標入力部１ｂが入力した前記品質指標とに基づいて、バグの発生が収束する収束時期を予測する品質評価部１０とを備えた。【選択図】図１
2014174895.tif 000002
【特許請求の範囲】
【請求項１】
複数のプログラムから構成されるシステムに発生したバグのバグ発生件数と、前記システムに発生したバグのバグ発生時期とを含むバグ発生実績データを入力する実績データ入力部と、
前記システムに要求される品質を示す品質指標を入力するプロジェクト品質指標入力部と、
前記実績データ入力部が入力した前記バグ発生実績データから前記システムに将来発生するバグ件数を予測し、予測したバグ件数と前記プロジェクト品質指標入力部が入力した前記品質指標とに基づいて、バグの発生が収束する収束時期を予測する品質評価部と
を備えたことを特徴とするバグ収束予測装置。
【請求項２】
前記品質評価部は、
予測したバグの前記収束時期と前記プロジェクト品質指標入力部が入力した前記品質指標とに基づいて、前記収束時期における予め指定された品質の評価を実行することを特徴とする請求項１記載のバグ収束予測装置。
【請求項３】
前記プロジェクト品質指標入力部は、
前記システムの納入期限を含む品質指標を入力し、
前記品質評価部は、
予測した前記収束時期と、前記品質指標に含まれる前記システムの納入期限とを前記品質指標として比較し、比較の結果、前記収束時期が前記システムの納入期限よりも遅いときには、警告を発することを特徴とする請求項１または２のいずれかに記載のバグ収束予測装置。
【請求項４】
前記バグ収束予測装置は、
さらに、予め設定された品質対策を入力する品質対策入力部を備え、
前記品質評価部は、
前記品質対策入力部が入力した前記品質対策を用いて、前記品質対策の効果を算出することを特徴とする請求項１〜３のいずれかに記載のバグ収束予測装置。
【請求項５】
コンピュータを、
複数のプログラムから構成されるシステムに発生したバグのバグ発生件数と、前記システムに発生したバグのバグ発生時期とを含むバグ発生実績データを入力する実績データ入力部、
前記システムに要求される品質を示す品質指標を入力するプロジェクト品質指標入力部、
前記実績データ入力部が入力した前記バグ発生実績データから前記システムに将来発生するバグ件数を予測し、予測したバグ件数と前記プロジェクト品質指標入力部が入力した前記品質指標とに基づいて、バグの発生が収束する収束時期を予測する品質評価部、
として機能させるためのバグ収束予測プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、システムのバグ発生の収束時期を予測するバグ収束予測装置及びバグ収束予測プログラムに関する。
【背景技術】
【０００２】
従来技術（特許文献１）では、発生したバグ発生期日、件数を入力し、ゴンペルツ曲線を利用して潜在バグ数の推測を行う。しかしながら特許文献１は、潜在バグ数の推測の精度を上げて試験工程の計画に役立てることが目的であり、プロジェクトのテスト工程での進捗遅れの検知ができない（特許文献１）。また従来技術（特許文献２）では、実測データに最も適合するソフトウェア信頼モデルを選択すると共に、発生バグ数の推測値を見積りに使用しているが、試験工程への影響をシミュレーションできない（特許文献２）。
従来の障害収束予測はその名の通り、いかに正確に潜在バグ数を推測できるかに注力しており、プロジェクトの品質指標と比較しての品質評価機能や品質対策による試験工程への影響をシミュレーションする機能がなかった。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００３−１４０９２９号公報
【特許文献２】特開２００３−１８６７０１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
この発明は、プロジェクトの品質指標と比較しての品質評価や、品質対策による試験工程への影響をシミュレーションの可能な装置の提供を目的とする。
【課題を解決するための手段】
【０００５】
この発明のバグ収束予測装置は、
複数のプログラムから構成されるシステムに発生したバグのバグ発生件数と、前記システムに発生したバグのバグ発生時期とを含むバグ発生実績データを入力する実績データ入力部と、
前記システムに要求される品質を示す品質指標を入力するプロジェクト品質指標入力部と、
前記実績データ入力部が入力した前記バグ発生実績データから前記システムに将来発生するバグ件数を予測し、予測したバグ件数と前記プロジェクト品質指標入力部が入力した前記品質指標とに基づいて、バグの発生が収束する収束時期を予測する品質評価部と
を備えたことを特徴とする。
【発明の効果】
【０００６】
この発明により、プロジェクトの開発対象である開発対象システム（プログラム群）の品質指標と比較しての品質評価（バグ収束時期の評価）の可能な装置を提供できる。
【図面の簡単な説明】
【０００７】
【図１】実施の形態１の障害収束予測装置１０００の構成図。
【図２】実施の形態１の各入力部によるデータベース部への登録を示す図。
【図３】実施の形態１の品質評価部１０の動作を説明する図。
【図４】実施の形態１の各入力部への入力データ及び品質評価部１０の算出するデータをまとめた図。
【図５】実施の形態１のレポート、リストの出力のイメージを示す図。
【図６】実施の形態１の品質評価レポートの例を示す図。
【図７】実施の形態１の品質評価レポートの例を示す別の図。
【図８】実施の形態１の品質評価レポートの例を示す更に別の図。
【図９】実施の形態１の実績データ（ａ０）を示す図。
【図１０】実施の形態１のゴンペルツ曲線を構成するｉＤｃｅｎｔｅｒ、ＩＤ管理ＷＦ，その他のそれぞれのデータを示す図。
【図１１】実施の形態１のゴンペルツ曲線を構成するｉＤｃｅｎｔｅｒ、ＩＤ管理ＷＦ，その他のデータの合計値を示すデータを示す図。
【図１２】実施の形態２の障害収束予測装置１０００の外観を示す図。
【図１３】実施の形態２の障害収束予測装置１０００のハードウェア構成を示す図。
【発明を実施するための形態】
【０００８】
実施の形態１．
図１〜図１１を参照して、実施の形態１の障害収束予測・品質評価装置（以下、障害収束予測装置１０００という）を説明する。
図１は、障害収束予測装置１０００（バグ収束予測装置）の構成図である。
図２は、各入力部によるデータベース部への登録を示す図である。
図３は、品質評価部１０の動作を説明する図である。
図４は、実績データ入力部１ａ、プロジェクト品質指標入力部１ｂ及び品質対策入力部１ｃへ入力項目と、品質評価部１０が算出する算出項目とをまとめた図である。実績データ入力部１ａへの入力データは符号を「ａ０」とし、プロジェクト品質指標入力部１ｂへの入力データは符号を「ｂ０−〜」とし、品質対策入力部１ｃへ入力データは符号を「ｃ０−〜」として区別した。また、品質評価部１０による算出データは、符号を「１０−〜」とした。
図５は、障害収束予測装置１０００が出力する品質評価レポートのイメージをゴンペルツ曲線で表した図である。
図６〜図８は、障害収束予測装置１０００が出力する品質評価レポート（表形式）を示す図である。図６〜図８は報告日（図３のＳＴ７の作成の日）がそれぞれ、２０１２／２／２８、２０１２／２／１４、２０１２／１／１７である。
図９は、２０１１／５／１６（月曜日）〜２０１２／２／２０（月曜日）までの実績データ（ａ０）を示す図である。
図１０、図１１は、実績データ（ａ０）をもとにゴンペルツ曲線に展開されたデータを示す。なお各図の詳細は後述する。
【０００９】
図１に示すように、障害収束予測装置１０００は、「Ａ：実績データ」に関して、実績データ入力部１ａ、データベース部２ａ（実績）を備えている。また、「Ｂ：プロジェクト品質指標」に関して、障害収束予測装置１０００は、プロジェクト品質指標入力部１ｂ、データベース部２ｂ（プロジェクト品質指標）、データ分析部３ｂ（プロジェクト品質指標）を備えている。また、「Ｃ：品質対策」に関して、障害収束予測装置１０００は、品質対策入力部１ｃ、データベース部２ｃ（品質対策）を備えている。さらに、障害収束予測装置１０００は、品質評価部１０、品質評価表示部１１及びデータベース部１２（品質評価）を備えている。
【００１０】
なお実績データ入力部１ａ、プロジェクト品質指標入力部１ｂ及び品質対策入力部１ｃは、一つの入力部で実現しても構わない。また、データベース部２ａ、データベース部２ｂ，データベース部２ｃ及びデータベース部１２は一つのデータベース部で実現しても構わないし、複数のデータベース部で実現しても構わない。なお、データ分析部３ｂは、図４に示す出荷可能な目標残存バグ数Ｘ（１０−６）を、開発規模Ａ（ｂ０−２）と品質指標Ｂ（ｂ０−３）とを乗じて得るだけである。よってこの機能は品質評価部１０に持たせても構わない。以下では、品質評価部１０が目標残存バグ数Ｘ（１０−６）を算出するものとする。このため目標残存バグ数Ｘの符号を（１０−６）とした。
【００１１】
（Ａ：実績データの入力、ＤＢへの登録）
図９は、「ｉＤｃｅｎｔｅｒ」，「ＩＤ管理ＷＦ」及び「その他」の、それぞれの実績データ（ａ０）である。実績データ（ａ０）とは、そのシステムの発生バグ件数の時系列データである。図９の例では、実績データ（ａ０）とは期間毎（１週間ごと）に発生したバグ発生件数（図９では累積発生件数）である。一つのプロジェクトは、複数のシステム（ソフトウェアの集合体）からなる。図９の場合、一つのプロジェクトが、「ｉＤｃｅｎｔｅ」、「ＩＤ管理ＷＦ」及びこれら以外の「その他」の３つのシステムから構成されることを示している。そして、「ｉＤｃｅｎｔｅ」、「ＩＤ管理ＷＦ」、「その他」等は、いずれも複数のソフトウェア（プログラム）から成り立っている。図９の１行目の「２０１１／５／１６」（経過週の基準日）は、「２０１１／５／１６」（月）を先頭とする１週間、つまり２０１１／５／１６（月曜）〜２０１１／５／２２（日曜）の間に、「ｉＤｃｅｎｔｅｒ」、「ＩＤ管理ＷＦ」、「その他」のそれぞれに発生したバグ（障害）が１６，９，６件であることを示す。図９の２行目は、２０１１／５／２３（月曜）〜２０１１／５／２９（日曜）の間に、「ｉＤｃｅｎｔｅｒ」、「ＩＤ管理ＷＦ」、「その他」のそれぞれに発生した累積バグ件数が３７，１３，１０件であることを示す。前回週（累積）と今週（累積）との差分が今週のバグ発生件数であるので、２０１１／５／２３（月曜）の週の「ｉＤｃｅｎｔｅｒ」等のバグ発生件数は、２１，４，４である。
（１）実績データ入力部１ａは、毎週、図９の行に相当する、経過週毎の実績データ（ａ０）を入力する。図２に示すように、実績データ入力部１ａは、実績データ入力（ＳＴ９）として入力されたデータ（バグ発生件数、バグ発生期日の他、バグ内容、プロジェクト名など）を、データベース部２ａにデータ登録（ＳＴ１０）する。
（２）データベース部２ａは、実績データ入力部１ａが入力した図９に示す実績データ（ａ０）（発生バグ数、発生期間等）を保管する。
【００１２】
（Ｂ：プロジェクト品質指標の入力、ＤＢへの登録）
プロジェクト品質指標入力部１ｂ、データベース部２ｂ及びデータ分析部３ｂは、プロジェクト品質指標の関する構成要素である。なお上記のようにデータ分析部３ｂの機能は品質評価部１０にも持たせるので、データ分析部３ｂの説明は省略する。なお、品質評価部１０に持たせるデータ分析部３ｂの機能は、図４の目標残存バグ数Ｘ（１０−６）を算出することであるが、これは予め計算しておき、プロジェクト品質指標入力部１ｂからの入力データに加えても構わない。
（１）プロジェクト品質指標入力部１ｂは、プロジェクト品質指標を入力する。「プロジェクト品質指標」とは、プロジェクトの「目標品質」であり、図４に示すプロジェクト品質指標入力部１ｂの入力項目である。図４に示すように、入力項目は以下のものがある。プロジェクト名（ｂ０−１）、開発規模Ａ（ｂ０−２）、品質指標Ｂ（ｂ０−３）、納期Ｄ（ｂ０−４）、言語、などである。図６〜図８に示す品質評価レポートの中に入力項目の開発規模Ａ（ｂ０−２）、目標残存バグ数Ｘ（１０−６）（残存バグ件数）、品質指標Ｂ（ｂ０−３）が、記載されている。例えば「ｉＤｃｅｎｔｅｒ」の場合は、それぞれ１５０ｋｓｔｅｐｓ，３件、０．０２（件／ステップ）である。図２に示すように、プロジェクト品質指標入力部１ｂは、プロジェクト品質指標入力（ＳＴ１１）として入力されたデータ（プロジェクト名（ｂ０−１）〜納期Ｄ（ｂ０−４）等）をデータベース部２ｂにデータ登録（ＳＴ１２）する。
（２）データベース部２ｂは、プロジェクト品質指標入力部１ｂが入力したプロジェクト品質指標を保管する。
【００１３】
（Ｃ：品質対策）
品質対策入力部１ｃ、データベース部２ｃは、品質対策に関する構成要素である。
（１）図２に示すように、品質対策入力部１ｃは、品質対策を入力する（ＳＴ１３）。入力する品質対策の項目としては、図４に示すように、例えば、品質対策内容（ｃ０−１）（テスト要員増強、追加テストの実施等）及び品質対策実施時期（ｃ０−２）（年月日）などである。
（２）データベース部２ｃは、品質対策入力部１ｃが入力した品質対策の項目を保管する（ＳＴ１４）。
【００１４】
（品質評価部１０の動作）
品質評価部１０は、実績データ入力部１ａ、プロジェクト品質指標入力部１ｂ，品質対策入力部１ｃのそれぞれから入力されてデータベースに格納された入力データを用いて品質評価を行い、品質評価の結果を品質評価表示部１１によって表示する。また、品質評価部１０は、品質評価結果（図６〜図８に示す品質評価レポートの内容）をデータベース部１２に保管する。
【００１５】
図３は品質評価部１０の動作を示すフローチャートである。次に図３を参照して、品質評価部１０の動作を説明する。品質評価部１０は、入力されたプロジェクト品質指標を満たす、もっとも早い未来の出荷可能日（経過週の基準日）を、障害収束日（１０−３）（収束時期の一例）として求める。この障害収束日（１０−３）の求め方を以下に説明する。
【００１６】
（ＳＴ１）品質評価部１０は、評価対象期間を入力（ＳＴ１）する。ここで「評価対象期間」とは、品質評価の対象期間（ある年月日〜ある年月日）である。
（ＳＴ２）品質評価部１０は、評価対象期間に従ってデータベース部２ａから実績データ（ａ０）の抽出を行う（ＳＴ２）。
（ＳＴ３）品質評価部１０は、ＳＴ２で抽出した実績データ（ａ０）をゴンペルツ曲線に展開して、障害収束日（１０−３）や残存バグ数の計算などデータ分析を行う（ＳＴ３）。以下に具体的に説明する。品質評価部１０はＳＴ３において以下の（３．１）〜（３．３）の処理を行う。
（３．１）ゴンペルツ曲線への展開．
（３．１．１）経過週毎の障害発生件数（１０−１）の算出．
品質評価部１０は、実績データ（ａ０）をゴンペルツ曲線に展開することで、経過週毎の障害発生件数（１０−１）を算出する。ゴンペルツ曲線における値を示す図１０の「ｉＤｃｅｎｔｅｒ」の場合は、大項目の「ｉＤｃｅｎｔｅｒ」に含まれる小項目の「ｉＤｃｅｎｔｅｒ」の列の数値が経過週毎の障害発生件数（１０−１）である。小項目の「ｉＤｃｅｎｔｅｒ」の場合は、１、２行目の２０１１／５／１６、２０１１／５／２３の値は、３２、４４であるが、これらは経過週毎の障害発生件数（１０−１）の累積値である。よって３２と４４との差分である１２が、２０１１／５／１６〜２０１１／５／２３の１週間に発生した障害（バグ）である。
（３．１．２）障害収束件数（１０−２）の算出．
品質評価部１０は、実績データ（ａ０）をゴンペルツ曲線に展開し、障害が収束する障害収束件数（１０−２）（累積のバグ発生件数の予想収束値）を算出する。図１０では、「ｉＤｃｅｎｔｅｒ」、「ＩＤ管理ＷＦ」、「その他」のそれぞれの障害収束件数（１０−２）は、上部に示すａ，ｂ，ｃのうちのａの値である。例えば「ｉＤｃｅｎｔｅｒ」では「ａ＝４０８．９６７１７８３」が「ｉＤｃｅｎｔｅｒ」の障害収束件数（１０−２）である。「ｉＤｃｅｎｔｅｒ」では障害収束件数（１０−２）＝「ａ＝４０８．９６７１７８３」＝「４０８」
とする。
（３．２）経過週毎の障害残数Ｃ（１０−４）の算出．
品質評価部１０は、経過週毎の障害残数Ｃ（１０−４）を求める。
障害残数Ｃ（１０−４）は以下の式（１）で求める。
経過週毎の障害残数Ｃ（１０−４）＝障害収束件数（１０−２）−経過週毎の障害発生件数（１０−１）    式（１）
図１０の「ｉＤｃｅｎｔｅｒ」の場合は、障害収束件数（１０−２）＝「４０８」から、経過週毎の障害発生件数（１０−１）である小項目の「ｉＤｃｅｎｔｅｒ」の列の各値を引いた値が、それぞれの経過週毎の障害残数Ｃ（１０−４）である。図１０の「ｉＤｃｅｎｔｅｒ」の場合は、後述のように「２０１２／３／１９」が出荷可能日（収束時期）として決定されることになるが、この「２０１２／３／１９」における経過週の障害発生件数（１０−１）は「４０５」である。よって、「２０１２／３／１９」における経過週の障害残数Ｃ（１０−４）＝４０８−４０５＝３である。図１０では「２０１２／３／１９」の「ｉＤｃｅｎｔｅｒ」の行が「３」ではなく「２．９」となっている。これは計算に用いた障害収束件数（１０−２）が「ａ＝４０８．９６７１７８７３」であり、「２０１２／３／１９」の障害発生件数（１０−１）も小数点以下を有する数値を用いたこと、及び数値の丸め方による。
（３．３）経過週毎の障害品質指標Ｙ（１０−５）の算出．
品質評価部１０は、経過週毎の障害品質指標Ｙ（１０−５）を以下の式（２）で求める。
経過週毎の障害品質指標Ｙ（１０−５）＝経過週毎の障害残数Ｃ（１０−４）÷開発規模Ａ（ｂ０−２）      式（２）
つまり、品質評価部１０は、上記（３．２）で求めた経過週毎のそれぞれの障害残数Ｃ（１０−４）を開発規模Ａ（ｂ０−２）で除することで、経過週毎の障害品質指標Ｙ（１０−５）を求める。図１０の「ｉＤｃｅｎｔｅｒ」の場合は、後述のように「２０１２／３／１９」が出荷可能日として決定されることになるが、この「２０１２／３／１９」における経過週の障害残数Ｃ（１０−４）は「２．９」である。よって、「２０１２／３／１９」における障害品質指標Ｙ（１０−５）は、この２．９を「ｉＤｃｅｎｔｅｒ」の開発規模１５０（ｋＳｔｅｐｓ）（図４）で除すことで、「０．０１９（件／ステップ）」として得られる。
【００１７】
（ＳＴ４）品質評価部１０は、指定の納期Ｄ（ｂ０−４）や目標残存バグ数Ｘ（１０−６、品質指標Ｂ（ｂ０−３）など、プロジェクト品質指標をデータベース部２ｂから抽出を行う。
また、データベース部２ｃに品質対策の登録がされている場合には、品質対策をデータベース部２ｃから抽出して品質分析を実施する。例えば、品質評価部１０は、品質分析として、データ分析（後述のＳＴ３〜ＳＴ７）で蓄積された品質対策を、入力データである品質対策実施時期（ｃ０―２）の前後の品質評価レポート（図６〜図８等）を抽出する。例えば「品質対策実施時期（ｃ０―２）＝２０１２／２／１」とすると、品質評価部１０は、「２０１２／２／１」よりも後の図７（２０１２／２／１４）の品質評価レポートと、「２０１２／２／１」よりも前の図８（２０１２／１／１７）の品質評価レポートを抽出する。そして、品質評価部１０は、抽出した品質評価レポートを対象として、到達時期の比較を行う。
（ＳＴ４−１）品質評価部１０は、ＳＴ３の分析結果と、ＳＴ４で抽出した品質指標との比較を行う（ＳＴ４−１）。
（４−１．１）障害残数Ｃ（１０−４）、障害品質指標Ｙ（１０−５）と品質指標との比較．
品質評価部１０は、上記（３．２）で算出した経過週毎の障害残数Ｃ（１０−４）及び上記（３．３）で算出した障害品質指標Ｙ（１０−５）を、それぞれ目標残存バグ数Ｘ（１０−６）、品質指標Ｂ（ｂ０−３）と比較する。つまり、下記の式（３）かつ式（４）を満たす将来（未来）の経過週のうち最も過去（最も早く出荷できる未来の経過週）の経過週を、出荷可能な障害収束日（１０−３）（収束時期）として特定する。
障害残数Ｃ（１０−４）≦目標残存バグ数Ｘ（１０−６）    式（３）
かつ、
障害品質指標Ｙ（１０−５）≦品質目標Ｂ（ｂ０−３）    式（４）
図１０では、「ｉＤｃｅｎｔｅｒ」単独については、品質評価部１０が障害収束日（１０−３）（収束時期）として、「２０１２／３／１９」を特定（予測）した例を示している。品質評価部１０が特定した障害収束日（１０−３）は図６〜図８の品質評価レポートにおける「到達時期」である。
（ＳＴ５）品質評価部１０は、障害収束日が納期以降かどうかを判定する（ＳＴ５）。図１０の「ｉＤｃｅｎｔｅｒ」の場合、品質評価部１０は、障害収束日（１０−３）を「２０１２／３／１９」と予測したが、ＳＴ５において、品質評価部１０は障害収束日（１０−３）と、指定の納期Ｄ（ｂ０−４）とを比較して、障害収束日（１０−３）が納期Ｄ（ｂ０−４）以降かどうかを判定する。
（ＳＴ６）品質評価部１０は、ＳＴ５の判定結果から、予測した障害収束日が「指定の納期Ｄ（ｂ０−４）」以降の場合（ＳＴ５：ＹＥＳ）は、警告リストを作成する（ＳＴ６）。
（ＳＴ７）品質評価部１０は、算出した障害収束日（１０−３）が納期以前であるか納期以降であるかに関係なく、品質評価レポート（図６〜図８）を作成し（ＳＴ５：ＹＥＳ、ＮＯ）、作成した品質評価レポートをデータベース部に登録する。ここで図６の品質評価レポートについて説明する。図７、図８についても図６と同じである。図６は、「ｉＤｃｅｎｔｅｒ」，「ＩＤ管理ＷＦ」、「その他」のそれぞれについての評価結果、及び入力であるプロジェクト品質指標が記載されている。左列の報告日は、この品質評価レポートの作成日である。開発規模は、図４にまとめた開発規模Ａ（ｂ０−２）のことである。収束バグ累積件数とは、図１０の品質評価部１０の上部に「ａ」として示すゴンペルツ曲線への展開で求められる収束値である。目標品質の到達時期は、「ｉＤｃｅｎｔｅｒ」を例に説明した障害収束日（１０−３）（出荷可能日）である目標品質の残存バグ数は、図４にまとめた残存バグ数Ｘ（１０−６）のことである。目標品質の品質指標は、図４にまとめた品質指標Ｂ（ｂ０−３）のことである。
【００１８】
（ＳＴ８）また品質評価部１０は、ＳＴ３で生成した品質評価の際に、品質対策の効果も計算し、データベース部に登録する（ＳＴ８）。
【００１９】
なお図５は、障害収束予測装置１０００が出力する品質評価レポートのイメージをゴンペルツ曲線で表した図である。図５は図６の品質評価レポートに対応する。図５の各グラフは、一番上が「計」、「ｉＤｃｅｎｔｅｒ」、「ＩＤ管理ＷＦ」のバグ累積件数を示している。また報告日２／２８は、図６の報告日２０１２／２／２８のことである。また収束予想日２０１２／３／５は、図６の「計」での到達時期２０１２／３／５のことである。「計」での到達時期とは、「ｉＤｃｅｎｔｅｒ」、「ＩＤ管理ＷＦ」、「その他」を全体で一つとして見たときに、全体のプロジェクト品質指標を満たす到達時期（「ｉＤｃｅｎｔｅｒ」のみの場合の２０１２／３／１９に相当）時期である。
【００２０】
以上の実施の形態１の障害収束予測装置１０００によれば、以下の効果がある。
・発生した障害（バグ）件数（サイクル：週、日）と、プロジェクト品質指標（開発規模、ＳＴＥＰ辺りの障害（バグ）発生件数）とにより、各々の障害収束予測をし、比較することで、品質評価を行い、テスト進捗の警告や品質評価レポートを出力することができる。
・また障害収束予測装置１０００に品質対策内容と対策実施日などを入力し、品質対策の効果を数値化するので、対策の効果を評価することができる。
またこれらの効果により、早期にテスト方法の見直しや追加テストが判断でき、リソース（要員）増加の計画的な対応が可能となる。
またデータベースに蓄積した過去データや障害収束予想を別プロジェクトのシミュレーションや類似ケース検索で活用し、品質対策の工数、費用削減に役立てることができる。
【００２１】
実施の形態２．
図１２、図１３を参照して実施の形態２を説明する。実施の形態２は、コンピュータである障害収束予測装置１０００のハードウェア構成を説明する。
図１２は、コンピュータである障害収束予測装置１０００の外観の一例を示す図である。
図１３は、障害収束予測装置１０００のハードウェア資源の一例を示す図である。
【００２２】
外観を示す図１２において、障害収束予測装置１０００は、システムユニット８３０、ＣＲＴ（Ｃａｔｈｏｄｅ・Ｒａｙ・Ｔｕｂｅ）やＬＣＤ（液晶）の表示画面を有する表示装置８１３、キーボード８１４（Ｋｅｙ・Ｂｏａｒｄ：Ｋ／Ｂ）、マウス８１５、コンパクトディスク装置８１８（ＣＤＤ：Ｃｏｍｐａｃｔ  Ｄｉｓｋ  Ｄｒｉｖｅ）などのハードウェア資源を備え、これらはケーブルや信号線で接続されている。システムユニット８３０はネットワークに接続している。
【００２３】
またハードウェア資源を示す図１３において、障害収束予測装置１０００は、プログラムを実行するＣＰＵ８１０（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）を備えている。ＣＰＵ８１０は、バス８２５を介してＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）８１１、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）８１２、表示装置８１３、キーボード８１４、マウス８１５、通信ボード８１６、ＣＤＤ８１８、磁気ディスク装置８２０と接続され、これらのハードウェアデバイスを制御する。磁気ディスク装置８２０の代わりに、光ディスク装置、フラッシュメモリなどの記憶装置でもよい。
【００２４】
ＲＡＭ８１２は、揮発性メモリの一例である。ＲＯＭ８１１、ＣＤＤ８１８、磁気ディスク装置８２０等の記憶媒体は、不揮発性メモリの一例である。これらは、「記憶装置」あるいは記憶部、格納部、バッファの一例である。通信ボード８１６、キーボード８１４などは、入力部、入力装置の一例である。また、通信ボード８１６、表示装置８１３などは、出力部、出力装置の一例である。通信ボード８１６は、ネットワークに接続されている。
【００２５】
磁気ディスク装置８２０には、オペレーティングシステム８２１（ＯＳ）、ウィンドウシステム８２２、プログラム群８２３、ファイル群８２４が記憶されている。プログラム群８２３のプログラムは、ＣＰＵ８１０、オペレーティングシステム８２１、ウィンドウシステム８２２により実行される。
【００２６】
上記プログラム群８２３には、以上の実施の形態の説明において「〜部」として説明した機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ８１０により読み出され実行される。
【００２７】
ファイル群８２４には、以上の実施の形態の説明において、「〜の判定結果」、「〜の算出結果」、「〜の抽出結果」、「〜の生成結果」、「〜の処理結果」として説明した情報や、データや信号値や変数値やパラメータなどが、「〜ファイル」や「〜データベース」の各項目として記憶されている。「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。実施の形態１で述べたデータベース部は、ファイル群８２４によって実現される。また、ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ８１０によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示などのＣＰＵの動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。
【００２８】
また、以上に述べた実施の形態の説明において、データや信号値は、ＲＡＭ８１２のメモリ、ＣＤＤ８１８のコンパクトディスク、磁気ディスク装置８２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ（Ｄｉｇｉｔａｌ・Ｖｅｒｓａｔｉｌｅ・Ｄｉｓｋ）等の記録媒体に記録される。また、データや信号は、バス８２５や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
【００２９】
また、以上の実施の形態の説明において、「〜部」として説明したものは、「〜手段」、であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」として説明したものは、ソフトウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。プログラムはＣＰＵ８１０により読み出され、ＣＰＵ８１０により実行される。すなわち、プログラムは、以上に述べた「〜部」としてコンピュータを機能させるものである。あるいは、以上に述べた「〜部」の手順や方法をコンピュータに実行させるものである。
【００３０】
以上の実施の形態では、障害収束予測装置１０００を説明したが、障害収束予測装置１０００は、コンピュータを障害収束予測装置１０００として機能させるためのプログラムとしても把握できることは以上の説明から当然である。また、障害収束予測装置１０００の各「〜部」の動作は、障害収束予測方法としても把握できることは以上の説明により明らかである。
【符号の説明】
【００３１】
１０００  障害収束予測装置、１ａ  実績データ入力部、１ｂ  プロジェクト品質指標入力部、１ｃ  品質対策入力部、２ａ，２ｂ，２ｃ  データベース部、３ａ，３ｂ，３ｃ  データ分析部、１０  品質評価部、１１  品質評価表示部、１２  データベース部。
【図１】
2014174895.tif 000003
【図２】
2014174895.tif 000004
【図３】
2014174895.tif 000005
【図４】
2014174895.tif 000006
【図５】
2014174895.tif 000007
【図６】
2014174895.tif 000008
【図７】
2014174895.tif 000009
【図８】
2014174895.tif 000010
【図９】
2014174895.tif 000011
【図１０】
2014174895.tif 000012
【図１１】
2014174895.tif 000013
【図１２】
2014174895.tif 000014
【図１３】
2014174895.tif 000015