(57)【要約】【課題】ソフトウェアシステムで生じた様々な障害についての対策を施す優先順位を様々な要因を考慮して決定することのできるシステムを提供する。【解決手段】障害管理システム２には、障害についての３つの評価項目を４段階で評価する指標データを含む障害データの入力を受け付ける障害データ入力受付部２１０と、障害データを格納する障害データ保持部２２０と、障害対策を施すべき順序で障害データの優先順位付けを行う障害データ優先順位付け部２３０と、上記３つの評価項目に対する各顧客の要求の強さやユーザにとっての顧客の重要さを示す顧客プロファイルデータの入力を受け付ける顧客プロファイルデータ入力受付部２４０と、顧客プロファイルデータを格納する顧客プロファイルデータ保持部２５０とが設けられる。障害データ優先順位付け部２３０は、上記３つの評価項目の評価値に基づいて障害データの優先順位付けを行う。【選択図】図７
2009181536.tif 000002
【特許請求の範囲】
【請求項１】
ソフトウェアの障害の管理を行うための障害管理装置であって、
前記ソフトウェアの障害に関する情報である障害データであって障害についての複数の評価項目を複数の評価段階で評価するための指標データを含む前記障害データの入力を受け付ける障害データ入力受付手段と、
前記障害データ入力受付手段によって受け付けられた障害データを格納する障害データ保持手段と、
障害データ毎に前記指標データを用いて算出される障害評価値に基づいて、前記障害データ保持手段に格納されている障害データの順位付けを行う障害データ順位付け手段と
を備えることを特徴とする、障害管理装置。
【請求項２】
前記障害データ入力受付手段は、前記複数の評価項目としての３つの評価項目について、前記複数の評価段階としての４段階の指標値のうちのいずれかの入力を受け付ける指標値入力受付手段を含み、
前記障害データ順位付け手段は、各障害データについて、前記指標値入力受付手段によって受け付けられた指標値に基づいて前記障害評価値を算出することを特徴とする、請求項１に記載の障害管理装置。
【請求項３】
前記ソフトウェアの顧客に関する情報である顧客プロファイルデータであって各顧客についての前記複数の評価項目に対する要求度合を示す要求度合データを含む前記顧客プロファイルデータの入力を受け付ける顧客プロファイルデータ入力受付手段を更に備え、
前記障害データ順位付け手段は、前記顧客プロファイルデータ入力受付手段によって受け付けられた要求度合データに基づいて前記障害評価値を算出することを特徴とする、請求項２に記載の障害管理装置。
【請求項４】
前記障害データ順位付け手段は、各障害データについて、前記３つの評価項目の指標値と各顧客についての前記要求度合データとに基づいて、顧客毎に定められる値である顧客別評価値を算出し、当該各障害データと対応付けられている顧客のみについての前記顧客別評価値に基づいて前記障害評価値を算出することを特徴とする、請求項３に記載の障害管理装置。
【請求項５】
前記顧客プロファイルデータ入力受付手段は、前記ソフトウェアの顧客を複数の段階に区分するための顧客ランクデータの入力を受け付ける顧客ランクデータ入力受付手段を含み、
前記障害データ順位付け手段は、前記顧客ランクデータ入力受付手段によって受け付けられた前記顧客ランクデータに基づいて前記障害評価値を算出することを特徴とする、請求項３または４に記載の障害管理装置。
【請求項６】
ソフトウェアのテストの管理を行うためのテスト管理装置であって、
繰り返しテストが実施される複数のテストケースを格納するテストケース保持手段と、
請求項１から５までのいずれか１項に記載の障害管理装置の障害データ保持手段に格納され前記複数のテストケースのいずれかと対応付けられている障害データの指標データに基づいて算出される前記障害評価値を取得する障害評価値取得手段と、
前記障害評価値取得手段によって取得された障害評価値に基づいて、前記テストケース保持手段に格納されている前記複数のテストケースから今回テストが実施されるべきテストケースを抽出する第１のテストケース抽出手段と
を備えることを特徴とする、テスト管理装置。
【請求項７】
テストケースの抽出に関する条件を設定するためのパラメータ値の入力を受け付けるパラメータ値入力受付手段を更に備え、
前記第１のテストケース抽出手段は、
各テストケースと対応付けられている障害データについての前記障害評価値に基づいて、前記テストケース保持手段に格納されているテストケースの順位付けを行う第１のテストケース順位付け手段と、
前記パラメータ値入力受付手段によって受け付けられたパラメータ値と前記第１のテストケース順位付け手段による順位付けの結果とに基づいて、今回テストが実施されるべきテストケースを抽出する第１の抽出手段と
を含むことを特徴とする、請求項６に記載のテスト管理装置。
【請求項８】
ソフトウェアの要求仕様に関する情報である要求管理データであって所定の要求管理データ保持手段に格納され前記複数のテストケースのいずれかと対応付けられている前記要求管理データに含まれる、各要求仕様を複数の段階に区分するための要求仕様ランクデータに基づいて、前記テストケース保持手段に格納されている前記複数のテストケースから今回テストが実施されるべきテストケースを抽出する第２のテストケース抽出手段を更に備え、
前記パラメータ値入力受付手段によって受け付けられたパラメータ値に応じて、前記第１のテストケース抽出手段によるテストケースの抽出又は前記第２のテストケース抽出手段によるテストケースの抽出のいずれかが実行されることを特徴とする、請求項７に記載のテスト管理装置。
【請求項９】
ソフトウェアの障害の管理を行うための障害管理プログラムであって、
前記ソフトウェアの障害に関する情報である障害データであって障害についての複数の評価項目を複数の評価段階で評価するための指標データを含む前記障害データの入力を受け付ける障害データ入力受付ステップと、
前記障害データ入力受付ステップで受け付けられた障害データを所定の障害データ保持手段に格納する障害データ格納ステップと、
障害データ毎に前記指標データを用いて算出される障害評価値に基づいて、前記障害データ保持手段に格納されている障害データの順位付けを行う障害データ順位付けステップと、
をコンピュータのＣＰＵがメモリにおいて実行させる、障害管理プログラム。
【請求項１０】
前記障害データ入力受付ステップでは、前記複数の評価項目としての３つの評価項目について、前記複数の評価段階としての４段階の指標値のうちのいずれかの入力が受け付けられ、
前記障害データ順位付けステップでは、各障害データについて、前記障害データ入力受付ステップで受け付けられた前記３つの評価項目の指標値に基づいて前記障害評価値が算出されることを特徴とする、請求項９に記載の障害管理プログラム。
【請求項１１】
前記ソフトウェアの顧客に関する情報である顧客プロファイルデータであって各顧客についての前記複数の評価項目に対する要求度合を示す要求度合データを含む前記顧客プロファイルデータの入力を受け付ける顧客プロファイルデータ入力受付ステップを更に含み、
前記障害データ順位付けステップでは、前記顧客プロファイルデータ入力受付ステップで受け付けられた要求度合データに基づいて前記障害評価値が算出されることを特徴とする、請求項１０に記載の障害管理プログラム。
【請求項１２】
前記障害データ順位付けステップでは、各障害データについて、前記３つの評価項目の指標値と各顧客についての前記要求度合データとに基づいて、顧客毎に定められる値である顧客別評価値が算出され、当該各障害データと対応付けられている顧客のみについての前記顧客別評価値に基づいて前記障害評価値が算出されることを特徴とする、請求項１１に記載の障害管理プログラム。
【請求項１３】
前記顧客プロファイルデータ入力受付ステップでは、前記ソフトウェアの顧客を複数の段階に区分するための顧客ランクデータの入力が受け付けられ、
前記障害データ順位付けステップでは、前記顧客ランクデータ入力受付ステップで受け付けられた前記顧客ランクデータに基づいて前記障害評価値が算出されることを特徴とする、請求項１１または１２に記載の障害管理プログラム。
【請求項１４】
ソフトウェアのテストの管理を行うためのテスト管理プログラムであって、
所定のテストケース保持手段に格納され繰り返しテストが実施される複数のテストケースのいずれかと対応付けられた障害データに含まれる指標データであって障害についての複数の評価項目を複数の評価段階で評価するための前記指標データに基づいて算出される障害評価値を取得する障害評価値取得ステップと、
前記障害評価値取得ステップで取得された障害評価値に基づいて、前記テストケース保持手段に格納されている前記複数のテストケースから今回テストが実施されるべきテストケースを抽出する第１のテストケース抽出ステップと
をコンピュータのＣＰＵがメモリにおいて実行させる、テスト管理プログラム。
【請求項１５】
テストケースの抽出に関する条件を設定するためのパラメータ値の入力を受け付けるパラメータ値入力受付ステップを更に含み、
前記第１のテストケース抽出ステップは、
各テストケースと対応付けられている障害データについての前記障害評価値に基づいて、前記テストケース保持手段に格納されているテストケースの順位付けを行う第１のテストケース順位付けステップと、
前記パラメータ値入力受付ステップで受け付けられたパラメータ値と前記第１のテストケース順位付けステップでの順位付けの結果とに基づいて、今回テストが実施されるべきテストケースを抽出する第１の抽出ステップと
を含むことを特徴とする、請求項１４に記載のテスト管理プログラム。
【請求項１６】
ソフトウェアの要求仕様に関する情報である要求管理データであって所定の要求管理データ保持手段に格納され前記複数のテストケースのいずれかと対応付けられている前記要求管理データに含まれる、各要求仕様を複数の段階に区分するための要求仕様ランクデータに基づいて、前記テストケース保持手段に格納されている前記複数のテストケースから今回テストが実施されるべきテストケースを抽出する第２のテストケース抽出ステップを更に含み、
前記パラメータ値入力受付ステップで受け付けられたパラメータ値に応じて、前記第１のテストケース抽出ステップによるテストケースの抽出又は前記第２のテストケース抽出ステップによるテストケースの抽出のいずれかが実行されることを特徴とする、請求項１５に記載のテスト管理プログラム。
【請求項１７】
ソフトウェアの障害の管理を行うための障害管理方法であって、
前記ソフトウェアの障害に関する情報である障害データであって障害についての複数の評価項目を複数の評価段階で評価するための指標データを含む前記障害データの入力を受け付ける障害データ入力受付ステップと、
前記障害データ入力受付ステップで受け付けられた障害データを所定の障害データ保持手段に格納する障害データ格納ステップと、
障害データ毎に前記指標データを用いて算出される障害評価値に基づいて、前記障害データ保持手段に格納されている障害データの順位付けを行う障害データ順位付けステップと、
を含むことを特徴とする、障害管理方法。
【請求項１８】
ソフトウェアのテストの管理を行うためのテスト管理方法であって、
所定のテストケース保持手段に格納され繰り返しテストが実施される複数のテストケースのいずれかと対応付けられた障害データに含まれる指標データであって障害についての複数の評価項目を複数の評価段階で評価するための前記指標データに基づいて算出される障害評価値を取得する障害評価値取得ステップと、
前記障害評価値取得ステップで取得された障害評価値に基づいて、前記テストケース保持手段に格納されている前記複数のテストケースから今回テストが実施されるべきテストケースを抽出する第１のテストケース抽出ステップと、
を含むことを特徴とする、テスト管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアシステムで生じる障害を管理する障害管理装置およびソフトウェアシステムの開発や保守の際に行われるテストを管理するテスト管理装置に関する。
【背景技術】
【０００２】
従来より、ソフトウェアシステムに関して、開発中あるいは開発後に、「不具合」、「バグ」などと呼ばれる障害が生じることが多々ある。このような障害の中には、比較的容易に修正が可能なものもあれば、原因がわからない等の理由により修正が困難なものもある。また、当該ソフトウェアシステムを使用する顧客に与える影響の大きい障害もあれば、そのような影響の小さい障害もある。このような様々な障害への対策の優先順位を決定するために、障害データ（障害の発生日や障害の内容などの障害に関する情報の集合）に障害の影響度を示す情報（値など）を予め含めておくことが従来よりなされている。例えば、各障害について「１．致命的、２．重要、３．軽微」という３段階で評価した値が障害データに含められ、当該評価値が「１」の障害については優先順位が高くされ、当該評価値が「３」の障害については優先順位が低くされている。なお、以下の説明においては、いずれの障害から対策を施すべきかということが把握されるよう障害データに順位を付けることを「優先順位付け」といい、その処理のことを「優先順位付け処理」という。
【０００３】
また、ソフトウェアシステムの開発技法として、「ウォーターフォール型開発技法」、「プロトタイプ型開発技法」、「スパイラル型開発技法」など様々な技法が知られている。これら様々な開発技法によるソフトウェアシステムの開発工程には、「要件定義」、「設計」、「プログラミング」、「テスト」などの工程（フェーズ）が含まれている。これらの各工程のうちソフトウェアシステムのテストは、一般的にはテスト仕様書に基づいて行われる。テスト仕様書には、テストケース毎に、テストの方法や合否（成功または失敗）を判定するための条件などが記載されている。
【０００４】
ソフトウェアシステムの開発においては、上述した各工程が繰り返されることがある。このような場合、開発当初に作成されたテストケースあるいは仕様変更等に伴って作成されたテストケースについて、繰り返しテストが行われる。また、障害が発生した場合には、当該障害の修正が正しく施されているかを確認するテスト（以下、「修正確認テスト」という。）のためのテストケースが作成され、そのようなテストケースについても繰り返しテストが行われる。例えば、或るシステムに関し、バージョン１（Ｖｅｒ１）からバージョン２（Ｖｅｒ２）へのバージョンアップがあったと仮定する。このような場合、バージョンアップに基づく回帰テスト・シナリオテスト・機能テストに加え、バージョン１で生じた障害の修正確認テストやバージョン２の開発中に生じた障害の修正確認テストも行われるべきである（図３５参照）。ところが、開発期間や人的資源等の制約上、「全てのテストケースについてテストする」ということが困難な場合がある。このような場合、例えば、過去に実施されたテストの結果に基づいて、今回のフェーズでテストの対象とするべきテストケースの（全テストケースの中からの）抽出が行われている。例えば、特開２００７−１０２４７５号公報には、過去のテスト結果を考慮して好適なテストケースを効率良く抽出することができるテストケース抽出装置についての発明が開示されている。
【特許文献１】特開２００７−１０２４７５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
障害の影響度を示す（例えば）３段階の評価値のみに基づいて障害への対策の優先順位が決定される上記従来技術のような構成においては、上記評価値が同じであれば、頻繁に発生する障害とほとんど発生しない障害とが障害対策の優先順位の決定の際に区別されることがない。また、例えば障害後のシステムの再起動に関して、早期の復旧を要求する顧客もあれば、そうでない顧客もある。しかしながら、そのような顧客の要求を考慮して障害対策の優先順位を決定することもできなかった。このため、ソフトウェアシステムの開発や保守に際して、障害の影響度以外の様々な要因を考慮して障害対策の優先順位を決定したいという要求が起こっている。また、テストケースを抽出する際にも様々な要因を考慮して抽出したいという要求が起こっている。
【０００６】
そこで、本発明では、ソフトウェアシステムで生じた様々な障害についての対策を施すべき優先順位を様々な要因を考慮して決定することができるシステムを提供することを目的とする。また、予め用意されているテストケースから今回のテスト対象とされるべき好適なテストケースを様々な要因を考慮して抽出することができるシステムを提供することを別の目的とする。
【課題を解決するための手段】
【０００７】
第１の発明は、ソフトウェアの障害の管理を行うための障害管理装置であって、
前記ソフトウェアの障害に関する情報である障害データであって障害についての複数の評価項目を複数の評価段階で評価するための指標データを含む前記障害データの入力を受け付ける障害データ入力受付手段と、
前記障害データ入力受付手段によって受け付けられた障害データを格納する障害データ保持手段と、
障害データ毎に前記指標データを用いて算出される障害評価値に基づいて、前記障害データ保持手段に格納されている障害データの順位付けを行う障害データ順位付け手段と
を備えることを特徴とする。
【０００８】
第２の発明は、第１の発明において、
前記障害データ入力受付手段は、前記複数の評価項目としての３つの評価項目について、前記複数の評価段階としての４段階の指標値のうちのいずれかの入力を受け付ける指標値入力受付手段を含み、
前記障害データ順位付け手段は、各障害データについて、前記指標値入力受付手段によって受け付けられた指標値に基づいて前記障害評価値を算出することを特徴とする。
【０００９】
第３の発明は、第２の発明において、
前記ソフトウェアの顧客に関する情報である顧客プロファイルデータであって各顧客についての前記複数の評価項目に対する要求度合を示す要求度合データを含む前記顧客プロファイルデータの入力を受け付ける顧客プロファイルデータ入力受付手段を更に備え、
前記障害データ順位付け手段は、前記顧客プロファイルデータ入力受付手段によって受け付けられた要求度合データに基づいて前記障害評価値を算出することを特徴とする。
【００１０】
第４の発明は、第３の発明において、
前記障害データ順位付け手段は、各障害データについて、前記３つの評価項目の指標値と各顧客についての前記要求度合データとに基づいて、顧客毎に定められる値である顧客別評価値を算出し、当該各障害データと対応付けられている顧客のみについての前記顧客別評価値に基づいて前記障害評価値を算出することを特徴とする。
【００１１】
第５の発明は、第３または第４の発明において、
前記顧客プロファイルデータ入力受付手段は、前記ソフトウェアの顧客を複数の段階に区分するための顧客ランクデータの入力を受け付ける顧客ランクデータ入力受付手段を含み、
前記障害データ順位付け手段は、前記顧客ランクデータ入力受付手段によって受け付けられた前記顧客ランクデータに基づいて前記障害評価値を算出することを特徴とする。
【００１２】
第６の発明は、ソフトウェアのテストの管理を行うためのテスト管理装置であって、
繰り返しテストが実施される複数のテストケースを格納するテストケース保持手段と、
第１から第５までのいずれかの発明に係る障害管理装置の障害データ保持手段に格納され前記複数のテストケースのいずれかと対応付けられている障害データの指標データに基づいて算出される前記障害評価値を取得する障害評価値取得手段と、
前記障害評価値取得手段によって取得された障害評価値に基づいて、前記テストケース保持手段に格納されている前記複数のテストケースから今回テストが実施されるべきテストケースを抽出する第１のテストケース抽出手段と
を備えることを特徴とする。
【００１３】
第７の発明は、第６の発明において、
テストケースの抽出に関する条件を設定するためのパラメータ値の入力を受け付けるパラメータ値入力受付手段を更に備え、
前記第１のテストケース抽出手段は、
各テストケースと対応付けられている障害データについての前記障害評価値に基づいて、前記テストケース保持手段に格納されているテストケースの順位付けを行う第１のテストケース順位付け手段と、
前記パラメータ値入力受付手段によって受け付けられたパラメータ値と前記第１のテストケース順位付け手段による順位付けの結果とに基づいて、今回テストが実施されるべきテストケースを抽出する第１の抽出手段と
を含むことを特徴とする。
【００１４】
第８の発明は、第７の発明において、
ソフトウェアの要求仕様に関する情報である要求管理データであって所定の要求管理データ保持手段に格納され前記複数のテストケースのいずれかと対応付けられている前記要求管理データに含まれる、各要求仕様を複数の段階に区分するための要求仕様ランクデータに基づいて、前記テストケース保持手段に格納されている前記複数のテストケースから今回テストが実施されるべきテストケースを抽出する第２のテストケース抽出手段を更に備え、
前記パラメータ値入力受付手段によって受け付けられたパラメータ値に応じて、前記第１のテストケース抽出手段によるテストケースの抽出又は前記第２のテストケース抽出手段によるテストケースの抽出のいずれかが実行されることを特徴とする。
【００１５】
第９の発明は、ソフトウェアの障害の管理を行うための障害管理プログラムであって、
前記ソフトウェアの障害に関する情報である障害データであって障害についての複数の評価項目を複数の評価段階で評価するための指標データを含む前記障害データの入力を受け付ける障害データ入力受付ステップと、
前記障害データ入力受付ステップで受け付けられた障害データを所定の障害データ保持手段に格納する障害データ格納ステップと、
障害データ毎に前記指標データを用いて算出される障害評価値に基づいて、前記障害データ保持手段に格納されている障害データの順位付けを行う障害データ順位付けステップと、
をコンピュータのＣＰＵがメモリにおいて実行させる。
【００１６】
第１０の発明は、第９の発明において、
前記障害データ入力受付ステップでは、前記複数の評価項目としての３つの評価項目について、前記複数の評価段階としての４段階の指標値のうちのいずれかの入力が受け付けられ、
前記障害データ順位付けステップでは、各障害データについて、前記障害データ入力受付ステップで受け付けられた前記３つの評価項目の指標値に基づいて前記障害評価値が算出されることを特徴とする。
【００１７】
第１１の発明は、第１０の発明において、
前記ソフトウェアの顧客に関する情報である顧客プロファイルデータであって各顧客についての前記複数の評価項目に対する要求度合を示す要求度合データを含む前記顧客プロファイルデータの入力を受け付ける顧客プロファイルデータ入力受付ステップを更に含み、
前記障害データ順位付けステップでは、前記顧客プロファイルデータ入力受付ステップで受け付けられた要求度合データに基づいて前記障害評価値が算出されることを特徴とする。
【００１８】
第１２の発明は、第１１の発明において、
前記障害データ順位付けステップでは、各障害データについて、前記３つの評価項目の指標値と各顧客についての前記要求度合データとに基づいて、顧客毎に定められる値である顧客別評価値が算出され、当該各障害データと対応付けられている顧客のみについての前記顧客別評価値に基づいて前記障害評価値が算出されることを特徴とする。
【００１９】
第１３の発明は、第１１または第１２の発明において、
前記顧客プロファイルデータ入力受付ステップでは、前記ソフトウェアの顧客を複数の段階に区分するための顧客ランクデータの入力が受け付けられ、
前記障害データ順位付けステップでは、前記顧客ランクデータ入力受付ステップで受け付けられた前記顧客ランクデータに基づいて前記障害評価値が算出されることを特徴とする。
【００２０】
第１４の発明は、ソフトウェアのテストの管理を行うためのテスト管理プログラムであって、
所定のテストケース保持手段に格納され繰り返しテストが実施される複数のテストケースのいずれかと対応付けられた障害データに含まれる指標データであって障害についての複数の評価項目を複数の評価段階で評価するための前記指標データに基づいて算出される障害評価値を取得する障害評価値取得ステップと、
前記障害評価値取得ステップで取得された障害評価値に基づいて、前記テストケース保持手段に格納されている前記複数のテストケースから今回テストが実施されるべきテストケースを抽出する第１のテストケース抽出ステップと
をコンピュータのＣＰＵがメモリにおいて実行させる。
【００２１】
第１５の発明は、第１４の発明において、
テストケースの抽出に関する条件を設定するためのパラメータ値の入力を受け付けるパラメータ値入力受付ステップを更に含み、
前記第１のテストケース抽出ステップは、
各テストケースと対応付けられている障害データについての前記障害評価値に基づいて、前記テストケース保持手段に格納されているテストケースの順位付けを行う第１のテストケース順位付けステップと、
前記パラメータ値入力受付ステップで受け付けられたパラメータ値と前記第１のテストケース順位付けステップでの順位付けの結果とに基づいて、今回テストが実施されるべきテストケースを抽出する第１の抽出ステップと
を含むことを特徴とする。
【００２２】
第１６の発明は、第１５の発明において、
ソフトウェアの要求仕様に関する情報である要求管理データであって所定の要求管理データ保持手段に格納され前記複数のテストケースのいずれかと対応付けられている前記要求管理データに含まれる、各要求仕様を複数の段階に区分するための要求仕様ランクデータに基づいて、前記テストケース保持手段に格納されている前記複数のテストケースから今回テストが実施されるべきテストケースを抽出する第２のテストケース抽出ステップを更に含み、
前記パラメータ値入力受付ステップで受け付けられたパラメータ値に応じて、前記第１のテストケース抽出ステップによるテストケースの抽出又は前記第２のテストケース抽出ステップによるテストケースの抽出のいずれかが実行されることを特徴とする。
【００２３】
第１７の発明は、ソフトウェアの障害の管理を行うための障害管理方法であって、
前記ソフトウェアの障害に関する情報である障害データであって障害についての複数の評価項目を複数の評価段階で評価するための指標データを含む前記障害データの入力を受け付ける障害データ入力受付ステップと、
前記障害データ入力受付ステップで受け付けられた障害データを所定の障害データ保持手段に格納する障害データ格納ステップと、
障害データ毎に前記指標データを用いて算出される障害評価値に基づいて、前記障害データ保持手段に格納されている障害データの順位付けを行う障害データ順位付けステップと、
を含むことを特徴とする。
【００２４】
第１８の発明は、ソフトウェアのテストの管理を行うためのテスト管理方法であって、
所定のテストケース保持手段に格納され繰り返しテストが実施される複数のテストケースのいずれかと対応付けられた障害データに含まれる指標データであって障害についての複数の評価項目を複数の評価段階で評価するための前記指標データに基づいて算出される障害評価値を取得する障害評価値取得ステップと、
前記障害評価値取得ステップで取得された障害評価値に基づいて、前記テストケース保持手段に格納されている前記複数のテストケースから今回テストが実施されるべきテストケースを抽出する第１のテストケース抽出ステップと、
を含むことを特徴とする。
【発明の効果】
【００２５】
上記第１の発明によれば、ソフトウェアの障害に関する情報である障害データに（障害についての）複数の評価項目が設けられており、それら複数の評価項目のそれぞれについて複数段階での評価が行われる。また、障害管理装置には障害データの順位付けを行う障害データ順位付け手段が設けられているところ、当該障害データ順位付け手段は、各障害データについての上記複数の評価項目の評価値を用いて算出される障害評価値に基づいて、障害データの順位付けを行う。このため、様々な要因を考慮した障害データの順位付けが行われる。これにより、複数の障害についての対策を施す際に、（障害対策を施す）効果的な優先順位を導出することができる。
【００２６】
上記第２の発明によれば、障害毎に３つの評価項目について４段階での評価が行われる。すなわち、ソフトウェアの障害についての評価に関し、４点法のＦＭＥＡ（Failure Mode and Effect Analysis：故障モードとその影響解析）の考え方が取り入れられている。このため、個々の障害データの入力を比較的容易に行うことができ、また、ソフトウェアの障害によるトラブルの発生を効果的に防止することができる。
【００２７】
上記第３の発明によれば、上記複数の評価項目に対する（ソフトウェアの）顧客毎の要求度合に基づいて、障害データの順位付けを行うための障害評価値が算出される。このため、障害に対する顧客の要求度合を考慮しつつ、障害データの順位付けを行うことができる。
【００２８】
上記第４の発明によれば、各障害についての障害評価値には、当該各障害と対応付けられている顧客のみについての（上記複数の評価項目に対する）要求度合が反映される。このため、例えば、各障害を引き起こした機能の提供先を考慮しつつ、障害データの順位付けを行うことができる。
【００２９】
上記第５の発明によれば、ソフトウェアの顧客を複数段階に区分するために設けられた顧客ランクデータに基づいて、障害データの順位付けを行うための障害評価値が算出される。このため、例えば、ユーザにとっての顧客の重要さを考慮しつつ、障害データの順位付けを行うことができる。
【００３０】
上記第６の発明によれば、各障害についての複数の評価項目の評価値を用いて算出される障害評価値に基づいて、複数のテストケースから今回テストが実施されるべきテストケースが抽出される。このため、テストケースの基となる障害に関する様々な要因が考慮されつつテストケースが抽出される。
【００３１】
上記第７の発明によれば、上記障害評価値と予め設定された条件とに従って、テストケースが抽出される。
【００３２】
上記第８の発明によれば、予め設定された条件に応じて、異なる手法によるテストケースの抽出が行われる。
【発明を実施するための最良の形態】
【００３３】
＜１．はじめに＞
本発明の実施形態についての説明をする前に、本発明の基礎となる考え方について説明する。各種製品の故障や不具合の防止を目的として各種製品の潜在的な故障・不具合の体系的な分析を行うＦＭＥＡ（Failure Mode and Effect Analysis：故障モードとその影響解析）と呼ばれる信頼性評価技法が従来より知られている。ＦＭＥＡでは、「程度（厳しさ）」、「頻度（発生率）」、および「潜在性（検知度）」という３つの因子（指標）が定められ、各因子の観点から故障モードの評価が行われる。ここで、「程度（厳しさ）」は、故障による影響の大きさを示す指標である。「頻度（発生率）」は、故障がどの程度の頻度で発生するかを示す指標である。「潜在性（検知度）」は、故障を事前に発見できる可能性を示す指標である。また、故障モードとは故障状態の形式による分類であって、例えば、断線、短絡、折損、摩耗、特性の劣化などが挙げられる。ＦＭＥＡには、各因子につき４段階での評価を行う４点法と呼ばれる手法と各因子につき１０段階での評価を行う１０点法と呼ばれる手法とがある。一般的に、１０点法に比べて４点法の方が、評価に時間を要さず、故障への対策を迅速に施すことができるとされている。以下、４点法のＦＭＥＡによる分析手法の概要を説明する。
【００３４】
４点法のＦＭＥＡにおいては、各因子についての各評価段階の意味は、例えば図１に示すように定義されている。そして、各故障モードについて、３つの因子それぞれの評価段階に基づき、危険指数（Risk Index）と呼ばれる値（以下、「ＲＩ値」という。）の算出が行われる。具体的には、「程度（厳しさ）」についての評価段階をＡ、「頻度（発生率）」についての評価段階をＢ、「潜在性（検知度）」についての評価段階をＣとすると、ＲＩ値ＲＩは式（１）で算出される。なお、このＲＩ値は、対象製品の信頼性を評価するための値となる。
【数１】
2009181536.tif 000003
【００３５】
図２は、ＲＩ値と（対象製品の）信頼度とコストとの関係を示す図である。図２に示すように、ＲＩ値が小きいほど対象製品の信頼度は高くなる。ところで、対象製品の製造・保守等に掛かるトータルコストは、製造原価と整備関係費とに大きく分けられる。対象製品の信頼度が低いとき（ＲＩ値が大きいとき）には、製造原価は小さくなるが、整備関係費が大きくなる。このため、トータルコストは比較的高くなる。これは、信頼度の低い製品を出荷すると、故障対応や復旧作業が頻繁に生じるので、結果的にトータルコストが高くなることを意味している。また、対象製品の信頼度が高いとき（ＲＩ値が小さいとき）には、整備関係費は小さくなるが、製造原価は大きくなる。このため、トータルコストは比較的高くなる。これは、ある程度以上の品質を求めると、製造段階で要するコストが著しく高くなり、結果的にトータルコストが高くなることを意味している。
【００３６】
図２によると、製造原価と整備関係費との和であるトータルコストが最も低くなるのは、ＲＩ値が「２」のときである。そして、ＲＩ値が「２．３」以下となるような信頼度があれば、製品に生じている故障は容認できるとされている。一方、ＲＩ値が「２．３」を超えるときには、故障への対策が施されるべきとされている。なお、ＲＩ値が「２．０」以下のときには、製品の信頼性はあるが過剰品質のおそれがあるとされている。以上のように、ＦＭＥＡにおいては、最も好ましい信頼度はＲＩ値が「２」のときであって、ＲＩ値が「２．３」を超えるときには故障への対策が施されるべきとされている。そして、「様々な故障が生じているときに、例えば優先順位を付けて対策を施すなど、トータルコストが最も低くなるように故障への対策が施されるべき」というのがＦＭＥＡの考え方である。
【００３７】
以下に説明する実施形態においては、上述した４点法によるＦＭＥＡの考え方を取り入れて、ソフトウェアシステムの障害の管理が行われる。具体的には、障害の管理指標として、「重要度」、「優先度」、および「発生確率」という３つの評価項目が設けられ、各評価項目について４段階での評価が行われる。ここで、「重要度」は、障害による影響の大きさを示す指標である。「優先度」は、いかに早く障害から復旧すべきかを示す指標である。「発生確率」は、障害がどの程度の頻度で発生するかを示す指標である。障害に関する情報は障害データとして蓄積され、当該障害データから算出されるＲＩ値に基づいて、修正を施すべき障害の優先順位付けが行われる。
【００３８】
以下、添付図面を参照しつつ、本発明の一実施形態について説明する。
【００３９】
＜２．システムの構成＞
＜２．１  システムの概要＞
図３は、本発明の一実施形態におけるシステムの全体構成図である。このシステムは、「ソフトウェア開発管理システム」と呼ばれており、サブシステムとして障害管理システム２とテスト管理システム３と要求管理システム４とを含んでいる。
【００４０】
＜２．２  ハードウェア構成＞
図４は、このソフトウェア開発管理システムを実現するハードウェア構成図である。このシステムは、サーバ機７と複数のパソコン８とによって構成され、サーバ機７および各パソコン８はＬＡＮ９によって互いに接続されている。サーバ機７は、各パソコン８からの要求に応じた処理の実行や各パソコン８から共通して参照等可能なファイル、データベース等の格納などを行う。また、サーバ機７では、ソフトウェアシステムの開発に際しての要求仕様の管理、各種テストの管理、システムの障害（不具合）の管理などが行われる。このため、以下、サーバ機７のことを「ソフトウェア開発管理装置」という。パソコン８では、ソフトウェアシステムの開発のためのプログラミング等の作業、テストケースの入力、テストの実施、障害のデータの入力などが行われる。なお、図５に示すように、障害管理システム２を実現するためのサーバ機（障害管理装置）７２とテスト管理システム３を実現するためのサーバ機（テスト管理装置）７３と要求管理システム４を実現するためのサーバ機（要求管理装置）７４とをそれぞれ備える構成、すなわち、サブシステム毎にサーバ機を備える構成にしても良い。本実施形態においては、図４に示す構成を前提に説明する。本実施形態におけるソフトウェア開発管理装置７には、機能的には、図５に示す障害管理装置７２とテスト管理装置７３と要求管理装置７４とが含まれている。
【００４１】
図６は、ソフトウェア開発管理装置７の構成を示すブロック図である。このソフトウェア開発管理装置７は、ＣＰＵ１０と表示部４０と入力部５０とメモリ６０と補助記憶装置７０とを備えている。補助記憶装置７０には、プログラム格納部２０とデータベース３０とが含まれている。ＣＰＵ１０は、与えられた命令に従い演算処理を行う。プログラム格納部２０には、プログラム名をそれぞれ「障害データ入力」、「顧客プロファイルデータ入力」、「障害データ優先順位付け」、「テストケース入力」、および「テストケース抽出」とする５つのプログラム（実行モジュール）２１〜２５が格納されている。データベース３０には、テーブル名をそれぞれ「障害」、「顧客プロファイル」、「テストケース」、および「要求管理」とする４つのテーブル３１〜３４が格納されている。表示部４０は、例えば、オペレータが障害データを入力する際の操作用画面を表示する。入力部５０は、マウスやキーボードによるオペレータからの入力を受け付ける。メモリ６０には、ＣＰＵ１０の演算処理に必要なデータが一時的に格納される。なお、プログラム格納部２０には上述した５つのプログラム以外のプログラムが含まれていても良く、データベース３０には上述した４つのテーブル以外のテーブルが含まれていても良い。
【００４２】
パソコン８の構成については、図６に示すソフトウェア開発管理装置（サーバ機）７の構成とほぼ同様の構成となっているので、説明を省略する。但し、パソコン８の補助記憶装置７０にはデータベース３０は設けられていない。
【００４３】
＜２．３  機能的な構成＞
図７は、このソフトウェア開発管理システムを機能的な観点からみた機能ブロック図である。障害管理システム２には、障害データ入力受付部２１０と障害データ保持部２２０と障害データ優先順位付け部２３０と顧客プロファイルデータ入力受付部２４０と顧客プロファイルデータ保持部２５０とが含まれている。障害データ入力受付部２１０は、オペレータが障害データを入力するための操作用画面を表示し、オペレータからの入力を受け付ける。障害データ保持部２２０は、オペレータによって入力された障害データを保持する。障害データ優先順位付け部２３０は、障害データ保持部２２０に保持されている障害データについて、上述したＲＩ値に基づく優先順位付けを行う。顧客プロファイルデータ入力受付部２４０は、オペレータが顧客プロファイルデータを入力するための操作用画面を表示し、オペレータからの入力を受け付ける。なお、顧客プロファイルデータとは、障害の管理指標に対する顧客毎の要求の強さ（要求度合）などの情報のことである。顧客プロファイルデータ保持部２５０は、オペレータによって入力された顧客プロファイルデータを保持する。
【００４４】
各プログラムがＣＰＵ１０によってメモリ６０を利用して実行されることにより以下の機能が実現する。すなわち、障害データ入力受付部２１０は、障害データ入力プログラム２１が実行されることによって実現される。障害データ優先順位付け部２３０は、障害データ優先順位付けプログラム２３が実行されることによって実現される。顧客プロファイルデータ入力受付部２４０は、顧客プロファイルデータ入力プログラム２２が実行されることによって実現される。また、障害データ保持部２２０は、障害テーブル３１によって実現される。顧客プロファイルデータ保持部２５０は、顧客プロファイルテーブル３２によって実現される。
【００４５】
テスト管理システム３には、テストケース入力受付部３１０とテストケース保持部３２０とテストケース抽出部３３０とが含まれている。テストケース入力受付部３１０は、オペレータがテストケースを入力するための操作用画面を表示し、オペレータからの入力を受け付ける。テストケース保持部３２０は、オペレータによって入力されたテストケースを保持する。テストケース抽出部３３０は、オペレータによって設定された条件に基づいて、複数のテストケースの中から今回のフェーズでテストの対象とするべきテストケースを抽出する。
【００４６】
テストケース入力受付部３１０は、テストケース入力プログラム２４が実行されることによって実現される。テストケース抽出部３３０は、テストケース抽出プログラム２５が実行されることによって実現される。また、テストケース保持部３２０は、テストケーステーブル３３によって実現される。
【００４７】
テストケース抽出部３３０には、図８に示すように、パラメータ値入力受付部３３２と第１のテストケース抽出部３３４と第２のテストケース抽出部３３６とが少なくとも含まれている。パラメータ値入力受付部３３２は、オペレータがテストケース抽出の条件を設定するための操作用画面を表示し、オペレータからの入力を受け付ける。第１のテストケース抽出部３３４は、テストケース保持部３２０に保持されているテストケースのデータについて、後述するトータルＲＩ値に基づく優先順位付けを行う。第２のテストケース抽出部３３６は、テストケース保持部３２０に保持されているテストケースのデータについて、後述する機能別重要度に基づく優先順位付けを行う。
【００４８】
要求管理システム４には、要求管理データ保持部４１０が含まれている。要求管理データ保持部４１０は、要求管理データを保持する。なお、要求管理データとは、ソフトウェアシステムに要求されている仕様（要求仕様）を管理するためのデータである。要求管理データ保持部４１０は、要求管理テーブル３４によって実現される。
【００４９】
なお、各機能と各サブシステムとの対応関係については、図７に示す構成に限定されるものではない。
【００５０】
＜２．４  テーブル＞
次に、このソフトウェア開発管理システムで使用されるテーブルについて説明する。図９は、障害テーブル３１のレコードフォーマットを示す図である。障害テーブル３１には、項目名をそれぞれ「障害番号」、「発生製品」、「発生日」、「報告日」、「報告者」、「環境」、「障害内容」、「重要度」、「優先度」、「発生確率」、「ＲＩ値」、「要求管理番号」、および「最優先フラグ」とする複数の項目が含まれている。障害テーブル３１の各項目のフィールド（個々のデータが格納される領域）には、それぞれ以下のような内容のデータが格納される。「障害番号」には、個々の障害（レコード）を識別するための一意の番号が格納される。「発生製品」には、障害が発生した製品の名称が格納される。「発生日」には、障害の発生した日の日付が格納される。「報告日」には、障害発生が報告された日の日付が格納される。「報告者」には、障害発生を報告した者の氏名が格納される。「環境」には、障害の発生した環境（ハードウェア環境、ソフトウェア環境など）を説明した記述が格納される。「障害内容」には、障害の具体的な内容を説明した記述が格納される。「重要度」には、評価項目としての重要度の評価段階を示す値が格納される。「優先度」には、評価項目としての優先度の評価段階を示す値が格納される。「発生確率」には、評価項目としての発生確率の評価段階を示す値が格納される。「ＲＩ値」には、「重要度」、「優先度」、および「発生確率」に格納されている値に基づいて算出されるＲＩ値が格納される。「要求管理番号」には、障害がどの要求仕様に基づくものであるのかを特定するための番号が格納される。なお、この「要求管理番号」は、後述する要求管理テーブル３４の項目名「要求管理番号」とリンクされている。「最優先フラグ」には、３つの評価項目の値にかかわらず優先して対策を施すか否かを示すフラグが格納される。
【００５１】
なお、本実施形態においては、障害テーブル３１の「重要度」フィールド、「優先度」フィールド、および「発生確率」フィールドによって指標データが実現されている。
【００５２】
図１０は、顧客プロファイルテーブル３２のレコードフォーマットを示す図である。顧客プロファイルテーブル３２には、項目名をそれぞれ「顧客名」、「重要度」、「優先度」、「発生確率」、および「顧客ランク」とする複数の項目が含まれている。「顧客名」には、ソフトウェアシステムを使用している顧客の名称が格納される。「重要度」には、障害の評価項目としての重要度について当該顧客が要求するレベル（評価段階）を示す値が格納される。「優先度」には、障害の評価項目としての優先度について当該顧客が要求するレベル（評価段階）を示す値が格納される。「発生確率」には、障害の評価項目としての発生確率について当該顧客が要求するレベル（評価段階）を示す値が格納される。本実施形態においては、評価段階を示す値として「１」〜「４」までの４つの値が用意されている。そして、「重要度」、「優先度」、および「発生確率」には、顧客の要求するレベルが高いほど小さな値が格納される。「顧客ランク」には、ユーザ（このソフトウェア開発管理システムの利用者）にとっての当該顧客の重要さを示す値（例えば、「１」〜「５」までの値）が格納される。この「顧客ランク」には、ユーザにとって重要な顧客であるほど大きな値が格納される。
【００５３】
なお、本実施形態においては、顧客プロファイルテーブル３２の「重要度」フィールド、「優先度」フィールド、および「発生確率」フィールドによって要求度合データが実現されている。また、顧客プロファイルテーブル３２の「顧客ランク」フィールドによって顧客ランクデータが実現されている。
【００５４】
図１１は、テストケーステーブル３３のレコードフォーマットを示す図である。テストケーステーブル３３には、項目名をそれぞれ「テストケース番号」、「作成者」、「テスト分類」、「テスト方法」、「テストデータ」、「テストデータ概要」、「テストレベル」、「ランク」、「判定条件」、「障害番号」、「要求管理番号」、「テスト結果ＩＤ」、「テスト結果」、「報告者」、「報告日」、「環境」、および「備考」とする複数の項目が含まれている。なお、「テスト結果ＩＤ」、「テスト結果」、「報告者」、「報告日」、「環境」、および「備考」については、当該テストケースについてのテストが実施された回数だけ繰り返される。テストケーステーブル３３の各項目のフィールドには、それぞれ以下のような内容のデータが格納される。「テストケース番号」には、テストケースを識別するための一意の番号が格納される。「作成者」には、テストケースの作成者の氏名が格納される。「テスト分類」には、所定の指標に従ってテストケースを分類した分類名が格納される。「テスト方法」には、テストを実施する方法を説明した記述が格納される。「テストデータ」には、テストを実施するためのデータを特定する記述（例えばフルパス名）が格納される。「テストデータ概要」には、テストデータの概要を説明した記述が格納される。「テストレベル」には、テストケースのレベルが格納される。このレベルには、例えば、「単体テスト」、「結合テスト」、「システムテスト」等がある。「ランク」には、テストケースの重要度が格納される。この重要度には、例えば、「Ｈ」、「Ｍ」、「Ｌ」等がある。「判定条件」には、テストの合否を判定する基準を説明した記述が格納される。「障害番号」には、テストケースがどの障害に対応して作成されたのかを特定するための番号が格納される。なお、この「障害番号」は、障害テーブル３１の項目名「障害番号」とリンクされている。「要求管理番号」には、テストケースがどの要求仕様に基づくものであるのかを特定するための番号が格納される。なお、この「要求管理番号」は、後述する要求管理テーブル３４の項目名「要求管理番号」とリンクされている。「テスト結果ＩＤ」には、各テストケース内でテスト結果を識別するための番号が格納される。「テスト結果」には、テストを実施した結果が格納される。このテスト結果には、「成功」、「失敗」、「見送り」、「未実施」、「テスト中」、「テスト不可」がある。「報告者」には、テスト結果を報告した者の氏名が格納される。「報告日」には、テスト結果が報告された日の日付が格納される。「環境」には、テストが実施された時のシステム等の環境を説明した記述が格納される。「備考」には、テストの実施に関する注釈等の記述が格納される。
【００５５】
なお、上記テスト結果に関し、「成功」とは、テストの結果が成功（合格）であったことを意味する。「失敗」とは、テストの結果が失敗（不合格）であったことを意味する。「見送り」とは、当該テストケースについてはテストが実施されなかった（当該テストフェーズにおいてテスト対象とされなかった）ことを意味する。「未実施」とは、現在テストフェーズにあるが、当該テストケースについては未だテストが実施されていないことを意味する。「テスト中」とは、現在テストの実施中であることを意味する。「テスト不可」とは、プログラムができていない等の理由でテストが実施できないことを意味する。
【００５６】
また、テストケーステーブル３３には、「テスト結果ＩＤ」、「テスト結果」、「報告者」、「報告日」、「環境」、および「備考」がテストが実施された回数だけ繰り返されている。従って、テストケーステーブル３３については、正規化をしても良い。すなわち、図１２（ａ）および（ｂ）に示すようなレコードフォーマットの２つのテーブルにすることができる。
【００５７】
図１３は、要求管理テーブル３４のレコードフォーマットを示す図である。要求管理テーブル３４には、項目名をそれぞれ「要求管理番号」、「要求項目」、「オプション顧客」、「特注顧客」、および「機能別重要度」とする複数の項目が含まれている。「要求管理番号」には、ソフトウェアシステムの個々の要求仕様を識別するための一意の番号が格納される。「要求項目」には、要求仕様に基づく機能が全ての顧客の製品に取り入れられているのか、それとも、特定の顧客の製品のみに取り入れられているのかを示す種別が格納される。具体的には、この「要求項目」には、「標準」、「オプション」、および「特注」のいずれかが格納される。「オプション顧客」には、「要求項目」に「オプション」が格納されているデータ（レコード）について、対象となる顧客の名称が格納される。「特注顧客」には、「要求項目」に「特注」が格納されているデータ（レコード）について、対象となる顧客の名称が格納される。「機能別重要度」には、要求仕様に基づく機能の重要さを示す値が格納される。この機能別重要度についての詳しい説明は後述する。
【００５８】
図１４は、要求管理テーブル３４にデータが格納された例を示す図である。図１４に示すように、「要求項目」が「オプション」となっているレコードについては、「オプション顧客」に対象となる顧客の名称が格納されている。また、「要求項目」が「特注」となっているレコードについては、「特注顧客」に対象となる顧客の名称が格納されている。一方、「要求項目」が「オプション」以外のレコードについては、「オプション顧客」には何も格納されていない（ＮＵＬＬ値となっている）。また、「要求項目」が「特注」以外のレコードについては、「特注顧客」には何も格納されていない。このため、要求管理テーブル３４については、正規化をして、例えば図１５（ａ）〜（ｃ）に示すようなレコードフォーマットの３つのテーブルにしても良い。
【００５９】
なお、本実施形態においては、要求管理テーブル３４の「機能別重要度」フィールドによって要求仕様ランクデータが実現されている。
【００６０】
＜３．障害管理システムでの処理＞
次に、障害管理システム２で行われる処理について説明する。処理としては、障害の発生後に当該障害に関する情報をデータとして入力するための「障害データ入力処理」、上述した顧客プロファイルデータを入力するための「顧客プロファイルデータ入力処理」、および、障害の対策を施すべき順序に従って障害データの優先順位付けを行う「障害データ優先順位付け処理」がある。なお、各処理を実行するためのオペレータの操作はパソコン８で行われるものとして説明する。従って、後述する各種ダイアログ等は、パソコン８の表示部に表示される。
【００６１】
＜３．１  障害データ入力処理＞
まず、障害データ入力処理について説明する。障害データの入力を行うためのメニュー等がオペレータによって選択されると、障害データ入力受付部２１０は、図１６に示すような障害データ入力ダイアログ５００を表示する。オペレータは、この障害データ入力ダイアログ５００より、個々の障害データに関する情報の入力を行う。
【００６２】
障害データ入力ダイアログ５００には、障害に関する一般的な情報を入力するためのテキストボックス等（例えば、「障害番号」を入力するためのテキストボックス）と、障害の各評価項目の評価段階を選択するための重要度リストボックス５０２、優先度リストボックス５０３、および発生確率リストボックス５０４と、３つの評価項目の評価段階に基づいて算出されるＲＩ値を表示するためのＲＩ値表示領域５０５と、各評価項目の解説画面（後述する指標解説ダイアログ５１０）を表示させるための指標解説ボタン５０６と、入力内容を確定するための確定ボタン５０８と、入力内容を取り消すためのキャンセルボタン５０９とが含まれている。
【００６３】
ここで、オペレータによって重要度リストボックス５０２が押下（クリック）されると、障害データ入力受付部２１０は、図１７に示すように、重要度の評価段階として選択可能な４つの値を表示する。オペレータは、これらの値のうちのいずれかの値を選択することができる。優先度リストボックス５０３および発生確率リストボックス５０４についても同様である。重要度リストボックス５０２、優先度リストボックス５０３、および発生確率リストボックス５０４の全てにおいていずれかの値の選択が行われると、それら選択された値に基づいて計算されたＲＩ値がＲＩ値表示領域５０５に表示される。このＲＩ値の計算方法についての説明は後述する。なお、本実施形態においては、重要度リストボックス５０２、優先度リストボックス５０３、および発生確率リストボックス５０４によって指標値入力受付手段が実現されている。
【００６４】
オペレータによって指標解説ボタン５０６が押下されると、障害データ入力受付部２１０は、図１８に示すような指標解説ダイアログ５１０を表示する。この指標解説ダイアログ５１０は、各評価項目についての各評価段階の意味をオペレータが参照するためのダイアログである。オペレータによって閉じるボタン５１１が押下されると、このダイアログは非表示となる。
【００６５】
オペレータによって障害データ入力ダイアログ５００の確定ボタン５０８が押下されると、障害データ入力受付部２１０は、オペレータによる入力内容を取り込み、その入力内容に基づいて障害テーブル３１にレコードを１件追加する。
【００６６】
また、本実施形態においては、障害データ入力ダイアログ５００にはテストケース登録ボタン５０１が設けられている。このテストケース登録ボタン５０１は、障害データからテストケースを生成するためのものである。オペレータによってテストケース登録ボタン５０１が押下されると、図１９に示すようなテストケース登録ダイアログ５２０が表示される。テストケース登録ダイアログ５２０には、障害データからテストケースを生成する際に必要となる情報を入力するためのテキストボックス等（例えば、テストケース番号を入力するためのテキストボックス）と、入力内容に基づいてテストケースの登録を実行するための登録ボタン５２８と、入力内容を取り消すためのキャンセルボタン５２９とが含まれている。このテストケース登録ダイアログ５２０によってテストケースの登録が行われると、障害データ入力ダイアログ５００での入力内容とテストケース登録ダイアログ５２０での入力内容とに基づいてテストケースのデータが生成され、当該データは１件のレコードとしてテストケーステーブル３３に追加される。
【００６７】
＜３．２  顧客プロファイルデータ入力処理＞
次に、顧客プロファイルデータ入力処理について説明する。顧客プロファイルデータの入力を行うためのメニュー等がオペレータによって選択されると、顧客プロファイルデータ入力受付部２４０は、図２０に示すような顧客プロファイルデータ入力ダイアログ５３０を表示する。オペレータは、この顧客プロファイルデータ入力ダイアログ５３０より、顧客プロファイルデータの入力を行う。
【００６８】
顧客プロファイルデータ入力ダイアログ５３０には、顧客の名称を入力するための顧客名入力テキストボックス５３１と、重要度を選択するための重要度リストボックス５３２と、優先度を選択するための優先度リストボックス５３３と、発生確率を選択するための発生確率リストボックス５３４と、顧客ランクを選択するための顧客ランクリストボックス５３５と、入力内容を確定するための確定ボタン５３８と、入力内容を取り消すためのキャンセルボタン５３９とが含まれている。なお、ここでの重要度とは、障害の評価項目としての重要度について顧客が要求するレベル（評価段階）を示す値のことである。優先度および発生確率についても同様である。また、本実施形態においては、上記顧客ランクリストボックス５３５によって顧客ランクデータ入力受付手段が実現されている。
【００６９】
オペレータによって顧客プロファイルデータ入力ダイアログ５３０の確定ボタン５３８が押下されると、顧客プロファイルデータ入力受付部２４０は、オペレータによる入力内容を取り込み、その入力内容に基づいて顧客プロファイルテーブル３２にレコードを１件追加する。
【００７０】
＜３．３  障害データ優先順位付け処理＞
次に、障害データ優先順位付け処理について説明する。この処理では、障害の対策を施すべき順序に従って障害データの優先順位付けが行われる。障害データの優先順位付けは各障害データのＲＩ値に基づいて行われるが、その際、障害についての各評価項目に対する各顧客の要求の強さ（要求度合）やこのシステムのユーザにとっての各顧客の重要さが考慮される。すなわち、障害データのみから算出されるＲＩ値だけでなく、顧客プロファイルテーブル３２や要求管理テーブル３４に格納されているデータの内容をも考慮したＲＩ値が算出される。なお、顧客プロファイルテーブル３２の内容を考慮して顧客毎に算出されるＲＩ値のことを「顧客別プロファイルＲＩ値（顧客別評価値）」といい、顧客プロファイルテーブル３２の内容に加え要求管理テーブル３４の内容をも考慮して障害データの最終的な優先順位付けを行うためのＲＩ値のことを「トータルＲＩ値（障害評価値）」という。本実施形態においては、このトータルＲＩ値が大きいほど優先順位が高くなる。
【００７１】
＜３．３．１  ＲＩ値の算出＞
本実施形態においては、障害データ毎（１レコード毎）に、「（狭義の）ＲＩ値」、「顧客別プロファイルＲＩ値」、および「トータルＲＩ値」という３つの「（広義の）ＲＩ値」が算出される。その算出方法について以下に説明する。なお、以下の説明においては、障害テーブル３１には図２１に示すようなデータが格納され（説明に必要なフィールドのみを示している）、顧客プロファイルテーブル３２には図２２に示すようなデータが格納され、要求管理テーブル３４には図１４に示すようなデータが格納されているものとする。そして、後述のようにして各障害データについての（広義の）ＲＩ値が算出された結果は、図２３に示すとおりとなる。なお、以下においては特に説明のない限り、「（狭義の）ＲＩ値」のことを単に「ＲＩ値」という。
【００７２】
ＲＩ値は、障害データの評価項目としての重要度、優先度、および発生確率の積の３乗根である。すなわち、障害データの重要度をＡ、障害データの優先度をＢ、障害データの発生確率をＣとすると、ＲＩ値Ｒ１は式（２）で算出される。
【数２】
2009181536.tif 000004
例えば、図２１で障害番号が「Ａ００１」の障害データについては、「１×２×３＝６」であり、「６」の３乗根は「１．８」（小数第２位を四捨五入している）である。従って、障害番号が「Ａ００１」の障害データのＲＩ値は「１．８」となる。
【００７３】
なお、このＲＩ値については、障害データ入力ダイアログ５００で重要度リストボックス５０２、優先度リストボックス５０３、および発生確率リストボックス５０４の全てにおいて値の選択が行われたときに、上述のようにして算出された値が障害テーブル３１のＲＩ値フィールドに格納される。
【００７４】
顧客別プロファイルＲＩ値は、「障害データの重要度を顧客プロファイルデータの対象顧客の重要度の２乗で除した値」と「障害データの優先度を顧客プロファイルデータの対象顧客の優先度の２乗で除した値」と「障害データの発生確率を顧客プロファイルデータの対象顧客の発生確率の２乗で除した値」との和である。すなわち、障害データの重要度をＡ、障害データの優先度をＢ、障害データの発生確率をＣ、顧客プロファイルデータの対象顧客の重要度をＤ、顧客プロファイルデータの対象顧客の優先度をＥ、顧客プロファイルデータの対象顧客の発生確率をＦとすると、顧客別プロファイルＲＩ値Ｒ２は式（３）で算出される。
【数３】
2009181536.tif 000005
例えば、図２１で障害番号が「Ａ００５」の障害データのＡ社についての顧客別プロファイルＲＩ値は、「３」を「３」の２乗で除した値、「１」を「２」の２乗で除した値、および「４」を「１」の２乗で除した値の和、すなわち「４．５８」（小数第３位を四捨五入している）となる。
【００７５】
トータルＲＩ値は、障害を引き起こした機能を提供している顧客を要求管理テーブル３４に基づいて特定し、その特定された顧客についての「顧客別プロファイルＲＩ値と顧客ランクとの積」の和である。すなわち、障害を引き起こした機能を提供している顧客がＬ社、Ｍ社、およびＮ社である場合、Ｌ社の顧客別プロファイルＲＩ値をＬ１、Ｌ社の顧客ランクをＬ２、Ｍ社の顧客別プロファイルＲＩ値をＭ１、Ｍ社の顧客ランクをＭ２、Ｎ社の顧客別プロファイルＲＩ値をＮ１、Ｎ社の顧客ランクをＮ２とすると、トータルＲＩ値Ｒ３は式（４）で算出される。
【数４】
2009181536.tif 000006
但し、最優先フラグが「１」の障害データについては、トータルＲＩ値は「９９９９」となる。
【００７６】
例えば、図２１で障害番号が「Ａ００２」のデータについては、要求管理番号は「０００３」である。ここで、要求管理テーブル３４で要求管理番号が「０００３」のデータの要求項目は「オプション」となっており、オプション顧客は「Ａ社、Ｃ社」となっている。これにより、障害番号「Ａ００２」の障害を引き起こした機能はＡ社およびＣ社に提供されていることが把握される。また、顧客プロファイルテーブル３２より、Ａ社の顧客ランクは「３」であり、Ｃ社の顧客ランクは「１」であることが把握される。そして、Ａ社の顧客別プロファイルＲＩ値「３．７２」とＡ社の顧客ランク「３」との積は「１１．１６」となり、Ｃ社の顧客別プロファイルＲＩ値「７」とＣ社の顧客ランク「１」との積は「７」となるので、トータルＲＩ値は、「１１．１６」と「７」との和、すなわち「１８．１６」となる。
【００７７】
本実施形態においては、障害データ優先順位付け処理の際に上述のようにしてトータルＲＩ値が算出され（後述する図２４のステップＳ１５１〜Ｓ１５７を参照）、そのトータルＲＩ値に基づいて障害データの優先順位付けが行われる。
【００７８】
＜３．３．２  処理手順＞
図２４は、本実施形態における障害データ優先順位付け処理の処理手順を示すフローチャートである。オペレータによって障害データ優先順位付け処理のメニュー等が選択されると、障害データ優先順位付け部２３０は、データベース３０内の障害テーブル３１より障害データを１レコード読み込む（ステップＳ１１０）。その後、障害データ優先順位付け部２３０は、ステップＳ１１０で読み込んだ障害データの最優先フラグが「１」であるか否かの判定を行う（ステップＳ１２０）。ステップＳ１２０での判定の結果、最優先フラグが「１」であればステップＳ１５７に進み、「１」でなければステップＳ１３０に進む。例えば、図２１においては、障害番号が「Ａ００３」の障害データの最優先フラグが「１」となっている。
【００７９】
ステップＳ１３０では、障害データ優先順位付け部２３０は、ステップＳ１１０で読み込んだ障害データが「特注」の要求仕様に基づくものであるか否かの判定を行う。例えば、図２１で障害番号が「Ａ００４」の障害データについては、要求管理番号が「０００２」となっているところ、図１４に示す要求管理テーブル３４においては、要求管理番号が「０００２」のデータの要求項目は「標準」となっている。従って、当該障害データは、「特注」の要求仕様に基づくものではない。また、例えば、図２１で障害番号が「Ａ００５」の障害データについては、要求管理番号が「０００６」となっているところ、図１４に示す要求管理テーブル３４においては、要求管理番号が「０００６」のデータの要求項目は「特注」となっている。従って、当該障害データは、「特注」の要求仕様に基づくものである。以上のようにして「特注」であるか否かの判定が行われ、「特注」であればステップＳ１５５に進み、「特注」でなければステップＳ１４０に進む。
【００８０】
ステップＳ１４０では、障害データ優先順位付け部２３０は、ステップＳ１１０で読み込んだ障害データが「オプション」の要求仕様に基づくものであるか否かの判定を行う。この判定は、上述した「特注」についての判定と同様にして行われる。判定の結果、「オプション」であればステップＳ１５３に進み、「オプション」でなければステップＳ１５１に進む。
【００８１】
ステップＳ１５１では、障害データ優先順位付け部２３０は、全ての顧客についての「顧客別プロファイルＲＩ値と顧客ランクとの積」の和をトータルＲＩ値として算出する。ステップＳ１５３では、障害データ優先順位付け部２３０は、要求管理テーブル３４のオプション顧客フィールドに格納されているデータの顧客についての「顧客別プロファイルＲＩ値と顧客ランクとの積」の和をトータルＲＩ値として算出する。ステップＳ１５５では、障害データ優先順位付け部２３０は、要求管理テーブル３４の特注顧客フィールドに格納されているデータの顧客についての「顧客別プロファイルＲＩ値と顧客ランクとの積」をトータルＲＩ値として算出する。ステップＳ１５７では、障害データ優先順位付け部２３０は、トータルＲＩ値を「９９９９」とする。上記各ステップ（ステップＳ１５１〜Ｓ１５７）の終了後、ステップＳ１６０に進む。
【００８２】
ステップＳ１６０では、障害データ優先順位付け部２３０は、障害テーブル３１に格納されている障害データの全レコードの読み込みが終了したか否かを判定する。判定の結果、全レコードの読み込みが終了していればステップＳ１７０に進み、終了していなければステップＳ１１０に戻る。
【００８３】
ステップＳ１７０では、障害データ優先順位付け部２３０は、ステップＳ１５１、ステップＳ１５３、ステップＳ１５５、およびステップＳ１５７で算出したトータルＲＩ値に基づいて、障害データの優先順位付けを行う。このとき、例えば図２３に示した各障害データのトータルＲＩ値に基づいて、値の大きいものから小さいものへと各障害データに優先順位が割り当てられる。そして、トータルＲＩ値の大きい順に並べられた障害データの情報がパソコン８の表示部に表示される。これにより、障害データ優先順位付け処理が終了する。
【００８４】
＜４．テスト管理システムでの処理＞
次に、テスト管理システム３で行われる処理について説明する。処理としては、テストケースの情報をデータとして入力するための「テストケース入力処理」と、オペレータにより設定された条件に基づいて複数のテストケースの中から今回のフェーズでテストの対象とするべきテストケースを抽出する「テストケース抽出処理」とがある。なお、テスト管理システム３ではテスト結果を入力するための処理等も行われるが、本実施形態に係る内容とは特に関係がないので、説明を省略する。また、上述した障害管理システム２での処理と同様に、各処理を実行するためのオペレータの操作はパソコン８で行われるものとして説明する。
【００８５】
＜４．１  テストケース入力処理＞
まず、テストケース入力処理について説明する。テストケースの入力を行うためのメニュー等がオペレータによって選択されると、テストケース入力受付部３１０は、図２５に示すようなテストケース入力ダイアログ５４０を表示する。テストケース入力ダイアログ５４０には、テストケースに関する情報を表示するための表示領域（例えば、「テストプロジェクト」の名称を表示するための表示領域）と、テストケースに関する情報を入力するためのテキストボックス等（例えば、「テストケース番号」を入力するためのテキストボックス）と、入力内容を確定するための確定ボタン５４８と、入力内容を取り消すためのキャンセルボタン５４９とが含まれている。オペレータは、このテストケース入力ダイアログ５４０より、個々のテストケースの内容等の入力を行う。
【００８６】
オペレータによってテストケース入力ダイアログ５４０の確定ボタン５４８が押下されると、テストケース入力受付部３１０は、オペレータによる入力内容を取り込み、その入力内容に基づいてテストケーステーブル３３にレコードを１件追加する。
【００８７】
＜４．２  テストケース抽出処理＞
次に、テストケース抽出処理について説明する。図２６は、テストケース抽出処理の処理手順を示すフローチャートである。オペレータによってテストケース抽出処理のメニュー等が選択されると、テストケース抽出部３３０は、図２７に示すようなテストケース抽出ダイアログ５５０を表示する（ステップＳ２１０）。テストケース抽出ダイアログ５５０には、テストプロジェクト名を選択するためのテストプロジェクト名リストボックス５５１と、テストプロジェクトに含まれているテスト仕様書数を表示するためのテスト仕様書数表示領域５５２と、テストプロジェクトに含まれているテストケース数を表示するためのテストケース数表示領域５５３と、テスト種別を選択するためのテスト種別リストボックス５５４と、テストケースを絞り込む際の詳細な条件を設定するための間引きボタン５５５と、必ずテストが実施されるべきテストケースを選択するための必須ボタン５５６と、抽出するテストケース数を指定するための未実施数指定ボタン５５７と、入力内容を確定するための確定ボタン５５８と、入力内容を取り消すためのキャンセルボタン５５９とが含まれている。
【００８８】
オペレータによってテストプロジェクト名リストボックス５５１より対象となるテストプロジェクトが選択されると、当該テストプロジェクトに含まれているテスト仕様書の数がテスト仕様書数表示領域５５２に表示され、当該テストプロジェクトに含まれているテストケースの数がテストケース数表示領域５５３に表示される。テスト種別リストボックス５５４では、「修正確認テスト」、「機能テスト」、「回帰テスト」、「シナリオテスト」などのテスト種別の中から今回実施されるテストの種別が選択される。オペレータによって間引きボタン５５５が押下されると、所定のダイアログが表示され、オペレータはテストケースを絞り込む際の詳細な条件を当該ダイアログにて設定する。オペレータによって必須ボタン５５６が押下されると、所定のダイアログが表示され、オペレータは必ずテストが実施されるべきテストケースの条件を当該ダイアログにて設定する。
【００８９】
オペレータによってテストケース抽出ダイアログ５５０の確定ボタン５５８が押下されると、ステップＳ２２０に進み、テストケース抽出部３３０は、各種パラメータ値（テストケース抽出ダイアログ５５０でオペレータによって入力された値）を取得する。その後、ステップＳ２３０に進み、テストケース抽出部３３０は、テストケース抽出ダイアログ５５０でオペレータによって選択されたテスト種別が「修正確認テスト」であるか否かの判定を行う。判定の結果、「修正確認テスト」であればステップＳ２４０に進み、「修正確認テスト」でなければステップＳ２６０に進む。
【００９０】
ステップＳ２４０では、テストケース抽出部３３０は、データベース３０内のテストケーステーブル３３に含まれているテストケースについてのトータルＲＩ値に基づく優先順位付け処理を行う。なお、処理内容についての詳しい説明は後述する。ステップＳ２４０の終了後、ステップＳ２５０に進む。
【００９１】
ステップＳ２５０では、テストケース抽出部３３０は、ステップＳ２２０で取得したパラメータ値に基づいて、優先順位の高いものからテストケースを抽出する。このステップＳ２５０で抽出されたテストケースについては、テストケーステーブル３３の今回のテスト結果を示すフィールドに「未実施」というデータが書き込まれる。一方、このステップＳ２５０で抽出されなかったテストケースについては、テストケーステーブル３３の今回のテスト結果を示すフィールドに「見送り」というデータが書き込まれる。ステップＳ２５０の終了後、テストケース抽出処理は終了する。
【００９２】
ステップＳ２６０では、テストケース抽出部３３０は、データベース３０内のテストケーステーブル３３に含まれているテストケースについての過去の（テストの）実施結果に基づく優先順位付け処理を行う。テストケーステーブル３３には、各テストケースについての過去の実施結果（「成功」、「失敗」、「見送り」、「未実施」、「テスト中」、「テスト不可」）が格納されているので、例えば、「失敗」の回数に基づいて優先順位付け処理を行うことができる。ステップＳ２６０で各テストケースに割り当てられた優先順位は、例えば図２８に示すような一時テーブル３７の符号６０１で示すフィールドに書き込まれる。
【００９３】
ステップＳ２６０の終了後、ステップＳ２７０に進み、テストケース抽出部３３０は、データベース３０内のテストケーステーブル３３に含まれているテストケースについての機能別重要度に基づく優先順位付け処理を行う。ステップＳ２７０で各テストケースに割り当てられた優先順位は、図２７に示した一時テーブルの符号６０２で示すフィールドに書き込まれる。なお、機能別重要度に基づく優先順序付け処理についての詳しい説明は後述する。ステップＳ２８０では、テストケース抽出部３３０は、過去の実施結果に基づく優先順位および機能別重要度に基づく優先順位に基づいて、各テストケースに最終的な優先順位（最終順位）を割り当てる。ステップＳ２８０で各テストケースに割り当てられた優先順位は、図２８に示した一時テーブル３７の符号６０３で示すフィールドに書き込まれる。ステップＳ２８０の終了後、ステップＳ２９０に進む。
【００９４】
ステップＳ２９０では、テストケース抽出部３３０は、上記ステップＳ２５０と同様にして、ステップＳ２２０で取得したパラメータ値に基づいて、優先順位の高いものからテストケースを抽出する。ステップＳ２９０の終了後、テストケース抽出処理は終了する。
【００９５】
なお、本実施形態においては、ステップＳ２１０とステップＳ２２０とによってパラメータ値入力受付手段（ステップ）が実現され、ステップＳ２４０とステップＳ２５０とによって第１のテストケース抽出手段（ステップ）が実現され、ステップＳ２６０〜Ｓ２９０によって第２のテストケース抽出手段（ステップ）が実現されている。また、ステップＳ２４０によって第１のテストケース順位付け手段（ステップ）が実現され、ステップＳ２５０によって第１の抽出手段（ステップ）が実現されている。
【００９６】
＜４．３  トータルＲＩ値に基づく優先順位付け処理＞
図２９は、トータルＲＩ値に基づく優先順位付け処理の詳細な処理手順を示すフローチャートである。まず、データベース３０内のテストケーステーブル３３より１件のテストケースのレコードが読み込まれる（ステップＳ３００）。その後、ステップＳ３００で読み込まれたテストケースに対応する障害データについてのトータルＲＩ値が取得される（ステップＳ３１０）。図１１に示すようにテストケーステーブル３３には「障害番号」フィールドが設けられており、障害データに基づいて生成されたテストケースについては、当該フィールドに障害番号が格納されている。その障害番号をキーとして障害テーブル３１を参照することによりトータルＲＩ値が取得される。
【００９７】
ステップＳ３１０の終了後、ステップＳ３２０に進み、例えば図３０に示すような一時テーブル３８の符号６１１で示すフィールドに、ステップＳ３１０で取得されたトータルＲＩ値が書き込まれる。ステップＳ３２０の終了後、ステップＳ３３０に進み、テストケーステーブル３３に格納されているテストケースのデータの全レコードの読み込みが終了したか否かが判定される。判定の結果、全レコードの読み込みが終了していればステップＳ３４０に進み、終了していなければステップＳ３００に戻る。
【００９８】
ステップＳ３４０では、図３０に示す一時テーブル３８に格納されているテストケースのデータに、トータルＲＩ値に基づくソート（並び替え）が施される。そして、そのソート結果に基づいて、各テストケースに優先順位が割り当てられる。なお、ステップＳ３４０で各テストケースに割り当てられた優先順位は、図３０に示した一時テーブル３８の符号６１２で示すフィールドに書き込まれる。ステップＳ３４０の終了後、図２６のステップＳ２５０に進む。なお、トータルＲＩ値に基づく優先順位付け処理が行われたときには、上述したステップＳ２５０において、図３０に示した一時テーブル３８に書き込まれている優先順位に基づいてテストケースが抽出される。
【００９９】
なお、本実施形態においては、ステップＳ３１０によって障害評価値取得手段（ステップ）が実現されている。
【０１００】
＜４．４  機能別重要度に基づく優先順位付け処理＞
図３１は、機能別重要度に基づく優先順位付け処理の詳細な処理手順を示すフローチャートである。まず、データベース３０内のテストケーステーブル３３より１件のテストケースのレコードが読み込まれる（ステップＳ４００）。その後、ステップＳ４００で読み込まれたテストケースに対応する要求管理データについての機能別重要度が取得される（ステップＳ４１０）。図１１に示すようにテストケーステーブル３３には「要求管理番号」フィールドが設けられており、当該フィールドにはテストケースがどの要求仕様に基づくものかを示す要求管理番号が格納されている。その要求管理番号をキーとして要求管理テーブル３４を参照することにより機能別重要度が取得される。
【０１０１】
ここで、機能別重要度がどのようにして算出されるのかを図１４および図２２を参照しつつ説明する。図１４で要求管理番号が「０００１」のデータの要求項目は「標準」となっている。このように要求項目が「標準」となっているデータについては、全ての顧客についての顧客ランクの和が機能別重要度とされる。図２２では、Ａ社の顧客ランクは「３」、Ｂ社の顧客ランクは「２」、Ｃ社の顧客ランクは「１」となっているので、それらの和「６」が機能別重要度となる。図１４で要求管理番号が「０００３」のデータの要求項目は「オプション」となっている。このように要求項目が「オプション」となっているデータについては、「オプション顧客」フィールドに入力されている顧客についての顧客ランクの和が機能別重要度とされる。要求管理番号が「０００３」のデータの「オプション顧客」は「Ａ社、Ｃ社」となっているので、Ａ社の顧客ランク「３」とＣ社の顧客ランク「１」との和「６」が機能別重要度となる。図１４で要求管理番号が「０００５」のデータの要求項目は「特注」となっている。このように要求項目が「特注」となっているデータについては、「特注顧客」フィールドに入力されている顧客についての顧客ランクが機能別重要度とされる。要求管理番号が「０００５」のデータの「特注顧客」は「Ａ社」となっているので、Ａ社の顧客ランク「３」が機能別重要度となる。
【０１０２】
図３１のステップＳ４１０の終了後、ステップＳ４２０に進み、例えば図３２に示すような一時テーブル３９の符号６２１で示すフィールドに、ステップＳ４１０で取得された機能別重要度が書き込まれる。ステップＳ４２０の終了後、ステップＳ４３０に進み、テストケーステーブル３３に格納されているテストケースのデータの全レコードの読み込みが終了したか否かが判定される。判定の結果、全レコードの読み込みが終了していればステップＳ４４０に進み、終了していなければステップＳ４００に戻る。
【０１０３】
ステップＳ４４０では、図３２に示す一時テーブル３９に格納されているテストケースのデータに、機能別重要度に基づくソート（並び替え）が施される。そして、そのソート結果に基づいて、各テストケースに優先順位が割り当てられる。なお、ステップＳ４４０で各テストケースに割り当てられた優先順位は、図３２に示した一時テーブル３９の符号６２２で示すフィールドに書き込まれる。ステップＳ４４０の終了後、図２６のステップＳ２８０に進む。
【０１０４】
＜５．効果＞
本実施形態に係るソフトウェア開発管理システムによれば、ソフトウェアの障害に関する情報である障害データに、障害の評価項目として３つの評価項目（「重要度」、「優先度」、「発生確率」）が設けられており、３つの評価項目のそれぞれについて４段階での評価が行われる。また、障害データの優先順位付けを行う障害データ優先順位付け部２３０が設けられているところ、当該障害データ優先順位付け部２３０は、各障害データについての上記３つの評価項目の評価値に基づいて、障害データの優先順位付けを行う。このため、１つの項目について例えば３段階での評価が行われていた従来技術と比べて、様々な要因を考慮しつつ障害データの優先順位付けを行うことができる。これにより、障害についての対策を施すべき優先順位を様々な要因を考慮して決定することができる。
【０１０５】
また、このソフトウェア開発管理システムには、上記３つの評価項目に対する顧客毎の要求の強さ等を示すデータ（顧客プロファイルデータ）のオペレータによる入力を受け付ける顧客プロファイルデータ入力受付部２４０が設けられている。そして、障害データ毎に、各評価項目の評価値に顧客毎の要求の強さが反映された値である顧客別プロファイルＲＩ値が算出される。障害データ優先順位付け処理の際には、各障害を引き起こした機能を提供している顧客が要求管理テーブル３４に基づいて特定され、その特定された顧客のみについての顧客別プロファイルＲＩ値に基づいて、最終的な優先順位を決定するためのトータルＲＩ値が算出される。このため、障害に対する顧客の要求の強さを考慮しつつ障害データの優先順位付けを行うことができる。これにより、障害対策に顧客の要求が反映され、顧客満足度を向上させることができる。
【０１０６】
さらに、上記顧客プロファイルデータには、ユーザにとっての顧客の重要さを示す値である顧客ランクが含まれている。そして、障害データ優先順位付け処理の際には、顧客別プロファイルＲＩ値に顧客ランクを乗じた値に基づいてトータルＲＩ値が算出される。このため、ユーザにとっての顧客の重要さを考慮しつつ障害データの優先順位付けを行うことができる。これにより、例えば、ユーザにとって重要な顧客が早急な対策を望んでいる障害に優先的に処置を施すようなことができる。
【０１０７】
また、本実施形態によれば、ソフトウェア開発管理システムには、障害データのトータルＲＩ値に基づいてテストケースを抽出するテストケース抽出部３３０が設けられている。このため、テストケースの基となる障害に関する様々な要因を考慮しつつテストケースの抽出を行うことができる。これにより、例えば、障害による影響範囲が大きいものについては当該障害に対応するテストケースが優先的に抽出されるようにすることができる。
【０１０８】
さらに、本実施形態によれば、障害の修正確認テストであれば、障害データのトータルＲＩ値に基づいてテストケースが抽出され、障害の修正確認テストでなければ、テストケースの基となる機能の重要度や過去のテスト結果に基づいてテストケースが抽出される。このため、テストの種類に応じて、より好適なテストケースの抽出が行われる。
【０１０９】
＜６．変形例＞
図３３は、上記実施形態の変形例における顧客プロファイルテーブルのレコードフォーマットを示す図であり、図３４は当該テーブルにデータが格納された例を示す図である。障害に関する上記各評価項目に対する顧客の要求やこのシステムのユーザにとっての顧客の重要さについては、顧客の属する業界毎に特性がみられることがある。そこで、図３３に示すように顧客プロファイルテーブルに（顧客の属する）業界を示す情報を格納するためのフィールドを設けることにより、上述した障害データ優先付け処理やテストケース抽出処理の際に業界毎の特性を反映させることができる。例えば、図３４に示す例では、「Ｘ」という業界では「発生確率」に対する要求が高く、「Ｙ」という業界では「優先度」に対する要求が高いことが把握される。そして、このような業界毎の特性を考慮して上述したトータルＲＩ値を算出することにより、業界毎の特性を考慮した障害データ優先付け処理やテストケース抽出処理を行うことができる。
【０１１０】
＜７．その他＞
上述のソフトウェア開発管理装置７は、メモリ６０や補助記憶装置７０等のハードウェアの存在を前提として、ＣＰＵ１０によって実行されるテーブル作成等のプログラム２１〜２５に基づき実現される。このようなプログラム２１〜２５の一部または全部は、例えば、そのプログラム２１〜２５を記録したＣＤ−ＲＯＭ等のコンピュータ読み取り可能な記録媒体によって提供される。使用者は、上記プログラム２１〜２５の記録媒体としてのＣＤ−ＲＯＭを購入して、ＣＤ−ＲＯＭ駆動装置（図示せず）に装着し、そのＣＤ−ＲＯＭからそのプログラム２１〜２５を読み出してソフトウェア開発管理装置の補助記憶装置７０にインストールすることができる。このように、図２４等に示す各ステップをコンピュータに実行させるプログラムの形態として提供することもできる。
【図面の簡単な説明】
【０１１１】
【図１】本発明の基礎となる考え方のＦＭＥＡについて説明するための図である。
【図２】本発明の基礎となる考え方のＦＭＥＡについて説明するための図である。
【図３】本発明の一実施形態におけるシステムの全体構成図である。
【図４】上記実施形態において、ソフトウェア開発管理システムを実現するハードウェア構成図である。
【図５】ソフトウェア開発管理システムを実現するハードウェア構成の変形例を示す図である。
【図６】上記実施形態において、ソフトウェア開発管理装置の構成を示すブロック図である。
【図７】上記実施形態において、ソフトウェア開発管理システムを機能的な観点からみた機能ブロック図である。
【図８】上記実施形態において、テストケース抽出部の構成を示す図である。
【図９】上記実施形態において、障害テーブルのレコードフォーマットを示す図である。
【図１０】上記実施形態において、顧客プロファイルテーブルのレコードフォーマットを示す図である。
【図１１】上記実施形態において、テストケーステーブルのレコードフォーマットを示す図である。
【図１２】テストケーステーブルのレコードフォーマットの変形例を示す図である。
【図１３】上記実施形態において、要求管理テーブルのレコードフォーマットを示す図である。
【図１４】上記実施形態において、要求管理テーブルにデータが格納された例を示す図である。
【図１５】要求管理テーブルのレコードフォーマットの変形例を示す図である。
【図１６】上記実施形態において、障害データ入力ダイアログを示す図である。
【図１７】上記実施形態において、障害データ入力ダイアログの重要度リストボックスについて説明するための図である。
【図１８】上記実施形態において、指標解説ダイアログを示す図である。
【図１９】上記実施形態において、テストケース登録ダイアログを示す図である。
【図２０】上記実施形態において、顧客プロファイルデータ入力ダイアログを示す図である。
【図２１】上記実施形態において、障害テーブルにデータが格納された例を示す図である。
【図２２】上記実施形態において、顧客プロファイルテーブルにデータが格納された例を示す図である。
【図２３】上記実施形態において、各障害データについての（広義の）ＲＩ値を算出した結果を示す図である。
【図２４】上記実施形態において、障害データ優先順位付け処理の処理手順を示すフローチャートである。
【図２５】上記実施形態において、テストケース入力ダイアログを示す図である。
【図２６】上記実施形態において、テストケース抽出処理の処理手順を示すフローチャートである。
【図２７】上記実施形態において、テストケース抽出ダイアログを示す図である。
【図２８】上記実施形態において、テストケース抽出の際に使用される一時テーブルの例を示す図である。
【図２９】上記実施形態において、トータルＲＩ値に基づく優先順位付け処理の詳細な処理手順を示すフローチャートである。
【図３０】上記実施形態において、トータルＲＩ値に基づく優先順位付け処理の際に使用される一時テーブルの例を示す図である。
【図３１】上記実施形態において、機能別重要度に基づく優先順位付け処理の詳細な処理手順を示すフローチャートである。
【図３２】上記実施形態において、機能別重要度に基づく優先順位付け処理の際に使用される一時テーブルの例を示す図である。
【図３３】上記実施形態の変形例において、顧客プロファイルテーブルのレコードフォーマットを示す図である。
【図３４】上記実施形態の変形例において、顧客プロファイルテーブルにデータが格納された例を示す図である。
【図３５】ソフトウェアシステムの開発におけるテストについて説明するための図である。
【符号の説明】
【０１１２】
２…障害管理システム
３…テスト管理システム
７…サーバ機（ソフトウェア開発管理装置）
８…パソコン
３０…データベース
３１…障害テーブル
３２…顧客プロファイルテーブル
３３…テストケーステーブル
３４…要求管理テーブル
２１０…障害データ入力受付部
２２０…障害データ保持部
２３０…障害データ優先順位付け部
２４０…顧客プロファイルデータ入力受付部
２５０…顧客プロファイルデータ保持部
３１０…テストケース入力受付部
３２０…テストケース保持部
３３０…テストケース抽出部
４１０…要求管理データ保持部
５００…障害データ入力ダイアログ
５１０…指標解説ダイアログ
５２０…テストケース登録ダイアログ
５３０…顧客プロファイルデータ入力ダイアログ
５４０…テストケース入力ダイアログ
５５０…テストケース抽出ダイアログ
【図１】
2009181536.tif 000007
【図２】
2009181536.tif 000008
【図３】
2009181536.tif 000009
【図４】
2009181536.tif 000010
【図５】
2009181536.tif 000011
【図６】
2009181536.tif 000012
【図７】
2009181536.tif 000013
【図８】
2009181536.tif 000014
【図９】
2009181536.tif 000015
【図１０】
2009181536.tif 000016
【図１１】
2009181536.tif 000017
【図１２】
2009181536.tif 000018
【図１３】
2009181536.tif 000019
【図１４】
2009181536.tif 000020
【図１５】
2009181536.tif 000021
【図１６】
2009181536.tif 000022
【図１７】
2009181536.tif 000023
【図１８】
2009181536.tif 000024
【図１９】
2009181536.tif 000025
【図２０】
2009181536.tif 000026
【図２１】
2009181536.tif 000027
【図２２】
2009181536.tif 000028
【図２３】
2009181536.tif 000029
【図２４】
2009181536.tif 000030
【図２５】
2009181536.tif 000031
【図２６】
2009181536.tif 000032
【図２７】
2009181536.tif 000033
【図２８】
2009181536.tif 000034
【図２９】
2009181536.tif 000035
【図３０】
2009181536.tif 000036
【図３１】
2009181536.tif 000037
【図３２】
2009181536.tif 000038
【図３３】
2009181536.tif 000039
【図３４】
2009181536.tif 000040
【図３５】
2009181536.tif 000041