JP2005107803A - システム更新方法、および、それを実行するための計算機システム - Google Patents

Abstract

【課題】ネットワークを介して、ソフトウェアを更新する場合に、システムの更新を簡単におこなえるようにし、しかも、ソフトウェア更新後のユーザシステムの信頼性とサービスレベルを保証する。
【解決手段】ベンダシステムで、ユーザシステムにインストールされているソフトウェア情報やハードウェア情報を含むユーザシステム情報を取得する。そして取得したユーザシステム情報を基にテスト環境を構築して、そのテスト環境においてソフトウェア更新パッチを適用したシステムの動作を検証し、テスト環境においてシステムが正常に動作するかを確認する。そして、正常動作が確認された場合に、ソフトウェア更新パッチをユーザシステムに送信し、ユーザシステムでは、そのソフトウェア更新パッチを適用して、自らのシステムを更新する。
【選択図】 図１

Description

本発明は、システム更新方法、および、それを実行するための計算機システムに係り、特に、ユーザシステムのソフトウェアを更新することの多いオープンシステムに用いて好適であって、ユーザシステムにおけるソフトウェア更新作業を容易におこなうことができ、しかも、ソフトウェア更新後のユーザシステムの信頼性とサービスレベルを保証することのできるシステム更新方法、および、それを実行するための計算機システムに関する。

ユーザの計算機システム（以下、単に「ユーザシステム」という）を更新する方法としては、従来では、ＣＤ−ＲＯＭなどの記憶媒体からソフトウェアをインストールする方法が殆どであった。

しかしながら、近年では、インターネットの普及などにより、ネットワークを介してソフトウェアを提供するベンダ計算機システム（以下、単に「ベンダシステム」という）からソフトウェアをダウンロードして、ユーザシステムにインストールする方法も広くおこなわれるようになってきている。

このネットワークによるソフトウェアインストール方法では、例えば、ユーザシステム側でユーザシステムのソフトウェア構成情報を生成し、ユーザシステムがベンダシステムのパッチ管理サーバからの定期的にソフトウェア更新情報をネットワークを通じて受信する。そして、ユーザシステムのソフトウェア構成情報と受信したソフトウェア更新情報とを比較して、更新すべきソフトウェアを調査し、調査結果から更新すべきソフトウェア一覧を表示する。ユーザがそれを選択して、更新を要求すると、ベンダシステムは、ソフトウェアの更新パッチをユーザシステムにネットワークを通じて送信する。ユーザシステムでは、その更新パッチを更新するソフトウェアに適用して、ソフトウェアを更新する。ここで、「パッチ」とは、プログラムの修正をおこなうための差分ファイルである。

例えば、以下の特許文献１には、サーバ側にパッチデータベースを構築しておき、クライアントは、ネットワークを介してパッチ情報を受信して、自らのコンピュータシステムに適用する例が開示されている。

また、ミッションクリティカルなユーザシステムを更新する場合には、ベンダ側のシステム管理者がユーザシステムにソフトウェア更新パッチを持ちこみ、更新したいソフトウェアに対して稼動中に前記ソフトウェア更新パッチを適用して、ユーザシステムやソフトウェアの再起動をせずに更新することで、可用性を低下させずに更新する方法も存在する。

さらに、ユーザシステムを構築したベンダがユーザシステムと同じシステムをベンダ側で準備して、ユーザシステムの更新をベンダ側でテストする方法がある。

特開２００２−５５８３９号公報

ネットワークによるユーザシステムのソフトウェアの更新は、記録媒体による方法に比べて、手軽にでき、しかも、最新のソフトウェアを利用できるメリットがある。

しかしながら、従来のネットワークによるソフトウェア更新方法では、ユーザシステムの更新後に、更新のよって動作が変化したユーザシステムが障害を発生して、システム停止や再起動などの発生により可用性が低下する場合や、ユーザシステムの更新の結果、ユーザシステムに要求されるサービスレベルに達しない場合や、ユーザシステムの更新によってユーザが所望の機能を実行できなくなるなどなどの問題が発生する可能性がある。

特に、セキュリティにおける脆弱性の発覚やバグの発生など、重大な原因によってソフトウェアを更新したい場合には、上記の問題は大変な損害を発生する可能性が高い。また、２４時間３６５日稼動していることが必要なシステムを更新する場合には、確実にソフトウェアの更新ができなければならない。

また、ベンダが作成した一意なソフトウェア更新パッチは、ユーザシステムのシステム構成によっては必ずしも正しく動作しない可能性がある。特にオープンソースなどのソフトウェアを利用するユーザシステムでは、ユーザ自身によってソフトウェアのソースコードの書き換えが可能であるため、ユーザシステムはユーザ固有の構成となっている可能性がたかい。このために、ユーザシステムにベンダが作成した一意なパッチが適応できないことが多い。

本発明は、上記問題点を解決するためになされたもので、その目的は、ネットワークを介して、ソフトウェアを更新する方法において、ユーザシステムにおけるソフトウェア更新作業を容易におこなうことができ、しかも、ソフトウェア更新後のユーザシステムの信頼性とサービスレベルを保証することのできるシステム更新方法を提供することにある。

上記の課題を解決するため、本発明に係るシステム更新方法は、ベンダシステムで、ユーザシステムにインストールされているソフトウェア情報やハードウェア情報を含むユーザシステム情報を取得する。そして取得したユーザシステム情報を基にテスト環境を構築して、そのテスト環境においてソフトウェア更新パッチを適用したシステムの動作を検証し、テスト環境においてシステムが正常に動作するかを確認する。そして、正常動作が確認された場合に、ソフトウェア更新パッチをユーザシステムに送信し、ユーザシステムでは、そのソフトウェア更新パッチを適用して、自らのシステムを更新する。

また、テスト環境をユーザシステム側に構築し、最適なソフトウェア更新パッチをベンダシステム側から受信する仕組みにしてもよい。

これにより、ユーザシステムと同じ環境のテスト環境でシステム動作が確認されたソフトウェア更新パッチのみがユーザに配布されることになり、ユーザシステムでのソフトウェアの更新によるトラブルをなくすことができる。

すなわち、ユーザシステムの更新に利用するソフトウェア更新パッチは、ユーザシステムと同等のテスト環境によってテストに成功したものであり、ユーザシステムの更新時にシステムがクラッシュすることなく、確実に更新することができる。また、更新後の機能や性能についてもテストが実施できるため、ユーザの要求するサービスレベルを確実に達成し、かつ、必要な機能を確実に追加することができる。

また、ユーザシステム情報をベンダが得て、ユーザシステムと同等のテスト環境を利用してテストを実施するため、オープンソースソフトウェアをユーザシステムにインストールして利用しているユーザが、オープンソースソフトウェアを自身で書き換えた場合や、ユーザ固有の環境でしか発生しない問題が存在する場合であっても、ユーザシステムに適合したソフトウェア更新パッチを作成することができる。そのために、このようなユーザシステム固有の問題にも対処することができる。

本発明によれば、ネットワークを介して、ソフトウェアを更新する方法において、ユーザシステムにおけるソフトウェア更新作業を容易におこなうことができ、しかも、ソフトウェア更新後のユーザシステムの信頼性とサービスレベルを保証することのできるシステム更新方法を提供することができる。

以下、本発明に係る各実施形態を、図１ないし図１６を用いて説明する。

〔実施形態１〕
以下、本発明に係る第一の実施形態を、図１ないし図１５を用いて説明する。

先ず、図１を用いて本発明に係る第一の実施形態のシステム更新方法を実現するためのシステム構成を説明する。
図１は、本発明に係る第一の実施形態のシステム更新方法を実現するためのシステム構成図である。

本実施形態の計算機システムは、図１に示されるようにユーザがプログラムを実行するためのユーザシステム１１０と、ユーザにソフトウェアを提供するベンダベンダシステム１３０がネットワーク１４０により接続された構成をしている。

ユーザシステム１１０は、アプリケーション１２１と、ミドルウェア１２２と、ＯＳ１２３と、システム更新部１１１とから構成されるシステムである。

システム更新部１１１は、ユーザシステム１１０のユーザシステム情報１０１を収集しネットワーク１４０などの遠隔通信手段によってベンダシステム１３０へユーザシステム情報１０１を送信する機能と、アプリケーション１２１、ミドルウェア１２２、ＯＳ１２３のコンポーネントを更新する機能とを有する
ここで、ＯＳ１２３には、ユーザシステム１１０に組み込まれているライブラリや、デバイスドライバや、モジュールなどのソフトウェアも含まれている。

一方のベンダシステム１３０は、ユーザシステム管理部１３１と、パッチテスト部１３２と、パッチ送信部１３４と、テスト環境２０１とから構成されるシステムである。

パッチテスト部１３２は、テスト環境構築部１３３を含み、修正ソフトウェア更新パッチ１０２を読み込み、そのソフトウェアによるシステムのテスト環境を構築して、システム動作を確認する機能を有する。そして、テストに成功するようにソフトウェア更新パッチを修正し、修正後ソフトウェア更新パッチ１０３を生成する。

パッチ送信部１３４は、テストに成功した修正後ソフトウェア更新パッチ１０３をネットワークにより、ユーザシステム１１０に送信する。

次に、図２ないし図７を用いて本発明に係る第一の実施形態のシステム更新方法の手順を説明する。
図２は、本発明に係る第一の実施形態のシステム更新方法の手順の概要を示すシーケンス図である。
図３は、ユーザシステム情報の一例を示す図である。
図４は、被テストソフトウェア更新パッチの一例を示す図である。
図５は、ユーザシステムの表示装置で、更新パッチの種別を選択する場面を示す模式図である。
図６は、ユーザシステムの表示装置で、更新テスト結果を確認し、更新を実行する場面を示す模式図である。
図７は、ユーザシステムのシステム更新の一形態を示す模式図である。

以下、図２を追いながら他の図面を随時参照して、本実施形態のシステム更新方法の手順を説明することにする。

図２に示されるように、ユーザシステム１０２は、アプリケーション１２１、ミドルウェア１２２、ＯＳ１２３のレイヤを持ち、アプリケーション１２１は、更新前のコンポーネントａ１，ａ２，…，ａｘ、ミドルウェア１２２は、更新前のコンポーネントｍ１，ｍ２，…，ｍｘ、ＯＳ１２３は、更新前のコンポーネントｋ１，ｋ２，…，ｋｘから成ることにする。

そして、各レイヤのコンポーネントは、テスト環境２０１では、置き換えられる。本実施形態の説明では、更新後のコンポーネントは、それぞれのアルファベットの大文字で表すことにする。

先ず、ユーザシステム１１０が、システム更新を要求し（Ｓ１１）、ベンダシステムは、ユーザシステムからのシステム更新の要求を受信する（Ｓ２１）。

このＳ１１のステップで、システム更新要求をするときには、例えば、ユーザシステム１１０では、図６に示されるように、ブラウザなどを利用して、リクエスト送信インタフェイス７１０をユーザシステムの表示装置７０１に表示し、更新に利用できるパッチをパッチリスト７１１に表示する。そして、ユーザは、パッチリスト７１１から選択ボタン７１２をチェックして選択し、リクエスト送信ボタン７１３をマウスなどのポインテイングデバイスにより、クリックしてベンダに送信する。

次に、ユーザシステム１１０のシステム更新部１１１が、ユーザシステム情報１０１を取得して、取得したユーザシステム情報１０１をユーザシステム管理部１３１に送信する（Ｓ１２）。システム更新部１１１がユーザシステム情報１０１を取得する方法としては、エージェントプログラムをユーザシステム１１０上で動作させてユーザのユーザシステム１１０に対する変更を常に監視する方法や、ユーザ自身がユーザシステム情報１０１をベンダに通知するためのユーザインタフェイスを用意する方法がある。また、Ｓ１２のステップの処理は、必ずしもＳ１１の処理の後に実行せずに、ユーザによるユーザシステム１１０の更新の度に実行しても良い。

ここで、ユーザシステム情報１０１は、図３に示すように、ハードウェア情報３１０と、ソフトウェア情報３２０や、ソースコード情報とから成る情報である。

ハードウェア情報３１０は、ユーザシステムのプロセッサの種類や、メモリの容量や、チップセットの種類や、デバイスの種類などからなる情報である。

ソフトウェア情報３２０は、ユーザシステムにインストールされているアプリケーション１２１のコンポーネントの種類や、ミドルウェア１２２のコンポーネントの種類や、ＯＳ１２３のコンポーネントの種類などからなる情報である。

ソースコード情報３３０は、アプリケーション１２１、ミドルウェア１２２、ＯＳ１２３のソースコードと、それに関連する情報である。ここで、本実施形態で、ユーザシステム情報１０１にソースコード情報３３０を含めたのは、ソースコードが公開されるオープンシステムへの適用を意識したものである。

次に、ベンダシステム１３０は、ユーザシステム管理部１３１からＳ１２の処理で送信されたユーザシステム情報１０１を受信する（Ｓ２２）。

ベンダシステム１３０では、パッチテスト部１３２のテスト環境構築部１３３が、ステップＳ２２の処理で受信したユーザシステム情報１０１を受け取り、さらに、ユーザシステム１１０の更新に必要な被テストソフトウェア更新パッチ１０２を取得し、ユーザシステム１１０と同じ環境を持つテスト環境２０１を構築する（Ｓ２３）。

本実施形態では、ユーザシステム１１０からユーザシステム情報１０１を直接受信したが、ベンダシステム１３０で、ユーザシステム情報データベースを構築して置き、そこから取得するようにしてもよい。

また、被テストソフトウェア更新パッチ１０２は、例えば、Ｓ１１の処理でユーザが図１３のパッチリスト７１１から選択したパッチである。被テストソフトウェア更新パッチ１０２の取得方法は、ユーザから入手する場合や、ベンダ自身が作成した場合や、オープンソースコミュニティなどのその他の組織や個人から入手する場合がある。あるいは、ベンダは被テストソフトウェア更新パッチ１０２が必要になった場合にすぐに取得できるように、ベンダがパッチデータベースを用意して、複数のソフトウェア更新パッチを記録しておき、必要な時に必要なソフトウェア更新パッチをパッチデータベースから取得できるようにする方法もある。

被テストソフトウェア更新パッチ１０２は、ソースコードパッチ４１０、バイナリコードパッチ４２０のいずれか一方、または、両方からなるソフトウェア更新パッチ１０２である。

ソースコードパッチ４１０は、更新の対象となるソフトウェアの更新前のソースコードと更新後のソースコードの差分である。バイナリコードパッチ４２０は、更新の対象となるソフトウェアの更新前のバイナリコードと更新後のバイナリコードのバイナリ形式の差分である。また、被テストソフトウェア更新パッチ１０２をテストして作られるテスト成功ソフトウェア更新パッチ１０３の構成も、これと同じ構成になる。

なお、テスト環境構築部１３３の構成と動作については、後に詳細に説明する。

構築されたテスト環境２０１では、ユーザシステムと同じ環境を構築し、修正前更新パッチによりソフトウェアを更新して、システム動作をテストするための検証テストが実施される（Ｓ２４）。

そして、検証テストに失敗した被テストソフトウェア更新パッチ１０２を、Ｓ２４のステップで得たテスト結果を元に修正し、テスト環境構築部１３３において修正したソフトウェア更新パッチを被テストソフトウェア更新パッチ１０２の代わりに利用してテスト環境を構築し、再度検証テストを実施する（Ｓ２５）。このＳ２４とＳ２５のステップの処理をテストが成功するまで繰り返す。

また、Ｓ２５のステップにおいて、Ｓ２４のステップでの検証テストのテスト結果をユーザに通知し、ユーザに更新の是非を問い合わせる方法もある。

例えば、図６に示すようにブラウザなどを利用して、ユーザシステムの表示装置８０１に更新情報表示インタフェイス８１０を用意し、Ｓ２４のステップのテスト結果である更新テスト結果情報８１１を表示する。そして、ここで、ユーザが更新実行ボタン８１２をクリックすることによって、検証テストに成功したとみなすことにする。

ベンダシステム１３０では、次に、パッチ送信部１３１が、Ｓ２５のステップの処理で検証テストに成功したテスト成功ソフトウェア更新パッチ１０３をユーザのシステム更新部１１１に送信する（Ｓ２６）。

ユーザシステム１１０側では、ベンダシステム１３０からテスト成功ソフトウェア更新パッチ１０３を受信し、システム更新部１１１がテスト成功ソフトウェア更新パッチ１０３を取得して、テスト成功ソフトウェア更新パッチ１０３をユーザシステム１１０のアプリケーション１２１、ミドルウェア１２２、ＯＳ１２３に適用して、ユーザシステム１１０を更新する（Ｓ１３）。

図の例では、ミドルウェア１２２のコンポーネントｍ１がＭ１に、ＯＳ１２３のコンポーネントｋ２がＫ２に更新されたことを示している。

ユーザシステム１１０の事情が許せば、ユーザシステム１１０を再起動して更新してもよいが、ユーザシステム１１０のプログラムやシステムを再起動せずに更新することができる。

例えば、図７では、システム更新部１１１がＯＳ１２３を再起動せずに更新する一例を示している。図７の旧コードＣ１０は、稼動中のＯＳ１２３のバイナリコードであり、新コードＣ２０は、テスト成功ソフトウェア更新パッチのバイナリコードパッチ４２０か、あるいは、システム更新部１１１がソースコードパッチ４１０をコンパイルして生成したバイナリコードである。システム更新部１１１は、新コードＣ２０をＯＳ１２３に挿入して、旧コードＣ１０の先頭に、新コードＣ２０への分岐命令Ｃ０１を挿入することにより、ＯＳ１２３を更新する。

次に、図８ないし図１５を用いてテスト環境構築部１３３の詳細について説明する。
図８は、テスト環境構築部１３３の構成を示すブロック図である。
図９は、テスト環境２０１の構成例を示す模式図である。
図１０ないし図１５は、テスト環境構築部１３３の各部の動作を示すフローチャートである。

テスト環境構築部１３３は、図８に示すようにプラットフォーム選択部５１０と、ソフトウェア取得部５２０と、コンパイル部５３０と、インストール部５４０と、パッチ適用部５５０と、検証テスト実行部５６０とから成り、テスト環境２０１を構築する。

テスト環境２０１は、異なるハードウェア構成をもつ複数のプラットフォーム５７１を有し、それぞれのプラットフォームＰ１，Ｐ２，Ｐｎには、インストールされているアプリケーションのコンポーネントａ１，ａ２，ａｘと、ミドルウェアのコンポーネントｍ１，ｍ２，ｍｘと、ＯＳのコンポーネントｋ１，ｋ２，ｋｘが示されている。

また、テスト環境２０１は、実際に異なったハードウェア環境を用意して構築する方法のほかに、図９に示されるように、プラットフォーム５７１の実計算機を複数の論理計算機（Logical Partition）５１０に、論理的分割して、その各々の論理計算機５１０に割り当てる方法もある。ここで、管理計算機５３０は、論理計算機５１０のＣＰＵ数やＣＰＵの動作周波数、メモリ容量の設定や、論理計算機５１０に接続するデバイス５２０を選択する計算機である。

テスト環境構築部１３３は、以下の手順でユーザシステム１１０からユーザシステム情報１０１を取り込み、ユーザシステムの同じ環境を持つテスト環境２０１を構築して、構築したテスト環境を利用して検証テストを実行する。

先ず、プラットフォーム選択部５１０は、図１０に示すように、ユーザシステム情報１０１から、ハードウェア情報３１０を取得する（Ｓ５１１）。次に、取得したハードウェア情報３１０を元に、テスト環境５７０のプラットフォーム５７１からユーザシステム１１０と一致するハードウェア構成を持つプラットフォーム５７１を選択する（Ｓ５１２）。そして、必要であれば選択したプラットフォーム５７１に論理計算機６１０を生成し、論理計算機６１０の一つをユーザシステム１１０と一致するハードウェア構成となるように、ＣＰＵ数やＣＰＵの動作周波数、メモリ容量などを設定し、接続するデバイスを選択する（Ｓ５１３）。

ここで、ユーザシステム１１０のハードウェア構成と同等なプラットフォーム５７１をベンダが入手困難な場合は、ソフトウェアによるエミュレーションにより擬似的にプラットフォーム５７１を構築する方法もある。プラットフォームに論理計算機を利用せずに、実計算機を用いても良い。また、複数の計算機やデバイスをベンダが用意しておき、テスト環境２０１を構築する必要がある場合にその一つをテスト環境用のプラットフォーム５７１として利用し、不要な場合は別の用途に利用する方法もある。

次に、ソフトウェア取得部５２０は、図１１に示すように、ユーザシステム情報１０１から、ソフトウェア情報３２０を取得する（Ｓ５２１）。次に、取得したソフトウェア情報３２０を元に、ユーザシステム１１０にインストールされているアプリケーション１２１、ミドルウェア１２２、ＯＳ１２３のコンポーネントをソフトウェアデータベース５２１から取得する（ステップＳ５２２）。

ここで取得するソフトウェアのコンポーネントは、実行可能なバイナリ形式であっても、ソースコードであっても良い。

次に、コンパイル部５３０は、図１２に示すように、ユーザシステム情報１０１からソースコード情報３３０を取得する（Ｓ５３１）。次に、被テストソフトウェア更新パッチ１０２を取得して、前記ソースコード情報３３０およびソフトウェア取得部５２０で取得したソースコードの中に対象となるソースコードがあれば、被テストソフトウェア更新パッチ１０２のソースコードパッチ４１０を適用する（Ｓ５３２）。また、パッチを適用したソースコードとソフトウェア取得部５２０が取得したソースコードをコンパイルして、実行可能なバイナリ形式のコンポーネントを生成する（Ｓ５３３）。

ここで生成したコンポーネントは、ユーザシステム１１０にインストールされているアプリケーション１２１、ミドルウェア１２２、ＯＳ１２３のコンポーネントである。

次に、インストール部５４０は、図１３に示すように、ソフトウェア取得部５２０が取得したアプリケーション１２１、ミドルウェア１２２、ＯＳ１２３のバイナリ形式のコンポーネントと、コンパイル部５３０が生成したバイナリ形式のコンポーネントを取得する（Ｓ５４１）。そして、取得したコンポーネントをプラットフォーム選択部５１０が選択したプラットフォーム５７１にインストールする（Ｓ５４２）。

次に、パッチ適用部５５０は、図１４に示すように、被テストソフトウェア更新パッチ１０２を取得し、バイナリコードパッチ４２０が存在すれば、インストール部５４０がインストールしたコンポーネントの中から、該当するコンポーネントに対してバイナリコードパッチを適用する（Ｓ５５１）。

ここまでの手順により、ユーザシステム１１０と同じ環境を持つシステムがテスト環境２０１に構築されることになる。

次に、検証テスト実行部５６０は、図１５に示すように、テストパターンを利用して検証テストを実施する（Ｓ５６１）。ここでテストパターンは、例えばユーザから必要なテストパターンを取得する場合もあれば、ベンダが自身で用意する場合もある。そして、テスト結果を判定し（Ｓ５６２）、テストに成功すれば、テストに成功したソフトウェア更新パッチをテスト成功ソフトウェア更新パッチ１０３としてパッチ送信部１３４に渡し（Ｓ５６３）、テストに失敗していれば、そのテスト結果を記録する（Ｓ５６４）。ここでテスト失敗とは、検証テスト中にシステムクラッシュする場合や、目標となる機能を達成できなかった場合である。

そして、テスト結果の記録を参照して、再度被テストソフトウェア更新パッチ１０２が選択され、テストに成功するまで上記の手順が繰り返されることになる。

〔実施形態２〕
以下、本発明に係る第二の実施形態を、図１６を用いて説明する。
図１６は、本発明に係る第二の実施形態のシステム更新方法を実現するためのシステム構成図である。

第一の実施形態では、ベンダシステム１３１のテスト環境構築部１３３が、ベンダシステム１３３側にテスト環境を構築して、ベンダシステム１３３側でシステムのテストをおこなうものであった。

本実施形態では、ユーザシステム１１０側にテスト環境を構築して、ベンダシステム側から、テストの対象となる被テストソフトウェア更新パッチ１０２を送信する例である。

本実施形態のユーザシステムは、アプリケーション１２１と、ミドルウェア１２２と、ＯＳ１２３と、システム更新部１１１と、テスト環境構築部１３３ａと、テスト環境２０１ａとから構成されるシステムである。この内で、アプリケーション１２１と、ミドルウェア１２２と、ＯＳ１２３と、システム更新部１１１は、実施形態１と同様の構成である。

また、ベンダシステム１３０は、ユーザシステム管理部１３１と、パッチ送信部１３４と、テスト結果フィードバック部１３５とから構成されるシステムである。

ユーザシステムに構築されるテスト環境２０１ａのプラットフォームは、ユーザのハードウェア環境とは、別に、実計算機を論理的に分割した論理計算機を用意して、その論理計算機にテスト環境２０１ａを割り当てるようにする。これは、テストのためにユーザの使っている環境が影響を受けないようにするためである。

本実施形態は、ユーザシステム１１０側に、テスト環境２０１ａを構築するものである。そのため、ユーザシステム１１からベンダシステム１３０にユーザシステム情報１３１が送付される。あるいは、ベンダシステム１３０側でユーザシステム情報を蓄積しておいてもよい。

ベンダシステム１３０は、ユーザシステム１１０からシステム更新のリクエストがあると、パッチ送信部１３４からユーザシステム情報と被テストソフトウェア更新パッチ１０２を送付する。

ユーザシステム１１０のテスト環境構築部１３３ａでは、受け取ったユーザシステム情報と被テストソフトウェア更新パッチ１０２を元に、テスト環境を構築する。

そして、テストが成功すると、その被テストソフトウェア更新パッチ１０２を元にして、システム更新機能１１１がユーザシステム１１０の更新をおこなう。

テストが失敗すると、ユーザシステム１１０は、ベンダシステム１３０のテスト結果フィードバック部１３５に報告する。そして、テスト結果フィードバック部１３５は、次のテスト候補となる被テストソフトウェア更新パッチ１０２を再送付する。

本発明に係る第一の実施形態のシステム更新方法を実現するためのシステム構成図である。 本発明に係る第一の実施形態のシステム更新方法の手順の概要を示すシーケンス図である。 ユーザシステム情報の一例を示す図である。 被テストソフトウェア更新パッチの一例を示す図である。 ユーザシステムの表示装置で、更新パッチの種別を選択する場面を示す模式図である。 ユーザシステムの表示装置で、更新テスト結果を確認し、更新を実行する場面を示す模式図である。 ユーザシステムのシステム更新の一形態を示す模式図である。 テスト環境構築部１３３の構成を示すブロック図である。 テスト環境２０１の構成例を示す模式図である。 テスト環境構築部１３３のプラットホーム選択部５１０の動作を示すフローチャートである。 テスト環境構築部１３３のソフトウェア取得部５２０の動作を示すフローチャートである。 テスト環境構築部１３３のコンパイル部５１０の動作を示すフローチャートである。 テスト環境構築部１３３のインストール部５２０の動作を示すフローチャートである。 テスト環境構築部１３３のパッチ適用部部５５０の動作を示すフローチャートである。 テスト環境構築部１３３の検証テスト実行部５６０の動作を示すフローチャートである。 本発明に係る第二の実施形態のシステム更新方法を実現するためのシステム構成図である。

Claims (10)

1. ユーザ計算機システムにインストールされているソフトウェアを更新する方法において、
   前記ユーザ計算機システムにインストールされているソフトウェア情報、ハードウェア情報を含むユーザシステム情報を取得するステップと、
   取得したユーザシステム情報を基に、システム動作をテストするためのテスト環境を構築するステップと、
   前記テスト環境においてソフトウェア更新パッチを用いてソフトウェアの更新をおこなうステップと、
   前記テスト環境において前記更新されたソフトウェアによりシステムが正常に動作するか否かを確認するステップと、
   システムの正常動作が確認された場合に、前記ソフトウェア更新パッチを前記ユーザ計算機システムに送付して、前記ユーザ計算機システムのソフトウェアを更新するステップとを有することを特徴とするシステム更新方法。
2. 前記ユーザ計算機システムは、
   前記ユーザシステム情報を監視する手段と、
   ユーザ計算機システムにインストールされているソフトウェアを更新する手段とを有し、
   前記ユーザ計算機システムは、前記ソフトウェア更新パッチを取得して、前記ユーザ計算機システムの更新対象となるソフトウェアに係るプログラムを停止させることなく更新することを特徴とする請求項１記載のシステム更新方法。
3. 前記ユーザ計算機システムは、
   前記テスト環境におけるシステム動作のテスト結果を取得し、
   ユーザに前記テスト結果を表示して、
   ユーザ計算機システムのソフトウェア更新の是非を、前記ユーザに問い合わせることを特徴とする請求項１記載のシステム更新方法。
4. ユーザ計算機システムにインストールされ、ベンダ計算機システムから提供を受けるソフトウェアを更新するシステム更新方法において、
   ユーザシステム情報を前記ベンダ計算機システムに送信するステップと、
   前記ベンダ計算機システムにおいて、受信した前記ユーザシステム情報に基づき適切なソフトウェア更新パッチを選択して、前記ユーザ計算機システムにソフトウェア更新パッチを送信するステップと、
   前記ベンダ計算機システムから受信したソフトウェア更新パッチを基にテスト環境を構築するステップと、
   前記テスト環境を利用し前記ソフトウェア更新パッチを評価して評価結果を求めるステップと、
   前記評価結果に従って、前記評価結果が良いときには、前記ソフトウェア更新パッチを利用してユーザ計算機システムにインストールされているソフトウェアを更新するステップと、
   前記評価結果に従って、前記評価結果が悪いときには、前記ベンダ計算機システムに、前記評価結果を送付して、前記ソフトウェア更新パッチの再送付を促すステップとを有することを特徴とするシステム更新方法。
5. ユーザ計算機システムにソフトウェアを提供するベンダ計算機システムにおいて、
   前記ユーザ計算機システムのユーザシステム情報を受信する手段を有するユーザシステム管理部と、
   前記ユーザシステム情報とソフトウェア更新パッチとにより、ユーザ計算機システムのテスト環境を構築する手段と、
   前記テスト環境を利用して、ユーザ計算機システムに適合したソフトウェア更新パッチを評価する手段と、
   前記ソフトウェア更新パッチを前記ユーザ計算機システムに送付する手段とを有することを特徴とするベンダ計算機システム。
6. 前記ベンダ計算機システムを構成する実計算機を、複数の論理計算機に論理的に分割する手段と、前記論理計算機に前記テスト環境を構築する手段とを有することを特徴とする請求項５記載のベンダ計算機システム。
7. 前記ソフトウェア更新パッチをパッチデータベースに記録する手段と、
   前記ユーザ計算機システムからユーザシステム更新要求を取得し、前記ユーザシステム更新要求に基づき前記パッチデータベースから適切なソフトウェア更新パッチを取得する手段とを有することを特徴とする請求項５記載のベンダ計算機システム。
8. 前記ユーザ計算機システムから受信した前記ユーザシステム情報をユーザシステム情報データベースに記録する手段と、
   前記ユーザシステム情報を前記システム情報データベースから取得する手段とを有することを特徴とする請求項５記載のベンダ計算機システム。
9. ベンダ計算機システムからソフトウェアの提供を受けるユーザ計算機システムにおいて、
   ユーザシステム情報を前記ベンダ計算機システムに送信する手段と、
   前記ベンダ計算機システムからソフトウェア更新パッチを受信する手段と、
   前記ベンダ計算機システムから受信したソフトウェア更新パッチと自らのユーザシステム情報を基にテスト環境を構築する手段と、
   前記テスト環境を利用して前記ソフトウェア更新パッチを評価して評価結果を求める手段と、前記評価結果をベンダに送付する手段とを備えることを特徴とするユーザ計算機システム。
10. 前記ユーザ計算機システムを構成する実計算機を、複数の論理計算機に論理的に分割する手段と、前記論理計算機に前記テスト環境を構築する手段とを有することを特徴とする請求項９記載のユーザ計算機システム。
    

Images