JP4703811B2 - サーバ装置、障害管理システム、情報処理方法及び記録媒体 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、サーバ装置、障害管理システム、情報処理方法及び記録媒体に関する。
【０００２】
【従来の技術】
システム開発におけるソフトウェアの障害管理において、プログラム上のバグ（障害）を発見してそのデバッグを行ったり、ドキュメント上の間違いを修正したりしていく際などに、作業の効率化や適切化を図るためには、そのデバッグ等に必要な情報の管理や作業の管理等を行うことが必要である。そのために障害管理システムには、これらの情報管理や作業管理等の機能を組み込むことが要求される。
【０００３】
すなわち、障害管理システムは、開発中あるいは開発済のプログラムをコンパイルし、得られるエラー情報を単に蓄積して参照できるようにするだけでなく、それに対する障害対策の管理情報も保有し、適切に対策がとられているかについても監視し管理する機能や、ドキュメントをレビューした結果得られる指摘事項を管理する機能等を持たせる必要がある。従来の障害管理システムにおいては、オフィスの業務に関連する情報を各部門間で共有してその情報の流れを管理する所謂ワークフローシステムを利用して、上述の機能を実現していた。
【０００４】
例えば、クライアント・サーバシステムに上述のワークフロープログラムを組み込み、エラー情報の管理とその対策の管理とを行うものがある。その場合、作成されたソフトウェアについて発見した障害に関する情報をクライアント側で登録すると、そのことがサーバ側に伝えられ、それに対する障害対策がサーバ側においてワークフローの形式で管理される。そして、そのワークフローに従って、ソフトウェアの開発部門に対策指示が出され、これに応じて対策が完了するとその旨が承認部門に伝えられる。ここで、その対策が承認されると、対策結果がクライアント側に通知される。
【０００５】
このようなクライアント・サーバシステム内において、ワークフローシステムは、ソフトウェアの障害情報管理や対策作業管理を適切に行うことができるものである。そのワークフローシステムのプログラムは、通常は、サーバ側に組み込まれるだけでなく、クライアント側にもそのプログラムの一部が組み込まれ、システム全体として機能することになる。
【０００６】
【発明が解決しようとする課題】
しかしながら、このようなクライアント・サーバシステム上で実現された従来の障害管理システムでは、障害情報の流れや適切な対策作業等をあらかじめ想定してワークフローのプログラムを組んでいる。そのため、今までとは異なるルートで一連の障害対策を行うとか、プロジェクト毎にカスタマイズされるソフトウェアについては別のルートで障害対策を行うようにするなど、障害管理のワークフローの変更等をしようとすると、そのワークフローのプログラム自体を更新しなければならなくなる。
【０００７】
その際、従来の障害管理システムは、サーバ側のワークフロープログラムとクライアント側のワークフロープログラムとが一体となって機能するシステムであったので、ワークフローのプログラムの更新は、サーバ側だけでなく、個々のクライアントについても全て行わなければならない。そのため、その更新作業や管理が非常に煩雑であり、多くの労力と時間とを要するという問題があった。
【０００８】
また、ＷＡＮ（Wide Area Network ）等のような大きなネットワークを介して障害管理システムが構築される場合には、異なるプロトコルのシステムを相互接続するための所謂ゲートウェイ装置を設けなければならないが、このゲートウェイ装置のプログラムもワークフローに合わせて更新し、クライアントとサーバ間の整合性を調整しなければならないという問題があった。
【０００９】
また、障害管理のワークフロー自体を変更しなくても、ワークフローで定義されている、クライアント側で作業に当たるユーザの役割を変更したいというような場合も生じる。この場合は、それに関連するクライアント側のプログラムを修正・追加するなどの管理が必要となるが、この作業も非常に煩雑であり、多くの労力と時間とを要するという問題があった。
【００１０】
さらに、従来の障害管理システムでは、クライアント側にもワークフローのプログラムを持たせないといけないので、その分クライアント側のメモリを使用することになる。そのため、クライアント側のシステムリソースを多く使用し、使用可能なメモリ領域を圧迫してしまう。このようにシステムリソースを多く使用すると、クライアント側において障害管理システム以外のアプリケーションを起動することができなくなったり、起動できてもうまく動作しなくなってしまうことがあり、ユーザの通常の業務の妨げになってしまうことがあるという問題があった。
【００１１】
また、従来の障害管理システムは、グループウェアなどのワークフロープログラムで実現されており、当該グループウェアのプログラムをインストールしたクライアントにのみ使用が許可されていた。ところが、最近では、ソフトウェアの開発を複数の組織間や複数のプロジェクト間、あるいは複数の会社間などで分散して行うことが多くなってきており、１つのワークフローシステム内に外部から参加する要求が多く生じてきている。
【００１２】
したがって、特定のクライアントに対してのみワークフローへの参加を許可する従来の障害管理システムの仕組みは、現状に合わないものとなっている。この場合に、あらかじめ決められたクライアント以外のユーザが新たにワークフローに参加するためには、そのクライアントにグループウェアのワークフロープログラムをインストールして必要な設定を行う必要があり、その作業に非常に多くの労力と時間とを要するという問題があった。
【００１３】
本発明は、このような問題を解決するために成されたものであり、クライアントサーバ・システムによって実現される障害管理システムを簡易に構成し、障害管理に関するソフトウェアの変更等のメンテナンスを容易に行えるようにすることを第１の目的とする。
また、本発明は、クライアント側でのシステムリソースの使用を節約できるようにして、クライアント側における使用資源の負担を軽減できるようにすることを第２の目的とする。
【００１４】
また、本発明は、上記第１、第２の目的に合わせて障害管理の作業の効率性を向上させることを第３の目的とする。
さらに、本発明は、ソフトウェアの分散開発を行う場合に、必要なクライアントユーザが障害管理のワークフローに容易に参加できるようにするとともに、その際に重要な問題となるセキュリティを向上させることができるようにすることを第４の目的とする。
【００１５】
【課題を解決するための手段】
そこで、本発明のサーバ装置は、障害登録フォームに障害に関する情報が入力されることによって作成された障害レポートの通知を、ネットワークを介して通信可能なクライアント装置より受け取る送受信手段と、前記送受信手段で受け取られた前記通知に含まれるユーザ情報と、記憶装置に記憶されている障害管理のワークフローモデルの定義情報で定義されているユーザの役割定義情報と、に基づいて、有効なユーザからの障害レポートの通知か否かを判定する判定手段と、前記判定手段で有効なユーザからの障害レポートの通知であると判定された場合、前記障害レポートを記憶装置に登録し、前記障害管理のワークフローモデルの定義情報で定義されているワークフローモデルを構成する各状態間で障害管理の業務に関連する情報をどのように流していくかを表した遷移定義情報に基づいて、ワークフローの状態を遷移させ、前記ワークフローモデルの定義情報で定義されている前記各状態におけるユーザの役割の各々に応じて異なったどのような手順で障害に対する対策をとっていくかを表した手順情報に基づいて、遷移後の状態における該当するユーザの役割に応じた対策に関する指示を該当するクライアント装置に対して通知させるよう制御するワークフロー状態遷移処理手段と、を有することを特徴とする。
【００１６】
また、本発明は、障害管理システム、情報処理方法及び記録媒体としてもよい。
【００３９】
【発明の実施の形態】
以下、本発明の一実施形態を図面に基づいて説明する。
（第１の実施形態）
図１および図２は、本実施形態による障害管理システムの構成例を示すブロック図であり、図１はシステム内の詳細な機能構成を示し、図２はシステム全体の概略的な構成を示している。
【００４０】
図２に示すように、本実施形態の障害管理システムは、複数のクライアントマシン（以下、クライアントと略す）１０，１０，…と、サーバマシン（以下、サーバと略す）２０とがネットワーク４０を介して接続されたクライアント・サーバシステムとして構成される。さらに、サーバ２０には、障害管理システムを管理する管理者用の端末３０が接続される。また、このサーバ２０は、後述するワークフローの遷移状態に関する情報を含む障害管理業務データを格納するためのデータベース２１を備える。なお、このデータベース２１は、ファイルベースのものであっても良い。例えば、テキストファイルで、単に１つあるいは複数のファイルとして保存されたものである。
【００４１】
上記クライアント１０は、図１に示すように、メール送信部１１、メール受信部１２、メール返信部１３、ファイル添付部１４などの機能を有する通常のメールソフトを備えたユーザ端末である。このクライアント１０は、アプリケーションソフトウェアの開発部門およびその使用部門などに属する各種ユーザによって使用される。
【００４２】
以下に述べる説明によって順次明らかにするが、本実施形態のクライアント１０は、ソフトウェアの障害管理を行うに当たり、上述のような汎用的なメールベースのプログラムを備えていれば良く、障害管理のためのワークフロープログラムは何ら備えていなくても良い。一方、サーバ２０は、クライアント１０にメールを送信したり、クライアント１０からメールを受けてそれに応じた処理を行うメールプログラムと、障害管理のためのワークフロープログラムとを備える。すなわち、本実施形態において障害管理のためのワークフロープログラムは、サーバ２０のみが備えている。
【００４３】
管理者用端末３０には、入力フォーム定義部３１と、ワークフロー定義部３２とが備えられる。入力フォーム定義部３１は、ソフトウェアの障害管理を実行する際にユーザがメールで提出するレポートの入力フォーム（障害登録フォームや障害対策報告フォームなどの各種フォーム）を数種類定義するものである。ここでは、障害が起こったときにそれに対応して行われる各作業の段階（ワークフローの遷移状態）毎に、メールとして送るレポート中に入力すべき必要な項目を列挙したテンプレートを定義する。
【００４４】
また、ワークフロー定義部３２は、アプリケーションの開発部門や使用部門等の間で障害管理の業務に関連する情報をどのように流して、どのような手順で障害に対する対策をとっていくかを表したワークフローを定義するものである。さらに、各クライアント１０を使用するユーザの役割（障害に対する対策をとる担当者、部門内の複数担当者を統括する管理者など）を定義したり、メールの通知範囲を各入力フォーム毎に定義したりする処理もここで行う。
【００４５】
図３は、上記入力フォーム定義部３１およびワークフロー定義部３２により入力フォームやワークフローモデルを定義する際の手順を示すフローチャートである。図３において、まずステップＳ１で、障害管理システムに参加するユーザとしてどの部門の誰がいるかとか、それらユーザの役割が何であるとか言った情報を定義する。通常は１人に対して１つの役割を定義するが、１人に対して上述の担当者や管理者など複数の役割を定義することも可能である。
【００４６】
次に、ステップＳ２で障害管理のためのワークフローを定義する。ここでは、例えばどの種類の障害登録レポートを受け取ったときにその通知をどの部門に行うべきかとか、障害対策完了のレポートを受け取ったらそのことをユーザに通知すると言った障害管理情報の流れや、あるワークフローの状態のときに、担当者あるいは管理者として次のどのような作業を行うべきかの作業手順などを定義する。
【００４７】
さらに、ステップＳ３で、入力フォーム定義部３１により各種入力フォームのテンプレートを定義した後、ステップＳ４で、各種入力フォームに基づき作成されたメールの通知範囲、すなわち、どの部門内の誰々にメールの通知を行うかを１件毎に定義する。そして、以上のようにして各種の定義が終了したら、ステップＳ５でそれらの定義内容をファイルに保存する。図１に示したように、このように定義された入力フォーム３３、ワークフローモデル３４のファイルは、サーバ２０に与えられて保存される。
【００４８】
図４は、上記図３のステップＳ３において入力フォームのテンプレートを定義する際の手順を示すフローチャートである。図４において、まずステップＳ１１で、ある入力フォームに必要な項目をリストアップする。例えば、障害登録フォームに必要な項目としては、障害名称、障害発生対象環境、症状、対策期限、重要度などの項目が挙げられる。また、障害対策報告フォームに必要な項目としては、障害名称、障害原因、対策内容、修正後プログラムの版ナンバ、修正の工数などの項目が挙げられる。
【００４９】
次に、ステップＳ１２で、上記ステップＳ１１にてリストアップした各項目へのデータの入力形式（データ型や文字数など）を決定した後、ステップＳ１３で、各項目へのデータ入力の省略可否を決定する。ここでデータ入力を省略不可能と決定した項目については、実際にメールを送る際にチェックが行われ、データが入力されていない場合にはエラーメッセージが出力されることとなる。このような必須入力項目のチェック機能は、サーバ２０側で行われる。なお、ＪＡＶＡ等を利用してクライアント１０側で行うようにしても良い。
【００５０】
次のステップＳ１４では、入力フォームが完成したかどうかを判断し、項目の定義漏れなどがあって未だ完成していない場合は、ステップＳ１１に戻って同様の処理を行う。一方、入力フォームが完成した場合は、ステップＳ１５に進み、当該入力フォームをファイルに保存する。以上のようなステップＳ１１〜Ｓ１５の処理を各種の入力フォームについて行うことにより、様々な入力フォームのファイルを生成する。
【００５１】
次に、サーバ２０内の具体的な構成について、図１をもとに説明する。上述したように、本実施形態のサーバ２０は、ワークフロー管理機能とメール管理機能とを有しており、このうち後者のメール管理機能は、メールサーバ２２により実現される。メールサーバ２２は、クライアント１０から送られてきた各種メールを受け取り、それを以下に述べるワークフロー管理手段に渡すとともに、ワークフロー管理手段により生成されたメールをクライアント１０に送信する等の処理を行う。なお、ワークフロー管理手段は、図１に示したサーバ２０内のメールサーバ２２、情報一覧処理部２８以外の機能ブロックにより構成される。
【００５２】
提出者チェック部２３は、入力フォーム３３の取得要求や障害の一覧表示要求、もしくは、ある入力フォームに基づき作成されたレポート等がクライアント１０からメールで送られてきたときに、その提出者がそのメールを送ってもいい役割を持った者かどうかをチェックする。これは、メールのヘッダ中に含まれている送信者の情報と、ワークフローモデル３４内に定義されている各ユーザの役割とを参照することによって行うことができる。
【００５３】
ワークフロー状態判定部２４は、ワークフローモデル３４の定義情報およびクライアント１０から与えられたレポート等に基づいて、障害管理のワークフローにおいて現在の状態が何であるかを、発生した障害毎に判定するものである。例えば、障害登録が行われたばかりの初期の状態、障害の原因調査中、障害への対策中、対策保留中、対策完了などの各状態のうち、現在はどの状態にあるのかを判定する。このとき、登録されている複数の障害のうち、与えられたレポートがどの障害に対するものであるかは、メールのヘッダ部に含まれている後述のＩＤによって特定する。
【００５４】
識別番号採番部２５は、障害登録が行われたばかりの初期状態の障害に対し、その障害に固有の識別番号（ＩＤ）を付与する。このとき、データベース２１に既に格納されている各種障害管理業務データ（レポート等）に割当済の識別番号を見て、最も大きい番号の次の番号を新たな障害に対するＩＤとして付与する。
【００５５】
ワークフロー状態遷移処理部２６は、障害対策の担当者や管理者によって何らかの処理が行われてその報告がメールで通知される毎に、ワークフローの状態を遷移させる処理を実行する。これは、データベース２１に格納されているワークフローの遷移状態を表す情報を読み込み、定義されているワークフローモデル３４に従って、クライアント１０からメールで送られてきたレポートの内容に応じて次の状態に変更することによって行われる。このように更新された遷移状態の情報は、与えられたレポートと共に再びデータベース２１に格納される。
【００５６】
また、このワークフロー状態遷移処理部２６は、定義されているワークフローモデル３４に従って、当該ワークフローで定められている適切なクライアント１０に対して次の業務指示を通知する処理も行う。この業務指示は、あるクライアントから与えられたレポートをそのまま他のクライアントに転送することによって次に行うべき作業を示唆するものであっても良いし、明確な作業指示を作成して送るようにしても良い。この通知は、メールサーバ２２を介してメールの形式で行われる。
【００５７】
状態遷移通知部２７は、上記ワークフロー状態遷移処理部２６によりある障害に関するワークフローの状態が遷移させられたときに、そのように状態が遷移させられたことを、通知範囲内として定義されているユーザのクライアント１０に通知するものである。この通知も、メールサーバ２２を介してメールの形式で行われる。なお、作業指示と状態遷移の通知は一緒になされても良い。
【００５８】
また、情報一覧処理部２８は、クライアント１０からメールによる要求があったときに、データベース２１に格納されている各種障害に関する情報の一覧を作成し、それをメールサーバ２２を介してクライアント１０に送信する処理を行うものである。この障害一覧の情報は、メール中に組み込んで送るようにしても良いし、メールに対する添付ファイルとして送るようにしても良い。なお、障害一覧の情報の中には、障害番号（ＩＤ）、ワークフロー中の現在の状態、障害名称等の情報が含まれる。
【００５９】
以下に、上記のように構成した本実施形態の障害管理システムの障害発生時における動作を、サーバ２０の動作を表す図５〜図７のフローチャートを参照しながら説明する。なお、図５は、サーバ２０に保存されている入力フォーム３３のテンプレートをクライアント１０が入手する際の動作を示し、図６は、入力フォーム３３に基づき作成したレポートをクライアント１０からサーバ２０にメールで提出する際の動作を示し、図７は、上記図６中に示されるメイン処理の動作を示している。
【００６０】
まず、作成されたアプリケーションをあるクライアント１０もしくは図示しないユーザ端末上で使用しているとき等に、何らかの障害（バグ）を発見したら、そのユーザは、発見した障害の報告を行う。そのとき使用する障害登録フォームをサーバ２０の入力フォーム３３の中から入手するために、障害を発見したユーザは、自分が使用するクライアント１０のメール送信部１１から当該フォームの入手要求をメールの形でサーバ２０に送信する。
【００６１】
図５のステップＳ２１で、サーバ２０内のメールサーバ２２が上記フォーム入手要求のメールを受信すると、ステップＳ２２で提出者チェック部２３は、ワークフローモデル３４を読み込む。そして、次のステップＳ２３で、上記読み込んだワークフローモデル３４内に定義されているユーザの役割定義情報と、上記受信したメールのヘッダ部に記述されているユーザ名とを参照して、障害登録フォームの要求が正しい提出者から出されているかどうか、すなわち、その提出者が障害登録を行っても良い役割を持った者かどうかを判定する。
【００６２】
正しい提出者からの要求であれば、ステップＳ２４に進み、要求されたフォームが存在するかどうかを判定する。ここで要求されている障害登録フォームは存在するので、ステップＳ２５に進み、当該障害登録フォームのテンプレートをメールサーバ２２を介して要求元のクライアント１０に送信する。この送信は、フォーム要求に対する返信メールに添付する形で行われ、それが要求元のクライアント１０内のメール受信部１２にて受信される。
【００６３】
なお、上記ステップＳ２３において、障害登録フォームの要求が正しい提出者によって成されたものではないと判定された場合、および上記ステップＳ２４において、要求されたフォームがサーバ２０内の入力フォーム３３として保存されていないと判定された場合は、ステップＳ２６に進み、メールサーバ２２を介してフォーム要求元のクライアント１０に対してエラー通知が行われる。
【００６４】
クライアント１０側で障害登録フォームを受信すると、ユーザは、そのフォーム内の各項目に必要事項を記述することによって障害レポートを作成し、それをメール送信部１１あるいはメール返信部１３からサーバ２０に送信する。このとき障害レポートは、ファイル添付部１４によりメールに添付されて送信される。図６のステップＳ３１で、サーバ２０内のメールサーバ２２が上記障害レポートのメールを受信すると、以下に述べるワークフロー処理が実行される。
【００６５】
すなわち、提出者チェック部２３は、ステップＳ３２でワークフローモデル３４を読み込み、ステップＳ３３で、その読み込んだワークフローモデル３４内に定義されているユーザの役割定義情報と、上記受信したメールのヘッダ部に記述されているユーザ名とを参照して、当該障害レポートの提出が正しい提出者によって行われているかどうかを判定する。
【００６６】
正しい提出者であれば、ステップＳ３４に進んで図７に示すメイン処理を実行する。一方、正しい提出者でない場合は、ステップＳ３５に進み、メールサーバ２２を介して障害レポートを提出したクライアント１０に対してエラー通知が行われる。
【００６７】
図７に示すメイン処理では、まずステップＳ４１で、ワークフロー状態判定部２４により、クライアント１０からメールで受信したレポートが、その障害に関して最初のレポートかどうか、すなわち、その障害についてワークフローの状態が既に進行した状態でないかどうかを判定する。ここで、ある障害に関して最初のレポートとは、発生した障害を最初に登録する際の障害レポートである。よって、受信したレポートが障害レポートか否かを見れば、現在対象としてしている障害が初期状態であるか否かは少なくとも判定することが可能である。
【００６８】
受信したレポートがその障害に関して最初のレポートであれば、ステップＳ４２で識別番号採番部２５は、データベース２１内に既に格納されている障害情報を読み込み、次のステップＳ４３で、それらの障害情報に既に割当済みの識別番号（ＩＤ）をインクリメントする形で、今回報告された新たな障害に対して固有のＩＤを付与する。今の例では、サーバ２０では障害レポートを受信しているので、ステップＳ４２、Ｓ４３においてその障害に対する採番が行われる。採番の済んだレポート情報は、データベース２１に格納される。
【００６９】
次に、ステップＳ４４に進み、ワークフロー状態遷移処理部２６は、データベース２１から現在ワークフローの処理対象としている障害の情報を読み込み、ステップＳ４５で次の状態へと遷移させる。例えば、障害レポートの登録が済んだばかりの障害の場合は、ワークフローの状態が障害発生前の初期状態から原因調査中の状態へと遷移させられる。
【００７０】
そして、ステップＳ４６で、ワークフロー状態遷移処理部２６は、ワークフローモデル３４で定められている適切なユーザ（今の例の場合は障害対策を行うべき担当者）のクライアント１０に対して、次の障害管理業務指示をメールによって通知する。その際、メールのヘッダ部にその障害に固有のＩＤを含ませるようにする。また、このステップＳ４６では、状態遷移通知部２７が、ワークフローの状態遷移に関する情報を通知範囲内として定義されたユーザのクライアント１０に通知する処理も行う。
【００７１】
図８は、障害管理業務指示として通知された障害レポートの画面表示例を示す図である。この画面表示では、１番上の行に“Ｓubject”として [障害レポート] と表示されており、その次の行から数行に渡ってメールの送信元や送信先、日付などの書誌情報が表示されている。更にその下には、障害番号（ＩＤ）と名称、提出者、レポート名、状態遷移が表示されており、どのような障害が、ワークフロー中で現在どのような状態にあるのかを一目で分かるようになっている。
【００７２】
更にその下には、提出者（障害の発見者）によって入力フォーム３３に基づき記述された障害レポートの具体的内容が表示されている。図８の画面中に墨付き括弧で示した項目は、障害登録フォームのテンプレートとして提示された項目であり、当該フォームの入手時には項目名だけが表示され、中身はブランクとなっている。図は、障害の発見者がこれらの各項目を埋めることによって障害レポートを完成させた後の状態を示している。
【００７３】
このような障害レポートのメールを受け取った担当者（システム開発者）は、その報告された障害を解消するために必要な対策を実行する。例えば、必要に応じてプログラムを修正する。何らかの対策を行ったら、そのことを対策レポートとして記述し、メールでサーバ２０に送信する。このとき担当者は、まず、障害対策報告フォームをサーバ２０の入力フォーム３３の中から入手する。そして、その入手した障害対策報告フォーム中の各項目に必要事項を記述することによって対策レポートを作成し、それをメールで送信する。このメールのヘッダ部にもＩＤが含まれている。
【００７４】
この障害対策報告フォームの入手の際も、障害登録フォームの入手の際と同様に、そのフォーム要求が正しい提出者から出されているかどうかを判定する処理を行う。また、当該フォームに基づき作成された対策レポートのメールをサーバ２０が受信した際には、そのメールのヘッダ部に書かれているＩＤを読み取り、障害レポートと対応付ける。そして、そのＩＤを頼りに、障害レポートのメールを受信した際と同様に、ワークフローの現在の状態を判定して次の状態に遷移させる処理を行う（今の例の場合、原因調査中から対策中に状態が遷移する）。
【００７５】
さらに、サーバ２０側では、当該受け取った対策レポートを次にどのユーザに送れば良いかをワークフローモデル３４に従って検出し、適切なユーザ（例えば管理者など）のクライアント１０に送信する。これを受け取ったクライアント１０のユーザは、対策レポートの報告に問題があるかどうかを判断し、問題があれば、対応差戻しの指示をメールで行う。一方、報告に問題がなければ、対策完了レポートのメールを送信して、ワークフローの状態を“対策完了”へと遷移させる。
【００７６】
なお、ここでは、障害レポートを受け取った担当者が直ちに必要な対策をとっている例を示しているが、障害の原因を再調査したり、その障害について他の担当者と意見交換をしたり、あるいは緊急を要する他の障害の発生などにより対策を一時的に保留したりすることなども考えられる。このような場合も、それらの態様に応じた入力フォームをサーバ２０からクライアント１０に入手して、必要事項を記述して作成したレポートをメールでサーバ２０に返信する。サーバ２０では、送られてきたレポートに応じてワークフローの状態を遷移させるとともに、そのレポートをワークフローに従って適切なユーザに通知する。
【００７７】
また、あるユーザのクライアント１０からサーバ２０に一覧表示の要求をメールで送ると、サーバ２０内では、まず提出者チェック部２３によって正しい提出者か否かのチェックが行われる。一覧表示の要求が正しい提出者から出されている場合には、情報一覧処理部２８に一覧作成の指示が出され、データベース２１内から各障害に関するレポート情報を取り出してきて一覧が生成される。そして、その一覧情報がメールに添付ファイルとして組み込まれ、メールサーバ２２を介してクライアント１０に送信される。
【００７８】
以上詳しく説明したように、本実施形態の障害管理システムでは、クライアント１０とサーバ２０との間では障害ＩＤ付きのメールでやり取りが行われ、障害管理のワークフロー処理は全て、上記障害ＩＤに基づいてサーバ２０内でのみ順次実行される。したがって、少なくともクライアント１０側ではワークフローのためのプログラムは持つ必要がなく、通常のメールプログラムを備えていれば良い。これにより、障害管理のワークフローを変更する場合でも、サーバ２０側のプログラムを更新するだけで、個々のクライアント１０側については何らプログラムを更新しなくても済むので、従来に比べてワークフローの更新作業や管理が非常に簡単になる。
【００７９】
また、本実施形態の障害管理システムがＷＡＮ（Wide Area Network ）等のような大きなネットワークを介して構築される場合でも、異なるプロトコルのシステムを相互接続するためのゲートウェイ装置のプログラムも修正する必要がない。さらに、クライアント側で作業に当たるユーザの役割を変更するような場合にも、クライアント１０側のプログラムは全く修正する必要がない。
以上のことから、本実施形態によれば、障害管理システムのメンテナンスにかかる労力や時間を格段に少なくすることができる。
【００８０】
上述したように、クライアント１０側では通常のメールソフトを備えていれば良いが、そのメール中には、サーバ２０側のワークフロー処理の中で各障害との対応をとるために障害固有のＩＤが付けられるとともに、メールの作成は所定の入力フォーム３３に基づいて行われるようになっている。ただし、このＩＤはサーバ２０側のワークフロー処理の流れの中で付与されるものであり、しかもメールのヘッダ部という隠れたところに書かれている。よって、クライアント１０のユーザとしては、ＩＤのことは全く意識することなく、入力フォーム３３中の決められた項目だけを記入して送りさえすれば良いので、作業がしやすいというメリットがある。
【００８１】
また、本実施形態では、クライアント１０側ではワークフローのプログラムを全く持たなくても良いので、クライアント１０側でのメモリの使用を節約することができる。これにより、従来に比べて、クライアント１０側のシステムリソースをより多く解放することができ、クライアント１０側において障害管理システム以外のアプリケーションを起動することができなくなったり、起動できてもうまく動作しなくなってしまうなどの不都合を回避することができる。
【００８２】
また、本実施形態では、任意の時点でクライアント１０から与えられる要求に応じて、各種障害に関する情報の一覧を情報一覧処理部２８にて作成し、それをメールの形でクライアント１０に送信するようにしている。この一覧表示は、データベース２１内に格納されている各障害のレポート情報から現在のワークフロー状態を見るだけのものである。つまり、実際にワークフローを動かすことなく、ワークフローを動かした結果として得られているある時点での各種障害の状態を一覧として見ることができる。
【００８３】
これによりユーザは、対象としているアプリケーションソフトウェアで現在どのような障害が発生しており、それらの障害毎にワークフローがどの状態まで進んでいるのかを一覧として見ることができ、作成中あるいは作成済のアプリケーションのメンテンナンス作業を行う際の有効な参考とすることができる。
【００８４】
（第２の実施形態）
次に、本発明の第２の実施形態を説明する。上記第１の実施形態では、各種障害に関する情報の一覧表示を行う際にも、クライアント１０とサーバ２０との間の通信をメールベースで行っていた。これに対して第２の実施形態は、これをＨＴＭＬ形式のウェブベースで行うものである。
【００８５】
図９は、第２の実施形態による障害管理システムの機能構成を示すブロック図である。第２の実施形態では、クライアント１０は、上述した通常のメールソフトの他に、通常のブラウザソフトを有し、その中の１つの機能として情報一覧表示部１５を備えている。
【００８６】
一方、サーバ２０内の情報一覧処理部２９は、クライアント１０からメールによる要求があったときに、データベース２１に格納されている各種障害に関する情報の一覧をウェブベースで作成し、それをクライアント１０内の情報一覧表示部１５に送信する。この情報一覧処理部２９はまた、データベース２１に格納されている障害管理業務データを用いて、対応中の障害に関して現在の状態から次に行える作業の一覧情報を作成してクライアント１０に送信する処理も行う。
【００８７】
なお、図９中に示したその他の機能ブロックは図１に示したものと同じ機能を有するものであり、それらは両図で同一の符号を付している。
【００８８】
図１０は、情報一覧表示部１５に表示された障害一覧を画面表示例を示す図である。図１０に示すように、画面の一番上のフレーム内には、現在対応中の障害の一覧が表示されている。この障害一覧の情報の中には、障害番号（ＩＤ）、最終更新日、ワークフロー中の現在の状態、障害名称の情報が含まれる。障害番号の下にはアンカー（下線）が引かれており、ここをマウスでクリックすると、その障害に関する現在のワークフローの状態に関する詳細な情報が下のフレームに表示される。
【００８９】
この図１０の例では、障害番号が１５番のところをクリックした場合の表示例を示している。このワークフローの状態を示すフレーム内には、その障害に関してこれまでどのような作業がいつ誰によって行われてきたかの履歴情報と、どういった役割のユーザが現在の状態から次にどのようなレポートを提出できるか、つまり次にどのような作業を行うことができるかの作業一覧情報とが示されている。本実施形態では、１人に複数の役割を持たせることができるので、管理者の立場として次に行える作業と、担当者として次に行える作業とが提示される。
【００９０】
例えば、管理者としては、“対策中”の状態から対策完了レポートを提出すれば“対策完了”という状態に遷移させることができる。また、担当者としては、“対策中”の状態から対策レポートや意見レポートを提出して“対策中”の状態を維持したり、対策保留レポートを提出して“対策保留中”の状態に遷移させたり、あるいは再調査レポートを提出して“原因調査中”の状態に遷移させたりすることができる。
【００９１】
図１に示した第１の実施形態では、ある役割のユーザがあるレポートを作成してメールでサーバ２０に送ったときに、提出者チェック部２３で提出者のチェックが行われて正しい提出者でない場合にはエラーが出力されるという程度のものであった。これに対して、本実施形態によれば、ワークフローの現在の状態と、一覧表示のアクセスをしているユーザの役割とを参照して次にどんな作業を行えるかという示唆をあらかじめ表示することができる。よって、障害対策の一連のワークフローの中で次に行うべき作業内容をユーザがあらかじめ容易に把握することができ、作業の効率を上げることができる。
【００９２】
（第３の実施形態）
次に、本発明の第３の実施形態について説明する。上述した第１および第２の実施形態は、第２の実施形態の一覧表示を除いてクライアント１０とサーバ２０との間のやり取りは全てメールの形で行うようになされていた。これに対して、第３の実施形態では、メールの通信は一切行わず、全ての通信をウェブベースで行うものである。
【００９３】
したがって、本実施形態のクライアント１０は、第１、第２の実施形態で用いていた通常のメールソフトの代わりに、通常のブラウザソフトが稼働している。そして、このブラウザソフトは、図１１に示すように、情報一覧表示部１５、入力フォーム要求部４１、フォーム送信部４２、通知受信部４３を機能として備えている。
【００９４】
一方、サーバ２０には、第１および第２の実施形態で説明した提出者チェック部２３と識別番号採番部２５はなく、その代わりにフォーム解析部４４を備えている。また、サーバ２０内に保存される入力フォーム４５は、入力フォーム定義部３１によってウェブベースで作成されたものである。さらに、通知部４６は、ワークフローに従った次の障害管理業務指示や状態遷移の通知を、メールベースではなくウェブベースで行うものである。
【００９５】
なお、図１１において、図１および図９に示した符号と同一の符号を付したものは、同一の機能を有するものであるので、これについての詳細な説明は省略する。
【００９６】
上記入力フォーム要求部４１は、サーバ２０内に保存されている各種の入力フォーム４５の中から所望のフォームの取得を要求するためのものであり、例えば画面中に表示されたブラウザボタン等を有している。このブラウザボタンをマウスでクリックして所望のフォームを指定すると、その指定された入力フォーム４５がサーバ２０から送られる。この入力フォーム４５は、第１の実施形態のようにメールに添付して送られるのではなく、ＨＴＭＬ形式のブラウザ画面そのものとして送られる。ここでは、ＨＴＭＬ形式だけで説明するが、ＧＩＦファイルやテキストファイル等のデータも一緒に取り扱って良い。
【００９７】
フォーム送信部４２は、上述のように入手した入力フォーム４５内の各項目に必要事項を記入することによってレポートを作成し、それをＨＴＭＬ形式にてサーバ２０側に送るものである。フォーム解析部４４は、クライアント１０から送られてきたレポートのフォームを、サーバ２０内に保存されている入力フォーム４５を参照することによって解析する。そして、そのフォームがどういう種類のものかを確認する。このフォーム解析部４４はまた、レポート内に書かれた情報をもとに、そのレポートがどの障害に対するものであるかとか、どのユーザから送られてきたものであるか等についても解析する。
【００９８】
クライアント１０からレポートが与えられると、フォーム解析部４４により解析された障害に対して、ワークフロー状態判定部２４およびワークフロー状態遷移処理部２６によって第１の実施形態で述べたようなワークフロー処理が行われる。そして、そのときの状態遷移や次の障害管理業務指示が通知部４６によってＨＴＭＬ形式にて適切なクライアント１０に送られ、それが通知受信部４３で受信される。
【００９９】
また、フォーム解析部４４の解析処理により、クライアント１０から障害の一覧表示が要求されていることが判明した場合には、情報一覧処理部２９によってデータベース２１内のレポート情報から一覧が作成され、ＨＴＭＬ形式にてクライアント１０に送られる。図１２は、第３の実施形態において障害の一覧を表示させる際のサーバ２０内の動作を示すフローチャートである。
【０１００】
本実施形態では、クライアント１０側において障害の一覧表示を行いたい場合は、一覧表示要求用の入力フォームを入手してそれに必要事項を記入し、それをサーバ２０側に送ることによって実行する。また、例えば図１０に示したように、画面の一番下に常に表示されるメニュー中で“対応中の障害一覧”と表示されている部分をマウスでクリックすることによって、一覧表示の要求をサーバ２０側に送るようにしても良い。
【０１０１】
図１２のステップＳ５１で、サーバ２０が上記一覧表示要求を受信すると、ステップＳ５２で、フォーム解析部４４は、ワークフローモデル３４内に定義されているユーザの役割定義情報を参照し、解析した要求送信元のユーザが正しい提出者であるかどうかを判定する。
【０１０２】
ここで、正しい提出者からの一覧表示要求であれば、ステップＳ５３に進み、情報一覧処理部２９は、データベース２１内に既に格納されている各種の障害情報を読み込み、次のステップＳ５４で、それらの障害情報の一覧をウェブベースで作成する。そして、ステップＳ５５で、このように作成した一覧情報を要求元のクライアント１０に送信する。
【０１０３】
一方、上記ステップＳ５２において、一覧表示要求が正しい提出者によって成されたものではないと判定された場合は、ステップＳ５６に進み、一覧要求元のクライアント１０に対してエラー通知が行われる。
【０１０４】
以上のように、第３の実施形態では、障害管理のワークフロー処理を全てサーバ２０内で行っていることについては上述した第１および第２の実施形態と同様であるが、クライアント１０とサーバ２０との間のやり取りをＨＴＭＬ形式のウェブベースで行っている。したがって、入力フォームがメールの添付ファイルとしてやり取りされていた第１、第２の実施形態に比べて、レポートの作成作業や一覧の取得作業をより効率的に行うことができる。
【０１０５】
また、第２の実施形態と同様に、図１０に示したような表示画面を見ることにより、ワークフローの現在の状態から次にどんな作業を行えるかということもユーザが容易に知ることができる。さらに、この図１０の表示画面の中で、アンカーが引かれているレポート名の部分をクリックすることにより、それに対応する入力フォームをサーバ２０から自動的に取得することもできる。よって、障害対策の一連の作業の操作性をより向上させることができる。
【０１０６】
以上、第１〜第３の実施形態について詳しく述べたが、本発明はこれらの実施形態に限定されるものではない。例えば、上記各実施形態では原則的にメールベースの障害管理システムか、ウェブベースの障害管理システムかの何れかについて説明したが、両者を混在させたものであっても良い。例えば、第３の実施形態ではサーバ２０からクライアント１０への通知もウェブベースで行っているが、これをメールにより行うようにしても良い。
【０１０７】
また、障害管理の流れを例えば次のようにすることも可能である。すなわち、クライアントからサーバに障害データがメールで送られてくると、サーバにおいて所定のワークフローが起動する。そして、ワークフローモデルによって定められた適切なクライアントに障害レポートをメールで送信するとともに、その障害についてのワークフローの状態を次の状態へと遷移させる。
【０１０８】
クライアントでは、この障害レポートをメールで受信すると、それに対応して適切な対策作業を行う。そして、その作業が終了したら、クライアント側のウェブブラウザを起動して、ウェブベースにて対応作業完了報告を入力する。そして、それをサーバ側へと送信する。
【０１０９】
この対応作業完了報告を受け取ったサーバでは、その報告内容を解析して特定した障害についてのワークフローの状態を次の状態へと遷移させる。そして、そのウェブで入力された報告内容をチェックし、問題があれば、対応差戻しの指示がメールで行われる。一方、報告に問題がなければ、対策完了レポートのメールが送信される。
【０１１０】
（第４の実施形態）
次に、本発明の第４の実施形態について説明する。図１３は、本実施形態による障害管理システムの全体の概略的な構成例を示すブロック図である。
【０１１１】
図１３に示すように、本実施形態の障害管理システムは、複数のクライアント１０，１０，…とサーバ２０とが接続されたＬＡＮ（Local Area Network）等のネットワーク４０が、インターネット５０などを介して他のネットワーク６０に接続されている。そして、この他のネットワーク６０に接続されたクライアント７０，７０，…からもインターネット５０を介してサーバ２０にアクセスできるようになっている。このように、本実施形態では、複数の組織、プロジェクト、会社などでソフトウェアを分散開発する場合の障害管理について示している。
【０１１２】
また、この第４の実施形態は、クライアント１０，７０とサーバ２０間のやりとりをメールベースとウェブベースの両者を混在させて行うものである。例えば、サーバ２０からクライアント１０，７０への通知はメールベースで行い、その他の部分をウェブベースで行う。したがって、本実施形態のクライアント１０，７０は、通常のメールソフトと通常のブラウザソフトとが稼働している。
【０１１３】
図１４は、本実施形態による障害管理システムの詳細な機能構成を示す図であり、図１１に示したブロックと同じブロックには同一の符号を付して、重複する説明は省略する。なお、ここではクライアント１０の構成について示すが、クライアント７０についても同様である。
【０１１４】
図１４において、クライアント１０上で稼働するブラウザソフトは、第３の実施形態で示した情報一覧表示部１５、入力フォーム要求部４１およびフォーム送信部４２の他に、ログイン部５１を機能として備えている。また、クライアント１０上で稼働するメールソフトは、少なくとも通知受信部５２を機能として備えている。
【０１１５】
上記ログイン部５１は、クライアント１０のユーザが障害管理のワークフローシステムにログインするための処理を行うものであり、例えばユーザ名、パスワードなどのユーザ情報の入力をここで行う。このパスワードの登録は、管理者用端末３０のパスワード登録部５３により行う。すなわち、管理者用端末３０を使用する管理者は、ワークフローへの参加を希望するユーザからの要求に応じて、パスワード登録部５３を用いてそのユーザに特有のパスワードを発行する。発行されたパスワードは、ユーザ名と共にサーバ２０に与えられてパスワードファイル５４として保存されるとともに、該当するユーザに何らかの形で通知される。
【０１１６】
本実施形態の障害管理システムにおいては、複数のワークフローを定義してそれぞれを個別に稼働させることができるようにしている。そのため、入力フォーム定義部３１は、ウェブベースの入力フォーム４５をそれぞれのワークフロー毎に定義する。また、ワークフロー定義部３２も、障害管理のためのワークフローモデル３４をそれぞれのワークフロー毎に定義する。さらに、上述したパスワード登録部５３においても、ユーザのパスワードをそれぞれのワークフロー毎に発行し、登録する。
【０１１７】
この場合、サーバ２０内のワークフロー状態判定部２４、ワークフロー状態遷移処理部２６、情報一覧処理部２９、フォーム解析部４４、ユーザ認証部５５および通知部５７は、クライアント１０から送られてくる各種レポートのフォームや記載されている情報などを参照することによって、現在どのワークフローが対象とされているのかを判断し、その結果に応じて対応するワークフローに関する処理を実行する。
【０１１８】
上記ユーザ認証部５５は、クライアント１０のログイン部５１より入力されたユーザ名およびパスワードと、サーバ２０にパスワードファイル５４として保存されているユーザ名およびパスワードとを照合し、ログインしてきたユーザが障害管理のワークフローに確かに参加できる者かどうかの認証を行う。このときユーザ認証部５５は、同じユーザが全てのワークフローにログインできるとは限らず、一部のワークフローに対してのみパスワードが与えられてログインが許可されている場合もあるので、ワークフローの種類毎にユーザ認証を実行する。
【０１１９】
ＯＮ／ＯＦＦ切替部５６は、管理者用端末３０からの指示に応じて、上記ユーザ認証部５５によるユーザ認証の機能をＯＮとするかＯＦＦとするかを切り替えるものである。ユーザ認証の機能をＯＮとした場合は、所望のワークフローシステムにログインするためにはユーザ名の他にパスワードを入力する必要がある。一方、ユーザ認証の機能をＯＦＦとした場合は、所望のワークフローシステムにログインするためにパスワードの入力は不要となる。ユーザ名の入力も不要としても良い。
【０１２０】
また、通知部５７は、ワークフローに従った次の障害管理業務指示や状態遷移の通知をメールベースで行う。このとき通知部５７は、上述のような通知内容の他に、その通知内容に応じて次に起動すべきウェブページへのリンク情報（そのページのＵＲＬ（Uniform Resource Locator）そのもの、あるいはリンクメッセージなど）を記述する。通知メールを受け取ったユーザは、その中に記述されているリンク情報をクリックすることにより、指定されたリンク先のウェブページを直ちに開くことができる。
【０１２１】
なお、ここで用いるメールは、クライアント１０内のメールソフトで受信しても良いし、ウェブブラウザさえあれば送受信できるようなものを用いても良い。後者の方式であれば、ウェブブラウサさえあればメールの送受信およびウェブページの参照ができるので、メールサーバに直接アクセスする必要のあるメールソフトと異なり、どこでもアクセスすることが可能となる。あるいは、ネットスケープコミュニケーションズ社やマイクロソフト社などから提供されているようなメールを送受信する機能とブラウザの閲覧機能とが備わったソフトウェアを利用しても良い。
【０１２２】
図１５は、サーバ２０からクライアント１０に状態変更の通知メールが送られてきたときに行われるクライアント１０内の動作を示すフローチャートである。図１５のステップＳ６１で、クライアント１０が上記状態変更通知メールを受信したら、ユーザは、次のステップＳ６２で、当該通知メールの本文中に書かれたＵＲＬをクリックする。これに応じてステップＳ６３では、クライアント１０内のウェブブラウザが起動される。
【０１２３】
次に、ステップＳ６４でログイン部５１は、そのユーザのログイン状況を確認し、既にログイン済か否かをステップＳ６５で判断する。ここで、未だログインが済んでいない場合は、ステップＳ６６でユーザ認証の処理を行った後、上記ＵＲＬで指定されたウェブページを開く。一方、既にログインが済んでいる場合には、ステップＳ６６の処理を行うことなく、上記ＵＲＬで指定されたウェブページを直ちに開く。ユーザは、この開かれたウェブページに従って次の処理を行うことになる。
【０１２４】
図１６は、上記ステップＳ６６におけるユーザ認証の動作を示すフローチャートである。
図１６において、まずステップＳ７１で、クライアント１０のユーザは、ログイン部５１を用いて自己のユーザ名とパスワードを入力する。この場合、ログインしようとするワークフローに対応するユーザ名とパスワードを入力する必要がある。入力されたこれらの情報は、サーバ２０内のユーザ認証部５５に伝えられる。
【０１２５】
次に、ステップＳ７２においてユーザ認証部５５は、クライアント１０のログイン部５１から送られてきたユーザ名およびパスワードと、パスワードファイル５４にワークフロー毎に保存されているユーザ名およびパスワードとを照合し、ログインしてきたユーザがそのワークフローに確かに参加できる者かどうかをステップＳ７３で確認する。ここで、確認がとれた場合には次の処理へと進み、確認がとれない場合はステップＳ７２に戻る。
【０１２６】
図１７は、上記図１５および図１６に示した動作を画面イメージで示す図である。図１７（ａ）は、サーバ２０からクライアント１０に送られてきた状態変更の通知メールを示している。この通知メールの本文中には、障害の件名、提出者などの図８に示したような内容の他に、その通知内容に応じて次に起動すべきウェブページのＵＲＬが記述されている。このＵＲＬには、どのワークフローのどの案件のもので、現在どの状態にあるのか等の情報が含まれている。
【０１２７】
したがって、この通知メールを受け取ったユーザは、その中に記述されているＵＲＬをクリックするだけで、特に意識しなくても適切なウェブページにアクセスすることができる。このとき、そのユーザが既にログイン済の場合は、ユーザ認証の処理を行うことなく、図１７（ｃ）に示すような通知内容の詳細が記載されたウェブページが直ちに開かれる。このウェブページは、通知内容の詳細な表示だけでなく、ユーザが必要な情報を入力してサーバ２０に送るための機能も持っている。例えば、障害の報告通知に対して対策方法を記入してサーバ２０に送り、それをデータベース２１に登録するような使い方が可能である。
【０１２８】
一方、ユーザが該当するワークフローに未だログインしていない場合は、図１７（ｂ）に示すようなログイン画面が表示され、ログインを行うことが促される。これに応じてユーザは、自己のユーザ名およびパスワードを入力することになる。この画面のタイトルバーには、ＵＲＬからシステムによって判別されたワークフロー名が表示されているので、ユーザが複数のワークフローに参加している場合でも、どのユーザ名とパスワードを入力すれば良いのかが認識できる。ここで入力したユーザ名とパスワードに応じてユーザ認証が行われると、その後図１７（ｃ）に示すようなウェブページが開かれる。
【０１２９】
以上のように、第４の実施形態では、サーバ２０にユーザ認証部５５を設けたので、障害管理のためのワークフローシステムをグループウェアにより構成しなくても済み、ソフトウェアの分散開発を行うような場合に、グループウェアによってあらかじめ固定されたユーザだけが障害管理のワークフローに参加できる従来のシステムとは異なり、認証を受けたユーザであれば誰でも容易に参加することができるようになる。しかも、ユーザ認証を行うことで、登録されていないユーザの参加を拒否することができ、セキュリティを向上させることができる。
【０１３０】
また、本実施形態では、１つの障害管理システムにおいて複数のワークフローを稼働させ、それぞれのワークフロー毎に異なるパスワードを設定してユーザ認証を別々に行うようにしている。同じユーザでも、システム内で稼働している全てのワークフローに関する情報を見せるべきでなく、特定のワークフローに限って参加を認める場合もあり得るが、本実施形態によればこのような要求にも対応することができ、より質の高いセキュリティを実現することができる。
【０１３１】
また、本実施形態では、ユーザ認証の機能をＯＮにするかＯＦＦにするかを切り替えられるようにしたので、ソフトウェアの開発を比較的少ない人数によって行うような場合であって、かつ、図２のように孤立したネットワークの中で行うような場合には、ユーザ認証の機能をＯＦＦにすることによって、ログインする際にユーザ名やパスワードを入力する手間を省略することができる。このようにＯＮ／ＯＦＦ切替部５６を設けることによって、ソフトウェアの開発を複数の組織間等で分散して行う場合や、あらかじめ決められた単独の組織等の中で行う場合の双方に柔軟に対応することができる。
【０１３２】
なお、以上に説明した各実施形態の障害管理システムは、コンピュータのＣＰＵあるいはＭＰＵ、ＲＡＭ、ＲＯＭなどで構成されるものであり、ＲＡＭやＲＯＭに記憶されたプログラムが動作することによって実現できる。したがって、コンピュータが上記機能を果たすように動作させるプログラムを、例えばＣＤ−ＲＯＭのような記録媒体に記録し、コンピュータに読み込ませることによって実現できるものである。記録媒体としては、ＣＤ−ＲＯＭ以外に、フロッピーディスク、ハードディスク、磁気テープ、光磁気ディスク、不揮発性メモリカード等を用いることができる。
【０１３３】
また、コンピュータが供給されたプログラムを実行することにより上述の実施形態の機能が実現されるだけでなく、そのプログラムがコンピュータにおいて稼働しているＯＳ（オペレーティングシステム）あるいは他のアプリケーションソフト等と共同して上述の実施形態の機能が実現される場合や、供給されたプログラムの処理の全てあるいは一部がコンピュータの機能拡張ボードや機能拡張ユニットにより行われて上述の実施形態の機能が実現される場合も、かかるプログラムは本発明の実施形態に含まれる。
上述した実施形態では上述したように、クライアントに少なくともウェブあるいはメールによるデータの入出力機能を備え、サーバには、クライアントより送られてきた障害管理業務データに基づいてワークフローの処理を行うワークフロー処理手段を設けたので、障害管理のためのワークフロー処理をサーバ内のプログラムに従ってのみ行い、障害管理業務の遂行に必要なクライアントとのデータのやり取りは、単にウェブ機能あるいはメール機能を用いて行うことができる。そのため、クライアント側では、ワークフロー処理のためのプログラムを備えなくても済み、通常のウェブ機能あるいはメール機能さえ備えていれば良くなる。
これにより、障害管理のワークフローを変更したり、クライアント側で作業に当たるユーザの役割を変更したりする場合でも、サーバ側のプログラムを更新するだけで、個々のクライアントについては何らプログラムを更新しなくても済む。また、上述した実施形態の障害管理システムが大きなネットワークを介して構築される場合でも、異なるプロトコルのシステムを相互接続するための所謂ゲートウェイ装置のプログラムも修正する必要がなくなる。よって、上述した実施形態によれば、ワークフローの更新作業や管理等が非常に簡単になり、障害管理システムのメンテナンスにかかる労力や時間を格段に少なくすることができる。
また、上述した実施形態では、クライアント側ではワークフローのプログラムを全く持たなくても良いので、クライアント側でのメモリの使用を節約することができる。これにより、従来に比べて、クライアント側のシステムリソースをより多く解放することができ、クライアント側において障害管理システム以外のアプリケーションを起動することができなくなったり、起動できてもうまく動作しなくなったりしてしまうという不都合を回避することができる。
また、上述した実施形態の他の特徴によれば、発生した障害の一覧を作成し、それをクライアントに送信して表示するようにしたので、クライアントのユーザは、現在どのような障害が発生しており、それらの障害毎にワークフローがどの状態まで進んでいるのか等を一覧として見ることができ、障害管理の業務を遂行するに当たっての一助とすることができる。
また、上述した実施形態のその他の特徴によれば、対応中の障害に関し、現在の状態から次に行える作業の一覧情報を作成し、それをクライアントに送信して表示するようにしたので、障害対策の一連のワークフローの中で次に行うべき作業内容をユーザがあらかじめ容易に把握することができ、作業の効率を向上させることができる。
上述した実施形態のその他の特徴によれば、クライアント・サーバ間のデータのやり取りをメールにて行う場合、障害との対応をとるために必要なＩＤを、ユーザには直接見えることのないメールのヘッダ部に含ませたので、クライアントのユーザとしては、ＩＤのことは全く意識することなく、ただ必要なメールをやり取りするだけで障害管理の業務を遂行することができ、作業の操作性を向上させることができる。
上述した実施形態のその他の特徴によれば、クライアントから送られてくるユーザ情報とサーバ内にあらかじめ登録されたユーザ情報とを用いてユーザ認証を行い、ユーザ認証が行われたユーザに対してワークフローの処理への参加を許可するようにしたので、障害管理システムをグループウェアにより構成しなくても済み、ソフトウェアの分散開発を行うような場合に、それぞれのクライアントにグループウェアのプログラムをインストールするなどの面倒な作業を行うことなく、必要なユーザは認証を受ければワークフローに参加することができるようになる。また、ユーザ認証を受けていないユーザの参加を拒否することができるので、セキュリティの問題を解消することもできる。
上述した実施形態のその他の特徴によれば、１つの障害管理システム内で異なる複数のワークフローの処理が行われる場合に、異なる複数のワークフロー毎にユーザ認証を行うようにしたので、同じユーザでも、システム内で稼働している複数のワークフローのうち特定のワークフローに限って参加を認めることが可能となり、より質の高いセキュリティを実現することができる。
上述した実施形態のその他の特徴によれば、ユーザ認証機能のＯＮ／ＯＦＦを切り替えられるようにしたので、例えばソフトウェアの開発をあらかじめ固定された組織等の中で行うような場合には、ユーザ認証の機能をＯＦＦにすることによって、ログインする際にユーザ名やパスワードなどのユーザ情報を入力する手間を省略することができる。このように、ユーザ認証機能の有無を切り替えることで、ソフトウェアを分散開発する場合とそうでない場合との双方に柔軟に対応することができる。
【０１３４】
【発明の効果】
本発明によれば、クライアントサーバ・システムによって実現される障害管理システムを簡易に構成し、障害管理に関するソフトウェアの変更等のメンテナンスを容易に行えるようにすることができる。
また、本発明によれば、クライアント側でのシステムリソースの使用を節約できるようにして、クライアント側における使用資源の負担を軽減できるようにすることができる。
また、本発明によれば、障害管理の作業の効率性を向上させることができる。
また、本発明によれば、ソフトウェアの分散開発を行う場合に、必要なクライアントユーザが障害管理のワークフローに容易に参加できるようにするとともに、その際に重要な問題となるセキュリティを向上させることができるようにすることができる。
【図面の簡単な説明】
【図１】第１の実施形態による障害管理システムの詳細な機能構成例を示すブロック図である。
【図２】第１〜第３の実施形態による障害管理システム全体の概略的な構成を示すブロック図である。
【図３】入力フォーム定義部およびワークフロー定義部により入力フォームやワークフローモデルを定義する際の手順を示すフローチャートである。
【図４】図３のステップＳ３において入力フォームのテンプレートを定義する際の手順を示すフローチャートである。
【図５】サーバに保存されている入力フォームのテンプレートをクライアントが入手する際の動作を示すフローチャートである。
【図６】入力フォームに基づき作成したレポートをクライアントからサーバに提出する際の動作を示すフローチャートである。
【図７】図６中に示されるメイン処理の動作を示すフローチャートである。
【図８】通知された障害レポートの画面表示例を示す図である。
【図９】第２の実施形態による障害管理システムの詳細な機能構成例を示すブロック図である。
【図１０】情報一覧表示部に表示された障害一覧の画面表示例を示す図である。
【図１１】第３の実施形態による障害管理システムの詳細な機能構成例を示すブロック図である。
【図１２】第３の実施形態において障害の一覧を表示させる際のサーバ内の動作を示すフローチャートである。
【図１３】第４の実施形態による障害管理システム全体の概略的な構成を示すブロック図である。
【図１４】第４の実施形態による障害管理システムの詳細な機能構成例を示すブロック図である。
【図１５】サーバからクライアントに状態変更の通知メールが送られてきたときに行われるクライアント内の動作を示すフローチャートである。
【図１６】図１５のステップＳ６６におけるユーザ認証の動作を示すフローチャートである。
【図１７】図１５および図１６に示した動作を画面イメージで示す図である。
【符号の説明】
１０ クライアントマシン
１１ メール送信部
１２ メール受信部
１３ メール返信部
１４ ファイル添付部
１５ 情報一覧表示部
２０ サーバマシン
２１ データベース
２２ メールサーバ
２３ 提出者チェック部
２４ ワークフロー状態判定部
２５ 識別番号採番部
２６ ワークフロー状態遷移処理部
２７ 状態遷移通知部
２８ 情報一覧処理部
２９ 情報一覧処理部
３０ 管理者用端末
３１ 入力フォーム定義部
３２ ワークフロー定義部
３３ 入力フォーム
３４ ワークフローモデル
４０ ネットワーク
４１ 入力フォーム要求部
４２ フォーム送信部
４３ 通知受信部
４４ フォーム解析部
４５ 入力フォーム
４６ 通知部
５０ インターネット
５１ ログイン部
５２ 通知受信部
５３ パスワード登録部
５４ パスワードファイル
５５ ユーザ認証部
５６ ＯＮ／ＯＦＦ切替部
５７ 通知部
６０ ＬＡＮ
７０ クライアントマシン

Claims (13)

1. 障害登録フォームに障害に関する情報が入力されることによって作成された障害レポートの通知を、ネットワークを介して通信可能なクライアント装置より受け取る送受信手段と、
   前記送受信手段で受け取られた前記通知に含まれるユーザ情報と、記憶装置に記憶されている障害管理のワークフローモデルの定義情報で定義されているユーザの役割定義情報と、に基づいて、有効なユーザからの障害レポートの通知か否かを判定する判定手段と、
   前記判定手段で有効なユーザからの障害レポートの通知であると判定された場合、前記障害レポートを記憶装置に登録し、前記障害管理のワークフローモデルの定義情報で定義されているワークフローモデルを構成する各状態間で障害管理の業務に関連する情報をどのように流していくかを表した遷移定義情報に基づいて、ワークフローの状態を遷移させ、前記ワークフローモデルの定義情報で定義されている前記各状態におけるユーザの役割の各々に応じて異なったどのような手順で障害に対する対策をとっていくかを表した手順情報に基づいて、遷移後の状態における該当するユーザの役割に応じた対策に関する指示を該当するクライアント装置に対して通知させるよう制御するワークフロー状態遷移処理手段と、
   を有することを特徴とするサーバ装置。
2. 前記送受信手段は、更に、前記障害登録フォームのテンプレートの入手要求を、ネットワークを介して通信可能なクライアント装置より受け取り、
   前記判定手段は、更に、前記送受信手段で受け取られた前記入手要求に含まれるユーザ情報と、前記障害管理のワークフローモデルの定義情報で定義されているユーザの役割定義情報と、に基づいて、有効なユーザからの前記障害登録フォームのテンプレートの入手要求か否かを判定し、
   前記送受信手段は、更に、前記判定手段で有効なユーザからの前記障害登録フォームのテンプレートの入手要求であると判定された場合、前記障害登録フォームのテンプレートを前記クライアント装置に送信することを特徴とする請求項１に記載のサーバ装置。
3. 前記送受信手段は、更に、障害対策報告フォームのテンプレートの入手要求を、ネットワークを介して通信可能なクライアント装置より受け取り、
   前記判定手段は、更に、前記送受信手段で受け取られた前記入手要求に含まれるユーザ情報と、記憶装置に記憶されている前記障害管理のワークフローモデルの定義情報で定義されているユーザの役割定義情報と、に基づいて、有効なユーザからの前記障害対策報告フォームのテンプレートの入手要求か否かを判定し、
   前記送受信手段は、更に、前記判定手段で有効なユーザからの前記障害対策報告フォームのテンプレートの入手要求であると判定された場合、前記障害対策報告フォームのテンプレートを前記クライアント装置に送信することを特徴とする請求項１又は２に記載のサーバ装置。
4. 前記送受信手段は、更に、前記障害対策報告フォームに障害対策報告に関する情報が入力されることによって作成された対策レポートの通知を前記クライアント装置より受け取り、
   前記ワークフロー状態遷移処理手段は、更に、前記対策レポートの通知に前記障害に固有の識別情報を含ませ、前記識別情報に基づいて、前記対策レポートを、前記対策レポートに対応する前記障害レポートと対応付けることを特徴とする請求項３に記載のサーバ装置。
5. サーバ装置と、クライアント装置と、を含む障害管理システムであって、
   前記クライアント装置は、
   障害登録フォームに障害に関する情報が入力されることによって作成された障害レポートの通知を、ネットワークを介して通信可能なサーバ装置に通知する通知手段を有し、
   前記サーバ装置は、
   前記通知を、ネットワークを介して通信可能なクライアント装置より受け取る送受信手段と、
   前記送受信手段で受け取られた前記通知に含まれるユーザ情報と、記憶装置に記憶されている障害管理のワークフローモデルの定義情報で定義されているユーザの役割定義情報と、に基づいて、有効なユーザからの障害レポートの通知か否かを判定する判定手段と、
   前記判定手段で有効なユーザからの障害レポートの通知であると判定された場合、前記障害レポートを記憶装置に登録し、前記障害管理のワークフローモデルの定義情報で定義されているワークフローモデルを構成する各状態間で障害管理の業務に関連する情報をどのように流していくかを表した遷移定義情報に基づいて、ワークフローの状態を遷移させ、前記ワークフローモデルの定義情報で定義されている前記各状態におけるユーザの役割の各々に応じて異なったどのような手順で障害に対する対策をとっていくかを表した手順情報に基づいて、遷移後の状態における該当するユーザの役割に応じた対策に関する指示を該当するクライアント装置に対して通知させるよう制御するワークフロー状態遷移処理手段と、
   を有することを特徴とする障害管理システム。
6. 前記送受信手段は、更に、前記障害登録フォームのテンプレートの入手要求を、ネットワークを介して通信可能なクライアント装置より受け取り、
   前記判定手段は、更に、前記送受信手段で受け取られた前記入手要求に含まれるユーザ情報と、前記障害管理のワークフローモデルの定義情報で定義されているユーザの役割定義情報と、に基づいて、有効なユーザからの前記障害登録フォームのテンプレートの入手要求か否かを判定し、
   前記送受信手段は、更に、前記判定手段で有効なユーザからの前記障害登録フォームのテンプレートの入手要求であると判定された場合、前記障害登録フォームのテンプレートを前記クライアント装置に送信することを特徴とする請求項５に記載の障害管理システム。
7. 前記送受信手段は、更に、障害対策報告フォームのテンプレートの入手要求を、ネットワークを介して通信可能なクライアント装置より受け取り、
   前記判定手段は、更に、前記送受信手段で受け取られた前記入手要求に含まれるユーザ情報と、記憶装置に記憶されている前記障害管理のワークフローモデルの定義情報で定義されているユーザの役割定義情報と、に基づいて、有効なユーザからの前記障害対策報告フォームのテンプレートの入手要求か否かを判定し、
   前記送受信手段は、更に、前記判定手段で有効なユーザからの前記障害対策報告フォームのテンプレートの入手要求であると判定された場合、前記障害対策報告フォームのテンプレートを前記クライアント装置に送信することを特徴とする請求項５又は６に記載の障害管理システム。
8. サーバ装置における情報処理方法であって、
   障害登録フォームに障害に関する情報が入力されることによって作成された障害レポートの通知を、ネットワークを介して通信可能なクライアント装置より受け取る送受信ステップと、
   前記送受信ステップで受け取られた前記通知に含まれるユーザ情報と、記憶装置に記憶されている障害管理のワークフローモデルの定義情報で定義されているユーザの役割定義情報と、に基づいて、有効なユーザからの障害レポートの通知か否かを判定する判定ステップと、
   前記判定ステップで有効なユーザからの障害レポートの通知であると判定された場合、前記障害レポートを記憶装置に登録し、前記障害管理のワークフローモデルの定義情報で定義されているワークフローモデルを構成する各状態間で障害管理の業務に関連する情報をどのように流していくかを表した遷移定義情報に基づいて、ワークフローの状態を遷移させ、前記ワークフローモデルの定義情報で定義されている前記各状態におけるユーザの役割の各々に応じて異なったどのような手順で障害に対する対策をとっていくかを表した手順情報に基づいて、遷移後の状態における該当するユーザの役割に応じた対策に関する指示を該当するクライアント装置に対して通知させるよう制御するワークフロー状態遷移処理ステップと、
   を含むことを特徴とする情報処理方法。
9. 前記送受信ステップでは、更に、前記障害登録フォームのテンプレートの入手要求を、ネットワークを介して通信可能なクライアント装置より受け取り、
   前記判定ステップでは、更に、前記送受信ステップで受け取られた前記入手要求に含まれるユーザ情報と、前記障害管理のワークフローモデルの定義情報で定義されているユーザの役割定義情報と、に基づいて、有効なユーザからの前記障害登録フォームのテンプレートの入手要求か否かを判定し、
   前記送受信ステップでは、更に、前記判定ステップで有効なユーザからの前記障害登録フォームのテンプレートの入手要求であると判定された場合、前記障害登録フォームのテンプレートを前記クライアント装置に送信することを特徴とする請求項８に記載の情報処理方法。
10. 前記送受信ステップでは、更に、障害対策報告フォームのテンプレートの入手要求を、ネットワークを介して通信可能なクライアント装置より受け取り、
    前記判定ステップでは、更に、前記送受信ステップで受け取られた前記入手要求に含まれるユーザ情報と、記憶装置に記憶されている前記障害管理のワークフローモデルの定義情報で定義されているユーザの役割定義情報と、に基づいて、有効なユーザからの前記障害対策報告フォームのテンプレートの入手要求か否かを判定し、
    前記送受信ステップでは、更に、前記判定ステップで有効なユーザからの前記障害対策報告フォームのテンプレートの入手要求であると判定された場合、前記障害対策報告フォームのテンプレートを前記クライアント装置に送信することを特徴とする請求項８又は９に記載の情報処理方法。
11. コンピュータを、
    障害登録フォームに障害に関する情報が入力されることによって作成された障害レポートの通知を、ネットワークを介して通信可能なクライアント装置より受け取る送受信手段と、
    前記送受信手段で受け取られた前記通知に含まれるユーザ情報と、記憶装置に記憶されている障害管理のワークフローモデルの定義情報で定義されているユーザの役割定義情報と、に基づいて、有効なユーザからの障害レポートの通知か否かを判定する判定手段と、
    前記判定手段で有効なユーザからの障害レポートの通知であると判定された場合、前記障害レポートを記憶装置に登録し、前記障害管理のワークフローモデルの定義情報で定義されているワークフローモデルを構成する各状態間で障害管理の業務に関連する情報をどのように流していくかを表した遷移定義情報に基づいて、ワークフローの状態を遷移させ、前記ワークフローモデルの定義情報で定義されている前記各状態におけるユーザの役割の各々に応じて異なったどのような手順で障害に対する対策をとっていくかを表した手順情報に基づいて、遷移後の状態における該当するユーザの役割に応じた対策に関する指示を該当するクライアント装置に対して通知させるよう制御するワークフロー状態遷移処理手段と、
    して機能させることを特徴とするプログラムを記録したコンピュータ読み取り可能な記録媒体。
12. 前記送受信手段は、更に、前記障害登録フォームのテンプレートの入手要求を、ネットワークを介して通信可能なクライアント装置より受け取り、
    前記判定手段は、更に、前記送受信手段で受け取られた前記入手要求に含まれるユーザ情報と、前記障害管理のワークフローモデルの定義情報で定義されているユーザの役割定義情報と、に基づいて、有効なユーザからの前記障害登録フォームのテンプレートの入手要求か否かを判定し、
    前記送受信手段は、更に、前記判定手段で有効なユーザからの前記障害登録フォームのテンプレートの入手要求であると判定された場合、前記障害登録フォームのテンプレートを前記クライアント装置に送信することを特徴とする請求項１１に記載の記録媒体。
13. 前記送受信手段は、更に、障害対策報告フォームのテンプレートの入手要求を、ネットワークを介して通信可能なクライアント装置より受け取り、
    前記判定手段は、更に、前記送受信手段で受け取られた前記入手要求に含まれるユーザ情報と、記憶装置に記憶されている前記障害管理のワークフローモデルの定義情報で定義されているユーザの役割定義情報と、に基づいて、有効なユーザからの前記障害対策報告フォームのテンプレートの入手要求か否かを判定し、
    前記送受信手段は、更に、前記判定手段で有効なユーザからの前記障害対策報告フォームのテンプレートの入手要求であると判定された場合、前記障害対策報告フォームのテンプレートを前記クライアント装置に送信することを特徴とする請求項１１又は１２に記載の記録媒体。

Images