JP4021874B2 - 障害管理装置 - Google Patents

Description

本発明は、障害管理装置に関し、特に、コンピュータ上で稼動するソフトウェア（プログラム）に発生した障害を管理するための装置に用いて好適なものである。

システム開発におけるソフトウェアの障害管理では、プログラム上のバグ（障害）を発見してそのデバッグを行ったり、ドキュメント上の間違いを修正したり等していく際に、作業の効率化や適切化等を図るためには、そのデバッグ等に必要な情報の管理や作業の管理等を行うことが必要である。そのためにソフトウェアのテストツールには、バグに関する情報の管理機能等を組み込むことが要求される場合がある。

しかしながら、従来のテストツールは、開発中あるいは開発済のプログラムをコンパイルし、得られるエラー情報を単に蓄積して参照できるようにするだけのものが殆どであった。

そのため、あるソフトウェアについて発生した幾つかの障害を分析し、その分析した内容をもとにグラフ化することなどは、開発者等が人手により行っていた。そして、何か問題があるかどうかは、この人手により作成したグラフを参照して開発者自身が判断していた。そのため、異常の有無はそのグラフ化をしたときに初めて理解できることになるので、障害対策に非常に多くの時間がかかってしまうという問題があった。

また、例えば、一連の開発工程の中で障害の発生やそれに対する対策作業がどのように推移しているかとか、各工程のどの段階でどれだけ障害が発生しているか等の分析結果をグラフとして見る場合に、あまりにも開発の初期の段階で分析を行っても、それが正常か異常かを判断することができない。そのため、その分析作業が手間をかけた割には有意義でなかったりすることがある。さらに、データの分析およびグラフ化の作業を、開発が相当程度進んだ段階あるいは開発が終了した後で行うと、その分析結果に基づいてプログラム開発工程等への対策をとるには遅すぎてしまうという問題もあった。

本発明は、このような事情に鑑みてなされたものであり、システム開発におけるソフトウェアの障害対策などの作業をより効率的に行うことができるようにすることを目的とする。

本発明の障害管理装置は、ソフトウェア上に発生した各種障害に関してユーザが提出するレポートの入力フォームを定義する入力フォーム定義手段と、上記ユーザによって入力されたレポートを受信し、レポートのフォームを解析するフォーム解析手段と、上記入力された障害レポート、対策レポート、及び対策完了レポートを含む各種レポートのレポート情報を蓄積するための記憶手段と、上記入力されるレポート情報の障害毎にどのような手順で障害に対する対策処理をとっていくかを定義したワークフロー定義情報に基づいて対策処理の状態情報を遷移させる状態遷移処理手段と、ネットワークを介して接続されたクライアント装置に対して通知を行うための通知手段とを備え、上記フォーム解析手段は、上記クライアント装置から送られてきたレポートのフォームを、内部に保存されている入力フォームを参照することで、どの障害に対するレポートであるかを特定し、上記状態遷移処理手段は、上記ワークフロー定義情報に定義されたいずれかの手順が実行されそのレポートが通知される毎に、ワークフロー定義情報に基づいて対策処理の状態情報を遷移させ、当該ワークフロー定義情報に定められている次の業務指示を通知手段を介して上記クライアント装置に通知すると共に、ソフトウェア上で発生した各種障害に関して、上記クライアント装置からそれぞれ送られてきた上記障害レポート、上記対策レポート、及び上記対策完了レポートを含む各種レポートを障害毎に上記記憶手段に順次蓄積することを特徴とする。

本発明によれば、ワークフローに従って、ソフトウェア上に発生した各種障害そのものに関する情報だけでなくその障害に対する対策業務に関する情報も管理し適切なユーザに通知することができ、システム開発の一連の作業効率をより一層向上させることができる。また、入力されたレポートが、どの障害に対するレポートであるか特定することで、その後のデータ収集などを効率的に行うことができる。

以下、本発明の一実施形態を図面に基づいて説明する。
（第１の実施形態）
図１は、本実施形態による障害管理装置の主要な機能構成例を示すブロック図である。

図１において、入力フォーム定義部１は、ソフトウェアの障害管理を実行する際に開発担当者や管理者等のユーザが提出するレポートの入力フォーム２（障害の登録や障害対策の報告、あるいは対策完了の報告などの目的に使用する各種フォーム）を数種類定義するものである。ここでは、障害が起こったときにそれに対応して行われる各作業の段階毎に、ユーザが提出するレポート中に入力すべき必要な項目を列挙したテンプレートを定義する。

例えば、障害登録フォームのテンプレートの中には、レポート提出日、障害名称、障害発生対象環境、症状、対策期限、重要度などの各入力項目が含まれる。また、障害対策報告フォームや対策完了報告フォームのテンプレートの中には、レポート提出日、障害名称、障害原因、対策内容、修正後プログラムの版ナンバ、修正の工数などの各入力項目が含まれる。

フォーム入力部３は、あらかじめ定義され保存されている数種類の入力フォーム２の中から、提出しようとするレポートの内容に応じたフォームを入手し、その取得した入力フォーム内の各項目に必要事項を記入することによって各種レポート（障害レポート、対策レポート、対策完了レポートなど）を作成し、提出するためのものである。レポート登録部４は、フォーム入力部３によりレポートが提出される都度、そのレポートをデータベース５に登録するものである。

これにより、データベース５には、ある１つのソフトウェア上で発生した幾つかの障害に関して、それぞれ障害の発見からその対策の作業が進むにつれて、障害レポートや対策レポート、対策完了レポートなどが各障害毎に順次蓄積されていく。また、対象としているソフトウェアが複数ある場合には、それぞれのソフトウェア毎にその障害に関する各種レポートが各々蓄積されていく。

データ収集部６は、各種のレポート情報が蓄積されているデータベース５の中から必要な情報を収集するものである。必要な情報とは、これから行おうとする分析処理にて使用する情報のことである。例えば、あるソフトウェアに関する障害の発生件数を分析する場合には、対象とするソフトウェアに関して障害登録を行う際に提出された障害レポートの情報のみを収集する。

また、障害に対する対策の完了件数を分析する場合は、対象とするソフトウェアに関して対策完了の報告を行う際に提出された対策完了レポートの情報のみを収集する。また、各種障害の発生原因の割合を分析する場合は、対象とするソフトウェアに関して対策の報告を行う際に提出された対策レポートもしくは上述の対策完了レポートの情報のみを収集する。

分析・評価実行部７は、データ収集部６により収集された情報を分析し、その分析結果とあらかじめ用意されている評価基準８のデータとを比較して、異常の有無やソフトウェアの品質等の評価を実行するものである。また、分析結果出力部９は、分析・評価の結果を出力するものである。例えば、分析された結果をグラフ化して図示しない表示装置に表示したり、分析結果と評価基準８とがある許容範囲を越えて異なっている場合に警告通知を行ったりする等の処理を行う。

本実施形態においては、上記分析・評価実行部７では、障害発生に対する信頼度成長曲線の分析（障害の発生件数と対策完了件数の推移の分析）と、発生した障害が属する分類（発生原因）の割合の分析との２種類の分析を行えるようになっている。そして、どちらの分析を行うかは、例えば図示しない表示装置の画面に表示されたメニュー等を操作することによって、ユーザが任意に指定できるようになっている。

まず、障害発生に対する信頼度成長曲線の分析から説明する。図２は、上記信頼度成長曲線の出力例を示す図である。図２に示すグラフにおいて、横軸は時間の経過を示し、縦軸は件数を示している。図２には３つの折れ線グラフが示されている。これらのうち、◆でプロットした折れ線グラフＡと●でプロットした折れ線グラフＣは、あるソフトウェアについて発生した障害の件数（障害レポートの登録数）を示し、△でプロットした折れ線グラフＢは、あるソフトウェアについて完了した障害対策の件数（対策完了レポートの登録数）を示している。

通常のソフトウェアで、適切なテストツールを使って必要なテスト項目についてテストを行った場合、障害の発生件数は、折れ線グラフＡのように推移することが経験的に知られている。すなわち、障害の発生件数は、テスト開始直後はポツポツと発生し（第１フェーズ）、その後少し経過するとその件数が一気に増加し（第２フェーズ）、テスト開始後かなり経つと増加率は低くなる（第３フェーズ）。そして、テストの最終局面になると、飽和状態となる（第４フェーズ）といった具合である。

これに対して、折れ線グラフＣのようにテスト開始の当初から障害の発生件数が徐々にしか増加していかないケースや、あるいは障害の発生件数が最初からずっと増加し続けるケース（折れ線グラフは図示していない）など、折れ線グラフＡとは明らかに異なる推移を辿るケースでは、対象としているソフトウェアそのものに根本的な問題があったり、間違ったテストツールを使っていたりテスト項目が少ない等のようにテストの仕方に問題があったりすることが多い。

そこで、本実施形態では、評価基準８のデータとして、折れ線グラフＡのように通常の推移を辿るグラフの各フェーズにおける傾きの値をあらかじめ格納しておく。そして、分析・評価実行部７において、データベース５から収集した障害レポートについて分析した結果得られるグラフの傾きと、上記評価基準８のデータとしてあらかじめ用意されている傾きの値とを比較して、両者の傾きが所定の許容範囲を越えて異なっている場合には、分析結果出力部９から何らかの警告通知を行うようにする。

例えば、６月１９日の時点で上述のような分析・評価の処理を実行した結果、障害の発生件数が折れ線グラフＣのように推移していた場合には、この時点で直ちに警告通知が行われる。これにより、ソフトウェアの開発者等は、当該ソフトウェア自体あるいはテストの仕方などに何らかの問題があることを把握して、それに対する対策を直ちにとることができる。

この場合、障害の発生件数が折れ線グラフＣのように徐々にしか増加していかないケースや、障害の発生件数が最初からずっと増加しているケースなど、同じ異常でもそのグラフの傾きは様々に異なる。つまり、異常発生の原因として種々のものがあるが、その異常の種類に応じてグラフの傾きも異なってくるものである。そこで、異常の種類と傾きとの対応関係を経験的に一般化し、その情報を格納しておくことにより、傾きに応じて異なるコメントを出力することが可能である。このようにすれば、問題に対する適切な対策を容易にとることができる。

一方、分析・評価実行部７による障害発生件数の分析の結果得られたグラフの傾きと評価基準８の傾きとが一致する場合、もしくはその違いが所定の許容範囲内に収まっている場合は、分析結果出力部９では、上記分析・評価実行部７による分析結果をグラフ化して図示しない表示装置の画面上に表示する。あるいは、図示しない印刷装置により紙媒体などに印刷して出力するようにしても良い。

また、上記分析・評価実行部７による障害発生件数の分析結果をグラフ化して表示する際には、障害に対する対策完了件数の分析結果もグラフ化して併せて表示する。すなわち、分析・評価実行部７では、データベース５から収集された障害レポートの件数を分析すると同時に、同じく収集された対策完了レポートの件数も分析し、その結果を分析結果出力部９によって画面表示する。これにより、ソフトウェアの開発者等は、どのくらいの時間でどの程度の障害が発生し、それに対してどれだけ対策が行われたかを簡単に知ることができる。

さらに、障害発生件数が最終的にあまり変化しなくなる第４フェーズの部分を見ることによって、テストを終わらせるタイミングを判断したり、最終的に発生する障害の総数を予想したりすることもできる。障害の総数に対してどの割合まで障害を除去できれば当該ソフトウェアの品質が保証されるかということは、全てのソフトウェアやプログラムで同じではないが、それまでの経験から、個々のソフトウェアやプロジェクトの内容、特徴等から分かる。したがって、発生する障害の総数が予想できれば、現在の対策完了件数を参照することによって、あとどのくらい障害を除去すれば製品としてリリースできるか等の判断をすることもできるようになる。

なお、発生する障害の総数は、対象とするソフトウェアの規模、すなわちプログラムの行数に応じて概ね推定できる。そこで、プログラムの行数から予想した発生障害の総数に対して所定の割合（例えば８０％）をかけて得られた件数の部分に、品質目標の目安となるリリース可能ラインを表示するようにしても良い。このようにすれば、あとどのくらい障害を除去すればリリースできるかがより明確になるとともに、分析・評価の処理を第１〜第３フェーズの早い段階で行ったような場合にも、リリース可能な状態となるまでに必要な残り障害除去数を知ることができる。

また、対象とするプログラムの行数から予想した発生障害の総数に対して所定の割合をかけて得られた件数を、評価基準８のデータとして保存しておく。そして、分析・評価実行部７により分析された対策完了レポートの件数が上記評価基準８の件数を上回っているかどうかを判断し、上回っていた場合に、分析結果出力部９からリリース許可の承認メッセージを出力するようにしても良い。このようにすれば、図２のようなグラフを見るまでもなく、分析・評価処理を実行した時点でリリース可能かどうかを知ることができる。

次に、欠陥分類の割合の分析について説明する。図３は、上記欠陥分類の割合について分析した結果の出力例を示す図である。図３においては、実装機能の欠陥、コーディングの欠陥、仕様の欠陥、システム統合上の欠陥、システムアーキテクチャ上の欠陥、データ定義・参照に起因する欠陥など、各種の障害原因毎にその発生割合を円グラフにして出力した例を示している。

どの障害がどの原因により発生したかは、開発者によって障害の調査や対策が行われ、その結果として提出された対策レポートもしくは対策完了レポートの中に記述されている。したがって、データ収集部６によってデータベース５から対策レポートもしくは対策完了レポートを障害の発生原因毎に収集し、分析・評価実行部７によってその収集結果を個別に累積していけば、各原因毎の障害の発生割合を分析することができる。

この欠陥分類の割合に関しても、テスト等に異常がない場合に、どの分類の障害がどの程度の割合で発生するかが経験的に知られている。そこで、本実施形態では、評価基準８のデータとして、各分類の通常の割合の値をあらかじめ用意しておく。そして、分析・評価実行部７において、データベース５から収集した対策レポート等について分析した結果得られる各分類の割合と、上記評価基準８のデータとしてあらかじめ用意されている割合の値とを比較して、両者の割合が所定の許容範囲を越えて異なっている場合には、分析結果出力部９から何らかの警告通知を行うようにする。

このような欠陥分類の割合の分析は、ソフトウェア開発の一連の過程の中のどの段階でどの程度の障害が発生しているのかを見るものであるため、開発が最後まで終了した段階で行うのが通常である。ただし、ソフトウェアの規模に応じて発生する障害の総数が予想できれば、開発過程の途中の段階で行うことも可能である。すなわち、開発過程の途中の段階で分析・評価を実行しても、その段階までに発生した障害の予想障害総数に対する割合を知ることができるので、それが異常か否かに応じて警告通知を行うことが可能である。

図４は、データの自動収集および分析・評価の動作を示すフローチャートである。図４において、まずステップＳ１で、これから分析を行う種類に応じて特定の情報をデータベース５内のデータファイルから収集し、それを分析する。図５および図６は、このステップＳ１における具体的な処理手順を示すフローチャートであり、図５は信頼度成長曲線を分析する際の処理手順を示し、図６は欠陥分類の発生割合を分析する際の処理手順を示している。

例えば、信頼度成長曲線を分析する場合は、まず図５のステップＳ１１でデータ収集部６は、データベース５に蓄積されている障害レポートの提出日をデータファイルから収集する。また、ステップＳ１２では、同じくデータベース５に蓄積されている対策完了レポートの提出日をデータファイルから収集する。次に、ステップＳ１３で、分析・評価実行部７は、上記ステップＳ１１およびステップＳ１２で収集した情報の提出日毎に各レポートの件数を累積する。

また、欠陥分類の割合を分析する場合は、まず図６のステップＳ２１でデータ収集部６は、データベース５に蓄積されている対策完了レポートの欠陥分類結果（障害の発生原因）をデータファイルから収集する。次に、ステップＳ２２で、分析・評価実行部７は、上記ステップＳ２１で収集した情報の分類項目毎に各レポートの件数を累積する。さらに、ステップＳ２３では、上記ステップＳ２２にて各分類項目毎に累積した件数をもとに、それぞれの総件数に対する割合を計算する。

以上のように、図５あるいは図６のフローに従ってデータの収集および分析が終了すると、図４のステップＳ２に進み、その分析結果と、評価基準８のデータとを比較する。そして、ステップＳ３でその比較の結果が正常かどうか、すなわち、分析・評価実行部７による分析の結果得られるデータと評価基準８のデータとが一致するか、もしくはその違いが所定の許容範囲内に収まっているかどうかを判断する。

ここで、比較の結果が正常であった場合は、ステップＳ４に進み、分析結果出力部９によって分析結果を図示しない表示装置に出力する。これにより、この表示装置の画面上には、図２あるいは図３に示したようなグラフが表示される。一方、比較の結果が正常でなかった場合は、ステップＳ５に進み、分析結果出力部９によって所定の警告通知を行う。このとき、上述したように、分析結果が評価基準８とどのように違っているかに応じて、異なる警告メッセージを出力するようにすることが可能である。

以上詳しく説明したように、本実施形態の障害管理装置では、各種障害に関する情報をデータベース５の中から自動的に収集して分析し、その分析結果とあらかじめ用意されている評価基準とを比較して評価するとともに、分析・評価の結果を表示装置等に表示するようにしたので、ソフトウェアについて発生した障害の分析およびグラフ化等の作業を人手により行わなくても、分析・評価の処理を行うことを指示すれば、障害管理装置が評価基準８に基づいて異常の有無を自動的に判断してくれるので、分析内容を瞬時に理解することができる。また、一連の開発工程の中の任意の段階で分析・評価の処理を実行することで異常の有無を直ちに知ることもでき、それに対する適切な対策を早期に行うこともできる。

また、障害に対する対策の完了件数を分析し、その分析結果と予め用意されている評価基準とを比較することにより、障害対策を行ったソフトウェアの品質を評価するようにしたので、障害に対する対策がどれだけ進んでいるかの進捗状況等が開発者に提示され、開発者が直ちに知ることができ、例えば、品質目標にまで障害除去が進んだ場合にそのことが直ちに通知される。また、分析・評価の結果と予め用意されている評価基準とを併せて表示するようにしたので、両者を比較参照することにより、障害に対する対策作業の進捗度合いやテストの終了時期等を表示内容から容易に把握することができる。

（第２の実施形態）
次に、本発明の第２の実施形態を説明する。以下に述べる第２の実施形態は、第１の実施形態で説明した障害管理装置をクライアント・サーバシステムの形態をとる障害管理システムに応用したものである。第２の実施形態による障害管理システムでは、障害に関する情報の他に一連の障害対策の管理情報も保有し、適切に対策がとられているかについても監視し管理する機能を持つ。この機能は、オフィスの業務に関連する情報を各部門間で共有してその情報の流れを管理する所謂ワークフローシステムを利用することで実現している。

図７および図８は、本実施形態による障害管理システムの構成例を示すブロック図であり、図７はシステム全体の概略的な構成を示し、図８はシステム内の詳細な機能構成を示している。なお、図７および図８において、図１に示した符号と同一の符号を付したものは、同一の機能を有するものである。

図７に示すように、本実施形態の障害管理システムは、複数のクライアントマシン（以下、クライアントと略す）１０，１０，…と、サーバマシン（以下、サーバと略す）２０とがネットワーク４０を介して接続されたクライアント・サーバシステムとして構成される。さらに、サーバ２０には、障害管理システムを管理する管理者用の端末３０が接続される。また、このサーバ２０は、上述した各種レポートや後述するワークフローの遷移状態に関する情報を含む障害管理業務データを格納するためのデータベース２１を備える。

図８に示すように、管理者用端末３０には、入力フォーム定義部１、ワークフロー定義部３１、収集情報定義部３２、評価基準定義部３３および警告定義部３４が備えられる。入力フォーム定義部１は、上述したように、ソフトウェアの障害管理を実行する際にユーザが提出するレポートの入力フォームを数種類定義するものである。ここで定義された入力フォーム２は、サーバ２０に与えられて保存される。

また、ワークフロー定義部３１は、アプリケーションソフトウェアの開発部門や使用部門等の間で、障害管理の業務に関連する情報をどのように流して、どのような手順で障害に対する対策をとっていくか等を表したワークフローを定義するものである。ここで定義されたワークフローモデル２６のファイルも、サーバ２０に与えられて保存される。

収集情報定義部３２は、分析・評価実行部７によってデータの分析を行うときに必要な情報、つまり、どの分析処理においてデータベース２１内のどのデータが必要かについて定義するものである。例えば、障害の発生件数を分析する場合は障害レポート、障害に対する対策の完了件数を分析する場合や各種障害の発生原因の割合を分析する場合は対策完了レポートの情報が、分析に必要な情報として定義される。ここで作成された収集情報定義ファイル２７も、サーバ２０に与えられて保存される。

評価基準定義部３３は、上述した評価基準８のデータを定義するものであり、上述の信頼度成長曲線の各フェーズにおける傾き、欠陥分類毎の発生割合、製品リリースの品質保証目安となる対策完了件数などを定義する。また、警告定義部３４は、異常の種類（ソフトウェア自体の異常やテストの仕方の異常など）と分析結果（上述の傾きや割合など）との対応関係や、異常の種類に応じた警告メッセージ等を警告定義ファイル２８として定義するものである。ここで作成された評価基準８や警告定義ファイル２８も、サーバ２０に与えられて保存される。

また、クライアント１０上では、ウェブ（Ｗｅｂ）ベースの汎用的なブラウザソフトが稼働している。そして、このブラウザソフトは、図８に示すように、入力フォーム要求部１１、フォーム送信部１２、通知受信部１３および分析結果表示部１４を機能として備えている。なお、通知受信部１３は、汎用的なメールソフトの機能として実現しても良い。このクライアント１０は、ソフトウェアの開発部門およびその使用部門などに属する各種ユーザによって使用される。

本実施形態のクライアント１０は、ソフトウェアの障害管理を行うに当たり、汎用的なウェブベースやメールベースのプログラムを備えていれば良く、障害管理のためのワークフロープログラムは何ら備えていなくても良い。一方、サーバ２０は、ウェブやメールによるデータの入出力を行うプログラムと、障害管理のためのワークフロープログラムとを備える。すなわち、本実施形態において障害管理のためのワークフロープログラムは、サーバ２０のみが備えている。

上記入力フォーム要求部１１は、サーバ２０内に保存されている各種の入力フォーム２の中から所望のフォームの取得を要求するためのものであり、例えば画面中に表示されたブラウザボタン等を有している。このブラウザボタンをマウスでクリックして所望のフォームを指定すると、その指定された入力フォーム２がサーバ２０から送られる。この入力フォーム２は、例えばＨＴＭＬ形式のブラウザ画面そのものとして送られる。

フォーム送信部１２は、上述のように入手した入力フォーム２内の各項目に必要事項を記入することによってレポートを作成し、それをＨＴＭＬ形式にてサーバ２０側に送るものである。通知受信部１３は、サーバ２０から送られてくる後述の障害対策業務指示の通知や、警告通知などを受信するものである。また、分析結果表示部１４は、分析・評価実行部７によって分析された結果をグラフ化して表示するものである。

次に、サーバ２０内の構成について説明する。フォーム解析部２２は、クライアント１０のフォーム送信部１２から送られてきたレポートのフォームを、サーバ２０内に保存されている入力フォーム２を参照することによって解析する。そして、そのフォームがどういう種類のものかを確認する。このフォーム解析部４４はまた、レポート内に書かれた情報をもとに、そのレポートがどの障害に対するものであるかとか、その障害の発生原因等についても解析する。

ワークフロー状態判定部２３は、データベース２１に格納されているワークフローの遷移状態を表す情報を読み込み、さらにワークフローモデル２６の定義情報およびクライアント１０から与えられたレポート等に基づいて、障害管理のワークフローにおいて現在の状態が何であるかを、発生した障害毎に判定するものである。例えば、障害登録が行われたばかりの初期の状態、障害の原因調査中、障害への対策中、対策保留中、対策完了などの各状態のうち、現在はどの状態にあるのかを判定する。

ワークフロー状態遷移処理部２４は、障害対策の担当者や管理者によって何らかの処理が行われてそのレポートが通知される毎に、ワークフローの状態を遷移させる処理を実行する。これは、定義されているワークフローモデル２６に従って、クライアント１０から送られてきたレポートの内容に応じて次の状態に変更することによって行われる。このように更新された遷移状態の情報は、与えられたレポートと共に再びデータベース２１に格納される。

また、このワークフロー状態遷移処理部２４は、定義されているワークフローモデル２６に従って、当該ワークフローで定められている適切なクライアント１０に対して次の業務指示を通知部２５を介して通知する処理も行う。この業務指示は、あるクライアントから与えられたレポートをそのまま他のクライアントに転送することによって次に行うべき作業を示唆するものであっても良いし、明確な作業指示を作成して送るようにしても良い。この通知は、ウェブベースではなくメールベースで行っても良い。

この通知部２５はまた、上記ワークフロー状態遷移処理部２４によりある障害に関するワークフローの状態が遷移させられたときに、そのように状態が遷移させられたことを、ワークフローモデル２６中に通知範囲内として定義されているユーザのクライアント１０に通知する処理も行う。さらに、分析・評価実行部７による分析・評価の結果に応じて、警告メッセージや承認メッセージを通知する処理も行う。

以下に、上記のように構成した本実施形態の障害管理システムにおけるワークフロー動作について説明する。まず、作成されたアプリケーションをあるクライアント１０もしくは図示しないユーザ端末上で使用しているとき等に、何らかの障害（バグ）を発見したら、そのユーザは、発見した障害の報告を行う。そのとき使用する障害登録フォームをサーバ２０の入力フォーム２の中から入手するために、障害を発見したユーザは、自分が使用するクライアント１０の入力フォーム要求部１１から当該フォームの入手要求をサーバ２０に送信する。

サーバ２０が上記フォーム入手要求を受信すると、サーバ２０は、要求された障害登録フォームが各種入力フォーム２の中に存在するかどうかを判定する。ここで、要求されている障害登録フォームが存在する場合は、当該障害登録フォームのテンプレートを要求元のクライアント１０に送信する。

クライアント１０側で障害登録フォームを受信すると、ユーザは、そのフォーム内の各項目に必要事項を記述することによって障害レポートを作成し、それをフォーム送信部１２からサーバ２０に送信する。そして、サーバ２０側で上記障害レポートを受信すると、以下に述べるワークフローの処理が実行される。

すなわち、まずフォーム解析部２２により上記受信したレポートのフォームが解析され、どの障害に対するレポートであるかが特定される。そして、ワークフロー状態判定部２３により、上記特定された障害に関する現在のワークフローの状態がレポートの種類等に応じて判定される。今の例では障害レポートを受信しているので、発生した障害を最初に登録する初期段階であると判定される。

次に、ワークフロー状態遷移処理部２４は、ワークフローの処理対象としている障害の現在の状態を次の状態へと遷移させる。障害レポートの登録が済んだばかりの今の例では、ワークフローの状態は障害発生前の初期状態から原因調査中の状態へと遷移させられる。このとき更新された遷移状態の情報は、与えられたレポートと共にデータベース２１に格納される。さらに、ワークフロー状態遷移処理部２４は、通知部２５を用いて、ワークフローモデル２６で定められている適切なユーザ（今の例の場合は障害対策を行うべき担当者）のクライアント１０に対して、次の障害管理業務指示を通知する。

このような障害管理業務指示（障害レポート）を受け取った担当者（システム開発者）は、その報告された障害を解消するために必要な対策を実行する。例えば、必要に応じてプログラムを修正する。何らかの対策を行ったら、そのことを対策レポートとして記述し、サーバ２０に送信する。このとき担当者は、まず、障害対策報告フォームをサーバ２０の入力フォーム２の中から入手する。そして、その入手した障害対策報告フォーム中の各項目に必要事項を記述することによって対策レポートを作成し、それをサーバ２０に送信する。

この障害対策報告フォームに基づき作成された対策レポートをサーバ２０が受信すると、サーバ２０は、障害レポートを受信した際と同様に、フォーム解析部２２による解析によって障害との対応を検出し、ワークフロー状態判定部２３およびワークフロー状態遷移処理部２４によってワークフローの現在の状態を次の状態に遷移させる処理を行う（今の例の場合、原因調査中から対策中に状態が遷移する）。このときも、更新された遷移状態の情報は、与えられたレポートと共にデータベース２１に格納される。

さらに、サーバ２０側では、当該受け取った対策レポートを次にどのユーザに送れば良いかをワークフローモデル２６に従って検出し、適切なユーザ（例えば管理者など）のクライアント１０に送信する。これを受け取ったクライアント１０のユーザは、対策レポートの報告に問題があるかどうかを判断し、問題があれば、対応差戻しの指示を行う。一方、報告に問題がなければ、対策完了レポートを送信して、ワークフローの状態を"対策完了"へと遷移させる。

なお、ここでは、障害レポートを受け取った担当者が直ちに必要な対策をとっている例を示しているが、障害の原因を再調査したり、その障害について他の担当者と意見交換をしたり、あるいは緊急を要する他の障害の発生などにより対策を一時的に保留したりすることなども考えられる。このような場合も、それらの態様に応じた入力フォーム２をサーバ２０からクライアント１０に入手して、必要事項を記述して作成したレポートをサーバ２０に返信する。サーバ２０では、送られてきたレポートに応じてワークフローの状態を遷移させるとともに、そのレポートをワークフローに従って適切なユーザに通知する。

以上のように障害管理のワークフロー処理が進められていくと、データベース２１には、ソフトウェア上で発生した幾つかの障害に関して、それぞれ障害レポートや対策レポート、対策完了レポートなどが各障害毎に順次蓄積されていく。この場合、対策レポートや対策完了レポートをデータベース２１に登録するときは、フォーム解析部２２によって障害の発生原因が検出されているので、それらのレポートを障害の原因別、障害の重要度別、等に分けて格納するようにしても良い。このようにすれば、その後の分析処理のために行うデータ収集を効率的に行うことができる。

データベース２１に蓄積されている各種のレポート情報に対して、データ収集部６および分析・評価実行部７によりデータ収集および分析・評価の処理を自動的に実行することの内容に関しては、第１の実施形態で述べた通りであるので、ここでは詳しい説明は省略する。

ただし、データ収集部６によるデータ収集の際には、収集情報定義ファイル２７にて定義された必要な情報のみが収集される。また、分析・評価実行部７による分析・評価の結果、異常と診断された場合には、警告定義ファイル２８に記述されている内容に従って適切な警告メッセージが通知部２５を介して行われることとなる。一方、診断の結果が異常でない場合は、分析の結果がサーバ２０からクライアント１０の分析結果表示部１４に与えられて表示される。

以上のように、第２の実施形態によれば、障害情報そのものだけでなくその障害に対する対策業務に関する情報も管理するワークフロー処理の中で、蓄積された情報を利用して第１の実施形態で述べたような分析・評価を実行することができる。これにより、システム開発の一連の作業の効率をより一層向上させることができる。

なお、以上に説明した各実施形態は、何れも本発明を実施するにあたっての具体化のほんの一例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその精神、またはその主要な特徴から逸脱することなく、様々な形で実施することができる。例えば、上記実施形態ではグラフの例として折れ線グラフと円グラフとを示したが、これらのグラフには限定されない。また、分析の内容も、障害の発生件数や対策完了件数、欠陥の分類などに限定されるものではない。

なお、以上に説明した各実施形態の障害管理装置は、コンピュータのＣＰＵあるいはＭＰＵ、ＲＡＭ、ＲＯＭなどで構成されるものであり、ＲＡＭやＲＯＭに記憶されたプログラムが動作することによって実現できる。したがって、コンピュータが上記機能を果たすように動作させるプログラムを、例えばＣＤ−ＲＯＭのような記録媒体に記録し、コンピュータに読み込ませることによって実現できるものである。記録媒体としては、ＣＤ−ＲＯＭ以外に、フレキシブルディスク、ハードディスク、磁気テープ、光磁気ディスク、不揮発性メモリカード等を用いることができる。

また、コンピュータが供給されたプログラムを実行することにより上述の実施形態の機能が実現されるだけでなく、そのプログラムがコンピュータにおいて稼働しているＯＳ（オペレーティングシステム）あるいは他のアプリケーションソフト等と共同して上述の実施形態の機能が実現される場合や、供給されたプログラムの処理の全てあるいは一部がコンピュータの機能拡張ボードや機能拡張ユニットにより行われて上述の実施形態の機能が実現される場合も、かかるプログラムは本発明の実施形態に含まれる。

第１の実施形態による障害管理装置の詳細な機能構成例を示すブロック図である。 信頼度成長曲線について分析した結果の出力例を示す図である。 欠陥分類の割合について分析した結果の出力例を示す図である。 データの自動収集および分析・評価の動作を示すフローチャートである。 図４のステップＳ１において信頼度成長曲線を分析する際の処理手順を示すフローチャートである。 図４のステップＳ１において欠陥分類の割合を分析する際の処理手順を示すフローチャートである。 第２の実施形態による障害管理システム全体の概略的な構成を示すブロック図である。 第２の実施形態による障害管理システムの詳細な機能構成例を示すブロック図である。

符号の説明

１ 入力フォーム定義部
２ 入力フォーム
３ フォーム入力部
４ レポート登録部
５ データベース
６ データ収集部
７ 分析・評価実行部
８ 評価基準
９ 分析結果出力部
１０ クライアントマシン
１１ 入力フォーム要求部
１２ フォーム送信部
１３ 通知受信部
１４ 分析結果表示部
２０ サーバマシン
２１ データベース
２２ フォーム解析部
２３ ワークフロー状態判定部
２４ ワークフロー状態遷移処理部
２５ 通知部
２６ ワークフローモデル
２７ 収集情報定義ファイル
２８ 警告定義ファイル
３０ 管理者用端末
３１ ワークフロー定義部
３２ 収集情報定義部
３３ 評価基準定義部
３４ 警告定義部
４０ ネットワーク

Claims (1)

1. ソフトウェア上に発生した各種障害に関してユーザが提出するレポートの入力フォームを定義する入力フォーム定義手段と、
   上記ユーザによって入力されたレポートを受信し、レポートのフォームを解析するフォーム解析手段と、
   上記入力された障害レポート、対策レポート、及び対策完了レポートを含む各種レポートのレポート情報を蓄積するための記憶手段と、
   上記入力されるレポート情報の障害毎にどのような手順で障害に対する対策処理をとっていくかを定義したワークフロー定義情報に基づいて対策処理の状態情報を遷移させる状態遷移処理手段と、
   ネットワークを介して接続されたクライアント装置に対して通知を行うための通知手段とを備え、
   上記フォーム解析手段は、上記クライアント装置から送られてきたレポートのフォームを、内部に保存されている入力フォームを参照することで、どの障害に対するレポートであるかを特定し、
   上記状態遷移処理手段は、上記ワークフロー定義情報に定義されたいずれかの手順が実行されそのレポートが通知される毎に、ワークフロー定義情報に基づいて対策処理の状態情報を遷移させ、当該ワークフロー定義情報に定められている次の業務指示を通知手段を介して上記クライアント装置に通知すると共に、
   ソフトウェア上で発生した各種障害に関して、上記クライアント装置からそれぞれ送られてきた上記障害レポート、上記対策レポート、及び上記対策完了レポートを含む各種レポートを障害毎に上記記憶手段に順次蓄積することを特徴とする障害管理装置。

Images