JP2004530191A - ウェブ・サービスで構成された、インタネット・ホスティング・ビジネス・アプリケーションの開発システム - Google Patents

Abstract

ウェブ・サービスで構成されたインタネット・ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法、ならびに各アプリケーションおよび各アプリケーション・コンポーネントが相互作用して、要求されたビジネス機能を実行する、そのような環境で使用されるソフトウェア。本発明のシステムおよび方法は、ソフトウェア開発アプリケーション・サービス・プロバイダ・モジュール（DASP）、インスタンシエータ・モジュール、ビルダ・モジュール、アプリケーション・サービス・プロバイダ（ASP）インフラストラクチャ・プラットフォーム（AIP）モジュール、および被ホスティング・プロダクション環境モジュールを用いる。本発明のシステムおよび方法は、従来の作業を最大限に活用して繰返しを不要にし、開発コストを削減し開発時間を短縮する。新しいプロジェクトができるたびにライブラリと経験が増大する。本発明のシステムおよび方法は、多数の熟練者を使用し、世界中の人を使用することによって1日中作業を行い、かつ労務費の安い国の人に作業を依頼することによってコストを削減することができるように、離散した位置に配置された開発者および試験者を使用することができる。本発明のシステムおよび方法は、開発者の初期に導入されるサード・パーティと開発者を連携させることによって、効率を高め、すべての当事者のコストを削減する。

Description

【技術分野】
【０００１】
本出願は、参照として本明細書に組み入れられる、2001年2月22日に出願された「インタネット・ホスティング環境およびそのような環境で使用されるソフトウェアを開発するシステムおよび方法（SYSTEM AND METHOD FOR DEVELOPING INTERNET-HOSTED ENVIRONMENTS AND SOFTWARE FOR USE IN SUCH ENVIRONMENTS）」という名称の米国特許仮出願第60/270,163号に対する優先権を主張するものである。
【０００２】
発明の分野
本発明は、ウェブ・サービスで構成された、インタネットによるビジネス・アプリケーション、およびそのような環境で使用されるソフトウェアに関する。特に、本発明は、インタネットに基づくASP開発環境およびそのような環境で使用されるソフトウェアを開発すると共に、各アプリケーションおよび各アプリケーション・コンポーネントが相互作用して、要求されたビジネス機能を実行する、インタネットでアクセス可能な被ホスティングASPの作成を容易にするシステムおよび方法に関する。
【背景技術】
【０００３】
発明の背景
ウェブ・サービスで構成された被ホスティングビジネス・アプリケーションの開発は経費および時間がかかる場合がある。インタネット・ホスティング・ビジネス・アプリケーションとは、ビジネス機能を実行する、（WWWを介して）インタネットでアクセス可能なアプリケーションを指す。ビジネス・アプリケーションは、XML標準を用いてインタネット上でアクセス可能なソフトウェア・コンポーネントであるウェブ・サービスを用いて「アセンブル」することができる。
【０００４】
ビジネス機能を実行すると共に個人によってアクセスすることのできるウェブ・サービスで構成された被ホスティング・ビジネス・アプリケーションの例には、宅配便、フライト情報および予約サービスを使用することのできる航空ウェブサイト、言語翻訳サービスを行う、AltaVistaによるBabefishなどのユーティリティから提供される追跡サービスが含まれる。これらの例はすべて、あらゆる人が使用可能である。しかし、企業による独自のイントラネットの開発はずっと複雑で困難である。
【０００５】
経費および開発の困難さに寄与する要因には、開発者の経験レベル、以前のプロジェクトに対して行われる同様のまたは関連する作業の繰返し、様々なサード・パーティ・アプリケーションが協働するのを助けるように作成された固有のアプリケーションに対するアクセスまたはそのようなアプリケーションの開発、およびそのような環境を作成するリソースのライブラリへのアクセスの可能性が含まれる。
【０００６】
従来、ウェブ・サービスで構成された、被ホスティング・ビジネス・アプリケーションは、アプリケーション開発者および試験者のすべてではないにせよその多数が働く中央位置で作成されている。この開発センターが、このような開発者およびソフトウェア設計者の需要が高い地域に位置しているか、またはこのようなサービスの提供コストが高い場合、このような環境を作成するコストはかなりの額になる可能性がある。さらに、このような開発チームが勤勉に働いた場合でも、たとえば、12時から6時までなど、開発または試験がほとんどまたはまったく完了しない時間が存在することがある。
【０００７】
ウェブ・サービス・ベースの被ホスティング・ビジネス・アプリケーションが開始される前に行われる試験には、開発のコストの実質的な部分が費やされる。試験コストを削減するためのある既知の解決策では、試験者の労務費が、一次開発が行われる国ほど高くない地域または外国で開発の試験部分が行われる。しかし、この場合、開発が行われる国の開発者は、試験が行われる国を訪れ、被ホスティング・ウェブ・サービスの適切な試験環境を試験位置のコンピュータ上でセットアップし環境設定する必要がある。最低でも、システムを開発するための実際のコンピュータが、依然として輸送コストおよびセットアップ・コストが生じている試験位置に輸送される。
【０００８】
さらに、各環境が分離されて作成され、かつ開発の終了近くまでまたは開発の完了後まで他の潜在的な長期的なパートナーがプロジェクトに導入されないため、上述の従来の環境開発では追加の経費が生じることがある。アプリケーション開発が完了に近づくまで、インタネット・ホスティング・サービス・プロバイダ（HSP）がプロジェクトに導入されない場合、アプリケーションは、選択されたHSPの固有のネットワーク特性およびサービスに対しても、またこれらの特性およびサービスを使用するようにも最適化されていない可能性があり、HSPは一般に、開発プロセスに最初から関わった場合ほど深く環境のことを理解しない。
【０００９】
現在の所、地理的に分散された開発者が、ウェブ・サービスで構成された、被ホスティング・ビジネス・アプリケーションを作成することのできるシステムも、輸送コストを被ることも、第2の位置で広範囲のソフトウェア・セットアップおよびインストールを行うこともなしに、ある位置で開発を行い、第2の位置で試験を行うことができるシステムもない。したがって、様々な位置からの開発者および試験者が、特定の開発位置を訪れる必要なしに、被ホスティング・ビジネス・アプリケーション・システムの開発および試験を行うことのできる、インタネットでアクセス可能なアプリケーション開発環境を提供することは、当技術分野の進歩に繋がる。
【発明の開示】
【００１０】
発明の概要
本発明は、ウェブ・サービスで構成された、被ホスティング・ビジネス・アプリケーションを開発するソフトウェア・システムおよび方法を提供することによって、従来技術の問題および制限を解消する。特に、本発明は、要求されたビジネス機能を実行するためにインタネットでアクセス可能なウェブ・サービスがシームレスに相互作用することのできる被ホスティング・ビジネス・アプリケーションの作成を容易にする。
【００１１】
本発明は、前の開発サイクル中に行われた同様の作業の繰返しを最小限に抑えることにより、被ホスティング・インタネット開発環境を用いたビジネス・アプリケーションおよびウェブ・サービスの開発をより効率的にする。各環境は、様々なサード・パーティ・プロダクトおよびサービスによって作成することができる。これらの環境では、意図された結果が得られるように各サード・パーティ・プロダクトが協働するように固有のアプリケーションを開発し試験する必要がある。さらに、このシステムは、各クライアントの要求に応じ、このクライアントによる環境の最終的な用途に応じて、固有のアプリケーションの開発を容易にする。
【００１２】
本発明のシステムは、新しい環境が開発されるたびに使用することのできる、このような環境を作成するためのリソースのダイナミック・ライブラリを作成することによって、これらの環境の開発を容易にする。リソース・ライブラリは、プラットフォーム、ミドルウェア・プロダクト、アプリケーション、およびデータベースを含む。プラットフォームおよびミドルウェア・プロダクトは、NetCool、Microsoftプロダクト、Solarisなどのサード・パーティ・プロダクトであってよい。アプリケーションは、サード・パーティ・プロダクトであっても、開発者によって社内で開発されたアプリケーションであってもよい。ソフトウェア開発プロジェクト中に社内で使用または開発された新しいサード・パーティ・アプリケーションをリソース・ライブラリに追加してもよい。したがって、新しい開発プロジェクトができるたびに、開発グループの技能、使用済みのプロダクトのライブラリ、および固有のアプリケーションのライブラリが増大する。
【００１３】
ソフトウェア開発環境を構築するために使用できる潜在的なプロダクトはかなりの数である。これらのプロダクトを統合できる方法の数はそれよりもずっと多い。本発明のシステムおよび方法は、以前の作業を最大限に活用して繰返しを無くし、それによって開発コストを削減し開発時間を短縮しようとする。
【００１４】
本発明のシステムのシステムおよび方法の他の局面は、開発者および試験者を中央位置ではなく離散位置で使用する能力である。その結果、より多くの熟練者を使用することができ、世界中の人を使用することによって1日中作業を行うことができ、実行中の作業に対する労務費がより安い国の人に作業を依頼することによって、試験コストを含むコストを削減することができる。
【００１５】
最後に、本発明のシステムおよび方法は、サード・パーティに開発局面および試験局面ならびに最終的な実施の全体にわたってビジネス・アプリケーションをホスティングさせることによって、クライアントとサード・パーティが共にコスト節約および利点を実現できるように、開発サイクルの初期に導入されるHSPなどのサード・パーティと開発者を提携させることにより、効率を高めコストを削減する。
【００１６】
アプリケーションとウェブ・サービスがビジネス機能を実行するようにシームレスに相互作用するインタネット・ベースのビジネス・アプリケーションの開発を容易にするために、本発明のシステムは、ソフトウェア開発アプリケーション・サービス・プロバイダ（DASP）モジュール、インスタンシエータ・モジュール、ビルダ・モジュール、アプリケーション・サービス・プロバイダ（ASP）インフラストラクチャ・プラットフォーム（AIP）モジュール、および被ホスティング・プロダクション環境モジュールを含んでいる。DASPモジュールは、リモートのソフトウェア開発および試験を可能にし、ユーザのデスクトップ上のウェブ・ブラウザのみを用いて共同ソフトウェア開発および試験を行うのを可能にするソフトウェア・インフラストラクチャ、開発環境、および方法を実現する。
【００１７】
イニシエータ・モジュールは、被ホスティング・ウェブ・サービス・ベースのビジネス・アプリケーションが開発されるクライアントによって選択された特定の目標ホスティング環境向けに調整されたアプリケーション・サービスを生成するようにDASP環境をカスタマイズする。特定のホスティング環境を求める要求に応答して、目標ホスティング環境からの関連するアプリケーション・サービスが与えられる。
【００１８】
ビルダ・モジュールは、クライアントがAIPモジュール上に存在するアプリケーション・サービスを見つけて使用するのを可能にする索引を含んでいる。ビルダ・モジュールは、DASP、インスタンシエータ、およびAIPモジュールと協働して、開発者が、索引の選択によって、既存のサービスを呼び出すか、または事前に構築されたウェブ・サービスをアプリケーションとして統合するのを可能にする。
【００１９】
被ホスティング・プロダクション環境（HPE）モジュールは、HSPウェブ・サーバや関連する業務サポート・アプリケーションのような、インタネット・ベースの開発が行われるインフラストラクチャを含んでいる。HPEモジュールは、ビジネス・アプリケーションを開発した技術向けに調整することができる。AIPモジュールは、アプリケーションの検索および供給、ユーザの認証、ユビキタス・アクセス、および使用度に応じた加入者課金サービスを行う。
【００２０】
本発明のこれらおよびその他の属性について、下記の図面に関して説明する。
【００２１】
発明の詳細な説明
本発明のシステムおよび方法は、ウェブ・サービスで構成された、新しい被ホスティング・ビジネス・アプリケーションの構築、および顧客が仮想ソフトウェア開発環境を提供することによって顧客のソフトウェア開発コストを削減するのを可能にするソフトウェア開発ツールの構築を容易にするように構成されている。本発明は、既存の技術を使用することによって多数の利点を実現する。特に、本発明のシステムおよび方法は、プログラミング・インフラストラクチャ・ツール（たとえば、第4世代言語、すなわち4GL、コード生成プログラム、バージョン制御プログラム、試験ツールなど）を統合された単一の開発環境としてカプセル化する。情報システム人的資源は不足しており、ソフトウェア開発労務費は各国間で著しく異なっている。顧客は、本発明を用いることにより、追加の輸送や、出張や、セットアップ・コストを生じさせずに、経済的な労働力が存在する地域へプロジェクト作業を移すことができる。
【００２２】
各実体が新しいビジネス・システムを見つけ、拡張し、妥当性を検証し、ネットワーク上で効率的に確立するのを可能にする解決策を提供するために、本発明は好ましくは、1つまたは複数のコンピュータおよび1つまたは複数のネットワークと共に実施される。このようなコンピュータの例示的な動作環境が図1に示されており、コンピュータ100はローカル・エリア・ネットワーク（LAN）102およびワイド・エリア・ネットワーク（WAN）104に接続されている。コンピュータ100は、コンピュータの動作全体を制御する中央演算処理装置110と、中央演算処理装置110を後述のコンポーネントに接続するシステム・バス112とを含んでいる。システム・バス112は、様々な従来のバス・アーキテクチャのうちのいずれか1つで実施することができる。
【００２３】
コンピュータ100は、データまたはファイルの読み書きを行う様々なインタフェース・ユニットおよびドライブを含んでよい。特に、コンピュータ100は、それぞれハード・ディスク・ドライブ118および取外し可能なメモリ・ドライブ120をシステム・バス112に結合するローカル・メモリ・インタフェース114および取外し可能なメモリ・インタフェース116を含んでいる。取外し可能なメモリ・ドライブの例には、磁気ディスク・ドライブおよび光ディスク・ドライブが含まれる。ハード・ディスクは一般に、コンピュータ可読媒体122への書込みを行う場合は各ビットを磁気パルスに変換し、コンピュータ可読媒体122からデータを読み取る場合は各磁気パルスをビットに変換する1つまたは複数の読取り／書込みヘッドを含んでいる。単一のハード・ディスク・ドライブ118および単一の取外し可能なメモリ・ドライブ120が、例示のためのみに、コンピュータ100が複数のそのようなドライブを含んでよいという理解の下に示されている。さらに、コンピュータ100は、磁気光ドライブのような他の種類のコンピュータ可読媒体とのインタフェースをとるドライブを含んでもよい。
【００２４】
ハード・ディスクとは異なり、システム・メモリ126などのシステム・メモリは一般に、データを電子的に読み書きし、読取り／書込みヘッドを含んでいない。システム・メモリ126は、ベーシック入出力システム（BIOS）を記憶する読取り専用メモリ部を有する従来のシステム・メモリと、他のデータおよびファイルを記憶するランダム・アクセス・メモリ（RAM）とによって実施することができる。
【００２５】
ユーザは、様々な入力装置を有するコンピュータ100と対話することができ
る。図1は、キーボード130およびポインティング・デバイス132をシステム・バス112に結合するシリアル・ポート・インタフェース128を示している。ポインティング・デバイス132は、ハード配線されたマウスまたは無線マウス、トラック・ボール、ペン・デバイス、または同様の装置によって実施することができる。
【００２６】
コンピュータ100は、周辺装置をシステム・バス112に接続する追加のインタフェースを含んでよい。図1は、ビデオまたはデジタル・カメラ136をシステム・バス112に結合するユニバーサルシリアルバス（USB）インタフェース134を示している。IEEE1394インタフェース138を用いて追加の装置をコンピュータ100に結合することができる。さらに、インタフェース138は、Apple Computerによって開発されたFire WireやSonyによって開発されたi.Linkのような特定の製造インタフェースと協働するように構成することができる。周辺装置には、接触感応画面、ゲーム・パッド・スキャナ、プリンタ、およびその他の入出力装置を含めることができ、パラレル・ポート、ゲーム・ポート、PCIボード、または周辺装置をコンピュータに結合するのに用いられる他のインタフェースを通して周辺装置をシステム・バス112に結合することができる。
【００２７】
コンピュータ100は、表示装置142をシステム・バス112に結合するビデオ・アダプタ140も含んでいる。表示装置142は、陰極管（CRT）、液晶ディスプレイ（LCD）、電界放出ディスプレイ（FED）、プラズマ・ディスプレイ、またはユーザが見ることのできる画像を生成する他の装置を含んでよい。マイクロフォン144およびスピーカ146によって音声を記録し再生することができる。サウンド・カード148を用いてマイクロフォン144およびスピーカ146をシステム・バス112に結合することができる。
【００２８】
当業者には、図1に示されている装置接続が図示のためのみのものであり、いくつかの周辺装置を他のインタフェースを介してシステム・バス112に結合できることが理解されよう。たとえば、ビデオ・カメラ136をIEEE1394インタフェース138に接続することができ、ポインティング・デバイス132をUSBインタフェース134に接続することができる。
【００２９】
コンピュータ100は、システム・バス112をLAN102に結合するネットワーク・インタフェース150を含んでいる。LAN102は、1つまたは複数の公知のLANトポロジーを有してよく、イーサネットのような様々な異なるプロトコルを使用することができる。コンピュータ100は、コンピュータ152やプリンタ154のような、LAN102に接続された他のコンピュータおよび装置と通信することができる。コンピュータおよび他の装置は、より対線、同軸ケーブル、光ファイバ、またはその他の媒体を介してLAN102に接続することができる。または、無線波を用いて1つまたは複数のコンピュータまたは装置をLAN102に接続することができる。
【００３０】
インタネットなどのワイド・エリア・ネットワーク104に、コンピュータ100によってアクセスすることもできる。図1は、シリアル・ポート・インタフェース128およびWAN104に接続されたモデム・ユニット156を示している。モデム・ユニット156は、コンピュータ100内に位置してもコンピュータ100の外部に位置してもよく、ケーブル・モデムや衛星モデムのような任意の種類の従来のモデムであってよい。LAN102を用いてもWAN104を接続することができる。図1は、従来の方法でLAN102をWAN104に接続することができるルータ158を示している。サーバ160は、WAN104に接続されるように示されている。もちろん、多数の追加のサーバ、コンピュータ、ハンドヘルド装置、パーソナル・デジタル・アシスタント、電話、および他の装置をWAN104に接続することもできる。
【００３１】
コンピュータ100およびサーバ160の動作は、コンピュータ可読媒体上に記憶されているコンピュータ実行可能命令によって制御することができる。たとえば、コンピュータ100は、サーバ160に情報を送信し、サーバ160から情報を受信し、受信された情報を表示装置142上に表示するためのコンピュータ実行可能命令を含んでよい。さらに、サーバ160は、ハイパーテキスト記述言語（HTML）コンピュータ・コードまたはXMLコンピュータ・コードをコンピュータ100に送信するためのコンピュータ実行可能命令を含んでよい。
【００３２】
本発明のシステムを用いることにより、顧客は、冗長なマシン用の開発ハードウェアおよびシステムの管理を無くすことによって顧客の全体的な開発コストを削減することができる。顧客は、（以前の開発サイクルからの）立証済みの方法および増分管理サービス（たとえば、OS、データベース管理など）にアクセスすることもできる。従来の開発モデルと本発明のシステムおよび方法のモデルとの比較が図2に示されている。
【００３３】
現在のモデルでは、従業員、ハードウェア、ソフトウェアなどのモデル・ソフトウェア開発リソースは、ソフトウェア開発者サイト160、すなわち図2のAccentureからクライアント・サイト162に直接輸送される。独立ソフトウェア・ベンダ（ISV）およびハードウェア・ベンダ164もクライアント・サイト162に行き来しなければならない。プロダクション・ホスティング、すなわち、開発サイクル中に使用されるウェブ・サーバを与えることは、独立ホスタ166によって行われる。現在のモデルでは、すべての活動の調和をクライアント・サイト162で図らなければならず、クライアントはコンサルティング・サービスの経費および出張旅費、開発環境の資本、プロダクション・システムに対するウェブ・ホスティングの経費を支払う。
【００３４】
図2の将来の本発明のモデルによれば、本発明は、クライアント162のサイトに位置していない新しい開発環境168を含んでいる。ソフトウェア開発者160は、クライアント162および新しい開発環境168と直接協働することができる。ISVとハードウェア・ベンダ164とウェブ・ホスタ166は、クライアント162ではなく新しい開発環境168を通じて対話する。開発リソースを物理的にクライアント162まで運ぶ必要はない。というのは、このような資源を従来のウェブ・ブラウザを介して得ることができ、かつクライアント162が経費を支払うのがコンサルティング・サービスおよびDASPだけだからである。
【００３５】
図3を参照すると、従来のシステム統合構成が示されている。ここで、クライアント162は、クライアント／サーバ・システムを構築するのにシステム・インテグレータを雇用している。システム・インテグレータ164は、Pacific Rimの開発「ソリューション・センター」を使用してコストを低く維持している。フロント・エンドは、ニューヨークにあるクライアント・サイトで働く、ワシントンD.C.に本拠地を置くチーム160によって作成される。クライアントは、開発・試験ハードウェアおよびソフトウェアのライセンスを購入する責任を負う。クライアントはこの場合も、プロダクション・ホスティング・プロバイダ166を選択することができる。
【００３６】
図4は、本発明のシステムおよび方法を使用するシステム統合を示している。この例では、システム管理サービスおよびデータベース管理サービスと同様に、すべての開発サーバ・ハードウェアおよびソフトウェアが1つの位置168に設けられている。他の位置にいる試験者および開発者は、インタネット上の従来のウェブ・ブラウザを介して開発システムにアクセスすることができる。
【００３７】
一例として、Regional Bell Operating Company (RBOC)情報サービス部が、Accenture、すなわちシステム・インテグレータの顧客であると仮定する。ISP、インタネット業務外注会社、およびホスティング・サービス・プロバイダは、それぞれインタネット接続、ウェブサイト・メンテナンス、およびウェブサイト・ホスティング用のインフラストラクチャ・リソースを提供することができる。1つまたは複数の独立ソフトウェア・ベンダがあってよい。本発明のシステムおよび方法を用いることによって、顧客は、ソフトウェア開発コストを削減し、たとえば、開発ハードウェア／ソフトウェアの購入など、技術資源への投資を不要にすることができ、かつ後述のように、複数のシステム・インテグレータと容易に協働することができる。
【００３８】
システム・インテグレータは、利益も実現することができ、すなわち、出張旅費を削減し、したがってコストを削減して、エンド・クライアントに対して供給リスクを少なくし、統合をより密にし、たとえば、マーケット時間を短縮し、作業スケジュールおよび作業位置の融通性によって従業員の満足度を高め、かつシステム管理ではなく設計システム、開発システム、および試験システムの真の能力に焦点を当てることを可能にする。さらに、システム・インテグレータは、資源を、たとえば各地理的位置でより効率的に使用できるようになり、かつ最も費用有効な資源にてこ入れできるようになる（グローバル経済因子）。システム・インテグレータの他の利益は、サード・パーティのパートナーおよび専門家とうまく統合することができ、コード・リポジトリを再利用できるようになることである。
【００３９】
本発明のシステムおよび方法におけるインフラストラクチャ・プロバイダも利益を実現する。特に、インフラストラクチャ・プロバイダは新しい顧客（ソフトウェア開発を行う顧客）を開発し、かつ追加の販売経路を開発し、すなわち、開発環境を外注する顧客はプロダクション環境を外注することが必要になる。さらに、インフラストラクチャ・プロバイダは、従来のウェブ・ホスティング会社よりも早く顧客との関係を築けるようになり、かつより高度なアプリケーション管理システムを提供できるようになる。
【００４０】
本発明のシステムおよび方法を使用した結果として、ISV/ソフトウェア開発ツール・ベンダは、その顧客ベースを広げ、顧客がそのプログラムを使用するためのより容易な方法を開発し、端末間環境用の他のユーティリティとの統合することができるようになる。他の追加の利益として、出張時間および費用が大幅に削減される。
【００４１】
図5および図6を参照すると分かるように、本発明のシステムの基本コンポーネントは、ソフトウェア開発アプリケーション・サービス・プロバイダ（DASP）モジュール180、インスタンシエータ・モジュール182、ビルダ・モジュール184、アプリケーション・サービス・プロバイダ（ASP）インフラストラクチャ・プラットフォーム（AIP）モジュール186、および被ホスティング・プロダクション環境（HPE）モジュール188である。
【００４２】
DASP180は、リモートなソフトウェア開発および試験を可能にし、ウェブ・ブラウザ190のみを用いた共同ソフトウェア開発を可能にするソフトウェア・インフラストラクチャ、環境、および方法を実現する。DASP180は、互いに統合しウェブ・ブラウザ190を通して対話することのできる、ソフトウェア開発プロセスに必要な様々なツール（推定ツール、データ・モデリング・ユーティリティ、ソフトウェア開発ツール、試験環境サポート、および文書化された方法）を与える。したがって、開発チーム、試験チーム、および管理チームは、その物理的位置にかかわらず大規模なプロジェクトで共同することができ、ソフトウェア・プロジェクトを効率的に開発し試験するためのグローバル・チームワークが可能になる。
【００４３】
DASP180は、プロジェクト・セットアップ・コストを削減するための事前に環境設定されたツールおよびコンポーネントを、1組の被ホスティング環境およびサービスに与え、プロジェクト環境のセットアップを無くし、開発ライフサイクルを簡略化することもできる。このようなサービスは、ウェブ・ブラウザからアクセスできるカスタマイズされたポータル192においてDASP180ユーザに示され、したがって、プロジェクト・チームは任意の位置からリモートに調整、開発、および試験を行うことができる。統合された1組のツールは、自動化された環境作成、標準化された開発習慣、コンポーネントの再利用可能性の向上、環境設定の管理および環境の移行、およびプロダクション・メンテナンスを容易にする。
【００４４】
DASPポータル192は、プロジェクトにおける各ユーザの役割によってカスタマイズされたツールおよびサービスをユーザに供給する。たとえば、プロジェクト管理者には、プロジェクト・プランニング・ツール、リソース管理ツール、リリース管理ツール、ステータス報告機能、およびDASP180環境管理を与えることができる。一方、開発者には、開発環境の端末、ソース・コード・エディタ、デバッガ、SQLデータベース・サービス、バージョン制御サービス、および欠陥追跡サービスを与えることができる。
【００４５】
本発明によって提供されるサービスは、ソフトウェア開発タスク（ソフトウェア設計、プログラミング、デバッギング、試験、およびプロジェクト管理）を実行する場合に各プロジェクト・チームを同じ物理的位置に位置させるのを不要にする。
【００４６】
DASP180は、様々な開発ツールを有するポータル192を含んでいる。事前に構築され環境設定された環境を作成するようにすでに開発されている固有のアプリケーションを含むこれらの環境をDASP180を通じて使用することができる。DASP180は、ブラウザ190を有するPCからアクセスできる中央システム上に維持されており、したがって、冗長なハードウェアの購入およびメンテナンスは不要になる。
【００４７】
インスタンシエータ・モジュール182は、クライアント（たとえば、PeopleSoftERP、SiebelSFA、BEA WebLogicなど）によって選択された特定の目標ホスティング環境向けに調整されたアプリケーション・サービスを提供することによってDASP180環境をカスタマイズする。特定の目標ホスティング環境を求める要求に応答して、目標ホスティング環境プロファイルおよび所望の環境の要件を満たす関連するアプリケーション・サービスが提供される。これには、調整された方法、事前に作成された試験データベース、試験環境、ならびに関連する内部コンテントおよび外部コンテント（たとえば、Forrester Industryトレンド）が含まれる。インスタンシエータ・モジュール182は、プロダクトの構築、バージョン化、アプリケーション・サービスのプロダクション環境への導入を容易にする。
【００４８】
インスタンシエータ・モジュール182は、アプリケーション・サービス開発ライフサイクルを容易にする被ホスティング・アプリケーションである。プロジェクトに関わっているユーザはまず、開発環境、試験環境、またはプロダクション環境を特定の目標ホスティング環境向けにインスタンス化することを要求する。インスタンシエータ・モジュール182は、要求された環境（たとえば、開発や、試験や、プロダクション）を生成して自動的に設定し、アプリケーション・コードおよびデータを移し、目標ホスティング環境プロファイルおよび所望の環境に合うすべての関連するアプリケーション・サービスをユーザが使用できるようにし、したがって、アプリケーション・サービス開発ライフサイクルの開発局面と構築局面と試験局面とリリース局面との間の円滑な移行を容易にすることによって要求に応答する。インスタンシエータ・モジュール182はまた、AIP186とのインタフェースをとり、生成された環境を供給することに対して顧客に課金する。
【００４９】
インスタンシエータ・モジュール182は、開発チームおよび試験チームが過去の最良の慣習にてこ入れした新しいアプリケーションを構築するのを可能にするように、これらのチーム向けの個人化されたコンテントも提供し（たとえば、Siebelインスタンシエータを介してSiebel設計文書が供給される）、また、開発環境、試験環境、およびプロダクション環境の生成を容易にし、パッケージ固有のデータベースおよびテーブルの多くを事前に作成する。
【００５０】
ビルダ・モジュール184は、クライアントが、AIPモジュール186に存在するアプリケーション・サービスを見つけ使用するのを可能にする索引を含んでいる。ビルダ・モジュール184は、DASPモジュール180、インスタンシエータ・モジュール182、およびAIPモジュール186と統合され、開発者が、索引を選択することによって、容易に既存のサービスを呼び出すか、または事前に構築されたコンポーネントを開発者のアプリケーションに組み込むのを可能にする。
【００５１】
ビルダ・モジュール184は、特定の目標ホスティング環境およびユーザが使用できるようにAIP186上に存在する関連する汎用アプリケーション・サービスを見つけて呼び出すのを可能にする被ホスティング・アプリケーションであってよい。開発環境、試験環境、またはプロダクション環境をインスタンス化する際、ビルダ・モジュール184は、AIPモジュール186に存在する利用可能な関連するアプリケーション・サービスを判定する。
【００５２】
開発者がアプリケーションを作成する際、ビルダ・モジュール184は、利用可能なコンポーネントのリストをDASPポータル192を介して提供する。開発者は、アプリケーションの要件および設計に基づいて、この1組の再利用可能なコンポーネントのうちのどれかを選択し、それを必要に応じてアプリケーションに組み込む。コンポーネントの多くは、アプリケーション・オペレーションズ・センター（AOC）、ビジネス・オペレーションズ・センター（BOC）、およびネットワーク・オペレーションズ・センター（NOC）用のロギング・サービスや警告サービスのような、HPEモジュール188に直接フックされる実行アーキテクチャ・サービスである。これらのコンポーネントは、本発明のプロダクション環境の報告機能、監視機能、および管理機能と統合される。開発サイクルを短縮するために、各プロジェクトごとに頻繁に再作成される共通のアプリケーション・サービスおよびビジネス論理サービスをビルダ・モジュール184を介して各プロジェクト・チーム間で（検討および承認後に）共用することができる。さらに、ビルダ・モジュール184を介してサード・パーティ・ウェブ・サービスを開発し販売することができ、AIP186との統合により、使用度に応じて請求書が生成される。
【００５３】
被ホスティング・プロダクション環境（HPE）188は、アプリケーション・サービスが構築された目標ホスティング環境のインスタンス向けに調整することができる。この1つの利点として、より早い段階でサード・パーティが開発サイクルに導入されるので、これらのサード・パーティが開発プロセスにおいて最初から呼び出され、したがって、より高いサービス・レベルを実現することができる。
【００５４】
HPEモジュール188は、アプリケーション・サービスが組み込まれ、プロダクション監視システムおよびビジネス・システム・サービス（BSS）/アプリケーション・インフラストラクチャ・プロバイダのオペレーション・システム・サポート（OSS）を緊密に統合し、高レベルなサービスを提供する（例えば100％可用性、開発/テストシュミレーション）技術インスタンスを標的としているリモートラン・タイム環境を含むことができる。
【００５５】
HPEモジュール188は、アプリケーション・アーキテクチャがアプリケーション（たとえば、NetCool）の端末間管理可能性を向上させるのに使用する実行アーキテクチャAPIを、ホスティング実行時データ・センターを通じて供給する。すべてのアプリケーション・サーバおよびソフトウェア／ハードウェアは、HPEモジュール188内に組み込まれ、ネットワーク・オペレーションズ・センター（NOC）で監視される。アプリケーション・オペレーションズ・センター（AOC）はビジネス・オペレーションズ・センター（BOC）と共に、ロバストなアプリケーション安定性・性能監視ユーティリティおよびビジネス使用度・トレンド分析ユーティリティをHPEモジュール188によって提供する。
【００５６】
HPEモジュール188はまた、自動化された中央環境管理機能およびコード移行機能を顧客に与え、リモート・チームまたはリモート・チーム・メンバーの生産性を高めるのを可能にする。HPEモジュール188は、統合された開発／試験環境と共に、開発者とプロダクション管理者の双方が、そのシミュレーションにおいて綿密にかつシームレスに共同するのを可能にする。さらに、顧客はソフトウェア／ハードウェア環境設定に対する投資を削減する。
【００５７】
本発明のアプリケーション・サービス・インフラストラクチャ・プラットフォーム（AIP）モジュール186は、アプリケーションの供給、検索、ユーザの認証、ユビキタス・アクセス、およびユーザ／加入者ベースの課金サービス用の機構を提供する。AIPモジュール186は、ライトウェイト・ディレクトリ・アシスタンス・プロトコル（LDAP）ベースのサービス・ディレクトリ・サーバへのオープンXMLプロトコルを介した通信アクセスを可能にする。
【００５８】
エンド・ユーザ（開発者など）は、ポータル192を通じてウェブ・アプリケーション・サービスにアクセスすることができると共に、オープンXMLインタフェース・プロトコルを介して他のアプリケーションにアクセスすることができる。このオープン・アーキテクチャの結果として、サービスは、サーバ側とクライアント側の両方で、オペレーティング・システムにも、プログラミング言語にも、オブジェクト・モデルにも依存しない。したがって、任意の言語で書かれ、任意のコンポーネント・モデルを使用し、任意のオペレーティング・システム上で実行されるアプリケーションをAIPモジュールを通じてウェブ・サービスとして供給することができる。統合されたAIP BSS/OSSシステムは、これらのサービスの使用に対して使用度に応じて課金するか、または単一料金で課金する機能を実行する。
【００５９】
AIPモジュール186は、顧客が、HPEモジュール188に存在するアプリケーションおよびアプリケーション・コンポーネントのライブラリを通じてeサービスにアクセスするのを可能にする。アプリケーション・サービスの性能、可用性、および完全性は、NOC、AOC、およびBOCを通じて適切に監視しスケーリングすることができる。AIPモジュール186を通じて大規模でスケーリング可能なLDAPデータベースを用いてインタネット・サービスへのアクセスを制御することができる。AIPモジュール186は、すでに開発されているソフトウェアおよびコンポーネントを再利用することによって、マーケット時間を短縮し、開発コストを削減する。
【００６０】
本発明のシステムおよび方法は、データ・センター機能およびオペレーションズ・サービス（アプリケーション・インフラストラクチャ・プロバイダ）とソフトウェア開発プラットフォーム／ツールとの統合（インタネット・サービス・ベンダ、ハードウェア会社）の両方によって仮想ソフトウェア開発環境を構築し、動作させ、スケーリングする必要がある。
【００６１】
次に、本発明のシステムおよび方法を、様々なコンポーネントと共に、特定の例に関して説明する。まず、プロジェクト管理者が、本システムの販売に関わっている人と連絡をとり、契約に署名するかまたはオンライン支払いを用いてDASP180をSiebelのような特定の技術、すなわちプロジェクトXYZ用のインプリメンテーションに使用する。オペレーションズ・チームは、要求を検討して承認し、インスタンシエータ・モジュール182をトリガしてXYZプロジェクト用のSiebel DASP環境インスタンスを作成する。インスタンシエータ182は、環境、ツール、文書、セキュリティ・フレームワークを生成し、AIPモジュール186とのインタフェースをとって環境の作成に対して課金する。
【００６２】
オペレーションズ・チームは、DASPポータル192を介してXYZプロジェクト用の新しい「プロジェクト管理者」ユーザを作成する。「DASPモジュール180」180は、AIPモジュール186とのインタフェースをとり、ユーザの作成に対して課金する。次に、プロジェクト管理者はDASPモジュール180にログインし、ポータル192は、プロジェクト・プランニング・ツールや、推定ツールや、リリース管理ツールや、新しいチーム・メンバーを作成する機能のような「プロジェクト管理者」固有のサービスを表示し、新しい環境を生成する。DASPポータル192は、ユーザの役割（この場合は、「プロジェクト管理者」）に基づいてコンテントを表示する。
【００６３】
プロジェクト管理者は、チーム・メンバー作成サービスを用いて、DASPモジュール180がチーム・リード、開発者などにアクセスするのを可能にする。ユーザがDASPポータル192を介して作成され、DASPモジュール180はAIPモジュール186とのインタフェースをとり、ユーザの作成に対して課金する。
【００６４】
次に、開発者が、DASPモジュール180にログインし、ポータルが開発環境端末、バージョン制御ツール、欠陥追跡ツール、オブジェクト・モデリング・ツールおよびデータ・モデリング・ツール、ビルダ・モジュール184サービスのような「開発者」固有のサービスを表示する。DASPポータル192はユーザの役割（この場合「開発者」）に基づいてコンテントを表示する。ビルダ・モジュール184は、アプリケーションに組み込むことのできるサービスを表示する。これらのサービスには、特に目標環境（Siebel）向けに設計されたサービスと、汎用グローバル・サービスとを含めてよい。
【００６５】
次いで、開発者はアプリケーションを構築し、（たとえば）3つのビルダ・モジュール184サービスを統合する。1つのサービスはロギングを実行し、第2のサービスは、ホストの監視コンソールに対する警告を実行し、第3のサービスはクレジット・カードの妥当性を検証するサード・パーティ・コンポーネントである。開発者は、DASPから供給される開発環境ツール、バージョン制御ツール、欠陥追跡ツール、設計ツールなどを使用する。ビルダ・モジュール184は、事前に構築された各コンポーネントをリストして統合し、AIPモジュール186と通信して構成サービスに対して1度限りの課金を行い、クレジット・カード・サービスのサード・パーティ・プロバイダに対して継続的な支払いを行う。
【００６６】
開発が完了に近づくと、プロジェクト管理者は、DASPポータルを192を用いて試験環境を購入し作成する。プロジェクト管理者は、DASPポータル192を用いて購入を開始し、インスタンシエータ・モジュール182は、プロダクションに存在するすべてのサービスを含むプロダクション的Siebel試験環境を作成する。次いで、インスタンシエータ・モジュール182は、AIPモジュール186とのインタフェースをとり、環境の作成に対して課金する。
【００６７】
リリース管理者が、DASPから供給される環境設定管理サービスによって試験環境への移行を開始する。統合環境設定管理サービスは完全なコンパイルを実行し、必要なコード、データなどを試験環境に移行する。
【００６８】
次に、試験チーム・メンバーが、DASPから供給される自動化試験ツール、ロード試験ツール、および欠陥追跡サービスを使用して機能・性能試験を行う。ロード試験ツールを用いると、ロード試験サーバを使用した持続時間に基づいてAIPモジュール186を介して請求書が生成される。プロダクション管理機能とのインタフェースを有する、ビルダ・モジュールから供給されるロギング・コンポーネントおよび警告コンポーネントが、被ホスティング・プロダクション環境188と適切に対話することを確認するために試験される。
【００６９】
アプリケーションを開発環境から試験環境に移行する複数のソフトウェア・ビルドによって反復開発が続行する。リリース管理ツールは欠陥解消およびパッチ移行を容易にする。
【００７０】
試験が完了に近づくと、プロジェクト管理者は、DASPポータル192を用いるプロダクション環境をDASPポータル192を用いて購入し作成する。次いで、インスタンシエータ・モジュール182は、プロダクションSiebel環境を作成し、AIPモジュール186とのインタフェースをとり、環境の作成に対して課金する。
【００７１】
次に、HPEモジュール188が作成され試験され、機能プロダクトをHPEモジュール188に移行することができる。統合リリース管理ツールは、プロダクション・アプリケーションの移行および初期設定を実行する。このアプリケーションはHPEモジュール188で実行される。ビルダから供給されるサービスがプロダクション・アプリケーションと統合される。構成サービスがホスティング環境と統合され、ホストの監視機能に対してログし警告する。AOC、BOC、およびNOCはアプリケーション、ビジネス、およびネットワークのステータス、統計、および安定性の監視および報告を継続的に行う。ホストにフックされる、アプリケーションに組み込まれた報告機能、ロギング機能、および警告機能は、リアルタイム・トレンド分析機能、性能・安定性監視機能、および高度デバッギング機能を実行することができる。
【００７２】
図7に示されているように被ホスティング・インタネット環境を開発する従来の方法と比べて、本発明による、ウェブ・サービスで構成された被ホスティング・ビジネス・アプリケーションを開発する方法は、図8に示されているように、多数の経費および手順を減らすかまたは無くする。特に、本システムは、パッケージされたソフトウェアの選択、物理的環境の設計および計画、技術インフラストラクチャの設計、ならびに初期チームワーク環境の設計を容易にする。
【００７３】
本発明による、このような環境で使用されるウェブ・サービスおよびソフトウェアで構成された被ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法は、物理的な環境資産およびサービスを獲得する段階と、技術インフラストラクチャを構築して試験する段階と、初期チームワーク環境を実施する段階と、チームワーク環境を動作させる段階とを不要にする。
【００７４】
チームワーク環境は通常、初期開発環境、オプション・エンジニアリング・ラボ、初期ネットワーク化インフラストラクチャ、初期通信環境、PCベースのツール、設計リポジトリ、知識管理機能、プログラム管理ソフトウェア、および／またはモデル・オフィスから成っている。
【００７５】
初期チームワーク環境の実施は通常、初期チームワーク環境デリベラブル（deliverable）の実施を完了する段階から成る。これには、初期チームワーク・コンポーネントを構築またはインストールする段階と、適切な試験段階および妥当性検証段階を行う段階と、サポートすべきプロジェクトにチームワーク環境を導入する段階とが含まれる。本発明による、ウェブ・サービスで構成された被ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法は、これらのサービスを行う。プロジェクト・チームはPCを有しインタネットにアクセスするだけでよい。
【００７６】
従来の開発における次の段階は、初期チームワーク環境の動作である。サポートされているプロジェクトによって識別され要求された拡張が必要に応じて行われるように、チームワーク環境の継続的なメンテナンスおよびサポートが行われる。チームワーク環境は、サポートされているプロジェクトが、その作業を最も効果的に可能にする環境で動作するように、最新バージョンの技術インフラストラクチャ（すなわち、ハードウェア）を用いて定期的に更新される。本発明による、ウェブ・サービスで構成された被ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法は、これらのサービスを行う。
【００７７】
従来の開発ではプログラムおよびプロジェクトを管理する必要がある。プログラム管理では、複数のプロジェクトおよびリリースによるビジネス機能の供給をサポートするのに必要な連続的なガイダンスに焦点が当てられる。適切な考え、技術、およびツールを用いて作業が計画され構成され、新しいビジネス機能の増分的な供給が管理される。プロジェクト管理では、適用範囲、品質、作業、リスク、およびスケジュールのバランスのとれた管理によって、特定のデリベラブル、たとえば、プロセス・フロー、ジョブ設計、ビジネス・アプリケーション、および報酬システムを提供することに焦点が当てられる。プロジェクト管理は、プログラムによって調和が図られる各作業と、必要なプログラム・インフラストラクチャが確立される前に行うことのできる独立プロジェクトとに適用される。本発明による、ウェブ・サービスで構成された被ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法は、プロジェクト管理者がアプリケーションの供給を計画し、たとえば、試験のスケジューリング、コードの検討、開発者へのチケットの割当てなどを行う手段を提供する。本発明による、ウェブ・サービスで構成された被ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法は、ビジネス統合方法のグラフィカル表現をプロジェクト・チームに与えて供給リスクを減らすのを助ける。
【００７８】
従来の計画供給では、機能供給手法および機能分析段階で収集された情報に基づいて、ビジネス機能の特定のリリースの供給手法が調整される。機能リリース設計段階で、最終的な計画および推定が行われる。供給局面の後の段階における作業に関する推定が、ビジネス機能の以後のリソースに関する推定と共に修正される。機能リリース設計段階を継続することの約束が後援機関から得られる。このタスク・パッケージは、機能リリース設計段階における作業が開始される前に、各ビジネス機能リリースごとに一度実行される。本発明による、ウェブ・サービスで構成された被ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法は、プロジェクト管理者がアプリケーションの供給を計画し、たとえば、試験のスケジューリング、コードの検討、開発者へのチケットの割当てなどを行う手段を提供する。
【００７９】
従来の開発では、構築および試験が許可される。この場合、機能リリース設計段階で収集された詳細な情報に基づいて機能リリース供給手法が修正され、最終的な機能リリース構築・試験段階計画および推定が行われ、かつそれらが約束される。これらは、段階を管理するためのベースラインになる。導入段階における作業とビジネス機能の以後のリリースに関する推定を修正する必要がある。機能リリース構築・試験段階を継続することの約束を後援機関から得る必要がある。本発明による、ウェブ・サービスで構成された被ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法は、プロジェクト管理者が試験ライフサイクルの様々な段階に対するアプリケーションのリリースを自動的に許可する手段を提供する。
【００８０】
次に、導入を許可する必要がある。この場合、機能リリース構築・試験段階で収集された詳細な情報に基づいて機能リリース供給手法の残りの局面が修正され、最終的な導入段階計画および推定が行われ、かつそれらが約束される。これらは、段階を管理するためのベースラインになる。ビジネス機能の以後のリリースにおける作業に関する推定を修正する必要がある。ビジネス機能リリースの導入を継続することの約束を後援機関から得る必要がある。本発明による、ウェブ・サービスで構成された被ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法は、プロジェクト管理者がプロダクションに対するアプリケーションのリリースを自動的に許可する手段を提供する。
【００８１】
ビジネス性能モデルは、ビジネス機能要件を収集し、ビジネス性能モデルを定義し、導入要件を確立することによって修正される。これらの要件は、ビジネス機能およびそのリリースについての詳細な適用範囲定義を作成するために実施面の制約、動作面の制約、およびその他の制約を評価するための基礎を形成する。本発明による、ウェブ・サービスで構成された被ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法は、ビジネス要件に関するフロント・エンド、記憶、およびバージョン制御を行う。
【００８２】
次の段階では、供給オプションが選択される。この場合、ビジネス機能に関する様々な供給オプションが調査され、オプションの各組ごとに設計および実施に関する推薦が行われる。推薦される各オプションは、人的性能要素、ビジネス・プロセス要素、アプリケーション要素、および技術インフラストラクチャ要素が互いに対話して必要な性能レベルを満たすにはどうすべきかを記述し、オプションの各組の性能要件を明確に示し、このような要件をビジネス事例に直接関係付ける必要がある。本発明による、ウェブ・サービスで構成された被ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法は、アプリケーション導入要件に対して正しいホスティング解決策がとられるように顧客と連携する。
【００８３】
従来の開発によれば、次の段階では、パッケージされたソフトウェアが選択される。この場合、サード・パーティのパッケージ・ソフトウェアが評価され選択される。この文書に概略的に記載された活動は、ビジネス・アーキテクチャ、ビジネス機能、または個々の機能リリースのいずれかの部分として選択をサポートする。この方法内では、パッケージ・ソフトウェアの選択は3つの点、すなわち、ビジネス・アーキテクチャ段階、機能分析段階、および機能リリース設計段階でサポートされる。ビジネス・アーキテクチャ段階中に選択されるパッケージ・ソフトウェアは、ビジネス・アーキテクチャを定義するので必須のソフトウェアとみなされる。この種の選択は、選択されたパッケージ・ソフトウェアがビジネス・アーキテクチャを定義するのに必要なソフトウェアである場合に行われる。しかし、パッケージ・ソフトウェアの必要性は、特定のパッケージを選択することなしにプランニング局面中に識別することができる。この場合、ビジネス・アーキテクチャは、必要な構造および高レベル機能を識別し、次いで機能分析段階中に、パッケージ・ソフトウェアが、ビジネス・アーキテクチャ・ブループリントの制約内のビジネス機能の一部として選択される。機能リリース設計段階中に選択されるパッケージ・ソフトウェアとしては、アプリケーション要件指定デリベラブルを分析する間に識別される機能のギャップを埋めるソフトウェアが選択される。
【００８４】
本発明による、ウェブ・サービスで構成されたインタネット・ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法は、開発環境において適用範囲内の多数の異なるソフトウェア・ツールを提供する。プロジェクト・チームは、プロジェクトの技術要件がシステムによって満たされるかどうかを判定し、満たされる場合、システムは、プロジェクト・チームがこれらのアプリケーション、たとえば、開発環境、試験環境、プロダクション・サポートにアクセスできるようにする。新しい機能が必要である場合、システムはプロジェクト・チームと協働してこれらの機能をサポートすることができる。
【００８５】
人的性能インフラストラクチャの設計が従来の開発における次の段階である。この場合、組織インフラストラクチャ、性能管理インフラストラクチャ、および性能拡張インフラストラクチャが設計される。これらの設計には、後援機関内の新しい能力、役割、仕事、およびチームの定義が含まれる。人的性能インフラストラクチャは、労働力の技能の向上を管理し維持し、ビジネス・プロセスおよび結果と責任の調和を図るための基礎を確立する。本発明による、ウェブ・サービスで構成されたインタネット・ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法は、人的性能設計に関するフロントエンド、サーバ、エディタ、方法、記憶、関連するコンテント、およびバージョン制御を実現する。
【００８６】
従来の開発は、物理的環境の設計およびプランニングを伴う。このような設計およびプランニングでは、機能、レイアウト、および機器を含む物理的環境に関連する設計およびプランニングの問題が識別され解決される。物理的環境の詳細な設計および要件を確立する必要がある。環境の設計は、本発明による、ウェブ・サービスで構成されたインタネット・ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法によって提供される材料／資産によって容易になる。プロジェクト・チームはシステムと対話して要件を指定する。
【００８７】
ビジネス・プロセス、技能、およびユーザとの対話の設計が、従来の開発における次の段階である。この場合、新しいビジネス・プロセスが作成され、これらのビジネス・プロセスと労働力（技能）、アプリケーション（アプリケーションとの対話）、および物理的環境との対話が定義される。この作業によって、詳細な機能要件の基礎を形成し、人的性能とビジネス・プロセスと技術との詳細な対話を示す機能対話モデルが作成される。パッケージ・ソフトウェア解決策の場合、新しいビジネス・プロセスを定義する代わりに、パッケージ・ソフトウェアをサポートする定義済みのビジネス・プロセスを開始点として用いて、選択されたパッケージ・ソフトウェアを完全に使用できることが保証される。本発明による、ウェブ・サービスで構成されたインタネット・ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法は、ビジネス・プロセス設計に関するフロントエンド、サーバ、エディタ、方法、記憶、関連するコンテント、およびバージョン制御を実現する。
【００８８】
従来のアプリケーション設計には、カスタム・アプリケーションの分析および設計と、パッケージ・ソフトウェアのインストールおよび環境設定が含まれる。この場合、主要な設計デリベラブルが作成されると共に、アプリケーションの詳細な設計・構築・試験作業の推定を駆動するインベントリおよび推定因子が識別される。本発明による、ウェブ・サービスで構成されたインタネット・ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法は、アプリケーション設計に関するフロントエンド、サーバ、エディタ、方法、記憶、関連するコンテント、およびバージョン制御を実現する。
【００８９】
技術インフラストラクチャは、従来の開発における次の段階である。この場合、実行アーキテクチャ、開発アーキテクチャ、およびオペレーションズ・アーキテクチャを含む技術インフラストラクチャの各コンポーネントが設計され、ネットワーク、通信、およびコンピューティング・プラットフォームが設計される。この作業は、情報技術（IT）プロセスの開発および新しいインフラストラクチャをサポートするのに必要な組織の変更と調和させられる。本発明による、ウェブ・サービスで構成されたインタネット・ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法は、ホスティング実行時環境と対話するAPIを提供すると共に、このようなタスクの実行を助けるためにオペレーションズ・エンジニアのアクセスを可能にし、アプリケーションが適切に設計されるようにする。
【００９０】
次に、従来の開発ではビジネス機能リリースの妥当性が検証される。ビジネス機能の性能特性は、ビジネス性能モデル・デリベラブルと突き合わせて妥当性が検証される。この妥当性検証には、機能の各要素間の統合または「一致」の評価が含まれる。これらの試験は、機能リリース構築・試験段階で実行される。本発明による、ウェブ・サービスで構成されたインタネット・ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法は、試験材料（試験事例、試験スクリプト、および試験データ）に関するフロントエンド、試験サーバ、エディタ、方法、記憶、関連するコンテント、およびバージョン制御を実現する。
【００９１】
人的性能インフラストラクチャを構築することができる。この場合、人的性能インフラストラクチャの基本構造は、この機能に関する従業員を評価し、このような従業員に報酬を支払い、このような従業員を向上させ、かつ募集するのに必要なプログラムを開発することによって作成することができる。人的性能のこれらの主要な局面に関する方針および手順を開発することができる。人的性能インフラストラクチャの変更には、人的資源オペレーション、ツール、および組織の変更が含まれる。本発明による、ウェブ・サービスで構成されたインタネット・ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法は、これらの材料に関するフロントエンド、試験サーバ、エディタ、方法、記憶、関連するコンテント、およびバージョン制御を実現する。
【００９２】
次に、物理的環境資産およびサービスを獲得することができる。これは、ビジネス機能を働かせるうえでどの新しい機能、機器、およびサービスを獲得できるかを判定するために行われる。ベンダを選択し指名する調達方式を開発することができ、獲得計画に流動性を持たせることができ、指名された各ベンダの予想されるコストおよび結果を評価することができる。これによって、新しい機能を構築するプロセスおよび新しい機器を設置するプロセスに専門家を通じて対処しつつ、指定・獲得プロセスを管理することがサポートされる。本発明による、ウェブ・サービスで構成されたインタネット・ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法は、物理的資産を提供する。プロジェクト・チームは本システムと協働してこれらの資産の適切な要件を決定する。
【００９３】
アプリケーションおよび性能サポートを構築し試験することができる。アプリケーションを構築し試験する場合、訓練材料、媒体コンテント、およびビジネス機能によって必要とされる他の形態の性能サポートを開発することができる。アプリケーションの詳細な設計、コンポーネント試験、およびアセンブリ試験を開発することができる。さらに、指導者によって導かれる目標ベースのシナリオに従う学習材料、またはコンピュータ・ベースの学習手法を作成することができる。同様に、ビジネス方針および手順をそれに関連する性能サポート機構と共に作成することができる。本発明による、ウェブ・サービスで構成されたインタネット・ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法は、フロントエンド解決策および記憶解決策を提供してこれらの材料／アプリケーションを開発する。本システムを用いて適切な検討を容易に行うこともできる。コードおよび試験スクリプト／データのすべてのバージョンが本システムに記憶される。すべての構築／コンパイルを本システムによって実行することができる。
【００９４】
従来の開発では、技術インフラストラクチャを構築し試験する必要がある。ここで必要とされる試験パッケージは、実行アーキテクチャ、開発アーキテクチャ、およびオペレーションズ・アーキテクチャの追加機能および拡張機能を実施する。物理的ネットワークおよびコンピューティング資源は、アプリケーション・プロダクト試験の前に統一されたプロダクトとして開発し試験することができる。これらの試験には、組織の技術機能を向上させるための情報技術（IT）プロセスおよび組織の変更を含めるべきである。本発明による、ウェブ・サービスで構成されたインタネット・ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法は、技術インフラストラクチャを提供する。プロジェクト・チームは、（適切な検討／品質保証およびAPIを用いて）本システム仕様に対するチームのアプリケーションを構築し、適切な試験を行う必要がある。
【００９５】
次に、ビジネス機能リリースを試験しかつパイロット試験することができる。プロダクト・レベルおよび全体的な機能が試験され、ビジネス機能リリースの統合および動作が評価される。これらの試験ではまず、アプリケーションおよびアプリケーションと技術インフラストラクチャとの対話に、調節された試験が施される。これらの試験の後、動作環境におけるビジネス機能を評価する、ビジネス機能のパイロット試験が行われる。
【００９６】
本発明による、ウェブ・サービスで構成されたインタネット・ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法は、システムの機能を試験するのに用いられる。ホスティング・パートナーは技術インフラストラクチャ（たとえば、ステージング環境）を提供することができる。
【００９７】
最後に、ビジネス機能が導入される。これによって、新しいビジネス機能が確立され、新しい性能レベルを維持するのに必要な労働力、方針、および管理手順に移行する。この主要な活動は、新しい機能を受け入れる組織内の各導入ユニットごとに繰り返される。
【００９８】
本発明のシステムが使用される分野では、中央でのコードの検討および品質保証、供給リスクを減らすのを助ける自動ビジネス統合方法ワークフロー、リモートチームおよびチーム・メンバーの生産性の向上、すべての設計文書用の中央リポジトリの維持、プロジェクトの長所の調和、環境管理およびコード移行の中央化／自動化によって連続的な効率を期待することができる。
【００９９】
本発明のシステムおよび方法の実行アーキテクチャに関して、アプリケーションとオペレーティング・システムとデータベースとの間のインタフェースでは、顧客と管理されるサービス・プロバイダとの間で従来の責任の記述が行われる。高レベルのサービス（たとえば、可用性100%）を提供するには、アプリケーション・インフラストラクチャ・プロバイダのプロダクション監視システムおよびBSS/OSSと密に統合された適切に書かれたアプリケーションを有することが重要である。図9に示されているように、本発明によるシステムおよび方法は、アプリケーション・インフラストラクチャ・プロバイダ監視システムに対してプラグ・アンド・プレイ機能を実行するアプリケーション開発者標準APIを提供する。新しい開発環境は、アプリケーション・アーキテクチャがアプリケーションの端末間管理可能性を高めるのに使用する実行アーキテクチャAPIを供給する。
【０１００】
図10は、本発明による仮想ソフトウェア開発環境を示すブロック図である。ここで、フロントエンド要素、ウェブ・ブラウザ、eメール、およびPDAはすべて、インタネットを介してウェブ・サービスに接続されている。ウェブ・サーバは、顧客データベースに接続された開発サーバ、試験サーバ、およびプロジェクト管理サーバに接続されている。被ホスティング開発環境188である仮想ソフトウェア開発環境は、すべての前述のサーバと顧客データベースを含んでいる。
【０１０１】
図11および12はそれぞれ、ホスティング・システム・コンポーネントおよびASP186システム・コンポーネントを示している。図13は、環境開発全体にわたってコンポーネントに対する責任がどのように共有されるかを示すブロック図である。システム・インテグレータとホスティング・プロバイダ194は、設計局面、開発局面、試験局面、およびステージング局面中にサービス・レベルの責任を共有する。ホスティング・プロバイダは、プロダクション局面で全責任を負う。開発段階中には、アプリケーション、API、およびホスティング実行時に対する責任が、ホスティング・プロバイダとシステム・インテグレータの両方で共有される。試験中には、アプリケーション、API、イベント・シミュレータ、およびエンド・ユーザ試験に対する責任がホスティング・プロバイダとシステム・インテグレータによって共有される。同様に、ホスティング・プロバイダとシステム・インテグレータは、ステージング中にアプリケーション、API、実行時環境、およびエンド・ユーザ試験に対する責任を共有する。アプリケーション、実行時API、ホスティング環境、および実際のユーザは、プロダクション中のホスティング・プロバイダの唯一の責任である。
【０１０２】
一般に、本発明のシステムおよび方法は、クライアントが、インタネットによってホスティングされるサービス・ベースのビジネス・アプリケーションが必要であることを明らかにした後、質問に答え、必要な機能の記録を作成するように動作する。次に、環境に関する推薦を行うために、環境の基本となるビジネス事例またはモデル、システム定義、ユーザ要件、機能要件、技術要件、使用事例、様々なコンポーネント、ユーザ・インタフェース、動作シーケンス、分類、およびデータ設計モデルが決定される。このような推薦には、環境で使用されるアプリケーションの提案が含まれる。アプリケーションを最初から開発する必要がある場合、このようなアプリケーションは、将来の環境の開発用に再び使用できるようにデータ・ライブラリに記憶され、それによって、以後の環境を開発するのに必要な作業量が潜在的に少なくなる。
【０１０３】
次に、本発明による、ウェブ・サービスで構成されたインタネット・ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法、ならびにそのような環境で使用されるソフトウェアについて、図14〜21に示されているフローチャートを参照して説明する。
【０１０４】
図14a〜14lは、本発明による、ウェブ・サービスで構成されたインタネット・ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法による、環境要件の設計プロセスおよび開発を示すフローチャートである。図14aに示されている段階200で、ユーザは要件・設計ツールを開始する。ユーザは次いで、段階202でビジネス事例ツールを開く。段階204で、ビジネス事例が完全であるかどうかが判定される。ビジネス事例が完全である場合、ユーザは、図14bに示されている段階206でシステム定義ツールを開く。
【０１０５】
段階204の答えがNOである場合、ユーザは段階208でビジネス事例を作成または編集し、段階210でビジネス事例を保存する。段階212で、ビジネス事例がバージョン化され、XMLとして保存される。次に段階214で、ユーザは、検討すべきビジネス事例を送信する。段階216で、検討者が自動的にメッセージを要件・設計マネージャに送信し、このメッセージを段階218で要件・設計マネージャが受信する。ビジネス事例作成者は次いで、段階220で、必要とされる承認または追加の編集の通知を受信する。段階222で、ビジネス事例が承認されるかどうかが判定される。YESの場合、ユーザは、図14bに示されている段階206でシステム定義ツールを開く。NOの場合、システムは段階208に戻る。
【０１０６】
段階206の後で、システム定義が完全であり、段階224で承認されるかどうかが判定される。YESの場合、ユーザは、図14cに示されている段階226で要件ツールを開く。NOの場合、ユーザは、段階228でシステム定義を作成し編集し、この定義は、段階230で保存され、さらに、段階232で、バージョン化されデータ・リポジトリにXMLとして保存される。ユーザは次いで段階234で、検討すべきシステム定義を送信する。検討者は、段階236で自動的にメッセージを要件・設計マネージャに送信し、このメッセージを段階238で要件・設計マネージャが受信する。システム定義作成者は次いで、段階240で、必要とされる承認または追加の編集の通知を受信する。段階242で、システム定義が承認されるかどうかが判定される。YESの場合、ユーザは、図14cに示されている段階226でシステム定義ツールを開く。NOの場合、システムは段階228に戻る。
【０１０７】
ユーザが段階226でユーザ要件ツールを開くと、段階244で、ユーザ要件が完全であるかどうかが判定される。YESの場合、ユーザは、図14dに示されている段階246で機能要件ツールを開く。ユーザ要件が完全である場合、段階248で、クライアント回答注意事項が利用可能であるかどうかが判定される。クライアント回答注意事項が利用可能である場合、ユーザは段階250でそれを開き参照する。ユーザは次いで段階252で、ユーザ要件を作成または編集することができる。段階248でクライアント回答注意事項が利用可能でない場合、段階250を飛ばして段階252が実行される。次に、ユーザは段階254で要件を保存し、段階256でユーザ要件がバージョン化され文書リポジトリにXMLで保存される。ユーザは次いで段階258で、検討すべきユーザ要件を送信する。検討者は、段階260で自動的にメッセージを要件・設計マネージャに送信し、このメッセージを段階262で要件・設計マネージャが受信する。ユーザ要件作成者は次いで、段階264で、必要とされる承認または追加の編集の通知を受信する。段階266で、ユーザ要件を承認すべきかどうかが判定される。YESの場合、ユーザは、図14dに示されている段階246で機能要件ツールを開く。NOの場合、システムは段階248に戻る。
【０１０８】
段階246の後、段階267で、機能要件が完全であり承認されるかどうかが判定される。そうである場合、ユーザは、図14eに示されている段階268で技術要件ツールを開く。機能要件が完全ではなく承認されない場合、段階270で、ユーザ要件が利用可能であるかどうかが判定される。ユーザ要件が利用可能である場合、ユーザは段階272でそれを開き参照する。ユーザは次いで段階274で、機能要件を作成または編集することができる。段階270でユーザ要件注意事項が利用可能でない場合、段階272を飛ばして段階274が実行される。次に、ユーザは段階276で機能要件を保存し、段階278で機能要件がバージョン化され文書リポジトリにXMLで保存される。ユーザは次いで段階280で、検討すべきユーザ要件を送信する。検討者は、段階282で自動的にメッセージを要件・設計マネージャに送信し、このメッセージを段階284で要件・設計マネージャが受信する。機能要件作成者は次いで、段階286で、必要とされる承認または追加の編集の通知を受信する。段階288で、機能要件を承認すべきかどうかが判定される。YESの場合、ユーザは、図14eに示されている段階268で技術要件ツールを開く。NOの場合、システムは段階270に戻る。
【０１０９】
図14eにおいて、段階268の後、段階290で、技術要件が完全であり承認されるかどうかが判定される。そうである場合、ユーザは、図14fに示されている段階292で使用事例要件ツールを開く。機能要件が完全ではなく承認されない場合、段階294で、機能要件が利用可能であるかどうかが判定される。機能要件が利用可能である場合、ユーザは段階296でそれを開き参照する。ユーザは次いで段階298で、技術要件を作成または編集することができる。段階294で機能要件が利用可能でない場合、段階296を飛ばして段階298が実行される。次に、ユーザは段階300で技術要件を保存し、段階302で技術要件がバージョン化されXMLで保存される。ユーザは次いで段階304で、検討すべきユーザ要件を送信する。検討者は、段階306で自動的にメッセージを要件・設計マネージャに送信し、このメッセージを段階308で要件・設計マネージャが受信する。技術要件作成者は次いで、段階310で、必要とされる承認または追加の編集の通知を受信する。段階312で、技術要件を承認すべきかどうかが判定される。YESの場合、ユーザは、図14fに示されている段階292で使用事例ツールを開く。NOの場合、システムは段階294に戻る。
【０１１０】
ユーザが、図14fに示されている段階292で使用事例ツールを開いた後、段階316で、使用事例が承認されるかどうかが判定される。使用事例が承認された場合、ユーザは、図14gに示されている段階318でコンポーネント・ツールを開く。段階316で使用事例が承認されない場合、ユーザは、段階320で使用事例を作成または編集し、段階322でその使用事例を保存する。段階324で、使用事例はバージョン化され文書リポジトリにXMLで保存される。次に、ユーザは段階326で、検討すべき使用事例を送信する。段階328で、検討者が自動的にメッセージを要件・設計マネージャに送信し、このメッセージを段階330で要件・設計マネージャが受信する。使用事例作成者は次いで、段階332で、必要とされる承認または追加の編集の通知を受信する。段階334で、使用事例が承認されるかどうかが判定される。YESの場合、ユーザは、図14gに示されている段階318でコンポーネント・ツールを開く。NOの場合、システムは段階320に戻る。
【０１１１】
図14gに示されている段階320でコンポーネント・ツールを開いた後、段階338で、各コンポーネントが承認されるかどうかが判定される。各コンポーネントが承認される場合、ユーザは、図14hに示されている段階340でユーザ・インタフェース・ツールを開く。段階338で各コンポーネントが承認されない場合、ユーザは、段階342で各コンポーネントを作成または編集し、段階344で各コンポーネントを保存する。段階346で、各コンポーネントはバージョン化され文書リポジトリにXMLで保存される。次に、ユーザは段階348で、検討すべき使用事例を送信する。段階350で、検討者が自動的にメッセージを要件・設計マネージャに送信し、このメッセージを段階352で要件・設計マネージャが受信する。コンポーネント作成者は次いで、段階354で、必要とされる承認または追加の編集の通知を受信する。段階356で、各コンポーネントが承認されるかどうかが判定される。YESの場合、ユーザは、図14hに示されている段階360ユーザ・インタフェース・ツールを開く。NOの場合、システムは段階342に戻る。
【０１１２】
次に、図14hに示されているように、ユーザが、段階340でユーザ・インタフェース・ツールを開いた後、段階358で、ユーザ・インタフェース設計が承認されるかどうかが判定される。ユーザ・インタフェース設計が承認される場合、ユーザは、図14iに示されている段階360でシーケンス図ツールを開く。段階358でユーザ・インタフェース設計が承認されない場合、ユーザは、段階362でユーザ・インタフェース設計を作成または編集し、段階364でそのユーザ・インタフェース設計を保存する。段階366で、ユーザ・インタフェース設計はバージョン化され文書リポジトリにXMLで保存される。次に、ユーザは段階368で、検討すべきユーザ・インタフェース設計を送信する。段階370で、検討者が自動的にメッセージを要件・設計マネージャに送信し、このメッセージを段階372で要件・設計マネージャが受信する。ユーザ・インタフェース作成者は次いで、段階374で、必要とされる承認または追加の編集の通知を受信する。段階376で、ユーザ・インタフェース設計が承認されるかどうかが判定される。YESの場合、ユーザは、図14iに示されている段階360でシーケンス図ツールを開く。NOの場合、システムは段階362に戻る。
【０１１３】
図14iに戻ると分かるように、ユーザが、段階364でシーケンス図ツールを開いた後、段階378で、シーケンス図が承認されるかどうかが判定される。シーケンス図が承認される場合、ユーザは、図14jに示されている段階380でクラス図ツールを開く。段階378でシーケンス図が承認されない場合、ユーザは、段階382でシーケンス図を作成または編集し、段階384で各シーケンス図を保存する。段階386で、シーケンス図はバージョン化され文書リポジトリにXMLで保存される。次に、ユーザは段階388で、検討すべきシーケンス図を送信する。段階390で、検討者が自動的にメッセージを要件・設計マネージャに送信し、このメッセージを段階392で要件・設計マネージャが受信する。シーケンス図作成者は次いで、段階394で、必要とされる承認または追加の編集の通知を受信する。段階396で、シーケンス図が承認されるかどうかが判定される。YESの場合、ユーザは、図14jに示されている段階380でクラス図ツールを開く。NOの場合、システムは段階382に戻る。
【０１１４】
ユーザが、段階380でクラス図ツールを開いた後、段階398で、クラス図が承認されるかどうかが判定される。クラス図が承認される場合、ユーザは、図14kに示されている段階400でデータ設計モデル・ツールを開く。段階398でクラス図が承認されない場合、ユーザは、段階402でクラス図を作成または編集し、段階404で各クラス図を保存する。段階406で、クラス図はバージョン化され文書リポジトリにXMLで保存される。次に、ユーザは段階408で、検討すべきクラス図を送信する。段階410で、検討者が自動的にメッセージを要件・設計マネージャに送信し、このメッセージを段階412で要件・設計マネージャが受信する。クラス図作成者は次いで、段階414で、必要とされる承認または追加の編集の通知を受信する。段階416で、クラス図が承認されるかどうかが判定される。YESの場合、ユーザは、図14kに示されている段階400でデータ設計モデル・ツールを開く。NOの場合、システムは段階402に戻る。
【０１１５】
次に、図14kに示されているように、ユーザが、段階400でデータ設計モデル・ツールを開いた後、段階418で、設計モデルが承認されるかどうかが判定される。クラス図が承認される場合、ユーザは、図14lに示されている段階420で推薦ツール・ページを開く。段階418で設計モデルが承認されない場合、ユーザは、段階422で設計モデルを作成または編集し、段階424でその設計モデルを保存する。段階426で、設計モデルはバージョン化され文書リポジトリにXMLで保存される。次に、ユーザは段階428で、検討すべきデータ設計モデルを送信する。段階430で、検討者が自動的にメッセージを要件・設計マネージャに送信し、このメッセージを段階432で要件・設計マネージャが受信する。データ設計モデル作成者は次いで、段階434で、必要とされる承認または追加の編集の通知を受信する。段階436で、データ設計モデルが承認されるかどうかが判定される。YESの場合、ユーザは、図14lに示されている段階420で推薦ツール・ページを開く。NOの場合、システムは段階422に戻る。
【０１１６】
段階420で推薦ツール・ページが開かれた後、段階438で、要件から収集されたメタデータおよびプロジェクトに関して収集された設計情報が受信される。段階440で、使用度に関して選択することのできるアプリケーションに関連するメタデータが検索される。段階442で、要件・設計ツールは、使用度に関して提供される要件・設計メタデータ・アプリケーションにおいてユーザから供給される情報に関連するメタデータを比較する。段階444で、メタデータの比較に基づいて、プロジェクトの要件に最も適したアプリケーションが推薦されるアプリケーションとして表示される。段階446で、比較の統計結果が、推薦されるアプリケーションの記述と共に表示され、段階448で、要件・設計ツールが閉じられる。
【０１１７】
図14a〜14lでは、ユーザ、管理者、検討者、および作成者を広く拡張し、すべての通信をインタネット上で行うことができる。前述の個人のうちの幾人かまたはすべてが中央のインタネット・サイトを通じて通信し対話することができる。
【０１１８】
ウェブ・サービスからアプリケーションを構築するプロセスが図15a〜15cのフローチャートに示されている。まず、図15aに示されている段階460で、ユーザが要件ツールを開始し、次いで段階462で、機能要件にアクセスする。段階464で機能要件を編集することができ、その後段階466で、ユーザは機能要件に関する一連の記述子にチェックする。次いで段階468で、機能要件が完全であるかどうかが判定される。機能要件が完全でない場合、ユーザは段階462に戻る。一方、段階468で機能要件が完全であると判定された場合、ユーザは段階470でこの要件を保存する。段階472で、機能要件がバージョン化され文書リポジトリにXMLで保存され、かつ記述子に関連するメタデータが保存される。
【０１１９】
次に段階474で、ユーザは設計ツールを開始する。段階476で、アプリケーションのコンポーネントに関連するあらゆるメタデータ・タグがメタデータ・リポジトリから検索される。設計ツールは次いで、段階478で、すでに図14a〜14lに関して説明したプロセスですでに指定されている要件、コンポーネント、および使用事例記述子に関連するタグを含むメタデータを検索する。
【０１２０】
図15bに示されている段階480で、設計ツール・エンジンは、作成すべきアプリケーションのコンポーネントおよびウェブ・サービスを表すステンシルを生成する。次に段階482で、ユーザはウェブ・サービス・ステンシルおよびコンポーネント・ステンシルをアプリケーション設計キャンバス上にドラッグ・アンド・ドロップし、アプリケーションのコンポーネントおよびウェブ・サービスを表すことができる。次いで段階484で、ユーザは、ウェブ・サービス・ステンシルをクリックすることによってウェブ・サービスに関する詳細を入力することができる。段階486で指摘したように、図示の例では、ユーザがウェブ・サービスを有するアプリケーションを構築しているため、すべてのステンシルはウェブ・サービスである。
【０１２１】
段階488で、サービスがスタチックであるかどうかが判定される。サービスがスタチックである場合、ユーザは、段階490で、どのウェブ・サービスURL、すなわちユニフォーム・リソース・ロケータ（Uniform Resource Locator）および方法を呼び出すべきかを指定する。サービスがスタチックではないと判定された場合、ユーザは、段階492で、ユーザが呼び出したいサービスの種類に関する詳細を入力し、その後段階494で、アプリケーションが実行された場合に、呼び出すべきサービスの選択をダイナミックにするための追加の詳細を入力する。たとえば、ユーザは、指定された要件を満たす最も廉価なサービスを選択することを指定することができる。
【０１２２】
段階490と段階494のどちらの場合でも、その後に段階496が実行され、ユーザはウェブ・サービスの対話をマップする。次に、ユーザは、段階498で各サービスの入力および出力をマップし、段階500で設計を完成する。段階501で、ユーザは設計を保存し、段階502で、設計はバージョン化され文書リポジトリにXMLで保存される。
【０１２３】
ユーザは、作成された設計のコードを生成する場合に、段階504で、コード・エンジンに段階506で設計中の各ウェブ・サービスに関するURL情報およびWSDL情報を探索させるボタンをクリックすることができる。WSDLは、ウェブ・サービス記述言語（Web Services Description Laguage）の略であり、ある企業から提供されるサービスを記述し、個人および他の企業がこのようなサービスに電子的にアクセス方法を提供するのに用いられるXMLベースの言語である。段階508で、情報がウェブ・サービス・リポジトリから検索される。段階510で、コード・エンジンがアプリケーションのすべてのコンポーネントを生成し、次いで段階512で、1連のコンポーネントが文書リポジトリに保存される。段階512が完了した後、ユーザは、段階514で、生成されたコードの位置を通知され、したがって、ウェブ・サービスからアプリケーションを構築するプロセスが完了する。
【０１２４】
次に、段階492および494で参照されたウェブ・サービスを呼び出すプロセスについて図16を参照して説明する。このプロセスではまず、段階516でユーザがアプリケーションを開始する。段階518で、アプリケーションがウェブ・サービスを呼び出すかどうかが判定される。YESの場合、段階520で、ウェブ・サービスの試験バージョンが利用可能であるかどうかが判定される。試験バージョンが利用可能である場合、段階522で、ルータが試験シミュレータURLを呼び出し、入力をシミュレータに転送する。シミュレータは、段階524で入力を受け入れ、段階526で、プロファイル、ウェブ・サービス名、方法、および入力に基づいて試験データ・リポジトリが探索される。段階527で出力が返され、段階528で出力がシミュレータからアプリケーションに転送される。この点で、アプリケーションは、段階530で入力を受け入れ実行を開始し、段階532で終了する。
【０１２５】
段階520の結果として、ウェブ・サービスの試験バージョンが存在しない場合、段階534で、セキュリティによってプロファイルが検討され、このウェブ・サービスを呼び出すことが許可されているかどうかが判定され、段階536で、セキュリティが許可されているかどうかが判定される。セキュリティが許可されていない場合、段階538で、アプリケーションが割り込まれ、メッセージ・エラーを出して終了する。
【０１２６】
セキュリティが許可されている場合、段階540でロギング・コンポーネントがこのウェブ・サービスの呼出しを記録する。段階542で、課金コンポーネントが、ウェブ・サービスへの呼出しについて、適用可能なプロジェクトに課金する。段階544で、入力を含むシングル・オブジェクト・プロトコール（SOAP）呼出しがウェブ・サービスに対して行われる。段階546で、ウェブ・サービスは入力を処理し、SOAPを介して出力を返す。段階546中に課金が行われ、その場合、段階540で課金が記録される。段階546の後、アプリケーションは、段階530で入力を受け入れ実行を開始し、次いで段階532で終了する。段階546で、課金コンポーネントは、ウェブ・サービスの呼出しについてプロジェクトに課金することができる。
【０１２７】
ウェブ・サービス・プロセス・フローを試験するプロセスが図17に示されている。プロセスは、段階550で、ユーザが開発ツールから試験ツールを開始した場合に始まる。ユーザは次いで段階552で、WSDLソースURLを入力し、段階554でXML文書が解析される。段階556で、サービスの入力および方法が判定され、段階558で、試験ツールが方法名および入力を受信する。ユーザは次いで段階560で、試験すべき方法を選択し、入力を行う。ユーザは段階562で、サービスに対するヒット数のような追加のオプションを選択し、試験を実行する。段階563でウェブ・サービス試験が開始され、その後段階564で、入力を含むSOAP呼出しがウェブ・サービスに転送される。ウェブ・サービスは、段階566で入力が処理され、SOAPを介して出力を返す。段階568で、出力がウェブ・サービス試験ツールによって受信され、段階570でウェブ・サービス試験が完了する。
【０１２８】
図18は、シミュレータ試験データを挿入するプロセスを示すフローチャートである。段階572で、ユーザが、ビルダ184を開始することによってプロセスを始める。次にユーザは、段階574で所望のウェブ・サービスを見つけ、段階576で新しい試験データを挿入する。段階578で、URLおよびユーザの名前を用いて、ウェブ・サービス試験シミュレータ試験データ・リポジトリが探索され、既存の試験データが見付けられる。段階580で、データはXMLとしてビルダ184に転送され、ビルダ184は段階582で、XMLを解析し適切なフォーマットに変換する。段階584で、ビルダ184はあらゆる既存のデータをテーブル内に表示する。利用可能なデータがない場合、空白のテーブルが表示される。ユーザは、段階586で試験データを編集するかまたはテーブルに追加することを選択し、段階588でデータを保存する。データは、段階590でウェブ・サービス・シミュレータ・リポジトリにXMLとして保存される。
【０１２９】
ウェブ・サービスを挿入するプロセスは、図19a〜19cに示されたフローチャートに示されている。プロセスは、段階592で、ユーザが要件・設計ツールを開始した場合に始まる。次いで段階594で、ユーザは設計ツール内でデータ図を開く。段階596で、ユーザは各コンポーネントをコードに関係付ける詳細を表示する。段階598で、要件・設計一般スケルトン・コードが生成され、その後段階600で、統合開発環境（IDE）が自動的に開始される。スケルトン・コードは段階602でIDEに表示される。段階604で、スケルトン・コードを維持するかどうかが判定される。スケルトン・コードを維持しない場合、プロセスは、図19bに示されている段階606に進み、開発ツールが閉じられる。
【０１３０】
段階604における決定がスケルトン・コードを維持することである場合、段階608で、ユーザがコンポーネントをコード化して保存し、それぞれ段階610および612で、コードが文書リポジトリにXMLとして保存され、バージョン化される。段階614で、コードをコンパイルすべきかどうかが判定される。コードをコンパイルすべきであると段階614で判定された場合、段階616で、コードがIDE作業空間に書き込まれコンパイルされ、図19bに示されている段階618で、IDEに返される。IDEは段階620で出力を受信して表示し、その後段階622で、ウェブ・サービスを挿入すべきかどうかが判定される。コードをコンパイルすべきでないと段階614で判定された場合、プロセスは段階622に進む。
【０１３１】
ウェブ・サービスを挿入すべきでないと段階622で判定された場合、段階606で開発ツールが閉じられる。一方、ウェブ・サービスを挿入すべきであると段階622で判定された場合、段階624でビルダ184が開始され、段階626で、ブックマークが存在するかどうかが判定される。ブックマークが存在する場合、段階628で、ブックマークのメタデータがウェブ・サービスのメタデータが一致させられる。段階630で、推薦されるサービスが表示される。次に段階632で、ユーザがウェブ・サービスを選択し、方法を選択する。段階626で、ブックマークは存在しないと判定された場合、プロセスは段階634に進み、すべてのウェブ・サービスが表示される。段階634から、段階632で、ユーザはウェブ・サービスを選択し方法を選択することができる。段階636で、ユーザは試験バージョンまたはプロダクション・バージョンを挿入することを選択する。
【０１３２】
図19cに示されているように、段階638で、このウェブ・サービスに呼出しを挿入することが承認されているかどうかが判定される。呼出しを挿入すべきでないと段階638で判定された場合、段階640で、このサービスの挿入の承認を要求するメッセージが検討者に送信される。段階642で、検討者は、このウェブ・サービスを承認するかどうかを判定する。検討者がこの段階642で、ウェブ・サービスを承認しない場合、段階644で、このウェブ・サービスの使用を拒否するメッセージが開発者に送信される。一方、検討者が段階642でウェブ・サービスを承認した場合、段階646で、課金コンポーネントおよびロギング・コンポーネントが、選択されたウェブ・サービスに将来課金できるように現在のプロジェクトをセットアップする。同様に、段階638で、ビルダがこのウェブ・サービスの呼出しの挿入を承認した場合、プロセスは段階646に進む。
【０１３３】
段階648で、このウェブ・サービスの挿入がログされ、プロジェクト口座に対して課金され、段階650で、ビルダが、呼び出されたウェブ・サービスにコードをプロダクション・フラグの試験と共に転送する。最後に段階652で、このウェブ・サービスがフラグと共にコードに挿入される。
【０１３４】
ウェブ・サービスをウェブ・サービス・リポジトリに追加するには、ウェブ・サービスを証明しなければならない。このような証明を行うプロセスが図20a〜20dに示されている。このプロセスは、ユーザが段階654でビルダ184を開始し、段階656で新しいサービスを証明するオプションを選択した場合に始まる。ユーザは次いで段階658で、ウェブ・サービスUPL、WSDL URL、入力に対する応答の種類、有効な入力値、方法の記述、およびサンプル統合コードを入力する。段階660で、この情報がウェブ・サービス・リポジトリにXMLとして保存される。段階658の後で、ユーザは段階662で、ビルダ184からサービス・レーベル合意（SLA）を選択する。SLAは段階664で、ウェブ・サービス・リポジトリにXMLとして記憶される。段階666で、ホスト・サイトでこのウェブ・サービスをホスティングすべきかどうかが判定される。段階666での判定がYESである場合、段階668で、ユーザはこのウェブ・サービスをアップロードし、段階670で、コードがウェブ・サービス・リポジトリにXMLとして保存される。段階670の後、段階672で、別個の試験プロダクションURLが必要であるかどうかが判定される。この判定がNOである場合、段階666の後にも段階672が実行される。
【０１３５】
段階672で別個の試験プロダクションURLが必要である場合、段階674で、ユーザはこの試験プロダクションウェブ・サービスのURLを入力し、段階676で、試験データが試験シミュレータ・リポジトリにデフォルト・データとして記憶される。別個の試験プロダクションURLは不要であると段階672で判定された場合、段階678で入力パラメータのフラグが立てられる。段階676と段階678のどちらの場合でもその後に、図20bに示されている段階680が実行され、まもなく証明に関する通知が与えられることが、ビルダ184からユーザに通知される。次いで段階684で、検討者が、証明を求める新しい要求の通知を自動的に送信し、この通知が段階686で、共同作業を介してウェブ証明管理者によって受信される。次に、ウェブ・サービス試験者が、段階688でサービスを探索し、次いで段階690で情報および試験データを表示する。
【０１３６】
段階692で、ユーザは試験管理を開始し、段階694で試験条件およびスクリプトを書き込む。スクリプトは、段階696で保存され、段階698で文書リポジトリにXMLとして記憶される。段階700で、試験者が検討すべきスクリプトを送信し、段階702で、検討者が、スクリプトに関するメッセージを試験チーム・リーダに自動的に送信する。チーム・リーダは段階704で、検討すべきスクリプトおよび試験注意事項の通知を受信し、検討者は段階706で、検討の結果を試験者に自動的に送信する。段階708で、スクリプトを承認すべきかどうかが判定される。スクリプトが承認されない場合、段階710で、試験者はこのスクリプトに必要な変更の通知を受信し、プロセスは段階694に戻る。段階708でスクリプトが承認された場合、検討者は段階712で、承認の通知を試験者に自動的に送信し、試験者は、図20cの段階714で、ホストIDE内のウェブ・サービス試験ツールを開始する。
【０１３７】
次に、試験者は、段階716で試験管理ツールを開始し、段階718でウェブ・サービス用の試験スクリプトを開くことを選択する。段階720で、ウェブ・サービス・リポジトリがファイルを探索し、段階722で、試験スクリプトがXMLとして保存され、試験スクリプト作成ツールにおいて解析され表示される。試験者は次いで段階724で、スクローリング・ツールに試験スクリプトを表示し、段階726で試験すべきウェブ・サービスを選択する。段階728で、試験者は、スクローリング・ツールを用いて試験スクリプトに次の段階を表示する。段階730で、スクリプトが完全かどうか決定する。スクリプトが完全でない場合、段階732が実行され、試験者は、試験中のその段階を終了するのに必要な段階を実行する。段階730で、スクリプトが完全であると判定された場合、図20dに示されている段階734で試験スクリプトが保存される。スクリプトは、段階736で文書リポジトリにXMLとして保存され、段階738で、試験が完全であるかどうかが判定される。段階738の結果として、試験が完全ではない場合、プロセスは、図20cに示されている段階718に戻る。
【０１３８】
段階738の結果として、試験が完全である場合、プロセスは段階740に進み、試験者はこのウェブ・サービスの証明を承認または拒否する。段階742で、このウェブ・サービスが承認されるかどうかが判定される。承認されない場合、段階744で、検討者は、試験の結果と、証明に必要となる可能性のあるあらゆる修正とを含むメッセージを、試験者、ウェブ・サービス管理者、およびこのウェブ・サービスの作成者に送信する。次いで段階746で、このウェブ・サービスが「未証明」であることを示すフラグがウェブ・サービス・リポジトリ内に立てられる。
【０１３９】
段階742での判定の結果として、このウェブ・サービスが承認された場合、段階748で、検討者は、このウェブ・サービスが証明された旨のメッセージを試験者、ウェブ・サービス管理者、およびこのウェブ・サービスの作成者に送信し、次いで段階750で、このウェブ・サービスが「証明済み」であることを示すフラグがウェブ・サービス・リポジトリ内に立てられ、証明プロセスが完了する。
【０１４０】
次に、図21a〜21fに示されているフローチャートを参照してインスタンシエータ182の動作について説明する。図21aに示されている点751からインスタンシエータ・プロセスが開始される。インスタンシエータ・プロセスが開始する1つの場合は、段階752で課金システムから切断要求が受信され、その結果段階754で、ホスティング会社が、環境へのアクセスを取り消すという通知を受けた場合である。次に、顧客は段階756で、アクセスが取り消されており、口座が適切な状態に戻った場合に復元されることを通知される。次いで、インスタンシエータ・プロセスは点758で終了する。
【０１４１】
インスタンシエータ・プロセスは、段階760で環境ユーザ・インタフェースから環境要求が受信された場合に開始する。段階762で、要求の種類が判定される。要求が新しい環境を求めるか、または環境の更新を求める要求である場合、プロセスは段階764に進み、インスタンシエータは環境から入力パラメータを取り出し、要求を環境設定チームにルーティングする。環境設定チームは、段階766で、顧客のソフトウェア選択が適切であること、すなわち、すべてのソフトウェア依存性が妥当であることを検証する。環境設定チームは、次いで段階768で、要求が新しい環境を求める要求であるか、それとも環境の更新を求める要求であるかを判定する。
【０１４２】
要求が環境の更新を求める要求である場合、プロセスは、接続C-Cを介して図21fの段階770に進み、環境設定チームは、ソフトウェアの選択およびユーザの数に基づいて現在の環境に追加のハードウェアが必要であるかどうかを判定する。次いで段階772で、追加のハードウェアが必要であるかどうかが判定される。必要である場合、環境設定チームは、段階774で、そのハードウェアが既存の環境とどのように統合されるかを判定し、プロセスは、接続H-Hを介して図21aの段階776に進む。段階774で追加のハードウェアが必要ではない場合、プロセスは図20aの段階778に進む。
【０１４３】
要求が新しい環境を求める要求である場合、環境設定チームは、段階780で、環境の種類、ソフトウェアの選択、およびユーザの数に基づいて、適切なハードウェア環境設定が存在するかどうかを判定する。次に段階776で、在庫管理チームが環境設定チームからの要求を受信する。段階782で、利用可能な在庫が検査され、段階784で、在庫が利用可能であるかどうかが判定される。在庫が利用可能ではない場合、インスタンシエータは段階786で、オペレーションズ・チームに通知する。在庫が利用可能である場合、段階788で、在庫を保持し在庫IDを追跡するように在庫ステータスが更新される。
【０１４４】
段階790で、残りの在庫が算出され、段階792で、在庫レベルが比較され、事前に設定されたしきい値よりも低いかどうかが判定される。在庫レベルが、事前に設定されたしきい値よりも低い場合、段階794でオペレーションズ・チームが通知を受け、インスタンシエータは点758でプロセスを終了する。
【０１４５】
段階788の後、段階778で、ソフトウェア・ライセンスが利用可能であるかどうかが検査される。次に段階796で、要求全体を実現できるかどうかが判定される。要求全体を実現できない場合、2つの段階が実行される。まず段階798で、オペレーションズ・チームが通知を受け、その後段階778が繰り返される。第2に段階800で、ライセンスIDを保持し追跡するように必要なライセンス・ステータスが更新される。要求全体を実現できる場合、段階802でライセンスIDSを保持し追跡するように、必要なライセンスステータスが更新される。
【０１４６】
段階800と段階802のどちらの場合も、その後に、接続E-Eを介して、図21bに示されている段階804が実行される。段階804で、プロダクトからソフトウェア・コンポーネントが呼び出され、サーバおよびホスティング・センターに関する情報が転送される。次に段階806で、要求されたソフトウェア・コンポーネントに対してインストール機構が起動される。次いで段階808で、ホスティング・センター内のプロダクト機構が新しいサーバまたは既存のサーバ上にこのソフトウェアをインストールし環境設定する。段階810で、インストールが成功したかどうかが判定される。成功しなかった場合、段階812で、オペレーションズ・チームが通知を受け、顧客、サーバ、ホスティング・センター、および失敗したソフトウェアに関する情報がオペレーションズ・チームに与えられる。
【０１４７】
段階810でソフトウェアのインストールが成功した場合、段階814でディレクトリ機構が構築され、許可がセットアップされる。段階816で、ソフトウェア・アプリケーションが作成される。次に段階818で、すべてのソフトウェア・コンポーネントがインストールされているかどうかが判定される。インストールされていない場合、プロセスは段階804に戻る。インストールされている場合、段階819で環境が新しい環境であるかどうかが判定される。新しい環境である場合、段階820で、システム・ユーザが作成され、段階822で、バージョン制御ツールが環境設定され、アクセスが可能になる。段階824で、ロギング・ツールが環境設定され、アクセスが可能になる。段階824の後、または段階819で環境が新しい環境ではないと判定された場合、プロセスは、接続F-Fを介して図21cの段階826に進む。
【０１４８】
段階826で、新しい／修正された環境のセットアップに関する情報を含むリードミー・ファイルが生成される。段階828で、環境の準備が完了したことが顧客に通知され、顧客にリードミー・ファイルが送信される。段階830で、課金システムが、顧客の新しい／修正された環境に関する通知を受ける。次に段階832で、在庫が使用中であることを示すように、在庫IDを用いて必要な在庫ステータスが更新される。さらに段階834で、ライセンスが使用中であることを示すように、在庫IDを用いて必要なソフトウェア・ライセンスが更新される。段階836で、顧客と資産との関連が更新される。
【０１４９】
段階838で、中断中の項目があるかどうかが判定される。中断中の項目がない場合、段階840で、コードを移行するべきかどうかが判定される。中断中の項目がある場合、段階842で、オペレーションズ・チームが通知を受け、インスタンシエータ・プロセスは点844で終了する。
【０１５０】
段階840の結果として、コードを移行しない場合、段階846であらゆる一時ファイルが削除され、段階848で、環境が供給されることが顧客に通知され、その後インスタンシエータ・プロセスは点844で終了する。段階840でコードを移行すべきである場合、プロセスは、接続G-Gを介して図21dの段階850に進む。
【０１５１】
段階850で、コード・リリースが移行され、段階852でユーザ・インタフェースから移行要求が受信された後、段階所与のリリースに必要なファイルのバージョンが取り込まれる。段階854で、ファイルは論理的に各コンポーネントとしてグループ分けされる。たとえば、SQLファイル、記憶されている手順、ウェブ・ページ、インクルード・ファイル、ビジネス・ロジックなどがグループ分けされる。段階856で、所与のリリースに関するコンポーネントがパッケージされ、段階858で、このリリースが新しい環境に導入される。次いで段階860で、ホスティング・センターは新しい環境において各コンポーネントをパッケージ解除する。
【０１５２】
段階862で、導入が成功したかどうかが判定される。失敗である場合、段階864で、オペレーションズ・チームおよびホスティング・センター・サポート・チームが通知を受ける。導入が成功した場合、段階866で、正しいバージョンが転送されたかどうかが判定される。正しいバージョンが転送されていない。段階868で、正しいバージョンを移行させる必要のあるファイルが判定され、次いで新しい環境に転送される。正しいバージョンが転送された場合、段階870で、顧客は、環境が供給されコードが移行された旨の通知を受け、その後、インスタンシエータ・プロセスは終了する。
【０１５３】
図21aで、インスタンシエータ・プロセスは、別の方法、すなわち、段階872でオペレーションズ・チームから終了要求を受信することによって開始することができる。次いで、プロセスは接続B-Bを介して図21eの段階874に進む。段階874で、あるソフトウェア・コンポーネントが呼び出されてアンインストールされ、サーバおよびホスティング・センターにこのアンインストールが通知される。段階876でアンインストール機構が起動され、要求されたソフトウェア・コンポーネントが削除される。段階878で、要求されたソフトウェア・コンポーネントが専用サーバ用のコンポーネントであるかどうかが判定される。専用サーバ用のコンポーネントである場合、段階880で、プロダクト機構が専用／共用サーバ上でこのソフトウェア・コンポーネントをアンインストールする。次いで段階882で、クリーンナップ・ユーティリティが実行され、ディスク空間が再利用できるようにクリアされる。段階884で、アンインストールが成功したかどうかが判定される。失敗である場合、段階886で、オペレーションズ・チームおよびホスティング・センターが通知を受け、顧客、サーバ、ホスティング・センター、およびソフトウェア・コンポーネントに関する情報が与えられる。
【０１５４】
アンインストールが成功した場合、段階888で、すべてのソフトウェア・コンポーネントがアンインストールされているかどうかが判定される。アンインストールされていない場合、段階874が繰り返される。すべてのソフトウェア・コンポーネントがアンインストールされている場合、段階890で、バージョン制御へのアクセスが取り消され、段階892で、ロギング・ツールへのアクセスが取り消される。段階894で、インスタンシエータによって顧客資産情報が更新され、次いで、インスタンシエータ・プロセスは点895で終了する。
【０１５５】
段階878で、要求されたソフトウェア・コンポーネントは専用サーバ用のコンポーネントではないと判定された場合、段階896で、このソフトウェアのインスタンスが複数であるかどうかが判定される。このソフトウェアのインスタンスが1つだけである場合、段階880が実行される。このソフトウェアのインスタンスが複数である場合、段階898で、プロダクト機構が共用サーバ上でこのソフトウェアのこの顧客のインスタンスを削除し、段階882が実行される。
【０１５６】
図21aで、段階800で、ライセンスIDを保持し追跡するように必要なライセンス・ステータスが更新された後、プロセスは、接続D-Dを介して図21cの段階900に進む。段階900で、更新されたパッケージに関する残りの利用可能なライセンス在庫が算出される。次いで段階902で、ライセンス在庫レベルが、事前に設定された低しきい値よりも低くなっているかどうかが判定される。しきい値レベルよりも低くなっている場合、前述の段階842で、オペレーションズ・チームが通知を受ける。
【０１５７】
最後に、図21aの段階762における要求の種類の判定として、要求がユーザの管理を求める要求である場合、プロセスは、接続A-Aを介して図21cの段階904に進む。段階904で、新しいユーザが供給される。次いで段階906で、新しいユーザが供給されたことが顧客に通知され、インスタンシエータ・プロセスは点844で終了する。
【０１５８】
本発明のシステムおよび方法に関する潜在的なインスタンシエータには、Allaire、Ariba、ATG Dynamo、BAAN、BEA Tuxedo、BEA WebLogic Platform、Blue Martini、BroadVision、CommerceOne、Crystal Reports、IBM MQ Series、IBM WebSphere Platform、Interwoven、iPlanet Platform、JD Edwards、Kabira、Kana、Keenan、Microsoft NET Platform、Microsoft MSMQ、Nortel (Clarify)、Open Source Platform、Oracle Financials、PeopleSoft (Vantive)、Pivotal、Portal Infranet、SAP、Siebel、Vitria、およびWebMethodsが含まれる。
【０１５９】
サポートされる潜在的な技術には以下のものが含まれるが、これらに限らない。
a.開発ツール：Microsoft Visual Studio、Microsoft Office/Frontpage、Webgain Suite、Allaire Coldfusion Suite、Macromedia Suite、IBM Visual Age、およびForte
b.データベース：Oracle、Microsoft SQL Server、DB2、Sybase、Informix、Ingris、およびLotus Notes
c.プログラミング／スクリプティング環境：C、C++、C#、Java、Perl、Visual Basic、SQL、Transact-SQL、PL/SQL、JavaScript、VBScript、Unix Shells、Windows batch、SyncSort、JCC、およびAssembler
d.モデリング・ツール：Rational Enterprise Suite、Visio、およびPlatinum Suite
e.バージョン制御／リリース管理／環境設定管理／欠陥追跡ツール：Microsoft Visual Sourcesafe、PVCS、Rational ClearCase/ClearQuest、CVS、Razor、Endevor、SCCS、RCS、およびPegasys
f.試験ツール：Mercury Test Suite、Rational Test Suite、J Probe Test Suite、Segue、Sun Test Java tools、Preview、Java Unit、File-Aid、およびPlatinum
g.オペレーティング・システム・プラットフォーム：Windows NT/2K、Sun Solaris、HP/UX、Linux、AIX、およびMVS
h.プロジェクト管理：Microsoft Project、ABT Workbench、およびPWW
i.文書化：Microsoft Office
【０１６０】
本発明による、ウェブ・サービスで構成されたインタネット・ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法、ならびにこのような環境で使用されるソフトウェアのいくつかの態様について説明したが、当業者には、上記の説明を考慮して他の修正、変形、および変更が構想されると考えられる。したがって、すべてのそのような変形、修正、および変更が、添付の特許請求の範囲で定義された本発明の範囲内であると考えられることを理解されたい。
【図面の簡単な説明】
【０１６１】
【図１】本発明のシステムおよび方法を実施することのできるコンピュータ・システムを示すブロック図である。
【図２】従来の開発モデルと本発明のシステムおよび方法との比較を示す図である。
【図３】従来のシステム統合構成を示す図である。
【図４】本発明のシステムおよび方法を使用したシステム統合を示す図である。
【図５．６】本発明のシステムおよび方法の基本コンポーネントを示す図である。
【図７】被ホスティング・インタネット環境を開発する従来の方法を示す図である。
【図８】本発明による、ウェブ・サービスで構成された、インタネット・ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法、ならびにそのような環境で使用されるソフトウェアを示す図である。
【図９】アプリケーション・インフラストラクチャ・プロバイダ監視システムに対してプラグ・アンド・プレイ機能を実行するアプリケーション開発者標準APIを本発明によるシステムおよび方法においてどのように設けるかを示す図である。
【図１０】本発明による仮想ソフトウェア開発環境を示すブロック図である。
【図１１．１２】それぞれ、ホスティング・システム・コンポーネントおよびASPシステム・コンポーネントを示すブロック図である。
【図１３】各コンポーネントに対する責任が環境開発全体にわたったどのように共用されるかを示すブロック図である。
【図１４】図14a〜lは、本発明の、ウェブ・サービスで構成された、インタネット・ホスティング・ビジネス・アプリケーションを開発するシステムおよび方法による、環境要件の設計プロセスおよび開発を示すフローチャートである。
【図１５】図15a〜cは、本発明による、ウェブ・サービスからアプリケーションを構築するプロセスを示すフローチャートである。
【図１６】本発明による、ウェブ・サービスを呼び出すプロセスを示すフローチャートである。
【図１７】本発明による、ウェブ・サービスを試験するプロセスを示すフローチャートである。
【図１８】本発明によるシミュレータ試験データを挿入するプロセスを示すフローチャートである。
【図１９】図19a〜cは、本発明による、ウェブ・サービスを挿入するプロセスを示すフローチャートである。
【図２０】図20a〜dは、本発明による、ウェブ・サービスを証明するプロセスを示すフローチャートである。
【図２１】図21a〜fは、本発明によるインスタンシエータ・プロセスを示すフローチャートである。

Claims (20)

1. ウェブ・サービスで構成されたインタネット・ホスティング・ビジネス・アプリケーションを開発するシステムであって、
   アプリケーション・サービスを生成し、アプリケーション・サービスの構築、バージョン化、および導入を容易にすることによって、ビジネス・アプリケーションをカスタマイズする第1のソフトウェア・モジュールと、
   第1のソフトウェア・モジュールを通じて環境を供給しする被ホスティング・プロダクション環境とを含むシステム。
2. 供給された環境が手動で妥当性が検査される、請求項1記載のシステム。
3. 供給された環境が、1組の所定の規則を用いて自動的に妥当性が検査される、請求項1記載のシステム。
4. プロダクション環境へのウェブ・サービスのアップロードを可能にするウェブ・サービス・リポジトリをさらに含む、請求項1記載のシステム。
5. ウェブ・サービス・リポジトリが、複数の開発言語によってアクセス可能である、請求項4記載のシステム。
6. ウェブ・サービス・リポジトリへのアクセスが制限される、請求項4記載のシステム。
7. 変更が維持されるようにバージョン制御ツールをさらに含む、請求項1記載のシステム。
8. バージョン制御ツールが、改訂を記憶し検索し、リリースすべき改訂にラベル付けし、変更を追跡し、レポートを作成し、修正を行う機能を制限することができる、請求項7記載のシステム。
9. ウェブ・サービス用の試験データを作成するIDE試験ツールをさらに含む、請求項4記載のシステム。
10. 要求がウェブ・サービス・リポジトリに記憶されている場合に要件に付加されたメタデータを用いてIDEツール内のコードに該要件を関連付ける要件管理ツールをさらに含む、請求項9記載のシステム。
11. 供給された環境を試験環境の基礎として実施することができる、請求項1記載のシステム。
12. 設計完了日付を用いて設計タスクを更新する設計ツールおよび作業計画ツールをさらに含む、請求項1記載のシステム。
13. アプリケーション・コードに基づいて各設計を関連付けるようにIDEと統合される設計ツールをさらに含む、請求項9記載のシステム。
14. 要件をサポートする設計に関連付けるように要件管理ツールと統合される設計ツールをさらに含む、請求項10記載のシステム。
15. 試験環境が、被ホスティング・プロダクション環境内のサービス保証システムにアクセスし、監視コンポーネントと警告コンポーネントを統合することができる、請求項12記載のシステム。
16. ウェブ・サービスで構成されたインタネット・ホスティング・ビジネス・アプリケーションを開発するシステムであって、
    複数の開発ツール、事前に構築され環境設定された環境、および環境を作成するアプリケーションを含むポータルを含むソフトウェア開発環境と、
    特定の技術向けに調整されたアプリケーション・サービスを生成し、アプリケーション・サービスの、プロダクト構築、バージョン化、およびプロダクション環境への導入を容易にすることによって、ビジネス・アプリケーションをカスタマイズする第1のソフトウェア・モジュールと、
    該アプリケーション・サービスをアプリケーション・サービス・プロバイダ・インフラストラクチャ・プラットフォーム上で使用するのを可能にするビルダとを含むシステム。
17. ソフトウェア開発アプリケーション・サービス・プロバイダが、ブラウザを有するコンピュータからアクセスできる中央システム上に維持される、請求項17記載のシステム。
18. 第1のソフトウェア・モジュールが、方法、事前に作成された試験データベース、および試験環境を含む、請求項17記載のシステム。
19. ソフトウェア開発アプリケーション・サービス・プロバイダであって、
    ポータルと、
    複数の開発ツールと、
    事前に構築され環境設定された環境と、
    事前に環境設定された環境を作成するアプリケーションとを含むソフトウェア開発アプリケーション・サービス・プロバイダ。
20. ウェブ・サービスで構成されたインタネット・ホスティング・ビジネス・アプリケーションを開発する方法であって、
    複数の開発ツール、事前に構築され環境設定された環境を有し、環境を作成する固有のアプリケーションを有するポータルを含むソフトウェア開発アプリケーション・サービス・プロバイダ（DASP）を設ける段階と、
    特定の目標ホスティング環境向けに調整されたアプリケーション・サービスを生成し、アプリケーション・サービスの、プロダクト構築、バージョン化、およびプロダクション環境への導入を容易にすることによって、該事前に環境設定された環境をカスタマイズする段階と、
    ユーザがアプリケーション・サービス・プロバイダ・インフラストラクチャ・プラットフォーム上に存在するアプリケーション・サービスを使用するのを可能にするインデックスを設ける段階とを含む方法。

Images