目的
  • 実装サブシステムに含まれている要素を統合する順序を計画する。
役割:  統合担当者 
頻度: 必要に応じて。通常は作成と移行の反復ごとに複数回、推敲の反復作業ごとに最低 1 回行う。
ステップ
入力とする成果物:    結果となる成果物:   
ツール・メンター:   

ワークフローの詳細:   

ビルドの定義 ページの先頭へ

現在の反復について選択されたユース・ケースとシナリオを検討します。 統合の各インクリメントの目標となるシナリオを 1 つ以上選択します。サブシステムに関係するシナリオの一部のみを選択することが必要になる場合があります。

サブシステムを統合する計画を、プロジェクトの「統合ビルド計画書」またはそのサブシステムに固有の統合ビルド計画書で把握します。

クラスの割り出し ページの先頭へ

選択されたシナリオに関係するクラスを割り出します。各シナリオは、設計ユース・ケースの実現のシーケンス図、コミュニケーション図、クラス図で記述されます。実装する必要のあるクラスと、既に実装されているクラスを割り出します。また、シナリオには含まれなくても、スタブとして必要なクラスも割り出します。

クラス・ユース・ケース図

クラスは設計ユース・ケースの実現から割り出されます。

サブシステムのインポートの更新 ページの先頭へ

ビルドに必要な他の実装サブシステムを割り出します。各サブシステムのどのバージョンを使用するかを決定します。サブシステムのインポート依存関係を、他のサブシステムの正しいバージョンに更新します。

新しいシステムのベースラインが最近プロモートされた場合、統合担当者は、サブシステムの統合ワークスペースをいつ更新 (再ベースライン化) するかを決定する必要があります。 この決定は開発のどのサイクルにいるかによって異なります。重要な領域においてサブシステムの開発が不安定な場合は、再ベースライン化を延期できます。

プロジェクトの後半でリリース時期が近づいた (内部または外部を問わず) ときは、サブシステムのインポート・セットが一貫していることが不可欠です。また、システムの現在のベースラインに適合していることも非常に重要です。



Rational Unified Process   2003.06.15