JP4769826B2 - レベルダウン検出プログラム、レベルダウン検出方法、及び、管理プログラム - Google Patents

Description

本発明は、プログラム製品の更新管理技術に関するものである。

企業間の競争が厳しい産業分野では、新製品や後継製品のリリース周期が極めて短い。例えば、パーソナルコンピュータ、サーバ、ＰＤＡあるいは携帯電話等の情報機器では、数ヶ月のサイクルで新製品が出荷される。さらに、これらの情報機器では、新製品の出荷の他、現製品の不具合を対策した改訂製品の出荷も煩雑に行われる。このため、短期間に複数世代に渡る製品の開発が並行して行われる場合も多い。

また、このような製品の１つの世代には、通常、複数の修正作業や更新作業が含まれる。そのような複数の修正作業や更新作業が並行して行われる場合も多い。

このような情報機器は、周知のようにハードウェアとプログラム製品の組み合わせにより動作する。また、そのうち、プログラム製品は、多数のモジュールの組み合わせから構成されている。

さらに、情報機器に含まれるプログラム製品は一般的に大規模であり、多数の開発者により開発され、あるいは更新されている。したがって、短期間に、複数の世代に渡って、新製品、後継製品、または改訂製品が開発される場合には、各世代に渡って修正モジュールが正確に管理される必要がある。

特に、プログラム製品の開発においては、開発者ごとの個別作業の後、結合テスト、さらにシステムテストという工程を経て、プログラム製品がリリースされる。また、プログラム製品は、関連するソースプログラムを１箇所にまとめて保持し、コンパイルする統合コンパイル環境で開発される場合が多い。

このような統合コンパイル環境で、複数の修正作業や、複数世代に渡る製品の開発が並行して行われる場合、１つの世代における特定のソースプログラムまたは特定モジュールにおける変更や修正が他の世代の開発内容に悪影響を及ぼす場合がある。従来は、そのようなプログラム製品の世代間の整合性や、修正作業間の整合性を人手で確認するような作業が行われていた。そのような人手による確認作業は、多大な時間を要し、人為的なミスが発生する場合もあった。

本発明はこのような従来の技術の問題点に鑑みてなされたものである。すなわち、本発明の課題は、製品に対する複数の更新作業が並行して行われる状況において、製品リリース時の不具合を機械的に防止することにある。

本発明は上記課題を解決するために、以下の手段を採用した。すなわち、本発明は、コンピュータに、複数のモジュールを含むプログラム製品の更新時の不良を検出させるプログラムであり、プログラム製品の更新作業を識別する更新識別情報を付与するステップと、上記更新作業ごとに、更新されたモジュールを識別する情報とそのモジュールの更新時点を示す情報とを上記更新識別情報とともに記録するステップと、リリース予定の更新作
業の対象モジュールとリリース予定外の更新作業の対象モジュールとに対して更新時点を比較する比較ステップと、リリース予定のモジュールの更新時点が、そのモジュールに対応するリリース予定外のモジュールの更新時点より新しいときに所定の処理の実行を指令するステップとを備えるものである。

ここで、更新作業を識別する情報は、プログラム製品の所定の部分に対して所定の期間に行う更新、修正等を識別する。この情報は、例えば、修正番号と呼ばれ、このような更新作業が１以上組み合わせられ、プログラム製品の世代を構成する。なお、プログラム製品の世代を版、バージョン、またはリビジョンともいう。

本プログラムを実行するコンピュータは、リリース予定の更新作業とリリース予定外の更新作業とにおいて、対応するモジュールの更新日付を比較する。この更新日付には、時間を含めてもよい。

そして、このコンピュータは、リリース予定のモジュールの更新時点が、そのモジュールに対応するリリース予定外のモジュールの更新時点より新しいときに、不良の可能性があるとして、所定の処理の実行を指示する。

このようにして、本プログラムを実行するコンピュータは、１つのプログラム製品に対する複数の更新作業が並行して実施されているような場合でも、機械的にプログラム製品の更新に伴う不良を検出する。

好ましくは、更新作業ごとに識別され更新されたモジュールを格納する、そのようなファイルにアクセスし、そのファイルの更新時点を参照するステップをさらに備え、上記比較ステップおいては、リリース予定のモジュールまたはリリース予定外のモジュールの少なくとも一方について、ファイルから参照した更新時点に基づき上記モジュールの更新時点が比較されるようにしてもよい。

すなわち、上記コンピュータは、更新モジュールに関して記録された、モジュールを識別する情報とそのモジュールの更新時点を示す情報により、更新時点を比較するのでなく、モジュールを格納するファイルにアクセスし、ファイルの更新情報を入手する。このため、上記コンピュータは、確実にモジュールの更新時点を把握できる。

好ましくは、上記所定の処理は、リリース対象のプログラム製品のリリース延期である。また、好ましくは、上記所定の処理は、リリース対象外のプログラム製品で上記リリース予定のモジュールより古いモジュールを含むプログラム製品のリリースの促進処理であってもよい。ここで、リリースの促進処理とは、例えば、リリース対象外のプログラム製品のテストの実施である。

また、本発明は、コンピュータに、複数のモジュールを含むプログラム製品の更新時の不良を検出させるプログラムであり、プログラム製品の更新世代ごとにその更新世代を識別する世代識別情報を付与するステップと、上記更新世代ごとに、更新されたモジュールを識別する情報とそのモジュールの更新時点を示す情報とを上記世代識別情報とともに記録するステップと、リリース対象の更新世代とリリース対象外の更新世代とにおいて更新されているモジュールの更新時点を比較する比較ステップと、リリース予定のモジュールの更新時点が、そのモジュールに対応するリリース予定外のモジュールの更新時点より新しいときに所定の処理の実行を指令するステップとを備えるものでもよい。

ここで、更新世代とは、プログラム製品の１以上の更新作業の結果を含む、プログラム製品の履歴上の世代をいう。世代を版、バージョン、またはリビジョンともいう。ただし
、この更新世代が１つの更新作業に対応するものであってもよい。

このプログラムを実行するコンピュータは、リリース対象の更新世代とリリース対象外の更新世代とにおいて、対応するモジュールの更新日付を比較する。この更新日付には、時間を含めてもよい。

そして、上記コンピュータは、リリース予定のモジュールの更新時点が、そのモジュールに対応するリリース予定外のモジュールの更新時点より新しいときに、不良の可能性があるとして、所定の処理の実行を指示する。

このようにして、上記コンピュータは、プログラム製品が複数の世代について並行して更新されているような場合でも、機械的にプログラム製品の更新に伴うの不良を検出する。

本発明は、コンピュータその他の装置、機械等が上記いずれかの処理を実行する方法であってもよい。また、本発明は、コンピュータその他の装置、機械等に、以上のいずれかの機能を実現させるプログラムをコンピュータ等が読み取り可能な記録媒体に記録したものでもよい。

以上説明したように、本発明によれば、製品に対する複数の更新作業が並行して行われる状況において、製品リリースの不具合を機械的に防止することができる。

以下、本発明の一実施の形態に係る情報システムを図１から図８の図面に基いて説明する。

図１は、プログラム製品リリース時の不具合発生例を示す図であり、図２は、本情報システムの原理を示す図であり、図３は、本情報システムのシステム構成図であり、図４は、本情報システムのデータフロー図であり、図５は、プログラム製品修正時の運用フローを示す図であり、図６は、リリース時の運用フローを示す図であり、図７は、本情報システムにおける修正モジュールリリース処理を示すフローチャートであり、図８は、レベルダウン防止チェック処理（図７のＳ２）の詳細を示すフローチャートである。

＜機能概要＞
図１に、プログラム製品リリース時の不具合発生例を示す。この図１では、１つのプログラム製品の２つの世代が、短期間にリリースされる状況での不具合発生例の経緯を示している。

ここで、プログラム製品とは、例えば、パーソナルコンピュータ上で利用されるシステムプログラムやアプリケーションプログラム等である。本実施の形態では、プログラム製品を資産ともいう。

このようなプログラム製品は、一般的には、複数のモジュールから構成される。図１では、そのようなモジュールの例としてA.dllというファイル（ダイナミックリンクライブ
ラリ）が示されている。また、ここでは、A.cppおよびB.cppというソースプログラムをコンパイルしたファイル（いわゆるロードモジュール）がA.dllに含まれると仮定する。

また、世代は、バージョン、リビジョン等とも呼ばれ、リリースされるプログラム製品を特定する。図２では、世代ごとの修正対象をインシデントＸ、インシデントＹのように
明示している。以下、図１にしたがい、不具合発生の経緯を説明する。

（１）１２月７日（図１に示した「２００１年」は省略する。省略以下同様である）に、インシデントＸ（A.cppというソースプログラム）を修正し、コンパイル完了した。この
場合、A.cppのコンパイル結果（これをロードモジュールと呼ぶ）が含まれるダイナミッ
クリンクライブラリA.dll全体がコンパイルされる。このとき作成されるダイナミックリ
ンクライブラリをA.dll５０と呼ぶ。このA.dll５０は、テスト待ちの状態に置かれる（矢印１０１）。

（２）１２月１０日に、インシデントＹ（B.cppというソースプログラム）を修正し、コ
ンパイル完了した。このB.cppのコンパイル結果は、上記と同一のダイナミックリンクラ
イブラリA.dllに含まれる。

したがって、ダイナミックリンクライブラリA.dll全体が再びコンパイルされる。この
コンパイルは、統合コンパイル環境で実行されるため、インシデントＸで修正されたA.cppもコンパイルされる。このコンパイルによって生成されたダイナミックリンクライブラ
リをA.dll５１と呼ぶ。このA.dll５１も、テスト待ちの状態に置かれる（矢印１０２）。

（３）１２月１０日に、インシデントＹ（B.cpp）に対応するA.dll５１のテストが完了し（矢印１０３）、インシデントＹ対応モジュールとしてA.dll５１がリリースされる（矢
印１０４）。ただし、この時点で、インシデントＸに対するテストは、未完である。

（４）１２月１２日に、インシデントＸ（A.cpp）に対応するA.dll５０のテストが完了し（矢印１０５）、インシデントＸ対応モジュールとしてA.dll５０がリリースされる（矢
印１０６）。

この状況では、以下のような不具合が含まれる（この不具合をレベルダウンともいう）。

第１に、上記（３）で述べたように、インシデントＹに対応するA.dll５１は、テスト
未完のA.cppのコンパイル結果が含まれているにも拘わらず、そのままリリースされてし
まう。

第２に、上記（４）において後からリリースされるA.dll５０には、インシデントＹに
対応するB.cppの修正結果が含まれていない。このため、後からリリースされるA.dll５０により、先にリリースされたA.dll５１を上書きすると、リリースを受けるユーザ側でイ
ンシデントＹの修正結果が消滅してしまう。

図２は、このような不具合を回避する本情報システムの原理を示す図である。図２では、プログラム製品にユーザ（リリース担当の管理者）がそのような不具合の有無をチェックするレベルダウンチェック画面１９と、そのレベルダウンチェック画面１９から指示により実行される処理の概要が示されている。

このレベルダウンチェック画面１９は、画面中央部の設定リリースＶＬ（バージョンレベル）欄３１、コメント欄３２、予定ＶＬ欄３３、レベルダウンチェック表示欄３４、表示ボタン、チェックボタン２０および画面下部の設定対象資産欄３５を有している。

管理者は、設定リリースＶＬ３１に、リリース対象のプログラムのバージョンを示すバージョンレベルを設定する。バージョンレベルは、例えば、Ｖ１０Ｌ１０等の文字列である。

また、管理者は、コメント欄３２に、そのバージョンレベルに関するコメントを設定する。コメントは、例えば、「障害Ｎｏ．００１１対応モジュール」等である。

また、管理者は、予定ＶＬ欄３３に、リリース予定となっているバージョンレベルを設定、表示ボタンを押下することにより、そのバージョンレベルに属する修正Ｎｏ．の一覧を表示することができる。そのような修正Ｎｏ．の一覧は、設定対象資産欄３５に表示される。

ここで、修正Ｎｏ．とは、プログラム製品に対する１まとまりの修正作業や更新作業を特定する情報である。また、修正Ｎｏ．は、そのような修正作業や更新作業の結果を特定する。そして、そのような修正作業、更新作業の結果が１以上組み合わせられて１つのバージョンレベルを構成する。

また、レベルダウンチェック表示欄３４には、レベルダウンチェック実行の有無が表示される。

設定対象資産欄３５には、リリース予定の修正Ｎｏ．の一覧が表示される。この設定対象資産欄３５の表の各行は、リリース対象チェックマーク、修正番号、および案件番号の各フィールドを有している。ここで、チェックマークは、その修正Ｎｏ．の修正作業による修正結果がリリース対象であることを指定する。

管理者が所望の修正番号の行について、リリース対象チェックマークを設定し、チェックボタン２０を押下することにより、レベルダウンチェックが開始する。

例えば、図２の例では、リリース対象の修正番号（００１〜００３）で示されるプログラム製品のリリースモジュール管理テーブルが読み出され、リリース対象となっていない修正番号のモジュール管理テーブルと比較される。

リリースモジュール管理テーブルには、ソースプログラムのコンパイルにより更新されたモジュールが記録される。図２のように、リリースモジュール管理テーブルは、修正Ｎｏ．により識別され、当該修正作業で改造されたモジュールの一覧を有している。また、モジュールの一覧には、改造されたモジュール名とそのモジュールが更新された更新日付（コンパイルの日付）が含まれる。

ここで、例えば、修正Ｎｏ．０００１のリリースモジュール管理テーブル２０Ａに記録されたモジュールA.dllの更新日付は、２００１年１２月１０日である。一方、修正Ｎｏ
．００３１のリリースモジュール管理テーブル２０Ｂに記録されたモジュールA.dllの更
新日付は、２００１年１２月７日である。

したがって、修正Ｎｏ．０００１で特定される今回リリース対象のモジュールの中に、今回リリース対象でない（後からリリースされる）モジュールより修正日付が新しいものがある。

このような状況では、図１において述べたように、修正Ｎｏ．００１のリリース時にＡ.dllには、未テストの改造が含まれる可能性がある。また、後に、修正Ｎｏ．００３１のリリースにより、リリース済みの内容が抹消される可能性がある。

一方、例えば、修正Ｎｏ．０００１のモジュールB.dllの更新日付は、１２月１１日で
あり、修正Ｎｏ．００３１のモジュールB.dllの更新日付１２月１８日より、古い。した
がって、モジュールB.dllには、不具合は含まれていないことが分かる。

また、修正Ｎｏ．０００１のリリースモジュール管理テーブル２０Ａには、Y.EXE、Z.dllというモジュールが記録されている。しかし、これらのモジュールは、修正Ｎｏ．００３１のリリースモジュール管理テーブル２０Ｂには記録されていない。これは、Y.EXEお
よびZ.dllが修正Ｎｏ．０００１では更新されたが、修正Ｎｏ．００３１では、更新され
なかったことを示す。

また、修正Ｎｏ．００３１のリリースモジュール管理テーブル２０Ｂには、XX01.EXE、XX02.EXE等のモジュールが記録されている。しかし、これらのモジュールは、修正Ｎｏ．０００１のリリースモジュール管理テーブル２０Ａには記録されていない。

このように、２つのリリースモジュール管理テーブルの一方に記録され、他方のリリースモジュール管理テーブルに記録されていないモジュールは、不具合を発生しない。リリースモジュール管理テーブルに記録されていないモジュールは、コンパイルされていないからである。

＜システム構成＞
図３は、本情報システムのシステム構成図である。この情報システムは、ウェブサーバ１、資産管理サーバ２、開発サーバ３（コンパイルサーバを含む）、リリースサーバ４（テストサーバを含む）、障害・Ｑ／Ａ登録サーバ５およびＳＱＬサーバ６を有している。

資産管理サーバ２は、資産管理プログラムを実行し、プログラム製品、各プログラム製品を構成するモジュール、プログラム製品やモジュールをコンパイルするためのソースプログラム等のバージョンを管理する。ここで、資産管理とは、いわゆるプログラム製品のバージョン管理をいう。

コンパイルサーバを含む開発サーバ３は、ソースプログラムの編集やコンパイル等に使用される。テストサーバを含むリリースサーバ４は、プログラム製品のテスト環境を提供する。

障害・Ｑ／Ａ登録サーバ５は、サービス部門等からの障害情報の通知、Ｑ／Ａ（質問とその回答）等を登録する。ＳＱＬサーバ６は、開発環境に関する情報や、障害・Ｑ／Ａ登録サーバ５から登録された情報を保持する。

ウェブサーバ１は、管理者や開発者が使用する端末１０に対し、ウェブページを提供し、バージョン管理に関する情報、ソースプログラムの入出庫、障害情報、Ｑ／Ａ（プログラム製品に関する質問および回答）等を提供する。

また、ウェブサーバ１は、資産管理コントロール部（プログラム）を実行し、プログラム製品リリース時における不良、すなわち、レベルダウンを検出する。

＜システム運用フロー＞
図４は、本情報システムのデータフロー図である。この情報システムでは、プログラム製品のソースプログラムが世代ごとに区別され、原本２１としてデータベースに保存されている。

ユーザは、自身の端末１０を通じて情報システムにアクセスし、原本２１から必要なソースプログラムを取得する。すなわち、ユーザは、所定のウェブページにアクセスし、更新に必要なソースプログラムを指定してソースプログラムの貸出を資産管理サーバ２に依
頼する。すると、資産管理サーバ２は、管理用発行フォルダ２２に出力され、さらに、開発サーバ３の貸出フォルダ２３に移動される（図４の（１）（ここでは、まる１を（１）と表記する。以下同様））。ユーザは、開発サーバ３の貸出フォルダ２３から自身の端末１０にそのソースプログラムを複写し、プログラムの修正作業を行う。ただし、ユーザは、貸出フォルダ２３において、そのままプログラムの修正作業を行ってもよい。

修正完了後、ユーザは、修正後のソースプログラムを返却フォルダ２４に返却する。そして、ユーザは、所定のウェブページにアクセスし、そのソースプログラムの返却操作を行う。この返却操作により、返却フォルダ２４のソースプログラムが管理受付用フォルダ２５に転送される。また、返却フォルダ２４のソースプログラムが統合コンパイル環境フォルダ２６に転送される（図４の（２））。

コンパイルサーバは、複写したソースプログラムおよびそのソースプログラムと同一のモジュールに組み込まれるすべてのソースプログラムをコンパイルし、更新されたモジュールを作成する。

さらに、コンパイルサーバは、更新したモジュールを管理用受付フォルダ２５に返却する（図４の（３））。このとき、資産管理サーバ２は、修正Ｎｏ．を発行し、修正モジュール管理テーブルに、その修正Ｎｏ．および返却されたモジュールのモジュール名と更新日付を記録する。また、コンパイルサーバは、更新したモジュールを統合テスト環境に合致するディレクトリ構成に変更する（図４の（４））。

そして、コンパイルサーバは、そのモジュールをテスト展開待ちディレクトリ２９に格納する（図４の（５））。統合テスト環境を提供するテストサーバ４は、テスト展開待ちディレクトリ２９に格納されたモジュールを順次読み出し、テスト環境に展開する。

テストサーバ４では、統合テスト環境において、更新されたモジュールのテストが実行される。テストが正常に終了すると、ユーザは、テストが完了した修正Ｎｏ．を所定のウェブページに入力する。この入力により、資産管理サーバ２は、管理用受付フォルダ２５から更新されたモジュールを原本２１に登録する（図４の（６））。

管理者は、テストが完了した修正Ｎｏ．のうち、リリース対象となる修正Ｎｏ．を収集し、リリースするバージョンレベルを設定する。そして、そのバージョンレベルに含まれる修正Ｎｏ．の修正結果について、レベルダウンチェックを実行する。

レベルダウンチェックが正常に終了すると、管理者は、作業フォルダを介して、そのバージョンレベルに含まれるモジュールをリモートメンテナンスサーバのリリース環境フォルダ２８に転送する（図４の（７））。

リモートメンテナンスサーバは、エンドユーザとの契約条件にしたがい、所定の時期にリリース環境フォルダ２８のモジュールをエンドユーザのコンピュータに転送する。

図５に、プログラム製品修正時の運用フローを示す。まず、ユーザ（図５では開発者と記載）は、所定のウェブページへの操作により、原本２１から修正対象のソースプログラムを自身の端末１０に取り出す（図５の（１））。ユーザは、修正作業を完了後、上記ウェブページへの操作により、修正されたソースプログラムを返却用一時ディレクトリ２４Ａに返却する（図５の（３））。ここで、返却用一時ディレクトリ２４Ａとは、図４に示す返却フォルダ２４および管理用受付フォルダ２５に対応する。

返却されたソースは、コンパイル環境フォルダ２６に転送される（図５の（４））。こ
のコンパイル環境フォルダ２６でソースプログラムのコンパイルが実行される。このような修正されたソースプログラムに関連するコンパイルだけを実行する技術は、例えば、ｕｎｉｘシステムではｍａｋｅコマンドとして広く知られている。

次に、コンパイル結果の差分が抽出される（図５の（６））。差分とは、コンパイル環境に転送されたソースプログラムをコンパイルすることにより更新されるモジュールの集合をいう。この差分は、返却用一時ディレクトリ２４Ａとテスト環境フォルダ２７の両方にコピーされる。

テストサーバ４は、コピーされた差分（更新されたモジュールの集合）をテスト環境に展開する（図５の（７））。ここで展開とは、更新されたモジュールをテスト環境にインストールすることをいう。ユーザは、テスト環境でテストを実行する（図５の（８））。

テスト完了後、ユーザは所定のウェブページにテスト完了を設定する。この設定により、テスト完了の電子メールが管理者に通知される（図５の（１０））。管理者は、所定のウェブページを通じて修正終了の承認処理を実行する（図５の（１１））。この承認処理により、返却用一時フォルダのファイル（修正済みのソースプログラムおよび更新されたモジュール）が原本２１に反映される。また、このとき、対応する修正Ｎｏ．のリリースモジュール管理テーブルに、更新モジュール名および更新日付が記録される（図５の（１２））。

図６に、リリース時の運用フローを示す。この処理では、管理者は、レベルダウンチェック画面１９においてリリース対象の修正番号を選択する（図６の（１））。

そして、管理者は、このレベルダウンチェック画面１９上のチェックボタン１８（図２参照）を押下し、レベルダウンチェックの実行を指定する。これにより、レベルダウンチェック、すなわち、プログラム製品リリース時の不具合チェックが実行される（図６の（２））。

すると、資産管理サーバ２は、リリース対象の修正Ｎｏ．とリリース対象でない修正Ｎｏ．について、リリースモジュール管理テーブル（図６のテーブル２０Ａと２０Ｂ）を比較する。この比較において、リリース対象のモジュールの更新日付がリリース対象でないモジュールの更新日付より新しい場合に（リリース対象外のモジュールの更新日付がリリース対象のモジュールの更新日付より古い場合に）、不具合、すなわち、レベルダウンが検出される。

次に、資産管理サーバ２は、リリース対象の修正Ｎｏ．で識別されるリリースモジュール管理テーブルに記録されたモジュールの更新日付と、テスト環境フォルダ２７に保持され、そのモジュールを格納するファイルの更新日付とを比較する。この比較において、リリース対象のモジュールの更新日付がテスト環境フォルダ２７において同一名称のモジュールを格納したファイルの更新日付より新しい場合に（テスト環境フォルダ２７のファイルの更新日付が古い場合に）、不具合、すなわち、レベルダウンが検出される。

次に、不具合が検出されない場合、資産管理サーバ２は、リリース対象の修正Ｎｏ．を所定のウェブページに表示する。管理者は、リリース対象の修正Ｎｏ．を確認し、リリース対象を決定する（図６の（３））。

資産管理サーバ２は、確認された修正Ｎｏ．で識別されるリリースモジュール管理テーブルを基に、原本２１からリリース対象のモジュールを抽出する（図６の（４））。

＜作用＞
図７に、本情報システムにおける修正モジュールリリース処理を示す。この処理は、図３に示した資産管理サーバ２が情報処理プログラムを実行することにより実現される。

この処理では、資産管理サーバ２は、まず、管理者によりリリース対象の選択を受ける（Ｓ１）。次に、資産管理サーバ２は、レベルダウン防止チェック処理を実行する（Ｓ２）。

次に、資産管理サーバ２は、レベルダウンの可能があるか否かを判定する（Ｓ３）。レベルダウンの可能性がない場合（Ｓ３の判定でＮＯの場合）、資産管理サーバ２は、リリース対象モジュールを抽出し、処理を終了する（Ｓ４）。

一方、レベルダウンの可能性がある場合（Ｓ３の判定でＹＥＳの場合）、資産管理サーバ２は、管理者からレベルダウン防止の処置の選択を受ける（Ｓ５）。レベルダウン防止処置が、「繰り上げリリース」であった場合、資産管理サーバ２は、リリース非対象であるが古い更新日付のモジュールに対応する修正番号のテストを促す。

これにより、例えば、所定のメッセージが開発者の端末１０に通知される。開発者は当該修正番号のテストを完了し、完了報告を通知する。この通知を受けることにより、資産管理サーバ２は、当該修正番号のプログラム製品をリリース対象とし、制御をＳ１に戻す。

また、レベルダウン防止処置が、「リリース延期」であった場合、資産管理サーバ２は、リリース対象として設定されている修正番号をリリース非対象とする（Ｓ７）。そして、資産管理サーバ２は、制御をＳ１に戻す。

図８に、レベルダウン防止チェック処理（図７のＳ２）の詳細を示す。この処理では、資産管理サーバ２は、まず、リリース対象の修正番号で識別されるリリースモジュール管理テーブルとリリース非対象の修正番号で識別されるリリースモジュール管理テーブルとを比較する（Ｓ２１）。

リリース対象の修正番号で識別されるリリースモジュール管理テーブルに記録されたモジュールがリリース非対象のリリースモジュール管理テーブルに記録された同一名のモジュールより古くない場合（Ｓ２２でＮＯの場合）、資産管理サーバ２は、エラー情報を出力し、処理を終了する（Ｓ２６）。

一方、リリース対象の修正番号で識別されるリリースモジュール管理テーブルに記録されたモジュールがリリース非対象のリリースモジュール管理テーブルに記録された同一名のモジュールより古い場合（Ｓ２２でＹＥＳの場合）、資産管理サーバ２は、次のデータがあるか否かを判定する（Ｓ２３）。次のデータがあるとは、リリース対象の修正番号で識別されるリリースモジュール管理テーブルに残りデータがある場合、または、次のリリース対象の修正番号で識別されるリリースモジュール管理テーブルがある場合をいう。

Ｓ２３の判定で次のデータがある場合、資産管理サーバ２は、制御をＳ２１に戻す。また、Ｓ２３の判定で、次のデータがない場合、資産管理サーバ２は、リリース対象の修正番号で識別されるリリースモジュール管理テーブルに記録されたモジュールの更新日付とそのモジュールを格納するファイル（例えば、統合テスト環境でテスト待ちのモジュール）の日付を比較する（Ｓ２４）。

そして、リース対象の修正番号で識別されるリリースモジュール管理テーブルに記録さ
れたモジュールの更新日付の方が古くない場合（Ｓ２５でＮＯの場合）、資産管理サーバ２は、エラー情報を出力し、処理を終了する（Ｓ２６）。

一方、リース対象の修正番号で識別されるリリースモジュール管理テーブルに記録されたモジュールの更新日付の方が古い場合（Ｓ２５でＹＥＳの場合）、資産管理サーバ２は、次のデータがあるか否かを判定する（Ｓ２７）。

Ｓ２７の判定で次のデータがある場合、資産管理サーバ制御をＳ２４に戻す。また、Ｓ２７の判定で、次のデータがない場合、資産管理サーバ２は、処理完了メッセージを表示し、処理を終了する（Ｓ２８）。

以上述べたように、本情報システムによれば、プログラム製品に対する複数の更新作業が並行して実施され、リリースされるような場合において、機械的にリリースの不具合を防止することができる。

すなわち、すでにリリース済み世代のプログラム製品に含まれていたモジュールより古いをモジュールを後発世代のプログラム製品に含めてリリースしてしまうような場合を検出できる。

また、統合コンパイル環境、すなわち、特定モジュールまたはすべてのプログラム製品のソースプログラムを１つの領域（例えば、フォルダやディレクトリ等）でコンパイルするような環境において、リリース対象のプログラム製品に、修正された後テスト未完のソースプログラムに対応する部分（ロードモジュールまたはオブジェクトモジュール）が含まれている可能性がある場合に、そのような部分を含む可能性のあるモジュールを検出できる。

＜変形例＞
上記実施形態では、ウェブサーバ１、資産管理サーバ２、開発サーバ３、コンパイルサーバ、リリースサーバ４、テストサーバ等および端末１０により情報システムを構成した。しかし、本発明の実施は、このようなコンピュータの構成に限定されるものではない。

例えば、１台のサーバで、上記サーバの機能を提供するようにしてもよい。また、逆に、各サーバを複数のコンピュータによって構成してもよい。さらに、１台のコンピュータによるスタンドアロンの環境で、上記情報システムの機能を実現してもよい。

上記実施形態では、リリース対象のリリースモジュール管理テーブルとリリース非対象のリリースモジュール管理テーブルとを比較して、不具合がなかったとき、さらに、リリース対象のリリースモジュール管理テーブルに記録されたモジュールの更新日付とそのモジュールを格納するファイルの更新日付を比較した。

しかし、本発明の実施は、このような手順には限定されない。例えば、リリース対象のモジュールのファイルと、統合テスト環境でテスト待ち（テスト中を含む）のモジュールのファイルとの間で、更新日付を比較してもよい。すなわち、リリースモジュール管理テーブルには、修正番号と、その修正番号に含まれるモジュールを格納するファイル名を記録しておき、ファイル同士で更新日付を比較してもよい。

上記実施形態では、プログラム製品に対する１まとまりの修正作業や更新作業を修正Ｎｏ．で特定し、そのような複数の修正作業の結果や更新作業の結果を組み合わせて１つのバージョンレベル（世代）を構成した。そして、レベルダウンチェックは、リリース対象の修正Ｎｏ．の修正作業とリリース対象外の修正Ｎｏ．の修正作業との間で、対応するモ
ジュールの修正日付を比較することにより行った。

しかし、そのようなリリース対象の修正Ｎｏ．とリリース対象外の修正Ｎｏ．との間で、対応するモジュールの修正日付を比較する代わり、リリース対象の世代とリリース対象外の世代との間で、対応するモジュールの修正日付を比較してもよい。

すなわち、修正Ｎｏ．により特定される修正作業ごとにモジュールを比較するのでなく、プログラム製品の世代同士で対応するモジュールを比較するようにしてもよい。例えば、先にリリースされる世代のプログラム製品のモジュールで、後からリリースされる世代のプログラム製品の対応するモジュールより更新日付が新しいものが検出された場合に、レベルダウンとして、所定の処理を実行するようにすればよい。

＜コンピュータ読み取り可能な記録媒体＞
コンピュータに上記いずれかの機能を実現させるプログラムをコンピュータが読み取り可能な記録媒体に記録することができる。そして、コンピュータに、この記録媒体のプログラムを読み込ませて実行させることにより、その機能を提供させることができる。

ここで、コンピュータ読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータから読み取ることができる記録媒体をいう。このような記録媒体の内コンピュータから取り外し可能なものとしては、例えばフロッピー（登録商標）ディスク、光磁気ディスク、CD-ROM、CD-R/W、DVD、DAT、８mmテープ、メモリカード等がある。

また、コンピュータに固定された記録媒体としてハードディスクやＲＯＭ（リードオンリーメモリ）等がある。

＜搬送波に具現化されたデータ通信＞
また、上記プログラムは、コンピュータのハードディスクやメモリに格納し、通信媒体を通じて他のコンピュータに配布することができる。この場合、プログラムは、搬送波によって具現化されたデータ通信信号として、通信媒体を伝送される。そして、その配布を受けたコンピュータに上記機能を提供させることができる。

ここで通信媒体としては、有線通信媒体、例えば、同軸ケーブルおよびツイストペアケーブルを含む金属ケーブル類、光通信ケーブル等、または、無線通信媒体例えば、衛星通信、地上波無線通信等のいずれでもよい。

また、搬送波は、データ通信信号を変調するための電磁波または光である。ただし、搬送波は、直流信号でもよい。この場合、データ通信信号は、搬送波がないベースバンド波形になる。したがって、搬送波に具現化されたデータ通信信号は、変調されたブロードバンド信号と変調されていないベースバンド信号（電圧０の直流信号を搬送波とした場合に相当）のいずれでもよい。

＜その他＞
さらに、本実施の形態は以下の発明を開示する。

（付記１）
コンピュータに、複数のモジュールを含むプログラム製品の更新時の不良を検出させるプログラムであり、
プログラム製品の更新作業を識別する更新識別情報を付与するステップと、
前記更新作業ごとに、更新されたモジュールを識別する情報とそのモジュールの更新時
点を示す情報とを前記更新識別情報とともに記録するステップと、
リリース予定の更新作業の対象モジュールとリリース予定外の更新作業の対象モジュールとに対して更新時点を比較する比較ステップと、
リリース予定のモジュールの更新時点が、そのモジュールに対応するリリース予定外のモジュールの更新時点より新しいときに所定の処理の実行を指令するステップと
を備えるプログラム。

（付記２）
更新作業ごとに識別され更新されたモジュールを格納する、そのようなファイルにアクセスし、そのファイルの更新時点を参照するステップをさらに備え、
前記比較ステップおいては、リリース予定のモジュールまたはリリース予定外のモジュールの少なくとも一方について、ファイルから参照した更新時点に基づき前記モジュールの更新時点が比較される
付記１に記載のプログラム。

（付記３）
前記所定の処理は、リリース予定のプログラム製品のリリース延期である
付記１または２に記載のプログラム。

（付記４）
前記所定の処理は、リリース予定外のプログラム製品で前記リリース予定のモジュールより古いモジュールを含むプログラム製品のリリース促進処理である
付記１または２に記載のプログラム。

（付記５）
コンピュータに、複数のモジュールを含むプログラム製品の更新時の不良を検出させるプログラムであり、
プログラム製品の更新世代ごとにその更新世代を識別する世代識別情報を付与するステップと、
前記更新世代ごとに、更新されたモジュールを識別する情報とそのモジュールの更新時点を示す情報とを前記世代識別情報とともに記録するステップと、
リリース対象の更新世代とリリース対象外の更新世代とにおいて更新されているモジュールの更新時点を比較する比較ステップと、
リリース予定のモジュールの更新時点が、そのモジュールに対応するリリース予定外のモジュールの更新時点より新しいときに所定の処理の実行を指令するステップと
を備えるプログラム。

（付記６）
コンピュータが、複数のモジュールを含むプログラム製品の更新時の不良を検出する方法であり、
プログラム製品の更新作業を識別する更新識別情報を付与するステップと、
前記更新作業ごとに、更新されたモジュールを識別する情報とそのモジュールの更新時点を示す情報とを前記更新識別情報とともに記録するステップと、
リリース予定の更新作業の対象モジュールとリリース予定外の更新作業の対象モジュールとに対して更新時点を比較する比較ステップと、
リリース予定のモジュールの更新時点が、そのモジュールに対応するリリース予定外のモジュールの更新時点より新しいときに所定の処理の実行を指令するステップと
を備える方法。

（付記７）
コンピュータが、複数のモジュールを含むプログラム製品の更新時の不良を検出する方法であり、
プログラム製品の更新世代ごとにその更新世代を識別する世代識別情報を付与するステップと、
前記更新世代ごとに、更新されたモジュールを識別する情報とそのモジュールの更新時点を示す情報とを前記世代識別情報とともに記録するステップと、
リリース対象の更新世代とリリース対象外の更新世代とにおいて更新されているモジュールの更新時点を比較する比較ステップと、
リリース予定のモジュールの更新時点が、そのモジュールに対応するリリース予定外のモジュールの更新時点より新しいときに所定の処理の実行を指令するステップと
を備える方法。

（付記８）
複数のモジュールを含むプログラム製品の更新時の不良を検出する管理装置であり、
プログラム製品の更新作業を識別する更新識別情報を付与する手段と、
前記更新作業ごとに、更新されたモジュールを識別する情報とそのモジュールの更新時点を示す情報とを前記更新識別情報とともに記録する手段と、
リリース予定の更新作業の対象モジュールとリリース予定外の更新作業の対象モジュールとに対して更新時点を比較する比較手段と、
リリース予定のモジュールの更新時点が、そのモジュールに対応するリリース予定外のモジュールの更新時点より新しいときに所定の処理の実行を指令する手段と
を備える管理装置。

（付記９）
複数のモジュールを含むプログラム製品の更新時の不良を検出する管理装置であり、
プログラム製品の更新世代ごとにその更新世代を識別する世代識別情報を付与する手段と、
前記更新世代ごとに、更新されたモジュールを識別する情報とそのモジュールの更新時点を示す情報とを前記世代識別情報とともに記録する手段と、
リリース対象の更新世代とリリース対象外の更新世代とにおいて更新されているモジュールの更新時点を比較する比較手段と、
リリース予定のモジュールの更新時点が、そのモジュールに対応するリリース予定外のモジュールの更新時点より新しいときに所定の処理の実行を指令する手段と
を備える管理装置。

プログラム製品リリース時の不具合発生例を示す図 本発明の一実施の形態に係る情報システムの原理を示す図 情報システムのシステム構成図 情報システムのデータフロー図 プログラム製品修正時の運用フローを示す図 リリース時の運用フローを示す図 修正モジュールリリース処理を示すフローチャート レベルダウン防止チェック処理（図７のＳ２）の詳細を示すフローチャート

符号の説明

１ ウェブサーバ
２ 資産管理サーバ
３ 開発サーバ（コンパイルサーバ）
４ リリースサーバ（テストサーバ）
１０ 端末
１９ レベルダウンチェック画面１９
２１ 原本

Claims (4)

1. 複数のモジュールにより構成されるコンピュータプログラムのユーザへのリリースでのレベルダウンを検出するためのレベルダウン検出プログラムであって、
   コンピュータを、
   前記コンピュータプログラムになされた複数の更新作業にそれぞれ対応する複数のリリースモジュール管理テーブルにおいて、その更新作業を特定する更新作業情報と、そのバージョンレベルのコンピュータプログラムを構成する１つ以上のモジュールを特定するモジュール名称と、前記各モジュールがコンパイルされて更新された日時を特定する更新日時情報とを、関連付けて記憶する記憶手段、
   ユーザへのリリースの対象とするバージョンレベルを特定するバージョンレベル情報を、操作者から受け付ける受付手段、
   前記受付手段が受け付けたバージョンレベル情報にて特定されるバージョンレベルに属する更新作業情報の一覧を表示する表示手段、
   前記表示手段が表示した一覧の中からユーザによって選択された更新作業情報を取得する取得手段、
   前記取得手段が取得した更新作業情報にて特定される更新作業のリリースモジュール管理テーブルと同じモジュール名称を含むとともに、そのモジュールの更新日時情報よりも古い日時を特定する更新日時情報を含むリリースモジュール管理テーブルを、検索する検索手段、及び、
   前記検索手段が何れかのリリースモジュール管理テーブルを検出した場合に、エラー情報を出力する出力手段
   として機能させる
   ことを特徴とするレベルダウン検出プログラム。
2. 複数のモジュールにより構成されるコンピュータプログラムのユーザへのリリースでのレベルダウンを検出するためのレベルダウン検出方法であって、
   コンピュータが、
   前記コンピュータプログラムになされた複数の更新作業にそれぞれ対応する複数のリリースモジュール管理テーブルにおいて、その更新作業を特定する更新作業情報と、そのバージョンレベルのコンピュータプログラムを構成する１つ以上のモジュールを特定するモジュール名称と、前記各モジュールがコンパイルされて更新された日時を特定する更新日時情報とを、関連付けて記憶する記憶手順、
   ユーザへのリリースの対象とするバージョンレベルを特定するバージョンレベル情報を、操作者から受け付ける受付手順、
   前記受付手順で受け付けたバージョンレベル情報にて特定されるバージョンレベルに属する更新作業情報の一覧を表示する表示手順、
   前記表示手順で表示した一覧の中からユーザによって選択された更新作業情報を取得する取得手順、
   前記取得手順で取得した更新作業情報にて特定される更新作業のリリースモジュール管理テーブルと同じモジュール名称を含むとともに、そのモジュールの更新日時情報よりも古い日時を特定する更新日時情報を含むリリースモジュール管理テーブルを、検索する検索手順、及び、
   前記検索手順で何れかのリリースモジュール管理テーブルを検出した場合に、エラー情報を出力する出力手順
   を実行する
   ことを特徴とするレベルダウン検出方法。
3. 複数のモジュールを含むコンピュータプログラムの更新時の不良を検出するための管理プログラムであって、
   コンピュータに、
   前記コンピュータプログラムの更新作業ごとに、その更新作業を識別するための更新識別情報と、その更新作業で更新されたモジュールを識別するためのモジュール識別情報と、そのモジュールの更新時点を示す更新時点情報とを、テーブルに記録する記録ステップ、
   前記複数の更新作業の更新識別情報のうち、エンドユーザのコンピュータへ提供すべき対象となるモジュールが更新された更新作業の更新識別情報を、リリース予定に含める指定を受け付ける受付ステップ、
   前記受付ステップでリリース予定に含める指定がなされた更新識別情報にて特定されるモジュールの更新時点を示す更新時点情報と、前記受付ステップで前記リリース予定に含める指定がなされていないリリース予定外の更新識別情報で特定されるモジュールの更新時点を示す更新時点情報とを、比較する比較ステップ、及び、
   前記比較ステップでの比較の結果、前記リリース予定に含める指定がなされた更新識別情報で特定されるモジュールの更新時点が、その同一のモジュールについて前記リリース予定外の更新識別情報にて特定される更新時点より新しいときに、前記リリース予定に係るモジュールを含む前記コンピュータプログラムのリリースを延期する指令を出力する出力ステップ
   を実行させる
   ことを特徴とする管理プログラム。
4. 複数のモジュールを含むコンピュータプログラムの更新時の不良を検出するための管理プログラムであって、
   コンピュータに、
   前記コンピュータプログラムの更新作業ごとに、その更新作業を識別するための更新識別情報と、その更新作業で更新されたモジュールを識別するためのモジュール識別情報と、そのモジュールの更新時点を示す更新時点情報とを、テーブルに記録する記録ステップ、
   前記複数の更新作業の更新識別情報のうち、エンドユーザのコンピュータへ提供すべき対象となるモジュールが更新された更新作業の更新識別情報を、リリース予定に含める指定を受け付ける受付ステップ、
   前記受付ステップでリリース予定に含める指定がなされた更新識別情報にて特定されるモジュールの更新時点を示す更新時点情報と、前記受付ステップで前記リリース予定に含める指定がなされていないリリース予定外の更新識別情報で特定されるモジュールの更新時点を示す更新時点情報とを、比較する比較ステップ、及び、
   前記比較ステップでの比較の結果、前記リリース予定に含める指定がなされた更新識別情報で特定されるモジュールの更新時点が、その同一のモジュールについて前記リリース予定外の更新識別情報にて特定される更新時点より新しいときに、前記リリース予定外に係るモジュールのうち、前記リリース予定に係るモジュールよりも更新時点の古いモジュールについて、テストの実施を促すための指令を出力する出力ステップ
   を実行させる
   ことを特徴とする管理プログラム。

Images