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

Abstract

(57)【要約】 【課題】製品に対する複数の更新作業が並行して行われ
る状況において、製品リリース時の不具合を機械的に防
止する。 【解決手段】コンピュータに、複数のモジュールを含む
プログラム製品の更新時の不良を検出させるプログラム
であり、プログラム製品の更新作業を識別する更新識別
情報を付与するステップと、上記更新作業ごとに、更新
されたモジュールを識別する情報とそのモジュールの更
新時点を示す情報とを上記更新識別情報とともに記録す
るステップと、リリース予定の更新作業の対象モジュー
ルとリリース予定外の更新作業の対象モジュールとに対
して更新時点を比較する比較ステップと、リリース予定
のモジュールの更新時点が、そのモジュールに対応する
リリース予定外のモジュールの更新時点より新しいとき
に所定の処理の実行を指令するステップとを備える。

Description

【発明の詳細な説明】

【０００１】

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

【０００２】

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

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

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

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

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

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

【０００８】

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

【０００９】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００２３】

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

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

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

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

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

【００２８】また、世代は、バージョン、リビジョン等
とも呼ばれ、リリースされるプログラム製品を特定す
る。図２では、世代ごとの修正対象をインシデントＸ、
インシデントＹのように明示している。以下、図１にし
たがい、不具合発生の経緯を説明する。 （１）１２月７日（図１に示した「２００１年」は省略
する。省略以下同様である）に、インシデントＸ（A.cp
pというソースプログラム）を修正し、コンパイル完了
した。この場合、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.c
ppの修正結果が含まれていない。このため、後からリリ
ースされる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、DA
T、８mmテープ、メモリカード等がある。

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

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

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

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

【０１０６】＜その他＞さらに、本実施の形態は以下の
発明を開示する。 （付記１） コンピュータに、複数のモジュールを含む
プログラム製品の更新時の不良を検出させるプログラム
であり、プログラム製品の更新作業を識別する更新識別
情報を付与するステップと、前記更新作業ごとに、更新
されたモジュールを識別する情報とそのモジュールの更
新時点を示す情報とを前記更新識別情報とともに記録す
るステップと、リリース予定の更新作業の対象モジュー
ルとリリース予定外の更新作業の対象モジュールとに対
して更新時点を比較する比較ステップと、リリース予定
のモジュールの更新時点が、そのモジュールに対応する
リリース予定外のモジュールの更新時点より新しいとき
に所定の処理の実行を指令するステップとを備えるプロ
グラム。（１） （付記２） 更新作業ごとに識別され更新されたモジュ
ールを格納する、そのようなファイルにアクセスし、そ
のファイルの更新時点を参照するステップをさらに備
え、前記比較ステップおいては、リリース予定のモジュ
ールまたはリリース予定外のモジュールの少なくとも一
方について、ファイルから参照した更新時点に基づき前
記モジュールの更新時点が比較される付記１に記載のプ
ログラム。（２） （付記３） 前記所定の処理は、リリース予定のプログ
ラム製品のリリース延期である付記１または２に記載の
プログラム。（３） （付記４） 前記所定の処理は、リリース予定外のプロ
グラム製品で前記リリース予定のモジュールより古いモ
ジュールを含むプログラム製品のリリース促進処理であ
る付記１または２に記載のプログラム。（４） （付記５） コンピュータに、複数のモジュールを含む
プログラム製品の更新時の不良を検出させるプログラム
であり、プログラム製品の更新世代ごとにその更新世代
を識別する世代識別情報を付与するステップと、前記更
新世代ごとに、更新されたモジュールを識別する情報と
そのモジュールの更新時点を示す情報とを前記世代識別
情報とともに記録するステップと、リリース対象の更新
世代とリリース対象外の更新世代とにおいて更新されて
いるモジュールの更新時点を比較する比較ステップと、
リリース予定のモジュールの更新時点が、そのモジュー
ルに対応するリリース予定外のモジュールの更新時点よ
り新しいときに所定の処理の実行を指令するステップと
を備えるプログラム。 （付記６） コンピュータが、複数のモジュールを含む
プログラム製品の更新時の不良を検出する方法であり、
プログラム製品の更新作業を識別する更新識別情報を付
与するステップと、前記更新作業ごとに、更新されたモ
ジュールを識別する情報とそのモジュールの更新時点を
示す情報とを前記更新識別情報とともに記録するステッ
プと、リリース予定の更新作業の対象モジュールとリリ
ース予定外の更新作業の対象モジュールとに対して更新
時点を比較する比較ステップと、リリース予定のモジュ
ールの更新時点が、そのモジュールに対応するリリース
予定外のモジュールの更新時点より新しいときに所定の
処理の実行を指令するステップとを備える方法。（５） （付記７） コンピュータが、複数のモジュールを含む
プログラム製品の更新時の不良を検出する方法であり、
プログラム製品の更新世代ごとにその更新世代を識別す
る世代識別情報を付与するステップと、前記更新世代ご
とに、更新されたモジュールを識別する情報とそのモジ
ュールの更新時点を示す情報とを前記世代識別情報とと
もに記録するステップと、リリース対象の更新世代とリ
リース対象外の更新世代とにおいて更新されているモジ
ュールの更新時点を比較する比較ステップと、リリース
予定のモジュールの更新時点が、そのモジュールに対応
するリリース予定外のモジュールの更新時点より新しい
ときに所定の処理の実行を指令するステップとを備える
方法。 （付記８） 複数のモジュールを含むプログラム製品の
更新時の不良を検出する管理装置であり、プログラム製
品の更新作業を識別する更新識別情報を付与する手段
と、前記更新作業ごとに、更新されたモジュールを識別
する情報とそのモジュールの更新時点を示す情報とを前
記更新識別情報とともに記録する手段と、リリース予定
の更新作業の対象モジュールとリリース予定外の更新作
業の対象モジュールとに対して更新時点を比較する比較
手段と、リリース予定のモジュールの更新時点が、その
モジュールに対応するリリース予定外のモジュールの更
新時点より新しいときに所定の処理の実行を指令する手
段とを備える管理装置。 （付記９） 複数のモジュールを含むプログラム製品の
更新時の不良を検出する管理装置であり、プログラム製
品の更新世代ごとにその更新世代を識別する世代識別情
報を付与する手段と、前記更新世代ごとに、更新された
モジュールを識別する情報とそのモジュールの更新時点
を示す情報とを前記世代識別情報とともに記録する手段
と、リリース対象の更新世代とリリース対象外の更新世
代とにおいて更新されているモジュールの更新時点を比
較する比較手段と、リリース予定のモジュールの更新時
点が、そのモジュールに対応するリリース予定外のモジ
ュールの更新時点より新しいときに所定の処理の実行を
指令する手段とを備える管理装置。

【０１０７】

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

【図面の簡単な説明】

【図１】 プログラム製品リリース時の不具合発生例を
示す図

【図２】 本発明の一実施の形態に係る情報システムの
原理を示す図

【図３】 情報システムのシステム構成図

【図４】 情報システムのデータフロー図

【図５】 プログラム製品修正時の運用フローを示す図

【図６】 リリース時の運用フローを示す図

【図７】 修正モジュールリリース処理を示すフローチ
ャート

【図８】 レベルダウン防止チェック処理（図７のＳ
２）の詳細を示すフローチャート

【符号の説明】

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

Claims (5)

【特許請求の範囲】
1. 【請求項１】 コンピュータに、複数のモジュールを含
   むプログラム製品の更新時の不良を検出させるプログラ
   ムであり、 プログラム製品の更新作業を識別する更新識別情報を付
   与するステップと、 前記更新作業ごとに、更新されたモジュールを識別する
   情報とそのモジュールの更新時点を示す情報とを前記更
   新識別情報とともに記録するステップと、 リリース予定の更新作業の対象モジュールとリリース予
   定外の更新作業の対象モジュールとに対して更新時点を
   比較する比較ステップと、 リリース予定のモジュールの更新時点が、そのモジュー
   ルに対応するリリース予定外のモジュールの更新時点よ
   り新しいときに所定の処理の実行を指令するステップと
   を備えるプログラム。
2. 【請求項２】 更新作業ごとに識別され更新されたモジ
   ュールを格納する、そのようなファイルにアクセスし、
   そのファイルの更新時点を参照するステップをさらに備
   え、 前記比較ステップおいては、リリース予定のモジュール
   またはリリース予定外のモジュールの少なくとも一方に
   ついて、ファイルから参照した更新時点に基づき前記モ
   ジュールの更新時点が比較される請求項１に記載のプロ
   グラム。
3. 【請求項３】 前記所定の処理は、リリース予定のプロ
   グラム製品のリリース延期である請求項１または２に記
   載のプログラム。
4. 【請求項４】 前記所定の処理は、リリース予定外のプ
   ログラム製品で前記リリース予定のモジュールより古い
   モジュールを含むプログラム製品のリリース促進処理で
   ある請求項１または２に記載のプログラム。
5. 【請求項５】 コンピュータが、複数のモジュールを含
   むプログラム製品の更新時の不良を検出する方法であ
   り、 プログラム製品の更新作業を識別する更新識別情報を付
   与するステップと、 前記更新作業ごとに、更新されたモジュールを識別する
   情報とそのモジュールの更新時点を示す情報とを前記更
   新識別情報とともに記録するステップと、 リリース予定の更新作業の対象モジュールとリリース予
   定外の更新作業の対象モジュールとに対して更新時点を
   比較する比較ステップと、 リリース予定のモジュールの更新時点が、そのモジュー
   ルに対応するリリース予定外のモジュールの更新時点よ
   り新しいときに所定の処理の実行を指令するステップと
   を備える方法。