JP2014048699A - 管理装置、管理方法およびプログラム - Google Patents

Abstract

【課題】修正プログラムの検証に適した手順を定めたワークフローを動的に生成できるようにする。
【解決手段】管理装置は、（Ａ）修正前のプログラムと修正後のプログラムを比較する比較部４０３と、（Ｂ）修正されたプログラムの検証を行う標準の手順を定めた第１のワークフローに含まれる複数のアクティビティの各々について、比較結果が当該アクティビティの有効条件を満たすか否かを判定し、当該有効条件を満たす一又は複数のアクティビティからなる第２のワークフローを生成する生成部４０９とを含む。
【選択図】図４

Description

本技術は、プログラムを検証するワークフローの生成技術に関する。

様々なビジネスの現場で業務を標準化し、作業の効率を高めるためにワークフローシステムが用いられている。ワークフローシステムは、その業務に関わる関係者が、ワークフローに従って情報を伝達し、手続きを円滑に行うことができるように支援する。そのため、ワークフローには、それぞれの業務の特性に応じた手続きの処理手順が規定される。

ソフトウエア開発の現場においても、このようなワークフローが用いられる。特に、ソフトウエアの検証段階において、検証プロセスを反映したワークフローを規定し、構造的なプログラムを検証することに役立っている。

ソフトウエアの検証プロセスには、例えば、開発グループ内のソースコードのレビュー、経験者によるソースコードのレビュー、モジュール単位の動作テスト、モジュールの集合であるコンポーネント単位の動作テスト、あるいはコンポーネントの集合であるシステムとしての総合的な動作テストなどが含まれる。

ソースコードのレビューは、机上におけるアルゴリズムの検証に役立つ。一方、動作テストは、動作環境やソフトウエアの運用形態を加味した実用性の検証に役立つ。このように、各段階における検証の観点はそれぞれ異なる。

一般的に、修正されたプログラムの検証に対しても、新規なプログラムの検証プロセスがそのまま適用されていることが多い。そのため、ワークフローは固定化されている。このように固定化されたワークフローは、ときに業務の効率を下げることもある。

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

一側面では、修正プログラムの検証に適した手順を定めたワークフローを動的に生成できるようにすることを目的とする。

一態様の管理装置は、（Ａ）修正前のプログラムと修正後のプログラムを比較する比較部と、（Ｂ）修正されたプログラムの検証を行う標準の手順を定めた第１のワークフローに含まれる複数のアクティビティの各々について、比較結果が当該アクティビティの有効条件を満たすか否かを判定し、当該有効条件を満たす一又は複数のアクティビティからなる第２のワークフローを生成する生成部とを含む。

一態様によれば、修正プログラムの検証に適した手順を定めたワークフローを動的に生成することができる。

図１は、管理サーバの概要を示す図である。 図２は、資産管理部とメンバー管理部のモジュール構成例を示す図である。 図３は、メンバーデータの例を示す図である。 図４は、主にワークフロー管理部のモジュール構成例を示す図である。 図５は、ワークフローの生成処理フローの例を示す図である。 図６は、比較データの例を示す図である。 図７は、標準ワークフローのチャート例を示す図である。 図８は、アクティビティデータの例を示す図である。 図９は、アクティビティデータの例を示す図である。 図１０は、アクティビティデータの例を示す図である。 図１１は、アクティビティデータの例を示す図である。 図１２は、ワークフローの生成処理フローの例を示す図である。 図１３は、個別ワークフローのチャート例を示す図である。 図１４は、品質管理部とワークフロー管理部のモジュール構成例を示す図である。 図１５は、ワークフローの省略処理フローの例を示す図である。 図１６は、ワークフローの省略処理フローの例を示す図である。 図１７は、省略された個別ワークフローのチャート例を示す図である。 図１８は、コンピュータのハードウエア構成の例を示す図である。

図１は、管理サーバの概要を示す図である。管理サーバ１０１は、プログラムの開発と検証を支援する管理サーバである。開発システム１１１は、開発者がプログラムの開発に用いるシステムである。管理サーバ１０１は、ＬＡＮ（Local Area Network）などのネットワークを介して開発システム１１１と接続している。

管理サーバ１０１は、資産管理部１０３、メンバー管理部１０５、ワークフロー管理部１０７及び品質管理部１０９を有している。資産管理部１０３は、プログラムを資産として管理するモジュールである。メンバー管理部１０５は、開発者などのメンバーについての属性データを管理するモジュールである。ワークフロー管理部１０７は、プログラム検証のワークフローを管理するモジュールである。品質管理部１０９は、修正されたプログラムに関わる検証結果である品質記録を管理するモジュールである。

図２は、資産管理部とメンバー管理部のモジュール構成例を示す図である。資産管理部１０３は、プログラム格納部２０１、管理データ格納部２０３、貸出部２０５及び返却部２０７を有している。

プログラム格納部２０１は、プログラムを格納している。管理データ格納部２０３は、プログラムの管理データを格納している。貸出部２０５は、プログラムを開発者に貸し出すように動作する。返却部２０７は、貸し出したプログラムの返却を受け付けるように動作する。

メンバー管理部１０５は、更新部２０９とメンバーデータ格納部２１１とを有している。更新部２０９は、プログラムの開発と検証に関わるメンバーのデータを更新するように動作する。メンバーデータ格納部２１１は、上記メンバーデータを格納している。

管理データ格納部２０３は、プログラム格納部２０１におけるプログラムの格納位置を記憶している。貸出部２０５は、開発システム１１１からプログラムの指定を受け付け、指定されたプログラムをプログラム格納部２０１から読み出し、開発システム１１１へ送信する。貸出部２０５は、転送したプログラム名に対応付けて、貸出日、貸し出した開発者名を、管理データ格納部２０３に記憶させる。

借り受けた開発者は、開発システム１１１を用いて、借り受けたプログラムを修正し、修正されたプログラムを返却部２０７に送信する。

返却部２０７は、開発システム１１１から返却されたプログラムを受信し、プログラム格納部２０１に記憶させる。返却部２０７は、返却されたプログラム名に対応付けて、返却日とプログラム格納部２０１の格納位置を管理データ格納部２０３に記憶させる。

更新部２０９は、プログラムの修正の都度、管理データ格納部２０３の管理データに基づいて修正前のプログラムと修正後のプログラムを特定し、当該プログラムを修正した開発者についての属性を更新する。

メンバーデータ格納部２１１は、メンバー毎にメンバーデータを有している。図３に、メンバーデータの例を示す。メンバーデータは、プログラムの開発と検証に関わる可能性のあるメンバー毎に、名前、所属グループ、メンバー属性、修正プログラム数、修正プログラム、修正回数、修正ステップ数、経験外部モジュール及び経験ＯＳＳの項目を有している。

名前は、そのメンバーの名前である。所属グループは、そのメンバーの属するグループである。メンバー属性は、そのメンバーが果たすプログラムの開発と検証における役割である。メンバー属性には、例えば、リーダ、開発者あるいはテスターなどの役割が割り当てられる。名前と、所属グループと、メンバー属性とは、予め設定されている。

修正プログラム数は、そのプログラマが修正したプログラムの数である。メンバーデータは、修正プログラム数分の修正プログラムと修正回数と修正ステップ数のデータを含んでいる。

修正プログラムは、そのプログラマが修正したプログラムの名前を示す。修正回数は、そのメンバーがそのプログラムを修正した回数である。修正ステップ数は、そのメンバーがそのプログラムに対して修正したステップ数である。

経験外部モジュールは、そのメンバーが用いたことがある外部モジュールである。経験ＯＳＳ（Open Source Software）は、そのメンバーが用いたことがある外部ＯＳＳである。外部モジュールとＯＳＳは、処理単位の例である。メンバーデータは、処理単位として、そのプログラマが用いたことがある内部モジュールである経験内部モジュールを含むようにしてもよい。

図４に、ワークフロー管理部のモジュール構成例を示す。ワークフロー管理部１０７は、受付部４０１、比較部４０３、比較データ記憶部４０５、標準ワークフロー格納部４０７、生成部４０９、個別ワークフロー格納部４１１、特定部４１３及び出力部４１５を有している。

受付部４０１は、ワークフローの生成などの指示を受け付けるように動作する。受付部４０１は、実行したアクティビティの実行日と実行結果を受け付け、個別ワークフローに含まれるアクティビティデータに設定する動作も行う。比較部４０３は、修正前のプログラムと修正後のプログラムを比較し、比較データを得るように動作する。比較データは、比較部４０３による比較結果を含むデータである。比較データ記憶部４０５は、比較データを記憶する。

標準ワークフロー格納部４０７は、修正されたプログラムの検証を行う標準の手順を定めた標準ワークフローを格納している。生成部４０９は、標準ワークフローに含まれる複数のアクティビティの各々について、比較結果がアクティビティの有効条件を満たすか否かを判定し、有効条件を満たす一又は複数のアクティビティからなる個別ワークフローを生成するように動作する。個別ワークフロー格納部４１１は、修正されたプログラムに対して生成される個別ワークフローを格納する。

特定部４１３は、メンバーの属性が、個別ワークフローのアクティビティにおける実行者の選定条件を満たすか否かを判定し、アクティビティを実行するメンバーを特定するように動作する。出力部４１５は、個別ワークフローをチャートとして表示するように動作する。

以下、ワークフローを生成する処理について説明する。この例では、プログラム修正の量や質に応じて、実行すべきアクティビティを選び出し、個別のワークフローを生成する。

図５は、ワークフローの生成処理フローの例を示す図である。まず、受付部４０１は、ワークフローを生成する指示を受け付ける（Ｓ５０１）。ワークフローを生成する指示には、検証対象となる修正プログラムを特定する情報が含まれている。あるいは、受付部４０１は、生成の指示と別に、検証対象となる修正プログラムを特定する情報を受け付ける。

Ｓ５０３〜Ｓ５１１で、比較部４０３は、修正前のプログラムと修正後のプログラムを比較する。この比較により、比較データが得られる。以下、比較データの例とともに処理について説明する。

図６に、比較データの例を示す。この比較データの例は、修正割合と、複雑度比と、追加外部モジュールと、追加ＯＳＳとを有している。

修正割合は、プログラムに対する修正の割合である。つまり、修正割合は、全体のコードと修正したコードの量的な比を意味する。複雑度比は、修正前プログラムの複雑度と修正後プログラムの複雑度の比である。複雑度比は、アルゴリズムの難解さが増したことを示す指標である。

追加外部モジュールは、修正により追加された外部モジュールである。追加ＯＳＳは、修正により追加されたＯＳＳである。追加外部モジュールと追加ＯＳＳは、修正後プログラムにおいて、修正前プログラムに対して追加した処理単位の例である。

この例では、プログラム単位の修正割合、複雑度比、追加外部モジュール及び追加ＯＳＳを示したが、プログラムの集合であるコンポーネント単位の修正割合、複雑度比、追加外部モジュール及び追加ＯＳＳを、比較データとして用いてもよい。更に、コンポーネントの集合であるシステム単位の修正割合、複雑度比、追加外部モジュール及び追加ＯＳＳを、比較データとして用いてもよい。

図５の処理に戻って、比較部４０３は、修正前プログラムを取得し（Ｓ５０３）、修正前プログラムの属性データを求める（Ｓ５０５）。比較部４０３は、例えば、修正前プログラムの複雑度を算出する。プログラムの複雑度の算出は、周知の方法により実施できるので、説明を省略する。更に、比較部４０３は、修正前プログラムで利用している外部モジュールを特定し、更に修正前プログラムで利用している外部ＯＳＳも特定する。

比較部４０３は、続いて、修正後プログラムを取得し（Ｓ５０７）、修正後プログラムの属性データを求める（Ｓ５０９）。比較部４０３は、例えば、修正後プログラムのステップ数を算出し、修正後プログラムの複雑度を算出する。更に、比較部４０３は、修正後プログラムで利用している外部モジュールを特定し、修正後プログラムで利用している外部ＯＳＳも特定する。

そして、比較部４０３は、比較データを求める（Ｓ５１１）。比較部４０３は、例えば、修正後プログラムと修正前プログラムを比較し、修正ステップ数を算出する。そして、修正ステップ数を修正後プログラムのステップ数で除して、修正割合を求める。また、比較部４０３は、修正後プログラムの複雑度を修正前プログラムの複雑度で除して、複雑度比を求める。

更に、比較部４０３は、修正後プログラムで利用している外部モジュールのうち、修正前プログラムで利用している外部モジュールを除いて、追加外部モジュールを特定する。同様に、比較部４０３は、修正後プログラムで利用している外部ＯＳＳのうち、修正前プログラムで利用している外部ＯＳＳを除いて、追加外部ＯＳＳを特定する。比較部４０３は、求めた修正割合と、求めた複雑度比と、特定した追加外部モジュールと、特定した追加外部ＯＳＳとを、比較データ記憶部４０５に記憶させる。

図５の処理に戻って、生成部４０９は、標準ワークフローに含まれるアクティビティ毎に以下の処理を繰り返す（Ｓ５１３）。

ここで、標準ワークフローについて説明する。標準ワークフローは、修正されたプログラムの検証を行う標準の手順を定めたワークフローである。標準ワークフローは、一般的にプログラムの開発と検証を行う組織において規定される検証プロセスに従って設定される。

図７に、標準ワークフローのチャート例を示す。この例のワークフローは、始端と終端を除く１０個のノードと、そのノード間を方向付ける矢印から構成されている。

ノード「１．グループ内ソースレビュー」は、実行順位が「１」であり、アクティビティの内容が「グループ内ソースレビュー」であることを示している。「開始」から「１．グループ内ソースレビュー」への矢印は、「１．グループ内ソースレビュー」のアクティビティが最初に実行されることを意味している。また、現時点で、「１．グループ内ソースレビュー」のアクティビティは未実行であることを示している。

以下同様に、ノード「２．リーダの承認（Ａ）」は、実行順位が「２」であり、アクティビティの内容が「リーダの承認（Ａ）」であることを示している。リーダの承認（Ａ）は、グループ内ソースレビューに対する承認である。「１．グループ内ソースレビュー」から「２．リーダの承認（Ａ）」への矢印は、「１．グループ内ソースレビュー」のアクティビティの実行後に、「２．リーダの承認（Ａ）」のアクティビティが実行されることを意味している。また、現時点で、「２．リーダの承認（Ａ）」のアクティビティは未実行であることを示している。

ノード「３．経験者によるソースレビュー」は、実行順位が「３」であり、アクティビティの内容が「経験者によるソースレビュー」であることを示している。「２．リーダの承認（Ａ）」から「３．経験者によるソースレビュー」への矢印は、「２．リーダの承認（Ａ）」のアクティビティの実行後に、「３．経験者によるソースレビュー」のアクティビティが実行されることを意味している。また、現時点で、「３．経験者によるソースレビュー」のアクティビティは未実行であることを示している。

ノード「４．リーダの承認（Ｂ）」は、実行順位が「４」であり、アクティビティの内容が「リーダの承認（Ｂ）」であることを示している。リーダの承認（Ｂ）は、経験者によるソースレビューに対する承認である。「３．経験者によるソースレビュー」から「４．リーダの承認（Ｂ）」への矢印は、「３．経験者によるソースレビュー」のアクティビティの実行後に、「４．リーダの承認（Ｂ）」のアクティビティが実行されることを意味している。また、現時点で、「４．リーダの承認（Ｂ）」のアクティビティは未実行であることを示している。

ノード「５．モジュールテスト」は、実行順位が「５」であり、アクティビティの内容が「モジュールテスト」であることを示している。「４．リーダの承認（Ｂ）」から「５．モジュールテスト」への矢印は、「４．リーダの承認（Ｂ）」のアクティビティの実行後に、「５．モジュールテスト」のアクティビティが実行されることを意味している。また、現時点で、「５．モジュールテスト」のアクティビティは未実行であることを示している。

ノード「６．リーダの承認（Ｃ）」は、実行順位が「６」であり、アクティビティの内容が「リーダの承認（Ｃ）」であることを示している。リーダの承認（Ｃ）は、モジュールテストに対する承認である。「５．モジュールテスト」から「リーダの承認（Ｃ）」への矢印は、「５．モジュールテスト」のアクティビティの実行後に、「リーダの承認（Ｃ）」のアクティビティが実行されることを意味している。また、現時点で、「リーダの承認（Ｃ）」のアクティビティは未実行であることを示している。

ノード「７．コンポーネントテスト」は、実行順位が「７」であり、アクティビティの内容が「コンポーネントテスト」であることを示している。「６．リーダの承認（Ｃ）」から「７．コンポーネントテスト」への矢印は、「６．リーダの承認（Ｃ）」のアクティビティの実行後に、「７．コンポーネントテスト」のアクティビティが実行されることを意味している。また、現時点で、「７．コンポーネントテスト」のアクティビティは未実行であることを示している。

ノード「８．リーダの承認（Ｄ）」は、実行順位が「８」であり、アクティビティの内容が「リーダの承認（Ｄ）」であることを示している。リーダの承認（Ｄ）は、コンポーネントテストに対する承認である。「７．コンポーネントテスト」から「８．リーダの承認（Ｄ）」への矢印は、「７．コンポーネントテスト」のアクティビティの実行後に、「８．リーダの承認（Ｄ）」のアクティビティが実行されることを意味している。また、現時点で、「８．リーダの承認（Ｄ）」のアクティビティは未実行であることを示している。

ノード「９．システムテスト」は、実行順位が「９」であり、アクティビティの内容が「システムテスト」であることを示している。「８．リーダの承認（Ｄ）」から「９．システムテスト」への矢印は、「８．リーダの承認（Ｄ）」のアクティビティの実行後に、「９．システムテスト」のアクティビティが実行されることを意味している。また、現時点で、「９．システムテスト」のアクティビティは未実行であることを示している。

ノード「１０．リーダの承認（Ｅ）」は、実行順位が「１０」であり、アクティビティの内容が「リーダの承認（Ｅ）」であることを示している。リーダの承認（Ｅ）は、システムテストに対する承認である。「９．システムテスト」から「１０．リーダの承認（Ｅ）」への矢印は、「９．システムテスト」のアクティビティの実行後に、「１０．リーダの承認（Ｅ）」のアクティビティが実行されることを意味している。また、現時点で、「１０．リーダの承認（Ｅ）」のアクティビティは未実行であることを示している。

標準ワークフロー格納部４０７は、上記の各ノードに相当する各アクティビティデータを記憶している。続いて、アクティビティデータについて説明する。

図８に、アクティビティデータの例を示す。アクティビティ番号、実行順位、アクティビティの内容、有効条件、有効フラグ、選定条件、評価条件、省略条件、省略フラグ、実行メンバー、実行日、実行結果及び品質評価の項目を有している。

アクティビティ番号は、アクティビティの識別情報である。実行順位は、アクティビティを実行する順番を定める情報である。アクティビティの内容は、アクティビティにより実行する手続の内容である。

有効条件は、修正されたプログラムを検証するために、アクティビティが有効となる条件である。有効フラグは、有効なアクティビティであるか否かを定めるフラグである。選定条件は、アクティビティを実行する者の条件である。評価条件は、アクティビティにおける品質評価を定める条件である。省略条件は、アクティビティの実行を省略する場合の条件である。省略フラグは、アクティビティの実行を省略するか否かを定めるフラグである。

実行メンバーは、アクティビティを実行する者である。実行日は、アクティビティを実行した日である。実行結果は、アクティビティを実行した結果である。品質評価は、修正されたプログラムの品質についての評価である。

この例は、アクティビティ番号「Ａ＿０３」、実行順位「３」であるアクティビティの内容「経験者によるソースレビュー」について、有効条件「プログラムの修正割合＞５％」と選定条件「同一グループ ａｎｄ 開発者 ａｎｄ 修正ステップ数最大」と評価条件「高：レビュー結果のＮＧ件数／時間＜０．１、低：高以外」と省略条件「なし」を定めている。

有効条件「プログラムの修正割合＞５％」は、プログラムの修正割合が５％より大きい場合に、このアクティビティが有効となることを示している。選定条件「同一グループ ａｎｄ 開発者 ａｎｄ 修正ステップ数最大」は、修正した開発者が属するグループと同じグループに属し、かつメンバー属性が開発者である者のうち、修正ステップ数の合計が最大である者が実行メンバーとして選ばれることを示している。

この選定条件の例は、１番目の条件がグループに関する条件であり、２番目の条件がメンバー属性に関する条件であり、３番目の条件が経験に関する条件であるという前提で構成されている。但し個々の条件の順番を固定しない場合には、「所属グループ＝修正メンバーの所属グループ」、「メンバー属性＝開発者」、あるいは「修正ステップ数＝ＭＡＸ」など、項目を含む条件式を設定するようにしてもよい。

評価条件「高：レビュー結果のＮＧ件数／時間＜０．１、低：高以外」は、レビュー結果に含まれるＮＧ件数／時間の値が０．１より小さい場合に「高」と判定し、「高」と判定しない場合に「低」と判定することを示している。有効フラグと省略フラグは、初期値「ＯＦＦ」が設定されている。実行メンバー、実行日、実行結果及び品質評価の初期値は「未定」であり、具体的なデータは、ワークフローの実行段階で受付部４０１を介して設定される。

図９に、アクティビティ番号「Ａ＿０４」、実行順位「４」であるアクティビティの内容「リーダの承認（Ｂ）」のアクティビティデータの例を示す。

有効条件「Ａ＿０３が有効な場合」と選定条件「同一グループ ａｎｄ リーダ」と評価条件「高：実行結果が承認済みの場合、低：高以外」と省略条件「Ａ＿０３を省略する場合」を定めている。

有効条件「Ａ＿０３が有効な場合」は、アクティビティ番号Ａ＿０３のアクティビティが有効である場合に、このアクティビティが有効となることを示している。選定条件「同一グループ ａｎｄ リーダ」は、修正した開発者が属するグループと同じグループに属し、かつメンバー属性がリーダである者が実行メンバーとして選ばれることを示している。評価条件「高：実行結果が承認済みの場合、低：高以外」は、実行結果が承認済みの場合に「高」と判定し、「高」と判定しない場合に「低」と判定することを示している。有効フラグ、省略フラグ、実行メンバー、実行日、実行結果及び品質評価については、図８と同様である。

図１０に、アクティビティ番号「Ａ＿０７」、実行順位「７」であるアクティビティの内容「コンポーネントテスト」のアクティビティデータの例を示す。

有効条件「常に」と選定条件「同一グループ ａｎｄ 開発者」と評価条件「高：テスト結果のＮＧ件数／８時間＜２の場合、低：高以外」と省略条件「Ａ＿０１〜Ａ０６がすべて高の場合」を定めている。

有効条件「常に」は、常にこのアクティビティが有効となることを示している。選定条件「同一グループ ａｎｄ 開発者」は、修正した開発者が属するグループと同じグループに属し、かつメンバー属性が開発者である者が実行メンバーとして選ばれることを示している。評価条件「高：テスト結果のＮＧ件数／８時間＜２の場合、低：高以外」は、テスト結果に含まれるＮＧ件数／８時間が２より小さい場合に「高」と判定し、「高」と判定しない場合に「低」と判定することを示している。有効フラグ、省略フラグ、実行メンバー、実行日、実行結果及び品質評価については、図８と同様である。

図１１は、アクティビティ番号「Ａ＿０８」、実行順位「８」であるアクティビティの内容「リーダの承認（Ｄ）」のアクティビティデータの例を示す。

有効条件「Ａ＿０７が有効な場合」と選定条件「同一グループ ａｎｄ リーダ」と評価条件「高：実行結果が承認済みの場合、低：高以外」と省略条件「Ａ＿０７を省略する場合」を定めている。

有効条件「Ａ＿０７が有効な場合」は、アクティビティ番号Ａ＿０７のアクティビティが有効である場合に、このアクティビティが有効となることを示している。選定条件「同一グループ ａｎｄ リーダ」は、修正した開発者が属するグループと同じグループに属し、かつメンバー属性がリーダである者が実行メンバーとして選ばれることを示している。評価条件「高：実行結果が承認済みの場合、低：高以外」は、実行結果が承認済みの場合に「高」と判定し、「高」と判定しない場合に「低」と判定することを示している。有効フラグ、省略フラグ、実行メンバー、実行日、実行結果及び品質評価については、図８と同様である。他のアクティビティについても、アクティビティデータが設定されている。

図５の処理に戻って、生成部４０９は、アクティビティに含まれる有効条件を満たすか否かを判定する（Ｓ５１５）。図８のアクティビティデータの例では、プログラムの修正割合を比較データ記憶部４０５から取得し、５％より大きいか否かを判定する。プログラムの修正割合が５％より大きい場合に、有効条件を満たすと判定し、プログラムの修正割合が５％以下の場合に、有効条件を満たさないと判定する。

図９のアクティビティデータの例では、アクティビティ番号「Ａ＿０３」のアクティビティデータの有効フラグがＯＮの場合に、有効条件を満たすと判定し、アクティビティ番号「Ａ＿０３」のアクティビティデータの有効フラグがＯＦＦの場合に、有効条件を満たさないと判定する。

図１０のアクティビティデータの例では、常に有効条件を満たすと判定する。

図１１のアクティビティデータの例では、アクティビティ番号「Ａ＿０７」のアクティビティデータの有効フラグがＯＮの場合に、有効条件を満たすと判定し、アクティビティ番号「Ａ＿０７」のアクティビティデータの有効フラグがＯＦＦの場合に、有効条件を満たさないと判定する。

比較データを用いる有効条件の例として、修正割合が所定値より大きい条件を示したが、修正割合が所定値以上の条件、修正割合が所定値より小さい条件、あるいは修正割合が所定値以下の条件であってもよい。

更に、複雑度比が所定値より大きい条件、複雑度比が所定値以上の条件、複雑度比が所定値より小さい条件、あるいは複雑度比が所定値以下の条件であってもよい。

追加外部モジュールについては、特定のモジュールが追加外部モジュールに含まれることを条件としてもよい。また、追加外部モジュールの数が所定値より大きい条件、追加外部モジュールの数が所定値以上の条件、追加外部モジュールの数が所定値より小さい条件、あるいは追加外部モジュールの数が所定値以下の条件であってもよい。

追加ＯＳＳについては、特定のＯＳＳが追加ＯＳＳに含まれることを条件としてもよい。また、追加ＯＳＳの数が所定値より大きい条件、追加ＯＳＳの数が所定値以上の条件、追加ＯＳＳの数が所定値より小さい条件、あるいは追加ＯＳＳの数が所定値以下の条件であってもよい。

追加外部モジュールと追加ＯＳＳの総数が所定値より大きい条件、追加外部モジュールと追加ＯＳＳの総数が所定値以上の条件、追加外部モジュールと追加ＯＳＳの総数が所定値より小さい条件、あるいは追加外部モジュールと追加ＯＳＳの総数が所定値以下の条件であってもよい。

プログラム単位の修正割合、複雑度比、追加外部モジュール及び追加ＯＳＳに関する条件以外に、コンポーネント単位の修正割合、複雑度比、追加外部モジュール及び追加ＯＳＳに関する条件を用いてもよい。あるいは、システム単位の修正割合、複雑度比、追加外部モジュール及び追加ＯＳＳに関する条件を用いてもよい。

また、上記の条件を、任意にＡＮＤ条件あるいはＯＲ条件で組み合わせるようにしてもよい。

アクティビティに含まれる有効条件を満たさないと判定した場合には、Ｓ５１９へ移る。この場合、有効フラグは初期値のＯＦＦのままである。アクティビティに含まれる有効条件を満たすと判定した場合には、生成部４０９は、有効フラグをＯＮに設定する（Ｓ５１７）。

生成部４０９は、すべてのアクティビティについて処理したか否かを判定する（Ｓ５１９）。まだ処理していないアクティビティがあると判定した場合には、Ｓ５１３の処理へ戻る。すべてのアクティビティについて処理したと判定した場合には、端子Ａを介して、図１２のＳ１２０１の処理へ移る。

このようにアクティビティの有効条件を判定するので、プログラム修正の量や質に応じて、実行すべきアクティビティを選び出すことができる。

例えば、修正割合が所定値より大きい場合に動作テストのアクティビティが有効となるように有効条件を設定してもよい。このようにすると、修正割合が少ない場合には、ソースコードのレビューによる検証で品質の担保が可能であるので、動作テストを省き、一方修正割合が多い場合には、ソースコードのレビューによる確認だけでは不十分なので、十分に動作テストを行う運用ができる。

例えば、複雑度比が所定値より大きい場合にソースコードレビューのアクティビティが有効となるように有効条件を設定してもよい。このようにすると、プログラムの修正内容が単純である場合には、動作テストによる動作環境への適応の確認のみで足るのでソースコードレビューを省き、一方修正内容が複雑である場合には、動作テストのみでは本質的なアルゴリズムの欠点を見つけ出せないので、ソースコードレビューを行う運用ができる。

続いて、アクティビティの実行内容に応じて実行者を自動的に選定する処理について説明する。図１２に、ワークフローの生成処理フローの続きを示す。

特定部４１３は、個別ワークフローに含まれるアクティビティ毎に以下の処理を繰り返す（Ｓ１２０１）。特定部４１３は、アクティビティの選定条件に合うメンバーを特定する（Ｓ１２０３）。

図８のアクティビティデータの例では、プログラムを修正した開発者の所属グループを特定し、その所属グループと同じ所属グループであり、メンバー属性が開発者であるメンバーのうち、修正ステップ数の合計が最大の者を特定する。

図９のアクティビティデータの例では、プログラムを修正した開発者の所属グループを特定し、その所属グループと同じ所属グループであり、メンバー属性がリーダである者を特定する。

図１０のアクティビティデータの例では、プログラムを修正した開発者の所属グループを特定し、その所属グループと同じ所属グループであり、メンバー属性が開発者である者を特定する。

図１１のアクティビティデータの例では、プログラムを修正した開発者の所属グループを特定し、その所属グループと同じ所属グループであり、メンバー属性がリーダである者を特定する。

上述の例では、所属グループとメンバー属性の他に、修正ステップ数の条件を設定する例を示したが、修正プログラム数あるいは修正回数の合計が、所定値以上（あるいは所定値より大きい）などの条件を用いてもよい。また、特定の外部モジュールが経験外部モジュールに含まれることを条件としてもよい。同様に、特定のＯＳＳが経験ＯＳＳに含まれることを条件としてもよい。更に、修正ステップ数、修正プログラム数、修正回数、経験外部モジュール及び経験ＯＳＳの条件を、ＡＮＤ条件あるいはＯＲ条件で、任意に組み合わせるようにしてもよい。

特定部４１３は、特定したメンバーをアクティビティの実行メンバーに設定する（Ｓ１２０５）。特定部４１３は、標準ワークフローに含まれるすべてのアクティビティについて処理したか否かについて判定する（Ｓ１２０７）。まだ処理していないアクティビティがあると判定した場合には、Ｓ１２０１の処理へ戻る。

すべてのアクティビティについて処理したと判定した場合には、出力部４１５は、個別ワークフローのチャートを生成する（Ｓ１２０９）。具体的には、出力部４１５は有効フラグがＯＮであるアクティビティを実行順位に従ってノードとして配列し、隣接するノード間を実行順位に従って矢印で連結する。

出力部４１５は、生成した個別ワークフローのチャートを表示する（Ｓ１２１１）。上述のように処理することによって、プログラムの修正の実績に基づいて、開発者としての経験を反映した実行者の選定ができるようになる。

図１３に、個別ワークフローのチャート例を示す。このチャートは、プログラムの修正割合が５％以下であり、アクティビティ番号「Ａ＿０３」が有効とならない例を示している。また、アクティビティ番号「Ａ＿０３」が有効ではないので、「４．リーダの承認（Ｂ）」も有効とならない。従って、図７の個別ワークフローのチャート例に比べて、「３．経験者によるソースレビュー」と「４．リーダの承認（Ｂ）」のアクティビティが省かれている。このチャートで、「２．リーダの承認（Ａ）」から「５．モジュールテスト」への矢印は、「２．リーダの承認（Ａ）」のアクティビティの実行後に、「５．モジュールテスト」のアクティビティが実行されることを意味している。

続いて、ワークフローの実行中の動作について説明する。図１４は、品質管理部とワークフロー管理部のモジュール構成例を示す図である。登録部１４０１は、アクティビティを実行した結果得られた品質記録を受け付け、登録するように動作する。品質記録は、例えば、ソースレビューのレビュー結果であり、動作テストのテスト結果である。ソースレビューのレビュー結果には、例えばＮＧ件数／時間の値が含まれる。動作テストのテスト結果には、例えばＮＧ件数／８時間の値が含まれる。これらの品質記録は、アクティビティの実行結果の例である。

本形態では、品質管理部１０９を資産管理部１０３と別に設ける例を示したが、品質管理部１０９を資産管理部１０３に含めるようにしてもよい。また、プログラム格納部２０１と、管理データ格納部２０３と、品質記録格納部１４０３とをまとめて、資産リポジトリと呼ぶこともある。

評価部１４０５は、評価条件に従って、修正されたプログラムの品質についての評価を求めるように動作する。

変更部１４０７は、実行済みのアクティビティの実行結果が未実行のアクティビティの省略条件を満たす場合に、未実行のアクティビティを省略するように個別ワークフローを変更するように動作する。この例で、アクティビティの実行結果は、品質評価を介して間接的に判定される場合がある。省略条件は、アクティビティの実行結果を直接判定する条件でもよい。例えば、直前のアクティビティにおけるテスト結果のＮＧ件数／８時間が２より小さい場合に省略する省略条件を用いてもよい。あるいは、直前のアクティビティにおけるレビュー結果のＮＧ件数／時間が０．１より小さい場合に省略する省略条件を用いてもよい。

図１５に、ワークフローの省略処理フローの例を示す。評価部１４０５は、個別ワークフローに含まれるアクティビティ毎に以下の処理を繰り返す（Ｓ１５０１）。評価部１４０５は、そのアクティビティが評価済みであるか否かを判定する（Ｓ１５０３）。具体的には、品質評価が設定されている場合に評価済みであると判定し、品質評価が未定の場合に評価済みでないと判定する。アクティビティが評価済みであると判定した場合には、Ｓ１５１１の処理へ移る。

アクティビティが評価済みでないと判定した場合には、評価部１４０５は、品質記録又は実行結果を取得する（Ｓ１５０５）。具体的には、評価条件が、図８に示したアクティビティデータのようにレビュー結果に関する条件である場合には、品質記録格納部１４０３からレビュー結果を取得する。評価条件が、図１０に示したアクティビティデータのようにテスト結果に関する条件である場合には、品質記録格納部１４０３からテスト結果を取得する。評価条件が、図９と図１１に示したアクティビティデータのように実行結果に関する条件である場合には、アクティビティデータから実行結果を取得する。実行結果は、例えば承認済みを示す。実行結果は、適時受付部４０１を介して個別ワークフロー格納部４１１に格納されている。

そして、評価部１４０５は、品質記録又は実行結果があったか否かを判定する（Ｓ１５０７）。アクティビティが未実行の場合には、取得しようとした品質記録又は実行結果が得られない。このように、品質記録又は実行結果が無かったと判定した場合には、Ｓ１５１１の処理へ移る。

一方、品質記録又は実行結果があったと判定した場合には、評価部１４０５は、評価条件に従って判定し、品質評価を得る（Ｓ１５０９）。評価部１４０５は、得た品質評価をアクティビティデータに設定する。この例では、「高」あるいは「低」の２値の評価値が得られる。評価部１４０５は、３値以上の評価値を得るようにしてもよい。

評価部１４０５は、個別ワークフローに含まれるすべてのアクティビティについて処理したか否かについて判定する（Ｓ１５１１）。まだ処理していないアクティビティがあると判定した場合には、Ｓ１５０１の処理へ戻る。すべてのアクティビティについて処理したと判定した場合には、端子Ｂを介して、図１６のＳ１６０１の処理へ移る。

図１６に、ワークフローの省略処理フローの例を示す。変更部１４０７は、個別ワークフローに含まれるアクティビティ毎に以下の処理を繰り返す（Ｓ１６０１）。変更部１４０７は、アクティビティが未実行であるか否かを判定する（Ｓ１６０３）。具体的には、変更部１４０７は、アクティビティデータの実行日が設定されていない場合に、未実行であると判定し、アクティビティデータの実行日が設定されている場合に、未実行でないと判定する。実行日は、適時受付部４０１を介して個別ワークフロー格納部４１１に格納されている。

未実行でないと判定した場合には、Ｓ１６０９の処理に移る。省略の対象とならないからである。未実行であると判定した場合には、変更部１４０７は、アクティビティの省略条件を満たすか否かを判定する（Ｓ１６０５）。

図８のアクティビティデータの例では、省略条件はないので、常に省略条件を満たさないと判定する。

図９のアクティビティデータの例では、アクティビティ番号「Ａ＿０３」のアクティビティデータの省略フラグがＯＮの場合に、省略条件を満たすと判定し、アクティビティ番号「Ａ＿０３」のアクティビティデータの省略フラグがＯＦＦの場合に、省略条件を満たさないと判定する。

図１０のアクティビティデータの例では、アクティビティ番号「Ａ＿０１」からアクティビティ番号「Ａ＿０６」までのアクティビティデータの品質評価がすべて「高」の場合に、省略条件を満たすと判定し、アクティビティ番号「Ａ＿０１」からアクティビティ番号「Ａ＿０６」までのアクティビティデータにおける品質評価のいずれかが「高」でない場合に、有効条件を満たさないと判定する。

図１１のアクティビティデータの例では、アクティビティ番号「Ａ＿０７」のアクティビティデータの省略フラグがＯＮの場合に、省略条件を満たすと判定し、アクティビティ番号「Ａ＿０７」のアクティビティデータの省略フラグがＯＦＦの場合に、省略条件を満たさないと判定する。

アクティビティの省略条件を満たさないと判定した場合には、Ｓ１６０９の処理に移る。省略条件を満たさない場合には、アクティビティを省略しないからである。アクティビティの省略条件を満たすと判定した場合には、変更部１４０７は、省略フラグをＯＮに設定する（Ｓ１６０７）。変更部１４０７は、個別ワークフローに含まれるすべてのアクティビティについて処理したか否かについて判定する（Ｓ１６０９）。まだ処理していないアクティビティがあると判定した場合には、Ｓ１６０１の処理へ戻る。

すべてのアクティビティについて処理したと判定した場合には、出力部４１５は、個別ワークフローのチャートを生成する（Ｓ１６１１）。このとき、出力部４１５は、省略フラグがＯＮであるアクティビティのノードをチャートに含めない。また、出力部４１５は、実行済みのアクティビティのノードを太枠で示し、実行済みの表示を付す。そして、出力部４１５は、個別ワークフローのチャートを表示する（Ｓ１６１３）。

図１７は、省略された個別ワークフローのチャート例を示す図である。図１３の個別ワークフローのチャート例に比べて、「７．コンポーネントテスト」と「８．リーダの承認（Ｄ）」のアクティビティが省かれている。このチャートは、アクティビティ番号「Ａ＿０１」〜アクティビティ番号「Ａ＿０６」のアクティビティデータの品質評価がすべて「高」であり、アクティビティ番号「Ａ＿０７」のアクティビティが省略され、アクティビティ番号「Ａ＿０７」のアクティビティが省略されるので、アクティビティ番号「Ａ＿０８」のアクティビティも省略される例を示している。「６．リーダの承認（Ｃ）」から「９．システムテスト」への矢印は、「６．リーダの承認（Ｃ）」のアクティビティの実行後に、「９．システムテスト」のアクティビティが実行されることを意味している。

太枠で示した「１．グループ内ソースレビュー」と「２．リーダの承認（Ａ）」と「５．モジュールテスト」と「６．リーダの承認（Ｃ）」は、現時点で実行済みであることを意味している。「９．システムテスト」と「１０．リーダの承認（Ｅ）」は、現時点で未実行である。

このように省略する処理を行うことによって、前のアクティビティによる検証手続きで高い信頼性が確認され、プログラムの修正による品質低下のリスクが少ないと想定される場合に、後の検証手続きのアクティビティを省くように運用することができるようになる。

以上本技術の一実施の形態を説明したが、本技術はこれに限定されるものではない。例えば、上述の機能ブロック構成は必ずしも実際のプログラムモジュール構成に対応するものではない。

また、上で説明した各記憶領域の構成は一例であって、必ずしも上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。

なお、上で述べた管理サーバ１０１と開発システム１１１は、コンピュータ装置であって、図１８に示すように、メモリ２５０１とＣＰＵ（Central Processing Unit）２５０３とハードディスク・ドライブ（ＨＤＤ：Hard Disk Drive）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

以上述べた実施の形態をまとめると、以下のようになる。

本実施の形態に係る管理装置は、（Ａ）修正前のプログラムと修正後のプログラムを比較する比較部と、（Ｂ）修正されたプログラムの検証を行う標準の手順を定めた第１のワークフローに含まれる複数のアクティビティの各々について、比較結果が当該アクティビティの有効条件を満たすか否かを判定し、当該有効条件を満たす一又は複数のアクティビティからなる第２のワークフローを生成する生成部とを含む。

このようにすれば、プログラム修正の量や質に応じて、実行すべきアクティビティを選び出した個別のワークフローを生成することができる。例えば、修正の量が少ない場合には、ソースコードのレビューによる検証で品質の担保が可能であるので、一部の動作テストを省き、一方修正の量が多い場合には、ソースコードのレビューによる確認だけでは不十分なので、十分に動作テストを行うなどのワークフローの設定の判断を、自動的かつ客観的に行うことができるようになる。また、プログラムの修正内容が単純である場合には、動作テストによる動作環境への適応の確認のみで足り、一方修正内容が複雑である場合には、動作テストのみでは本質的なアルゴリズムの欠点を見つけ出せないので、ソースコードのレビューが有効であるなど、アクティビティの実行内容の特性も考慮したワークフローの設定が可能となる。

また、プログラムの修正の都度、修正前のプログラムと修正後のプログラムに基づいて、当該プログラムを修正した開発者についての属性を更新する更新部を有するようにしてもよい。更に、上記属性が、個別のワークフローのアクティビティにおける実行者の選定条件を満たすか否かを判定し、当該アクティビティを実行する開発者を特定する特定部を有するようにしてもよい。

このようにすれば、アクティビティの実行内容に応じて実行者を自動的に選定できるようになる。また、プログラムの修正の実績に基づいて、開発者としての経験を反映した実行者の選定ができるようになる。

また、個別のワークフローのアクティビティにおける実行結果を登録する登録部を有するようにしてもよい。更に、上記実行結果が、個別のワークフローにおいて未実行であるアクティビティの省略条件を満たす場合に、当該未実行のアクティビティを省略するように個別のワークフローを変更する変更部を有するようにしてもよい。

このようにすれば、前の検証手続きで高い信頼性が確認され、プログラムの修正による品質低下のリスクが少ないと想定される場合に、後の検証手続きを省くように運用することができるようになる。

また、上記比較結果は、当該プログラムの修正割合であってもよい。

このようにすれば、プログラムの修正による品質低下のリスクを、全体のコードと修正したコードの量的な比により推し量り、アクティビティによる検証の要否をより的確に判定できるようになる。

また、上記比較結果は、修正前のプログラムの複雑度と、修正後のプログラムの複雑度の比であってもよい。

このようにすれば、プログラムの修正による品質低下のリスクを、アルゴリズムの難解さを基準に推し量り、アクティビティによる検証の要否をより的確に判定できるようになる。

また、上記比較結果は、修正後のプログラムにおいて、修正前のプログラムに対して追加した処理単位であってもよい。

このようにすれば、プログラムの修正による品質低下のリスクを、追加した処理を基準に推し量り、アクティビティによる検証の要否をより的確に判定できるようになる。例えば、エラーを生じさせやすい処理を追加した場合には、品質低下のリスクは高まることになる。

なお、上記方法による処理をコンピュータに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。

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

（付記１）
修正前のプログラムと修正後のプログラムを比較する比較部と、
修正されたプログラムの検証を行う標準の手順を定めた第１のワークフローに含まれる複数のアクティビティの各々について、比較結果が当該アクティビティの有効条件を満たすか否かを判定し、当該有効条件を満たす一又は複数のアクティビティからなる第２のワークフローを生成する生成部と
を含む管理装置。

（付記２）
更に、
プログラムの修正の都度、修正前のプログラムと修正後のプログラムに基づいて、当該プログラムを修正した開発者についての属性を更新する更新部と、
前記属性が、前記個別のワークフローのアクティビティにおける実行者の選定条件を満たすか否かを判定し、当該アクティビティを実行する開発者を特定する特定部と
を含む付記１記載の管理装置。

（付記３）
更に、
前記個別のワークフローのアクティビティにおける実行結果を登録する登録部と、
前記実行結果が、前記個別のワークフローにおいて未実行であるアクティビティの省略条件を満たす場合に、当該未実行のアクティビティを省略するように前記個別のワークフローを変更する変更部と
を含む付記１又は２記載の管理装置。

（付記４）
前記比較結果は、当該プログラムの修正割合である
付記１記載の管理装置。

（付記５）
前記比較結果は、前記修正前のプログラムの複雑度と、前記修正後のプログラムの複雑度の比である
付記１記載の管理装置。

（付記６）
前記比較結果は、前記修正後のプログラムにおいて、前記修正前のプログラムに対して追加した処理単位である
付記１記載の管理装置。

（付記７）
修正前のプログラムと修正後のプログラムを比較する処理と、
修正されたプログラムの検証を行う標準の手順を定めた第１のワークフローに含まれる複数のアクティビティの各々について、比較結果が当該アクティビティの有効条件を満たすか否かを判定し、当該有効条件を満たす一又は複数のアクティビティからなる第２のワークフローを生成する処理と
を含む管理方法。

（付記８）
修正前のプログラムと修正後のプログラムを比較する処理と、
修正されたプログラムの検証を行う標準の手順を定めた第１のワークフローに含まれる複数のアクティビティの各々について、比較結果が当該アクティビティの有効条件を満たすか否かを判定し、当該有効条件を満たす一又は複数のアクティビティからなる第２のワークフローを生成する処理と
をコンピュータに実行させるためのプログラム。

１０１ 管理サーバ １０３ 資産管理部
１０５ メンバー管理部 １０７ ワークフロー管理部
１０９ 品質管理部 １１１ 開発システム
２０１ プログラム格納部 ２０３ 管理データ格納部
２０５ 貸出部 ２０７ 返却部
２０９ 更新部 ２１１ メンバーデータ格納部
４０１ 受付部 ４０３ 比較部
４０５ 比較データ記憶部 ４０７ 標準ワークフロー格納部
４０９ 生成部 ４１１ 個別ワークフロー格納部
４１３ 特定部 ４１５ 出力部
１４０１ 登録部 １４０３ 品質記録格納部
１４０５ 評価部 １４０７ 変更部

Claims (5)

1. 修正前のプログラムと修正後のプログラムを比較する比較部と、
   修正されたプログラムの検証を行う標準の手順を定めた第１のワークフローに含まれる複数のアクティビティの各々について、比較結果が当該アクティビティの有効条件を満たすか否かを判定し、当該有効条件を満たす一又は複数のアクティビティからなる第２のワークフローを生成する生成部と
   を含む管理装置。
2. 更に、
   プログラムの修正の都度、修正前のプログラムと修正後のプログラムに基づいて、当該プログラムを修正した開発者についての属性を更新する更新部と、
   前記属性が、前記個別のワークフローのアクティビティにおける実行者の選定条件を満たすか否かを判定し、当該アクティビティを実行する開発者を特定する特定部と
   を含む請求項１記載の管理装置。
3. 更に、
   前記個別のワークフローのアクティビティにおける実行結果を登録する登録部と、
   前記実行結果が、前記個別のワークフローにおいて未実行であるアクティビティの省略条件を満たす場合に、当該未実行のアクティビティを省略するように前記個別のワークフローを変更する変更部と
   を含む請求項１又は２記載の管理装置。
4. 修正前のプログラムと修正後のプログラムを比較する処理と、
   修正されたプログラムの検証を行う標準の手順を定めた第１のワークフローに含まれる複数のアクティビティの各々について、比較結果が当該アクティビティの有効条件を満たすか否かを判定し、当該有効条件を満たす一又は複数のアクティビティからなる第２のワークフローを生成する処理と
   を含む管理方法。
5. 修正前のプログラムと修正後のプログラムを比較する処理と、
   修正されたプログラムの検証を行う標準の手順を定めた第１のワークフローに含まれる複数のアクティビティの各々について、比較結果が当該アクティビティの有効条件を満たすか否かを判定し、当該有効条件を満たす一又は複数のアクティビティからなる第２のワークフローを生成する処理と
   をコンピュータに実行させるためのプログラム。

Images