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

レベルダウン検出プログラム、レベルダウン検出方法、及び、管理プログラム Download PDF

Info

Publication number
JP4769826B2
JP4769826B2 JP2008032887A JP2008032887A JP4769826B2 JP 4769826 B2 JP4769826 B2 JP 4769826B2 JP 2008032887 A JP2008032887 A JP 2008032887A JP 2008032887 A JP2008032887 A JP 2008032887A JP 4769826 B2 JP4769826 B2 JP 4769826B2
Authority
JP
Japan
Prior art keywords
update
module
release
information
time
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
JP2008032887A
Other languages
English (en)
Other versions
JP2008176803A (ja
Inventor
正 佐藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2008032887A priority Critical patent/JP4769826B2/ja
Publication of JP2008176803A publication Critical patent/JP2008176803A/ja
Application granted granted Critical
Publication of JP4769826B2 publication Critical patent/JP4769826B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Landscapes

  • Stored Programmes (AREA)

Description

本発明は、プログラム製品の更新管理技術に関するものである。
企業間の競争が厳しい産業分野では、新製品や後継製品のリリース周期が極めて短い。例えば、パーソナルコンピュータ、サーバ、PDAあるいは携帯電話等の情報機器では、数ヶ月のサイクルで新製品が出荷される。さらに、これらの情報機器では、新製品の出荷の他、現製品の不具合を対策した改訂製品の出荷も煩雑に行われる。このため、短期間に複数世代に渡る製品の開発が並行して行われる場合も多い。
また、このような製品の1つの世代には、通常、複数の修正作業や更新作業が含まれる。そのような複数の修正作業や更新作業が並行して行われる場合も多い。
このような情報機器は、周知のようにハードウェアとプログラム製品の組み合わせにより動作する。また、そのうち、プログラム製品は、多数のモジュールの組み合わせから構成されている。
さらに、情報機器に含まれるプログラム製品は一般的に大規模であり、多数の開発者により開発され、あるいは更新されている。したがって、短期間に、複数の世代に渡って、新製品、後継製品、または改訂製品が開発される場合には、各世代に渡って修正モジュールが正確に管理される必要がある。
特に、プログラム製品の開発においては、開発者ごとの個別作業の後、結合テスト、さらにシステムテストという工程を経て、プログラム製品がリリースされる。また、プログラム製品は、関連するソースプログラムを1箇所にまとめて保持し、コンパイルする統合コンパイル環境で開発される場合が多い。
このような統合コンパイル環境で、複数の修正作業や、複数世代に渡る製品の開発が並行して行われる場合、1つの世代における特定のソースプログラムまたは特定モジュールにおける変更や修正が他の世代の開発内容に悪影響を及ぼす場合がある。従来は、そのようなプログラム製品の世代間の整合性や、修正作業間の整合性を人手で確認するような作業が行われていた。そのような人手による確認作業は、多大な時間を要し、人為的なミスが発生する場合もあった。
本発明はこのような従来の技術の問題点に鑑みてなされたものである。すなわち、本発明の課題は、製品に対する複数の更新作業が並行して行われる状況において、製品リリース時の不具合を機械的に防止することにある。
本発明は上記課題を解決するために、以下の手段を採用した。すなわち、本発明は、コンピュータに、複数のモジュールを含むプログラム製品の更新時の不良を検出させるプログラムであり、プログラム製品の更新作業を識別する更新識別情報を付与するステップと、上記更新作業ごとに、更新されたモジュールを識別する情報とそのモジュールの更新時点を示す情報とを上記更新識別情報とともに記録するステップと、リリース予定の更新作
業の対象モジュールとリリース予定外の更新作業の対象モジュールとに対して更新時点を比較する比較ステップと、リリース予定のモジュールの更新時点が、そのモジュールに対応するリリース予定外のモジュールの更新時点より新しいときに所定の処理の実行を指令するステップとを備えるものである。
ここで、更新作業を識別する情報は、プログラム製品の所定の部分に対して所定の期間に行う更新、修正等を識別する。この情報は、例えば、修正番号と呼ばれ、このような更新作業が1以上組み合わせられ、プログラム製品の世代を構成する。なお、プログラム製品の世代を版、バージョン、またはリビジョンともいう。
本プログラムを実行するコンピュータは、リリース予定の更新作業とリリース予定外の更新作業とにおいて、対応するモジュールの更新日付を比較する。この更新日付には、時間を含めてもよい。
そして、このコンピュータは、リリース予定のモジュールの更新時点が、そのモジュールに対応するリリース予定外のモジュールの更新時点より新しいときに、不良の可能性があるとして、所定の処理の実行を指示する。
このようにして、本プログラムを実行するコンピュータは、1つのプログラム製品に対する複数の更新作業が並行して実施されているような場合でも、機械的にプログラム製品の更新に伴う不良を検出する。
好ましくは、更新作業ごとに識別され更新されたモジュールを格納する、そのようなファイルにアクセスし、そのファイルの更新時点を参照するステップをさらに備え、上記比較ステップおいては、リリース予定のモジュールまたはリリース予定外のモジュールの少なくとも一方について、ファイルから参照した更新時点に基づき上記モジュールの更新時点が比較されるようにしてもよい。
すなわち、上記コンピュータは、更新モジュールに関して記録された、モジュールを識別する情報とそのモジュールの更新時点を示す情報により、更新時点を比較するのでなく、モジュールを格納するファイルにアクセスし、ファイルの更新情報を入手する。このため、上記コンピュータは、確実にモジュールの更新時点を把握できる。
好ましくは、上記所定の処理は、リリース対象のプログラム製品のリリース延期である。また、好ましくは、上記所定の処理は、リリース対象外のプログラム製品で上記リリース予定のモジュールより古いモジュールを含むプログラム製品のリリースの促進処理であってもよい。ここで、リリースの促進処理とは、例えば、リリース対象外のプログラム製品のテストの実施である。
また、本発明は、コンピュータに、複数のモジュールを含むプログラム製品の更新時の不良を検出させるプログラムであり、プログラム製品の更新世代ごとにその更新世代を識別する世代識別情報を付与するステップと、上記更新世代ごとに、更新されたモジュールを識別する情報とそのモジュールの更新時点を示す情報とを上記世代識別情報とともに記録するステップと、リリース対象の更新世代とリリース対象外の更新世代とにおいて更新されているモジュールの更新時点を比較する比較ステップと、リリース予定のモジュールの更新時点が、そのモジュールに対応するリリース予定外のモジュールの更新時点より新しいときに所定の処理の実行を指令するステップとを備えるものでもよい。
ここで、更新世代とは、プログラム製品の1以上の更新作業の結果を含む、プログラム製品の履歴上の世代をいう。世代を版、バージョン、またはリビジョンともいう。ただし
、この更新世代が1つの更新作業に対応するものであってもよい。
このプログラムを実行するコンピュータは、リリース対象の更新世代とリリース対象外の更新世代とにおいて、対応するモジュールの更新日付を比較する。この更新日付には、時間を含めてもよい。
そして、上記コンピュータは、リリース予定のモジュールの更新時点が、そのモジュールに対応するリリース予定外のモジュールの更新時点より新しいときに、不良の可能性があるとして、所定の処理の実行を指示する。
このようにして、上記コンピュータは、プログラム製品が複数の世代について並行して更新されているような場合でも、機械的にプログラム製品の更新に伴うの不良を検出する。
本発明は、コンピュータその他の装置、機械等が上記いずれかの処理を実行する方法であってもよい。また、本発明は、コンピュータその他の装置、機械等に、以上のいずれかの機能を実現させるプログラムをコンピュータ等が読み取り可能な記録媒体に記録したものでもよい。
以上説明したように、本発明によれば、製品に対する複数の更新作業が並行して行われる状況において、製品リリースの不具合を機械的に防止することができる。
以下、本発明の一実施の形態に係る情報システムを図1から図8の図面に基いて説明する。
図1は、プログラム製品リリース時の不具合発生例を示す図であり、図2は、本情報システムの原理を示す図であり、図3は、本情報システムのシステム構成図であり、図4は、本情報システムのデータフロー図であり、図5は、プログラム製品修正時の運用フローを示す図であり、図6は、リリース時の運用フローを示す図であり、図7は、本情報システムにおける修正モジュールリリース処理を示すフローチャートであり、図8は、レベルダウン防止チェック処理(図7のS2)の詳細を示すフローチャートである。
<機能概要>
図1に、プログラム製品リリース時の不具合発生例を示す。この図1では、1つのプログラム製品の2つの世代が、短期間にリリースされる状況での不具合発生例の経緯を示している。
ここで、プログラム製品とは、例えば、パーソナルコンピュータ上で利用されるシステムプログラムやアプリケーションプログラム等である。本実施の形態では、プログラム製品を資産ともいう。
このようなプログラム製品は、一般的には、複数のモジュールから構成される。図1では、そのようなモジュールの例としてA.dllというファイル(ダイナミックリンクライブ
ラリ)が示されている。また、ここでは、A.cppおよびB.cppというソースプログラムをコンパイルしたファイル(いわゆるロードモジュール)がA.dllに含まれると仮定する。
また、世代は、バージョン、リビジョン等とも呼ばれ、リリースされるプログラム製品を特定する。図2では、世代ごとの修正対象をインシデントX、インシデントYのように
明示している。以下、図1にしたがい、不具合発生の経緯を説明する。
(1)12月7日(図1に示した「2001年」は省略する。省略以下同様である)に、インシデントX(A.cppというソースプログラム)を修正し、コンパイル完了した。この
場合、A.cppのコンパイル結果(これをロードモジュールと呼ぶ)が含まれるダイナミッ
クリンクライブラリA.dll全体がコンパイルされる。このとき作成されるダイナミックリ
ンクライブラリをA.dll50と呼ぶ。このA.dll50は、テスト待ちの状態に置かれる(矢印101)。
(2)12月10日に、インシデントY(B.cppというソースプログラム)を修正し、コ
ンパイル完了した。このB.cppのコンパイル結果は、上記と同一のダイナミックリンクラ
イブラリA.dllに含まれる。
したがって、ダイナミックリンクライブラリA.dll全体が再びコンパイルされる。この
コンパイルは、統合コンパイル環境で実行されるため、インシデントXで修正されたA.cppもコンパイルされる。このコンパイルによって生成されたダイナミックリンクライブラ
リをA.dll51と呼ぶ。このA.dll51も、テスト待ちの状態に置かれる(矢印102)。
(3)12月10日に、インシデントY(B.cpp)に対応するA.dll51のテストが完了し(矢印103)、インシデントY対応モジュールとしてA.dll51がリリースされる(矢
印104)。ただし、この時点で、インシデントXに対するテストは、未完である。
(4)12月12日に、インシデントX(A.cpp)に対応するA.dll50のテストが完了し(矢印105)、インシデントX対応モジュールとしてA.dll50がリリースされる(矢
印106)。
この状況では、以下のような不具合が含まれる(この不具合をレベルダウンともいう)。
第1に、上記(3)で述べたように、インシデントYに対応するA.dll51は、テスト
未完のA.cppのコンパイル結果が含まれているにも拘わらず、そのままリリースされてし
まう。
第2に、上記(4)において後からリリースされるA.dll50には、インシデントYに
対応するB.cppの修正結果が含まれていない。このため、後からリリースされるA.dll50により、先にリリースされたA.dll51を上書きすると、リリースを受けるユーザ側でイ
ンシデントYの修正結果が消滅してしまう。
図2は、このような不具合を回避する本情報システムの原理を示す図である。図2では、プログラム製品にユーザ(リリース担当の管理者)がそのような不具合の有無をチェックするレベルダウンチェック画面19と、そのレベルダウンチェック画面19から指示により実行される処理の概要が示されている。
このレベルダウンチェック画面19は、画面中央部の設定リリースVL(バージョンレベル)欄31、コメント欄32、予定VL欄33、レベルダウンチェック表示欄34、表示ボタン、チェックボタン20および画面下部の設定対象資産欄35を有している。
管理者は、設定リリースVL31に、リリース対象のプログラムのバージョンを示すバージョンレベルを設定する。バージョンレベルは、例えば、V10L10等の文字列である。
また、管理者は、コメント欄32に、そのバージョンレベルに関するコメントを設定する。コメントは、例えば、「障害No.0011対応モジュール」等である。
また、管理者は、予定VL欄33に、リリース予定となっているバージョンレベルを設定、表示ボタンを押下することにより、そのバージョンレベルに属する修正No.の一覧を表示することができる。そのような修正No.の一覧は、設定対象資産欄35に表示される。
ここで、修正No.とは、プログラム製品に対する1まとまりの修正作業や更新作業を特定する情報である。また、修正No.は、そのような修正作業や更新作業の結果を特定する。そして、そのような修正作業、更新作業の結果が1以上組み合わせられて1つのバージョンレベルを構成する。
また、レベルダウンチェック表示欄34には、レベルダウンチェック実行の有無が表示される。
設定対象資産欄35には、リリース予定の修正No.の一覧が表示される。この設定対象資産欄35の表の各行は、リリース対象チェックマーク、修正番号、および案件番号の各フィールドを有している。ここで、チェックマークは、その修正No.の修正作業による修正結果がリリース対象であることを指定する。
管理者が所望の修正番号の行について、リリース対象チェックマークを設定し、チェックボタン20を押下することにより、レベルダウンチェックが開始する。
例えば、図2の例では、リリース対象の修正番号(001〜003)で示されるプログラム製品のリリースモジュール管理テーブルが読み出され、リリース対象となっていない修正番号のモジュール管理テーブルと比較される。
リリースモジュール管理テーブルには、ソースプログラムのコンパイルにより更新されたモジュールが記録される。図2のように、リリースモジュール管理テーブルは、修正No.により識別され、当該修正作業で改造されたモジュールの一覧を有している。また、モジュールの一覧には、改造されたモジュール名とそのモジュールが更新された更新日付(コンパイルの日付)が含まれる。
ここで、例えば、修正No.0001のリリースモジュール管理テーブル20Aに記録されたモジュールA.dllの更新日付は、2001年12月10日である。一方、修正No
.0031のリリースモジュール管理テーブル20Bに記録されたモジュールA.dllの更
新日付は、2001年12月7日である。
したがって、修正No.0001で特定される今回リリース対象のモジュールの中に、今回リリース対象でない(後からリリースされる)モジュールより修正日付が新しいものがある。
このような状況では、図1において述べたように、修正No.001のリリース時にA.dllには、未テストの改造が含まれる可能性がある。また、後に、修正No.0031のリリースにより、リリース済みの内容が抹消される可能性がある。
一方、例えば、修正No.0001のモジュールB.dllの更新日付は、12月11日で
あり、修正No.0031のモジュールB.dllの更新日付12月18日より、古い。した
がって、モジュールB.dllには、不具合は含まれていないことが分かる。
また、修正No.0001のリリースモジュール管理テーブル20Aには、Y.EXE、Z.dllというモジュールが記録されている。しかし、これらのモジュールは、修正No.0031のリリースモジュール管理テーブル20Bには記録されていない。これは、Y.EXEお
よびZ.dllが修正No.0001では更新されたが、修正No.0031では、更新され
なかったことを示す。
また、修正No.0031のリリースモジュール管理テーブル20Bには、XX01.EXE、XX02.EXE等のモジュールが記録されている。しかし、これらのモジュールは、修正No.0001のリリースモジュール管理テーブル20Aには記録されていない。
このように、2つのリリースモジュール管理テーブルの一方に記録され、他方のリリースモジュール管理テーブルに記録されていないモジュールは、不具合を発生しない。リリースモジュール管理テーブルに記録されていないモジュールは、コンパイルされていないからである。
<システム構成>
図3は、本情報システムのシステム構成図である。この情報システムは、ウェブサーバ1、資産管理サーバ2、開発サーバ3(コンパイルサーバを含む)、リリースサーバ4(テストサーバを含む)、障害・Q/A登録サーバ5およびSQLサーバ6を有している。
資産管理サーバ2は、資産管理プログラムを実行し、プログラム製品、各プログラム製品を構成するモジュール、プログラム製品やモジュールをコンパイルするためのソースプログラム等のバージョンを管理する。ここで、資産管理とは、いわゆるプログラム製品のバージョン管理をいう。
コンパイルサーバを含む開発サーバ3は、ソースプログラムの編集やコンパイル等に使用される。テストサーバを含むリリースサーバ4は、プログラム製品のテスト環境を提供する。
障害・Q/A登録サーバ5は、サービス部門等からの障害情報の通知、Q/A(質問とその回答)等を登録する。SQLサーバ6は、開発環境に関する情報や、障害・Q/A登録サーバ5から登録された情報を保持する。
ウェブサーバ1は、管理者や開発者が使用する端末10に対し、ウェブページを提供し、バージョン管理に関する情報、ソースプログラムの入出庫、障害情報、Q/A(プログラム製品に関する質問および回答)等を提供する。
また、ウェブサーバ1は、資産管理コントロール部(プログラム)を実行し、プログラム製品リリース時における不良、すなわち、レベルダウンを検出する。
<システム運用フロー>
図4は、本情報システムのデータフロー図である。この情報システムでは、プログラム製品のソースプログラムが世代ごとに区別され、原本21としてデータベースに保存されている。
ユーザは、自身の端末10を通じて情報システムにアクセスし、原本21から必要なソースプログラムを取得する。すなわち、ユーザは、所定のウェブページにアクセスし、更新に必要なソースプログラムを指定してソースプログラムの貸出を資産管理サーバ2に依
頼する。すると、資産管理サーバ2は、管理用発行フォルダ22に出力され、さらに、開発サーバ3の貸出フォルダ23に移動される(図4の(1)(ここでは、まる1を(1)と表記する。以下同様))。ユーザは、開発サーバ3の貸出フォルダ23から自身の端末10にそのソースプログラムを複写し、プログラムの修正作業を行う。ただし、ユーザは、貸出フォルダ23において、そのままプログラムの修正作業を行ってもよい。
修正完了後、ユーザは、修正後のソースプログラムを返却フォルダ24に返却する。そして、ユーザは、所定のウェブページにアクセスし、そのソースプログラムの返却操作を行う。この返却操作により、返却フォルダ24のソースプログラムが管理受付用フォルダ25に転送される。また、返却フォルダ24のソースプログラムが統合コンパイル環境フォルダ26に転送される(図4の(2))。
コンパイルサーバは、複写したソースプログラムおよびそのソースプログラムと同一のモジュールに組み込まれるすべてのソースプログラムをコンパイルし、更新されたモジュールを作成する。
さらに、コンパイルサーバは、更新したモジュールを管理用受付フォルダ25に返却する(図4の(3))。このとき、資産管理サーバ2は、修正No.を発行し、修正モジュール管理テーブルに、その修正No.および返却されたモジュールのモジュール名と更新日付を記録する。また、コンパイルサーバは、更新したモジュールを統合テスト環境に合致するディレクトリ構成に変更する(図4の(4))。
そして、コンパイルサーバは、そのモジュールをテスト展開待ちディレクトリ29に格納する(図4の(5))。統合テスト環境を提供するテストサーバ4は、テスト展開待ちディレクトリ29に格納されたモジュールを順次読み出し、テスト環境に展開する。
テストサーバ4では、統合テスト環境において、更新されたモジュールのテストが実行される。テストが正常に終了すると、ユーザは、テストが完了した修正No.を所定のウェブページに入力する。この入力により、資産管理サーバ2は、管理用受付フォルダ25から更新されたモジュールを原本21に登録する(図4の(6))。
管理者は、テストが完了した修正No.のうち、リリース対象となる修正No.を収集し、リリースするバージョンレベルを設定する。そして、そのバージョンレベルに含まれる修正No.の修正結果について、レベルダウンチェックを実行する。
レベルダウンチェックが正常に終了すると、管理者は、作業フォルダを介して、そのバージョンレベルに含まれるモジュールをリモートメンテナンスサーバのリリース環境フォルダ28に転送する(図4の(7))。
リモートメンテナンスサーバは、エンドユーザとの契約条件にしたがい、所定の時期にリリース環境フォルダ28のモジュールをエンドユーザのコンピュータに転送する。
図5に、プログラム製品修正時の運用フローを示す。まず、ユーザ(図5では開発者と記載)は、所定のウェブページへの操作により、原本21から修正対象のソースプログラムを自身の端末10に取り出す(図5の(1))。ユーザは、修正作業を完了後、上記ウェブページへの操作により、修正されたソースプログラムを返却用一時ディレクトリ24Aに返却する(図5の(3))。ここで、返却用一時ディレクトリ24Aとは、図4に示す返却フォルダ24および管理用受付フォルダ25に対応する。
返却されたソースは、コンパイル環境フォルダ26に転送される(図5の(4))。こ
のコンパイル環境フォルダ26でソースプログラムのコンパイルが実行される。このような修正されたソースプログラムに関連するコンパイルだけを実行する技術は、例えば、unixシステムではmakeコマンドとして広く知られている。
次に、コンパイル結果の差分が抽出される(図5の(6))。差分とは、コンパイル環境に転送されたソースプログラムをコンパイルすることにより更新されるモジュールの集合をいう。この差分は、返却用一時ディレクトリ24Aとテスト環境フォルダ27の両方にコピーされる。
テストサーバ4は、コピーされた差分(更新されたモジュールの集合)をテスト環境に展開する(図5の(7))。ここで展開とは、更新されたモジュールをテスト環境にインストールすることをいう。ユーザは、テスト環境でテストを実行する(図5の(8))。
テスト完了後、ユーザは所定のウェブページにテスト完了を設定する。この設定により、テスト完了の電子メールが管理者に通知される(図5の(10))。管理者は、所定のウェブページを通じて修正終了の承認処理を実行する(図5の(11))。この承認処理により、返却用一時フォルダのファイル(修正済みのソースプログラムおよび更新されたモジュール)が原本21に反映される。また、このとき、対応する修正No.のリリースモジュール管理テーブルに、更新モジュール名および更新日付が記録される(図5の(12))。
図6に、リリース時の運用フローを示す。この処理では、管理者は、レベルダウンチェック画面19においてリリース対象の修正番号を選択する(図6の(1))。
そして、管理者は、このレベルダウンチェック画面19上のチェックボタン18(図2参照)を押下し、レベルダウンチェックの実行を指定する。これにより、レベルダウンチェック、すなわち、プログラム製品リリース時の不具合チェックが実行される(図6の(2))。
すると、資産管理サーバ2は、リリース対象の修正No.とリリース対象でない修正No.について、リリースモジュール管理テーブル(図6のテーブル20Aと20B)を比較する。この比較において、リリース対象のモジュールの更新日付がリリース対象でないモジュールの更新日付より新しい場合に(リリース対象外のモジュールの更新日付がリリース対象のモジュールの更新日付より古い場合に)、不具合、すなわち、レベルダウンが検出される。
次に、資産管理サーバ2は、リリース対象の修正No.で識別されるリリースモジュール管理テーブルに記録されたモジュールの更新日付と、テスト環境フォルダ27に保持され、そのモジュールを格納するファイルの更新日付とを比較する。この比較において、リリース対象のモジュールの更新日付がテスト環境フォルダ27において同一名称のモジュールを格納したファイルの更新日付より新しい場合に(テスト環境フォルダ27のファイルの更新日付が古い場合に)、不具合、すなわち、レベルダウンが検出される。
次に、不具合が検出されない場合、資産管理サーバ2は、リリース対象の修正No.を所定のウェブページに表示する。管理者は、リリース対象の修正No.を確認し、リリース対象を決定する(図6の(3))。
資産管理サーバ2は、確認された修正No.で識別されるリリースモジュール管理テーブルを基に、原本21からリリース対象のモジュールを抽出する(図6の(4))。
<作用>
図7に、本情報システムにおける修正モジュールリリース処理を示す。この処理は、図3に示した資産管理サーバ2が情報処理プログラムを実行することにより実現される。
この処理では、資産管理サーバ2は、まず、管理者によりリリース対象の選択を受ける(S1)。次に、資産管理サーバ2は、レベルダウン防止チェック処理を実行する(S2)。
次に、資産管理サーバ2は、レベルダウンの可能があるか否かを判定する(S3)。レベルダウンの可能性がない場合(S3の判定でNOの場合)、資産管理サーバ2は、リリース対象モジュールを抽出し、処理を終了する(S4)。
一方、レベルダウンの可能性がある場合(S3の判定でYESの場合)、資産管理サーバ2は、管理者からレベルダウン防止の処置の選択を受ける(S5)。レベルダウン防止処置が、「繰り上げリリース」であった場合、資産管理サーバ2は、リリース非対象であるが古い更新日付のモジュールに対応する修正番号のテストを促す。
これにより、例えば、所定のメッセージが開発者の端末10に通知される。開発者は当該修正番号のテストを完了し、完了報告を通知する。この通知を受けることにより、資産管理サーバ2は、当該修正番号のプログラム製品をリリース対象とし、制御をS1に戻す。
また、レベルダウン防止処置が、「リリース延期」であった場合、資産管理サーバ2は、リリース対象として設定されている修正番号をリリース非対象とする(S7)。そして、資産管理サーバ2は、制御をS1に戻す。
図8に、レベルダウン防止チェック処理(図7のS2)の詳細を示す。この処理では、資産管理サーバ2は、まず、リリース対象の修正番号で識別されるリリースモジュール管理テーブルとリリース非対象の修正番号で識別されるリリースモジュール管理テーブルとを比較する(S21)。
リリース対象の修正番号で識別されるリリースモジュール管理テーブルに記録されたモジュールがリリース非対象のリリースモジュール管理テーブルに記録された同一名のモジュールより古くない場合(S22でNOの場合)、資産管理サーバ2は、エラー情報を出力し、処理を終了する(S26)。
一方、リリース対象の修正番号で識別されるリリースモジュール管理テーブルに記録されたモジュールがリリース非対象のリリースモジュール管理テーブルに記録された同一名のモジュールより古い場合(S22でYESの場合)、資産管理サーバ2は、次のデータがあるか否かを判定する(S23)。次のデータがあるとは、リリース対象の修正番号で識別されるリリースモジュール管理テーブルに残りデータがある場合、または、次のリリース対象の修正番号で識別されるリリースモジュール管理テーブルがある場合をいう。
S23の判定で次のデータがある場合、資産管理サーバ2は、制御をS21に戻す。また、S23の判定で、次のデータがない場合、資産管理サーバ2は、リリース対象の修正番号で識別されるリリースモジュール管理テーブルに記録されたモジュールの更新日付とそのモジュールを格納するファイル(例えば、統合テスト環境でテスト待ちのモジュール)の日付を比較する(S24)。
そして、リース対象の修正番号で識別されるリリースモジュール管理テーブルに記録さ
れたモジュールの更新日付の方が古くない場合(S25でNOの場合)、資産管理サーバ2は、エラー情報を出力し、処理を終了する(S26)。
一方、リース対象の修正番号で識別されるリリースモジュール管理テーブルに記録されたモジュールの更新日付の方が古い場合(S25でYESの場合)、資産管理サーバ2は、次のデータがあるか否かを判定する(S27)。
S27の判定で次のデータがある場合、資産管理サーバ制御をS24に戻す。また、S27の判定で、次のデータがない場合、資産管理サーバ2は、処理完了メッセージを表示し、処理を終了する(S28)。
以上述べたように、本情報システムによれば、プログラム製品に対する複数の更新作業が並行して実施され、リリースされるような場合において、機械的にリリースの不具合を防止することができる。
すなわち、すでにリリース済み世代のプログラム製品に含まれていたモジュールより古いをモジュールを後発世代のプログラム製品に含めてリリースしてしまうような場合を検出できる。
また、統合コンパイル環境、すなわち、特定モジュールまたはすべてのプログラム製品のソースプログラムを1つの領域(例えば、フォルダやディレクトリ等)でコンパイルするような環境において、リリース対象のプログラム製品に、修正された後テスト未完のソースプログラムに対応する部分(ロードモジュールまたはオブジェクトモジュール)が含まれている可能性がある場合に、そのような部分を含む可能性のあるモジュールを検出できる。
<変形例>
上記実施形態では、ウェブサーバ1、資産管理サーバ2、開発サーバ3、コンパイルサーバ、リリースサーバ4、テストサーバ等および端末10により情報システムを構成した。しかし、本発明の実施は、このようなコンピュータの構成に限定されるものではない。
例えば、1台のサーバで、上記サーバの機能を提供するようにしてもよい。また、逆に、各サーバを複数のコンピュータによって構成してもよい。さらに、1台のコンピュータによるスタンドアロンの環境で、上記情報システムの機能を実現してもよい。
上記実施形態では、リリース対象のリリースモジュール管理テーブルとリリース非対象のリリースモジュール管理テーブルとを比較して、不具合がなかったとき、さらに、リリース対象のリリースモジュール管理テーブルに記録されたモジュールの更新日付とそのモジュールを格納するファイルの更新日付を比較した。
しかし、本発明の実施は、このような手順には限定されない。例えば、リリース対象のモジュールのファイルと、統合テスト環境でテスト待ち(テスト中を含む)のモジュールのファイルとの間で、更新日付を比較してもよい。すなわち、リリースモジュール管理テーブルには、修正番号と、その修正番号に含まれるモジュールを格納するファイル名を記録しておき、ファイル同士で更新日付を比較してもよい。
上記実施形態では、プログラム製品に対する1まとまりの修正作業や更新作業を修正No.で特定し、そのような複数の修正作業の結果や更新作業の結果を組み合わせて1つのバージョンレベル(世代)を構成した。そして、レベルダウンチェックは、リリース対象の修正No.の修正作業とリリース対象外の修正No.の修正作業との間で、対応するモ
ジュールの修正日付を比較することにより行った。
しかし、そのようなリリース対象の修正No.とリリース対象外の修正No.との間で、対応するモジュールの修正日付を比較する代わり、リリース対象の世代とリリース対象外の世代との間で、対応するモジュールの修正日付を比較してもよい。
すなわち、修正No.により特定される修正作業ごとにモジュールを比較するのでなく、プログラム製品の世代同士で対応するモジュールを比較するようにしてもよい。例えば、先にリリースされる世代のプログラム製品のモジュールで、後からリリースされる世代のプログラム製品の対応するモジュールより更新日付が新しいものが検出された場合に、レベルダウンとして、所定の処理を実行するようにすればよい。
<コンピュータ読み取り可能な記録媒体>
コンピュータに上記いずれかの機能を実現させるプログラムをコンピュータが読み取り可能な記録媒体に記録することができる。そして、コンピュータに、この記録媒体のプログラムを読み込ませて実行させることにより、その機能を提供させることができる。
ここで、コンピュータ読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータから読み取ることができる記録媒体をいう。このような記録媒体の内コンピュータから取り外し可能なものとしては、例えばフロッピー(登録商標)ディスク、光磁気ディスク、CD-ROM、CD-R/W、DVD、DAT、8mmテープ、メモリカード等がある。
また、コンピュータに固定された記録媒体としてハードディスクやROM(リードオンリーメモリ)等がある。
<搬送波に具現化されたデータ通信>
また、上記プログラムは、コンピュータのハードディスクやメモリに格納し、通信媒体を通じて他のコンピュータに配布することができる。この場合、プログラムは、搬送波によって具現化されたデータ通信信号として、通信媒体を伝送される。そして、その配布を受けたコンピュータに上記機能を提供させることができる。
ここで通信媒体としては、有線通信媒体、例えば、同軸ケーブルおよびツイストペアケーブルを含む金属ケーブル類、光通信ケーブル等、または、無線通信媒体例えば、衛星通信、地上波無線通信等のいずれでもよい。
また、搬送波は、データ通信信号を変調するための電磁波または光である。ただし、搬送波は、直流信号でもよい。この場合、データ通信信号は、搬送波がないベースバンド波形になる。したがって、搬送波に具現化されたデータ通信信号は、変調されたブロードバンド信号と変調されていないベースバンド信号(電圧0の直流信号を搬送波とした場合に相当)のいずれでもよい。
<その他>
さらに、本実施の形態は以下の発明を開示する。
(付記1)
コンピュータに、複数のモジュールを含むプログラム製品の更新時の不良を検出させるプログラムであり、
プログラム製品の更新作業を識別する更新識別情報を付与するステップと、
前記更新作業ごとに、更新されたモジュールを識別する情報とそのモジュールの更新時
点を示す情報とを前記更新識別情報とともに記録するステップと、
リリース予定の更新作業の対象モジュールとリリース予定外の更新作業の対象モジュールとに対して更新時点を比較する比較ステップと、
リリース予定のモジュールの更新時点が、そのモジュールに対応するリリース予定外のモジュールの更新時点より新しいときに所定の処理の実行を指令するステップと
を備えるプログラム。
(付記2)
更新作業ごとに識別され更新されたモジュールを格納する、そのようなファイルにアクセスし、そのファイルの更新時点を参照するステップをさらに備え、
前記比較ステップおいては、リリース予定のモジュールまたはリリース予定外のモジュールの少なくとも一方について、ファイルから参照した更新時点に基づき前記モジュールの更新時点が比較される
付記1に記載のプログラム。
(付記3)
前記所定の処理は、リリース予定のプログラム製品のリリース延期である
付記1または2に記載のプログラム。
(付記4)
前記所定の処理は、リリース予定外のプログラム製品で前記リリース予定のモジュールより古いモジュールを含むプログラム製品のリリース促進処理である
付記1または2に記載のプログラム。
(付記5)
コンピュータに、複数のモジュールを含むプログラム製品の更新時の不良を検出させるプログラムであり、
プログラム製品の更新世代ごとにその更新世代を識別する世代識別情報を付与するステップと、
前記更新世代ごとに、更新されたモジュールを識別する情報とそのモジュールの更新時点を示す情報とを前記世代識別情報とともに記録するステップと、
リリース対象の更新世代とリリース対象外の更新世代とにおいて更新されているモジュールの更新時点を比較する比較ステップと、
リリース予定のモジュールの更新時点が、そのモジュールに対応するリリース予定外のモジュールの更新時点より新しいときに所定の処理の実行を指令するステップと
を備えるプログラム。
(付記6)
コンピュータが、複数のモジュールを含むプログラム製品の更新時の不良を検出する方法であり、
プログラム製品の更新作業を識別する更新識別情報を付与するステップと、
前記更新作業ごとに、更新されたモジュールを識別する情報とそのモジュールの更新時点を示す情報とを前記更新識別情報とともに記録するステップと、
リリース予定の更新作業の対象モジュールとリリース予定外の更新作業の対象モジュールとに対して更新時点を比較する比較ステップと、
リリース予定のモジュールの更新時点が、そのモジュールに対応するリリース予定外のモジュールの更新時点より新しいときに所定の処理の実行を指令するステップと
を備える方法。
(付記7)
コンピュータが、複数のモジュールを含むプログラム製品の更新時の不良を検出する方法であり、
プログラム製品の更新世代ごとにその更新世代を識別する世代識別情報を付与するステップと、
前記更新世代ごとに、更新されたモジュールを識別する情報とそのモジュールの更新時点を示す情報とを前記世代識別情報とともに記録するステップと、
リリース対象の更新世代とリリース対象外の更新世代とにおいて更新されているモジュールの更新時点を比較する比較ステップと、
リリース予定のモジュールの更新時点が、そのモジュールに対応するリリース予定外のモジュールの更新時点より新しいときに所定の処理の実行を指令するステップと
を備える方法。
(付記8)
複数のモジュールを含むプログラム製品の更新時の不良を検出する管理装置であり、
プログラム製品の更新作業を識別する更新識別情報を付与する手段と、
前記更新作業ごとに、更新されたモジュールを識別する情報とそのモジュールの更新時点を示す情報とを前記更新識別情報とともに記録する手段と、
リリース予定の更新作業の対象モジュールとリリース予定外の更新作業の対象モジュールとに対して更新時点を比較する比較手段と、
リリース予定のモジュールの更新時点が、そのモジュールに対応するリリース予定外のモジュールの更新時点より新しいときに所定の処理の実行を指令する手段と
を備える管理装置。
(付記9)
複数のモジュールを含むプログラム製品の更新時の不良を検出する管理装置であり、
プログラム製品の更新世代ごとにその更新世代を識別する世代識別情報を付与する手段と、
前記更新世代ごとに、更新されたモジュールを識別する情報とそのモジュールの更新時点を示す情報とを前記世代識別情報とともに記録する手段と、
リリース対象の更新世代とリリース対象外の更新世代とにおいて更新されているモジュールの更新時点を比較する比較手段と、
リリース予定のモジュールの更新時点が、そのモジュールに対応するリリース予定外のモジュールの更新時点より新しいときに所定の処理の実行を指令する手段と
を備える管理装置。
プログラム製品リリース時の不具合発生例を示す図 本発明の一実施の形態に係る情報システムの原理を示す図 情報システムのシステム構成図 情報システムのデータフロー図 プログラム製品修正時の運用フローを示す図 リリース時の運用フローを示す図 修正モジュールリリース処理を示すフローチャート レベルダウン防止チェック処理(図7のS2)の詳細を示すフローチャート
符号の説明
1 ウェブサーバ
2 資産管理サーバ
3 開発サーバ(コンパイルサーバ)
4 リリースサーバ(テストサーバ)
10 端末
19 レベルダウンチェック画面19
21 原本

Claims (4)

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

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2008032887A JP4769826B2 (ja) 2008-02-14 2008-02-14 レベルダウン検出プログラム、レベルダウン検出方法、及び、管理プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008032887A JP4769826B2 (ja) 2008-02-14 2008-02-14 レベルダウン検出プログラム、レベルダウン検出方法、及び、管理プログラム

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2002096881A Division JP2003296108A (ja) 2002-03-29 2002-03-29 管理プログラム、および方法

Publications (2)

Publication Number Publication Date
JP2008176803A JP2008176803A (ja) 2008-07-31
JP4769826B2 true JP4769826B2 (ja) 2011-09-07

Family

ID=39703731

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008032887A Expired - Lifetime JP4769826B2 (ja) 2008-02-14 2008-02-14 レベルダウン検出プログラム、レベルダウン検出方法、及び、管理プログラム

Country Status (1)

Country Link
JP (1) JP4769826B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5537599B2 (ja) * 2012-04-27 2014-07-02 株式会社日立製作所 業務システムにおけるバージョンアップ管理方法
JP6984120B2 (ja) * 2016-12-12 2021-12-17 中国電力株式会社 ロードコンペア装置、ロードコンペアプログラムおよびロードコンペア方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05216635A (ja) * 1991-12-04 1993-08-27 Nec Corp プログラム競合の管理システム
JPH05233234A (ja) * 1992-02-24 1993-09-10 Nec Corp ソフトウェアパッケージのリリース処理方式
JPH11296350A (ja) * 1998-04-09 1999-10-29 Hitachi Ltd オブジェクトリリース管理方法
JP2001166923A (ja) * 1999-12-10 2001-06-22 Nec Corp リリース処理システム及び方法並びに記録媒体

Also Published As

Publication number Publication date
JP2008176803A (ja) 2008-07-31

Similar Documents

Publication Publication Date Title
EP3769223B1 (en) Unified test automation system
CN110532189B (zh) 一种持续集成系统、方法及装置
US10114637B1 (en) Automatically updating a shared project build platform
US7926038B2 (en) Method, system and computer program for testing a command line interface of a software product
KR100655124B1 (ko) 주문 제작 컴퓨터시스템을 위한 소프트웨어 설치 및 테스트를촉진하는 데이타베이스
US7870547B2 (en) Method and apparatus for managing patchable software systems
US8245216B2 (en) Patch management system
US7500234B2 (en) System-updating method and computer system adopting the method
US8677348B1 (en) Method and apparatus for determining least risk install order of software patches
US20160306737A1 (en) Automated error checking system for a software application and method therefor
US20070106978A1 (en) Patch management system
US20080201702A1 (en) System and method for scheduling software updates
US20070106979A1 (en) Patch management system
US20100218176A1 (en) Test system configuration method and system
US20070106980A1 (en) Patch management system
JPH10222374A (ja) 遠隔ソフトウェア技術支援を提供するための方法
US20030088810A1 (en) Methods and apparatus for determining software component sizes associated with errors
CN104932973A (zh) 一种版本兼容测试方法和装置
CN108776643A (zh) 一种基于版本控制流程的目标代码合并控制方法及系统
US20060112189A1 (en) Method for tracking transport requests and computer system with trackable transport requests
US20070266371A1 (en) Multiple correction requests occurring from a single request
JP4769826B2 (ja) レベルダウン検出プログラム、レベルダウン検出方法、及び、管理プログラム
JP4702194B2 (ja) プログラム開発支援装置、プログラム開発支援方法およびプログラム開発支援プログラム
US20190065168A1 (en) Apparatus and method to shorten software installation time based on a history of file installation
CN111414194B (zh) 一种接口信息生成方法、系统、电子设备及存储介质

Legal Events

Date Code Title Description
TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110531

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110620

R150 Certificate of patent or registration of utility model

Ref document number: 4769826

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140624

Year of fee payment: 3

EXPY Cancellation because of completion of term