JP2014194703A - 案件保守管理装置、案件保守管理方法及び案件保守管理プログラム - Google Patents

Abstract

【課題】アプリケーションが複数のモジュールから構成される場合において、所定の基準にしたがって、モジュールの更新の可否を判断する。
【解決手段】本発明の案件保守管理装置は、案件のうち既に終了している最新の案件において更新されたモジュールを削除し、最新の案件の直前の案件において更新されたモジュールを元にして、操作中の案件においてモジュールを更新したい旨の要求を受け付け、直前の案件に始まり最新の案件を経て前記操作中の案件に至る第１の更新順序を、直前の案件に始まり操作中の案件を経て最新の案件に至る第２の更新順序に変更することが可能であるか否かを、記憶部に格納した変更パターンを参照することによって判断し、判断の結果が可能である場合は、更新履歴情報において、最新の案件についてのレコードを削除し、操作中の案件についてのレコードを記憶することを特徴とする。
【選択図】図３

Description

本発明は、案件保守管理装置、案件保守管理方法及び案件保守管理プログラムに関する。

業務用アプリケーションとして使用されるプログラムは、その業務内容の変化に伴い、日常的に更新されて行く。例えば、企業の決算業務用アプリケーションは、税制の改正、会計規則の改正等がある都度、システムエンジニアによる保守を受ける。ここで保守とは、プログラム内容の変更一般を意味し、例えば、アルゴリズムの一部を変更すること、メソッド呼び出し時の引数を変更すること等を含む。アプリケーションの保守については、どの業務に使用されるアプリケーションがどのバージョンにまで更新され、そのバージョンがどの時点の業務に適用可能であるか、という「バージョン管理」が重要である。

特許文献１は「アプリケーションの更新処理システム」等について記載している。特許文献１によれば、あるアプリケーションが複数のサーバで使用されており、ある端末装置からそのアプリケーションの更新要求通知をあるサーバに対して送信する。そして、そのサーバが更新に失敗すると、更新失敗通知をその端末装置に返信する。更新失敗通知を受信した端末装置は、すべてのサーバに対して、アプリケーションの更新取消要求通知を送信する。この更新取消要求通知を受信したサーバは、アプリケーションの更新を取消して更新前の状態に戻す。

特開２００４−８６７６９号公報（段落００１２）

アプリケーションは、大規模になるに伴い、多くのモジュールから構成されるようになる。そして、そのモジュールの１つ１つが保守の対象となる。また、１つのモジュールは複数のアプリケーションの一部となっている場合がある。このような場合に、ある業務のアプリケーションに含まれるあるモジュールを変更したとする。すると、当該変更されたモジュールを構成の一部として有する他の業務のアプリケーションが稼動しなくなることもあるし、全く影響が生じない場合もある。このように、アプリケーションのモジュールの保守については、どのモジュールがどのバージョンにまで更新され、そのバージョンがどのアプリケーションの稼動を保証するか、というモジュールごとの「バージョン管理」が極めて重要である。

しかしながら、特許文献１は、アプリケーションが複数のモジュールから構成される場合を想定していない。したがって、モジュールとアプリケーションとの対応関係が多対多である場合、あるモジュールをあるアプリケーションのために更新し得るか否かを、他のアプリケーションの稼動保証の観点から判断することができない。
さらに、特許文献１は、アプリケーションの更新が失敗に終わるか否かの判断基準を開示していない。したがって、アプリケーションの更新が可能である場合とそうでない場合とを比較して、最終的な更新の可否を判断するには別途方策が必要となる。
そこで、本発明は、アプリケーションが複数のモジュールから構成される場合において、所定の基準にしたがって、モジュールの更新の可否を判断する案件保守管理装置を提供することを目的とする。

本発明の案件保守管理装置は、案件のうち既に終了している最新の案件において更新されたモジュールを削除し、最新の案件の直前の案件において更新されたモジュールを元にして、操作中の案件においてモジュールを更新したい旨の要求を受け付け、直前の案件に始まり最新の案件を経て操作中の案件に至る第１の更新順序を、直前の案件に始まり操作中の案件を経て最新の案件に至る第２の更新順序に変更することが可能であるか否かを、記憶部に格納した変更パターンを参照することによって判断し、判断の結果が可能である場合は、更新履歴情報において、最新の案件についてのレコードを削除し、操作中の案件についてのレコードを記憶することを特徴とする。
その他の手段については、発明を実施するための形態のなかで説明する。

本発明によれば、アプリケーションが複数のモジュールから構成される場合において、所定の基準にしたがって、モジュールの更新の可否を判断する案件保守管理装置を提供することが可能になる。

本実施形態の案件とモジュールとの関係を説明する図である。 本実施形態のモジュールが記憶される状態を説明する図である。 本実施形態の案件保守管理装置の構成を説明する図である。 （ａ）は、本実施形態の案件モジュール対応情報の一例を示す図であり、（ｂ）は、本実施形態のコミット順序情報の一例を示す図である。 本実施形態の更新履歴情報の一例を示す図である。 本実施形態のコミット推移を説明する図である。 本実施形態のコミット推移を説明する図（続き）である。 本実施形態のコミット順序変更情報の一例を示す図である。 （ａ）は、本実施形態のコミット解除コスト算出情報の一例を示す図であり、（ｂ）は、本実施形態のコミット解除コストの比較例を示す図である。 （ａ）は、本実施形態の案件詳細情報の一例を示す図であり、（ｂ）は、本実施形態の案件評価情報の一例を示す図である。 本実施形態の第１の処理手順のフローチャートの一例を示す図である。 本実施形態の第２の処理手順のフローチャートの一例を示す図である。

以降、本発明を実施するための形態（「本実施形態」という）を、図等を参照しながら詳細に説明する。

図１に沿って、案件とモジュールとの関係を説明する。
案件とは、企業内において一般的に行われる業務である。いま、案件Ａは「決算」という名称が付され、案件Ｂは「法人税納税」という名称が付され、案件Ｃは「資産税納税」という名称が付されている。単純化のために、１つの案件には１つのアプリケーションが使用されるものとする。そしてそのアプリケーションにもやはり、「決算」、「法人税納税」及び「資産税納税」という名称が付されているものとする。

通常、「決算」が終了しなければその企業の年間利益が確定しないので、「法人税納税」を行うことはできない。「決算」が終了しなければ、企業が保有する償却資産の簿価が確定しないので、「資産税納税」を行うこともできない。その意味で、「決算」及び「法人税納税」は厳密な先後関係にある。同様に、「決算」及び「資産税納税」も厳密な先後関係にある。一方、「法人税納税」及び「資産税納税」は、相互にどちらが先であってもかまわない。このことは、「Ａ＜Ｂ＝Ｃ」と表現される（詳細後記）。

モジュールとは、前記したようにアプリケーションの構成要素である。図１の例では、モジュールは５つ存在する。それらは、「利益算出」ｍ１、「資産管理」ｍ２、「売上経費管理」ｍ３、「税額算出」ｍ４及び「銀行振込」ｍ５である。そして、アプリケーション「決算」は、モジュール「利益計算」ｍ１、モジュール「資産管理」ｍ２及びモジュール「売上経費管理」ｍ３から構成される。同様に、アプリケーション「法人税納税」は、モジュール「利益計算」ｍ１、モジュール「税額算出」ｍ４及びモジュール「銀行振込」ｍ５から構成される。アプリケーション「資産税納税」は、モジュール「資産管理」ｍ２、モジュール「税額算出」ｍ４及びモジュール「銀行振込」ｍ５から構成される。

案件Ａ「決算」が始まると、まず、その年の税制等を反映させる保守が、モジュールｍ１、ｍ２及びｍ３に対して行われる。そしてその後直ちに、保守後のモジュールｍ１、ｍ２及びｍ３を使用して案件Ａが障害なく実行されるか否かがテストされる。テストの結果に問題がなければ、保守後のモジュールｍ１、ｍ２及びｍ３を更新（コミット）したうえで、実際の「決算」が行われる。

同様に、案件Ｂ「法人税納税」が始まると、まず、その年の税制等を反映させる保守が、モジュールｍ１、ｍ４及びｍ５に対して行われる。そしてその後直ちに、保守後のモジュールｍ１、ｍ４及びｍ５を使用して案件Ｂが障害なく実行されるか否かがテストされる。いま、モジュールｍ１に注目すると、案件Ａについて１度更新された後、案件Ｂについて再度更新されようとしている。したがって、再度の更新が、（翌年度の）案件Ａに対して影響を与えることになるか否かを確認するために、案件Ａ及びＢの組合せテストを行う必要もある。そして、これらのテストの結果に問題がなければ、保守後のモジュールｍ１、ｍ４及びｍ５を更新したうえで、実際の「法人税納税」が行われる。

繰り返しの詳細説明は省略するが、同様に、案件Ｃ「資産税納税」について、モジュールｍ２、ｍ４及びｍ５を更新するには、案件Ｃについてのテストだけではなく、案件Ａ、Ｂ及びＣの組合せテストを行い、テスト結果に問題がないことが条件となる。

図２に沿って、モジュールが記憶される状態を説明する。
図２の左は、モジュールｍ１である。モジュールｍ１はメインデータ及びメタデータから構成される。メインデータは、「利益算出」を行うためのプログラムそのものである。モジュールｍ１のプログラムの機能は、例えば「売上経費期間配分」及び「資産減損処理」等である。メタデータは、モジュールを一意に特定する識別子（ｍ１）、モジュールの名称及びモジュールが更新された年月日を有する。更新日に注目すると、「２０１３０１０５」、「２０１３０１１０」及び「２０１３０１１２」の時点で、モジュールｍ１が更新され、それぞれの時点で更新された３つのモジュールｍ１が記憶されていることが分かる。モジュールｍ２（図２の中央）及びモジュールｍ３（図２の右）についても同様である。なお、実際は、年月日だけでなく時分秒単位で細かく更新時点が管理されているが、ここでは説明の単純化のために、年月日だけを記載した。

図３に沿って、案件保守管理装置１の構成を説明する。案件保守管理装置１は、一般的なコンピュータである。案件保守管理装置１は、中央制御装置１１、例えばマウス、キーボードのような入力装置１２、例えばディスプレイのような出力装置１３、主記憶装置１４、補助記憶装置１５及び通信装置１６を有している。これらの各装置は、バスによって相互に接続されている。補助記憶装置１５は、案件モジュール対応情報３１、コミット順序情報３２、更新履歴情報３３、コミット順序変更情報３４、コミット解除コスト算出情報３５、案件詳細情報３６及び案件評価情報３７を格納している（いずれも詳細後記）。補助記憶装置１５は、モジュール４１（図１における符号ｍ１等）も格納している。

主記憶装置１４内に記載されている更新履歴管理部２１は、プログラムである。本実施形態において、「○○部は」というように主体を記した場合は、中央制御装置１１が、そのプログラムを補助記憶装置１５から主記憶装置１４にロードしたうえで、そのプログラムの機能（詳細後記）を実現するのとする。
案件保守管理装置１は、ネットワーク３を介して、端末装置２と接続されている。端末装置２もまた同様に、相互にバスで接続された、中央制御装置、入力装置、出力装置、主記憶装置、補助記憶装置及び通信装置（図示せず）を有している。端末装置２は通常複数存在し、複数のユーザが、端末装置２を介してモジュール４１の保守を行う。もちろん、ユーザは、案件保守管理装置１を直接操作することによって、モジュール４１の保守を行うこともできる。

（案件モジュール対応情報）
図４（ａ）に沿って、案件モジュール対応情報３１を説明する。案件モジュール対応情報３１においては、案件ＩＤ欄１０１に記憶された案件ＩＤに関連付けて、モジュールＩＤ欄１０２にはモジュールＩＤが記憶されている。
案件ＩＤ欄１０１の案件ＩＤは、案件を一意に特定する識別子である。
モジュールＩＤ欄１０２のモジュールＩＤは、モジュールを一意に特定する識別子である。
図４（ａ）の例えば１行目に注目すると、案件ＩＤが「Ａ」である案件においては、モジュールＩＤが「ｍ１」、「ｍ２」及び「ｍ３」である３つのモジュールから構成されるアプリケーションが使用されることがわかる。これは、図１の、案件Ａ「決算」、モジュールｍ１「利益算出」、モジュールｍ２「資産管理」及びモジュールｍ３「売上経費管理」の関係そのものである。

（コミット順序情報）
図４（ｂ）に沿って、コミット順序情報３２を説明する。コミット順序情報３２においては、案件ＩＤ欄１１１に記憶された案件ＩＤに関連付けて、標準コミット順序欄１１２には標準コミット順序が記憶されている。
案件ＩＤ欄１１１の案件ＩＤは、図４（ａ）の案件ＩＤと同じである。
標準コミット順序欄１１２の標準コミット順序は、モジュールを更新する順序であって、案件に対して定義される。「標準」とは、順序が変更可能であることを意味する（詳細後記）。

案件ＩＤ「Ａ」等は、図１の「Ａ」等に対応している。すると、図４（ｂ）の１〜３行目のレコードは、まず「決算」について使用されるモジュールが更新され、次に、「法人税納税」について使用されるモジュールが更新され、最後に、「資産税納税」について使用されるモジュールが更新されるべきであることを示すことになる。なお、例えば１行目のレコードは、「決算」において、モジュールｍ１、ｍ２及びｍ３が、それぞれの間でどのような順序で更新されるかを決めているのではない。

（更新履歴情報）
図５に沿って、更新履歴情報３３を説明する。更新履歴情報３３においては、履歴ＩＤ欄１２１に記憶された履歴ＩＤに関連付けて、日時欄１２２には日時が、バージョン欄１２３には、バージョンが記憶されている。
履歴ＩＤ欄１２１の履歴ＩＤは、更新履歴情報３３のレコードを一意に特定する識別子である。
日時欄１２２の日時は、当該レコードが作成された年月日時分秒である。
バージョン欄１２３は、モジュールＩＤを見出しとする小欄１２３ａ〜１２３ｊを有している。小欄１２３ａ〜小欄１２３ｊのそれぞれには、バージョンが記憶されている。バージョンとは、案件ＩＤ（「Ａ」、「Ｂ」等）又は文字列「ｏｒｇ」である。「ｏｒｇ」は、そのモジュールが初期状態であることを示す。「Ａ」は、そのモジュールが、案件「Ａ」に使用されることによって更新されたことを示す。

図５の１行目のレコードに注目すると、日時「２０１３０１０５ １０：００：００」において、すべてのモジュールが初期状態にあることがわかる。
次いで、２行目のレコードに注目すると、日時「２０１３０１１０ １０：００：００」において、モジュールｍ１、モジュールｍ２及びモジュールｍ３が案件「Ａ」に使用されることによって更新されており、他のモジュールは初期状態のままであることがわかる。
さらに、３行目のレコードに注目すると、日時「２０１３０１１２ １０：００：００」において、モジュールｍ１、モジュールｍ４及びモジュールｍ５が案件「Ｂ」に使用されることによって更新されていることがわかる。そして、モジュールｍ２及びモジュールｍ３は、前回の更新以降変化がなく、他のモジュールは依然として初期状態のままであることもわかる。

最後に、４行目のレコードに注目すると、日時「２０１３０１１５ １０：００：００」において、モジュールｍ２、モジュールｍ４及びモジュールｍ５が案件「Ｃ」に使用されることによって更新されたことがわかる。そして、モジュールｍ１及びモジュールｍ３は、前回の更新以降変化がなく、他のモジュールは依然として初期状態のままであることもわかる。

視点を変えて、モジュールｍ１についての小欄１２３ａを列方向に見る。すると、モジュールｍ１は、初期状態から、案件「Ａ」に使用されて一度更新され、その後、案件「Ｂ」に使用されて再度更新されていることがわかる。図５からは直接わからないが、案件保守管理装置１は、モジュールｍ１の最新のバージョン「Ｂ」を補助記憶装置１５に必ず記憶している。そして、次にモジュールｍ１が更新される際は、モジュールｍ１の最新のバージョン「Ｂ」が基準になる。バージョン「Ｂ」が基準になるとは、変更された箇所がバージョン「Ｂ」に上書きされ、変更されなかった箇所についてはバージョン「Ｂ」のその箇所が単純にコピーされることによって、新たなバージョンが作成されることを意味する。要するに、バージョン「Ｂ」がコピーを作成する元になることを意味する。

案件保守管理装置１は、モジュールｍ１の旧バージョン「ｏｒｇ」及びモジュールｍ１の旧バージョン「Ａ」を記憶していてもかまわない（図２参照）。ただし、旧バージョンがコピーを作成する元になることは稀である。したがって、案件保守管理装置１は、旧バージョンに対して、コスト削減のための措置を講じる。当該措置は、例えば、旧バージョンを、補助記憶装置１５のうち比較的維持コストが小さい特定の領域に格納する、主記憶装置１４にキャッシュとして取り出さない、所定の時間が経過すると消去する、最新バージョンとの差分データのみとして記憶する、等の措置を含む。

（コミット推移）
図６及び図７に沿って、コミット推移を説明する。
いま、案件Ａが終了しており、案件Ｂも終了しており、案件Ｃが終了する直前の時点であるとする。更新履歴情報３３は、図６（ａ）の状態を経て、さらに図６（ｂ）の状態も経た後、図６（ｃ）の状態になっている。しかしながら、何らかの理由で、案件Ｂにおけるモジュールの更新はなかったこととして、案件Ｃにおけるモジュールの更新を行いたいような事情が生じたとする。

このような事情は、図１に示した「決算」、「法人税納税」及び「資産税納税」の例では発生しにくい。あえて想定すれば、「法人税納税」では、納税者が法人税（国税）を銀行口座に振込む際の手数料がかからないことを前提にモジュールｍ５の更新が行われていた。しかしながら、その後、「資産税納税」では、納税者が資産税（資産が所在する自治体の地方税）を銀行口座に振込む際の手数料が自治体ごとに異なることが判明した、のようなことはあり得る。このような場合、案件Ｂでのモジュールの更新を解除し、案件Ｃを開始し、案件Ａで更新したモジュールをコピー元として、案件Ｃで使用したモジュールを更新したいという動機が生じる。そして、それは可能であるか否かが問題となる。

それが可能であれば、更新履歴情報３３は、図６（ｃ）の状態から図７（ｄ）の状態に遷移する。つまり、「Ｈ０００３」のレコードが削除され、案件Ｂでのモジュールの更新が解除されることになる。このことを、「コミット解除」と呼ぶ。なお、図７（ｄ）の状態は図６（ｂ）の状態と同じである。その後、案件Ａで更新したモジュールをコピー元として、案件Ｃで使用したモジュールが更新されると、更新履歴情報３３は、図７（ｅ）の状態に遷移する。さらにその後、案件Ｃで更新したモジュールをコピー元として、案件Ｂで使用したモジュールが更新されると、更新履歴情報３３は、図７（ｆ）の状態に遷移する。

（標準コミット順序の変更）
標準コミット順序を変更することが可能であるか否かを判断する判断基準は３つ存在する。その第１は、コミット順序変更情報３４（図８）であり、その第２は、コミット解除コスト算出情報３５（図９（ａ））であり、その第３は、案件詳細情報（図１０（ａ））である。

（コミット順序変更情報）
図８に沿って、コミット順序変更情報３４を説明する。コミット順序変更情報３４においては、パターンＩＤ欄１３１に記憶されたパターンＩＤに関連付けて、変更パターン欄１３２には変更パターンが、適用フラグ欄１３３には適用フラグが記憶されている。
パターンＩＤ欄１３１のパターンＩＤは、変更パターン（直ちに後記）を一意に特定する識別子である。
変更パターン欄１３２の変更パターンは、複数の案件ＩＤを等号（＝）又は不等号（＜）で直列的に連結した数式であり、標準コミット順序に対して、どのような変更を行うことが可能であるかを示している。
適用フラグ欄１３３の適用フラグは、その変更パターンが実際に適用可能であることを示す情報であり、ここでは「○」である。

変更パターンについて更に詳しく説明する。一般的に、「Ａ＜Ｂ」は、案件Ｂに使用されるモジュールの更新が、案件Ａに使用されるモジュールの更新の後に行われなければならないことを示す。「Ａ＝Ｂ」は、案件Ａに使用されるモジュールの更新と、案件Ｂに使用されるモジュールの更新との前後関係は問われないことを示す。そして、「Ａ＜Ｂ＝Ｃ」は、「Ａ＜Ｂ」かつ「Ｂ＝Ｃ」を意味する。『「Ａ＜Ｂ」かつ「Ｂ＝Ｃ」』からは、当然に、「Ａ＜Ｃ」であることが導かれる。いま、案件の前後関係を「→」を使用して「前→後」のように表すことにする。すると、「Ａ＜Ｂ＝Ｃ」は、「Ａ→Ｂ→Ｃ」及び「Ａ→Ｃ→Ｂ」を許容する一方、「Ｂ→Ａ→Ｃ」、「Ｂ→Ｃ→Ａ」、「Ｃ→Ａ→Ｂ」及び「Ｃ→Ｂ→Ａ」を許容しないことになる。

（コミット解除コスト算出情報）
図９（ａ）に沿って、コミット解除コスト算出情報３５を説明する。コミット解除コスト算出情報３５においては、更新前案件ＩＤ欄１４１に記憶された更新前案件ＩＤに関連付けて、更新後案件ＩＤ欄１４２には更新後案件ＩＤが、差分データ量欄１４３には差分データ量が、作業時間欄１４４には作業時間が、作業賃金欄１４５には作業賃金が、テスト費用欄１４６にはテスト費用が記憶されている。

更新前案件ＩＤ欄１４１の更新前案件ＩＤは、モジュールのあるバージョンをコピー元にして他のバージョンを作成する場合の、「あるバージョン」が使用される案件の案件ＩＤである。「*」については後記する。
更新後案件ＩＤ欄１４２の更新後案件ＩＤは、モジュールのあるバージョンをコピー元にして他のバージョンを作成する場合の、「他のバージョン」が使用される案件の案件ＩＤである。
「*」は、その案件に係るモジュールが、既に更新されたうえで、補助記憶装置１５に記憶されていることを示す。「*」が付されていないということは、その案件に係るモジュールが更新されてはいないが、更新された状態を知ることができる状態にあることを示す。更新された状態を知ることができる状態とは、例えば、補助記憶装置１５に更新された状態で記憶される直前の、主記憶装置１４に一時的に記憶されている状態である。

差分データ量欄１４３の差分データ量は、更新前案件ＩＤが特定する案件において更新された（される予定の）モジュールと、更新後案件ＩＤが特定する案件において更新される予定の（更新された）対応するモジュールとの間の差分のデータ量である。さらに詳しく言えば、対応するモジュール間の差分のデータ量を、すべてのモジュールについて合計したデータ量である。
作業時間欄１４４の作業時間は、更新後案件ＩＤが特定する案件において、ユーザが差分データを作成するために要する時間である。
作業賃金欄１４５の作業賃金は、更新後案件ＩＤが特定する案件において、ユーザが差分データを作成することに対して支払われる賃金である。
テスト費用欄１４６のテスト費用は、更新後案件ＩＤが特定する案件におけるテストの費用である。ここで、テストとは、当該案件単体のテストであって、過去の案件分も併せた組合せテストではない。

案件保守管理装置１の更新履歴管理部２１は、案件Ａが終了し、案件Ｂも終了した時点で、図９（ａ）のレコードＲ_１を作成する。案件Ａにおいて更新されたモジュール（「ｏｒｇ」が元になっている）及び案件Ｂにおいて更新されたモジュール（「Ａ」が元になっている）の両者が、補助記憶装置１５に記憶されている。したがって、変更前案件ＩＤ欄１４１の「Ａ」には「*」が付されており、変更後案件ＩＤ欄１４２の「Ｂ」にも「*」が付されている。

更新履歴管理部２１は、案件Ａが終了し、案件Ｂも終了した後であって、案件Ｃが終了する直前の時点で、図９（ａ）のレコードＲ_２、Ｒ_３及びＲ_４を作成する。この時点では、案件Ａにおいて更新されたモジュール（「ｏｒｇ」が元になっている）及び案件Ｂにおいて更新されたモジュール（「Ａ」が元になっている）の両者が、補助記憶装置１５に記憶されている。さらに、案件Ｃにおいて更新される直前のモジュールが主記憶装置１４に一時的に記憶されている。したがって、変更前案件ＩＤ欄１４１及び変更後案件ＩＤ欄１４２の「Ｃ」には「*」が付されていない。

すると、更新履歴管理部２１は、「Ａ」を元とする場合と、「Ｂ」を元とする場合の２つにわけて、案件Ｃにおいて変更が加えられたモジュールを更新する際の差分データ量を算出することができる。同様に、更新履歴管理部２１は、将来に繰り返される案件Ｂにおいて「Ｃ」を元にしてモジュールを更新する際の差分データ量を算出することができる。さらに、更新履歴管理部２１は、例えば差分データ量に対して所定の換算係数を乗じて、作業時間、作業賃金及びテスト費用（いずれも想定値）を決定することができる。

案件Ａ、案件Ｂ及び案件Ｃに使用されるモジュールが図４（ａ）に示される通りであり、案件Ａ、案件Ｂ及び案件Ｃの標準コミット順序が、図４（ｂ）に示される通りであるとする。このとき、コミットを解除するコストを、図９（ａ）及び図９（ｂ）を用いて説明する。

（想定１）
図９（ｂ）の１行目に注目する。案件Ａ、案件Ｂ及び案件Ｃが、その順に予定通りに進捗した場合、最終的にかかる費用は、作業賃金として３０万円（欄１５３）であり、テスト費用として６０万円（欄１５４）である。これらの値は、図９（ａ）の、レコードＲ_１及びレコードＲ_３の作業賃金の和及びテスト費用の和である。同様に算出した最終的な差分データ量は３．０ＭＢ（欄１５１）であり、最終的な作業時間は３０時間（欄１５２）である。なお、バージョン「ｏｒｇ」からバージョン「Ａ」に至るコスト等は捨象する（想定２でも同様）。

（想定２）
続いて、図９（ｂ）の２行目に注目する。案件Ａが終了し、案件Ｂも終了した後、案件Ｃを開始し、案件Ｂの終了はなかったことにして、案件Ｃを終了し、その後、案件Ｂをやり直す場合を考える。最終的にかかる費用は、作業賃金として２２万円（欄１５３）であり、テスト費用として４４万円（欄１５４）である。これらの値は、図９（ａ）の、レコードＲ_１、Ｒ_２及びレコードＲ_４の作業賃金の和及びテスト費用の和である。同様に算出した最終的作業時間は２２時間（欄１５２）である。最終的な差分データは、１．２ＭＢ（欄１５１）である。この値は、図９（ａ）の、レコードＲ_２及びレコードＲ_４の差分データの和である。レコードＲ_１の「１．０ＭＢ」は、消去されてしまうものであり、加算する意味はない。

（想定１と想定２の比較）
図９（ｂ）の１行目及び２行目のレコードを比較すると、費用及び時間の観点からは、「想定１」の方が不利である。これは、案件Ｂで更新したモジュールをコピー元として案件Ｃで使用したモジュールを更新することは、案件Ａで更新したモジュールをコピー元として案件Ｃで使用したモジュールを更新することに比して変更部分が多いことを意味する。当然その差は、作業時間、作業賃金及びテスト費用に反映される。
差分データ量の観点からは、想定１と想定２との最終的な差分データ量の差は、３．０−１．２＝１．８ＭＢであり、実際上無視できる水準である。しかしながら、この差が膨大になり、かつ有料の外部リソースに記憶されるような場合は、無視できなくなる。

（案件詳細情報）
図１０（ａ）に沿って、案件詳細情報３６を説明する。案件詳細情報３６においては、案件ＩＤ欄１６１記憶された案件ＩＤに関連付けて、操作類型欄１６２には操作類型が、必要性類型欄１６３には必要性類型が、優先度欄１６４には優先度が、モジュール数欄１６５にはモジュール数が、更新回数欄１６６には更新回数が記憶されている。
案件ＩＤ欄１６１の案件ＩＤは、図４（ａ）の案件ＩＤと同じである。
操作類型欄１６２の操作類型は、「画面系」又は「バッチ系」のいずれかである。「画面系」は、その案件が、画面項目の追加等、ユーザが視認する画面の構成に影響を与える案件であることを示す。「バッチ系」は、その案件が、夜間一括処理における演算方法の変更等、バッチ処理に影響を与える案件であることを示す。

必要性類型欄１６３の必要性類型は、「Ｍ」又は「Ｃ」のいずれかである。「Ｍ」は、その案件が、バグ等の不具合に対する措置として必要であることを示す。「Ｃ」は、その案件が、制度の変更に伴う処理機能の追加等、業務の仕様を変更するために必要であることを示す。
優先度欄１６４の優先度は、案件の優先度を示す文字列であり、優先度が高い順に「緊急」、「高」、「中」及び「低」である。
モジュール数欄１６５のモジュール数は、その案件に使用されるアプリケーションを構成するモジュールの数である。
更新回数欄１６６の更新回数は、過去において、その案件が行われた結果、更新履歴情報３３（図５）のレコードが新たに作成された（更新された）回数である。
なお、「属性」には、操作類型、必要性類型、優先度、モジュール数及び更新回数が相当する。

（案件詳細情報）
図１０（ｂ）に沿って、案件評価情報３７を説明する。案件評価情報３７においては、項目欄１７１に記憶された項目に関連付けて、選択肢欄１７２には選択肢が、点数欄１７３には点数が記憶されている。
項目欄１７１の項目は、案件を評価する際の区分であり、図１０（ａ）において説明した「操作類型」、「必要性類型」、「優先度」、「モジュール数」及び「更新回数」である。
選択肢欄１７２の選択肢は、図１０（ａ）においてその項目が示す各欄１６２〜１６６において、記憶される値そのもの、又は、記憶される値が属する数値範囲である。
点数欄１７３の点数は、案件に対して、その項目について与えられる部分点である。点数は、ユーザが任意に設定することができる。点数は、複数の案件間において、案件の重要度を示す尺度になる。点数が大きい案件は、点数が小さい案件が先に更新されていても、点数が小さい案件の更新を削除したうえで、更新されることができる。

図１０（ｂ）のレコードを項目ごとに参照すると以下のことがわかる。
（１）操作類型（１及び２行目）
「バッチ系」の案件は、テスト後直ちに稼動されるとは限らない。したがって、「バッチ系」は、「画面系」よりも点数が低い。
（２）必要性類型（３及び４行目）
「Ｍ」の案件は、ユーザが現在直面している不具合を治癒するための案件である。したがって、「Ｍ」は、「Ｃ」よりも点数が高い。
（３）優先度（５〜８行目）
当然のことながら、優先度が高い案件であるほど、点数が大きい。
（４）モジュール数（９〜１３行目）
案件を構成するモジュールの数が多いということは、他の案件に対する影響が大きいということである。したがって、モジュール数が多い案件であるほど、点数が大きい。
（５）更新回数（１４〜１７行目）
案件の更新回数が多いということは、その案件に対する変更要求が大きいということである。したがって、更新回数が多い案件であるほど、点数が大きい。

（処理手順）
以降、処理手順を説明する。図１１の「第１の処理手順」は、コミット順序変更情報３４（図８）及びコミット解除コスト算出情報３５（図９（ａ））を使用する。図１２の「第２の処理手順」は、コミット順序変更情報３４（図８）及び案件詳細情報３６（図１０（ａ））を使用する。いずれの処理手順も、コミット解除が可能であるか否かを判断するものであり、相互に代替的な関係にある。

図１１に沿って、第１の処理手順を説明する。第１の処理手順が開始される時点で以下の前提１〜５が成立しているものとする。
（前提１）案件モジュール対応情報３１（図４（ａ））、コミット順序情報３２（図４（ｂ））及びコミット順序変更情報３４（図８）が、完成された状態で補助記憶装置１５に記憶されている。
（前提２）案件Ａ及び案件Ｂは既に終了している。したがって、更新履歴情報３３（図５）は、図６（ｃ）の状態で補助記憶装置１５に記憶されている。

（前提３）現在、案件Ｃが進行中であり、モジュールの変更（更新ではない）及びテストはすでに終了している。変更されたモジュールは、一時的に主記憶装置１４に記憶されている。
（前提４）ユーザは、案件Ｂにおいて更新したモジュールに何らかの不具合を発見している。その結果、ユーザは、バージョン「Ｂ」を元としてバージョン「Ｃ」を更新するのではなく、バージョン「Ａ」を元としてバージョン「Ｃ」を更新することを希望している。
（前提５）案件保守管理装置１は、現時点までに作成されたモジュールのバージョン「Ａ*」、「Ｂ*」、「Ｃ」の内容及びテスト内容から、差分データ量、作業時間、作業賃金及びテスト費用を算出している。その結果、コミット解除コスト算出情報３５（図９（ａ））が、完成された状態で補助記憶装置１５に記憶されている。
（前記６）ユーザは、端末装置２を使用して遠隔地より作業することも可能である。ただし、ここでは単純化のため、ユーザは案件保守管理装置１を使用して作業しているものとする。

（用語）
説明を単純にするために、以下の通り語義の定義を行う。
「操作中案件」又は「操作中の案件」：ユーザが現在操作している案件であって、モジュールを更新する前の案件である。
「直前案件」又は「直前の案件」：ユーザがモジュールの更新をするに際し、コピー元とすることを希望する案件である。
「最新案件」又は「最新の案件」：現時点において記憶されている更新履歴情報３３のレコードのうちの最新のレコードに初めて現れる案件である。

ステップＳ２０１において、案件保守管理装置１の更新履歴管理部２１は、モジュールを更新する旨の要求を受け付ける。具体的には、更新履歴管理部２１は、ユーザが入力装置１２を介して、当該要求を、直前案件ＩＤ及び操作中案件ＩＤとともに入力するのを受け付ける。操作中案件ＩＤとは、操作中案件の案件ＩＤである。直前案件ＩＤとは、直前案件の案件ＩＤである。ここでは、直前案件ＩＤとして「Ａ」が受け付けられ、操作中案件ＩＤとして「Ｃ」が受け付けられたものとして以降の説明を続ける。

ステップＳ２０２において、更新履歴管理部２１は、モジュールの更新を登録できるか否かを判断する。具体的には、更新履歴管理部２１は、第１に、コミット順序情報３２（図４（ｂ））から、直前案件ＩＤ及び操作中案件ＩＤに対応する標準コミット順序を取得する。ここでは、直前案件ＩＤについて「１」が、操作中案件ＩＤについて「３」が取得される。
更新履歴管理部２１は、第２に、更新履歴情報３３から最新案件ＩＤを取得する。最新案件ＩＤとは、最新案件の案件ＩＤである。ここでは、「Ｂ」が取得される。

更新履歴管理部２１は、第３に、以下の条件１及び条件２がすべて満たされるか否かを判断する。
（条件１）直前案件ＩＤが最新案件ＩＤに一致する。
（条件２）操作中案件ＩＤに対応する標準コミット順序が、直前案件ＩＤに対応する標準コミット順序の直後である。
ここでは、「条件１」は満たされず（Ａ≠Ｂ）、「条件２」も満たされない（「３」は「１」の直後ではない）。
更新履歴管理部２１は、第４に、判断の結果が「条件をすべて満たす」である場合（ステップＳ２０２“ＹＥＳ”）は、ステップＳ２０７に進み、それ以外の場合（ステップＳ２０２“ＮＯ”）は、ステップＳ２０３に進む。

ステップＳ２０３において、更新履歴管理部２１は、コミット順序を変更できるか否かを判断する。具体的には、更新履歴管理部２１は、第１に、コミット順序変更情報３４（図８）から、適用フラグが記憶されているレコードの変更パターンを取得する。ここでは、「Ａ＜Ｂ＝Ｃ」が取得される。
更新履歴管理部２１は、第２に、ステップＳ２０３の「第１」において取得した変更パターンが、直前案件ＩＤを「先」とし、操作中案件ＩＤを「後」とし、最新案件ＩＤを「そのさらに後」とする順序関係（この場合「Ａ→Ｃ→Ｂ」）を許容するか否かを判断する。ここでは、「Ａ＜Ｂ＝Ｃ」は、「Ａ→Ｃ→Ｂ」を許容する。
更新履歴管理部２１は、第３に、判断の結果が「許容する」である場合（ステップＳ２０３“ＹＥＳ”）は、ステップＳ２０４に進み、それ以外の場合（ステップＳ２０３“ＮＯ”）は、ステップＳ２０８に進む。

ステップＳ２０４において、更新履歴管理部２１は、コミット解除コストを算出する。具体的には、更新履歴管理部２１は、第１に、更新履歴情報３３及び操作中案件ＩＤに基づいて、コミット解除を実行しない場合の第１の更新順序を作成する。いま、更新履歴情報３３（図６（ｃ）の状態）の２行目にはバージョン「Ａ」が記憶されており、３行目にはバージョン「Ｂ」が記憶されており、操作中案件ＩＤは「Ｃ」である。したがって、第１の更新順序「Ａ→Ｂ→Ｃ」が作成される。
更新履歴管理部２１は、第２に、直前案件ＩＤ、操作中案件ＩＤ及び最新案件ＩＤに基づいて、コミット解除を実行する場合の第２の更新順序を作成する。ここでは、第２の更新順序は、「直前案件ＩＤ→最新案件ＩＤ×，直前案件ＩＤ→操作中案件ＩＤ→最新案件ＩＤ」＝「Ａ→Ｂ×，Ａ→Ｃ→Ｂ」となる。「×」は解除されるバージョンである。

更新履歴管理部２１は、第３に、図９（ａ）及び図９（ｂ）の説明において前記した方法によって、第１の更新順序及び第２の更新順序の両者について、最終的な差分データ量、作業時間、作業賃金及びテスト費用を算出する。ここでは、図９（ｂ）に示した通りの算出結果となる。
更新履歴管理部２１は、第４に、第１の比較値（直ちに後記）から第２の比較値（直ちに後記）を減算した結果である判断値を算出する。

更新履歴管理部２１は、第１の比較値として、以下の値を選択し得る。
（１）：第１の更新順序についての最終的な作業賃金
（２）：第１の更新順序についての最終的なテスト費用
（３）：第１の更新順序についての最終的な作業時間
（４）：第１の更新順序についての最終的な差分データ量
（５）：（３）の値に所定の換算係数を乗算した金額
（６）：（４）の値に所定の換算係数を乗算した金額
（７）：（１）、（２）、（５）及び（６）の値のうちの、少なくとも２つ以上の和
更新履歴管理部２１が、第２の比較値として、どのような値を選択し得るかについても全く同様である。

ステップＳ２０５において、更新履歴管理部２１は、判断値が閾値以上であるか否かを判断する。具体的には、更新履歴管理部２１は、ステップＳ２０４の「第４」において算出した判断値が所定の閾値以上である場合（ステップＳ２０５“ＹＥＳ”）は、ステップＳ２０６に進み、それ以外の場合（ステップＳ２０５“ＮＯ”）は、ステップＳ２０８に進む。

ステップＳ２０６において、更新履歴管理部２１は、コミット解除を行う。具体的には、更新履歴管理部２１は、更新履歴情報３３から、最新案件ＩＤに係るレコードを削除する。すると、更新履歴情報３３は、図６（ｃ）の状態から、図７（ｄ）の状態に遷移する。さらに、更新履歴管理部２１は、補助記憶装置１５から、最新案件ＩＤに係るモジュールそのものを削除する。

ステップＳ２０７において、更新履歴管理部２１は、コミットを行う。具体的には、更新履歴管理部２１は、第１に、操作中案件ＩＤを検索キーとして案件モジュール対応情報３１（図４（ａ））を検索し、該当するレコードのモジュールＩＤを取得する。
更新履歴管理部２１は、第２に、更新履歴情報３３（図５）の新たなレコードを作成する。
更新履歴管理部２１は、第３に、新たなレコードのバージョン欄１２３の小欄のうち、ステップＳ２０７の「第１」において取得したモジュールＩＤを見出しとして有する小欄に、操作中案件ＩＤを記憶する。他の小欄には、直前のレコードのバージョンを記憶する。
更新履歴管理部２１は、第４に、新たなレコードの履歴ＩＤ欄１２１及び日時欄１２２に、それぞれ、新たに採番した履歴ＩＤ及び現在の年月日時分秒を記憶する。この段階において、更新履歴情報３３は、図７（ｅ）の状態になっている。
更新履歴管理部２１は、第５に、直前案件ＩＤに係るモジュールをコピー元として、操作中案件ＩＤに係るモジュールを作成し、補助記憶装置１５に記憶する。その後、処理手順を終了する。

ステップＳ２０８において、更新履歴管理部２１は、エラーメッセージを出力する。具体的には、更新履歴管理部２１は、出力装置１３にメッセージ「コミット順序を変更することはできません」を表示する。その後、処理手順を終了する。

図１２に沿って、第２の処理手順を説明する。第２の処理手順が開始される時点で、前記した「前提１」、「前提２」、「前提３」、「前提４」及び「前記６」が成立しているものとする。そして前記した「前提５」の代わりに、以下の「前提７」が成立しているものとする。
（前提７）案件詳細情報３６（図１０（ａ））及び案件評価情報３７（図１０（ｂ））が、完成された状態で補助記憶装置１５に記憶されている。

第１の処理手順（図１１）と第２の処理手順（図１２）は、ステップＳ２０１〜Ｓ２０３及びＳ２０６〜Ｓ２０８を共有している。したがって、以降では、変更箇所であるステップＳ２０４ｂ及びＳ２０５ｂのみを説明する。

ステップＳ２０４ｂにおいて、更新履歴管理部２１は、案件の合計点数を算出する。具体的には、更新履歴管理部２１は、第１に、操作中案件ＩＤを検索キーとして案件詳細情報３６（図１０（ａ））を検索し、該当したレコードを取得する。
更新履歴管理部２１は、第２に、ステップＳ２０４ｂの「第１」において取得したレコードの各欄の見出し及びその欄の値を検索キーとして、案件評価情報３７（図１０（ｂ））を検索し、該当する５つのレコードの点数を取得する。そして取得した点数を合計し、第１の合計点数とする。操作中案件ＩＤは「Ｃ」であるので、合計点数は、「１＋２＋２＋１＋３＝９」となる。

更新履歴管理部２１は、第３に、最新案件ＩＤを検索キーとして案件詳細情報３６（図１０（ａ））を検索し、該当したレコードを取得する。
更新履歴管理部２１は、第４に、ステップＳ２０４ｂの「第３」において取得したレコードの各欄の見出し及びその欄の値を検索キーとして、案件評価情報３７（図１０（ｂ））を検索し、該当する５つのレコードの点数を取得する。そして取得した点数を合計し、第２の合計点数とする。最新案件ＩＤは「Ｂ」であるので、第２の合計点数は、「２＋３＋３＋１＋３＝１２」となる。
更新履歴管理部２１は、第５に、第１の合計点数から第２の合計点数を減算し、減算の結果を「合計点数の差」とする。このとき、合計点数の差は「９−１２＝△３」となる。

ステップＳ２０５ｂにおいて、更新履歴管理部２１は、合計点数の差が閾値以上であるか否かを判断する。具体的には、更新履歴管理部２１は、ステップＳ２０４ｂの「第５」における「合計点数の差」が所定の閾値以上である場合（ステップＳ２０５“ＹＥＳ”）は、ステップＳ２０６に進み、それ以外の場合（ステップＳ２０５“ＮＯ”）は、ステップＳ２０８に進む。
ここで、所定の閾値が「０」であるとする。すると、「△３＜０」であるので、更新履歴管理部２１は、ステップＳ２０８に進むことになる。このことは、案件Ｂの重要度は、案件Ｃの重要度よりも大きく、案件Ｃは、案件Ｂにおけるモジュールの更新を解除することができない（案件Ｃは、案件Ｂを追い越せない）ことを示す。

（第１の処理手順と第２の処理手順の組合せ）
第１の処理手順において、更新履歴管理部２１は、ステップＳ２０５“ＹＥＳ”の場合、第２の処理手順のステップＳ２０４ｂを実行し、その後直ちに第２の処理手順のステップＳ２０５ｂを実行してもよい。

（実施形態の効果）
本実施形態は、以下の効果を生む。
・複数のモジュールから構成されるアプリケーションを使用する複数の案件間のモジュールの更新順序について、更新済の案件の更新を解除して、操作中の案件を更新することが可能であるか否かが容易に判断できる。
・更新済の案件を元にして操作中の案件を更新する場合のコストと、更新済の案件の直前に更新された案件を元にして操作中の案件を更新する場合のコストと、を比較したうえで、前記判断をすることが可能になる。
・更新済の案件の重要度と、操作中の案件の重要度と、を比較したうえで、前記判断をすることが可能になる。

なお、本発明は前記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、前記した実施例は、本発明を分かり易く説明するために詳細に説明したものであり、必ずしも説明したすべての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
また、前記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウエアで実現してもよい。また、前記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウエアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしもすべての制御線や情報線を示しているとは限らない。実際には殆どすべての構成が相互に接続されていると考えてもよい。

１ 案件保守管理装置
２ 端末装置
３ ネットワーク
１１ 中央制御装置（制御部）
１２ 入力装置
１３ 出力装置
１４ 主記憶装置（記憶部）
１５ 補助記憶装置（記憶部）
１６ 通信装置
２１ 更新履歴管理部
３１ 案件モジュール対応情報
３２ コミット順序情報
３３ 更新履歴情報
３４ コミット順序変更情報
３５ コミット解除コスト算出情報
３６ 案件詳細情報
３７ 案件評価情報

Claims (7)

1. 複数のアプリケーションを構成する複数のモジュールごとに、前記アプリケーションによって実行される複数の案件のうちどの案件における操作によって当該モジュールが更新されたかを示すバージョンが、時系列で記憶される更新履歴情報と、
   前記案件が実行される順序を変更する場合における、可能な変更後の順序を示す変更パターンと、
   を格納する記憶部と、
   前記案件のうち既に終了している最新の案件において更新されたモジュールを削除し、前記最新の案件の直前の案件において更新されたモジュールを元にして、操作中の案件において前記モジュールを更新したい旨の要求を受け付け、
   前記直前の案件に始まり前記最新の案件を経て前記操作中の案件に至る第１の更新順序を、前記直前の案件に始まり前記操作中の案件を経て前記最新の案件に至る第２の更新順序に変更することが可能であるか否かを、前記変更パターンを参照することによって判断し、
   前記判断の結果が可能である場合は、前記更新履歴情報において、前記最新の案件についてのレコードを削除し、前記操作中の案件についてのレコードを記憶する制御部と、
   を備えることを特徴とする案件保守管理装置。
2. 前記記憶部は、
   ある案件において更新されたモジュールを元にして他の案件において前記モジュールを更新する場合のコストが、当該ある案件と当該他の案件の組合せごとに記憶されるコミット解除コスト算出情報を格納しており、
   前記制御部は、
   前記コミット解除コスト算出情報を参照し、
   前記第１の更新順序にしたがって前記複数の案件が実行されるコストの総量と、前記第２の更新順序にしたがって前記複数の案件が実行されるコストの総量との差を算出し、
   前記算出した差と所定の閾値との大小関係よって、前記第１の更新順序を前記第２の更新順序に変更することが可能であるか否かを判断すること、
   を特徴とする請求項１に記載の案件保守管理装置。
3. 前記コストは、
   差分データ量、作業時間、作業賃金、及び、テスト費用のうちの少なくとも１つを含むこと、
   を特徴とする請求項２に記載の案件保守管理装置。
4. 前記記憶部は、
   前記案件に関連付けて、前記案件の複数の属性が記憶される案件詳細情報と、
   前記複数の属性のそれぞれの値に関連付けて、前記案件の重要度を示す点数が記憶される案件評価情報と、
   を格納しており、
   前記制御部は、
   前記案件詳細情報及び前記案件評価情報を参照し、前記操作中の案件についての属性に基づき、前記操作中の案件の前記点数の合計値を取得し、さらに、前記最新の案件についての属性に基づき、前記最新の案件の前記点数の合計値を取得し、
   前記取得した操作中の案件の前記点数の合計値と、前記取得した最新の案件の前記点数の合計値との差を算出し、
   前記算出した合計値の差と所定の閾値との大小関係よって、前記第１の更新順序を前記第２の更新順序に変更することが可能であるか否かを判断すること、
   を特徴とする請求項１に記載の案件保守管理装置。
5. 前記属性は、
   前記案件の操作類型、前記案件の必要性類型、前記案件の優先度、前記案件を実行する前記アプリケーションを構成するモジュールの数、及び、前記案件の更新回数のうちの少なくとも１つを含むこと、
   を特徴とする請求項４に記載の案件保守管理装置。
6. 記憶部は、
   複数のアプリケーションを構成する複数のモジュールごとに、前記アプリケーションによって実行される複数の案件のうちどの案件における操作によって当該モジュールが更新されたかを示すバージョンが、時系列で記憶される更新履歴情報と、
   前記案件が実行される順序を変更する場合における、可能な変更後の順序を示す変更パターンと、
   を格納しており、
   制御部は、
   前記案件のうち既に終了している最新の案件において更新されたモジュールを削除し、前記最新の案件の直前の案件において更新されたモジュールを元にして、操作中の案件において前記モジュールを更新したい旨の要求を受け付け、
   前記直前の案件に始まり前記最新の案件を経て前記操作中の案件に至る第１の更新順序を、前記直前の案件に始まり前記操作中の案件を経て前記最新の案件に至る第２の更新順序に変更することが可能であるか否かを、前記変更パターンを参照することによって判断し、
   前記判断の結果が可能である場合は、前記更新履歴情報において、前記最新の案件についてのレコードを削除し、前記操作中の案件についてのレコードを記憶すること、
   を特徴とする、前記記憶部及び前記制御部を備える案件保守管理装置の案件保守管理方法。
7. 案件保守管理装置の記憶部に対し、
   複数のアプリケーションを構成する複数のモジュールごとに、前記アプリケーションによって実行される複数の案件のうちどの案件における操作によって当該モジュールが更新されたかを示すバージョンが、時系列で記憶される更新履歴情報と、
   前記案件が実行される順序を変更する場合における、可能な変更後の順序を示す変更パターンと、
   を格納させ、
   前記案件保守管理装置の制御部に対し、
   前記案件のうち既に終了している最新の案件において更新されたモジュールを削除し、前記最新の案件の直前の案件において更新されたモジュールを元にして、操作中の案件において前記モジュールを更新したい旨の要求を受け付け、
   前記直前の案件に始まり前記最新の案件を経て前記操作中の案件に至る第１の更新順序を、前記直前の案件に始まり前記操作中の案件を経て前記最新の案件に至る第２の更新順序に変更することが可能であるか否かを、前記変更パターンを参照することによって判断し、
   前記判断の結果が可能である場合は、前記更新履歴情報において、前記最新の案件についてのレコードを削除し、前記操作中の案件についてのレコードを記憶する処理を実行させること、
   を特徴とする、前記案件保守管理装置を機能させるための案件保守管理プログラム。
   
   
   

Images