(57)【要約】【課題】完全なエンドツーエンド・ソフトウェア送達プロセス管理のための統合システムおよび方法。【解決手段】構成管理／バージョン管理、変更／問題管理、構築、パッケージ化、および配布／インストールの各サブプロセスを含むソフトウェア送達プロセス。このプロセスは、構成管理サブシステム、変更／問題管理サブシステム、構築サブシステム、パッケージ化サブシステム、配布サブシステム、および追跡サブシステムを含む統合管理システムによって実装される。これらのサブシステムは、開発から生産でのインストールまで、その全ライフ・サイクルに沿ってソフトウェアを管理するために統合される。追跡サブシステムは、このプロセスのすべてのステップに沿ってその他のサブシステムから送達状況に関する情報を取り込み、それを統合する。【選択図】図３
2005502118.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク環境でソフトウェア製品の目標ソフトウェア製品実行ユニットへの送達プロセスを管理する統合データ処理システムであって、
少なくとも１つのソフトウェア製品のソフトウェア・コンポーネントを記憶する中央リポジトリと、
前記中央リポジトリ内で、送達されるソフトウェア製品のソフトウェア・コンポーネントを識別する第１のサブシステムと、
前記第１のサブシステムによって識別された前記識別済みソフトウェア・コンポーネントから少なくとも１つのソフトウェア製品パッケージを作成する第２のサブシステムと、
前記第２のサブシステムによって作成された前記少なくとも１つのソフトウェア製品パッケージを前記目標ソフトウェア製品実行ユニットに配布する第３のサブシステムと
を含む統合データ処理システム。
【請求項２】
前記識別済みソフトウェア・コンポーネントから前記第２のサブシステムによって作成された前記少なくとも１つのソフトウェア製品パッケージを記憶するソフトウェア・パッケージ配布リポジトリをさらに含む、請求項１に記載の統合データ処理システム。
【請求項３】
前記第３のサブシステムが、前記第２のサブシステムによって前記少なくとも１つのソフトウェア製品パッケージに割り当てられた少なくとも１つの役割に従って、少なくとも１つの環境に属する目標ソフトウェア製品実行ユニットに前記少なくとも１つのソフトウェア製品パッケージを配布する、請求項１に記載の統合データ処理システム。
【請求項４】
前記第１のサブシステムが、前記送達されるソフトウェア製品の前記ソフトウェア・コンポーネントの前記中央リポジトリでの記憶を管理する、請求項１に記載の統合データ処理システム。
【請求項５】
前記送達されるソフトウェア製品の前記識別済みソフトウェア・コンポーネントの間でソフトウェア・コード・コンポーネントの構築プロセスを実施する第４のサブシステムをさらに含み、前記第４のサブシステムは前記構築プロセスの結果を前記中央リポジトリに記憶する、請求項１に記載の統合データ処理システム。
【請求項６】
すでに送達されたソフトウェア製品に変更を適用するプロセスを管理する第５のサブシステムをさらに含む、請求項１に記載の統合データ処理システム。
【請求項７】
前記ソフトウェア製品の送達中に、統合データ処理システムの前記第１から第５のサブシステムの少なくとも１つによって提供される情報を記録する第６のサブシステムをさらに含む、請求項１に記載の統合システム。
【請求項８】
ネットワーク環境でソフトウェア製品を目標ソフトウェア製品実行ユニットに送達する方法であって、
少なくとも１つのソフトウェア製品のソフトウェア・コンポーネントを中央リポジトリに記憶するステップと、
前記中央リポジトリに記憶された前記ソフトウェア・コンポーネントの間で、送達されるソフトウェア製品のソフトウェア・コンポーネントを識別するステップと、
前記識別されたソフトウェア・コンポーネントの少なくとも１つを含む少なくとも１つのソフトウェア製品パッケージを作成するステップと、
前記ソフトウェア製品パッケージを前記目標ソフトウェア製品実行ユニットに配布し、そこに前記ソフトウェア製品パッケージをインストールするステップと
を含む方法。
【請求項９】
少なくとも１つのソフトウェア製品パッケージを作成する前記ステップが、前記少なくとも１つのソフトウェア製品パッケージに、前記ソフトウェア製品が配布される宛先の前記目標ソフトウェア製品実行ユニットを識別するための役割指示を割り当てること、前記役割指示に従って前記少なくとも１つのソフトウェア製品パッケージを配布することを含む、請求項８に記載の方法。
【請求項１０】
前記少なくとも１つのソフトウェア製品パッケージをソフトウェア配布リポジトリに記憶するステップをさらに含む、請求項８に記載の方法。
【請求項１１】
前記中央リポジトリに記憶された前記送達されるソフトウェア製品の識別されたソース・コード・コンポーネントを構築し、前記構築の結果を前記中央リポジトリに記憶するステップをさらに含む、請求項１０に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、ソフトウェア送達の分野に関し、詳細には、開発から生産でのインストールまで、その全ライフ・サイクルに沿ってソフトウェア製品を管理するようになされた、エンドツーエンド・ソフトウェア送達プロセスを完全に管理する統合システムおよび方法に関する。
【背景技術】
【０００２】
今日、大多数の企業の業務プロセスは、大部分が多様なソフトウェア・アプリケーションによって支援されている。
【０００３】
業務プロセスは新しい業務要件に適合するために不断の進化を必要とするので、それらの新しい要件を実装するために、企業の業務プロセスを支援するソフトウェア・システムおよびアプリケーションのコンポーネントを頻繁に変更し、動的に進化させる必要がある。
【０００４】
この変化する動的環境では、ソフトウェア送達プロセスは、ソフトウェア・アプリケーション開発領域においてだけでなくどんな企業の多様な領域、活動および業務プロセスにおいても重要な役割を果たす。
【０００５】
その結果、ソフトウェア送達管理は、ソフトウェアの進化およびソフトウェア・システムへの変更実装の制御を中心とした、企業システム管理内での、ソフトウェア・エンジニアリングの一部門として発展してきた。
【０００６】
ソフトウェア送達管理の主目的は、新しいソフトウェア・アプリケーションの（テスト、訓練、生産環境など）様々な環境での正しいインストール、ならびにすでにインストールされたソフトウェア・アプリケーションに適用される変更または修正の制御を可能にすることである。事実、ソフトウェア送達は、ソフトウェア・アプリケーションの新規リリースまたはバージョンの配置（すなわちインストールおよび実行）、既存のアプリケーションで発生したバグや問題を克服するための修正およびパッチの配布およびインストール、１つの集中管理点からのソフトウェア・システムの構成の変更を可能にする。また、ソフトウェア送達は、システム・クラッシュ後のシステムの再インストールおよび再構成も現場訪問を必要とせずに可能にする。
【０００７】
実際、ソフトウェア送達は、１つのファイルの配布からソフトウェア・システム全体の交換にまで及ぶことのある、複雑、微妙でかつ時間のかかる作業である。
【０００８】
ソフトウェア・システムに適用される変更の程度に応じて、インストール中のエラーや、すでにインストール済みのソフトウェアとの非互換性の可能性が増大する。ソフトウェア送達は、多数のシステムへの同時の変更適用を可能にするので、そうした変更がそれらのシステムに悪影響を及ぼさないことが非常に重要である。そうでないと、それらが大規模なユーザ妨害や業務上の損失さえもたらす可能性がある。
【０００９】
一般に、ソフトウェア送達のプロセスには複数の動作が関与する。これらの処理には、例えば、送達されるソフトウェア製品の様々なコンポーネント（たとえばソース・コード・モジュール、バイナリ・ファイルおよび実行可能ファイル、構成ファイル、インターフェイス、データ・モデル、データ構想、エンティティ、インストール・スクリプトや構成スクリプトなどのプロシージャ、ユーザ・ガイドなどの文書など）を識別すること、ソフトウェア製品の様々なコンポーネントのリリースやバージョンを管理すること、ソフトウェア製品が送達される宛先のソフトウェア・システムを構成する要素間の依存性を識別すること、目標システムすなわち目標環境およびプラットフォームでソフトウェア製品を実行するのに必要な項目を生成すること、目標プラットフォームにソフトウェア製品をインストールするのに必要なファイル、データ、スクリプト、およびユーティリティを含むソフトウェア・パッケージを作成すること、目標システムにソフトウェア・パッケージを配布すること、および配布されたソフトウェア・パッケージを目標システムにインストールすることが含まれる。
【００１０】
前述の完全な送達プロセスの一定の部分またはサブプロセスを実装するために、いくつか異なる方法が提案されている。以下に公知の方法の若干の例を報告する。
【００１１】
デービス他（Davis et al.）による、「異機種混合ネットワーク化クライアント・コンピュータ・システム上での自動ソフトウェア・インストール（Automaticsoftware installation on heterogeneous networked client computer systems）」という名称の米国特許第５，７４２，８２９号には、異機種混合クライアント・コンピュータ・システム上にソフトウェアを自動的にインストールする方法が提供されている。
【００１２】
コリンズ三世他（Collins, III et al.）による、「ディジタル・コンピュータ・ネットワークでのソフトウェア配布のためのシステム（Systemfor software distribution in a digital computer network）」という名称の米国特許第５，８４５，０９０号には、ソフトウェアおよびデータをメソッドと呼ばれるプログラムおよびデータと共に組み合わせてパッケージと呼ばれる単一エンティティにし、次いで特定の技法を使用してパッケージをあるコンピュータから別のコンピュータに伝送することによって、ネットワークでソフトウェアおよびデータを配布するプロセスが開示されている。この文献で開示されているプロセスは、配布パッケージ（プログラムおよびデータ・インストール）、収集パッケージ（データ収集用メソッド）、およびコマンド・パッケージ（システム管理タスク用メソッド）の伝送のためのサブプロセスをカバーするものである。
【００１３】
グロウニー（Glowny）による、「リモートのソフトウェア構成および配布のシステムおよび方法（Systemand method for remote software configuration and distribution）」という名称の米国特許第５，８０５，８９７号では、リモートのソフトウェア・インストールおよび維持のためのシステムおよび方法が扱われている。
【００１４】
ニール（Neal）による、「電子メールによりネットワーク・リンクを介してソフトウェアを配布する方法（Methodfor distributing software over network links via electronic mail）」という名称の米国特許第６，１９２，５１８号では、電子メールによってネットワークを介してソフトウェア・アプリケーションを配布する方法、装置、および製造品が開示されている。
【００１５】
ホームズ（Holms）による、「動的環境でソフトウェア・システムを指定、開発、配布および監視するための信頼性が高く反復可能なプロセス（Reliableand repeatable process for specifying, developing, distributing and monitoringa software system in a dynamic environment）」という名称の米国特許第６，２２６，７８４号には、プロジェクト管理のための一般的なプロセスが記載されている。このプロセスは、ソフトウェアのライフ・サイクルを、実験用環境でその開発の間だけ管理することに限定されるものである。
【００１６】
上記の各米国特許の全体を参照によって本明細書に組み込む。
【００１７】
従来技術で記載されているシステムおよび方法の別の例としては、ＩＢＭ社インターナショナル・テクニカル・サポート・オーガニゼーション（International Technical Support Organization, IBM Corporation）による、「ソフトウェア配布プロセス（TheSoftware Distribution Process）」という名称の資料、SG24.5504.00、1999年9月に、ソフトウェア配布およびインストールのサブプロセスが記載されている。あらゆるステップが詳細に記載され、それをどのようにいつ実装するかが説明されている。しかし、ソフトウェア送達プロセス全体に関与する他の任意のサブプロセスはカバーされていない。
【００１８】
公知の方法の大部分は、配布サブプロセスまたは無人インストール・サブプロセスあるいはその両方など、完全なソフトウェア送達プロセスのうちの個々のサブプロセスをカバーすることだけに限られている。他の公知の方法は、ソフトウェア・プロジェクト管理の特定の必要をカバーすることだけに限られており、開発から生産まで、ソフトウェア製品の全ライフ・サイクルに沿って業務環境上でソフトウェア送達プロセスを実装するためには適用できない。
【００１９】
従来技術のシステムおよび方法の実用的な一実装形態として、大多数の企業の情報技術（ＩＴ）組織は、全ソフトウェア送達プロセスのうちの特定のサブプロセスを実装するために、種々、別々の異機種混合の分離されたサブシステムをインストールしている。例えば、様々なバージョンのコードを制御するための特定の構成管理システム（またはアプリケーション）、変更を管理するための関連のないシステム（またはアプリケーション）、ソフトウェア製品での問題およびその解決策を追跡するための別のシステム、様々な環境にソフトウェア製品を配布するためのさらに別個のツールなどが考えられる。
【００２０】
適切なエンドツーエンド・ソフトウェア送達プロセス、あるいは分離された独立型のシステムによるこのプロセスの実装が行われないと、しばしば、低品質のソフトウェア製品、送達計画の遅延、コスト超過が発生し、あるいは顧客の要望を満たせないことがある。
【００２１】
本出願人は、現存の方法では、ソフトウェア・アプリケーションの様々なコンポーネントへの変更、それらの間の依存性および関係性、それらを走らせる複数のプラットフォーム、それらの複数のバージョンおよび様々な環境（開発、構築、単体テスト、機能テスト、統合テスト、回帰テスト、システム・テスト、生産など）を通じたそれらの進化という状況を包含することができないと考える。したがって、開発から生産でのインストールまで、その全ライフ・サイクルに沿ってソフトウェア・システムを管理できるエンドツーエンド・ソフトウェア送達プロセスが必要とされている。
【００２２】
この必要に適切に対処するためには、完全なエンドツーエンド・ソフトウェア送達プロセスを構成する種々の動作は相互に独立とすべきでも分離すべきでもない。その反対に、それらの全部ではなくても大部分を相互に関連させる必要がある。事実、これらの動作は、各動作が別の動作で必要とされる出力を生成するため、連鎖させる必要がある。また、このエンドツーエンド・ソフトウェア送達プロセスは、新規のソフトウェア製品、例えば新規のアプリケーションの完全なライフ・サイクルをカバーし、それを全体として管理し、そのプロセス全体を通じてその保全性を保つ必要がある。さらに、ソフトウェア送達プロセスは、ソフトウェア製品が、同じシステムまたは他の目標システム上で実行されている他のコンポーネントよびソフトウェア製品にも関連する、異なるが相互に関連した部分から構成されていることを考慮に入れる必要がある。
【特許文献１】
米国特許第５，７４２，８２９号
【特許文献２】
米国特許第５，８４５，０９０号
【特許文献３】
米国特許第５，８０５，８９７号
【特許文献４】
米国特許第６，１９２，５１８号
【特許文献５】
米国特許第６，２２６，７８４号
【非特許文献１】
「ソフトウェア配布プロセス（The SoftwareDistribution Process）」、ＩＢＭ社インターナショナル・テクニカル・サポート・オーガニゼーション（InternationalTechnical Support Organization, IBM Corporation）、SG24.5504.00、1999年9月
【発明の開示】
【発明が解決しようとする課題】
【００２３】
したがって、前述のすべての要件をカバーする全般的な解決策、およびソフトウェア製品が種々の相互に関連した部分から構成されていることを考慮に入れた上で、そのソフトウェア製品の完全なライフ・サイクルをカバーし、それを全体として管理すると共にその保全性を保つ統合管理システムに基づくエンドツーエンド・ソフトウェア送達プロセスが依然として必要とされている。
【課題を解決するための手段】
【００２４】
本発明は、前述の問題を解決することを対象とする。
【００２５】
詳細には、本発明の目的は、ソフトウェア製品を送達する現在のシステムおよび方法を改善して、満たすべきその主要な要件をカバーすることである。
【００２６】
本発明の第１の態様によれば、ネットワーク環境でのソフトウェア製品の目標ソフトウェア製品実行ユニットへの送達プロセスを管理する統合データ処理システムが提案される。それらの目標ユニットは、そのネットワーク環境内のソフトウェア製品テスト環境にも、ソフトウェア製品ユーザ訓練環境にも、あるいは生産環境にも属することができる。この統合データ処理システムは、少なくとも１つのソフトウェア製品のソフトウェア・コンポーネントを記憶する中央リポジトリと、中央リポジトリ内の、送達されるソフトウェア製品のソフトウェア・コンポーネントを識別する第１のサブシステムと、第１のサブシステムによって識別された識別済みソフトウェア・コンポーネントから少なくとも１つのソフトウェア製品パッケージを作成する第２のサブシステムと、第２のサブシステムによって作成された少なくとも１つのソフトウェア製品パッケージを目標ソフトウェア製品実行ユニットに配布する第３のサブシステムを含む。
【００２７】
ソフトウェア製品パッケージが配布される宛先である目標実行ユニットは、第２のサブシステムによって少なくとも１つのソフトウェア製品パッケージに割り当てられた役割の指示に従って決定される。
【００２８】
好ましい一実施形態では、この統合データ処理システムは、第３のサブシステムによって配布される予定の、識別済みソフトウェア・コンポーネントから第２のサブシステムによって作成された少なくとも１つのソフトウェア製品パッケージを記憶するソフトウェア・パッケージ配布リポジトリを含む。
【００２９】
第１のサブシステムは、送達されるソフトウェア製品のソフトウェア・コンポーネントの中央リポジトリ内の記憶も管理する。
【００３０】
好ましくは、この統合データ処理システムは、送達されるソフトウェア製品の識別済みソフトウェア・コンポーネントの間でのソフトウェア・コード・コンポーネントの構築プロセスを実施する第４のサブシステムをさらに含む。この第４のサブシステムは、その構築プロセスの結果を中央リポジトリに記憶する。
【００３１】
好ましい一実施形態では、この統合データ処理システムは、すでに送達されたソフトウェア製品に変更または修正あるいはその両方を適用するプロセスを管理する第５のサブシステム、およびソフトウェア製品の送達中にその統合データ処理システムの他のサブシステムによって提供される情報を記録する第６のサブシステムをさらに含む。
【００３２】
本発明の別の態様は、ネットワーク環境でソフトウェア製品を目標ソフトウェア製品実行ユニットに送達する方法である。この方法は、
少なくとも１つのソフトウェア製品のソフトウェア・コンポーネントを中央リポジトリに記憶するステップと、
中央リポジトリに記憶されたソフトウェア・コンポーネントの間で送達されるソフトウェア製品のソフトウェア・コンポーネントを識別するステップと、
識別されたソフトウェア・コンポーネントから少なくとも１つの配布可能ソフトウェア製品パッケージを作成するステップと、
そのソフトウェア製品パッケージを目標ソフトウェア製品実行ユニットに配布し、そこにそのソフトウェア製品パッケージをインストールするステップと
を含む。
【００３３】
本発明の特徴および利点は、添付の図面を参照してなされ、単に非限定的な例を引いて提供される、その好ましい一実施形態の以下の詳細な説明により明らかになるであろう。
【発明を実施するための最良の形態】
【００３４】
本発明は、情報インフラストラクチャを備える一般的な企業内での完全なエンドツーエンド・ソフトウェア送達プロセス実装のための統合管理システムおよび方法を提供する。
【００３５】
一般的な企業の情報インフラストラクチャを図１に概略的に示す。参照番号１０１でその全体を識別するインフラストラクチャは、例えばローカル・エリア・ネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）またはそれらの組み合わせ、あるいはその他任意の種類のネットワークである、ネットワーク１０５によってネットワークに接続されたパーソナル・コンピュータ、ワークステーション、サーバなど様々な性質の複数のプラットフォーム１０３を含む。プラットフォーム１０３は、ソフトウェア製品をテストするテスト環境ＴＥＳＴ、そのソフトウェア製品の対象とするエンド・ユーザがその使用法の訓練を受ける訓練環境ＴＲＡＩＮ、企業の毎日の業務管理で目的の用途のためにそのソフトウェア製品を実行する生産環境ＰＲＯＤなど、複数の異なる環境に属することができる。
【００３６】
この企業は、企業の情報インフラストラクチャ管理の機能を有する情報技術（ＩＴ）組織ＩＴ＿ＯＲＧも持つ。このＩＴ組織は一般に、例えば新規ソフトウェア製品や、既存のソフトウェア製品の新規リリースまたはバージョンの開発を担当するソフトウェア製品開発チームＤＥＶ、ソフトウェア・コードから開始して、目標環境でソフトウェア製品を実行するのに必要とされるすべての項目を構築するプロセスを担当するソフトウェア製品構築チームＢＵＩＬＤ、規定の環境での目標プラットフォーム１０３に配布されるソフトウェア・パッケージの作成を担当するソフトウェア・パッケージ作成チームＰＡＣＫ、および規定の環境での規定の目標プラットフォームへのソフトウェア・パッケージの配布およびインストールを担当するソフトウェア・パッケージ配布チームＤＩＳＴＲなど、複数のチームを含む。様々なチームの各メンバは、企業ネットワーク１０５に接続される、統合サーバ１０９にネットワークで接続されたプラットフォーム１０７上で処理を行う。
【００３７】
本発明によれば、適切で完全なエンドツーエンド・ソフトウェア送達プロセスは、構成管理／バージョン管理、変更／問題管理、構築、パッケージ化、配布、およびインストールの各サブプロセスを含むことができる。
【００３８】
構成管理／バージョン管理サブプロセスは、ソース・コード・モジュール、バイナリ・ファイルおよび実行可能ファイル、構成ファイル、インターフェイス、データ・モデル、データ構造、エンティティ、プロシージャ（インストール・スクリプトおよび構成スクリプト）、文書などの、ソフトウェア製品のコンポーネントの識別を可能にする。また、このサブプロセスは、開発ライフ・サイクル中にソフトウェア製品コンポーネントの異なるリリースおよびバージョンを管理し、それらの進化を追跡する。またこれは、ソフトウェア製品が送達され得る宛先目標ソフトウェア・システムの要素間の可能な依存関係の識別（プラットフォーム、オペレーティング・システム、ミドルウェア、ネットワークの検討など）を可能にし、これらの要素すべてをまとめて全体として管理できるようにする。したがってこのサブプロセスは、特定の環境および段階にある目標ソフトウェア・システムの状況を常に判断できるようにする。
【００３９】
変更／問題管理サブプロセスは、コードを拡張するために実装される変更や発生したエラーを解決するために開発される修正の制御を可能にする。開発チームが変更を実装し、またはバグを修正するために生成または変更したソフトウェア・コンポーネントは、識別し制御する必要があるので、このサブプロセスは、構成管理／バージョン管理サブプロセスと完全に一体化して動作することができる。
【００４０】
構築サブプロセスは、指定された目標システム、すなわち指定された目標環境およびプラットフォームでソフトウェア製品を実行するのに必要な項目を生成する。このサブプロセスの正常な実装は、構成管理／バージョン管理サブプロセスの正しい実装を必要とする。このためには、構築サブプロセスは、何を変更する必要があるか、構築プロセスで使用する要素がどこにあるか、ソフトウェア製品の新規バージョンを正常に生成するためにどのプロシージャをトリガすべきかを知る必要がある。
【００４１】
パッケージ化サブプロセスは、必要なファイル、データ、スクリプトおよびインストール・サブプロセスを支援するために必要とされるユーティリティを含む、インストール可能な形式のソフトウェア・パッケージを生成する。インストール・サブプロセスの正確さを保証するためには、必須ではないが、インストールが無人で（すなわちエンド・ユーザによる介入なしで）行われることが望ましい。このために、生成されるパッケージは、インストール・サブプロセス中に要求されるパラメータの値、選択肢、または可能な答えを正しく記録しておくことのできる必要な応答ファイルを含むこともできる。
【００４２】
配布サブプロセスは、パッケージ化サブプロセスで生成されたソフトウェア・パッケージの目標システムへのインストール可能にすると共に目標システムから使用可能にする。
【００４３】
最後に、インストール・サブプロセスは、配布されたソフトウェア・パッケージを目標システム、すなわち対応する環境（テスト、生産、訓練など）での規定の目標プラットフォーム上にインストールする。このサブプロセスは、ログ・ファイルも作成し、ソフトウェア・パッケージのインストールの結果として目標システムに適用された変更をログに記録する。また、インストール・サブプロセスは、配布管理チームに、正常で正確なインストールの完了について通知し、またはインストールに失敗した場合は処理をトリガすることもできる。
【００４４】
本発明の好ましい一実施形態による統合管理システムは、ソフトウェア送達プロセスを構成する様々なサブプロセスを実装する複数の異なるサブシステムを含む。
【００４５】
具体的には、本発明の好ましい一実施形態による統合管理システムは、構成管理／バージョン管理サブプロセスを実装する構成管理サブシステム、変更／問題管理サブプロセスを実装する変更／問題管理サブシステム、構築サブプロセスを実行する構築サブシステム、パッケージ化サブプロセスを実装するパッケージ化サブシステム、および配布／インストール・サブプロセスを実装する配布サブシステムを含む。
【００４６】
各サブシステムは、ソフトウェア送達プロセスの１つまたは複数の特定のサブプロセスを実施する。これらのサブシステムは、開発から生産でのインストールまで、その全ライフ・サイクルに沿ってソフトウェア製品を管理するために、分離されず、相互に統合され関連付けられている。
【００４７】
さらに、本発明の好ましい一実施形態による統合管理システムは、その他のサブシステムと統合され相互に対話する追跡サブシステムを含む。この追跡サブシステムは、ソフトウェア送達プロセスの様々な段階に沿って、他のサブシステムからソフトウェア送達の状況に関する情報を取り込み、それを統合する。プロセスの各段階およびそれらの段階で検出された問題は、追跡サブシステムによって記録することができる。また、追跡サブシステムは、ＩＴ組織内の様々なチームのメンバに、そうした組織内での各メンバの役割および責任に応じて、ソフトウェア送達プロセスに関して連絡を保つこともできる。
【００４８】
図２は、本発明の好ましい一実施形態によるエンドツーエンド・ソフトウェア送達統合管理システムの概略的構成図である。この統合管理システムは、参照番号２０１で全体として識別され、そのコンポーネント・サブシステムが機能ブロックとして概略的に表されている。具体的には、構成管理サブシステムはブロック２０３（ＣＭｓｓ）で、構築サブシステムはブロック２０５（Ｂｓｓ）で、パッケージ化サブシステムはブロック２０７（Ｐｓｓ）で、配布サブシステムはブロック２０９（Ｄｓｓ）で、変更／問題管理サブシステムはブロック２１１（Ｃ＆ＰＭｓｓ）で識別される。さらに、追跡サブシステムはブロック２１３（Ｔｓｓ）で識別される。
【００４９】
企業のＩＴ組織の開発チームＤＥＶがそれを用いて対話するための構成管理サブシステム２０３は、関連するセキュアな中央リポジトリ（ＣＲ）２１５を備え、構築サブシステム２０５、パッケージ化サブシステム２０７、変更／問題管理サブシステム２１１と対話する。次に、パッケージ化サブシステム２０７は、配布サブシステム２０９と対話する。本発明の好ましい一実施形態では、配布サブシステム２０９は関連するソフトウェア配布リポジトリ（ＤＲ）２１７を備える。ソフトウェア配布リポジトリ２１７には、パッケージ化サブシステム２０７からアクセスすることができる。
【００５０】
配布サブシステム２０９は、例えば生産環境ＰＲＯＤやテスト環境ＴＥＳＴなど、規定の環境の規定の目標プラットフォーム１０３に、後続のインストールのためにソフトウェア製品を配布することができる。
【００５１】
変更／問題管理サブシステム２１１は、ソフトウェア製品がインストールされている様々な環境の目標プラットフォームからフィードバックを受け取る。
【００５２】
ＩＴ組織の開発チームＤＥＶは、インストール済みソフトウェア製品の問題への変更または修正の開発段階で、変更／問題管理サブシステム２１１と対話する。変更／問題管理サブシステムは開発チームに、インストール済みソフトウェア製品に修正または変更が必要とされることを通知する。
【００５３】
構成管理サブシステム２０３、構築サブシステム２０５、パッケージ化サブシステム２０７、配布サブシステム２０９、および変更／問題管理サブシステム２１１はすべて、追跡サブシステム２１３と対話することができる。
【００５４】
図２では、サブシステム、リポジトリ、目標環境および開発チームの間の機能的対話が単純な線として概略的に表されている。
【００５５】
プロジェクトの要件に従って統合管理システムを形成するように前述の各サブシステムを実装し、相互に統合し合うためには、既存のソフトウェア製品およびツール、ならびにこのために特別に開発された他のソフトウェア・コンポーネントを使用することができる。
【００５６】
次に、様々なサブシステムの具体的な機能についてより詳細に説明する。
【００５７】
一般に、構成管理サブシステム２０３は、ソフトウェア送達プロセスの構成管理／バージョン管理サブプロセスを実装する。具体的には、このサブシステムは、ソース・コード・モジュール、構築スクリプト（すなわちＭａｋｅｆｉｌｅ）、バイナリ・ファイルおよび実行可能ファイル、インターフェイス、データ・モデル、データ構造、エンティティ、構成ファイル、インストール・スクリプトおよび応答ファイル、構成スクリプト、ならびに例えば送達情報、構築ガイド、管理ガイド、操作ガイドおよびユーザ・ガイドといった文書コンポーネントなど、ソフトウェア製品の各コンポーネントを識別し、編成し、制御するタスクを実施する。
【００５８】
ソフトウェア製品の前述の各コンポーネントは、例えば、開発チームが開発し、あるいはソフトウェア供給元から購入して、開発チームが構成管理サブシステム２０３に提供することができる。
【００５９】
構成管理サブシステム２０３は、それらのソフトウェア・コンポーネントを関連するセキュアな中央リポジトリ２１５に記憶する。
【００６０】
さらに、構成管理サブシステム２０３は、その開発ライフ・サイクル全体を通じてそれらのソフトウェア・コンポーネントのバージョンを制御、管理し、その進化を追跡して、その状況や、特定の環境でのそのコードのバージョンをすぐに判別できるようにする。
【００６１】
さらに、構成管理サブシステム２０３は、ソフトウェア製品を構成するソフトウェア・コンポーネント間の依存性および関係性の記録を可能にすると共に、それらすべてをまとめて全体として管理できるようにする。
【００６２】
したがって、構成管理サブシステム２０３は、ソフトウェア製品の保全性のみならず、システム全体の保全性も保証する。これらすべての機能が、複雑さを低減させて実装時間を節約し、ソフトウェア生産プロセスの品質および生産性を向上させ、以前のソフトウェア・バージョンの再利用を簡単にする。
【００６３】
変更／問題管理サブシステム２１１は、ソフトウェア送達プロセスの変更／問題管理サブプロセスを実装する。具体的にはこのサブシステムは、以下の機能を実施する。
ソフトウェア製品への変更の実装およびエラーの解決を制御する機能；
変更／問題管理サブプロセスの各ステップを支援する機能。これらのステップには、例えば、テスト、訓練または生産環境のいずれかにすでにインストール済みのソフトウェア製品での問題の検出、変更の承認、出力の検証、変更の実装、バグの訂正などが含まれる；
変更および問題を追跡し、変更／問題管理サブプロセスが正常に実現されたこと、および変更が適切に許可されたことを保証する機能；
変更および問題の影響を評価し、それによって意思決定を可能にし、コスト、労力および時間を節約する機能；
このサブシステム内で記録、管理された類似のエラーに基づき問題判別プロセスを容易にする機能；
コードのどの要素がアプリケーション問題の原因であるか、あるいは変更を実装するためにどのコード要素を変更する必要があるかを識別する機能；
複数のバージョンおよび環境にわたって、作成された変更および修正をそのソフトウェア製品の新規バージョンで解決される問題と関連付けて、それらを個々のソフトウェア要素上で分離できるようにする機能。
【００６４】
正確な問題および変更管理を実施するためには、堅固で適切な構成管理、ならびに効果的なバージョン管理が必要とされる。このために、変更／問題管理サブシステム２１１を、構成管理サブシステム２０３と完全に統合することができる。完全な統合とは、エンド・ユーザが、中央リポジトリ２１５内にある変更されるソフトウェア・コンポーネントのバージョンおよびリリース、その他の特徴を判別することができることを意味する。構成管理サブシステム２０３および変更／問題管理サブシステム２１１は、構成、バージョン管理、および変更／問題管理を実装する、単一サブシステムと考えることができる。
【００６５】
構築サブシステム２０５は、ソフトウェア送達プロセスの構築サブプロセスを実装する。具体的にはこのサブシステムは、中央リポジトリ２１５に記憶されたソース・コードが正しく構築されたことを保証すると共に、目標システム上でそのソフトウェア製品を実行するのに必要とされるバイナリ・ファイルを生成する機能を持つ。このサブシステムは、バイナリ・ファイルの生成元であるソース・コードのバージョンの識別も可能にする。
【００６６】
より詳細には、構成管理サブシステム２０３の制御下で、構築サブシステム２０５は、中央リポジトリ２１５から必要なソース・コード・コンポーネントを自動的に抽出し、そのソフトウェア製品を構築するのに必要なスクリプトおよび他の任意の要素を構築する。次いで、このサブシステムは、これらのコンポーネントを適当な構築システムに転送する。ソース・コードのタイプに応じて、構築サブシステム２０５は、そのソフトウェアの対応するバージョンを得るために、適当な構築スクリプト、構築システム、および目標実行プラットフォームおよび環境をトリガする。
【００６７】
その後、サブシステム２０５は、生成されたバイナリ・ファイルを中央リポジトリ２１５に自動的に記憶し、それらが生成された元であるソースを追跡する。
【００６８】
ソフトウェア・システムがＩＴ組織によって社内で開発されず、ソフトウェア供給元から購入されたときは、ほとんどの場合、バイナリ・ファイルは限定的に送達され、生成されることはない。この場合は、構築サブプロセスを実施する必要はない。企業のＩＴ組織の開発チームは、ソフトウェア供給元から提供されたバイナリ・ファイルを構成管理サブシステムに供給し、このサブシステムがそれらのファイルをソフトウェア製品のその他のコンポーネントと共に中央リポジトリ２１５に記憶する。
【００６９】
パッケージ化サブシステム２０７は、ソフトウェア送達プロセスのパッケージ化サブプロセスを実装し、ソフトウェア製品のパッケージを生成して、それらを規定環境の目標プラットフォームに配送しインストールすることができるように準備する。より具体的には、パッケージ化サブシステム２０７は、配布可能な圧縮ソフトウェア・パッケージを生成する。これらのパッケージは、構築サブプロセスで生成され、またはソフトウェア供給元から提供されたソフトウェア製品のバイナリ・ファイル、および構成ファイル、初期設定ファイル、目標プラットフォーム上での無人インストールに必要な応答ファイル、エンド・ユーザ用文書など、必要とされるその他すべてのファイルを含む。これらのファイルは、中央リポジトリ２１５に記憶されたソフトウェア製品を構成する各コンポーネントを識別する構成管理サブシステム２０３の制御下で、中央リポジトリ２１５からパッケージ化サブシステムによって自動的に抽出される。パッケージの内容は、アプリケーション・コードおよび目標実行プラットフォーム（ハードウェア、オペレーティング・システム、ミドルウェア）のタイプによって異なるが、パッケージ化サブプロセスおよびパッケージ形式はそのパッケージ内容とは無関係とすることができる。
【００７０】
次いで、ＩＴ組織のパッケージ化チームによって提供され追跡サブシステムに記録された情報に基づいて、パッケージ化サブシステム２０７は、そのソフトウェア製品が最終的にインストールされる目標システムの役割に一致するはずの役割を、生成されたソフトウェア・パッケージに割り当てる。例えば、目標システムの役割は、ＷＩＮＤＯＷＳ（Ｒ）  ＮＴ  ＳＱＬサーバ、ＭＱシリーズ・クライアント、ＳＡＰ  ＮＴ  サーバなどとすることができる。
【００７１】
好ましくは、パッケージ化サブシステム２０７は、生成されたソフトウェア・パッケージを、ソフトウェア配布サブシステム２０９のソフトウェア配布リポジトリ２１７に記憶する。これにより、追跡サブシステム２１３によって提供される情報を使用して、各プラットフォーム上のそのソフトウェア製品のあらゆるコンポーネントを容易に識別することができ、ソフトウェア配布リポジトリ２１７からこれらのコンポーネントそれぞれの正しいバージョンを含む対応するインストール可能なパッケージを取得することが可能になる。さらに、ソフトウェア・アプリケーションの各バージョンは、そのパッケージがソフトウェア配布サブシステム２０９のソフトウェア配布リポジトリ２１７に記憶されてから１回だけ構築、パッケージして、その後に改訂することができ、結果として実施されるインストールが、（単体テスト環境、機能テスト環境、統合テスト環境、回帰テスト環境、システム・テスト環境、生産などの）目標環境に関係なく、同一であることが保証される。
【００７２】
ソフトウェア配布サブシステム２０９は、ソフトウェア送達プロセスの配布／インストール・サブプロセスを実装し、規定環境の正しい目標プラットフォーム上へのソフトウェア・パッケージの配布およびインストールを実施する。配布されるソフトウェア・パッケージはソフトウェア配布リポジトリ２１７に記憶することもでき、ソフトウェア製品バイナリ・ファイル、および構成ファイル、初期設定ファイルおよび無人インストールに必要な応答ファイルなど必要とされる他の任意のファイルを含み、そのため、統合管理システムから要求され、あるいは目標プラットフォームに命令されてパッケージのインストールが開始された後には、ユーザの介入を必要とせず、したがってインストール・プロセスの正確さが保証される。
【００７３】
ソフトウェア・パッケージの配布およびインストールは、直接アクセス配布、ストリーミング配布、宛先変更配布、カスケード配布、Ｗｅｂサーバへの公開による配布、電子メールを介した送信による配布など、従来の配布方法のいずれか１つに従って実施することができる。これらの方法すべては、相互に異なっていても、「ｐｕｌｌ」型配布技術、「ｐｕｓｈ」型配布技術、またはそれらの組み合わせ（「ｐｕｓｈ−ｐｕｌｌ」型配布技術）のいずれかを利用する。ｐｕｌｌ型配布技術では、ソフトウェア・パッケージの配布は、そのソフトウェア・パッケージを目標プラットフォームにインストールしようとするエンド・ユーザによってトリガされる。ｐｕｓｈ型配布技術では、配布はソフトウェア配布サブシステム２０９によって開始され、それがソフトウェア・パッケージをソフトウェア配布リポジトリ２１７から目標プラットフォームに配布させる。ｐｕｓｈ−ｐｕｌｌ型配布技術では、ソフトウェア・パッケージの配布は、ｐｕｓｈ型技術とｐｕｌｌ型技術の組み合わせによって実施される。様々な状況に応じて、これらの技術のいずれか１つを実装し適用することができる。
【００７４】
プロジェクト目的に従ってソフトウェア・パッケージのインストールが許可されると、追跡サブシステム２１３からテスト・チーム、技術チーム、エンド・ユーザ、または（目標環境に応じた）関連する任意の専門家に通知を行うことができる。
【００７５】
配布サブシステム２０９は、パッケージ化サブシステム２０７によってそこに割り当てられた役割に従ってソフトウェア・パッケージを配布する。
【００７６】
追跡サブシステム２１３は、厳密にいうと、必ずしもソフトウェア配布プロセスのいずれか特定のサブプロセスを実装するとは限らない。このサブプロセスはむしろ、その全ライフ・サイクルに沿った一般のソフトウェア製品の送達プロセス状況に関してその他のサブシステムから収集した情報をまとめる。実施されるあらゆるプロセス・ステップ、あらゆる詳細、および統合管理システム上で検出されたあらゆるイベントは、追跡サブシステム２１３によって記録することができる。例えば、情報ツールとして、このサブシステムは、様々なソフトウェア製品送達およびソフトウェア・レベル、構築結果、配布またはインストール結果、送達状況に関する情報を提供する。
【００７７】
本発明の好ましい一実施形態では、追跡サブシステム２１３は、ある規定のイベントが発生したとき、例えば送達状況の遷移が発生したときに、その送達プロセスに関与する専門家らに電子メール・メッセージの形で通知を自動的に送達する、電子メール（ｅメール）ツールを含む。電子メール・メッセージによる自動通知は、送達状況に関して、適切な時期にチームのメンバに通知する。具体的にはこのサブシステムは、配布担当のチームにソフトウェア・パッケージの送達について連絡する。
【００７８】
前述の統合管理システムは、
構成管理サブシステム２０３の制御下で、ＩＴ組織の一チーム（例えば構成管理チームなど）によって、バージョン番号、プラットフォーム、言語、開発チームなどの関連する詳細を含むソフトウェア製品のバージョンを、追跡サブシステム２１３に記録し、ソース・コードの各部分を中央リポジトリ２１５にロードするステップと、
バージョン番号を割り当て、ソース・コードを記憶し、添付文書などを制御する、構成管理サブシステム２０３内のソース・コードを管理するステップと、
ソフトウェア供給元によって提供されなかった場合は、構築サブシステム２０５によって構成管理サブシステム２０３の制御下で、中央リポジトリ２１５に記憶されたソース・コードからバイナリ・ファイルを構築するステップと、
構成管理サブシステム２０３の制御下で、生成されたバイナリ・ファイル、および構成スクリプトやインストール・スクリプトなど、そのソフトウェア製品のその他のコンポーネントを中央リポジトリ２１５にロードするステップと、
構成管理サブシステム２０３の制御下で、中央リポジトリ２１５からバイナリ・ファイル、文書、構成スクリプトおよびインストール・スクリプトを抽出し、パッケージ化サブシステム２０７によって、配布されるソフトウェア・パッケージを生成するステップと、
ソフトウェア・パッケージを規定の目標環境での規定の目標プラットフォームに配布するために、前記生成されたソフトウェア・パッケージを配布サブシステム２０９に送るステップと、
配布サブシステム２０９の制御下で、ソフトウェア・パッケージを規定の環境の目標プラットフォームに配布しインストールするステップと、
このプロセス中に追跡サブシステムを更新し、そこに各ステップおよび問題を記録するステップと
を含むエンドツーエンド・ソフトウェア送達方法を実施する。
【００７９】
さらに、この方法は、変更／問題管理サブシステム２１１の制御下で、すでに送達済みのソフトウェア製品へのソフトウェア変更および修正を管理できるようにする。
【００８０】
次に図３を参照すると、本発明による、前述の統合ソフトウェア送達システムによってエンドツーエンド送達プロセスを実装する方法の好ましい一実施形態が、簡単な流れ図の形で示されている。
【００８１】
次に説明するこの方法の例示的実施形態では、企業のＩＴ組織の開発チームによって新規のソフトウェア製品が社内で完全に開発された場合について言及する。ただし、本発明による方法は、そのソフトウェア製品が社内で開発されたかそれともソフトウェア供給元によって提供されたかに関わらず、完全なエンドツーエンド・ソフトウェア送達プロセスを実装するように適合される。後者の場合は、この方法のステップの一部（構築のプロセスに関連するステップ）は実施する必要がない。
【００８２】
この方法は、企業ＩＴ組織の開発チームが新規ソフトウェア製品、あるいはバグを修正し、または何らかの変更を加えるための既存のソフトウェア製品の新規リリースまたはバージョンを開発することを決定し次第開始される。
【００８３】
まず（ブロック３０１）、開発チームは開発されるソフトウェア製品の関連詳細を追跡サブシステム２１３に記録する。記録される情報には、例えば、ソフトウェア製品名、リリース／バージョン番号、開発チームのリーダ名、目標実行プラットフォーム名、言語コード、製品参考資料、すでに修正された問題、実装された変更などが含まれ得る。
【００８４】
次いで（ブロック３０３）、構成管理サブシステム２０３の制御下で、開発チームは、そのソフトウェア製品を構築、実行するのに必要とされるソフトウェア製品のコンポーネントを中央リポジトリ２１５にロードする。これらの要素には、例えば、ソース・コード・モジュール、構築スクリプト（すなわちＭａｋｅｆｉｌｅ）、構築文書、インターフェイス、データ・モデル、データ構造、エンティティ、構成スクリプトまたはファイル、インストール・スクリプトおよび無人インストールのための応答ファイル、ならびに例えば送達情報（用途、日付、修正された問題、適用された変更など）、構築ガイド、管理ガイド、操作ガイド、およびユーザ・ガイドなどの文書が含まれ得る。
【００８５】
ブロック３０５で表すように、構成管理サブシステム２０３は、中央リポジトリ２１５に記憶されたソフトウェア製品のコンポーネントおよびそれらのバージョンを制御する。このために、開発チームは、ソース・コードを含む１つまたは複数のリポジトリ・コンポーネント名を含めて、構成管理サブシステム２０３がその制御を実施するために使用する情報を追跡サブシステム２１３に記録する。
【００８６】
開発段階が完了すると、開発チームは追跡サブシステム２１３を使用して、ＩＴ組織内のソフトウェア送達担当部門にそのソフトウェア製品が使用可能であることを報告する（ブロック３０７）。
【００８７】
次いで（ブロック３０９）、構築チームは、生成された構築スクリプトおよび文書が正確であるかどうかチェックする。このチェック中に、生成された構築スクリプトまたは文書あるいはその両方にエラーが見つかった場合は、構築チームによってそのイベントが追跡サブシステム２１３に記録され、そこから開発チームにエラー訂正の必要が通知される。開発チームがそのエラーを訂正した後で、少なくとも変更されたソフトウェア・コンポーネントについて前のステップを繰り返す。
【００８８】
次いで、そのソフトウェア製品を適正に実行させるのに必要なバイナリ・ファイルを生成するために、そのソフトウェア製品が構築される。ブロック３１１で表すように、これらのバイナリ・ファイルは、構成管理サブシステム２０３の制御下で、中央リポジトリ２１５に記憶されたソース・コードから構築サブシステム２０５によって生成される。
【００８９】
次いで、構築サブシステム２０５は、前のステップで生成されたバイナリ・ファイルを中央リポジトリ２１５に記憶する（ブロック３１３）。
【００９０】
次のステップ（ブロック３１５）として、構築チームは、ブロック３０９、３１１、および３１３の各ステップの実行に関連する情報または（該当する場合は）問題を追跡サブシステム２１３に記録する（例えば完了成功または失敗、関連問題、必要な文書の欠如など）。追跡サブシステム２１３は、必要に応じて構築チームのメンバに、例えば電子メール・メッセージの形で自動通知を送信する。
【００９１】
この時点で、ソフトウェア・アプリケーションの構築が完了する。パッケージ化サブシステム２０７によって、パッケージ化チームは対応するインストール可能なソフトウェア・パッケージを生成する（ブロック３１７）。構成管理／バージョン管理サブシステム２０３の制御下で、パッケージ化サブシステム２０７は中央リポジトリ２１５から、そのソフトウェア製品を規定の目標プラットフォーム上に配置（すなわちインストールおよび実行）するのに必要なソフトウェア・コンポーネントを抽出する。これらのコンポーネントには、バイナリ・ファイルおよび実行可能ファイル、インストール・スクリプト（必要に応じて）、無人インストール用応答ファイル、構成スクリプト（必要に応じて）、構成文書（必要に応じて）、エンド・ユーザ文書（すなわちユーザ・ガイド）、管理および操作文書、および規定の環境および規定の目標プラットフォーム上にそのソフトウェア製品を配置するために必要とされる可能性のあるその他のソフトウェア製品コンポーネントが含まれ得る。
【００９２】
ソフトウェア・パッケージには構築サブプロセス中に生成されるあらゆる要素を含む必要があるので、構築サブプロセス２０５の出力は構成管理サブシステム２０３の中央リポジトリ２１５に記憶され、パッケージ化サブシステム２０７に入力として供給される。一般に、各ソフトウェア・パッケージは必要なものを完備している必要があるが、アプリケーションの特定の設計やインストール要件によっては、インストールされる１つのソフトウェア製品につき複数のパッケージを使用することもできる。
【００９３】
ソフトウェア・パッケージが生成されると、それを配布することができる。したがって、生成されたソフトウェア・パッケージを、ソフトウェア配布サブシステム２０９に供給することが可能である。このために、パッケージ化サブシステム２０７は、そのソフトウェア・パッケージの配布を可能にするために、それを配布サブシステム２０９のソフトウェア配布リポジトリ２１７に記憶する（ブロック３１９）。
【００９４】
次いで、パッケージ化チームは、ブロック３１７および３１９のステップに関連する情報または問題を追跡サブシステム２１３に記録する（ブロック３２１）。後者は、必要に応じてチームのメンバに自動通知を送信し配布する。
【００９５】
配布サブシステム２０９を使用して、配布／インストール・チームは、目標環境の目標プラットフォームにソフトウェア・パッケージを配布、インストールする（ブロック３２３）。配布／インストール・チームは、このステップに関連する情報または問題も追跡サブシステム２１３に記録し、そこから必要に応じてチームのメンバに自動通知が送信される。好ましくは、企業のＩＴ組織方針に従って、目標環境へのアプリケーション・パッケージのインストールは、管理チームの承認を受けることができる。
【００９６】
ブロック３２５で表すように、インストール済みソフトウェア製品の拡張およびアプリケーション・バグの解決に必要な修正は、変更／問題管理サブシステム２１１によって処理される。このサブシステムは、構成管理サブシステム２０３と完全に統合することもできる。ソフトウェア変更および問題修正は、ＩＴ組織によって定義されるプロセスに従う必要がある。アプリケーション変更およびバグに関連する情報は、変更／問題管理サブシステム２１１に記録される。変更の場合には、変更の要求者がこの作業を実施し、エラーの場合には、それを発見した組織によってこのイベントが記録される。
【００９７】
すでにインストール済みのソフトウェア製品に変更を実装し、またはそのバグを修正するために生成されたコード・バージョンを送達するプロセスおよび方法は、他のどんな送達項目のものとも基本的に同じである。事実、新規コード・バージョンの開発が始まると、それは追跡サブシステム２１３に記録される。また、構成管理サブシステム２０３内の変更またはバグの識別子も、送達情報の一部として記録する必要がある。
【００９８】
ソフトウェア製品が企業ＩＴ組織によって社内で開発されず、ソフトウェア供給元によって提供された場合は、そのソフトウェア送達プロセスは、その供給元からソフトウェアを受け取ったときに開始する。ソフトウェア送達プロセス担当のスタッフに通知され、そのスタッフが追跡サブシステム２１３にその送達を記録する。この場合、インストール可能な形式のバイナリ・ファイルだけが送達されるはずであり、構成管理サブシステム内ではソース・コードの記憶も、管理もする必要がないので、構築サブプロセスは省略される。
【００９９】
図４は、ソフトウェア送達プロセスの主要ステップが送達の状況に関する情報、すなわち追跡サブシステム２１３に記録された情報をどのように提供するかを示す概略図である。追跡サブシステム２１３は、送達プロセスによって生成された情報を統合すると共に送達の状況を追跡するための中心点として働く。それらのステップで記録される情報は以下のように要約される。
【０１００】
ソフトウェア製品の新規リリースまたはバージョン、あるいは既存のソフトウェア製品の修正または変更の開発（ブロック４１１）を開始するとき、開発チームは追跡サブシステム２１３に、製品名、バージョン番号、開発チーム識別子、目標実行プラットフォーム、言語コード、ソフトウェア製品参考資料、構成管理サブシステム２０３に関連する情報（そのソース・コードを含む中央リポジトリ・コンポーネント名）、修正される問題、実装される変更などの関連詳細を記録する。ソフトウェア製品が社内で開発されず、ソフトウェア供給元から購入されるときは、前述したように、通常は、バイナリ・ファイルのみが送達されるはずである。この場合でも、供給されるソフトウェアは送達プロセスの流れに従う必要があり、ソフトウェア送達プロセス担当部門は、追跡サブシステム２１３にその供給元送達の情報を記録する必要がある。
【０１０１】
開発段階が終了したときには、そのアプリケーションを実行するのに必要とされるバイナリ・ファイルを生成するために、そのアプリケーションが構築される（ブロック４１３）。次いで、コード構築を担当する構築チーム（または、ＩＴ組織にそうした担当部門が存在しない場合は、開発チーム自体）は、プロセスのこのステップに関連する情報を追跡サブシステム２１３に記録する。記録される情報の種類の例としては、対応するバイナリ・ファイルの生成元であるソース・コードを含む中央リポジトリ２１５コンポーネント名、生成されたバイナリ・ファイルを含む中央リポジトリ２１５コンポーネント名、（開発チームによって提供された）構築スクリプトおよび文書を含む中央リポジトリ２１５コンポーネント名などの構成管理サブシステム情報、依存関係や前提条件（バージョン間管理、コード・セット・バージョンなど）に関する情報、構築日付、およびもしあれば構築の問題などがある。
【０１０２】
ソフトウェア製品が構築されると、パッケージ・サブシステム２０７によって対応するインストール可能パッケージが生成される（ブロック４１５）。次いで、ソフトウェアのパッケージ化を担当するパッケージ化チームは、このステップに関連する情報を追跡サブシステム２１３に記録する。記録される情報の種類の例としては、インストールを可能にするのに必要なスクリプトおよび応答ファイルを含むソフトウェア配布リポジトリ２１７コンポーネント名や、アプリケーション・パッケージを含むソフトウェア配布リポジトリ２１７コンポーネント名などの構成管理サブシステム情報、アプリケーション・パッケージ、パッケージ名、目標実行プラットフォームの役割、パッケージ化日付、およびもしあればパッケージ化の問題などがある。
【０１０３】
ソフトウェア・パッケージが生成されると、それを配布することができる（ブロック４１７）。次いで、パッケージ化チームは、パッケージの新しい状況（配布可能なパッケージ）を追跡サブシステム２１３に記録する。
【０１０４】
ソフトウェア・パッケージの配布が、おそらく承認の後で、配布およびインストール（ブロック４１９）のために要求されたときには、そのソフトウェア・パッケージを、その役割または機能に従って正しい目標システムに割り当てる必要がある。ソフトウェア配布サブシステム２０９は、ソフトウェア・パッケージの目標プラットフォームへの送達を実施し、パッケージの配布およびインストールを担当する配布チームは、インストールされたパッケージの新しい状況（インストール済みの状況）を追跡サブシステムに記録する。
【０１０５】
本発明による、エンドツーエンド・ソフトウェア送達統合管理のシステムおよび方法の最も顕著で有利な特徴は、以下の通りである。
【０１０６】
ソフトウェア製品の全ライフ・サイクルが、従来技術でのような１組の無関係で独立したプロセスとしてではなく、単一のプロセスとして管理される。
【０１０７】
本発明の統合管理ソフトウェア・システムは、ソフトウェア送達プロセス全体をサポートする固有で包括的な管理システムである。この統合管理システムの各サブシステムは相互に統合され、そのそれぞれが、ソフトウェア送達プロセスの特定のサブプロセスを実装する。
【０１０８】
本発明による統合管理システムは、特定の実装形態で利用されるプラットフォーム、オペレーティング・システム、リポジトリ、データベースとは無関係である。さらに、この統合管理システムは、ソフトウェア・システムおよびその正確な性能の保全性を保証し、様々なソフトウェア・コンポーネントと文書の間の依存性および関係を追跡、制御して、重複を回避し、すべての部分が必要に応じて相互に結びついて機能できるようにする。
【０１０９】
新規のソフトウェア製品、あるいはすでにインストール済みのアプリケーションへの修正や変更など、既存のソフトウェア製品の新規リリースまたはバージョンが、構成管理サブシステムの制御下で中央リポジトリから構築される。
【０１１０】
インストール可能なソフトウェア・パッケージは、パッケージ内容および宛先システムと無関係に生成、配布され、無人の手順によってインストールすることができる。
【０１１１】
有利には、（完全または付加的な）新規ソフトウェア・バージョンを一度構築、パッケージ化して、配布サブシステムのソフトウェア配布リポジトリに記憶することができ、様々な環境でのそのインストール・パッケージの再利用を可能にする。
【０１１２】
さらに、この統合管理システムは、無人インストールのためのソフトウェア・パッケージの自動抽出を可能にし、正しいパッケージがその役割に従って正しい目標システムにインストールされるようにし、任意の特定の環境および段階でのソフトウェア・システムの完全な状況情報をいつでも取り出せるにようにする。
【０１１３】
さらに、この統合管理システムは、異なるプラットフォーム上にある同じソフトウェアの様々なバージョンまたはレベルの間の同期、ならびに、遠隔地にある専門家によって所有され、管理されることの非常に多い異種（すなわち開発、構築、単体テスト、統合テスト、回帰テスト、システム・テスト、生産）環境上で、並列で実行されている同時アプリケーション間の同期を保証する。
【０１１４】
またこのシステムは、ソフトウェア状況の監査記録を残すこともできる。
【０１１５】
本明細書で述べたソフトウェア送達プロセス、およびそれを実装する開示のシステムおよび方法は、管理システムによってサポートされるソフトウェア送達プロセス実装の問題に直面するどんな業務、企業、ＩＴ組織にも適用可能であることを強調しておく必要がある。事実、本発明で説明したシステムの要件および主要な特徴は、一般的なものであり特定の実施形態とは無関係である。
【０１１６】
また、添付の特許請求の範囲によって定義されるように、所与の組織または企業の特定の要件に従って、他の実施形態を使用することも、本発明の範囲を逸脱することなく構造的変更を加えることもできることも理解されたい。
【図面の簡単な説明】
【０１１７】
【図１】一般的な企業の情報インフラストラクチャを示す簡略化した図である。
【図２】本発明の好ましい一実施形態によるソフトウェア送達統合管理システムを示す構成図である。
【図３】図２の統合管理システムによるエンドツーエンド送達プロセスを実装する、本発明の好ましい一実施形態による方法の主要ステップを概略的に示す流れ図である。
【図４】統合管理システムによって実装されるソフトウェア送達プロセスの各サブプロセスと図２の統合管理システムの追跡サブシステムの間の情報交換を概略的に示す図である。
【図１】
2005502118.tif 000003
【図２】
2005502118.tif 000004
【図３】
2005502118.tif 000005
【図４】
2005502118.tif 000006
【国際公開パンフレット】
2005502118.tif 000007
2005502118.tif 000008
2005502118.tif 000009
2005502118.tif 000010
2005502118.tif 000011
2005502118.tif 000012
2005502118.tif 000013
2005502118.tif 000014
2005502118.tif 000015
2005502118.tif 000016
2005502118.tif 000017
2005502118.tif 000018
2005502118.tif 000019
2005502118.tif 000020
2005502118.tif 000021
2005502118.tif 000022
2005502118.tif 000023
2005502118.tif 000024
2005502118.tif 000025
2005502118.tif 000026
2005502118.tif 000027
2005502118.tif 000028
2005502118.tif 000029
2005502118.tif 000030
2005502118.tif 000031
2005502118.tif 000032
2005502118.tif 000033
2005502118.tif 000034
2005502118.tif 000035
2005502118.tif 000036
2005502118.tif 000037
2005502118.tif 000038
2005502118.tif 000039
2005502118.tif 000040
【国際調査報告】
2005502118.tif 000041
2005502118.tif 000042
2005502118.tif 000043