JP2016024697A - リソース管理システム及びリソース管理方法 - Google Patents

Abstract

【課題】複数のソフトウェア開発のテスト実行に利用される共有システムのリソースの過度な割り当てを防ぐ管理システム及びリソース管理方法を提供する。
【解決手段】ソフトウェア開発で実行するテストの種類と実行条件とに基づいて、テストの実行に必要なリソースと、リソースを占有又は共有で利用するかを示す利用条件を決定する。指定されたテストの実行期間において、決定した利用条件でリソースの割り当てが可能かを判定し、割り当てが可能と判断した場合は、リソースの割り当てを予約する。
【選択図】図１

Description

本発明は、物理サーバ上に仮想サーバを設けたクラウドコンピューティングシステムのリソース管理に関する。

従来ソフトウェアなどの開発は、プロジェクト毎に専用の環境を用意し、開発が完了するまで使い続けるという利用が一般的だった。しかし、社内に複数のプロジェクトを抱える組織では、プロジェクトの数だけサーバやストレージが必要になり、開発コストの面で課題となっていた。

しかし、近年、仮想化技術を用いてサーバやストレージ、ネットワーク等のITリソースを分割して利用可能にするクラウド型のシステムの登場により、組織は複数のプロジェクトでITリソースをシェアして利用することが容易になった。このような環境下では、各プロジェクトに割り当てるリソースを最適化し、システム全体として効率よくリソースを使用する必要がある。

こうしたプロジェクトに割り当てるリソースの最適化問題の解決に向け、特開2013-117959のように、プロジェクトの各タスクの所要時間と変動やタスク間の関係から見込みの所要時間を算出する技術や、特開2012-146133のように、工程の進捗状況から、残作業量を計算するなど技術などが開示されている。

特開2013-117959 特開2012-146133

特許文献１および特許文献２は、いずれも工程の進捗状況に合わせて将来の作業量を予測するものである。ただし、予測した作業量に応じて、必要なリソースをどのように割り当てるかについては開示されていない。特に、ソフトウェア開発のテストにおいては、テストの種類に応じて必要とされるリソースの性能が異なるため、全てのテストにリソースを一律に割り当てると、一部のテストについてはリソースを過度に割り当ててしまう可能性がある。

上記課題を解決するため、本発明における複数のソフトウェア開発のテスト実行に利用される共有システムのリソースを管理するリソース管理システムは、テストの種類に応じて、共有システムのリソースの割り当て方法を変更する。

具体的には、本発明におけるリソース管理システムは、共有システムを構成する複数の物理サーバと複数の仮想サーバとを含むリソースの予約状況を示すリソース管理情報を記録する記録部と、ソフトウェア開発で実行するテストの識別子と種類と達成条件と実行期間とを含むリソース予約要求を受信する受信部と、テストの達成条件と種類とに基づいて、テストの実行に必要なリソースと、リソースを占有又は共有で利用するかを示す利用条件を決定し、リソース管理情報に基づき、前記実行期間において決定した前記利用条件で前記リソースの割り当てが可能かを判定し、前記割り当てが可能と判断した場合は、前記リソースの割り当てを予約することにより前記予約情報を更新する計画調整部を備える。

また、本発明におけるリソース管理方法では、共有システムを構成する複数の物理サーバと複数の仮想サーバとを含むリソースの予約状況を示すリソース管理情報を記録し、ソフトウェア開発で実行するテストの識別子と種類と達成条件と実行期間とを含むリソース予約要求を受信し、テストの達成条件と種類とに基づいて、テストの実行に必要なリソースと、リソースを占有又は共有で利用するかを示す利用条件を決定し、リソース管理情報に基づき、前記実行期間において決定した前記利用条件で前記リソースの割り当てが可能かを判定し、前記割り当てが可能と判断した場合は、前記リソースの割り当てを予約することにより前記予約情報を更新する。

複数のプロジェクトでITリソースを共有する環境において、ITリソースの効率的な割当てが可能となる。

本発明の一実施例によるリソース計画装置を用いたシステムの構成図である。 本発明の一実施例によるリソース計画装置を用いない場合のリソースの使用状況を表す図である。 本発明の一実施例によるリソース計画装置を用いる場合のリソースの使用状況を表す図である。 本発明の一実施例によるリソース計画装置内の機能と、プロジェクト管理ツールと、バージョン管理ツールと、利用者管理DB１０５と、構成管理DBで管理するデータを表す構成図である。 本発明の一実施例によるスケジュール登録時の振る舞いを表すフローチャートである。 本発明の一実施例による開発時の振る舞いを表すフローチャートである。 本発明の一実施例による開発完了後のテスト実行時の振る舞いを表すフローチャートである。 本発明の一実施例によるテスト完了後の本番実行時の振る舞いを表すフローチャートである。 本発明の一実施例による構成管理DBで管理する、現時点のシステム構成を表す図である。 本発明の一実施例による構成管理DBで管理する、リソースの利用計画を表す図である。 本発明の一実施例によるプロジェクト管理ツールのスケジュールを示す図である。 本発明の一実施例による物理サーバと仮想サーバの対応を示す図である。 本発明の一実施例によるスケジュール登録時の振る舞いを示す図である。

図１は本発明を適用したクラウド基盤１７０上のITリソースを複数のチームでシェアして利用する構成を表す第１の実施例である。

本構成において、ユーザ１１０は、プロジェクト管理ツール１２０を用いて、作業スケジュールの管理を行い、バージョン管理ツール１３０を用いてドキュメントやソースコードの管理を行っている。ここでプロジェクト管理ツール１２０は、プロジェクトの開発目標に対して、チームのメンバのタスクとスケジュール、成果物などを管理するツールである。プロジェクト管理ツール１２０を用いることで、プロジェクトの目標に対して、やるべき事(タスク)が網羅されているか、プロジェクトを推進するチームのメンバに無理なくタスクが割り当てられているか、タスクを実現する期間は妥当か、タスクがスケジュール通り実現されているかなどが管理でき、ガンチャートで現状を表示することで、進捗に問題が生じている場合などにいち早い対応が可能になる。また、近年のプロジェクト管理ツールでは、継続的インテグレーションの実施も対象になっており、TODOリストと、開発フェーズ毎の計画も併せて管理できるようになっていてもよい。さらに、プロジェクト管理ツールは、複数のプロジェクトの管理が行えても良く、複数のプロジェクトを管理する上位の管理者により、それぞれのプロジェクトの進捗を一元的に管理できる構成で会っても良い。プロジェクト管理ツール１２０は、このような目的に用いるツールであるため、同様の目的に利用可能なツールであれば、その実装の違いは本発明の効果を損なうものではない。プロジェクト管理ツールは、専用の装置であってもよいし、物理装置または仮想化された装置の上で動作するソフトウェアであってもよく、ユーザ１１０の手元にあるPCなどの機器で実現されていても、ユーザ１１０がネットワークを介してアクセス可能なサーバ上にあっても良い。これは後述のツール、装置、DBなどにおいても同様である。

またバージョン管理ツール１３０は、チームでドキュメントやプログラムを同時に利用したり更新する必要がある業務において、開発物のデグレードなどを起こすことなく、効率的にドキュメントやプログラムをシェアして開発を進められるようにするためのツールである。バージョン管理ツール１３０は、登録されたデータの更新履歴を、作業者と結びつけて管理しており、いつ、誰が何を更新したかを管理できる。利用者は、データを利用する際にそれが最新版であるかを確認でき、またデータを更新する際に、作業中に別の更新があったかどうかの確認や、作業前にファイルをロックすることで他の更新が行えないように制御することが可能である。こうしたプロジェクトにおける情報の管理は、プロジェクト管理において不可欠であることから、プロジェクト管理ツール１２０の一部としてバージョン管理ツール１３０の機能を持つものもある。本実施例では、プロジェクト管理ツール１２０とバージョン管理ツール１３０を別のツールとして説明しているが、両者が1つのツールとして実装されていてもよい。また、ドキュメントやソースコードのシェアと管理が可能なツールであれば、表計算ソフトウェアと(バックアップ機能を備えた)ネットワークストレージの組合わせであってもよい。

プロジェクト管理ツール１２０およびバージョン管理ツール１３０は、リソース計画装置１００に接続される。リソース計画装置１００は、その内部または外部に利用者管理DB（データベース）１０５を有するか、接続されていてもよい。リソース計画装置１００は、従来連携がとれていなかった、プロジェクト管理ツール１２０およびバージョン管理ツール１３０と、デプロイツール１４０およびテストツール１５０および構成管理DB１６０を連携させるための装置である。また、デプロイツール１４０およびテストツール１５０および構成管理DB１６０は、クラウド基盤１７０に接続される。

ここで、各装置およびツールおよびDB間の接続は、主にネットワークを介して行われるが、その通信方式および手段は、各装置およびツールおよびDB間で予め決められた方式により過不足なく情報伝達が行えれるものであれば良く、複数の方式に変化して送受信されていても良い。例えば、物理的な結線としてメタルケーブルを用い、通信伝送規格としてイーサネットを用いてもよく、その上でTCP/IPによるデータ通信を行うことで実現してもよく、このうち、通信伝送規格として、ADSLなどが用いられてもよく、有線ケーブルの代わりに無線が用いられてもよい。

リソース計画装置１００は、プロジェクト管理ツール１２０とバージョン管理ツール１３０により管理されるプロジェクトのスケ-ジュールと進捗状態に応じて、デプロイツールおよびテストツールおよび構成管理DBで管理するクラウド基盤の利用状態や利用計画、実際にプログラムの動作を行った結果などに基づき、計画されたITリソースの割当てが実現可能かを判断し、必要ならばスケジュールやリソース割当て量や期間を変更する機能を有する。リソース計画装置１００の詳細は後述する。

デプロイツール１４０は、クラウド基盤１７０に対し、仮想サーバの作成や起動、停止、削除などの指示を行うツールである。デプロイツール１４０は、仮想サーバに割り当てるCPU数やメモリ量、ディスクサイズやディスク数、ネットワーク回線数などを指定または変更する機能をもつ。また、CPU数を割り当てる際に、他の仮想サーバとCPUをシェアするかどうかを指定する機能を持つ。またクラウド基盤１７０で複数のネットワーク接続、サーバ、ストレージを有している場合、デプロイツール１４０は、仮想サーバが利用するネットワーク接続やサーバ、ストレージを直接指定したり、他のネットワーク接続やサーバ、ストレージへの切り替えを指示できてもよい。デプロイツール１４０は、クラウド基盤１７０を実現するソフトウェアやハードウェアの一部であってもよいし、クラウド基盤１７０を実現するソフトウェアやハードウェアが提供するインターフェースやサービスの一部を利用して制御するものであってもよい。リソース計画装置１００は、デプロイツール１４０が有するリソースの割当て、調整機能に応じて、リソースの割当て方法を変更してもよい。例えば、仮想サーバに割り当てるCPU数を少なくしたい場合で、デプロイツール１４０がCPU数の変更ができない場合、リソース計画装置１００は、CPU数の少ない仮想サーバを新規に追加し、必要な情報を引き継いだ後、元のCPU数が多い仮想サーバを削除することで、CPU数を少なくすると言う操作を置き換えてもよい。

テストツール１５０は、開発のテストフェーズにおいて、テストデータの送信やテストトラフィックの送信などにより、プログラムやサーバ、システムのテストを行うツールである。ユーザ１１０はテストデータとテストパターン、期待のテスト結果を予めテストツール１５０に登録しておくことで、テスト１５０はテストパターンを準じ実行し、その結果を期待のテスト結果と照合を行い、ユーザ１１０にテスト結果を通知する。本実施例では、ユーザからのテストデータの登録はバージョン管理ツール１３０から行い、プロジェクト管理ツール１２０から計画に合わせたテストの実行を行い、テスト結果のテスト消化率はプロジェクト管理ツール１２０が閲覧できるような実装を想定しているが、ユーザ１１０がテストデータをテストツールに入力し、その結果をユーザ１１０が直接閲覧できる実装であっても良い。このとき、テストツール１５０に入力されたデータと、テストツール１５０でもテスト結果は、リソース計画装置から参照できること。

構成管理DB１６０は、クラウド基盤１７０に搭載のネットワーク装置やサーバ、ストレージ、サーバ上の仮想化ソフトウェアまたはハードウェア、OS、OS上で動作するソフトウェアなどが出力するログ情報やイベント情報などを監視し、その結果から各装置がどのように使われているかを管理するDBである。例えば、構成管理DB１６０の情報を利用することで、物理サーバと仮想サーバの関係や、どの物理サーバのリソースに余裕があり、仮想サーバの追加が行えそうかなどがわかる。また本実施例では、構成管理DBの情報として、ユーザ１１０の情報や、プロジェクトに割り当てたリソースとその期間なども含むが、これらが別のDBに分けて実装されている形であってもよい。

クラウド基盤１７０は、ネットワーク装置とサーバ、ストレージなどを含み、デプロイツール１４０からのリクエストに応じて、指定の要件にあった仮想サーバや物理サーバなどを提供するシステムである。クラウド基盤１７０は、VMware ESX(VMware社の登録商標である)や、KVM、Hyper-V(Hyper-VはMicrosoft社の登録商標である)などの仮想化ソフトウェアで管理されるケースが多いが、物理サーバにネットワークブートでOSをインストールして提供ことで、物理サーバ自身を提供する仕組みであってもよい。ユーザ１１０は、デプロイツール１４０を用いてクラウド基盤１７０から提供された仮想サーバを操作することができる。ここで、クラウド基盤１７０は、デプロイツール１４０がAPIなどを利用してリクエストした仮想サーバなどを提供できる仕組みがあれば良く、構成する仮想化ソフトウェアの種類や、ネットワーク装置、サーバ、ストレージの接続方法は問わない。

図１を用いることでユーザ１１０はプロジェクト管理ツール１２０と バージョン管理ツール１３０を利用したソフトウェア開発などにおいて、複数のチームがクラウド基盤１７０をシェアして利用する場合でも、不足なく仮想サーバを入手することが可能になる。

図２は、本実施例における従来のクラウド基盤１７０の管理における課題を示したものである。図２では、サーバ3台(２１０、２１２、２１４)から構成されるクラウド基盤１７０を、3つのプロジェクト（２４０、２４２、２４４）が順に利用する場合を示している。ここでは各プロジェクトは決められた期間、Webサーバ、APサーバ、DBサーバからなるシステムを構築するため、3台のサーバを占有して利用するケースを想定している。従来、システムのテストにおいては、性能テストや障害テストを考慮した場合、安定した性能の確保や、テスト障害発生時の他のシステムへの影響を考慮し、他のシステムとリソースを場所的にシェアすることは困難だった。したがって、期間を指定することで順に利用する時間的なシェアを行う場合が考えられる。ただし、このケースにおいても、新規のテスト項目の発生により、サーバを追加する必要が生じても、サーバを追加することは難しかった(２２２)。また、プロジェクト１において工程が遅延しても、すぐ後ろではプロジェクト２の利用が控えているため、リソースの割当て見直しをすることが難しかった（２２４）。逆に、期日前に開発が完了しても、前のプロジェクトの利用が終わっていないため、直ちにテストはじめることができなかった（２２６）。

こうした問題は、クラウド基盤側では、いつ、誰がITリソースを利用するかの管理は行えても、利用状況の管理までは行うことができなかったために発生していたと考えられる。

そこで本発明では、プロジェクト管理ツール１２０が管理する、プロジェクトの開発物やスケ-ジュールの特性や、プロジェクトの進捗や要求の変化、実績の変化に関する情報を入力とすることで、クラウド基盤が割り当てるリソース量やスケジュールの最適化を行う。

図３は、本発明のリソース計画装置により実現される効果を示している。図3では、サーバ3台（３１０、３１２、３１４）から構成されるクラウド基盤１７０を、３つのプロジェクト（３４０、３４２、３４４）が順に利用する場合を示している。ここでも図２と同様に、各プロジェクトは決められた期間、Webサーバ、APサーバ、DBサーバからなるシステムを構築するため、3台のサーバを利用するケースを想定している。ただし、本発明では、テストを機能テスト、性能テスト、障害テストの３つに分けた。

機能テストは、テスト工程の初期に開発したプログラムが仕様の機能要件を満たすかどうかを、プログラム単体で確認するテストである。この特徴より、機能テストで用いるサーバは、本番で想定する構成が実現されていればよいため、相対的に少ないスペックでよく、また一定の性能を要求しない。このため、機能テストに割り当てる仮想サーバは、リソース共有３６０の状態で動作させる。

次に性能テストは、テスト工程の中期で、機能要件を満たすプログラムが実機上で期待の性能を出せるかどうかを評価するテストである。このとき性能テストで用いるサーバは、本番で割り当てられる物理サーバまたは仮想サーバとの性能比が予め評価されていれば、必ずしも本番と全く同じ性能のサーバを用意しなくてもよいが、テスト中や再実行時に与えられた性能が変化すると評価の意味を失うため、安定した性能が要求される。このため、性能テストに割り当てる仮想サーバは、仮想サーバ占有３６２の状態で動作させる。

最後に障害テストは、テストの後期で、ネットワーク障害やディスク障害など、特に物理的な異常が発生した際の動作を確認するテストである。この特徴より、障害テストで用いるサーバは、一台の物理サーバを他のプロジェクトとシェアして利用することが難しい。このため、障害テストでは、物理サーバの単位で割り当てる。このとき、物理サーバには仮想化ソフトウェアが入っていてもよく、他の仮想サーバが混在していなければ、物理サーバの一部だけを使う形であっても良い。ただし、実機でも同じ物理サーバ上で動作することが想定される仮想サーバであれば、その組合わせに限り同じ物理サーバ上で動作してもよい。

このように、システム開発におけるテストは、テストの内容により利用するリソースが異なるため、プロジェクト管理ツール１２０が管理するスケジュールの情報があれば、スケジュールに合わせリソースを効率的に割り当てることができる。

図３のプロジェクト１では、最初に機能テストが実施されるが、これはリソース共有で動かせばよいテストであるため、全てサーバ３の上で動作させることができる(３２０)。また、各テストは、開始時期や終了時期が異なっているため、必要ならば、その空きリソースを他で利用することができる。これにより、この場合では、プロジェクト１に割り当てた期間であっても、最大サーバ２台の空きが生み出せる。

また、性能テストにおいて、サーバ３とサーバ２の２台を使う計画であったが、急遽２台のサーバを必要になった場合でも、サーバ１が空いているため、追加の仮想サーバを用意することができる。

また、障害テストであっても、障害の発生箇所にあたらないサーバであるなら、物理サーバを割り当てず、仮想サーバを割り当てることでリソースの割当てを節約してもよい。

このように、リソースを割り当てることで、機能テストで割り当てるリソースは相対的に小さく、性能テスト、障害テストの順で必要なリソースは順に相対的に大きくなるが、障害テストでも全てのリソースを使い切らないように制御することで、前のプロジェクトの障害テストと、後のプロジェクトの機能テストを同時実施することが可能になるため、プロジェクトの遅延によるリソース競合のリスクを低減させることが可能になる。

説明箇所３２６では、サーバ１とサーバ２は遅延したプロジェクト１で占有してサーバを使っているが、サーバ３は、プロジェクト１とプロジェクト２のテストが混在した状態になる。また機能テストのうちで、単体でテスト可能な項目については、プロジェクト２の計画が著しく遅延しない範囲において、スケジュールを変更することで、より優先的にプロジェクト１にリソースを割り当てることも可能である。

逆に説明箇所３２８では、プロジェクト２のテスト予定期間中で、プロジェクト３のテスト期間が始まっていないが、サーバ１のリソースがあまっているため、既にプロジェクト３の開発が終わっていた場合、前倒しでリソースを割り当てることで遅延のリスクを減じている。

また説明箇所３３０のように、プロジェクト２の遅延の影響で、プロジェクト３の機能テストに割り当てるリソースが減少した場合、プロジェクト２のテスト終了後、機能テストであってもリソース割当ての優先度を上げ、迅速にテストを完了させるよう調整してもよい。

同様に、性能テストであっても、評価済の本番環境との性能比のデータがあれば、通常よりも多くのリソースを割り当てることでテスト完了までの時間を減じるように調整してもよい（３３２）。

このように、プロジェクト管理ツール１２０が管理する、テスト項目とスケージュールと進捗状況を用いることで、リソースの割当て効率が向上すると共に、プロジェクト遅延のリスクを減じることができる。説明では３台の構成であるが、通常のクラウド基盤では、数十台や数百台のサーバから構成されるものも珍しくなく、その場合、リソース割当ての自由度が上がり、より多くのプロジェクトで同時にクラウド基盤を使うことも可能になる。

図４は、本実施例における、リソース計画装置１００が有する機能ブロックを示している。リソース計画装置１００は、テスト環境に必要なサーバ台数の計算（４１０）、テスト環境への割当て計画の導出（４１２）、テスト環境の計画調整要否の判定（４１４）、構成管理DB１６０へのリソース計画の更新（４１８）、本番環境に必要なサーバ台数の計算（４２０）、本番環境への割当て計画の導出（４２２）、本番環境の計画調整要否の判定（４２４）、プロジェクト管理ツール１２０へのリソース計画の通知（４２８）、ルール４００から構成される。リソース計画装置１００は、PCのようなCPUやメモリ、ディスクとネットワークインターフェースと、それらを接続する内部バスから構成されていてもよいし、ハードウェアによる専用装置であってもよく、機能要件を満たすものであれば、構成の違いは本発明の効果に影響しない。各機能ブロックは、PCやサーバのようなアーキテクチャであれば、ソフトウェアとして実装されていてもよい。

プロジェクト管理ツール１２０は、内部情報として、TO DOリスト４５０、スケジュール４５２、成果物リスト４６４を有する。また、スケジュール４５２は、図１１に示すように、さらに項目ごとに期間４５４、作業者４５６、工種種別４５８、成果種別４６０、内容種別４６２、達成基準４６４を有する。これらはプロジェクト毎に管理される。

ここでTO DOリスト４５０は、プロジェクトで実施する項目のうち、まだ具体的な計画が定まっていないタスクが含まれる。TO DOリスト４５０は項目ごとに実施の優先度（すぐやる、次のフェーズでやる、次々のフェーズでやる、実施するが優先度低、実施するか未定、実施しない、など）を定めておき、要件の追加・変更に合わせて更新される。現在実行中のフェーズが完了すると、次のフェーズのタスクがスケジュール化され、TO DOリスト４５０内の他のタスクの優先度も合わせて変化する。

スケジュール４５２は現在実行中のフェーズのスケジュールと、計画済みのスケジュールが格納される。スケジュールに記載のタスク４５３毎に、期間４５４、作業者４５６、工程種別４５８、成果種別４６０、内容種別４６２、達成基準４６４、進捗４６６を有していてもよい。完了後の開発物は、成果物リスト４６８で管理する。

ここで、スケジュール４５２は、プロジェクトの全体または区切られたリリース毎の作業計画である。従来のウォーターフォール型の開発では、要件の全てを一度に開発するため、開発項目に応じた開発期間が必要であり、開発完了と同時にプロジェクトも完了するが、アジャイル型の開発では、開発からリリースまでのタイミングを定め、各リリース毎に実現する要件を定め優先度の高いモノから順にリリースしていく方式である。ウォーターフォール型の開発では開発期間が長いため、企画時と作業完了時で市場や顧客の要求が変化しているおそれがある。アジャイル型の開発は、市場や顧客のニーズが変化しないうちにサービスインが行えると共に、市場や顧客からのフィードバックを得ることでサービスや製品の品質を向上できるというメリットがある。このため、プロジェクトの明示的な終わりはなく、継続的な改善が続けられていくことになる。スケジュール４５２における、個々の計画はタスク４５３という形で、期間４５４、作業者４５６、達成基準４６４などが決められ実施されることになる。

タスク４５３は、ドキュメント開発やプログラム開発など、細分化されたスケジュールの構成要素であり、作業開始予定日時と終了予定日時は、期間４５４として管理される。作業者４５６はタスクに記載の作業を行う実行者である。達成基準４６４は、タスク４５３の完了を判断するための成果物と、その基準である。

また、工程種別４５８は、そのタスクが属する工程の違いを示すパラメータであり、この違いによりどの環境を利用するかが決定される。例えば設計の工程は主にデスクワークであるため、自席のPCがあれば良いが、テストではテスト環境が必要になるなど、利用する環境を選択する際のパラメータとなる。リソース計画装置も工程種別４５８を環境選択のパラメータに利用する。

成果種別４６０は、そのタスクで成果となる開発物の種別を示す。これには、ドキュメント開発、プログラム開発、構築作業、テストなどが該当する。本実施例ではこのうち主にプログラム、テストを用いるがドキュメントのページ数や、それらに記載の文言(MUSTやSHOULDなど)の登場回数により仕様の複雑さを推定することで、開発工数の妥当性を評価するなど、リソース計画に用いてもよい。

内容種別４６２は、成果種別４６０の詳細であり、例えばドキュメントなら調査報告書、要件定義書、機能仕様書、基本設計書、詳細設計書、パラメータシートなど、より詳細な分類を示す。ここでは主にテストの種別として、機能テスト、性能テスト、障害テストの種別により説明を行うが、実際には、前記３つの項目に対して単体、結合、全体の区分があり、この組合わせで表現する。単体は単一プログラムの動作の確認であり、そのプログラムの基本的な動作のテストを行う。結合試験は、開発した複数のプログラム間のメッセージ通信などが想定されるパターンにおいて正しく行われるかを主に確認する。全体テストは、特定のシナリオにおいて正しく動作することを確認すると共に、動作すべきでない部分が動作しないことも併せて確かめるテストである。

達成基準４６４は、タスク４５３が完遂したことを計るための基準である。一秒間辺りの処理数や、同時接続数、負荷増大時のスールアウト所要時間などが該当する。進捗４６６は、タスクが４６４の達成完遂をどの程度達成したかを示す。期日に対して進捗が滞っている場合、リソース計画装置はリソース使用予定時の調整などを行う。

またバージョン管理ツール１３０は、開発中や開発が完了したプログラム４７０やドキュメント４７８などを管理するツールであり、チームメンバが競合なく成果物をシェアするツールである。例えばプログラム４７０の場合、バージョン管理ツール１３０はプログラム４７０を、バージョン４７２、更新日時４７４、更新者４７６と共に管理する。バージョン管理ツール１３０は、全ての更新操作についてドキュメント本体または差分をこれらバージョン４７２、更新日時４７４、更新者４７６と合わせて管理することで前のバージョンからどういう変更が行われたかを時系列に確認することができる。仮にあるデータを消去してしまっても、指定のバージョンを復元することもできる。

構成管理DB１６０は、監視データ１６０、構成データ４３２、計画データ４３４、開発実績データ４３８、テスト実績データ４４０、本番実績データ４４２を有している。

監視データ４３０は、クラウド基盤１７０内のネットワーク装置、サーバ、ストレージ、仮想化ソフトウェア、ＯＳ、ミドルウェア、アプリケーションなどの稼働情報やログ情報、イベント情報である。構成管理ＤＢ１６０は監視データ４３０を収集するためのソフトウェアやハードウェアを有していてもよいし、外部の監視ツールで収集されたデータを蓄積、利用する方式であっても良い。

構成データ４３２は、監視データ４３０の情報を分析した結果で、ネットワーク装置、サーバ、ストレージの結線関係と、サーバ、仮想化ソフトウェア、ＯＳ、ミドルウェア、アプリケーションの論理的な接続関係のデータである。この情報は、ユーザ１１０から与えられた初期構成を元に、監視データ４３０を元に変更してもよい。

計画データ４３４は、リソース計画装置がプロジェクト管理ツール１００のスケジュール４５２を元に定めたクラウド基盤上のリソースの利用計画で、どのチームのどのタスクにいつまで、どの大きさのリソースが割り当てられるかを管理する。

予測データ４３６は、開発実績データ４３８、テスト実績データ４４０、本番実績データ４４２を元に将来に必要なリソースを予測した結果である。予測データは将来におけるあるべき姿を指し、計画データ４３４と差異がある場合には、その差異がより小さくなるようにリソースの並べ替えを行う場合の指標となるデータである。

開発実績データ４３８は、開発工程における、初期の計画データと最終的な計画データの差分を表す。開発実績データ４３８が小さいほど最初の予測とのずれがなく、より正確に見積もれたことを表す。このデータは、チーム内にいるメンバの違いや、チーム自体の傾向、開発物の傾向、複数のチームからなる組織全体の傾向などから、どれだけ計画とずれやすいかを計る指標にもなる。計画のずれが発生しやすい場合、それだけリソースの余裕がなくなる可能性が高くなるため、クラウド基盤は１７０はより多くのリソースを保有しておく必要が生じる。

同様に、テスト実績データ４４０はテスト工程における計画と実績の差異であり、本番実績データ４４２は本番工程における計画と実績の差異である。利用者管理ＤＢ１０５は、チームやチームメンバのロールや権限を管理するデータである。利用者管理ＤＢは、大きく利用者のデータ４８０と、チームのデータ４９２を持つ。利用者データ４８０は、名前４８２、認証情報４８４、所属４８６、権限４８８、作業実績データ４９０を有する。チームデータ４９２も同様の情報を有する。

名前４８２はユーザ１１０の名前であり、認証情報４８４はパスワードや証明書、ＩＤカードの情報を認証するための情報である。所属４８６は利用者の所属するチームなどの名称であり、権限４８８は、ユーザ１１０に割り当てられるファイルやサイトへのアクセス権や、閲覧・更新などの操作権や、提案、検査、承認などの決済権などを含む権限情報である。作業実績データ４９０は、過去にユーザ１１０が行ってきた一日辺りの開発コード量やバグの作り込み率などを示す情報である。

図５にリソース計画装置を用いた際の計画登録フローを示す。ユーザ１１０は、プロジェクト管理ツール１２０を用いてスケジュール４５２の登録を行う（５００）。リソース計画装置１００は、プロジェクト管理ツール１２０にスケジュールが登録されると、テスト工程、本番運用で必要となるサーバ台数を見積もるために、スケジュール４５２を読み出す（５０４）。このときのプロジェクト管理ツール１２０からリソース計画装置１００へのデータの受け渡し方法は、リソース計画装置１００が有するスケジュール登録用のＡＰＩを用いてもよいし、プロジェクト管理ツール１２０のＡＰＩスケジュール読み出し用のＡＰＩを用いてもよいし、スケジュールがファイルの形式で保存されているならば、そのファイルを読み出してもよいし、ＤＢに格納されているならば、ＤＢから読み出す形式であっても良い。このときのデータ通信方法の差異は本発明の効果を減じるものではないため、任意の方式でよい。特に断りがない限り、以下の説明においても同様である。

リソース計画装置１００は、スケジュール４５２を受け取ると、テスト環境に必要なサーバ台数の計算を行う（５０８）。この際の計算式は、ルール４００としてリソース計画装置１００が有しており、例えばWeb/APサーバ、DBサーバからなる構成のシステムにおいて、一分間に処理可能なセッション数に応じたサーバ台数が決められている場合、達成基準４６４に基づきテストに必要なサーバ台数が求められる。

例えば、１０００セッション/分あたり、２CPU、メモリ４ＧＢのサーバが１台必要な場合、１万セッション/分のセッションを処理するためには、１０台のサーバ必要になる。またこのとき、スケジュール４５２の工程種別４５８でテストと記載されているものを対象に、その内容種別４６２がどのタイプのテストであるかを調べ、その期間４５４でリソースを確保する。先の例で2ＣＰＵのサーバが１０台必要とされていても、機能テストのフェーズでは0.5ＣＰＵのサーバを最初は1台で2週間のテストを行い、性能テストでは0.5CPUのサーバを10台用意して2週間のテストを行い、最後の可用性テストでは、２ＣＰＵの物理サーバを10台用意して2週間のテストを行うというリソース計画を立てる。この制御を行わない場合、上記の例では、のべ１２０ＣＰＵ・週のリソースが必要となるが、それを５１ＣＰＵ・週のリソースに減じることができる。この処理は図４における処理４１０に該当する。 次にリソース計画装置は、構成管理ＤＢ１６０より、構成情報や計画の読み出しを行い（５１２）、手続き５０８で計算したリソースが実際に割当て可能かを評価する（５１６）。この処理は図４における手続き４１２に該当する。

リソースの計画方法に実施例について説明する。図９は構成管理DB１６０に格納される、仮想サーバと物理装置の関係を示す。本実施例では、仮想サーバが、ネットワークSW（スイッチ）、物理サーバ、ストレージから構成されているとみなし、それぞれの管理データをネットワークSW９６０、物理サーバ９６６、ストレージ９７２と仮定している。一般的に仮想サーバの構成要素としては、この他にOSやサポート種別、バックアップの有無などがあり、追加でこれらの情報が管理されていてもよい。

仮想サーバは、物理的なリソースをシェアして利用するが、本実施例では、物理サーバのリソースを占有可能な単位で細分化し、それぞれ物理ネットワークAtom９４２、物理サーバAtom９４８、物理ストレージAtom９５４として定義する。例えば、4コアで３ＧＨｚの処理能力を持つサーバの場合、これを１コア１ＧＨｚの単位で占有可能であるなら、物理サーバは１２個の物理サーバＡｔｏｍに分割できるとみなし、それぞれの物理サーバＡｔｏｍ毎に割当ての管理を行う。

これに対して、仮想サーバは複数の仮想ＣＰＵを持つが、これを複数の仮想サーバＡｔｏｍ９１２の集合と定義する。例えば、２つの仮想ＣＰＵを持つ仮想サーバは、２つの仮想サーバＡｔｏｍ９１２から構成されるとみなす。これにより、仮想サーバ９００は、それぞれ一つ以上の仮想ネットワークＡｔｏｍ９０６、仮想サーバＡｔｏｍ９１２、仮想ストレージＡｔｏｍ９１８の集合と見なすことができる。ここで、仮想ネットワークＡｔｏｍ９０６と物理ネットワークＡｔｏｍ９４２、仮想サーバＡｔｏｍ９１２と物理サーバＡｔｏｍ９４８、仮想ストレージＡｔｏｍ９１８と物理ストレージＡｔｏｍ９５４の関係性を、それぞれ仮想Ａｔｏｍマッパー（９２４、９３０、９３６）によって定義する。仮想サーバが占有と共有の区別を持って管理される場合、共有時には、複数の仮想サーバＡｔｏｍ９１２が、一つまたは複数の物理サーバＡｔｏｍ９４８をシェアする状況が発生する。これに対し、占有時には、一つの仮想サーバＡｔｏｍは、一つまたは複数の物理サーバＡｔｏｍと関連づけられ、他の仮想サーバＡｔｏｍとは関係を持たないよう設定する必要がある。これは、仮想ネットワークＡｔｏｍ９０６と物理ネットワークＡｔｏｍ９４２、仮想ストレージＡｔｏｍ９１８と物理ストレージＡｔｏｍ９５４の関係においても同様である。このため、仮想Ａｔｏｍマッパー（９２４、９３０、９３６）を用いて両者の関係を記述する。

構成管理ＤＢ１６０は、仮想サーバ９００と実機を図９のように関連づけるが、計画の割当てにおいては、時間単位におけるこれら仮想サーバと物理サーバの関係を定義する必要がある。

図１２は、仮想サーバと物理サーバの関係を模式的に示した図である。ここでは、３ＧＨｚのＣＰＵを４つ持つ物理サーバが４台ある場合の例を示している。物理サーバを搭載ＣＰＵごとに分解し、それを基本性能単位（例えば１ＧＨｚ）で分割したものが物理サーバＡｔｏｍ９４８であるため、ここでは４８個のＡｔｏｍがあることになる。この物理サーバＡｔｏｍ９４８と仮想サーバＡｔｏｍ９００を対応付けるのが仮想Ａｔｏｍマッパー９３０である。

図１０は、時系列に仮想サーバと物理サーバの関係を記述したものである。リソース計画装置１００にてスケジュールが決まる、スケジュールに併せて利用する仮想サーバが決定する。計画仮想サーバ１０１０は、ある時点において利用する仮想サーバのスペックを表している。計画仮想サーバ１０１０は、仮想ネットワーク計画Ａｔｏｍ１０２０、仮想サーバ計画Ａｔｏｍ１０３０、仮想ストレージ計画Ａｔｏｍ１０４０を介して仮想Ａｔｏｍマッパー（９２４、９３０、９３６）と対応づけられる。計画仮想サーバ１０１０は、仮想ネットワーク計画Ａｔｏｍ１０２０、仮想サーバ計画Ａｔｏｍ１０３０、仮想ストレージ計画Ａｔｏｍ１０４０は、時間Ａｔｏｍ１０００が定義する単位時間毎の仮想Ａｔｏｍマッパー（９２４、９３０、９３６）の状態と、各単位時間で個々の計画Ａｔｏｍがどの計画仮想サーバに割り当てられているかを示す。計画仮想サーバ１０１０を利用するユーザは、利用者データ４８０を用いてもよい。したがって、本発明におけるリソース計画の登録作業とは、計画仮想サーバ１０１０の要求性能・期間を満たす計画Ａｔｏｍがを検索して見つけ、登録することである。

手続き５１６においてリソースが割当て可能な場合は、作業計画の仮登録を構成管理ＤＢ１６０に要求し(５２０)、構成管理ＤＢ１６０は手続き５２０を受け付けると、計画の更新を行う（５２４）。ただし、人手による計画の確認が不要である場合には、手続き５２０〜５３６は省略してもよい。ここで、手続き５２０は、図４における手続き４１８に該当する。

適切な計画の立案ができた場合もできなかった場合も、リソース計画装置１００は結果をプロジェクト管理ツール１２０に返す（５２８）。ユーザ１１０はプロジェクト管理ツール１２０上で結果を確認し、ＯＫか否かを返す。このとき、タスク毎にコミットし、リソースが適切に割り当たらなかったタスクを細分化したり計画を見直すなどして、リソース計画装置１００に計画を再計算させてもよい。この場合、スケジュールの更新は、手続き５００と同じ処理になるので、手続き５００以降を再実行する。ここで手続き５２８は、図4における手続き４２８に該当する。

計画を承認すると（５３６）、リソース計画装置１００は、作業計画の登録を構成管理ＤＢ１６０に申請し（５４０）、構成管理ＤＢ１６０はこの申請を受け取ると、仮登録していた計画のステータスを本登録に切り返る（５４４）。ここで手続き５４０は、図4における手続き４１８に該当する。

図１３は、プロジェクトＡがリソースを予約している状況で、新たにプロジェクトＢの機能テストのためのリソースを割り当てる処理の例を図示したものである。リソース計画装置は、機能テストのスケジュールに登録されている情報に基づき、仮想サーバの台数及び仮想サーバが使用するＣＰＵの占有種別を決定し、その条件を示す計画仮想サーバ情報を作成する。例えば、テストの内容種別が機能テストの場合、テスト作業者の人数で仮想サーバの台数を決定し、仮想サーバに割り当てる仮想ＣＰＵは共有で利用できる状態とする。性能テストの場合は、テストの達成基準に基づき必要な仮想サーバの台数を決定し、仮想サーバに割り当てる仮想ＣＰＵは占有で利用できる状態とする。障害テストの場合も、テストの達成基準に基づき必要な仮想サーバの台数を決定するが、各仮想サーバには１台の物理サーバを割り当てるものとする。次に、指定された期間において、決定した条件のリソースの空きがあるかを確認し、空きがあればそのリソースを予約する。

図６はプログラム開発などが始まり、進捗が変化した際の振る舞いを表している。ユーザ１１０が開発したプログラムをバージョン管理ツール１３０に登録すると（６００）、バージョン管理ツール１３０はリポジトリの更新を行う(６０４)。リソース計画装置１００はバージョン管理ツール１３０のリポジトリが更新されると、更新データを読み出す（６０８）。また、これに併せて、プロジェクト管理ツール１２０より、作業計画の読み出しを行う（６１２）。次にリソース計画装置１００は、作業計画と更新されたコード量を評価し、開発が計画通りに推移しているかを評価する(６１６)。開発が進んでいる、または遅れている場合、計画を見直し可能かを評価するため、リソース計画装置１００は構成管理ＤＢ１６０よりリソース計画を読み出す（６２０）。計画が遅れそうであり、リソースに余剰があるなら、利用期間の後ろ倒しを計画する。計画が進んでおり、開発プログラム単体でのテストが可能であり、リソースを事前に確保できるなら、計画の前倒しを計画する（６２４）。ただし、この評価は、同じタスク内においても開発の進捗が常に一定とは限らないことから、1週間程度の平均より傾向を把握するのがよい。そうしない場合、計画が日々変動し、将来の予測が困難になるためである。ここで手続き６１６と手続き６２４は、それぞれ図4における手続き４１０と手続き４１２に該当する。

計画の見直しを提案する場合、リソース計画装置１００は、作業計画の仮登録を構成管理ＤＢ１６０に対して行う（６２８）。構成管理ＤＢ１６０は、仮登録の申請を受け取ると、計画の更新を行う（６３２）。ここで手続き６２８は、図４における手続き４１８に該当する。

リソース計画装置１００は、作成した作業計画の変更案をプロジェクト管理ツール１２０に通知する（６３６）。ユーザ１１０は、新しい作業計画を確認し、更新の要否を判断する（６４０）。更新する場合、プロジェクト管理ツール１２０はリソース計画装置１００に承認を通知し（６４４）、リソース計画装置は承認の指示を受け取ると、構成管理ＤＢに対して作業計画の本登録を申請する（６４８）。構成管理ＤＢ１６０は、申請を受け取ると、計画の更新を行う（６５２）。ここで手続き６３６と手続き６４８は、それぞれ図4における手続き４２８と手続き４１８に該当する。

この処理における計画の見直しは、将来の工程遅延リスクを予測した結果であるため、予測が外れる可能性を考慮した多重予約を許可してもよい。ただし、予測が全て当たった場合のリソース不足による工程遅延が必ず許容される最大の遅延以下になるような計算式をもって多重予約の可否を評価する必要がある。これはクラウド基盤１７０の規模が大きくなるほどリスクを回避しやすくなる。

図７は、開発完了後のテスト時の振る舞いを示している。プロジェクト管理ツール１２０上で開発タスクが完了したことをリソース計画装置１００が検知すると（７００）、リソース計画装置は、バージョン管理ツールに格納されたプログラムとテスト項目を読み出す（７０４）。次に構成管理ＤＢ１６０に対して、利用計画を登録していたリソースを実際に利用する状態に計画変更を要求する(７０８)。構成管理ＤＢ１６０は、要求を受け取ると、計画の更新を行う（７１０）。ここで手続き７０８は、図4における手続き４１８に該当する。

次にリソース計画装置１００は、プロジェクト管理ツール１２０にテスト準備が完了したことを通知する（７１２）。ユーザ１１０はプロジェクト管理ツール１２０からテスト開始を指示すると、その要求はリソース計画装置１００に通知される（７１６）。リソース計画装置１００はテスト開始の要求を受け取ると、テストに必要な仮想サーバのデプロイを、プログラムの送信に併せてデプロイツール１４０に指示する（７２０）。デプロイツール１４０はこの指示に基づきクラウド基盤１７０上に必要な仮想サーバをデプロイする。デプロイが完了すると、その通知はクラウド基盤１７０からデプロイツール１４０を介してリソース計画装置１００に送られる。ここでプログラムには、デプロイする仮想サーバにインストールするソフトウェアや仮想サーバ間の関係に関する情報もパラメータとして含まれているものとする。ここで手続き７２０は、図4における手続き４０２に該当する。

次にリソース計画装置１００はテストを実行する。リソース計画装置１００は、テスト項目の送信に併せてテストツール１５０に指示する（７２８）。テストツール１５０は、テスト項目に合わせたテストを実施し、テストが完了するとその結果をまとめてリソース計画装置１００に送信する。ここでテスト項目には、テスト用のプログラムとテストデータ、テストパターンと、テストパターンに対応した期待値が含まれているものとする。ここで手続き７２０は、図4における手続き４０４に該当する。

リソース計画装置はテスト結果を受け取ると、次に構成管理ＤＢからリソース計画を読み出す（７３６）。テスト結果が全てＯＫでない場合、プログラムは修正され、再度テストが実施されるが、通常テストは複数回実施し、最終的に全ての項目が期待値と一致するまで繰り返す。このときのテストのカバレッジの推移が、想定よりも遅い場合、テスト期間の延長を考える必要が生じる。このため、リソース計画装置をテスト結果をもとにテスト期間・リソース量の見直しの必要性と本番の期間・リソース量の見直しの必要性を判断する（７４０）。例えば、テスト期間については、想定の進捗に対して、２営業日分遅延が発生した段階でリカバリは困難と考え、計画の見直しを行う。また本番への移行時期・リソースについても同様に、テストの結果として、想定の性能が得られない場合、本番で割り当てるリソース量や、本番への移行時期の調整を行う。この際、リソース管理装置は、利用者管理ＤＢ１０５の作業実績データ４９０を用いて、作業者の過去の開発量や開発スピード、完了間際の追い込み量などを元に、追加で必要なリソース量を変更してもよい。

こうした場合、構成管理ＤＢ１６０に対しても、計画の期間の延長を行ったり、テストがリソースを増やすことで迅速化するならば、割り当てる仮想サーバの優先度を上げることで期間内に終わらせるよう計画を変更する（７４４）。この処理も自動で行ってもよいし、ユーザに確認を求めた後に実施してもよい。ここで手続き７４０は、図４における手続き４１４に該当する。また手続き７４４は、図４における手続き４１８に該当する。

リソース計画装置１００は、テスト結果をプロジェクト管理ツール１２０に返す。またリソース計画に何らかの変更がある場合、その情報を返し、必要なら人間による意思決定を仰ぐ（７４８）。

図８はテスト完了後に本番にデプロイする際の振る舞いを示している。テストが完了すると（８００）、リソース計画装置１００はバージョン管理ツール１３０より、プログラムやテスト項目の読み出しを行う(８０４)。このとき、本番へのデプロイと同時にテストを行わない場合は、テスト項目の読み出しを省略してもよい。次に計画していた本番用リソースのステータスを更新中に変更するよう構成管理ＤＢに要求する（８０８）。ここで手続き８０８は、図4における手続き４１８に該当する。

構成管理ＤＢ１６０は、要求に併せて計画を更新する（８１０）。次にリソース計画装置は本番への移行準備が完了したことをプロジェクト管理ツールに通知する（８１２）。ユーザ１１０は、プロジェクト管理ツール１２０で本番への移行準備が完了したことを確かめると、本番移行を指示する（８１６）。リソース計画装置１００はこの指示を受け取ると、１回目の移行で、まだシステムが準備されていない場合は、システムのデプロイを実施する（８２０）。ここで手続き８２０は、図４における手続き４０２に該当する。

また、２回目以降の移行で、システムが準備されており、開発したプログラムだけを追加、変更する場合、システム上の関連するプロセスを停止し（８２４）、プログラムの更新を行い（８２８）、システムの関連するプロセスの起動を行い（８３２）、必要ならテストを実施する（８３６）。ここでプログラムの更新として、必要な場合、システムの各仮想サーバ上のＯＳやミドルウェア、サーバ、ストレージ、ネットワーク機器、管理システムへの変更がある場合、それらの設定も含む。その際に仮想サーバや装置の再起動などが必要な場合、それらを併せて実施してもよい。また、システムの関連するプロセスの停止、起動処理においては、更新処理中の監視の一部フィルタリングや、外部から更新中のシステムにアクセスされないようにロードバランサやネットワーク装置の設定変更などを併せて行ってもよい。ここで手続き８２４、８２８、８３２は、図４における手続き４０６に該当する。また、手続き８３６は、図4における手続き４０４に該当する。

テストを実施した場合、その結果を用いてテストまでで予測したリソース量が適切であったかを評価する（８４０）。適切でなかった場合、クラウド基盤１７０に対してリソース量の変更を行い、併せて構成管理ＤＢ１６０の構成や計画を変更する（８４４）。構成管理ＤＢ１６０の更新処理は、監視によるクラウド基盤１７０の変更結果を元に行ってもよい。またこの際のリソース計画の変更は、本番だけでなく、テスト工程への割当てのリソース量の調整に使ってもよい。この実際の計画やリソースの調整は、手続き８４８のユーザの確認後の指示を受けて行ってもよい。リソース量と計画の調整が終わった後、リソース計画装置１００は、その結果をプロジェクト管理ツール１２０に通知する（８４８）。

以上の処理及び構成により、複数のプロジェクトでＩＴリソースを共有してソフトウェア開発のテストを実行する場合において、リソースの効率的な割り当てが可能になる。

１００…リソース計画装置
１０５…利用者管理DB
１１０…ユーザ
１２０…プロジェクト管理ツール
１３０…バージョン管理ツール
１４０…デプロイツール
１５０…テストツール
１６０…構成管理DB
１７０…クラウド基盤

Claims (10)

1. 端末に接続され、複数のソフトウェア開発のテスト実行に利用される共有システムのリソースを管理するリソース管理システムであって、
   前記共有システムを構成する複数の物理サーバと複数の仮想サーバとを含むリソースの予約状況を示すリソース管理情報を記録する記録部と、
   前記端末より、前記ソフトウェア開発で実行するテストの識別子と種類と実行条件と実行期間とを含むリソース予約要求を受信する受信部と、
   前記実行条件と前記種類とに基づいて、前記テストの実行に必要なリソースと、リソースを占有又は共有で利用するかを示す利用条件を決定し、前記リソース管理情報に基づき、前記実行期間において決定した前記利用条件で前記リソースの割り当てが可能かを判定し、前記割り当てが可能と判断した場合は、前記リソースの割り当てを予約することにより前記予約情報を更新する計画調整部を備えることを特徴とするリソース管理システム。
2. 請求項１に記載のリソース管理システムであって、
   前記計画調整部は、
   前記テストの種類が機能テストである場合、ＣＰＵを共有で利用する仮想サーバを割り当てることを決定し、
   前記テストの種類が性能テストである場合、ＣＰＵを占有で利用する仮想サーバを割り当てることを決定し、
   前記テストの種類が障害テストである場合、物理サーバ単位で割り当てることを決定することを特徴とするリソース管理システム。
3. 請求項２に記載のリソース管理システムであって、
   前記計画調整部は、前記リソースがないと判断した場合は、前記リソース予約要求に基づくリソースの予約ができないことを前記端末に通知することを特徴とするリソース管理システム。
4. 請求項３に記載のリソース管理システムであって、
   前記計画調整部は、
   前記テストの種類が性能テストである場合、前記割り当てが可能な仮想サーバを有する物理サーバが複数台ある場合、前記複数の物理サーバのうち空きリソース量が相対的に少ない物理サーバを特定し、特定した前記物理サーバの仮想サーバの割り当てを予約することを特徴とするリソース管理システム。
5. 請求項４に記載のリソース管理システムであって、
   前記受信部は、前記ソフトウェア開発の進捗を示す進捗情報を受信し、
   前記計画調整部は、前記進捗情報と前記リソース管理情報とに基づき、前記リソースの割り当てを予約する期間を変更することを特徴とするリソース管理システム。
6. 端末に接続され、複数のソフトウェア開発のテスト実行に利用される共有システムのリソースを管理するリソース管理方法であって、
   前記共有システムを構成する複数の物理サーバと複数の仮想サーバとを含むリソースの予約状況を示すリソース管理情報を記録し、
   前記端末より、前記ソフトウェア開発で実行するテストの識別子と種類と実行条件と実行期間とを含むリソース予約要求を受信し、
   前記実行条件と前記種類とに基づいて、前記テストの実行に必要なリソースと、リソースを占有又は共有で利用するかを示す利用条件を決定し、前記リソース管理情報に基づき、前記実行期間において決定した前記利用条件で前記リソースの割り当てが可能かを判定し、前記割り当てが可能と判断した場合は、前記リソースの割り当てを予約することにより前記予約情報を更新することを特徴とするリソース管理方法。
7. 請求項６に記載のリソース管理方法であって、
   前記テストの種類が機能テストである場合、ＣＰＵを共有で利用する仮想サーバを割り当てることを決定し、
   前記テストの種類が性能テストである場合、ＣＰＵを占有で利用する仮想サーバを割り当てることを決定し、
   前記テストの種類が障害テストである場合、物理サーバ単位で割り当てることを決定することを特徴とするリソース管理方法。
8. 請求項７に記載のリソース管理方法であって、
   前記リソースがないと判断した場合は、前記リソース予約要求に基づくリソースの予約ができないことを前記端末に通知することを特徴とするリソース管理方法。
9. 請求項８に記載のリソース管理方法であって、
   前記テストの種類が性能テストである場合、前記割り当てが可能な仮想サーバを有する物理サーバが複数台ある場合、前記複数の物理サーバのうち空きリソース量が相対的に少ない物理サーバを特定し、特定した前記物理サーバの仮想サーバの割り当てを予約することを特徴とするリソース管理システム。
10. 請求項９に記載のリソース管理方法であって、
    前記受信部は、前記ソフトウェア開発の進捗を示す進捗情報を受信し、
    前記計画調整部は、前記進捗情報と前記リソース管理情報とに基づき、前記リソースの割り当てを予約する期間を変更することを特徴とするリソース管理方法。

Images