JP2009245158A - 検証プログラム、該プログラムを記録した記録媒体、検証装置、および検証方法 - Google Patents

Abstract

【課題】予防策の挿入漏れおよび挿入位置を適切にチェックすることで、高信頼の運用プロセスの提供を可能とし、設計作業にかかる作業負担および作業時間を削減すること。
【解決手段】検証対象となる運用プロセス１００の中からメイン処理を検出し、マッピング情報３００を参照して、検出されたメイン処理の実行時に発生が予測されるエラーの予防策を運用プロセス１００の中から検索する。そして、メイン処理に対する検索された予防策の実行順序に基づいて、運用プロセス１００における予防策の挿入位置が正しいか否かを判断し、判断された判断結果を出力する。
【選択図】図１４

Description

この発明は、ＩＴ（Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）システムの運用管理にかかる運用プロセスの信頼性を検証する検証プログラム、該プログラムを記録した記録媒体、検証装置、および検証方法に関する。

近年、ＩＴシステムは大規模化・複雑化しており、その運用管理作業には、従来に比べてより専門的な知識が必要となっている。運用管理作業では、必要な処理を適切な手順（以下、「運用プロセス」という）に従っておこなう必要がある。一方で、近年におけるビジネス変化のスピードは非常に速く、ＩＴシステムも柔軟かつ迅速に追従することが求められている。

そのため、システム変更などの運用作業の工数が増大し、人為的ミスによる運用エラーが発生するといった事態が多く報告されている。これは、運用管理の煩雑化、運用マニュアルの不備、スキルやノウハウの属人化などが原因となって発生する。これらの問題を解決するためには、高信頼な運用プロセスを実行する必要がある。

運用プロセスを高信頼に実行するための重要なポイントは、失敗の発生を防ぐことである。過去に起こった失敗については、発生時点で原因を分析して予防策を検討し、その予防策を運用プロセスに挿入することで、過去に起こった失敗を防ぐことができる。したがって、運用プロセスが高信頼であるためには、過去に起こった失敗についての予防策が挿入されたプロセスを作成する必要がある。

ところが、現状では運用プロセスは人手で作成されており、作成者の経験不足やケアレスミスなどにより、失敗を防ぐための予防策が十分に仕込まれていない運用プロセスが作成される可能性がある。さらに、運用プロセスのチェックも人手でおこなわれるため、作成時と同様の理由で運用プロセスの不備に気付かない可能性がある。

このようなことから、チェックでは問題がないとされた運用プロセスが、実際には高信頼ではなく、実行時にエラーが発生してしまう場合がある。そこで、従来において、システムの運用管理作業を支援するための技術が提供されている（たとえば、下記特許文献１〜３参照）。

また、運用プロセスに予防策が挿入されているかどうかを確認するための手法として、付加情報（タグ）を用いた手法が知られている。タグ情報は、運用プロセスの各処理の属性をあらわす情報である。１つの処理に対して複数のタグ情報（たとえば、実行者、処理対象、処理タイプなど）を付加することができる。

各処理が実行される状況は、各処理に付加されたタグ情報から特定することができる。また、過去の失敗は、発生後の分析により発生原因と予防策とが検討されている。このため、各処理に付加されたタグ情報から特定される状況と過去の失敗とを関連付けることで、『処理』−『状況』−『失敗』−『予防策』の関連を特定可能なマッピング情報を作成することができる。

そして、運用プロセス内の処理に付加されているタグ情報を用いて、マッピング情報を参照することで、運用プロセスに挿入すべき予防策を特定することができる。さらに、特定された予防策のすべてが設計された運用プロセスに挿入されているか否かを判断することで、予防策の挿入漏れを防ぐことができる。

特開２００４−３１０３１１号公報 特開平８−１９０５８４号公報 特開２００１−１５５０６２号公報

しかしながら、上述した従来技術によれば、必要となる予防策が運用プロセスに挿入されているか否かをチェックすることはできるが、運用プロセス内の適切な位置に予防策が挿入されているか否かについては判断不能であった。予防策には、運用プロセス内の特定の箇所や特定の範囲内に挿入しなければ、その機能を発揮しないものもある。

このため、運用プロセス内に予防策が挿入されていたとしても、挿入位置が誤っていることで、実際の運用時にエラーが発生してしまう場合がある。このような場合、運用プロセスを設計し直す必要があるため、設計作業にかかる作業コストが増大し、ひいては設計期間の長期化を招くという問題があった。

また、運用プロセスの処理経路は途中で分岐することがあるため、運用プロセス内に複数の処理経路が存在することも少なくない。さらに、失敗の原因となる処理と予防策とが異なる経路上に存在する場合には、予防策が機能しないこともある。しかし、上述した従来技術では、運用プロセス内の分岐を考慮したチェックはおこなわれていない。このため、上述した問題に加えて、予防策の挿入漏れが発生し、運用プロセスの信頼性を著しく低下させるという問題があった。

この発明は、上述した従来技術による問題点を解消するため、予防策の挿入漏れおよび挿入位置を適切にチェックすることで、高信頼の運用プロセスの提供を可能とし、設計作業にかかる作業負担および作業時間を削減することができる検証プログラム、該プログラムを記録した記録媒体、検証装置、および検証方法を提供することを目的とする。

上述した課題を解決し、目的を達成するため、この検証プログラム、該プログラムを記録した記録媒体、検証装置、および検証方法は、検証対象となる一連の処理群の中からメイン処理を検出し、検出されたメイン処理の実行時に発生が予測されるエラーの予防策となるサブ処理を前記一連の処理群の中から検索し、前記メイン処理に対する検索されたサブ処理の実行順序に基づいて、前記一連の処理群における前記サブ処理の挿入位置が正しいか否かを判断し、判断された判断結果を出力することを要件とする。

この検証プログラム、該プログラムを記録した記録媒体、検証装置、および検証方法によれば、運用プロセスに挿入されている予防策の挿入位置が正しいか否かを判断することができる。

この検証プログラム、該プログラムを記録した記録媒体、検証装置、および検証方法によれば、予防策の挿入漏れおよび挿入位置を適切にチェックすることで、高信頼の運用プロセスの提供を可能とし、設計作業にかかる作業負担および作業時間を削減することができるという効果を奏する。

以下に添付図面を参照して、この検証プログラム、該プログラムを記録した記録媒体、検証装置、および検証方法の好適な実施の形態を詳細に説明する。本実施の形態では、ＩＴシステムの運用管理にかかる運用プロセスの適切な挿入位置に、メイン処理の実行時に発生が予測される失敗を予防する予防策が挿入されているか否かをチェックすることで、運用プロセスの信頼性を保証する。

（実施の形態１）
まず、ＩＴシステムの運用管理にかかる運用プロセスについて説明する。運用プロセスとは、ホテルの予約サービスや企業のホームページの閲覧サービスなどのＩＴシステムの運用管理にかかる一連の処理群の実行順序が記述された設計データである。

図１は、運用プロセスの具体例を示すアクティビティ図である。図１において、運用プロセス１００には、ＩＴシステムにおけるパッチ適用作業にかかる一連の処理群の実行順序が示されている。この運用プロセス１００では、実行者（Ｒｏｌｅ）が管理者（符号１０１）と関連部署（符号１０２）の２名存在している。

運用プロセス１００内のパーティションＰａ１に記述されている処理内容は管理者の作業内容であり、パーティションＰａ２に記述されている処理内容は関連部署の作業内容である。運用プロセス１００は、黒丸１０３を開始点として、矢印に従って各処理が実行され、白枠付き黒丸１０４で示す終了点に辿り着くと一連の処理が終了する。

なお、運用プロセス１００内に記述されている各処理の単位をアクションという。各アクションには、アクション名が記述されている。各実行者（Ｒｏｌｅ）は、運用プロセス１００に従って処理を実行することとなる。

一般に、運用プロセス（たとえば、運用プロセス１００）を高信頼に実行するための重要なポイントは、失敗の発生を防ぐことである。すなわち、運用プロセスが高信頼であるためには、過去に起こった失敗についての予防策が挿入された運用プロセスを設計する必要がある。

そこで、実施の形態１では、運用プロセスに予防策が挿入されているかどうかを確認するための手法として、タグ情報を用いた手法を適用する。タグ情報は、運用プロセスの各処理の属性をあらわす情報である。また、１つの処理に複数のタグ情報を付加することができる。ここで、タグ情報の具体例について説明する。

（タグ情報の具体例）
図２は、タグ情報の具体例を示す説明図である。図２において、タグ情報Ｔ１〜Ｔ３は、処理：『パッチ適用』の属性をあらわす情報である。タグ情報Ｔ１は、『パッチ適用』の実行者が『管理者』であることを示している。タグ情報Ｔ２は、『パッチ適用』の処理対象が『ＩＴシステム』であることを示している。タグ情報Ｔ３は、『パッチ適用』の処理種別が『操作』であることを示している。

各処理に付加されるタグ情報の組み合わせは、その処理が実行される状況を特定する。上記例では、タグ情報Ｔ１〜Ｔ３の組み合わせにより、『パッチ適用』は管理者がＩＴシステムに対して操作をおこなう状況で実行される処理であると特定することができる。

（マッピング情報の具体例）
つぎに、検証対象となる運用プロセス内のメイン処理および予防策を特定するために用いられるマッピング情報について説明する。図３は、マッピング情報の具体例を示す説明図である。図３において、マッピング情報３００には、処理と状況と失敗と予防策との間の関連性がモデル化されて示されている。

処理は、各運用プロセスで主目的となるメイン処理である。ここでは、処理Ｔ１〜Ｔ９が示されている。たとえば、処理Ｔ５は、パッチ適用をあらわしている。状況は、各処理が実行される状況である。ここでは、状況Ｓ１〜Ｓ１０が示されている。たとえば、状況Ｓ７は、管理者がＩＴシステムに対して操作をおこなう状況をあらわしている。

失敗は、各処理の実行時に発生した過去の失敗事例である。ここでは、失敗Ｅ１〜Ｅ７が示されている。たとえば、失敗Ｅ３は、保守作業と業務実施のバッティングをあらわしている。予防策は、各失敗を予防するための処理である。ここでは、予防策Ｐ１〜Ｐ１２が示されている。たとえば、予防策Ｐ６は、テスト実行をあらわしている。

このマッピング情報３００を参照して、各処理Ｔ１〜Ｔ９から状況Ｓ１〜Ｓ１０、失敗Ｅ１〜Ｅ７、予防策Ｐ１〜Ｐ１２までの矢印を辿っていくことで、『処理』−『状況』−『失敗』−『予防策』の関連性を特定することができる。

また、マッピング情報３００において、予防策Ｐ１〜Ｐ１２には、各予防策Ｐ１〜Ｐ１２が挿入されるべき運用プロセスにおける挿入フェーズＦ１〜Ｆ５が示されている。ここで、時間の経過に沿って分類された運用プロセス内の各挿入フェーズについて説明する。

図４は、運用プロセスの挿入フェーズを示す説明図である。図４において、フェーズモデル４００には、時間の経過に沿って分類された運用プロセス内の挿入フェーズＦ１〜Ｆ５が示されている。挿入フェーズＦ１は、メイン処理の実行前におこなわれるフェーズ（「開始準備」と表記）である。

挿入フェーズＦ２は、メイン処理の実行段階内で、メイン処理の実行前におこなわれるフェーズ（「実行直前」と表記）である。挿入フェーズＦ３は、メイン処理を実行するフェーズ（「メイン処理」と表記）である。挿入フェーズＦ４は、メイン処理の実行段階内で、メイン処理の実行後におこなわれるフェーズ（「実行直後」と表記）である。

挿入フェーズＦ５は、メイン処理の実行後におこなわれるフェーズ（「終了処理」と表記）である。このように運用プロセスは、『開始準備』→『実行直前』→『メイン処理』→『実行直後』→『終了処理』の段階を踏んでおこなわれる。つまり、各予防策の挿入フェーズＦ１〜Ｆ５から各予防策の実行順序を特定することができる。

実施の形態１では、マッピング情報３００を参照して、運用プロセス内のメイン処理について関連する予防策が運用プロセスに挿入されているか否かを確認する。以下、各処理に付加されたタグ情報を用いて運用プロセスの信頼性（予防策の挿入漏れ、挿入位置）を検証する手法の概要について説明する。

まず、運用プロセス（たとえば、運用プロセス１００）を読み込むことで、運用プロセスの中からマッピング情報３００に登録されているメイン処理を検出する。このあと、メイン処理に付加されているタグ情報から状況を特定する。そして、マッピング情報３００を参照することで、特定された状況で発生が予測される失敗と、その失敗の予防策とを特定する。

つぎに、運用プロセス内の一連の処理群を先頭から読み込むことで、特定された予防策が運用プロセスに挿入されているか否かを判断する。ここで、予防策が挿入されていない場合には、マッピング情報３００を参照して、未挿入の予防策と、その予防策がない場合に発生が予測される失敗を通知する。

さらに、運用プロセスに挿入されていることが確認された予防策の挿入フェーズＦ１〜Ｆ５を参照して、運用プロセス内における各予防策の挿入位置が正しいか否かを判断する。ここで、予防策の挿入位置が誤っている場合には、マッピング情報３００を参照して、挿入位置が誤っている予防策と、その予防策がない場合に発生が予測される失敗を通知する。

また、運用プロセスにおいて、開始（たとえば、図１中黒丸１０３）から終了（たとえば、図１中白枠付き黒丸１０４）に辿り着くまでの途中に、分岐や分流が存在することで経路が複数に分かれる場合には、経路ごとに上述した一連の処理をおこなう。

このようにして、実施の形態１では、設計対象となる運用プロセス内の各メイン処理に対する予防策の挿入漏れおよび挿入位置のチェックをおこなうことにより、高信頼の運用プロセスの提供を可能とし、設計作業にかかる作業負担および作業時間の低減化を図る。

（検証装置のハードウェア構成）
つぎに、本実施の形態にかかる検証装置のハードウェア構成について説明する。図５は、検証装置のハードウェア構成を示すブロック図である。

図５において、検証装置は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）５０１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）５０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）５０３と、磁気ディスクドライブ５０４と、磁気ディスク５０５と、光ディスクドライブ５０６と、光ディスク５０７と、ディスプレイ５０８と、Ｉ／Ｆ（インターフェース）５０９と、キーボード５１０と、マウス５１１と、スキャナ５１２と、プリンタ５１３と、を備えている。また、各構成部はバス５００によってそれぞれ接続されている。

ここで、ＣＰＵ５０１は、検証装置の全体の制御を司る。ＲＯＭ５０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ５０３は、ＣＰＵ５０１のワークエリアとして使用される。磁気ディスクドライブ５０４は、ＣＰＵ５０１の制御にしたがって磁気ディスク５０５に対するデータのリード／ライトを制御する。磁気ディスク５０５は、磁気ディスクドライブ５０４の制御で書き込まれたデータを記憶する。また、磁気ディスク５０５として、ハードディスク、フレキシブルディスクなどを採用することができる。

光ディスクドライブ５０６は、ＣＰＵ５０１の制御にしたがって光ディスク５０７に対するデータのリード／ライトを制御する。光ディスク５０７は、光ディスクドライブ５０６の制御で書き込まれたデータを記憶したり、光ディスク５０７に記憶されたデータをコンピュータ装置に読み取らせたりする。

また、光ディスク５０７として、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｋ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、ＭＯ（Ｍａｇｎｅｔｏ Ｏｐｔｉｃａｌ）、メモリーカードなどを採用することができる。ディスプレイ５０８は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。このディスプレイ５０８は、たとえば、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）、ＴＦＴ（Ｔｈｉｎ Ｆｉｌｍ Ｔｒａｎｓｉｓｔｏｒ）液晶ディスプレイ、プラズマディスプレイなどを採用することができる。

Ｉ／Ｆ５０９は、通信回線を通じてインターネットなどのネットワーク５１４に接続され、このネットワーク５１４を介して他のコンピュータ装置に接続される。そして、Ｉ／Ｆ５０９は、ネットワーク５１４と内部のインターフェースを司り、外部装置からのデータの入出力を制御する。Ｉ／Ｆ５０９には、たとえば、モデムやＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）アダプタなどを採用することができる。

キーボード５１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。また、タッチパネル式の入力パッドやテンキーなどであってもよい。マウス５１１は、カーソルの移動や範囲選択、あるいはウィンドウの移動やサイズの変更などをおこなう。ポインティングデバイスとして同様に機能を備えるものであれば、トラックボールやジョイスティックなどであってもよい。

スキャナ５１２は、画像を光学的に読み取りコンピュータ装置内に画像データを取り込む。なお、スキャナ５１２は、ＯＣＲ（Ｏｐｔｉｃａｌ Ｃｈａｒａｃｔｅｒ Ｒｅａｄｅｒ）機能を持たせてもよい。また、プリンタ５１３は、画像データや文書データを印刷する。プリンタ５１３には、たとえば、レーザプリンタやインクジェットプリンタを採用することができる。

（検証装置の機能的構成）
つぎに、検証装置の機能的構成について説明する。図６は、検証装置の機能的構成を示すブロック図である。図６において、検証装置は、入力部６０１と、検出部６０２と、検索部６０３と、判断部６０４と、出力部６０５と、探索部６０６と、を備えている。

これら各機能６０１〜６０６は、検証装置のＲＯＭ５０２やＲＡＭ５０３などの記憶部に記憶された当該機能６０１〜６０６に関するプログラムをＣＰＵ５０１に実行させることにより、または、入出力Ｉ／Ｆにより、当該機能を実現することができる。また、各機能６０１〜６０６からの出力データは上記記憶部に保持される。また、図６中矢印で示した接続先の機能は、接続元の機能からの出力データを記憶部から読み込んで、当該機能に関するプログラムをＣＰＵ５０１に実行させるものとする。

まず、入力部６０１は、検証対象となる運用プロセスの入力を受け付ける機能を有する。運用プロセスは、システムの運用管理にかかる一連の処理群の実行順序が記述された設計データであり、たとえば、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）によって記述されている。運用プロセスは、検証装置に直接入力することとしてもよく、また、外部のコンピュータ装置から取得することとしてもよい。

ここで、図１に示した運用プロセス１００に関する設計データについて説明する。図７は、設計データの具体例を示す説明図である。図７において、設計データ７００には、運用プロセス１００内の一連の処理群の実行順序がＸＭＬにより記述されている。この設計データ７００は、ＩＴシステムのパッチ適用アクティビティに関する運用プロセスをあらわしている。

なお、図示は省略するが、処理にタグ情報（たとえば、図２に示したタグ情報Ｔ１〜Ｔ３）が付加されている場合には、そのタグ情報をあらわすＸＭＬ記述が設計データ７００に追加される。これにより、運用プロセス１００内の各処理の属性（実行者、処理対象、処理種別など）を認識することができる。

図６の説明に戻り、検出部６０２は、検証対象となる一連の処理群の中からメイン処理を検出する機能を有する。メイン処理とは、各運用プロセスの主目的となる単一の処理である。具体的には、検出部６０２は、システムの管理者により作成されたマッピング情報を参照して、運用プロセスの中から任意のメイン処理を検出することができる。

マッピング情報は、『処理』−『状況』−『失敗』−『予防策』の関連を特定可能な情報であり、システムの管理者により作成される。また、マッピング情報は、たとえば、検証対象となる運用プロセスを記述する言語（たとえば、ＸＭＬ）と同一の言語を用いて記述される。なお、マッピング情報は、磁気ディスク５０５や光ディスク５０７などの記憶部に保持されていてもよく、また、検証装置に直接入力することで取得することとしてもよい。

より具体的には、たとえば、検出部６０２は、入力部６０１によって入力された設計データ７００を読み込んで、マッピング情報３００（図３参照）を参照することにより、運用プロセス１００の中からメイン処理を検出する。ここでは、マッピング情報３００に登録されている処理Ｔ５と一致する「パッチ適用」をメイン処理として検出する。

検索部６０３は、検出部６０２によって検出されたメイン処理の実行時に発生が予測されるエラーの予防策となるサブ処理を一連の処理群の中から検索する機能を有する。予防策となるサブ処理とは、予防策となるアクションを実行する処理である。以降において、実施の形態１では、「予防策となるサブ処理」を単に「予防策」と表記する。

予防策を検索する場合、まず、検出部６０２によって検出されたメイン処理に付加されているタグ情報から状況を特定する。たとえば、メイン処理に、図２に示したタグ情報Ｔ１〜Ｔ３が付加されているとすると、管理者がＩＴシステムに対して操作をおこなう状況Ｓ７が特定される。

つぎに、マッピング情報３００を参照して、特定された状況で発生が予測される失敗（エラー）を特定する。ここでは、状況Ｓ７と関連付けられている失敗Ｅ３〜Ｅ６が特定される。さらに、マッピング情報３００を参照して、特定された失敗と関連付けられている予防策を特定する。ここでは、失敗Ｅ３〜Ｅ６と関連付けられている予防策Ｐ３〜Ｐ１０が特定される（ここで、後述する予防策リストが作成される）。

このあと、検出部６０２により、運用プロセス１００の中から任意の処理を検出する。このとき、運用プロセス１００の実行順序に従って順次処理を検出することとしてもよい。そして、検索部６０３により、検出部６０２によって検出された処理と予防策Ｐ３〜Ｐ１０とを照らし合わせることで、メイン処理（パッチ適用）の実行時に発生が予測されるエラーの予防策を検索する。

ここで、運用プロセスに挿入すべき予防策がリスト化された予防策リストについて説明する。図８は、予防策リストの一例を示す説明図である。図８において、予防策リスト８００には、検出部６０２によって検出されたメイン処理の実行時に発生が予測される失敗ごとに、予防策と挿入状況に関する情報が示されている。

具体的には、失敗Ｅ３，Ｅ５，Ｅ６（失敗Ｅ４は予防策が未登録）ごとに、予防策を識別する予防策ＩＤと、予防策のアクション名と、予防策の挿入フェーズとが示されている。挿入状況には、検索部６０３によって検索されていない未検索の予防策は「未挿入」と表記され、検索部６０３によって検索された検索済みの予防策は「挿入済」と表記される。

判断部６０４は、検出部６０２によって検出されたメイン処理が、属性情報（たとえば、タグ情報Ｔ１〜Ｔ３）から特定される状況で実行された場合に発生したエラーの予防策のうち、検索部６０３によって検索されていない未検索の予防策があるか否かを判断する機能を有する。具体的には、たとえば、図８に示した予防策リスト８００を参照して、「未挿入」の予防策があるか否かを判断する。

また、判断部６０４は、メイン処理に対する検索部６０３によって検索された予防策の実行順序に基づいて、一連の処理群における予防策の挿入位置が正しいか否かを判断する機能を有する。具体的には、たとえば、予防策の挿入フェーズＦ１〜Ｆ５に基づいて、運用プロセス１００における予防策の挿入位置が正しいか否かを判断する。

より詳細に説明すると、予防策の挿入フェーズから得られる以下の原則に基づいて、挿入位置が正しいか否かを判断する。原則１−１は、挿入フェーズが、開始準備（挿入フェーズＦ１）や実行直前（挿入フェーズＦ２）となる予防策は、必ずメイン処理（挿入フェーズＦ３）の前に挿入される。原則１−２は、挿入フェーズが、実行直後（挿入フェーズＦ４）や終了処理（挿入フェーズＦ５）の予防策は、必ずメイン処理（挿入フェーズＦ３）の後に挿入される。

判断部６０４は、たとえば、メイン処理と予防策との位置関係が、上記原則１−１または原則１−２を満たしているか否かを判断することで、挿入位置が正しいか否かを判断することができる。なお、検証対象となる一連の処理群の先頭から読み込むことで、読み込み順をもとに各処理の挿入位置を特定することとしてもよい。

また、判断部６０４は、検索部６０３によってメイン処理の実行時に発生が予測されるエラーの第１および第２の予防策が検出された場合、第２の予防策に対する第１の予防策の実行順序に基づいて、一連の処理群における第１の予防策の挿入位置が正しいか否かを判断する機能を有する。具体的には、たとえば、第１の予防策の挿入フェーズＦ１〜Ｆ５と、第２の予防策の挿入フェーズＦ１〜Ｆ５とに基づいて、運用プロセス１００における予防策の挿入位置が正しいか否かを判断する。

より詳細に説明すると、各予防策の挿入フェーズから得られる以下の原則に基づいて、挿入位置が正しいか否かを判断する。まず、原則２−１は、挿入フェーズが開始準備（挿入フェーズＦ１）の予防策は、実行直前（挿入フェーズＦ２）、実行直後（挿入フェーズＦ４）、終了処理（挿入フェーズＦ５）が挿入フェーズとなっている予防策より前に挿入される。

原則２−２は、挿入フェーズが実行直前（挿入フェーズＦ２）の予防策は、開始準備（挿入フェーズＦ１）が挿入フェーズとなる予防策よりも後ろでかつ、実行直後（挿入フェーズＦ４）、終了処理（挿入フェーズＦ５）が挿入フェーズとなっている予防策よりも前に挿入される。

原則２−３は、挿入フェーズが実行直後（挿入フェーズＦ４）の予防策は、開始準備（挿入フェーズＦ１）、実行直前（挿入フェーズＦ２）が挿入フェーズとなる予防策よりも後ろでかつ、終了処理（挿入フェーズＦ５）が挿入フェーズとなっている予防策よりも前に挿入される。

原則２−４は、挿入フェーズが終了処理（挿入フェーズＦ５）の予防策は、開始準備（挿入フェーズＦ１）、実行直前（挿入フェーズＦ２）、実行直後（挿入フェーズＦ４）が挿入フェーズとなっている予防策よりも後ろに挿入される。判断部６０４は、原則２−１〜２−４のいずれかに違反している場合、予防策の挿入位置が誤っていると判断する。

ここで上記原則違反の具体例について説明する。図９は、原則違反の具体例を示す説明図である。図９において、パターンＡ，Ｂには、それぞれ異なる運用プロセスの一部の処理群が抜粋されて示されている。なお、図９中、黒丸は運用プロセスの開始点、白枠付き黒丸は運用プロセスの終了点、Ｆ１〜Ｆ４は挿入フェーズをあらわしている。

パターンＡでは、挿入フェーズＦ４（実行直後）の予防策（処理９１１）が挿入フェーズＦ３（メイン処理）のメイン処理（処理９１２）よりも前に挿入されているため、上記原則１−２に違反している。また、パターンＢでは、挿入フェーズＦ２（実行直前）の予防策（処理９２１）の後に挿入フェーズＦ１（開始準備）の予防策（処理９２２）が挿入されているため、上記２−１，２−２に違反している。

出力部６０５は、判断部６０４によって判断された判断結果を出力する機能を有する。出力部６０５による出力形式は、ディスプレイ５０８での画面表示、プリンタ５１３での印刷出力、メモリへのデータ出力（保存）、外部のコンピュータ装置への送信のいずれであってもよい。

具体的には、たとえば、判断部６０４によって挿入位置が誤っていると判断された予防策を特定するエラーメッセージを出力することとしてもよく、また、実行順序が誤っている第１の予防策と第２の予防策とを特定するエラーメッセージを出力することとしてもよい。

ここで、実行順序が誤っている第１および第２の予防策を特定する挿入違反リストの具体例について説明する。図１０は、挿入違反リストの具体例を示す説明図である。図１０において、挿入違反リスト１０００には、挿入違反となっている予防策と、違反タイプと、違反相手となる予防策とが示されている。

設計者は、この挿入違反リスト１０００を参照することで、予防策「事後バックアップ」が上述した原則２−３違反となっており、その違反相手は「業務動作監視」であることを把握することができる。この場合、設計者は、運用プロセス１００内の「事後バックアップ」と「業務動作監視」との位置関係を変更する設計データの修正をおこなうこととなる。

また、出力部６０５は、検索部６０３によって検索されなかった未検索の予防策を特定する結果が反映された検索結果リストを出力することとしてもよい。このとき、検索部６０３によって検索されなかった未検索のサブ処理を特定するエラーメッセージを出力することとしてもよい。

ここで、未検索の予防策を特定する予防策リストの具体例について説明する。図１１は、予防策リストの具体例を示す説明図である。図１１において、予防策リスト１１００には、検出部６０２によって検出されたメイン処理の実行時に発生が予測される失敗ごとに、予防策と挿入状況に関する情報が示されている。

具体的には、検索部６０３によって検索されなかった未検索の予防策の挿入状況が「未挿入」となっている。設計者は、この予防策リスト１１００を参照することで、運用プロセス１００に挿入されるべき未挿入の予防策「テスト実行」を把握することができる。この場合、設計者は、「テスト実行」を運用プロセス１００に追加する設計データの修正をおこなうこととなる。

また、出力部６０５は、予防策の実行順序が誤っているまたは／および未検索の予防策が存在することにより、発生が予測される失敗を特定するエラーメッセージを出力することとしてもよい。図１２は、エラーメッセージの具体例を示す説明図である。

図１２において、エラーメッセージ１２００には、「事後バックアップ」と「業務動作監視」との位置関係が誤っている旨のメッセージとともに、「異常発生の検知漏れ」の発生が予測される旨のメッセージが示されている。さらに、「テスト実行」が挿入されていない旨のメッセージとともに、「異常発生の検知漏れ」の発生が予測される旨のメッセージが示されている。

図６の説明に戻り、探索部６０６は、検証対象となる一連の処理群のうち、最初に実行される処理から最後に実行される処理に辿り着くまでの経路を探索する機能を有する。具体的には、運用プロセス内のすべての分岐経路を探索する。ここで、探索部６０６による探索結果の具体例について説明する。

図１３は、複数の経路が存在する運用プロセスの具体例を示すアクティビティ図である。図１３において、運用プロセス１３００内には、探索部６０６によって探索された経路Ｐ１，Ｐ２が示されている。このように、運用プロセス１３００内に複数の経路Ｐ１，Ｐ２が存在する場合には、経路Ｐ１，Ｐ２ごとに、上記検出部６０２、検索部６０３、判断部６０４および出力部６０５による一連の処理を実行することとなる。

このとき、経路Ｐ１，Ｐ２ごとの運用プロセス１３００を作成して、上記検出部６０２、検索部６０３、判断部６０４および出力部６０５による一連の処理を実行する。具体的には、入力部６０１によって入力された運用プロセス１３００に関する設計データをコピーすることで、経路Ｐ１，Ｐ２ごとの設計データを作成することができる。

このように、探索部６０６によって探索された経路Ｐ１，Ｐ２ごとに、予防策の挿入漏れ、挿入位置をチェックすることで、運用プロセス１３００に潜む失敗の可能性を漏れなく検証することができる。

（検証装置の検証処理手順）
つぎに、実施の形態１にかかる検証装置の検証処理手順について説明する。図１４は、実施の形態１にかかる検証装置の検証処理手順の一例を示すフローチャートである。図１４のフローチャートにおいて、まず、入力部６０１により、検証対象となる運用プロセスに関する設計データの入力を受け付けたか否かを判断する（ステップＳ１４０１）。

ここで、設計データが入力されるのを待って（ステップＳ１４０１：Ｎｏ）、入力された場合（ステップＳ１４０１：Ｙｅｓ）、検出部６０２により、マッピング情報３００を参照して、運用プロセス内の一連の処理群の中からメイン処理を検出する（ステップＳ１４０２）。

このあと、マッピング情報３００を参照して、検出部６０２によって検出されたメイン処理に付加されているタグ情報から特定される状況で発生が予測される失敗と、その失敗の予防策とを特定し（ステップＳ１４０３）、予防策リストおよび挿入違反リストを作成する（ステップＳ１４０４）。なお、ステップＳ１４０４において作成された予防策リストおよび挿入違反リストは初期化されている。

つぎに、検出部６０２により、一連の処理群の実行順序に従って、当該一連の処理群の中から処理を検出し（ステップＳ１４０５）、検索部６０３により、検出された処理が予防策リストに含まれているか否かを判断する（ステップＳ１４０６）。ここで、予防策リストに含まれている場合（ステップＳ１４０６：Ｙｅｓ）、予防策リスト内の該当する予防策の挿入状況を「未挿入」から「挿入済」に更新する（ステップＳ１４０７）。

このあと、判断部６０４により、ステップＳ１４０２において検出されたメイン処理に対する、ステップＳ１４０５において検出された予防策の実行順序は正しいか否かを判断する（ステップＳ１４０８）。ここで、実行順序が誤っていると判断された場合（ステップＳ１４０８：Ｎｏ）、挿入違反リストを更新して（ステップＳ１４０９）、ステップＳ１４１０に移行する。具体的には、挿入違反となっている予防策を挿入違反リストに追加する。

また、ステップＳ１４０８において、実行順序が正しいと判断された場合（ステップＳ１４０８：Ｙｅｓ）、判断部６０４により、予防策リスト内の挿入状況が「挿入済」の予防策に対する、ステップＳ１４０５において検出された予防策の実行順序は正しいか否かを判断する（ステップＳ１４１０）。

ここで、実行順序が誤っていると判断された場合（ステップＳ１４１０：Ｎｏ）、挿入違反リストを更新して（ステップＳ１４１１）、一連の処理群の中から抽出されていない未検出の処理があるか否かを判断する（ステップＳ１４１２）。一方、実行順序が正しいと判断された場合（ステップＳ１４１０：Ｙｅｓ）、ステップＳ１４１２に移行する。また、ステップＳ１４０６において、予防策リストに含まれていない場合には（ステップＳ１４０６：Ｎｏ）、ステップＳ１４１２に移行する。

ステップＳ１４１２において、未検出の処理がある場合（ステップＳ１４１２：Ｙｅｓ）、ステップＳ１４０５に戻って一連の処理を繰り返す。一方、未検出の処理がない場合（ステップＳ１４１２：Ｎｏ）、出力部６０５により、予防策リストと挿入違反リストとを出力して（ステップＳ１４１３）、本フローチャートによる一連の処理を終了する。

以上説明したように、実施の形態１によれば、検証対象となる運用プロセスに挿入されている予防策の挿入位置が正しいか否かを判断することができる。さらに、運用プロセスに挿入されるべき必須の予防策のうち、挿入されていない未挿入の予防策を特定することができる。

また、運用プロセス内に存在する経路ごとに、予防策の挿入漏れおよび挿入位置をチェックすることで、運用プロセスに潜む失敗の可能性を漏れなく検証することができる。このように、予防策の挿入漏れおよび挿入位置を適切にチェックすることで、高信頼の運用プロセスの提供を可能とし、設計作業にかかる作業負担および作業時間を削減することができる。

（実施の形態２）
つぎに、実施の形態２について説明する。実施の形態１では、部品化された処理（タグ情報が付加、マッピング情報に登録済み）を用いて運用プロセスを設計した場合について説明したが、実施の形態２では、部品化されていない処理を用いて運用プロセスを設計した場合について説明する。なお、実施の形態１で示した構成と同一構成については同一符号を付し、その説明を省略する。

実施の形態１では、部品化された処理に限り、予防策の挿入漏れや挿入違反をチェックすることができる。ところが、たとえば、部品化されていない処理のアクション名は、設計者により任意に記述された名称となるため、マッピング情報に登録されているメイン処理や予防策と一致しているか否かの判断ができない。

そのため、信頼性のチェックを実行しても、部品化された処理以外のアクションは無視することになり、高信頼性であることを確認することはできない。一方で、部品化された処理を用いて設計されていない運用プロセスの高信頼性を確認するためには、マッピング情報に必要となる部品を登録し、その部品を用いて運用プロセスを設計しなおす必要がある。これでは設計作業にかかる作業コストが増大してしまう。

一般に、既存の運用プロセスは部品化された処理を用いて設計されていないため、実施の形態１で説明した手法では、作業コストを増大させて運用プロセスの高信頼性を確認するか、作業コストを抑えて運用プロセスの信頼性を犠牲にするかのどちらかを選ぶしかなかった。

そこで、実施の形態２では、部品化されていない処理を用いて設計された運用プロセスに挿入されている予防策を推測して検出することで、運用プロセスの信頼性を検証する手法を提案する。予防策の推測には、推測対象となる予防策を特徴付けるキー情報を用いる。キー情報には、設計者により指定されるものと、運用プロセスから抽出するものとがある。

ここで、予防策を特徴付けるキー情報について説明する。実施の形態１では、予防策は単一のアクションとしてみなしていたが、予防策の中には他の処理や予防策と組み合わせて挿入されるものもある。さらに、その組み合わせには特徴がある。そこで、実施の形態２では、予防策を複数の要素から構成されるパターンとして扱う。

パターンとは、連続する複数の処理や、離れた位置にある処理の組み合わせなどである。また、予防策を特徴付けるキー情報には、『適用先』、『キーアクション』および『キー形状』に関する情報が含まれている。まず、『適用先』は、予防策が、どのメイン処理が実行される運用プロセスで適用されるべきかを示す情報である。なお、適用先のメイン処理は複数でもよい。

つぎに、『キーアクション』は、予防策の中で重要な処理となるキーアクションを示す情報である。具体的には、キーアクションを特徴付けるアクション内容、実行者、処理対象、挿入フェーズに関する情報が含まれている。アクション内容は、アクションの内容である。実行者は、キーアクションを実行する実行者（Ｒｏｌｅ）である。処理対象は、キーアクションが対象としているリソース（サーバ、人など）である。挿入フェーズは、キーアクションが適用されるべき運用プロセスのフェーズである。

最後に、『キー形状』は、パターンの形状を特徴付ける情報であり、以下の２つの形状に分類される。１つ目は、キーアクションと関連するアクションが連続しており、それぞれの実行者（Ｒｏｌｅ）が異なる形状（以下、「Ｒｏｌｅ越え」という）である。つまり、「Ｒｏｌｅ越え」では、キーアクションから関連するアクションへの遷移をあらわす矢印が運用プロセス内のパーティションをまたがることになる。

２つ目は、キーアクションの実行時に発生する異常状態と、その異常状態発生時の対処とからなる形状（以下、「異常系」という）である。「異常系」は、その異常状態の有効範囲（領域）によって示される場合もある。ここで、キー形状の予防策の一例について説明する。

図１５は、キー形状の予防策の一例を示す説明図である。図１５において、予防策１５１０は、キー形状αが「Ｒｏｌｅ越え」の予防策である。予防策１５１０のキーアクションは「作業開始連絡」である。キー形状αは、キーアクション「作業開始連絡」の実行者（管理者）のパーティションＰａ１と関連アクション「通知確認」の実行者（関連部署）のパーティションＰａ２をまたがっている。

予防策１５２０は、キー形状βが「異常系」の予防策である。予防策１５２０のキーアクションは「利用状況確認」であり、「利用者あり」が異常状態発生をあらわすイベントである。また、キー形状βは異常状態の有効範囲をあらわしており、有効範囲内に記述されたアクションは異常状態「利用者あり」の発生により処理が中断されることになる。

実施の形態２では、運用プロセスに必要な予防策をキー情報と関連付けて予め予防策リストに登録する。予防策リストは、たとえば、図５に示した磁気ディスク５０５や光ディスク５０７などの記憶部によりその機能を実現することができる。ここで、予防策リストの一例について説明する。

図１６は、予防策リストの一例を示す説明図である。図１６において、予防策リスト１６００には、予防策ごとに、予防策ＩＤ、予防策名、キー形状、キーアクション、適用先に関する情報が登録されている。予防策ＩＤは、予防策を識別する識別子である。予防策名は、予防策の名称である。キー形状、キーアクションおよび適用先は、上述したキー情報に含まれる情報である。

ここで、予防策「利用確認」を例に挙げると、予防策ＩＤは「２」、キー形状は「異常系」、アクション内容は「利用状況確認」、実行者は「メイン処理と同じ」、処理対象は「システム全体」、挿入フェーズは「開始準備」、適用先は「パッチ適用」と「ＭＷ設定変更」と「メモリ増設」である。

信頼性の検証時には、たとえば、予防策リスト１６００を参照することで、検証対象の運用プロセス内のメイン処理が適用先となる予防策を特定し、その運用プロセスの必須予防策リスト（実施の形態１で説明した予防策リスト８００に相当）を作成することとなる。

ここで、必須予防策リストの具体例について説明する。図１７は、必須予防策リストの具体例を示す説明図である。図１７において、必須予防策リスト１７００には、予防策ごとに、予防策ＩＤ、予防策名、キー形状、キーアクション、挿入状況に関する情報が登録されている。具体的には、図１６に示した予防策リスト１６００を参照することで、「パッチ適用」が適用先となる予防策が登録されている。

ここで、予防策「業務動作監視」を例に挙げると、予防策ＩＤは「６」、キー形状は「異常系」、アクション内容は「動作監視」、実行者は「メイン処理と同じ」、処理対象は「システム全体」、挿入フェーズは「終了処理」、挿入状況は「未挿入」である。

つぎに、予防策の推定手法について説明する。まず、検証対象となる運用プロセス内の処理を特徴付けるキー情報を特定する。キー情報は、運用プロセスに関する設計データから特定する、または、設計者により事前に指定された情報から特定する。設計者により事前に指定される情報は、運用プロセス内のメイン処理と各アクションの処理対象である。

具体的には、検出部６０２により、設計者によって事前に指定された情報を用いてメイン処理を特定することで、一連の処理群の中からメイン処理を検出する。さらに、運用プロセスに関する設計データを用いて、運用プロセス内のキー形状を検出する。たとえば、各実行者のパーティションをまたがる処理の遷移を示す矢印（図１５に示したキー形状α）を検出する。

ここで、キー形状αが特定された場合、「Ｒｏｌｅ越え」の予防策が挿入されている可能性有りと判断する。また、運用プロセスにおける、異常状態発生をあらわすイベント（図１５に示した「利用者あり」）や異常状態の有効範囲（図１５に示したキー形状β）を特定する。ここで、異常状態発生をあらわすイベントやキー形状βが特定された場合、「異常系」の予防策が挿入されている可能性有りと判断する。

最後に、キーアクションを推定する。キーアクションの特定にはキー形状を利用する。キー形状はそのパターン（形状）が決まっているため、キー形状の範囲を特定することで、その範囲のどの位置の要素がキーアクションとなるか特定可能である。

たとえば、キー形状αが検出された場合、そのキーアクションは、実行者のパーティションをまたがる処理の遷移を示す矢印（キー形状α）の直前のアクションとなる。つぎに、特定されたキーアクションのキー情報を特定する。具体的には、アクション内容と実行者と処理対象とを特定する。なお、挿入フェーズは、予防策推定後の信頼性の検証作業で利用する情報のため、予防策推定時に特定する必要はない。

より具体的には、アクション内容は、キーアクション名から特定する。実行者は、キーアクションが属するパーティションがどの実行者のパーティションなのかを判断することで特定する。処理対象は、設計者により事前に指定された情報から特定する。そして、予防策リスト１６００を参照して、特定されたキー情報と一致するキー情報の予防策があるか否かを判断する。

ここで、一致するキー情報がある場合には、その予防策が検証対象となる運用プロセス内に挿入されていると判断する。なお、上述したキー形状を用いてキーアクションを特定し、予防策リスト１６００を参照することで、キーアクションのキー情報から一致する予防策を検索する一連の処理は、検索部６０３によって実行される。

以下、予防策を推定する具体例について説明する。図１８は、運用プロセスの一部を抜粋して示すアクティビティ図である。図１８において、運用プロセス１８００には、パッチ適用作業にかかる一連の処理群（ここでは、アクションＡ１〜Ａ３）の実行順序が一部抜粋して示されている。

運用プロセス１８００内の予防策の推定に必要となる、設計者により事前に指定される情報は、メイン処理となるアクションおよびアクションの処理対象である。ここでは、メイン処理となるアクションＡ３：「パッチ適用」とともに、アクションＡ１：「作業開始連絡」の処理対象である「関連部署」と、アクションＡ３：「パッチ適用」の処理対象である「サーバ」が指定されているとする。

まず、設計者により事前に指定された情報を用いて、運用プロセス１８００の中からメイン処理を検出するとともに、アクションＡ１，Ａ３の処理対象を特定する。このあと、運用プロセス１８００の中からキー形状αまたはβ（図１５参照）を検出する。ここでは、アクションＡ１からアクションＡ２への処理の遷移を示すキー形状αが検出される。そのため、「Ｒｏｌｅ越え」の予防策が挿入されている可能性有りと判断する。

つぎに、予防策のキーアクションを特定する。ここでは、キー形状αの直前に挿入されているアクションＡ１：「作業開始連絡」をキーアクションとして特定する。さらに、アクションＡ１をキーアクションとして、キー情報（アクション内容、実行者、処理対象）を特定する。

具体的には、アクション名からアクション内容：「作業開始連絡」を特定し、アクションＡ１が属するパーティションから実行者：「管理者」を特定し、設計者から事前に指定された情報から処理対象：「関連部署」を特定する。つぎに、特定されたキー情報から、図１６に示した予防策リスト１６００に該当する予防策が登録されているか否かを判断する。

ここでは、予防策ＩＤ１の「開始連絡」が該当している。具体的には、キーアクションのアクション内容は「作業開始通知」、実行者はメイン処理と同じ、すなわち上記例では「管理者」となるため、特定されたキー情報と一致する。したがって、運用プロセス１８００には予防策として「開始連絡」が挿入されていると推定することができる。なお、予防策を推定したあとは、実施の形態１で説明した検証手法を用いて運用プロセスの信頼性の検証をおこなうことができる。

（検証装置の検証処理手順）
つぎに、実施の形態２にかかる検証装置の検証処理手順について説明する。図１９−１および図１９−２は、実施の形態２にかかる検証装置の検証処理手順の一例を示すフローチャートである。図１９−１のフローチャートにおいて、まず、入力部６０１により、検証対象となる運用プロセスに関する設計データの入力を受け付けたか否かを判断する（ステップＳ１９０１）。

ここで、設計データが入力されるのを待って（ステップＳ１９０１：Ｎｏ）、入力された場合（ステップＳ１９０１：Ｙｅｓ）、検出部６０２により、設計者により事前に指定された情報を用いて、運用プロセス内の一連の処理群の中からメイン処理を検出する（ステップＳ１９０２）。

このあと、予防策リスト１６００を参照して、検出部６０２によって検出されたメイン処理が適用先となる予防策を特定し（ステップＳ１９０３）、必須予防策リストおよび挿入違反リストを作成する（ステップＳ１９０４）。なお、ステップＳ１９０４において作成された必須予防策リストおよび挿入違反リストは初期化されている。

つぎに、検出部６０２により、一連の処理群の実行順序に従って、当該一連の処理群の中からキー形状を検出し（ステップＳ１９０５）、検索部６０３により、検出されたキー形状からキーアクションを特定する（ステップＳ１９０６）。さらに、予防策リスト１６００を参照して、特定されたキーアクションから予防策を特定して（ステップＳ１９０７）、図１９−２に示すステップＳ１９０８に移行する。

そして、図１９−１のステップＳ１９０４において作成された必須予防策リストを参照して、図１９−１のステップＳ１９０７において特定された予防策が必須予防策か否かを判断する（ステップＳ１９０８）。ここで、必須予防策と判断された場合（ステップＳ１９０８：Ｙｅｓ）、必須予防策リスト内の該当する予防策の挿入状況を「未挿入」から「挿入済」に更新する（ステップＳ１９０９）。

このあと、判断部６０４により、ステップＳ１９０２において検出されたメイン処理に対する、ステップＳ１９０７において特定された予防策の実行順序は正しいか否かを判断する（ステップＳ１９１０）。ここで、実行順序が誤っていると判断された場合（ステップＳ１９１０：Ｎｏ）、挿入違反リストを更新して（ステップＳ１９１１）、ステップＳ１９１２に移行する。具体的には、挿入違反となっている予防策を挿入違反リストに追加する。

また、ステップＳ１９１０において、実行順序が正しいと判断された場合（ステップＳ１９１０：Ｙｅｓ）、判断部６０４により、必須予防策リスト内の挿入状況が「挿入済」の予防策に対する、ステップＳ１９０７において特定された予防策の実行順序は正しいか否かを判断する（ステップＳ１９１２）。

ここで、実行順序が誤っていると判断された場合（ステップＳ１９１２：Ｎｏ）、挿入違反リストを更新して（ステップＳ１９１３）、一連の処理群の中から抽出されていない未検出のキー形状があるか否かを判断する（ステップＳ１９１４）。一方、実行順序が正しいと判断された場合（ステップＳ１９１２：Ｙｅｓ）、ステップＳ１９１４に移行する。また、ステップＳ１９０８において、必須予防策ではないと判断された場合（ステップＳ１９０８：Ｎｏ）、ステップＳ１９１４に移行する。

ステップＳ１９１４において、未検出のキー形状がある場合（ステップＳ１９１４：Ｙｅｓ）、図１９−１のステップＳ１９０５に戻って一連の処理を繰り返す。一方、未検出のキー形状がない場合（ステップＳ１９１４：Ｎｏ）、出力部６０５により、必須予防策リストと挿入違反リストとを出力して（ステップＳ１９１５）、本フローチャートによる一連の処理を終了する。

以上説明したように、実施の形態２によれば、部品化されていない予防策を推定することで、その予防策の運用プロセスにおける挿入位置が正しいか否かを判断することができる。さらに、運用プロセスに挿入されるべき必須の予防策のうち、挿入されていない未挿入の予防策を特定することができる。

これにより、既存の運用プロセスにおける予防策の挿入漏れおよび挿入位置を適切にチェックすることができるため、高信頼の運用プロセスの提供を可能とし、設計作業にかかる作業負担および作業時間を削減することができる。このとき、部品化された処理を用いた運用プロセスの再設計が不要のため、設計コストを削減することができる。

なお、実施の形態１，２で説明した検証方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーションなどのコンピュータで実行することにより実現することができる。このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。またこのプログラムは、インターネットなどのネットワークを介して配布することが可能な伝送媒体であってもよい。

また、実施の形態１，２で説明した検証装置は、スタンダードセルやストラクチャードＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）などの特定用途向けＩＣ（以下、単に「ＡＳＩＣ」と称す。）やＦＰＧＡなどのＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）によっても実現することができる。具体的には、たとえば、上述した検証装置の機能部６０１〜６０６をＨＤＬ記述によって機能定義し、そのＨＤＬ記述を論理合成してＡＳＩＣやＰＬＤに与えることにより、検証装置を製造することができる。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）システムの運用管理にかかる運用プロセスの信頼性を検証するコンピュータを、
検証対象となる一連の処理群の中からメイン処理を検出する検出手段、
前記検出手段によって検出されたメイン処理の実行時に発生が予測されるエラーの予防策となるサブ処理を前記一連の処理群の中から検索する検索手段、
前記メイン処理に対する前記検索手段によって検索されたサブ処理の実行順序に基づいて、前記一連の処理群における前記サブ処理の挿入位置が正しいか否かを判断する判断手段、
前記判断手段によって判断された判断結果を出力する出力手段、
として機能させることを特徴とする検証プログラム。

（付記２）前記判断手段は、
前記検索手段によって前記メイン処理の実行時に発生が予測されるエラーの予防策となる第１および第２のサブ処理が検出された場合、前記第２のサブ処理に対する前記第１のサブ処理の実行順序に基づいて、前記一連の処理群における前記第１のサブ処理の挿入位置が正しいか否かを判断することを特徴とする付記１に記載の検証プログラム。

（付記３）前記検出手段は、
特定の状況で実行されたメイン処理と、前記特定の状況で前記メイン処理が実行された場合に発生したエラーの予防策となるサブ処理とを関連付けて保持するテーブルを参照して、前記一連の処理群の中からメイン処理を検出し、
前記検索手段は、
前記テーブルを参照して、前記メイン処理に付加されている属性情報から特定される状況で前記メイン処理が実行された場合に発生したエラーの予防策となるサブ処理を、前記一連の処理群の中から検索することを特徴とする付記１または２に記載の検証プログラム。

（付記４）前記属性情報は、前記メイン処理の処理内容、実行者、処理対象および処理種別に関する情報を含み、
前記状況は、前記属性情報に含まれる前記メイン処理の処理内容、実行者、処理対象および処理種別から特定される状況であることを特徴とする付記３に記載の検証プログラム。

（付記５）前記判断手段は、
前記メイン処理が前記属性情報から特定される状況で実行された場合に発生したエラーの予防策となる複数のサブ処理のうち、前記検索手段によって検索されていない未検索のサブ処理があるか否かを判断することを特徴とする付記３または４に記載の検証プログラム。

（付記６）前記コンピュータを、
前記一連の処理群のうち、最初に実行される処理から最後に実行される処理に辿り着くまでの経路を探索する探索手段として機能させ、
前記コンピュータに、
前記探索手段によって探索された経路ごとに、前記検出手段、前記検索手段、前記判断手段および前記出力手段による一連の処理を実行することを特徴とする付記１〜５のいずれか一つに記載の検証プログラム。

（付記７）前記コンピュータを、
前記検出手段（以下、「第１の検出手段」という）によってメイン処理が検出された場合、前記一連の処理群の中から実行者がそれぞれ異なる連続する処理の組み合わせを検出する第２の検出手段として機能させ、
前記検索手段は、
前記第２の検出手段によって検出された処理の組み合わせのうち、実行順序が先の処理の属性情報に基づいて、前記第１の検出手段によって検出されたメイン処理の実行時に発生が予測されるエラーの予防策となるサブ処理を前記一連の処理群の中から検索することを特徴とする付記１〜６のいずれか一つに記載の検証プログラム。

（付記８）前記第２の検出手段は、
さらに、前記一連の処理群の中から異常系の処理を検出し、
前記検索手段は、
前記第２の検出手段によって検出された異常系の処理の属性情報に基づいて、前記第１の検出手段によって検出されたメイン処理の実行時に発生が予測されるエラーの予防策となるサブ処理を前記一連の処理群の中から検索することを特徴とする付記７に記載の検証プログラム。

（付記９）前記コンピュータを、
前記一連の処理群のうち、最初に実行される処理から最後に実行される処理に辿り着くまでの経路を探索する探索手段として機能させ、
前記コンピュータに、
前記探索手段によって探索された経路ごとに、前記第１および第２の検出手段、前記検索手段、前記判断手段および前記出力手段による一連の処理を実行することを特徴とする付記７または８に記載の検証プログラム。

（付記１０）付記１〜９のいずれか一つに記載の検証プログラムを記録したコンピュータに読み取り可能な記録媒体。

（付記１１）システムの運用管理にかかる運用プロセスの信頼性を検証する検証装置において、
検証対象となる一連の処理群の中からメイン処理を検出する検出手段と、
前記検出手段によって検出されたメイン処理の実行時に発生が予測されるエラーの予防策となるサブ処理を前記一連の処理群の中から検索する検索手段と、
前記メイン処理に対する前記検索手段によって検索されたサブ処理の実行順序に基づいて、前記一連の処理群における前記サブ処理の挿入位置が正しいか否かを判断する判断手段と、
前記判断手段によって判断された判断結果を出力する出力手段と、
を備えることを特徴とする検証装置。

（付記１２）システムの運用管理にかかる運用プロセスの信頼性を検証する検証方法において、
検証対象となる一連の処理群の中からメイン処理を検出する検出工程と、
前記検出工程によって検出されたメイン処理の実行時に発生が予測されるエラーの予防策となるサブ処理を前記一連の処理群の中から検索する検索工程と、
前記メイン処理に対する前記検索工程によって検索されたサブ処理の実行順序に基づいて、前記一連の処理群における前記サブ処理の挿入位置が正しいか否かを判断する判断工程と、
前記判断工程によって判断された判断結果を出力する出力工程と、
を含んだことを特徴とする検証方法。

運用プロセスの具体例を示すアクティビティ図である。 タグ情報の具体例を示す説明図である。 マッピング情報の具体例を示す説明図である。 運用プロセスの挿入フェーズを示す説明図である。 検証装置のハードウェア構成を示すブロック図である。 検証装置の機能的構成を示すブロック図である。 設計データの具体例を示す説明図である。 予防策リストの一例を示す説明図である。 原則違反の具体例を示す説明図である。 挿入違反リストの具体例を示す説明図である。 予防策リストの具体例を示す説明図である。 エラーメッセージの具体例を示す説明図である。 複数の経路が存在する運用プロセスの具体例を示すアクティビティ図である。 実施の形態１にかかる検証装置の検証処理手順の一例を示すフローチャートである。 キー形状の予防策の一例を示す説明図である。 予防策リストの一例を示す説明図である。 必須予防策リストの具体例を示す説明図である。 運用プロセスの一部を抜粋して示すアクティビティ図である。 実施の形態２にかかる検証装置の検証処理手順の一例を示すフローチャート（その１）である。 実施の形態２にかかる検証装置の検証処理手順の一例を示すフローチャート（その２）である。

符号の説明

１００ 運用プロセス
３００ マッピング情報
６０１ 入力部
６０２ 検出部
６０３ 検索部
６０４ 判断部
６０５ 出力部
６０６ 探索部

Claims (10)

1. システムの運用管理にかかる運用プロセスの信頼性を検証するコンピュータを、
   検証対象となる一連の処理群の中からメイン処理を検出する検出手段、
   前記検出手段によって検出されたメイン処理の実行時に発生が予測されるエラーの予防策となるサブ処理を前記一連の処理群の中から検索する検索手段、
   前記メイン処理に対する前記検索手段によって検索されたサブ処理の実行順序に基づいて、前記一連の処理群における前記サブ処理の挿入位置が正しいか否かを判断する判断手段、
   前記判断手段によって判断された判断結果を出力する出力手段、
   として機能させることを特徴とする検証プログラム。
2. 前記判断手段は、
   前記検索手段によって前記メイン処理の実行時に発生が予測されるエラーの予防策となる第１および第２のサブ処理が検出された場合、前記第２のサブ処理に対する前記第１のサブ処理の実行順序に基づいて、前記一連の処理群における前記第１のサブ処理の挿入位置が正しいか否かを判断することを特徴とする請求項１に記載の検証プログラム。
3. 前記検出手段は、
   特定の状況で実行されたメイン処理と、前記特定の状況で前記メイン処理が実行された場合に発生したエラーの予防策となるサブ処理とを関連付けて保持するテーブルを参照して、前記一連の処理群の中からメイン処理を検出し、
   前記検索手段は、
   前記テーブルを参照して、前記メイン処理に付加されている属性情報から特定される状況で前記メイン処理が実行された場合に発生したエラーの予防策となるサブ処理を、前記一連の処理群の中から検索することを特徴とする請求項１または２に記載の検証プログラム。
4. 前記判断手段は、
   前記メイン処理が前記属性情報から特定される状況で実行された場合に発生したエラーの予防策となる複数のサブ処理のうち、前記検索手段によって検索されていない未検索のサブ処理があるか否かを判断することを特徴とする請求項３に記載の検証プログラム。
5. 前記コンピュータを、
   前記一連の処理群のうち、最初に実行される処理から最後に実行される処理に辿り着くまでの経路を探索する探索手段として機能させ、
   前記コンピュータに、
   前記探索手段によって探索された経路ごとに、前記検出手段、前記検索手段、前記判断手段および前記出力手段による一連の処理を実行することを特徴とする請求項１〜４のいずれか一つに記載の検証プログラム。
6. 前記コンピュータを、
   前記検出手段（以下、「第１の検出手段」という）によってメイン処理が検出された場合、前記一連の処理群の中から実行者がそれぞれ異なる連続する処理の組み合わせを検出する第２の検出手段として機能させ、
   前記検索手段は、
   前記第２の検出手段によって検出された処理の組み合わせのうち、実行順序が先の処理の属性情報に基づいて、前記第１の検出手段によって検出されたメイン処理の実行時に発生が予測されるエラーの予防策となるサブ処理を前記一連の処理群の中から検索することを特徴とする請求項１〜５のいずれか一つに記載の検証プログラム。
7. 前記第２の検出手段は、
   さらに、前記一連の処理群の中から異常系の処理を検出し、
   前記検索手段は、
   前記第２の検出手段によって検出された異常系の処理の属性情報に基づいて、前記第１の検出手段によって検出されたメイン処理の実行時に発生が予測されるエラーの予防策となるサブ処理を前記一連の処理群の中から検索することを特徴とする請求項６に記載の検証プログラム。
8. 請求項１〜７のいずれか一つに記載の検証プログラムを記録したコンピュータに読み取り可能な記録媒体。
9. システムの運用管理にかかる運用プロセスの信頼性を検証する検証装置において、
   検証対象となる一連の処理群の中からメイン処理を検出する検出手段と、
   前記検出手段によって検出されたメイン処理の実行時に発生が予測されるエラーの予防策となるサブ処理を前記一連の処理群の中から検索する検索手段と、
   前記メイン処理に対する前記検索手段によって検索されたサブ処理の実行順序に基づいて、前記一連の処理群における前記サブ処理の挿入位置が正しいか否かを判断する判断手段と、
   前記判断手段によって判断された判断結果を出力する出力手段と、
   を備えることを特徴とする検証装置。
10. システムの運用管理にかかる運用プロセスの信頼性を検証する検証方法において、
    検証対象となる一連の処理群の中からメイン処理を検出する検出工程と、
    前記検出工程によって検出されたメイン処理の実行時に発生が予測されるエラーの予防策となるサブ処理を前記一連の処理群の中から検索する検索工程と、
    前記メイン処理に対する前記検索工程によって検索されたサブ処理の実行順序に基づいて、前記一連の処理群における前記サブ処理の挿入位置が正しいか否かを判断する判断工程と、
    前記判断工程によって判断された判断結果を出力する出力工程と、
    を含んだことを特徴とする検証方法。

Images