JP4002466B2 - 故障管理サーバ、故障モジュールの発生に伴うテスト作業支援システム並びにプログラム - Google Patents
故障管理サーバ、故障モジュールの発生に伴うテスト作業支援システム並びにプログラム Download PDFInfo
- Publication number
- JP4002466B2 JP4002466B2 JP2002135348A JP2002135348A JP4002466B2 JP 4002466 B2 JP4002466 B2 JP 4002466B2 JP 2002135348 A JP2002135348 A JP 2002135348A JP 2002135348 A JP2002135348 A JP 2002135348A JP 4002466 B2 JP4002466 B2 JP 4002466B2
- Authority
- JP
- Japan
- Prior art keywords
- module
- failure
- information
- test
- department
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Stored Programmes (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、故障モジュールの発生に伴うテスト作業を支援するための故障管理サーバ、テスト作業支援システム並びにプログラムに関する。
【０００２】
【従来の技術】
従来より、情報処理システムの開発・運用の場面で発生した故障において、故障処理票を用いた処理方法が知られている。故障処理すべき事案が発生すると、担当者は、故障処理票の発行を行うとともに、故障管理部門に対して故障処理票発行の連絡を行い、故障管理部門が、故障の原因となったモジュール（以下、故障モジュールともいう）の修正を行うべき開発・保守部門に対して、故障の連絡を行っている。
【０００３】
故障処理票を受け付けた開発・保守部門は、修正をなすべきモジュール（以下、修正モジュールともいう）について、いかなるバージョンのシステムに展開をする必要があるか判断して、故障管理部門に対して回答を行い、これを受けた故障管理部門が、テスト管理部門に対して連絡を行っている。
【０００４】
そして、テスト管理部門は、前記開発・保守部門の回答に基いて、修正モジュールのテストスケジュールの作成を行った後、そのテストスケジュールを開発・保守部門に対して連絡し、開発・保守部門が、修正モジュールの作業優先度を、テストスケジュールにあわせて設定し、修正作業を行っている。
【０００５】
【発明が解決しようとする課題】
しかしながら、こうした従来の故障処理票を用いた方法では、次のような問題点がある。第１の問題点は、修正モジュールが発生する度に、テストルートを設定するため、テスト回数が増加せざるを得ないことである。
【０００６】
第２の問題点は、総合的にテストスケジュールを考慮せずに、故障モジュールの修正を行っていたため、テストスケジュールが冗長となっていたことである。
【０００７】
そこで、部門間のネットワーク上に、上記した故障処理票コンテンツやテストスケジュールコンテンツを提供するサーバを設けて、各部門の協働を可能とするシステムを構築することが考えられるが、そのままでは、思うような効果を期待することは難しい。その理由は、テスト管理部門が、最適なテストスケジュールを組み立てるには、故障処理票に対する各開発・保守部門の適切な回答（展開すべきバージョンのシステムの有無、修正完了予定日等）が必要であり、その一方で、開発・保守部門が、効率良くその作業を行うためには、テストスケジュールは、常に最適化されている必要があるという相互依存関係が存在するからである。また、テスト管理部門と開発・保守部門との中継点をなす故障管理部門が従来行っていた、連絡作業は、単なる故障処理票に記載された情報の伝達に止まらず、テスト管理部門と開発・保守部門が作業を行いやすいよう情報を加工し、その内容をいかなる部門に伝達すべきかといった内容も含まれていたことも考慮しなければならない。
【０００８】
本発明は、上記事情に鑑みてなされたものであって、その目的とするところは、故障モジュールの発生に伴う各作業を最適化できる作業支援システム及びサーバ並びにプログラムを提供することにある。
【０００９】
【課題を解決するための手段】
前記課題を解決するための手段を提供する本発明の第１の視点によれば、ソースと該ソースから生成されるモジュールとを関連付けてなるソーステーブルと、モジュールと該モジュールの修正作業を行う部門の端末アドレスとを関連付けてなる担当情報と、を記憶保持し、モジュールのテスト作業を行う部門の端末に対して、少なくとも修正対象となるモジュールと、該モジュールのファイル統合を要する対象システムと、を関連付けてなるファイル統合情報を提供する故障管理サーバであって、故障の原因となったモジュールとその不具合内容とを含んだ故障情報の登録を受け付ける故障管理データベースと、前記故障管理データベースに新規の故障情報が登録された場合に、前記担当情報を参照して、前記故障の原因となったモジュールの修正作業を行う部門の端末に対して、前記新規に登録された故障情報を送信する手段と、前記故障情報及び前記ソーステーブルを参照して、前記送信した前記故障情報の回答として前記モジュールの修正作業を行う部門の端末より前記故障管理データベースに登録された修正対象となるソースに対応する修正対象となるモジュールを割り出すとともに、前記故障情報に基づき前記モジュールの修正作業を行う部門の端末より前記故障管理データベースに登録された前記故障箇所が存在する対象システムに基づいて、ファイル統合を要する対象システムを判定して、前記ファイル統合情報を生成する手段と、を備えたこと、を特徴とする故障管理サーバが提供される。
【００１４】
また、本発明の第２の視点によれば、上記各故障管理サーバと、モジュールのテスト作業を行う部門の端末と、を接続してなる故障モジュールの発生に伴うテスト作業支援システムが提供される。
【００１５】
また、本発明の第３の視点によれば、上記した故障管理サーバを構成するコンピュータに実行させるプログラムが提供される。
【００１６】
【発明の実施の形態】
続いて、本発明の一実施の形態について説明する。本発明は、その好ましい一実施の形態において、故障管理部門の故障管理サーバ（図１の１０）と、テスト管理部門のテスト管理サーバ（図１の２０）と、複数の端末（図１の３０）と、を相互に接続して、構成される。
【００１７】
故障管理サーバ（図１の１０）は、少なくとも、故障の発生が登録される修正モジュールのモジュールと、開発・保守部門の端末から送信される該修正モジュールの修正完了予定日情報とを関連付けて記憶保持するサーバである。
【００１８】
テスト管理サーバ（図１の２０）は、管理下にあるモジュールの階層構造を示すモジュール階層構造情報と、予め作成されたテストシナリオ群と、テストを要するモジュールとその修正完了予定日情報とを関連づけてなるテストモジュールリストと、テストシナリオと、その実行予定日（テスト予定日）を関連付けてなるテスト計画と、を記憶保持するとともに、前記故障管理サーバに対して前記修正モジュールの情報と、修正完了予定日情報とを要求して受信し、前記修正モジュールに応じてテストを行うべきテストモジュールを判定するテストモジュール判定手段と、テストモジュールの判定結果に基いてテスト計画を更新するテスト計画更新手段と、を備えている。
【００１９】
複数の端末（図１の３０）は、モジュールの修正作業を行う開発・保守部門の端末を含む、各部門に置かれる複数の端末である。
【００２０】
その作用を説明すると、まず、テスト管理サーバ（図１の２０）は、故障管理サーバ（図１の１０）に記憶保持された、前記修正モジュールに関する情報を監視し、修正モジュールの修正完了予定日情報の登録がなされると、テストモジュール判定手段を起動して、故障管理サーバ（図１の１０）からモジュールと、修正完了予定日情報とを入手し、次の処理を行わせる。
【００２１】
まず、テストモジュール判定手段は、前記モジュールの階層構造情報に基いて、入手した修正モジュールの最上位モジュールの判定処理を行う（図８のフローチャート参照）。続いて、テストモジュール判定手段は、前記判定処理により得られたテスト対象とすべきモジュールの情報と、入手した修正完了予定日情報とを、テストモジュールリストに加える処理を行う。
【００２２】
こうして、テストモジュールリストにテスト対象として加えられるモジュールは、修正対象となる修正モジュールそのものでなく、その最上位モジュールとなっている。
【００２３】
続いて、テスト計画を更新すべきイベント等の発生に応じて、テスト管理サーバ（図１の２０）は、テスト計画更新手段を起動して、以下の処理を行わせる。
【００２４】
テスト計画更新手段は、前記テストモジュールリストに含まれるすべてのテストモジュールについて、修正完了予定日情報に示された修正完了予定日以降となるよう、テスト予定日を、それぞれ設定して、前記テスト計画の更新を行う（図１０のフローチャート参照）。例えば、テストモジュールが、既存のテスト計画に含まれるテストシナリオに存在しない場合、或いは、前記テストシナリオに存在するがテスト予定日が前記条件に適合しない場合には、前記予め作成されたテストシナリオ群からテストモジュールが含まれるテストシナリオを選択するとともに、そのテスト予定日が前記修正完了予定日の同日以降となるようテスト計画を更新することで実現される。一方、テストモジュールが、既存のテスト計画に含まれるテストシナリオに存在し、テスト予定日も前記条件に適合している場合には、該テストシナリオに該テストモジュールを組み込む処理を行わせればよい。
【００２５】
このようにして更新されるテスト計画は、上述のとおり最上位モジュールを判定して作成され、さらに、一のテストシナリオには、可能な限り多くのテストを要するテストモジュールが組み込まれているため、冗長度が少ないものとなっている。また、そのテスト予定日は、修正モジュールの修正完了予定日以降となっているため、修正モジュールの修正作業の完了を待つことなく、テストシナリオを実行することが可能となっている。
【００２６】
また、故障管理サーバ（図１の１０）が、前記修正モジュール情報と、修正完了予定日情報に加え、該修正モジュールのファイル統合を要する対象（バージョン／システム）の情報と、関連付けて記憶保持するようにすれば、テスト管理サーバ（図１の２０）側において、対象（バージョン／システム）毎にテスト計画の更新処理を行わせることができる。
【００２７】
また、前記テスト計画に所望の加工を加え、テスト管理部門だけでなく、開発・保守部門からも参照可能とすることで、テスト管理部門のテスト計画に応じた、修正モジュールの修正作業を行わせることが可能となる。例えば、前記テスト計画のテストシナリオ毎のテスト予定日と、テストシナリオに含まれるテスト対象のモジュール及びそのソース名とを併せて参照可能とすることで、開発・保守部門に対して、いかなる修正モジュール／ソースを優先して、修正すべきかという有用な情報を提供することができる。
【００２８】
また、上記した故障管理サーバ（図１の１０）に、さらに、管理下にあるモジュールと、該モジュールの修正作業を行う部門の端末アドレスを関連付けてなる担当情報を、記憶保持させて、故障に係る情報を各部門の端末から受信して、記憶保持する機能と、開発・保守部門の適切な担当者から適切な回答が得られるよう、前記担当情報に基いて、前記故障に係る情報を転送する機能を持たせてもよい。該構成を採用することで、故障管理部門を中継点とする連絡業務の省力化を図ることができる。
【００２９】
【実施例】
続いて、上記した本発明の実施の形態をより詳細に説明すべく、本発明の一実施例について図面を参照して説明する。図１は、本発明の一実施例の全体構成を表した図である。図１を参照すると、故障管理部門の故障管理サーバ１０と、テスト管理部門のテスト管理サーバ２０と、複数の端末３０と、メールサーバ４０とを、ネットワーク５０を介して相互に接続してなる、情報処理システム開発、及び、運用時に発生した故障の原因となったモジュールの修正計画並びにテスト計画の管理を支援するシステムが示されている。
【００３０】
図２は、本発明の故障管理サーバ１０と、テスト管理サーバ２０の構成を示したブロック図である。図２を参照すると、故障管理サーバ１０は、故障管理データベース１１０と、ファイル統合情報データベース１２０と、電子メール送信手段１３０と、ファイル統合情報生成手段１４０と、を備えている。
【００３１】
故障管理データベース１１０には、故障の原因となった故障モジュールのモジュール名と、該モジュールの修正完了予定日情報と、該故障箇所が存在する対象（バージョン／システム）情報と、を関連付けてなる故障情報１０１と、本システムの管理下にあるモジュール毎に、該モジュールの修正担当の開発・保守部門の端末３０の電子メールアドレスを関連付けた担当情報１０２が記憶保持されている。ファイル統合情報データベース１２０には、本システムの管理下にあるソース名と各ソース名に対応するモジュール名とを関連付けてなるソーステーブル１０３と、故障情報１０１に基いて生成されるファイル統合情報１０４と、が記憶保持されている。電子メール送信手段１３０は、メールサーバ４０と連携して、故障情報１０１に含まれるモジュール名を参照して、担当情報１０２に対応するモジュール修正部門の端末３０に対して、故障情報１０１を含んだ電子メールを転送する手段である。ファイル統合情報生成手段１４０は、故障情報１０１に基いて、テスト管理サーバ２０に対して渡すべきファイル統合情報１０４を生成する手段である。
【００３２】
テスト管理サーバ２０は、テストモジュールデータベース２１０と、テストモジュール判定手段２２０と、テスト計画更新手段２３０と、作業優先度リスト更新・提供手段２４０とを備えて、テスト対象（バージョン／システム）毎に、テストの対象とするモジュール群と、そのテスト計画（テストシナリオリスト）と、の管理を行うサーバである。
【００３３】
テストモジュールデータベース２１０には、本システムの管理下にあるモジュールの階層構造を示すモジュール階層構造情報２０１と、予め作成されている、それぞれがテストのスケジュールを示すテストシナリオ群２０２と、テスト対象のモジュールを列記してなるテストモジュールリスト２０３と、作業対象であるバージョン／システム毎のテスト計画（テストシナリオリスト）２０４と、修正モジュールの修正作業の優先度を示す作業優先度リスト２０５と、が記憶保持されている。
【００３４】
図３は、テストモジュールデータベース２０３に格納される情報・リストの構成の一例を表した図である。図３を参照すると、モジュール階層構造情報２０１は、モジュール名と、その上位モジュールのモジュール名が関連付けられ、モジュールの上位のモジュールが示すことにより、管理下にあるモジュールの階層構造が示されたものとなっている。また、テストモジュールリスト２０３は、モジュール名と、その修正対象ソース名と、修正完了予定日とが関連付けられ、テストの対象とするモジュールの情報をリスト化したものとなっている。テスト計画（テストシナリオリスト）２０４は、選択されたテストシナリオと、そのテスト予定日とが関連付けられ、テストシナリオを実行するスケジュールをリスト化したものとなっている。
【００３５】
テストモジュール判定手段２２０は、ファイル統合情報１０４を解析して、テストを行うべきテストモジュールを判定してテストモジュールリスト２０３を更新する手段である。テスト計画更新手段２３０は、テストモジュール判定手段２２０により生成されるテストモジュールリスト２０３に基いて、テスト計画（テストシナリオリスト）２０４を更新する手段である。また、作業優先度リスト更新・提供手段２４０は、テスト計画（テストシナリオリスト）２０４に含まれるテスト予定日に基いて、対応するテストシナリオに含まれるテスト対象のモジュール毎に修正作業を行うべき優先度を決定して、作業優先度リスト２０５を生成し、前記修正モジュールの修正を行う部門の端末３０からの要求に応じて、前記作業優先度リストを参照させる手段である。
【００３６】
複数の端末３０は、故障モジュールの修正作業を行う開発・保守部門の端末を含む、各部門に置かれる複数の端末を構成するワークステーションやパーソナルコンピュータである。端末３０のうち、開発・保守部門の端末には、故障管理データベース１１０の登録済み故障情報１０１の修正権限が少なくとも与えられており、その他の端末には、故障情報１０１の新規登録権限が与えられている。
【００３７】
メールサーバ４０は、故障管理サーバ１０からの電子メールの送信依頼を受け取って、メール受信要求を行った端末に対して送信する、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ／Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）、ＰＯＰ（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ）等に対応する一般のメールサーバである。
【００３８】
ネットワーク５０は、上記故障管理サーバ１０と、テスト管理サーバ２０と、複数の端末３０と、メールサーバ４０とを相互に接続する、ＬＡＮ（ＬｏｃａｌＡｒｅａ Ｎｅｔｗｏｒｋ）等で構成されたネットワークである、
【００３９】
続いて、本実施例の動作について、図面を参照して、説明する。図４は、本実施例の動作の一例を表したフローチャートである。以下、図４及び図４に示された各処理を表した詳細図（図５から図１２）を適宜参照して説明する。
【００４０】
図５は、従来の故障処理票の起票に代えて、故障管理サーバに対する端末３０からの故障情報１０１の新規登録処理と、故障管理サーバ１０の電子メール送信手段１３０により行われる電子メールの転送処理を説明するための図である。
【００４１】
まず、故障が発生した場合、その担当者は、端末３０から、故障管理サーバ１０にアクセスして、故障管理データベース１１０に、故障の原因となった故障モジュールのモジュール名を含んだ故障情報１０１を登録する（図４のステップＳ１）。なお、この時点においては、修正対象ソース名や該故障モジュールの修正完了予定日や該故障箇所が存在する対象（バージョン／システム）は、不明であるため、登録されてない。
【００４２】
前記故障情報１０１の登録処理がなされると、故障管理サーバ１０は、前記故障情報１０１に含まれる故障モジュール名と、担当情報１０２とを照合して、該故障モジュールの開発・保守部門の端末の電子メールアドレスを特定し、特定された開発・保守部門の電子メールアドレスに対して、メールサーバ４０を介して、前記故障情報１０１の内容を含んだ電子メールを送信する（図４のステップＳ２）。該電子メールは、予め定められたテンプレートに、故障情報１０１に含まれる各項目を転写することによって生成されている。
【００４３】
図６は、前記電子メールに対する開発・保守部門からの回答入力処理（故障情報更新処理）と、前記回答内容に基いて故障管理サーバ１０がファイル統合情報１０４を生成する処理と、テスト管理サーバ２０がファイル統合情報１０４に応じた、テストの対象とすべきテストモジュールを判定してテストモジュールリスト２０３を更新する処理と、を説明するための図である。
【００４４】
まず、前記ステップＳ２において、故障情報が含まれた電子メールを受け取った担当者により、故障管理サーバ１０へのアクセスが行われ、前記電子メールに対する回答として、修正対象ソース名と、該ソースの修正完了予定日と、該故障箇所が存在する対象（バージョン／システム）情報と、の入力がなされて、故障情報１０１が更新される（図４のステップＳ３）。
【００４５】
前記故障情報１０１の更新がなされると、故障管理サーバ１０は、ファイル統合情報生成手段１４０を起動して、前記更新された故障情報１０１に含まれる、修正対象ソース名と、該ソースの修正完了予定日と、該故障箇所が存在する対象（バージョン／システム）情報と、自装置側で記憶保持するソーステーブル１０３と、に基いて、テスト管理サーバ２０に渡すべきファイル統合情報１０４を生成し、ファイル統合情報データベース１２０に格納する（図４のステップＳ４）。
【００４６】
図７は、ファイル統合情報生成手段１４０において行われる、該修正対象ソースからモジュールのファイル統合を要する対象（バージョン／システム）を判定するアルゴリズムの一例を示すフローチャートである。図７を参照すると、まず、ファイル統合情報生成手段１４０は、前記更新された故障情報１０１に含まれる修正対象ソース名とソーステーブル１０３とを参照して、修正対象ソース名より生成されるモジュール名を取得する（ステップＳ４−１）。続いて、ファイル統合情報生成手段１４０は、該故障箇所が存在する対象（バージョン／システム）情報に基いて、修正対象ソースにより生成されるモジュール・ファイルのファイル統合が必要な作業対象（バージョン／システム）を判定する（ステップＳ４−２、Ｓ４−３）。上記処理を、対象となるシステムのすべてのバージョンについて、繰り返し実行する。
【００４７】
上記処理により生成されるファイル統合情報１０４は、修正対象ソース名と、該ソースから生成される修正モジュール名と、該修正モジュールの修正完了予定日と、作業対象情報（バージョン／システム）と、が関連付けられたものとなっており、修正モジュール及び修正モジュールが存在する作業対象情報（バージョン／システム）が把握できるものとなっている。後述するように本実施例では、ファイル統合情報１０４が生成されることにより、テスト管理サーバ２０において、テスト対象のモジュールの判定並びにテスト計画の更新が実行可能となる。
【００４８】
このようにして、ファイル統合情報１０４が、新たに登録されると、ファイル統合情報１０４を監視するテスト管理サーバ２０のテストモジュール判定手段２２０は、故障管理サーバ１０に対して、ファイル統合情報１０４を要求して受信し、ファイル統合情報１０４と、テストモジュールデータベース２１０に記憶保持されているモジュール階層構造情報２０１に基いて、テストが必要な最上位のモジュールを判定し、テストモジュールリスト２０３に追加する処理を開始する（図４のステップＳ５）。
【００４９】
図８は、ファイル統合情報１０４に含まれるモジュール名からテストが必要な最上位のモジュールを判定するアルゴリズムの一例を示すフローチャートである。図８を参照すると、まず、テストモジュール判定手段２２０は、モジュール階層構造情報２０１を参照して、ファイル統合情報１０４に含まれる修正モジュール名に対応するモジュールの上位モジュール名を取得する（ステップＳ５−１）。ここで、上位モジュールが存在する場合には、順次、さらに上位のモジュール名を取得する処理を繰り返し（ステップＳ５−２）、上位のモジュールが存在しなくなった時点で、該モジュールをテストの対象とするテストモジュールに決定する（ステップＳ５−３）。なお、モジュールの階層構成上、上位モジュール候補が複数存在する場合が発生し得る。この場合は、故障モジュールを選択するようにし、上位モジュール候補に故障モジュールが存在しない場合は、最初の上位モジュール候補を選択する等の選択則を予め定めることで、解決される。
【００５０】
続いて、テスト管理サーバ２０は、テスト計画更新手段２３０を起動して、前記最上位モジュールの判定処理の結果が反映されたテストモジュールリスト２０３に基いて、テスト計画（テストシナリオリスト）の更新処理を開始する。図９は、テスト計画（テストシナリオリスト）の更新の際に行われるテストシナリオの選定処理を説明するための図である。図９を参照すると、テスト計画更新手段２３０は、テストモジュールリスト２０３と、テストシナリオ群２０２とを参照して、テストモジュールリスト２０３に含まれるすべてのモジュールのテスト予定日が、対応する修正完了予定日以降となるよう、前記テストシナリオを選定するとともに前記テスト予定日を設定して、前記テスト計画（テストシナリオリスト）２０４を更新する処理を行う（図４のステップＳ６）。
【００５１】
図１０は、テストシナリオ選定のアルゴリズムの一例を示すフローチャートである。図１０を参照すると、まず、テスト計画更新手段２３０は、テストモジュールリスト２０３から追加がなされたテストモジュールのデータ（図３参照）を取得する（ステップＳ６−１）。そして、既存のテスト計画（テストシナリオリスト）２０４に含まれるテストシナリオのいずれかに、該テスト対象のモジュールが存在し、かつ、該テストシナリオのテスト予定日が、該テスト対象のモジュールの修正完了予定日以降である場合には、該テストモジュールを該テストシナリオに組み込む処理を行い終了する（ステップＳ６−２）。一方、上記条件を満たさない場合には、テストシナリオ群２０２から該テスト対象のモジュールが含まれるテストシナリオを抽出し表示して、操作者の選択を誘引する（ステップＳ６−３）。前記表示がなされたテストシナリオに基いて、操作者がテストシナリオの選択を行うと、テスト計画更新手段２３０は、該テストシナリオをテスト計画（テストシナリオリスト）２０４に追加し（ステップＳ６−４）、そのテスト予定日としてテストモジュールリスト２０３より得られる修正完了予定日を設定して、終了する（ステップＳ６−５）。
【００５２】
このようにして更新されるテスト計画（テストシナリオリスト）２０４は、最も少ないテスト回数で、テストが必要なすべてのテスト対象のモジュールのテストを行い得るものとなっている。その理由は、修正モジュールそのものでなく、修正モジュールの最上位にあるモジュールを判定し、可能な限り既存のテストシナリオにおいてテストを完了できるよう構成したことにある。
【００５３】
また、併せて、テスト計画（テストシナリオリスト）２０４は、修正が完了したモジュールのテストを滞ることなく実行できるものとなっている。その理由は、テスト計画（テストシナリオリスト）２０４にテストシナリオを新たに加える場合であっても（ステップＳ６−３以降）、そのテスト予定日が前記修正完了予定日の同日以降とする条件下で、可能な限り滞留をなくすよう、テスト予定日を該モジュールの修正完了予定日と同日に設定したことにある（ステップＳ６−５参照）。
【００５４】
なお、ファイル統合情報１０４の作業対象情報（バージョン／システム）に、複数の作業対象（バージョン／システム）が存在する場合には、テスト管理サーバ２０において上記ステップＳ５からＳ６とを繰り返すことで、展開を行うべき作業対象（バージョン／システム）毎のテスト計画（テストシナリオリスト）を得ることができる。
【００５５】
続いて、テスト管理サーバ２０は、作業優先度リスト更新・提供手段２４０を起動して、好ましい修正モジュールの修正作業の順序を指示すべく、作業優先度リスト２０５を生成し、開発・保守部門の端末３０からの要求がなされた場合には、作業優先度リスト２０５を送信する（ステップＳ７）。
【００５６】
図１１は、作業優先度リストの作成処理と、作業優先度リストが開発・保守部門から参照される処理と、を説明するための図である。図１１を参照すると、まず、作業優先度リスト更新・提供手段２４０は、テスト計画（テストシナリオリスト）２０４を参照して、作業優先度リスト２０５を更新し、開発・保守部門の端末３０から、作業優先度リスト２０５の送信要求がなされた場合に、作業優先度リスト２０５を送信するものとなっている。
【００５７】
図１２は、作業優先度決定のアルゴリズムの一例を示すフローチャートである。図１２を参照すると、まず、作業優先度リスト更新・提供手段２４０は、テスト計画（テストシナリオリスト）２０４からテスト予定日の早い順にテストシナリオのデータを取得し（ステップＳ７−１）、続いて、テストの実行順に該テストシナリオに含まれるテスト対象のモジュール名を取得する（ステップＳ７−２）。続いて、作業優先度リスト更新・提供手段２４０は、テストモジュールリスト２０３より、前記テスト対象のモジュールに対応する修正対象ソース名をすべて取得し（ステップＳ７−３）、前記各修正対象ソース名を作業優先度リスト２０５に追加する（ステップＳ７−４）。上記ステップＳ７−２からＳ７−４の各処理を、該テストシナリオに存在するすべてのテスト対象のモジュールについて行い、さらに、テスト計画（テストシナリオリスト）２０４に含まれるすべてのテストシナリオについて、上記ステップＳ７−１からＳ７−４の各処理を、繰り返し実行する。
【００５８】
このように更新される作業優先度リスト２０５は、開発・保守部門の端末３０からの要求に応じて、端末３０に対して送信される（図１１参照）。そして、作業優先度リスト２０５は、また、テスト予定日の順に整列されているため、上位に存在する修正ソース名ほど、より優先度の高いものとなっており、開発・保守部門の担当者は、より上位にあるソースの修正作業を優先して行うことで、効率的に修正作業を行うことが可能となる。
【００５９】
また、テスト計画（テストシナリオリスト）２０４が、複数の作業対象（バージョン／システム）毎に作成されている場合には、上記したステップＳ７−１における読み込むべきテスト計画（テストシナリオリスト）を変更することで、作業対象（バージョン／システム）毎の作業優先度リスト２０５を得ることができる。
【００６０】
以上、本発明の実施の形態並びに実施例を、図面を参照して、説明したが、上記各実施の形態並びに実施例として記載した事項及び図面の内容は、本発明の技術的範囲を限定するものではなく、特許請求の範囲の記載の範囲内で、当業者であれば、なし得るであろう各種変形、修正を含むことはもちろんである。例えば、上記した実施例では、故障情報の転送手段として、メールサーバ４０を用いた例を説明したが、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）等、その他の情報転送プロトコルに対応するサーバを用いて転送させても同様の効果が奏される。また、上記した実施例における故障管理サーバ並びにテスト管理サーバにより提供・出力される各種情報・リストの類の構成や、例示したアルゴリズムは、各サーバ及び本システム全体の仕様等に応じて変更されるべき事項であって、実施例に示した例に限定されるものではない。
【００６１】
【効果の説明】
本発明によれば、故障モジュールの修正からテストまでの時間的、作業的な冗長性を大きく減少させることができる。その理由は、滞留時間、冗長度の少ないテスト計画（テストシナリオリスト）の生成を可能とする構成を採用したこと、故障発生の際の故障管理部門の各作業を極力自動化したことにある。
【図面の簡単な説明】
【図１】本発明の一実施例の全体構成を表した図である。
【図２】故障管理サーバと、テスト管理サーバの構成の一例を示したブロック図である。
【図３】テストモジュールデータベースに記憶保持される情報の構成を表した図である。
【図４】本発明の一実施例の動作を表したフローチャートである。
【図５】故障が発生した場合に、開発・保守部門に電子メールが自動配信される処理を説明するための図である。
【図６】開発・保守部門からの回答処理（故障情報更新処理）と、前記回答内容に基いたファイル統合情報の生成処理と、ファイル統合情報に応じたテストモジュールリストの生成処理と、を説明するための図である。
【図７】モジュールのファイル統合が必要な作業対象（バージョン／システム）を判定するアルゴリズムの一例を示すフローチャートである。
【図８】テスト対象とする、最上位のモジュールを判定するアルゴリズムの一例を示すフローチャートである。
【図９】テスト計画（テストシナリオリスト）を更新する処理を説明するための図である。
【図１０】テストシナリオ選定のアルゴリズムの一例を示すフローチャートである。
【図１１】作業優先度リストの作成処理と、作業優先度リストが開発・保守部門から参照される処理と、を説明するための図である。
【図１２】作業優先度決定のアルゴリズムの一例を示すフローチャートである。
【符号の説明】
１０ 故障管理サーバ
２０ テスト管理サーバ
３０ 端末
４０ メールサーバ
５０ ネットワーク
１０１ 故障情報
１０２ 担当情報
１０３ ソーステーブル
１０４ ファイル統合情報
１１０ 故障管理データベース
１２０ ファイル統合情報データベース
１３０ 電子メール送信手段
１４０ ファイル統合情報生成手段
２０１ モジュール階層構造情報
２０２ テストシナリオ群
２０３ テストモジュールリスト
２０４ テスト計画（テストシナリオリスト）
２０５ 作業優先度リスト
２１０ テストモジュールデータベース
２２０ テストモジュール判定手段
２３０ テスト計画更新手段
２４０ 作業優先度リスト更新・提供手段
【発明の属する技術分野】
本発明は、故障モジュールの発生に伴うテスト作業を支援するための故障管理サーバ、テスト作業支援システム並びにプログラムに関する。
【０００２】
【従来の技術】
従来より、情報処理システムの開発・運用の場面で発生した故障において、故障処理票を用いた処理方法が知られている。故障処理すべき事案が発生すると、担当者は、故障処理票の発行を行うとともに、故障管理部門に対して故障処理票発行の連絡を行い、故障管理部門が、故障の原因となったモジュール（以下、故障モジュールともいう）の修正を行うべき開発・保守部門に対して、故障の連絡を行っている。
【０００３】
故障処理票を受け付けた開発・保守部門は、修正をなすべきモジュール（以下、修正モジュールともいう）について、いかなるバージョンのシステムに展開をする必要があるか判断して、故障管理部門に対して回答を行い、これを受けた故障管理部門が、テスト管理部門に対して連絡を行っている。
【０００４】
そして、テスト管理部門は、前記開発・保守部門の回答に基いて、修正モジュールのテストスケジュールの作成を行った後、そのテストスケジュールを開発・保守部門に対して連絡し、開発・保守部門が、修正モジュールの作業優先度を、テストスケジュールにあわせて設定し、修正作業を行っている。
【０００５】
【発明が解決しようとする課題】
しかしながら、こうした従来の故障処理票を用いた方法では、次のような問題点がある。第１の問題点は、修正モジュールが発生する度に、テストルートを設定するため、テスト回数が増加せざるを得ないことである。
【０００６】
第２の問題点は、総合的にテストスケジュールを考慮せずに、故障モジュールの修正を行っていたため、テストスケジュールが冗長となっていたことである。
【０００７】
そこで、部門間のネットワーク上に、上記した故障処理票コンテンツやテストスケジュールコンテンツを提供するサーバを設けて、各部門の協働を可能とするシステムを構築することが考えられるが、そのままでは、思うような効果を期待することは難しい。その理由は、テスト管理部門が、最適なテストスケジュールを組み立てるには、故障処理票に対する各開発・保守部門の適切な回答（展開すべきバージョンのシステムの有無、修正完了予定日等）が必要であり、その一方で、開発・保守部門が、効率良くその作業を行うためには、テストスケジュールは、常に最適化されている必要があるという相互依存関係が存在するからである。また、テスト管理部門と開発・保守部門との中継点をなす故障管理部門が従来行っていた、連絡作業は、単なる故障処理票に記載された情報の伝達に止まらず、テスト管理部門と開発・保守部門が作業を行いやすいよう情報を加工し、その内容をいかなる部門に伝達すべきかといった内容も含まれていたことも考慮しなければならない。
【０００８】
本発明は、上記事情に鑑みてなされたものであって、その目的とするところは、故障モジュールの発生に伴う各作業を最適化できる作業支援システム及びサーバ並びにプログラムを提供することにある。
【０００９】
【課題を解決するための手段】
前記課題を解決するための手段を提供する本発明の第１の視点によれば、ソースと該ソースから生成されるモジュールとを関連付けてなるソーステーブルと、モジュールと該モジュールの修正作業を行う部門の端末アドレスとを関連付けてなる担当情報と、を記憶保持し、モジュールのテスト作業を行う部門の端末に対して、少なくとも修正対象となるモジュールと、該モジュールのファイル統合を要する対象システムと、を関連付けてなるファイル統合情報を提供する故障管理サーバであって、故障の原因となったモジュールとその不具合内容とを含んだ故障情報の登録を受け付ける故障管理データベースと、前記故障管理データベースに新規の故障情報が登録された場合に、前記担当情報を参照して、前記故障の原因となったモジュールの修正作業を行う部門の端末に対して、前記新規に登録された故障情報を送信する手段と、前記故障情報及び前記ソーステーブルを参照して、前記送信した前記故障情報の回答として前記モジュールの修正作業を行う部門の端末より前記故障管理データベースに登録された修正対象となるソースに対応する修正対象となるモジュールを割り出すとともに、前記故障情報に基づき前記モジュールの修正作業を行う部門の端末より前記故障管理データベースに登録された前記故障箇所が存在する対象システムに基づいて、ファイル統合を要する対象システムを判定して、前記ファイル統合情報を生成する手段と、を備えたこと、を特徴とする故障管理サーバが提供される。
【００１４】
また、本発明の第２の視点によれば、上記各故障管理サーバと、モジュールのテスト作業を行う部門の端末と、を接続してなる故障モジュールの発生に伴うテスト作業支援システムが提供される。
【００１５】
また、本発明の第３の視点によれば、上記した故障管理サーバを構成するコンピュータに実行させるプログラムが提供される。
【００１６】
【発明の実施の形態】
続いて、本発明の一実施の形態について説明する。本発明は、その好ましい一実施の形態において、故障管理部門の故障管理サーバ（図１の１０）と、テスト管理部門のテスト管理サーバ（図１の２０）と、複数の端末（図１の３０）と、を相互に接続して、構成される。
【００１７】
故障管理サーバ（図１の１０）は、少なくとも、故障の発生が登録される修正モジュールのモジュールと、開発・保守部門の端末から送信される該修正モジュールの修正完了予定日情報とを関連付けて記憶保持するサーバである。
【００１８】
テスト管理サーバ（図１の２０）は、管理下にあるモジュールの階層構造を示すモジュール階層構造情報と、予め作成されたテストシナリオ群と、テストを要するモジュールとその修正完了予定日情報とを関連づけてなるテストモジュールリストと、テストシナリオと、その実行予定日（テスト予定日）を関連付けてなるテスト計画と、を記憶保持するとともに、前記故障管理サーバに対して前記修正モジュールの情報と、修正完了予定日情報とを要求して受信し、前記修正モジュールに応じてテストを行うべきテストモジュールを判定するテストモジュール判定手段と、テストモジュールの判定結果に基いてテスト計画を更新するテスト計画更新手段と、を備えている。
【００１９】
複数の端末（図１の３０）は、モジュールの修正作業を行う開発・保守部門の端末を含む、各部門に置かれる複数の端末である。
【００２０】
その作用を説明すると、まず、テスト管理サーバ（図１の２０）は、故障管理サーバ（図１の１０）に記憶保持された、前記修正モジュールに関する情報を監視し、修正モジュールの修正完了予定日情報の登録がなされると、テストモジュール判定手段を起動して、故障管理サーバ（図１の１０）からモジュールと、修正完了予定日情報とを入手し、次の処理を行わせる。
【００２１】
まず、テストモジュール判定手段は、前記モジュールの階層構造情報に基いて、入手した修正モジュールの最上位モジュールの判定処理を行う（図８のフローチャート参照）。続いて、テストモジュール判定手段は、前記判定処理により得られたテスト対象とすべきモジュールの情報と、入手した修正完了予定日情報とを、テストモジュールリストに加える処理を行う。
【００２２】
こうして、テストモジュールリストにテスト対象として加えられるモジュールは、修正対象となる修正モジュールそのものでなく、その最上位モジュールとなっている。
【００２３】
続いて、テスト計画を更新すべきイベント等の発生に応じて、テスト管理サーバ（図１の２０）は、テスト計画更新手段を起動して、以下の処理を行わせる。
【００２４】
テスト計画更新手段は、前記テストモジュールリストに含まれるすべてのテストモジュールについて、修正完了予定日情報に示された修正完了予定日以降となるよう、テスト予定日を、それぞれ設定して、前記テスト計画の更新を行う（図１０のフローチャート参照）。例えば、テストモジュールが、既存のテスト計画に含まれるテストシナリオに存在しない場合、或いは、前記テストシナリオに存在するがテスト予定日が前記条件に適合しない場合には、前記予め作成されたテストシナリオ群からテストモジュールが含まれるテストシナリオを選択するとともに、そのテスト予定日が前記修正完了予定日の同日以降となるようテスト計画を更新することで実現される。一方、テストモジュールが、既存のテスト計画に含まれるテストシナリオに存在し、テスト予定日も前記条件に適合している場合には、該テストシナリオに該テストモジュールを組み込む処理を行わせればよい。
【００２５】
このようにして更新されるテスト計画は、上述のとおり最上位モジュールを判定して作成され、さらに、一のテストシナリオには、可能な限り多くのテストを要するテストモジュールが組み込まれているため、冗長度が少ないものとなっている。また、そのテスト予定日は、修正モジュールの修正完了予定日以降となっているため、修正モジュールの修正作業の完了を待つことなく、テストシナリオを実行することが可能となっている。
【００２６】
また、故障管理サーバ（図１の１０）が、前記修正モジュール情報と、修正完了予定日情報に加え、該修正モジュールのファイル統合を要する対象（バージョン／システム）の情報と、関連付けて記憶保持するようにすれば、テスト管理サーバ（図１の２０）側において、対象（バージョン／システム）毎にテスト計画の更新処理を行わせることができる。
【００２７】
また、前記テスト計画に所望の加工を加え、テスト管理部門だけでなく、開発・保守部門からも参照可能とすることで、テスト管理部門のテスト計画に応じた、修正モジュールの修正作業を行わせることが可能となる。例えば、前記テスト計画のテストシナリオ毎のテスト予定日と、テストシナリオに含まれるテスト対象のモジュール及びそのソース名とを併せて参照可能とすることで、開発・保守部門に対して、いかなる修正モジュール／ソースを優先して、修正すべきかという有用な情報を提供することができる。
【００２８】
また、上記した故障管理サーバ（図１の１０）に、さらに、管理下にあるモジュールと、該モジュールの修正作業を行う部門の端末アドレスを関連付けてなる担当情報を、記憶保持させて、故障に係る情報を各部門の端末から受信して、記憶保持する機能と、開発・保守部門の適切な担当者から適切な回答が得られるよう、前記担当情報に基いて、前記故障に係る情報を転送する機能を持たせてもよい。該構成を採用することで、故障管理部門を中継点とする連絡業務の省力化を図ることができる。
【００２９】
【実施例】
続いて、上記した本発明の実施の形態をより詳細に説明すべく、本発明の一実施例について図面を参照して説明する。図１は、本発明の一実施例の全体構成を表した図である。図１を参照すると、故障管理部門の故障管理サーバ１０と、テスト管理部門のテスト管理サーバ２０と、複数の端末３０と、メールサーバ４０とを、ネットワーク５０を介して相互に接続してなる、情報処理システム開発、及び、運用時に発生した故障の原因となったモジュールの修正計画並びにテスト計画の管理を支援するシステムが示されている。
【００３０】
図２は、本発明の故障管理サーバ１０と、テスト管理サーバ２０の構成を示したブロック図である。図２を参照すると、故障管理サーバ１０は、故障管理データベース１１０と、ファイル統合情報データベース１２０と、電子メール送信手段１３０と、ファイル統合情報生成手段１４０と、を備えている。
【００３１】
故障管理データベース１１０には、故障の原因となった故障モジュールのモジュール名と、該モジュールの修正完了予定日情報と、該故障箇所が存在する対象（バージョン／システム）情報と、を関連付けてなる故障情報１０１と、本システムの管理下にあるモジュール毎に、該モジュールの修正担当の開発・保守部門の端末３０の電子メールアドレスを関連付けた担当情報１０２が記憶保持されている。ファイル統合情報データベース１２０には、本システムの管理下にあるソース名と各ソース名に対応するモジュール名とを関連付けてなるソーステーブル１０３と、故障情報１０１に基いて生成されるファイル統合情報１０４と、が記憶保持されている。電子メール送信手段１３０は、メールサーバ４０と連携して、故障情報１０１に含まれるモジュール名を参照して、担当情報１０２に対応するモジュール修正部門の端末３０に対して、故障情報１０１を含んだ電子メールを転送する手段である。ファイル統合情報生成手段１４０は、故障情報１０１に基いて、テスト管理サーバ２０に対して渡すべきファイル統合情報１０４を生成する手段である。
【００３２】
テスト管理サーバ２０は、テストモジュールデータベース２１０と、テストモジュール判定手段２２０と、テスト計画更新手段２３０と、作業優先度リスト更新・提供手段２４０とを備えて、テスト対象（バージョン／システム）毎に、テストの対象とするモジュール群と、そのテスト計画（テストシナリオリスト）と、の管理を行うサーバである。
【００３３】
テストモジュールデータベース２１０には、本システムの管理下にあるモジュールの階層構造を示すモジュール階層構造情報２０１と、予め作成されている、それぞれがテストのスケジュールを示すテストシナリオ群２０２と、テスト対象のモジュールを列記してなるテストモジュールリスト２０３と、作業対象であるバージョン／システム毎のテスト計画（テストシナリオリスト）２０４と、修正モジュールの修正作業の優先度を示す作業優先度リスト２０５と、が記憶保持されている。
【００３４】
図３は、テストモジュールデータベース２０３に格納される情報・リストの構成の一例を表した図である。図３を参照すると、モジュール階層構造情報２０１は、モジュール名と、その上位モジュールのモジュール名が関連付けられ、モジュールの上位のモジュールが示すことにより、管理下にあるモジュールの階層構造が示されたものとなっている。また、テストモジュールリスト２０３は、モジュール名と、その修正対象ソース名と、修正完了予定日とが関連付けられ、テストの対象とするモジュールの情報をリスト化したものとなっている。テスト計画（テストシナリオリスト）２０４は、選択されたテストシナリオと、そのテスト予定日とが関連付けられ、テストシナリオを実行するスケジュールをリスト化したものとなっている。
【００３５】
テストモジュール判定手段２２０は、ファイル統合情報１０４を解析して、テストを行うべきテストモジュールを判定してテストモジュールリスト２０３を更新する手段である。テスト計画更新手段２３０は、テストモジュール判定手段２２０により生成されるテストモジュールリスト２０３に基いて、テスト計画（テストシナリオリスト）２０４を更新する手段である。また、作業優先度リスト更新・提供手段２４０は、テスト計画（テストシナリオリスト）２０４に含まれるテスト予定日に基いて、対応するテストシナリオに含まれるテスト対象のモジュール毎に修正作業を行うべき優先度を決定して、作業優先度リスト２０５を生成し、前記修正モジュールの修正を行う部門の端末３０からの要求に応じて、前記作業優先度リストを参照させる手段である。
【００３６】
複数の端末３０は、故障モジュールの修正作業を行う開発・保守部門の端末を含む、各部門に置かれる複数の端末を構成するワークステーションやパーソナルコンピュータである。端末３０のうち、開発・保守部門の端末には、故障管理データベース１１０の登録済み故障情報１０１の修正権限が少なくとも与えられており、その他の端末には、故障情報１０１の新規登録権限が与えられている。
【００３７】
メールサーバ４０は、故障管理サーバ１０からの電子メールの送信依頼を受け取って、メール受信要求を行った端末に対して送信する、ＳＭＴＰ（Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ／Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）、ＰＯＰ（Ｐｏｓｔ Ｏｆｆｉｃｅ Ｐｒｏｔｏｃｏｌ）等に対応する一般のメールサーバである。
【００３８】
ネットワーク５０は、上記故障管理サーバ１０と、テスト管理サーバ２０と、複数の端末３０と、メールサーバ４０とを相互に接続する、ＬＡＮ（ＬｏｃａｌＡｒｅａ Ｎｅｔｗｏｒｋ）等で構成されたネットワークである、
【００３９】
続いて、本実施例の動作について、図面を参照して、説明する。図４は、本実施例の動作の一例を表したフローチャートである。以下、図４及び図４に示された各処理を表した詳細図（図５から図１２）を適宜参照して説明する。
【００４０】
図５は、従来の故障処理票の起票に代えて、故障管理サーバに対する端末３０からの故障情報１０１の新規登録処理と、故障管理サーバ１０の電子メール送信手段１３０により行われる電子メールの転送処理を説明するための図である。
【００４１】
まず、故障が発生した場合、その担当者は、端末３０から、故障管理サーバ１０にアクセスして、故障管理データベース１１０に、故障の原因となった故障モジュールのモジュール名を含んだ故障情報１０１を登録する（図４のステップＳ１）。なお、この時点においては、修正対象ソース名や該故障モジュールの修正完了予定日や該故障箇所が存在する対象（バージョン／システム）は、不明であるため、登録されてない。
【００４２】
前記故障情報１０１の登録処理がなされると、故障管理サーバ１０は、前記故障情報１０１に含まれる故障モジュール名と、担当情報１０２とを照合して、該故障モジュールの開発・保守部門の端末の電子メールアドレスを特定し、特定された開発・保守部門の電子メールアドレスに対して、メールサーバ４０を介して、前記故障情報１０１の内容を含んだ電子メールを送信する（図４のステップＳ２）。該電子メールは、予め定められたテンプレートに、故障情報１０１に含まれる各項目を転写することによって生成されている。
【００４３】
図６は、前記電子メールに対する開発・保守部門からの回答入力処理（故障情報更新処理）と、前記回答内容に基いて故障管理サーバ１０がファイル統合情報１０４を生成する処理と、テスト管理サーバ２０がファイル統合情報１０４に応じた、テストの対象とすべきテストモジュールを判定してテストモジュールリスト２０３を更新する処理と、を説明するための図である。
【００４４】
まず、前記ステップＳ２において、故障情報が含まれた電子メールを受け取った担当者により、故障管理サーバ１０へのアクセスが行われ、前記電子メールに対する回答として、修正対象ソース名と、該ソースの修正完了予定日と、該故障箇所が存在する対象（バージョン／システム）情報と、の入力がなされて、故障情報１０１が更新される（図４のステップＳ３）。
【００４５】
前記故障情報１０１の更新がなされると、故障管理サーバ１０は、ファイル統合情報生成手段１４０を起動して、前記更新された故障情報１０１に含まれる、修正対象ソース名と、該ソースの修正完了予定日と、該故障箇所が存在する対象（バージョン／システム）情報と、自装置側で記憶保持するソーステーブル１０３と、に基いて、テスト管理サーバ２０に渡すべきファイル統合情報１０４を生成し、ファイル統合情報データベース１２０に格納する（図４のステップＳ４）。
【００４６】
図７は、ファイル統合情報生成手段１４０において行われる、該修正対象ソースからモジュールのファイル統合を要する対象（バージョン／システム）を判定するアルゴリズムの一例を示すフローチャートである。図７を参照すると、まず、ファイル統合情報生成手段１４０は、前記更新された故障情報１０１に含まれる修正対象ソース名とソーステーブル１０３とを参照して、修正対象ソース名より生成されるモジュール名を取得する（ステップＳ４−１）。続いて、ファイル統合情報生成手段１４０は、該故障箇所が存在する対象（バージョン／システム）情報に基いて、修正対象ソースにより生成されるモジュール・ファイルのファイル統合が必要な作業対象（バージョン／システム）を判定する（ステップＳ４−２、Ｓ４−３）。上記処理を、対象となるシステムのすべてのバージョンについて、繰り返し実行する。
【００４７】
上記処理により生成されるファイル統合情報１０４は、修正対象ソース名と、該ソースから生成される修正モジュール名と、該修正モジュールの修正完了予定日と、作業対象情報（バージョン／システム）と、が関連付けられたものとなっており、修正モジュール及び修正モジュールが存在する作業対象情報（バージョン／システム）が把握できるものとなっている。後述するように本実施例では、ファイル統合情報１０４が生成されることにより、テスト管理サーバ２０において、テスト対象のモジュールの判定並びにテスト計画の更新が実行可能となる。
【００４８】
このようにして、ファイル統合情報１０４が、新たに登録されると、ファイル統合情報１０４を監視するテスト管理サーバ２０のテストモジュール判定手段２２０は、故障管理サーバ１０に対して、ファイル統合情報１０４を要求して受信し、ファイル統合情報１０４と、テストモジュールデータベース２１０に記憶保持されているモジュール階層構造情報２０１に基いて、テストが必要な最上位のモジュールを判定し、テストモジュールリスト２０３に追加する処理を開始する（図４のステップＳ５）。
【００４９】
図８は、ファイル統合情報１０４に含まれるモジュール名からテストが必要な最上位のモジュールを判定するアルゴリズムの一例を示すフローチャートである。図８を参照すると、まず、テストモジュール判定手段２２０は、モジュール階層構造情報２０１を参照して、ファイル統合情報１０４に含まれる修正モジュール名に対応するモジュールの上位モジュール名を取得する（ステップＳ５−１）。ここで、上位モジュールが存在する場合には、順次、さらに上位のモジュール名を取得する処理を繰り返し（ステップＳ５−２）、上位のモジュールが存在しなくなった時点で、該モジュールをテストの対象とするテストモジュールに決定する（ステップＳ５−３）。なお、モジュールの階層構成上、上位モジュール候補が複数存在する場合が発生し得る。この場合は、故障モジュールを選択するようにし、上位モジュール候補に故障モジュールが存在しない場合は、最初の上位モジュール候補を選択する等の選択則を予め定めることで、解決される。
【００５０】
続いて、テスト管理サーバ２０は、テスト計画更新手段２３０を起動して、前記最上位モジュールの判定処理の結果が反映されたテストモジュールリスト２０３に基いて、テスト計画（テストシナリオリスト）の更新処理を開始する。図９は、テスト計画（テストシナリオリスト）の更新の際に行われるテストシナリオの選定処理を説明するための図である。図９を参照すると、テスト計画更新手段２３０は、テストモジュールリスト２０３と、テストシナリオ群２０２とを参照して、テストモジュールリスト２０３に含まれるすべてのモジュールのテスト予定日が、対応する修正完了予定日以降となるよう、前記テストシナリオを選定するとともに前記テスト予定日を設定して、前記テスト計画（テストシナリオリスト）２０４を更新する処理を行う（図４のステップＳ６）。
【００５１】
図１０は、テストシナリオ選定のアルゴリズムの一例を示すフローチャートである。図１０を参照すると、まず、テスト計画更新手段２３０は、テストモジュールリスト２０３から追加がなされたテストモジュールのデータ（図３参照）を取得する（ステップＳ６−１）。そして、既存のテスト計画（テストシナリオリスト）２０４に含まれるテストシナリオのいずれかに、該テスト対象のモジュールが存在し、かつ、該テストシナリオのテスト予定日が、該テスト対象のモジュールの修正完了予定日以降である場合には、該テストモジュールを該テストシナリオに組み込む処理を行い終了する（ステップＳ６−２）。一方、上記条件を満たさない場合には、テストシナリオ群２０２から該テスト対象のモジュールが含まれるテストシナリオを抽出し表示して、操作者の選択を誘引する（ステップＳ６−３）。前記表示がなされたテストシナリオに基いて、操作者がテストシナリオの選択を行うと、テスト計画更新手段２３０は、該テストシナリオをテスト計画（テストシナリオリスト）２０４に追加し（ステップＳ６−４）、そのテスト予定日としてテストモジュールリスト２０３より得られる修正完了予定日を設定して、終了する（ステップＳ６−５）。
【００５２】
このようにして更新されるテスト計画（テストシナリオリスト）２０４は、最も少ないテスト回数で、テストが必要なすべてのテスト対象のモジュールのテストを行い得るものとなっている。その理由は、修正モジュールそのものでなく、修正モジュールの最上位にあるモジュールを判定し、可能な限り既存のテストシナリオにおいてテストを完了できるよう構成したことにある。
【００５３】
また、併せて、テスト計画（テストシナリオリスト）２０４は、修正が完了したモジュールのテストを滞ることなく実行できるものとなっている。その理由は、テスト計画（テストシナリオリスト）２０４にテストシナリオを新たに加える場合であっても（ステップＳ６−３以降）、そのテスト予定日が前記修正完了予定日の同日以降とする条件下で、可能な限り滞留をなくすよう、テスト予定日を該モジュールの修正完了予定日と同日に設定したことにある（ステップＳ６−５参照）。
【００５４】
なお、ファイル統合情報１０４の作業対象情報（バージョン／システム）に、複数の作業対象（バージョン／システム）が存在する場合には、テスト管理サーバ２０において上記ステップＳ５からＳ６とを繰り返すことで、展開を行うべき作業対象（バージョン／システム）毎のテスト計画（テストシナリオリスト）を得ることができる。
【００５５】
続いて、テスト管理サーバ２０は、作業優先度リスト更新・提供手段２４０を起動して、好ましい修正モジュールの修正作業の順序を指示すべく、作業優先度リスト２０５を生成し、開発・保守部門の端末３０からの要求がなされた場合には、作業優先度リスト２０５を送信する（ステップＳ７）。
【００５６】
図１１は、作業優先度リストの作成処理と、作業優先度リストが開発・保守部門から参照される処理と、を説明するための図である。図１１を参照すると、まず、作業優先度リスト更新・提供手段２４０は、テスト計画（テストシナリオリスト）２０４を参照して、作業優先度リスト２０５を更新し、開発・保守部門の端末３０から、作業優先度リスト２０５の送信要求がなされた場合に、作業優先度リスト２０５を送信するものとなっている。
【００５７】
図１２は、作業優先度決定のアルゴリズムの一例を示すフローチャートである。図１２を参照すると、まず、作業優先度リスト更新・提供手段２４０は、テスト計画（テストシナリオリスト）２０４からテスト予定日の早い順にテストシナリオのデータを取得し（ステップＳ７−１）、続いて、テストの実行順に該テストシナリオに含まれるテスト対象のモジュール名を取得する（ステップＳ７−２）。続いて、作業優先度リスト更新・提供手段２４０は、テストモジュールリスト２０３より、前記テスト対象のモジュールに対応する修正対象ソース名をすべて取得し（ステップＳ７−３）、前記各修正対象ソース名を作業優先度リスト２０５に追加する（ステップＳ７−４）。上記ステップＳ７−２からＳ７−４の各処理を、該テストシナリオに存在するすべてのテスト対象のモジュールについて行い、さらに、テスト計画（テストシナリオリスト）２０４に含まれるすべてのテストシナリオについて、上記ステップＳ７−１からＳ７−４の各処理を、繰り返し実行する。
【００５８】
このように更新される作業優先度リスト２０５は、開発・保守部門の端末３０からの要求に応じて、端末３０に対して送信される（図１１参照）。そして、作業優先度リスト２０５は、また、テスト予定日の順に整列されているため、上位に存在する修正ソース名ほど、より優先度の高いものとなっており、開発・保守部門の担当者は、より上位にあるソースの修正作業を優先して行うことで、効率的に修正作業を行うことが可能となる。
【００５９】
また、テスト計画（テストシナリオリスト）２０４が、複数の作業対象（バージョン／システム）毎に作成されている場合には、上記したステップＳ７−１における読み込むべきテスト計画（テストシナリオリスト）を変更することで、作業対象（バージョン／システム）毎の作業優先度リスト２０５を得ることができる。
【００６０】
以上、本発明の実施の形態並びに実施例を、図面を参照して、説明したが、上記各実施の形態並びに実施例として記載した事項及び図面の内容は、本発明の技術的範囲を限定するものではなく、特許請求の範囲の記載の範囲内で、当業者であれば、なし得るであろう各種変形、修正を含むことはもちろんである。例えば、上記した実施例では、故障情報の転送手段として、メールサーバ４０を用いた例を説明したが、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）等、その他の情報転送プロトコルに対応するサーバを用いて転送させても同様の効果が奏される。また、上記した実施例における故障管理サーバ並びにテスト管理サーバにより提供・出力される各種情報・リストの類の構成や、例示したアルゴリズムは、各サーバ及び本システム全体の仕様等に応じて変更されるべき事項であって、実施例に示した例に限定されるものではない。
【００６１】
【効果の説明】
本発明によれば、故障モジュールの修正からテストまでの時間的、作業的な冗長性を大きく減少させることができる。その理由は、滞留時間、冗長度の少ないテスト計画（テストシナリオリスト）の生成を可能とする構成を採用したこと、故障発生の際の故障管理部門の各作業を極力自動化したことにある。
【図面の簡単な説明】
【図１】本発明の一実施例の全体構成を表した図である。
【図２】故障管理サーバと、テスト管理サーバの構成の一例を示したブロック図である。
【図３】テストモジュールデータベースに記憶保持される情報の構成を表した図である。
【図４】本発明の一実施例の動作を表したフローチャートである。
【図５】故障が発生した場合に、開発・保守部門に電子メールが自動配信される処理を説明するための図である。
【図６】開発・保守部門からの回答処理（故障情報更新処理）と、前記回答内容に基いたファイル統合情報の生成処理と、ファイル統合情報に応じたテストモジュールリストの生成処理と、を説明するための図である。
【図７】モジュールのファイル統合が必要な作業対象（バージョン／システム）を判定するアルゴリズムの一例を示すフローチャートである。
【図８】テスト対象とする、最上位のモジュールを判定するアルゴリズムの一例を示すフローチャートである。
【図９】テスト計画（テストシナリオリスト）を更新する処理を説明するための図である。
【図１０】テストシナリオ選定のアルゴリズムの一例を示すフローチャートである。
【図１１】作業優先度リストの作成処理と、作業優先度リストが開発・保守部門から参照される処理と、を説明するための図である。
【図１２】作業優先度決定のアルゴリズムの一例を示すフローチャートである。
【符号の説明】
１０ 故障管理サーバ
２０ テスト管理サーバ
３０ 端末
４０ メールサーバ
５０ ネットワーク
１０１ 故障情報
１０２ 担当情報
１０３ ソーステーブル
１０４ ファイル統合情報
１１０ 故障管理データベース
１２０ ファイル統合情報データベース
１３０ 電子メール送信手段
１４０ ファイル統合情報生成手段
２０１ モジュール階層構造情報
２０２ テストシナリオ群
２０３ テストモジュールリスト
２０４ テスト計画（テストシナリオリスト）
２０５ 作業優先度リスト
２１０ テストモジュールデータベース
２２０ テストモジュール判定手段
２３０ テスト計画更新手段
２４０ 作業優先度リスト更新・提供手段
Claims (4)
- ソースと該ソースから生成されるモジュールとを関連付けてなるソーステーブルと、モジュールと該モジュールの修正作業を行う部門の端末アドレスとを関連付けてなる担当情報と、を記憶保持し、モジュールのテスト作業を行う部門の端末に対して、少なくとも修正対象となるモジュールと、該モジュールのファイル統合を要する対象システムと、を関連付けてなるファイル統合情報を提供する故障管理サーバであって、
故障の原因となったモジュールとその不具合内容とを含んだ故障情報の登録を受け付ける故障管理データベースと、
前記故障管理データベースに新規の故障情報が登録された場合に、前記担当情報を参照して、前記故障の原因となったモジュールの修正作業を行う部門の端末に対して、前記新規に登録された故障情報を送信する手段と、
前記故障情報及び前記ソーステーブルを参照して、前記送信した前記故障情報の回答として前記モジュールの修正作業を行う部門の端末より前記故障管理データベースに登録された修正対象となるソースに対応する修正対象となるモジュールを割り出すとともに、前記故障情報に基づき前記モジュールの修正作業を行う部門の端末より前記故障管理データベースに登録された前記故障箇所が存在する対象システムに基づいて、ファイル統合を要する対象システムを判定して、前記ファイル統合情報を生成する手段と、を備えたこと、
を特徴とする故障管理サーバ。 - 前記ファイル統合情報を生成する手段は、前記故障情報に基づき前記モジュールの修正作業を行う部門の端末より前記故障管理データベースに登録された前記故障箇所が存在する対象システムのバージョン情報を用いてバージョン毎に前記ファイル統合情報を生成すること、
を特徴とする請求項１に記載の故障管理サーバ。 - ソースと該ソースから生成されるモジュールとを関連付けてなるソーステーブルと、モジュールと該モジュールの修正作業を行う部門の端末アドレスとを関連付けてなる担当情報と、を記憶保持し、モジュールのテスト作業を行う部門の端末に対して、少なくとも修正対象となるモジュールと、該モジュールのファイル統合を要する対象システムと、を関連付けてなるファイル統合情報を提供する故障管理サーバを構成するコンピュータに実行させるプログラムであって、
故障管理データベースに、故障の原因となったモジュールとその不具合内容とを含んだ故障情報が登録された場合に、前記担当情報を参照して、前記故障の原因となったモジュールの修正作業を行う部門の端末に対して、前記新規に登録された故障情報を送信する処理と、
前記故障情報及び前記ソーステーブルを参照して、前記送信した前記故障情報の回答として前記モジュールの修正作業を行う部門の端末より前記故障管理データベースに登録された修正対象となるソースに対応する修正対象となるモジュールを割り出すとともに、前記故障情報に基づき前記モジュールの修正作業を行う部門の端末より前記故障管理データベースに登録された前記故障箇所が存在する対象システムに基づいて、ファイル統合を要する対象システムを判定して、前記ファイル統合情報を生成する処理との、
前記各処理を前記コンピュータに実行させるプログラム。 - 前記ファイル統合情報は、前記故障情報に基づき前記モジュールの修正作業を行う部門の端末より前記故障管理データベースに登録された前記故障箇所が存在する対象システムのバージョン情報を用いてバージョン毎に生成されること、
を特徴とする請求項３に記載のプログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002135348A JP4002466B2 (ja) | 2002-05-10 | 2002-05-10 | 故障管理サーバ、故障モジュールの発生に伴うテスト作業支援システム並びにプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002135348A JP4002466B2 (ja) | 2002-05-10 | 2002-05-10 | 故障管理サーバ、故障モジュールの発生に伴うテスト作業支援システム並びにプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003330709A JP2003330709A (ja) | 2003-11-21 |
| JP4002466B2 true JP4002466B2 (ja) | 2007-10-31 |
Family
ID=29697697
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002135348A Expired - Fee Related JP4002466B2 (ja) | 2002-05-10 | 2002-05-10 | 故障管理サーバ、故障モジュールの発生に伴うテスト作業支援システム並びにプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4002466B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5093990B2 (ja) * | 2005-03-28 | 2012-12-12 | Ｎｅｃエンジニアリング株式会社 | バグ管理システム |
| JP2006309316A (ja) * | 2005-04-26 | 2006-11-09 | Fujitsu Ltd | バグ管理サーバ、バグ追跡方法、およびバグ追跡プログラム |
| JP5086555B2 (ja) * | 2006-03-29 | 2012-11-28 | 株式会社Ｊｓｏｌ | 開発管理システムおよび開発管理プログラム |
| JP5893595B2 (ja) * | 2013-09-10 | 2016-03-23 | 中国電力株式会社 | スケジュール支援システム |
-
2002
- 2002-05-10 JP JP2002135348A patent/JP4002466B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003330709A (ja) | 2003-11-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7707259B2 (en) | Workflow systems and methods for project management and information management | |
| US6279042B1 (en) | Methods of performing an interdependent task on a document | |
| US11698802B2 (en) | Customer service management | |
| CN110706800A (zh) | 设备维修自动管理方法、装置、计算机设备及存储介质 | |
| JP4002466B2 (ja) | 故障管理サーバ、故障モジュールの発生に伴うテスト作業支援システム並びにプログラム | |
| CN107688489A (zh) | 一种调度任务的方法和系统 | |
| JP2006277685A (ja) | 障害発生通知プログラム、および通知装置。 | |
| JP4291244B2 (ja) | 障害情報事前通知プログラム、及び障害情報事前通知処理装置 | |
| CN111756748B (zh) | 一种数据交互方法、装置、电子设备和存储介质 | |
| JP2007133545A (ja) | 運用管理プログラムおよび運用管理方法 | |
| GB2330497A (en) | Destination inconsistency in store and forward conferencing system | |
| JPH11250127A (ja) | システム開発における工程管理の自動化方法 | |
| CN117112319A (zh) | 一种基于分支机构灾备系统的任务调度方法及装置 | |
| JP4223505B2 (ja) | メールサーバ移行支援プログラムおよびメールサーバ移行支援装置 | |
| CN116962433A (zh) | 数据同步方法、装置、电子设备及存储介质 | |
| JP2023080834A (ja) | 情報処理装置、情報処理方法、及びプログラム | |
| JP2000003270A (ja) | バージョン管理装置及び出荷管理装置 | |
| JP2022049290A (ja) | 保守支援システム | |
| CN117033406A (zh) | 一种数据库结构比对修正方法、系统及设备 | |
| JP2005301923A (ja) | 不具合通知プログラムおよび不具合管理プログラム | |
| JP5048541B2 (ja) | ワークフロー処理装置 | |
| JPH04172502A (ja) | プログラマブルコントローラにおけるネットワーク間通信方式 | |
| CN117911102A (zh) | 基于交易链路完整性的交易处理方法和装置 | |
| JP2006127354A (ja) | ワークフロー管理方法およびシステム | |
| JPH11282664A (ja) | 非互換プログラム修正システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040419 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20061020 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061114 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070115 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070206 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070409 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070508 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070709 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070807 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070817 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100824 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4002466 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110824 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110824 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120824 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130824 Year of fee payment: 6 |
|
| S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| LAPS | Cancellation because of no payment of annual fees |