(57)【特許請求の範囲】
【請求項１】
要求元端末からの要求に応じて該要求元端末に対してソフトウェアを配布するプログラム配布サーバであって、
前記プログラム配布サーバは、第１のソフトウェアに依存される第２のソフトウェアがどのような複数の機能を有するかを示す第１の情報と、前記複数の機能のうちどの機能が前記第２のソフトウェアのバージョンアップに伴い変更されたかを示す第２の情報と、前記第１のソフトウェアが前記第２のソフトウェアのうちどれを使用するかを示す第３の情報と、前記第１のソフトウェアが、使用する前記第２のソフトウェアが有する機能のうちのどの機能を使用するかを示す第４の情報と、を有し、
前記第２のソフトウェアがバージョンアップされた場合であって、前記第１から第４の情報を基に前記第１のソフトウェアの動作検証が必要だと判断した場合には、その旨を開発者端末に通知し、ネットワークにより前記プログラム配布サーバに接続されたテストケース実行手段に働きかけてテストケースを実行させ、前記テストケースが成功した場合のみ、前記要求元端末に配布する前記第１のソフトウェアの更新を可能と判定することを特徴とするプログラム配布サーバ。
【請求項２】
セキュリティを保ったまま課金する課金手段を有し、前記テストケースの実行に伴い、テスト依頼元端末にテスト費用の請求を行うことを特徴とする請求項１記載のプログラム配布サーバ。
【請求項３】
要求元端末からの要求に応じて該要求元端末に対してソフトウェアを配布するプログラム配布サーバのプログラム配布方法であって、
前記プログラム配布サーバは、第１のソフトウェアに依存される第２のソフトウェアがどのような複数の機能を有するかを示す第１の情報と、前記複数の機能のうちどの機能が前記第２のソフトウェアのバージョンアップに伴い変更されたかを示す第２の情報と、前記第１のソフトウェアが前記第２のソフトウェアのうちどれを使用するかを示す第３の情報と、前記第１のソフトウェアが、使用する前記第２のソフトウェアが有する機能のうちのどの機能を使用するかを示す第４の情報と、を有し、
前記第２のソフトウェアがバージョンアップされた場合であって、前記第１から第４の情報を基に前記第１のソフトウェアの動作検証が必要だと判断した場合には、その旨を開発者端末に通知し、ネットワークにより前記プログラム配布サーバに接続されたテストケース実行手段に働きかけてテストケースを実行させ、前記テストケースが成功した場合のみ、前記要求元端末に配布する前記第１のソフトウェアの更新を可能と判定することを特徴とするプログラム配布サーバのプログラム配布方法。
【請求項４】
セキュリティを保ったまま課金する課金手段を有し、前記テストケースの実行に伴い、テスト依頼元端末にテスト費用の請求を行うことを特徴とする請求項３記載のプログラム配布サーバのプログラム配布方法。
【請求項５】
請求項３又は４に記載のプログラム配布方法を、コンピュータに実行させるためのプログラム配布プログラム。
【請求項６】
請求項５記載のプログラム配布プログラムを記録した記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介し、ユーザ端末に対して要求されたプログラムを提供する、プログラム配布サーバ、プログラム配布方法、及び、プログラム配布プログラムとその記録媒体に関する。
【背景技術】
【０００２】
従来、インターネット等のコンピュータ・ネットワークを利用して更新されたソフトウェアを配布するシステムとしては、特許文献１に開示されるものがある。特許文献１に記載されているシステムによれば，プログラムが動作するコンピュータ上に，プログラムアップデートのためのコンポーネント（アップデータ・コンポーネント）が配置され，このアップデータ・コンポーネントが、プログラムを配布するサーバに自動的にアクセスし、プログラムを更新する。
【０００３】
更に、そのプログラムが依存している他のプログラムがあれば、それらのアップデートも同時に行う。これらの効果により、プログラムの更新が自動化されるため，利用者の負担が軽減されることになる。特許文献１に従い、依存関係をもつ複数のプログラムを同時に、かつ、安全に更新するには、「依存関係の定義」を管理し、その情報の鮮度を維持する必要がある。
【０００４】
ある種のソフトウェア（以下、プラットフォームソフトウェア）は、ＳＤＫ（ソフトウェア開発キット）や、プラグインと呼ばれる機構を提供する。プラットフォームソフトウェアをそのまま利用する場合もあるが、外部ベンダーがこれらの機構を使い、プラットフォームソフトウェアを拡張し、また、拡張した部分（以下、ソリューションソフトウェア）を独自に販売するケースがある（一般的に、ソリューションソフトウェアは、プラットフォームソフトウェアに遅れて市場投入される）。
【０００５】
プラットフォームソフトウェアに障害対策が行われたり、機能拡張が行われた場合、その提供ベンダーは、外部ベンダーに対してプラットフォームソフトウェアの更新が市場に配布されることを知らせる必要がある。また、知らせを受けた外部ベンダーは、既リリース済みのソリューションソフトウェアと連携させたときに問題が発生しないか評価し、市場にアナウンスをする必要がある。
【０００６】
これらのソリューションソフトウェアが膨大な数になってくると、プラットフォームソフトウェアの更新に支障が出てくる。なぜなら、すべてのソリューションソフトウェアの評価完了を待ってから更新をリリースしたのでは、その確認の手間が増大する問題と、更新を迅速に提供できなくなる問題が発生する。また、プラットフォームソフトウェアを単体で使っている顧客にとって、ソリューションソフトウェアとの連携評価は不要であり、いち早く更新を手にする必要がある。
【特許文献１】特許第３３８５５９０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかし、上述したような状況において、特許文献１の方式を採用すると、依存情報の管理が膨大な手間となり、また、導入されているソリューションソフトウェアの組によって、あるいは、組み合わせ評価の完了有無によって、依存情報を動的に更新しなければならないという問題があった。
【０００８】
上記問題を言い換えると、プラットフォームソフトウェア単体で使っている顧客や、既に組み合わせ評価が完了しているソリューションソフトウェアのみを使っている顧客からみれば更新が提供されているように見え、逆に評価の終わっていないソリューションソフトウェアを使っている顧客から見れば、まだ更新が提供されていないように見えるようにしなければならないという問題があった。
【０００９】
本発明は、上記のような問題点に鑑み、プラットフォームソフトウェアの更新が発生してから、外部ベンダーがソリューションソフトウェアの更新を提供する或いは更新が必要ないことを確定するまでの業務フロー、及び、組み合わせ評価をプラットフォームソフトウェアの提供ベンダーが請け負う仕組みについての改善がなされた、プログラム配布サーバ、プログラム配布方法、及び、プログラム配布プログラムとその記録媒体を提供することを目的とする。
【課題を解決するための手段】
【００１０】
請求項１記載の発明は、要求元端末からの要求に応じて該要求元端末に対してソフトウェアを配布するプログラム配布サーバであって、前記プログラム配布サーバは、第１のソフトウェアに依存される第２のソフトウェアがどのような複数の機能を有するかを示す第１の情報と、前記複数の機能のうちどの機能が前記第２のソフトウェアのバージョンアップに伴い変更されたかを示す第２の情報と、前記第１のソフトウェアが前記第２のソフトウェアのうちどれを使用するかを示す第３の情報と、前記第１のソフトウェアが、使用する前記第２のソフトウェアが有する機能のうちのどの機能を使用するかを示す第４の情報と、を有し、前記第２のソフトウェアがバージョンアップされた場合であって、前記第１から第４の情報を基に前記第１のソフトウェアの動作検証が必要だと判断した場合には、その旨を開発者端末に通知し、ネットワークにより前記プログラム配布サーバに接続されたテストケース実行手段に働きかけてテストケースを実行させ、前記テストケースが成功した場合のみ、前記要求元端末に配布する前記第１のソフトウェアの更新を可能と判定するプログラム配布サーバとしたことを特徴とする。
【００１２】
請求項２記載の発明は、セキュリティを保ったまま課金する課金手段を有し、前記テストケースの実行に伴い、テスト依頼元端末にテスト費用の請求を行う請求項１記載のプログラム配布サーバとしたことを特徴とする。
【００１３】
請求項３記載の発明は、要求元端末からの要求に応じて該要求元端末に対してソフトウェアを配布するプログラム配布サーバのプログラム配布方法であって、前記プログラム配布サーバは、第１のソフトウェアに依存される第２のソフトウェアがどのような複数の機能を有するかを示す第１の情報と、前記複数の機能のうちどの機能が前記第２のソフトウェアのバージョンアップに伴い変更されたかを示す第２の情報と、前記第１のソフトウェアが前記第２のソフトウェアのうちどれを使用するかを示す第３の情報と、前記第１のソフトウェアが、使用する前記第２のソフトウェアが有する機能のうちのどの機能を使用するかを示す第４の情報と、を有し、前記第２のソフトウェアがバージョンアップされた場合であって、前記第１から第４の情報を基に前記第１のソフトウェアの動作検証が必要だと判断した場合には、その旨を開発者端末に通知し、ネットワークにより前記プログラム配布サーバに接続されたテストケース実行手段に働きかけてテストケースを実行させ、前記テストケースが成功した場合のみ、前記要求元端末に配布する前記第１のソフトウェアの更新を可能と判定するプログラム配布サーバのプログラム配布方法としたことを特徴とする。
【００１５】
請求項４記載の発明は、セキュリティを保ったまま課金する課金手段を有し、前記テストケースの実行に伴い、テスト依頼元端末にテスト費用の請求を行う請求項３記載のプログラム配布サーバのプログラム配布方法としたことを特徴とする。
【００１６】
請求項５記載の発明は、請求項３又は４に記載のプログラム配布方法を、コンピュータに実行させるためのプログラム配布プログラムとしたことを特徴とする。
【００１７】
請求項６記載の発明は、請求項５記載のプログラム配布プログラムを記録した記録媒体としたことを特徴とする。
【発明の効果】
【００１８】
本発明によれば、プラットフォームソフトウェアの更新が発生してから、外部ベンダーがソリューションソフトウェアの更新を提供する或いは更新が必要ないことを確定するまでの業務フロー、及び、組み合わせ評価をプラットフォームソフトウェアの提供ベンダーが請け負う仕組みについての改善がなされた、プログラム配布サーバ、プログラム配布方法、及び、プログラム配布プログラムとその記録媒体を実現することができる。
【発明を実施するための最良の形態】
【００１９】
本発明を実施するための最良の形態は、外部ベンダーから供給される複数のソフトウェアのいずれかを、ユーザ端末からの要求に応じてユーザ端末に対して配布するプログラム配布サーバにおいて、上記プログラム配布サーバが、外部ベンダーから供給されるソフトウェアがどのような複数の機能を有するかを示す第１の情報と、上記複数の機能のうちどの機能が上記ソフトウェアのバージョンアップに伴い変更されたかを示す第２の情報と、ユーザ端末に組み込まれ、上記ソフトウェアに依存して動作する依存ソフトウェアが上記複数のソフトウェアのどれを使用するかを示す第３の情報と、この依存ソフトウェアが、使用する依存先のソフトウェアのどの機能を使用するかを示す第４の情報とを有し、上記第１から第４の情報を基に、ユーザ端末に配布するソフトウェアの更新可否の決定をするようにする。
【００２０】
以下に、本発明の好適な実施形態を添付図面に基づいて詳細に説明する。尚、以下に述べる実施形態は本発明の好適な具体例であるから、技術的に好ましい種々の限定が付されているが、本発明の範囲は、以下の説明において特に本発明を限定する旨の記載がない限り、これらの実施形態に限られるものではない。
【００２１】
（実施形態１）
まず、本実施形態のプログラム配布サーバとの比較のため、従来のプログラム配布サーバについて、添付図面を用いて以下に説明する。プログラム配布サーバは、管理下にある複数のプログラムの依存関係を管理するための管理情報を有し、その管理情報のデータ構造は、例えば、図１、図２に示すようなものである。図１、図２は、プログラム配布サーバが有する管理情報のデータ構造を説明するための管理情報テーブルである。
【００２２】
図１に示す表の１行目及び２行目は、他のソフトウェアと関連がなく、このソフトウェア単体（ＰｌａｔｆｏｒｍＡ又はＰｌａｔｆｏｒｍＢ）ですべての機能の品質が満たされる商品のものであり、第２カラムに示すバージョンがリリース済みであることを示す。図１に示す表の３行目以降は、他の依存ソフトウェアと組み合わせて機能を実現しているソフトウェアを示す。
【００２３】
図１に示すように、例えば、ＳｏｌｕｔｉｏｎＸというソフトウェアは、バージョン１がリリース済み（第２カラム）で、ＰｌａｔｆｏｒｍＡというソフトウェアを必要とし（第３カラム）、組み合わせて動作検証が完了しているバージョンが、バージョン１、バージョン２、バージョン３のいずれか（第４カラム）であることを示す。そして、これ以外のバージョンのＳｏｌｕｔｉｏｎＸとＰｌａｔｆｏｒｍＡとの組み合わせは、動作検証が行なわれおらず、動作保証がされない。
【００２４】
次に、従来のプログラム配布サーバの動作について以下に説明する。従来のプログラム配布サーバは、ＰｌａｔｆｏｒｍＡのバージョン３のソフトウェアを単体で使っているシステムから更新有無の問い合わせを受けたとき、図１に示す１行目の情報から、ＰｌａｔｆｏｒｍＡのバージョン３．５のソフトウェアの更新が利用できることを判断し、問い合わせ元に回答する。
【００２５】
また、従来のプログラム配布サーバは、ＳｏｌｕｔｉｏｎＸのバージョン１のソフトウェアと、ＰｌａｔｆｏｒｍＡのバージョン２のソフトウェア使っているシステムから更新の問い合わせを受けた場合には、図１に示す３行目の情報から、ＰｌａｔｆｏｒｍＡのバージョン３のソフトウェアの更新が利用できることを判断し、問い合わせ元に回答する。
【００２６】
なお、図１に示す１行目の情報から、実際にはＰｌａｔｆｏｒｍＡのバージョン３．５のソフトウェアが用意されているが、ＳｏｌｕｔｉｏｎＸのバージョン１のソフトウェアとの組み合わせ評価が完了していないため、これらは無いものとして扱われる。
【００２７】
この状態で、ＰｌａｔｆｏｒｍＡのバージョン４のソフトウェアがリリースされたとき、図１に示す１行目の「バージョン」カラムには、直ちにバージョン４が追加され、ＰｌａｔｆｏｒｍＡを単体で使用するシステムに公開される。また、ＰｌａｔｆｏｒｍＡを利用するＳｏｌｕｔｉｏｎＸのバージョン１のソフトウェアが、ＰｌａｔｆｏｒｍＡのバージョン４のソフトウェアについて問題なく動作ができることが確認されると、図１に示す３行目の「テスト済み依存ソフトウェアバージョン」カラムにバージョン４が追加される。
【００２８】
また、同じくＰｌａｔｆｏｒｍＡを利用するＳｏｌｕｔｉｏｎＺが、ＰｌａｔｆｏｒｍＡのバージョン４のソフトウェアに対して問題が発生し、バージョン３．１の改変が行われた場合、図２に示すように新たに６行目が追加される。依存関係が図２の状態に更新されてから、ＳｏｌｕｔｉｏｎＺのバージョン３のソフトウェアと、ＰｌａｔｆｏｒｍＡのバージョン３のソフトウェアを使うシステムから問い合わせが来ると、ＳｏｌｕｔｉｏｎＺのバージョン３．１のソフトウェアと、ＰｌａｔｆｏｒｍＡのバージョン４のソフトウェアの同時更新が可能であることを回答する。
【００２９】
以上説明したように、従来のプラグラム配布サーバは、管理下のソフトウェア同士の依存関係を管理していた。しかしながら、上述のＳｏｌｕｔｉｏｎＸやＳｏｌｕｔｉｏｎＺの依存関係を更新する処理はテスト結果などを元に手動で更新されていたものであり、管理の手間がかかる。
【００３０】
次に、本実施形態のプログラム配布サーバを含むプログラム配布システムの構成及び各部の機能について図１０を用いて以下に説明する。図１０は、本実施形態のプログラム配布サーバを含むプログラム配布システムの構成及び各部の機能について説明するためのブロック構成図である。
【００３１】
図１０に示すような、本実施形態のプログラム配布サーバを含むプログラム配布システムは、ユーザ端末１、外部ベンダー２、及び、プログラム配布サーバ３、及び、テスト機４を備えている。ユーザ端末１及び外部ベンダー２とプログラム配布サーバ３とは、インターネットを介して接続される。プログラム配布サーバ３とテスト機４とは、ＬＡＮ接続される。
【００３２】
図１に示すように、プログラム配布サーバ３は、データベース５〜７を有し、リリースマネージャ８と、テストケースマネージャ９とを備えている。また、テスト機４は、テストケースビルダー１０を備えている。
【００３３】
データベース５は、ソフトウェアの更新を行なう更新プログラムや更新データを格納する。データベース６は、プログラム配布サーバ３の管理下にあるソフトウェアを管理するための管理データを格納する。データベース７は、ソフトウェアの動作検証をするためのテストプログラムやテストデータを格納する。
【００３４】
リリースマネージャ８は、更新要求元の顧客環境（ユーザ端末１）で稼動するアップデータ・コンポーネント（特許文献１参照。）と連携して動作する。具体的には、リリースマネージャ８は、ユーザ端末１のアップデータ・コンポーネントからの更新要求を受け取り、更新可能な情報があるかをデータベース６が有する管理データ（図１、図２に示したデータ）を使って調べる。
【００３５】
そして、リリースマネージャ８は、更新可能な情報があった場合、その旨をアップデータ・コンポーネントへ回答する。また、リリースマネージャ８は、アップデータ・コンポーネントへ更新データを送る。また、リリースマネージャ８は、外部ベンダー２からリリースされた更新内容の情報を受け取り、この更新内容の情報を、更新データ及び（図３や図４に示したような）管理データとしてそれぞれデータベース５及びデータベース６に格納する。
【００３６】
また、リリースマネージャ８は、図３や図４に示した管理データを使ってテストの要否を判断し、テストが必要な場合には、テストケースマネージャ９にテスト依頼を行なうと共に、外部ベンダー２へ通知を行なう。
【００３７】
テストケースマネージャ９は、リリースマネージャ８からのテスト依頼を図５に示す管理データにキューイングする。また、テストケースマネージャ９は、テスト依頼が溜まったら、図６に示す管理データからテスト機を探し、見つかったテスト機を起動する。
【００３８】
続いて、テストケースビルダー１０へテスト対象プログラムやテストケースデータを送る。また、テストケースマネージャ９は、テストケースビルダー１０からテスト結果を受け取り、この受け取ったテスト結果から通知を行なったり、図２に示した管理データの更新をリリースマネージャ８に依頼する。
【００３９】
テストケースビルダー１０は、テスト機の起動により自動的に実行され、テストケースマネージャ９と通信を確立する。また、テストケースビルダー１０は、テスト対象プログラムとテストケースデータをテストケースマネージャ９からダウンロードし、テストを実行する。更に、テストケースビルダー１０は、テスト結果をテストケースマネージャ９へ伝える。そして、テスト終了毎に、次回のテストに備えてテスト機を初期化する（図７、図１０参照。）。
【００４０】
次に、本実施形態のプログラム配布サーバを含むプログラム配布システムの動作について添付図面を用いて具体的に以下に説明する。本システム上で稼動するリリースマネージャ８は、依存先のＰｌａｔｆｏｒｍＡの機能を適当な粒度で分割し、ＰｌａｔｆｏｒｍＡを更新するときにどの機能に影響がある変更が行われたかを管理する。ここでいう機能とは、「文書を印刷する」というような形で表現される場合や、ＳＤＫが提供する「１つ１つの関数」の場合もある。
【００４１】
図３は、ＰｌａｔｆｏｒｍＡについての情報を抜き出したものだが、例えば、バージョン４のソフトウェアのリリースは、図３に示す機能１、８、１７番に変更が入っていることを示す。図３に示す情報を従来のように手動で提供すると手間は増える一方であるため、本実施形態では管理情報としてプログラム配布サーバ３のデータベース６に保有する。図３に示す情報は、一般的には、プログラム配布サーバ３により、管理対象であるソフトウェアを構成する各ファイルが属する機能分類と、そのファイルに対する更新が発生したかどうかを基に自動的に生成され、管理データとして管理される。
【００４２】
プログラム配布サーバ３は、図３に示す情報と似た、図４に示す情報も管理データとして管理する。図４に示す情報は、依存する側のソフトウェアが、依存される側のソフトウェアのどの機能を使っているかを示すもので、依存する側のソフトウェア開発者から提供される情報である。
【００４３】
ＰｌａｔｆｏｒｍＡのバージョン４のソフトウェアの更新がリリースされ、図３に示す表の４行目の情報が確定したとき、リリースマネージャ８は、図４に示された情報から、ＰｌａｔｆｏｒｍＡの更新が、ＳｏｌｕｔｉｏｎＸやＳｏｌｕｔｉｏｎＺに影響があるか否かを自動的に判断する。この例では、図４からわかるように、ＳｏｌｕｔｉｏｎＸが使っている機能に変更はなく、一方、機能８の更新がＳｏｌｕｔｉｏｎＺに影響する可能性が示される。
【００４４】
すなわち、リリースマネージャ８により、ＳｏｌｕｔｉｏｎＸがＰｌａｔｆｏｒｍＡのバージョン４のソフトウェアの更新に対して安全であることは瞬時に自動判断され、リリースマネージャ８は、ＳｏｌｕｔｉｏｎＸに関する図２に示した情報を更新し、瞬時反映してリリースを実行する。一方、リリースマネージャ８により、ＳｏｌｕｔｉｏｎＺはすぐにリリースできず、機能８に対する組み合わせ評価が必要と判断される。
【００４５】
次に、上述したように評価の必要性が確定した、ＳｏｌｕｔｉｏｎＺの評価について説明する。リリースマネージャ８は、テストケースマネージャ９へ通知し、テスト依頼をリリースマネージャ８にキューイングしてもらう。本システムは、この時点で例えばＳｏｌｕｔｉｏｎＺの管理者や開発者に対して、リリースマネージャ８がメールなどで依存関係に問題があることを通知する仕組みとする。
【００４６】
更に、本システムでは、商品プログラムであるＳｏｌｕｔｉｏｎＺと共に商品プログラム提供者から提供されるテストケースを起動し、テスト結果を得ることができる。テストケースとは、テストを実施するテスト用プログラムやテストデータである。
【００４７】
ＳｏｌｕｔｉｏｎＺがテストに合格した場合には、影響無しと判断し、その結果は図２に示す管理情報テーブルに即座に反映される。ＳｏｌｕｔｉｏｎＺがテストに失敗した場合には、上記と同じように、ＳｏｌｕｔｉｏｎＺの管理者や開発者へ、テスト結果とともにメールなどで通知し、ＳｏｌｕｔｉｏｎＺの更新を促す。
【００４８】
上記テストケースは、以下に説明するように実現され、実施される。テストケースマネージャ９は、プログラム配布サーバ３上で稼動し、リリースマネージャ８からのテスト依頼を管理する。テストケースマネージャ９は、テスト依頼を受けると、図５に示すような形でテスト依頼をキューイングする。ステータスには、待機／テスト実施中／テスト完了などがある。
【００４９】
テストケースマネージャ９は、依頼が１つ以上溜まると、図６に示すテスト機４を管理するための管理情報テーブルから、空いている機器を探し、テスト依頼に割り当てる。割り当て可能なテスト機４が見つかると、テストケースマネージャ９は、テストを実施するコンピュータあるいはコンピュータをソフトウェアでエミュレートする実行環境（ＶｉｒｔｕａｌＰＣやＶＭＷａｒｅという製品が有名）を起動する。例えば、コンピュータは、ネットワークボードから電源を入れることができる。
【００５０】
この実行環境は、オペレーティングシステムが起動されると自動的にログインし、テストケースビルダー１０を起動するようにセットアップされている（以下図７参照。）。テストケースビルダー１０が起動すると、テストケースマネージャ９とネットワークなどを通して通信し、テストに必要なソフトウェアをダウンロードしてインストールする。
【００５１】
また、評価対象ソフトウェアのテストケースも同様にダウンロードし、テストケースを起動する。テストケースが終了すると、テスト結果はテストケースビルダー１０を通してテストケースマネージャ９へ伝えられる。テストケースマネージャ９は、その合否結果により、上記のメール通知や図２に示した情報の更新を（リリースマネージャ８に依頼して）行う。
【００５２】
テストケースビルダー１０は、テストが終わるとＯＳの起動パラメータを変更し（例えば異なるパーティション上のＯＳが起動されるように変更し）、再起動を行う。この結果、再起動された実行環境は、先ほど使ったテスト環境を元の初期状態に戻し、次のテスト依頼に備えるようにコンピュータ自身を自己初期化し、シャットダウンする。
【００５３】
なお、エミュレータを使う環境では、単にその環境を捨てて、テンプレート環境をファイルコピーするだけで実現できる。以上の処理を、キューイングされたテスト依頼が無くなるまで、テストケースマネージャ９が繰り返し実行する。
【００５４】
次に、テストケースマネージャ９は、テストケースの実行で消費した課金情報を保存する。例えば、テストにかかった時間や、実行したテストケースの数などの情報である。図８は、プログラム配布サーバ３で管理されるソフトウェアの設定情報を示した図である。これらの情報はテストを実施するかどうかの判断に使われる。
【００５５】
また、図９は、テスト実施結果の管理情報を示した図である。これらの情報は、プログラム配布サーバ３により、テスト対象ソフトウェアごとに集計され、図８に示した情報を基にテスト結果の通知と費用の請求が発行される。
【図面の簡単な説明】
【００５６】
【図１】本実施形態及び従来のプログラム配布サーバが有する管理情報が格納された管理情報テーブルを示した図である。
【図２】本実施形態及び従来のプログラム配布サーバが有する管理情報が格納された管理情報テーブルを示した図である。
【図３】本実施形態のプログラム配布サーバが有する管理情報が格納された管理情報テーブルを示した図である。
【図４】本実施形態のプログラム配布サーバが有する管理情報が格納された管理情報テーブルを示した図である。
【図５】本実施形態のテスト依頼に関する管理情報が格納された管理情報テーブルを示した図である。
【図６】本実施形態のテスト機を管理するための管理情報が格納されている管理情報テーブルを示した図である。
【図７】本実施形態における、ソフトウェアの動作検証テストについて説明するための図である。
【図８】本実施形態のソフトウェアの設定情報を格納した管理情報テーブルを示した図である。
【図９】本実施形態のテスト実施結果に関する管理情報を格納した管理情報テーブルを示した図である。
【図１０】本実施形態のプログラム配布サーバを含むプログラム配布システムの構成ブロック図である。
【符号の説明】
【００５７】
１    ユーザ端末
２    外部ベンダー
３    プログラム配布サーバ
４    テスト機
５、６、７    データベース
８    リリースマネージャ
９    テストケースマネージャ
１０    テストケースビルダー
【図１】
0004732864.tif 000002
【図２】
0004732864.tif 000003
【図３】
0004732864.tif 000004
【図４】
0004732864.tif 000005
【図５】
0004732864.tif 000006
【図６】
0004732864.tif 000007
【図７】
0004732864.tif 000008
【図８】
0004732864.tif 000009
【図９】
0004732864.tif 000010
【図１０】
0004732864.tif 000011