JPWO2013094003A1 - ソフトウェアのインストール順序を決定する方法、プログラム、及び装置 - Google Patents

Abstract

複数のソフトウェアを順番に更新する途中で障害が発生するのを極力回避するよう、ソフトウェアの更新順序を決定する。
あるソフトウェアのバージョンがコンピュータに存在する度合の指標を出力する関数を、複数の既知のコンピュータに存在するソフトウェアに関する情報に適用して、複数のソフトウェアの現バージョンと新バージョンとの組合せ毎の指標を算出し、複数のソフトウェアについて、全てが現バージョンである状態から、全てが新バージョンの状態に至るまでの、前記更新プログラムを１つずつインストールする際にとり得る現バージョンと新バージョンとの組合せに対応する指標の総和に基づいて、所定の条件を満たすようインストール順序を決定する。

Description

本発明は、ソフトウェアのインストール又はその更新の技術に関する。

近年のＯＡ化の進展によって、企業内のコンピュータには、様々なバージョンの複数のプログラムがインストールされている。加えて、クラウドコンピューティングが進展してきている。このため、物理マシン、及び仮想マシンを問わず、複数のマシンにインストールされているソフトウェアを安定的に動作させるための管理を行うことが非常に重要となってきている。

各マシンに存在する多数のソフトウェアは、セキュリティの向上や、機能アップを目的として、不定期に更新することが必要となる。

また、様々なソフトウェアは、相互に共通のプログラムを利用している場合もある。また、複数のソフトウェア間での相性が存在する場合もある。

ソフトウェアのインストールや更新に伴い、相性が合わないソフトウェアの組合せが存在するようになると、ソフトウェアの挙動が不安定となったり、動作しなくなったりする場合がある。また、更新プログラムを含むソフトウェアのインストールの順番に起因して、ソフトウェアの挙動が不安定となったり、動作しなくなったりする場合もある。

例えば、ソフトウェアパッケージのパッケージマネジャには、各ソフトウェア同士やライブラリに対する依存関係が書かれている。このパッケージマネジャによれば、例えば、同時にインストールまたは更新できないソフトウェアパッケージが分かるため、それらのインストールや更新を回避できる。

しかしながら、パッケージマネジャに書かれているソフトウェア間の依存関係は、パッケージの作成者が明示的に記述した依存関係である。したがって、例えば、作成者が意識していない複数のバージョン間での依存関係や相性等は明記されていない。

このため、パッケージマネジャが存在するにもかかわらず、複数のソフトウェアの更新を行った際に、例えば、相性の悪いソフトウェアの組合せになってしまい、システムのパフォーマンスが低下したり、動作不能となってしまったりすることがある。

近年では、１つの物理マシン又は仮想マシンに存在するソフトウェアが膨大な数にのぼるため、更新を行う際にも、複数の更新プログラムを順番にインストールすることが多い。この場合、複数の更新プログラムのインストールの順番によって、マシンは非常に多くの状態を経ることになる。更新プログラムのインストールの順番が異なると、そのマシンが経る状態も異なるものとなる。この場合に、更新プログラムの順番が不適切であると、更新の途中で、マシンが非常に不安定な状態に直面することがあり得る。この場合には、その不安定な状態において、マシンがハングアップしてしまうこともある。そして、一連のソフトウェアの更新が継続できなくなることがある。

このように、一連のソフトウェアの更新の途中で、更新が不成功に終わると、多くの場合は、そのマシンのサービスが停止してしまう。そして、その不具合を解決するために多くの労力を割かなければならなくなることが多い。

従来、工程管理支援システムにおいて、作業間の相性値テーブルにより、作業の実行順序（工程）を計画する方法（例えば特許文献１参照）がある。この方法では、作業を特定する作業データに基づき、複数の作業をグループに分けるグループ化手段と、所定数のグループ間の類似性の高さを数値で示す類似性表示テーブルを格納する類似性表示テーブル格納手段と、上記類似性表示テーブルに基づき、上記複数の作業のそれぞれが属するグループ間の類似性を比較する類似性比較手段と、上記類似性比較手段による比較結果に基づき、先に行われる作業の後には該作業と類似性が最も高い他の作業が続くように上記複数の作業の実行順序を決定する工程計画手段とを有している。

しかしながら、このような工程管理支援システムで対象とする工程は、色塗り工程のような実作業の工程であり、本発明が対象としているソフトウェアのインストールとは、異なるものである。また、このような工程管理支援システムでは、前後に連続する2つの工程間の相性を調べることで前工程から後工程への推移時間を短くすることを目的とし、本発明のようにインストールの途中の状態をもとにして順番を決めるものと比して、過去の順番も考慮に入れている点と場合分けが膨大になることへの計算手段の点で、根本的な差が存在する。

また、従来、部品（ソフトウェアを含む）要素間の接続性の安定度を計算する技術（例えば、特許文献２）が存在する。この技術は、例えば、ストレージシステムにおけるハードウェアとソフトウェアのバージョンの相性を見て、構成の安定度の高い組合せを提示するものである。この技術は、ソフトウェアのインストールの順序を決定する技術ではない。

また、ハードウェアや、ハード部品間の相性情報を踏まえてチェックを行う技術（例えば特許文献３）が存在する。この技術は、コンピュータや携帯情報端末などが接続されるコンピュータネットワークにおいて、利用者のコンピュータのアップグレードや再生等の要望に応じて、機種に適合する部品を検索し、適否を判定し、注文をすることができるコンピュータのアップグレードに関するものである。この技術も、ソフトウェアのインストールの順序を決定する技術ではない。

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

１つの側面では、複数のソフトウェアを順番にインストールする際のシステムの安定化を図ることを目的とする。

本プログラムは、目的のコンピュータにインストールされている複数のソフトウェアを現バージョンから、新バージョンに更新するために、前記複数のソフトウェアのそれぞれに対応する複数の更新プログラムを順にインストールするためのインストール順序を決定するプログラムであって、あるソフトウェアのバージョンがコンピュータに存在する度合の指標を出力する関数を、複数の既知のコンピュータに存在するソフトウェアに関する情報に適用して、前記複数のソフトウェアの現バージョンと新バージョンとの組合せ毎の前記指標を算出し、前記複数のソフトウェアについて、全てが現バージョンである状態から、全てが新バージョンの状態に至るまでの、前記更新プログラムを１つずつインストールする際にとり得る現バージョンと新バージョンとの組合せに対応する前記指標の総和に基づいて、所定の条件を満たす前記インストール順序を探索する、処理をコンピュータに実行させるプログラムを提供する。

複数のプログラムのインストールの際のシステムの安定性の確保を図ることができる。

複数のマシンに存在するソフトウェアのバージョンを示す図である。 ハイパーキューブを用いてソフトウェアのインストール順序を示した図である。 更新プログラムを順にインストールしたときの状態遷移を示す図である。 複数のマシンに、存在するソフトウェアのバージョンを示す図である。 複数のソフトウェアのバージョンに対応する稀（まれ）度を示した図である。 各ソフトウェアのバージョンの稀度を合計した稀度を示す図である。 インストール順序毎に状態がとり得る稀度の総和を示した図である。 一実施例のブロック図である。 ＤＢにソフトウェアのバージョン毎の稀度を格納するフローを示す図である。 稀度から最適なインストール順序を出力するフローを示す図である。 相関性のあるソフトウェアを抽出する一実施例のブロック図である。 相関の高いソフトウェアの部分集合を示す図である。 相関の高いソフトウェアの部分集合を抽出するフローを示す図である。 一実施例のハードウェア構成を示す図である。 複数のソフトウェアの組合せの稀度を取り扱う一実施例を示す図である。 一実施例の方法のフローチャートを示す図である。 マシンに存在するソフトウェアの個数及び稀度を示す図である。 インストール順序毎に状態がとり得る稀度の総和を示した図である。 ハイパーキューブによる最適経路の探索の例を示す図である。

図１は、複数のマシン（物理マシン又は仮想マシン）に、存在する（インストールされている）ソフトウェアＡ、Ｂ、及びＣのバージョンを示す図である。ソフトウェアＡについては、バージョン５または６がインストールされており、ソフトウェアBについては、バージョン５．５または６．０がインストールされており、ソフトウェアＣについては、バージョン４．１または５．１がインストールされている。

この状況において、マシン１に対して、ソフトウェアＡについてバージョン５から６に、ソフトウェアＢについてバージョン５．５から６．０に、ソフトウェアＣについてバージョン４．１から５．１に、更新する場合を想定する。更新用のソフトウェアは、ソフトウェアＡ、Ｂ、及びＣに対応して、１つずつ存在する。このため、この3個の更新ソフトウェアをインストールする順番は、複数通り（この場合には、６通り）存在する。

図２（Ｂ）は、インストールする状態を、ハイパーキューブを用いて図示したものである。図２（Ａ）は、３つのソフトウェアの更新プログラムをインストールする操作をベクトルの方向として表したものである。たとえば、状態Ｍ１から状態Ｍ２に移動した場合には、ソフトウェアＡが更新されることを表している。すなわち、初期状態Ｍ１から、出発して、ゴールＭ７に至る経路は、６通り存在する。

そして、順番にインストールする際に、安定である可能性が高い経路を経由して、ゴールに至れば、インストールが成功する確率が高くなるであろう。これに対して、インストールの途中で、非常に不安定な状態を経由することとなれば、インストールが途中で止まってしまう可能性が高くなる。あるいは、インストールが完了しても、不安定なマシンの状態となる可能性が高くなるであろう。

既存の多くのマシンに既に存在する複数のソフトウェアのバージョンの組合せであれば、システムが安定的な動作となることが十分予測される。なぜなら、多くのマシンにおいて、その組合せの動作が実証されているからである。これに対して、既存のマシンにおいて稀にしか存在しないか、全く存在しない複数のソフトウェアのバージョンの組合せは、不安定な動作を起こす可能性が高いと言える。なぜなら、このような組合せは、不安定であるか、動作不能であるかの理由で、既存のマシンにおいて、その組合せの存在が稀となってしまっていることが経験上からも予想されるからである。

一般に、複数のソフトウェアを順番にインストールする前に、インストール後のマシンの状態が安定するか否かを予測することは難しい。しかしながら、上記の考察を考慮して、より安定した動作が期待できるインストールの順番を決定することは可能である。

以下、図１の情報を前提として、一例を挙げる。図３（Ａ）は、ソフトウェアＡ、Ｂ、及びＣに係る更新ソフトウェアをＡＢＣの順でインストールした状態遷移図を示している。図３（Ａ）のマシン存在数（１，２，２，３）は、状態（Ｍ１，Ｍ２，Ｍ３，Ｍ４）のそれぞれの状態に対応する、図１の既存のマシンの存在数を示している。この更新の順序においては、いずれの状態においても、ソフトウェアとバージョンの組合せが既存のマシンに存在していることが分かる。

図３（Ｂ）は、別の順序で３つのソフトウェアを更新した例を示している。この場合には、ソフトウェアの更新の順番をＣＢＡとした場合に相当する。この場合、インストールの際の状態（Ｍ１，Ｍ５，Ｍ８，Ｍ７）に対応する、既存のマシンの存在数は、（１，０，０，３）となっている。この場合、状態Ｍ５すなわち、（ソフトウェアＡバージョン5、ソフトウェアＢバージョン５．５、ソフトウェアＣバージョン５．１）は、図１の既存のマシンに存在しない。したがって、状態Ｍ５は、安定的な状態でない可能性が非常に高いと予想される。同様に、状態Ｍ８についても、図１の既存のマシンに、ソフトウェアとバージョンの組合せが存在しない。

上述の２つのインストール順序の例を比較すると、図３（Ａ）の順序すなわち、更新プログラムをソフトウェアＡＢＣの順に実行する方が、ＣＢＡの順に実行するよりも、より安定的な更新が行えることが十分予測できる。

上記の例の場合には、合計６通りのインストール順序が存在するため、これらを比較検討することにより、最も安定的なインストール順序が特定され得る。

［個別のソフトウェアの稀度を用いる実施例］
上述の例では、特定のソフトウェアの組合せを有する既存のマシンの存在数を採り上げて比較を行った。なお、上述の存在数は、1つの指標に過ぎず、本発明は、これに拘束されるものではない。

以下の実施例では、１つの評価関数として、稀（まれ）度を以下のように定義する。なお、本発明は、この評価関数に限定されるものではない。そして、あるソフトウェアＰのバージョンｋがコンピュータに存在する度合の指標として、存在が稀である度合すなわち稀（まれ）度Ｐ_ｋを以下の式により定義する。

ここで、ｘ_ｉは、ソフトウェアＰのバージョンがｉである個数（例えば図４のソフトウェアＡであれば、ｘ_５＝３、ｘ_６＝７）、ｎはソフトウェアＰのバージョンの標本数であり、バージョンｉのソフトウェアＳの個数をｉのとり得る値の全てについて総和をとった値（例えば図４のソフトウェアＡであれば、ｎ＝３＋７＝１０）、である。

そして、上記Ｉ_ｋは、選択情報量と呼び、プログラムＰのバージョンがｋである情報量を表す。（例えば、図４のソフトウェアＡのバージョン５であれば、Ｉ_ｋ＝−log₁₀（ｘ_５／ｎ）＝−log₁₀（３／１０）＝０．５３である）
また、Hは、平均情報量である。(例えば、図４のソフトエアAであれば、H＝−（（ｘ_５／ｎ）log₁₀（ｘ_５／ｎ）＋（ｘ_６／ｎ）log₁₀（ｘ_６／ｎ））＝−（（３／１０）log₁₀（３／１０）＋（７／１０）log₁₀（７／１０））＝０．２６５となる。

そして、ソフトウェアがバージョンｋである選択情報量Ｉ_ｋの重み（重要度）が、ソフトウェア毎に、なるべく変わらないようにするために、そのソフトウェアの平均情報量Ｈで割ることにより、Ｐ_ｋを定義する。すなわち、選択情報量を平均情報量で割ることにより、稀度Ｐ_ｋを算出している。稀度Ｐ_ｋは、ソフトウェアのバージョンｋの存在が、稀であればあるほど、大きな値となる。

なお、選択情報量や、平均情報量にマイナスの符号が付けられているのは、ｘ_ｉ／ｎが、必ず1よりも小さくなるため、logを計算した場合には、その計算結果がマイナスとなるからである。マイナスを付けることにより、選択情報量の値を正の値とすることができる。なお、ｘ_ｉ＝０がゼロの場合には、稀度Ｐ_ｋの計算等のlogの計算結果が計算できないため、例えばＰ_ｋとして、予め定められた大きな値を設定してもよい。

なお、上記の例では、logの底として１０を採用したが、その他の底を採用してもよい。また、log以外の関数を用いてもよい。

また、上記の実施例では、ソフトウェアのバージョンが存在する稀な度合を稀度と定義して用いたが、この稀度は一例に過ぎない。ソフトウェアのバージョンの存在に関する他の指標を用いてもよい。例えば、ソフトウェアのバージョンが存在する可能性が高いほど、大きな値となる指標を定義して用いてもよい。このような指標を用いた場合には、指標の総和が最大となるインストール順序を採用すればよい。

図５は、以上のようにして、図４に示された各ソフトウェアのバージョンに対応する稀度を計算した結果を示している。

図６は、図２（Ｂ）の各々の状態（Ｍ１〜Ｍ８）に対応する稀度を、各ソフトウェアのバージョンの稀度を合計することによって求めた表を表している。このように、各ソフトウェアのバージョンの稀度を合計することによって、近似的に各状態（複数のソフトウエアのバージョンの組合せ）の稀度を計算することができる。特に標本数が少ない場合には、この方式によって、各状態の近似的な稀度が計算できる。なお、標本数が多い場合には、複数のソフトウェアとバージョンの組合せに対する稀度を直接求めてもよい（この例については、後述の実施例で詳細に示す）。

図７は、図２（Ｂ）のハイパーキューブに示された各インストール順序において、インストール順序毎に状態がとり得る稀度の総和を網羅的に計算した表を示している。この中で、稀度の総和が一番小さいインストール順序は、インストール順序２（Ａ，Ｂ，Ｃ）である。そのときの稀度の総和は、１１．６である。そして、状態の遷移は、（Ｍ１，Ｍ２，Ｍ３，Ｍ７）であり、更新ソフトウェアのインストール順序は、Ａ，Ｂ，Ｃの順であることが分かる。すなわち、このインストール順序を経ることが、インストール途中も含めて、一番稀でない状態を経由するということになる。

なお、図７では、全てのインストール順序に関して稀度の総和を計算し、最小値のインストール順序を決定した。しかしながら、最小値を決定する方法としては、当業者に知られているダイクストラ法などの、探索アルゴリズムを用いることにより、図３（Ｂ）のハイパーキューブ上で探索して、最小値を取る経路を求めてもよい。なお、既知のダイクストラ法などの探索アルゴリズムについては、説明を省略する。

図８は、本実施例の機能ブロック図を示している。本実施例においては、運用対象としてのマシン１（８０１）、マシン２（８０２）ないしマシンｎ（８０９）を含む運用対象のシステム群８００のマシン１（８０１）に、バージョンアップ実行部８６０が、上述した一連のバージョンアップを実行する。運用対象のシステム８００の各マシンの情報は、構成情報ＤＢ８１０に予め格納されてもよい。稀度算出部８２０は、構成情報ＤＢ８１０を参照することにより、各マシンに存在するソフトウェアとそのバージョンの情報を取得する。そして、稀度演算部８２２は、上述の計算式を用いて稀度を算出してもよい。算出された稀度は、一旦稀度ＤＢ８３０に格納されてもよい。稀度演算部８２２は、指標演算部に相当する。稀度ＤＢ８３０は、更新プログラムの順序を決定するための情報を蓄積し、後の利用に供してもよい。個別稀度統合部８２４は、ソフトウェアとそのバージョンの個別の稀度を合計して複数のソフトウェアとバージョンの組合せの稀度を計算してもよい。なお、この計算において、合計ではなく他の演算を用いてもよい。個別稀度統合部８２４は、指標統合部に相当する。この統合された結果は、稀度ＤＢに８３０に再び格納されてもよく、あるいは、最適経路探索部８４０に直接送られてもよい。最適経路探索部８４０は、稀度ＤＢ８３０に格納された稀度を読み出し、図２（Ｂ）に示したハイパーキューブを作成し、バージョンアップ順序のうちで、稀度の合計値が一番小さくなるバージョンアップ順序を決定するよう、ハイパーキューブの経路探索手法を用いて探索する。そして、最適経路探索部８４０は、最適な（すなわち、安定した動作が期待できる）バージョンアップ順序８５０を出力する。この出力されたバージョンアップ順序８５０を用いて、バージョンアップ実行部８６０が、目的のマシンであるマシン１に対して、一連のソフトウェアの更新を実行する。

図９は、個別稀度ＤＢに複数のソフトウエア（例えばＮ個）のソフトウェアのバージョン毎に稀度を格納するフローを示している。

ステップ９１０において、全マシンの状態を構成情報ＤＢ８１０から取得する。そしてステップ９１２に移る。

ステップ９１２において、まだ個別稀度を算出していないソフトウェアがあるか否かが判断される。既に、全てのソフトウェアの個別稀度が算出されている場合には、終了する。まだ個別稀度を算出していないソフトウェアがある場合には、ステップ９１４に移る。

ステップ９１４において、ソフトウェアのバージョンごとに、個別稀度を算出する。そして、ステップ９１６に移る。

ステップ９１６において、個別稀度ＤＢに個別稀度を格納する。そして、ステップ９１２に戻る。

ステップ９１２において、既に、全てのソフトウェアの個別稀度が算出されている場合には、終了する。

図１０は、算出された稀度から最適なインストール順序を出力するフローを示している。

ステップ１０１０において、図２（Ｂ）に示したハイパーキューブを作る（ハイパーキューブにおける、初期状態からゴールに至る経路のバリエーションの数は、Ｎの階乗個となる）。そしてステップ１０１２に移る。

ステップ１０１２において、ハイパーキューブの各頂点に個別稀度DBを用いて稀度を付ける。この稀度の算出については、図６を用いて説明した手法を用いる。算出方法としては、各ソフトウェアのバージョンの稀度の合計を用いてもよい。あるいは、その他の演算手法を用いてもよい。そして、ステップ１０１４に移る。

ステップ１０１４において、ハイパーキューブから最適経路を求める。最適経路は、各頂点にある稀度の総和が最小となる経路を求める。この最適経路の求め方としては、図７に示した網羅的な手法を用いてもよい。あるいは、ダイクストラ法などの探索アルゴリズムを用いてもよい。そして、ステップ１０１６に移る。

ステップ１０１６において、求めた最適経路に基づいて、更新プログラムの最適なインストール順序を出力する。

図１１は、バージョンに関して相関性のあるソフトウェアを抽出する機能ブロック図を示している。相関性判定部１１１０は、構成情報ＤＢ８１０に格納された各ソフトウェアのバージョンの情報から、バージョンに関する相関性の高い複数のソフトウェアを抽出する機能を有する。相関性判定部１１１０には、相関計算部１１１２が設けられており、複数のソフトウェアの相関値が計算される。相関性の高い複数のソフトウェアは、部分集合抽出部１１１４によって、ソフトウェアの部分集合を構成する。そして、その部分集合は、１つのソフトウェアとして、稀度算出部８２０及び／又は最適経路探索部において取り扱われてもよい。複数のソフトウェアを部分集合にまとめて、1つのソフトウェアとして扱うことにより、稀度の計算や経路探索の計算が簡略化される。なお、部分集合としてまとめられたソフトウェアに含まれるソフトウェアに対応する更新ソフトウェアのインストールの順番は、連続にしてもよい。また、インストールの順番は、予め指定された順序で実行してもよい。あるいは、部分集合に含まれるソフトウェアに対して、本実施例のインストール順序決定の手法を再帰的に適用して、インストールの順番を決定してもよい。また、予め定められた複数のソフトウェアを、部分集合としてまとめるよう、指定してもよい。

図１２（Ａ）ないし（Ｃ）は、バージョンに関して相関の高いソフトウェアの部分集合を示している。図１２（Ａ）は、マシン１ないし１０に存在するソフトウェアＤ，Ｅ，Ｆのバージョンを示している。

図１２（Ｂ）は、ソフトウェアＤ及びＥと、それらのバージョン間の個数を示している。図１２（Ｂ）から分かるように、ソフトウェアＤの古いバージョン（５）と、ソフトウェアＥの古いバージョン（５．５）の組合せが多く、かつ、ソフトウェアＤの新しいバージョン（６）と、ソフトウェアＥの古いバージョン（６．０）の組合せが多い。これは、ソフトウェアＤとＥとの間で、バージョンに関して相関が高いことを示している。新旧バージョンに関して相関係数が正であり、かつ予め定められた閾値よりも相関係数が高い場合、複数のソフトウェアを、例えば図１２（Ｃ）のようにまとめてもよい。このようにまとめることによって、1つのソフトウェアとして取り扱ってもよい。

図１２（Ｃ）の場合には、例えば、以下のようにして稀度を計算してもよい。

ここで、Ｉ_{（Ｄ５，Ｅ５．５）}とは、ソフトウェアＤのバージョン５とソフトウェアＥのバージョン５．５の組に対する選択情報量を意味する。このような標記については、以下の数式についても同様である。

図１３は、バージョンに関して相関の高いソフトウェアの部分集合を抽出するフローを示している。

ステップ１３１０において、複数のソフトウェアの部分集合を全て網羅したかが、判断される。全てを網羅していない場合には、ステップ１３１２に進む。

ステップ１３１２において、新たな複数のソフトウェアの部分集合を１つ抽出する。そして、次のステップ１３１４に進む。

ステップ１３１４において、現・新バージョンに関して、部分集合に属する複数のソフトウェアの相関値を計算する。そして、ステップ１３１６に進む。

ステップ１３１６において、相関値が、所定の閾値以上であるか否かを判断する。相関値が所定の閾値以上である場合には、ステップ１３１８に進む。相関値が所定の閾値未満であれば、ステップ１３１０に戻る。

ステップ１３１８において、入力されたソフトウェアの部分集合をグループ化し、一つにまとめる。そしてステップ１３１０に戻る。

ステップ１３１０において、複数のソフトウェアの部分集合を全て網羅した場合には、処理は終了する。

図１４は、各マシン８００及び管理用サーバ（不図示）のハードウェア構成を示している。各マシン８００及び管理用サーバは、ＣＰＵ１４１０、メモリ１４１５、入力装置１４２０、出力装置１４２５、外部記憶装置１４３０、可搬記憶媒体駆動装置１４３５、ネットワーク接続装置１４４５が含まれる。そして、それぞれの機器は、バス１４５０によって接続されている。また、可搬記録媒体駆動装置１４３５は、可搬記録媒体１４４０を読み書きすることができる。そして、ネットワーク接続装置１４４５には、ネットワーク１４６０が接続されている。ネットワーク１４６０を介して他のマシンに接続されてもよい。また、ネットワークは、インターネット等の外部ネットワークに接続されてもよい。

なお、本実施形態のプログラムは、可搬記録媒体１４４０に格納することができる。可搬記録媒体１４４０とは、構造（structure）を有する１つ以上の非一時的（non-transitory）な、有形（tangible）な、記憶媒体を言う。例示として、可搬記録媒体１４４０としては、磁気記録媒体、光ディスク、光磁気記録媒体、不揮発性メモリなどがある。磁気記録媒体には、ＨＤＤ、フレキシブルディスク（ＦＤ）、磁気テープ（ＭＴ）などがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc-Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。また、光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。

［複数のソフトウェアの組合せの稀度を用いる実施例］
上述の実施例では、個別のソフトウェアとそのバージョンの稀度を算出した。上述の実施例は、標本数が少ない場合には有効な手法である。なお、標本数が十分にある場合には、下記に示す実施例を利用してもよい。すなわち、各状態における複数のソフトウェアとバージョンとの組合せに関して直接稀度を算出して、処理を進める実施例について、以下に説明する。

図１５は、複数のソフトウェアとそのバージョンとの組合せに対して稀度を計算する機能ブロック図である。構成は、図８と類似しており、図８と図１５のシステムは、統合されて1つのシステムとして構成されてもよい。図８と相違する部分について、以下説明する。

組合せ稀度算出部１５２０は、構成情報ＤＢ８１０から複数のソフトウェアとそのバージョンの組合せに係る稀度を算出する。組合せ稀度算出部１５２０は、組合せ指標算出部に相当する。算出の詳細は、後述する。そして、組合せ稀度ＤＢ１５３０に、算出された組合せ稀度を格納する。

その他の処理については、図８の処理と同様であるので説明を省略する。

図１６は、本実施例の方法のフローチャートを示している。まず、ステップ１６１０において、複数（例えばＮ個）のソフトウェアの現・新バージョンの組合せについて稀度を算出する（組合せの個数は、Ｎの階乗個となる）。なお、ステップ１６１０において、計算された稀度は、組合せ稀度ＤＢ１６３０に蓄積してもよい。

そして、ステップ１６１２において、稀度を算出していないバージョンの組合せがあるかを判断する。判断結果が「はい」であれば、ステップ１６１０に戻る。判断結果が「いいえ」であれば、ステップ１６１４に移動する。

ステップ１６１４において、全てが現バージョンの状態から、全てが新バージョンの状態に至るまで、更新ソフトウェアを１つずつインストールする際にとり得るバージョンの組合せの稀度の総和が最小となるインストール順序を探索する。

ステップ１６１６において、探索されたインストール順序が出力される。

図１７は、構成情報ＤＢ８１０に蓄積されている、既存の複数のマシンに存在する相当エアＰ，Ｑ，Ｒとそれぞれのバージョンとの組合せの個数及び稀度を示している。図17において、例えば状態Ｍ１２に関して以下説明する。状態Ｍ１２においては、ソフトウェアＰ，Ｑ，Ｒのバージョンがそれぞれ、6，5.5，4.1であり、構成情報ＤＢ８１０には、その構成を持つマシンが３つ存在していることが分かる。状態Ｍ１２に対する稀度を計算すると以下の通りである。すなわち、

となる。その他の状態についても同様に計算できる。なお、Ｉ_ｋ、ｘ_ｋ、Ｐ_ｋのｋは、ベクトル形式（例えば上述のように、（P6，Q5.5，R4.1）のように、ベクトル形式で標記できる。

図１８は、各インストール順序における状態遷移、稀度の総和を網羅的に計算した値を示している。稀度の総和が最も小さいのは、インストール順序３（Ｒ，Ｐ，Ｑ）の値４．８である。従って、ソフトウェア更新プログラムのインストール順序は、Ｒ，Ｐ，Ｑが最適となることが分かる。

図１９（Ｂ）は、それぞれの状態をハイパーキューブで表したものであり、その矢印に沿った経路が最適な経路であり、そのインストール順序は、上述の通りＲ，Ｐ，Ｑの順である。なお、図１８では、網羅的に計算して、最小値を求めたが、図１９のハイパーキューブ上を、ダイクストラ法などの、経路探索アルゴリズムで探索することにより、速く最適経路を見つけ出すことが可能である。

なお、以上の実施例では、ハイパーキューブとして三次元のものを例示したが、ソフトウェアの更新プログラムの数が３を超える場合には、三次元を超えるハイパーキューブにおいて、経路探索を行えばよい。本実施例では、三次元を超える例については、図示ができないために例示していない。しかしながら、三次元を超える場合についても、当業者であれば、そのプロセスを理解できることは明らかである。次元が大きくなれば、ダイクストラ法等の探索アルゴリズムを利用するメリットが増大することも理解できることは明らかである。

なお、本明細書においては、ソフトウェアを更新する実施例を中心に説明した。本明細書において使用する更新、及び更新プログラムは、広い概念を持つものとして理解すべきである。例えば新規にインストールするソフトウェアのインストールも、本発明における更新プログラムに含み得ることは言うまでもない。そして、本実施例に開示されたインストールの順番を決定する手法を用いて、新規にインストールするソフトウェアも含めた、複数のソフトウェアのインストールの順番を決定してもよい。

また、それぞれの実施例に開示された構成は、排他的なものではない。したがって、矛盾のない限り、複数の実施例の構成要素を任意に組み合わせることができる。

加えて、本実施例における方法、及びプログラムは、矛盾のない限り、その構成要素の順番を入れ替えて実施できる。添付の請求項に記載された方法、及びプログラムの構成要素の順番を入れ替えたものについても、その請求項の技術的範囲に属することは言うまでもない。

以上、実施例について説明したが、それぞれの実施例は、本発明を例示的に説明するためのものである。したがって、開示された実施例は、本発明を限定的に解釈するためのものでないことは言うまでもない。

８００ 運用対象のマシン
８１０ 構成情報ＤＢ
８２０ 稀度算出部
８３０ 稀度ＤＢ
８４０ 最適経路探索部
８５０ バージョンアップ順序
８６０ バージョンアップ実行部
１１１０ 相関性判定部
１５２０ 組合せ稀度算出部
１５３０ 組合せ稀度ＤＢ

Claims (21)

1. 目的のコンピュータにインストールされている複数のソフトウェアを現バージョンから、新バージョンに更新するために、前記複数のソフトウェアのそれぞれに対応する複数の更新プログラムを順にインストールするためのインストール順序を決定するプログラムであって、
   あるソフトウェアのバージョンがコンピュータに存在する度合の指標を出力する関数を、複数の既知のコンピュータに存在するソフトウェアに関する情報に適用して、前記複数のソフトウェアの現バージョンと新バージョンとの組合せ毎の前記指標を算出し、
   前記複数のソフトウェアについて、全てが現バージョンである状態から、全てが新バージョンの状態に至るまでの、前記更新プログラムを１つずつインストールする際にとり得る現バージョンと新バージョンとの組合せに対応する前記指標の総和に基づいて、所定の条件を満たす前記インストール順序を探索する、
   処理をコンピュータに実行させるプログラム。
2. 前記指標を算出する処理は、前記複数のソフトウェアのバージョンの各々に対して、前記関数を適用して前記指標を求め、前記組合せに含まれる複数のソフトウェアのバージョンの各々に対応する前記指標を統合することにより、前記組合せ毎の前記指標を算出する、請求項１記載のプログラム。
3. 前記指標を算出する処理は、前記組合せに前記関数を適用して、前記組合せ毎の前記指標を算出する、請求項１記載のプログラム。
4. 前記関数は、
   Ｎ（Ｎ≧１）個のソフトウェアのバージョンｋ（ｋはＮ次元ベクトル）に対して、前記指標Ｐ_ｋ（Ｐ_ｋはスカラー値）を、ｋのとり得る値について網羅的に出力するものであり、前記指標Ｐ_ｋは、
   

   

   によって与えられ、
   ここで、ｘ_ｉは、前記Ｎ個のソフトウェアのバージョンがｉ（ｉはＮ次元ベクトル）である個数であり、
   前記所定の条件は、前記総和が最小値となることである、
   請求項１記載のプログラム。
5. 前記複数のソフトウェアのうちの２個以上を含む部分集合に対して、現バージョン及び新バージョンに関して、前記部分集合に属する複数のソフトウェアの相関値を計算し、
   前記相関値が、所定の閾値よりも大きい部分集合を抽出し、
   前記抽出された部分集合に含まれる各ソフトウェアを、１つのソフトウェアとして扱うためにグループ化する、
   処理をコンピュータに実行させる、請求項１記載のプログラム。
6. 前記複数のソフトウェアのうちの２個以上を含む部分集合に対して、現バージョン及び新バージョンに関して、前記部分集合に属する複数のソフトウェアの相関値を計算し、
   前記相関値が、所定の閾値よりも大きい部分集合を抽出する、
   処理をコンピュータに実行させ、
   前記抽出された部分集合に含まれる各ソフトウェアをさらに処理の対象とする、請求項１記載のプログラム。
7. 前記所定の条件を満たす前記インストール順序を探索するために、最短経路探索を行うアルゴリズムを用いる、請求項１記載のプログラム。
8. 目的のコンピュータにインストールされている複数のソフトウェアを現バージョンから、新バージョンに更新するために、前記複数のソフトウェアのそれぞれに対応する複数の更新プログラムを順にインストールするためのインストール順序を決定する方法であって、
   あるソフトウェアのバージョンがコンピュータに存在する度合の指標を出力する関数を、複数の既知のコンピュータに存在するソフトウェアに関する情報に適用して、前記複数のソフトウェアの現バージョンと新バージョンとの組合せ毎の前記指標を算出し、
   前記複数のソフトウェアについて、全てが現バージョンの状態から、全てが新バージョンの状態に至るまで、前記更新プログラムを１つずつインストールする際にとり得る現バージョンと新バージョンとの組合せに対応する前記指標の総和が所定の条件を満たす前記インストール順序を探索する、
   処理をコンピュータが実行する方法。
9. 前記指標を算出する処理は、前記複数のソフトウェアのバージョンの各々に対して、前記関数を適用して前記指標を求め、前記組合せに含まれる複数のソフトウェアのバージョンの各々に対応する前記指標を統合することにより、前記組合せ毎の前記指標を算出する、請求項８記載の方法。
10. 前記指標を算出する処理は、前記組合せに前記関数を適用して、前記組合せ毎の前記指標を算出する、請求項８記載の方法。
11. 前記関数は、
    Ｎ（Ｎ≧１）個のソフトウェアのバージョンｋ（ｋはＮ次元ベクトル）に対して、前記指標Ｐ_ｋ（Ｐ_ｋはスカラー値）を、ｋのとり得る値について網羅的に出力するものであり、前記指標Ｐ_ｋは、
    

    

    によって与えられ、
    ここで、ｘ_ｉは、前記Ｎ個のソフトウェアのバージョンがｉ（ｉはＮ次元ベクトル）である個数であり、
    前記所定の条件は、前記総和が最小値となることである、
    請求項８記載の方法。
12. 前記複数のソフトウェアのうちの２個以上を含む部分集合に対して、現バージョン及び新バージョンに関して、前記部分集合に属する複数のソフトウェアの相関値を計算し、
    前記相関値が、所定の閾値よりも大きい部分集合を抽出し、
    前記抽出された部分集合に含まれる各ソフトウェアを、１つのソフトウェアとして扱うためにグループ化する、
    処理をコンピュータが実行する、請求項８記載の方法。
13. 前記複数のソフトウェアのうちの２個以上を含む部分集合に対して、現バージョン及び新バージョンに関して、前記部分集合に属する複数のソフトウェアの相関値を計算し、
    前記相関値が、所定の閾値よりも大きい部分集合を抽出する、
    処理をコンピュータが実行し、
    前記抽出された部分集合に含まれる各ソフトウェアをさらに処理の対象とする請求項８記載の方法。
14. 前記所定の条件を満たす前記インストール順序を探索するために、最短経路探索を行うアルゴリズムを用いる、請求項８記載の方法。
15. 目的のコンピュータにインストールされている複数のソフトウェアを現バージョンから、新バージョンに更新するために、前記複数のソフトウェアのそれぞれに対応する複数の更新プログラムを順にインストールするためのインストール順序を決定する情報処理装置であって、
    あるソフトウェアのバージョンがコンピュータに存在する度合の指標を出力する関数を、複数の既知のコンピュータに存在するソフトウェアに関する情報に適用して、前記複数のソフトウェアの現バージョンと新バージョンとの組合せ毎の前記指標を算出する算出部と、
    前記複数のソフトウェアについて、全てが現バージョンである状態から、全てが新バージョンの状態に至るまでの、前記更新プログラムを１つずつインストールする際にとり得る現バージョンと新バージョンとの組合せに対応する前記指標の総和に基づいて、所定の条件を満たす前記インストール順序を探索する探索部と、
    を有する情報処理装置。
16. 前記算出部は、前記複数のソフトウェアのバージョンの各々に対して、前記関数を適用して前記指標を求めるソフトウェアバージョン指標演算部と、前記組合せに含まれる複数のソフトウェアのバージョンの各々に対応する前記指標を統合することにより、前記組合せ毎の前記指標を算出する指標統合部と、を有する請求項１５記載の情報処理装置。
17. 前記算出部は、前記組合せに前記関数を適用して、前記組合せ毎の前記指標を算出する組合せ指標算出部、を有する請求項１５記載の情報処理装置。
18. 前記関数は、
    Ｎ（Ｎ≧１）個のソフトウェアのバージョンｋ（ｋはＮ次元ベクトル）に対して、前記指標Ｐ_ｋ（Ｐ_ｋはスカラー値）を、ｋのとり得る値について網羅的に出力するものであり、前記指標Ｐ_ｋは、
    

    

    によって与えられ、
    ここで、ｘ_ｉは、前記Ｎ個のソフトウェアのバージョンがｉ（ｉはＮ次元ベクトル）である個数であり、
    前記所定の条件は、前記総和が最小値となることである、
    請求項１５記載の情報処理装置。
19. 前記複数のソフトウェアのうちの２個以上を含む部分集合に対して、現バージョン及び新バージョンに関して、前記部分集合に属する複数のソフトウェアの相関値を計算する相関計算部と、
    前記相関値が、所定の閾値よりも大きい部分集合を抽出する部分集合抽出部と、
    を有し、
    前記抽出された部分集合に含まれる各ソフトウェアを、１つのソフトウェアとして扱うためにグループ化する、請求項１５記載の情報処理装置。
20. 前記複数のソフトウェアのうちの２個以上を含む部分集合に対して、現バージョン及び新バージョンに関して、前記部分集合に属する複数のソフトウェアの相関値を計算する相関計算部と、
    前記相関値が、所定の閾値よりも大きい部分集合を抽出する部分集合抽出部と、
    を有し、
    前記抽出された部分集合に含まれる各ソフトウェアをさらに処理の対象とする、請求項１５記載の情報処理装置。
21. 前記所定の条件を満たす前記インストール順序を探索するために、最短経路探索を行うアルゴリズムを用いる、請求項１５記載の情報処理装置。

Images