目的
  • システムの統合を計画する。
役割:  統合担当者 
頻度: 通常は作成と移行の反復、および可能ならば推敲の反復ごとに最低 1 回。
ステップ
入力とする成果物:   結果となる成果物:   
ツール・メンター:   

ワークフローの詳細:   

サブシステムの割り出し ページの先頭へ

反復計画書では、反復で実装する必要のあるすべてのユース・ケースとシナリオが指定されています。現在の反復について、ユース・ケースとシナリオに含まれる実装サブシステムを割り出します。設計ユース・ケースの実現のシーケンス図やコミュニケーション図などを調べます。また、コンパイルを可能にするために、つまりビルドを作成するために必要な他の実装サブシステムを割り出します。

反復図のユース・ケースとシナリオ

実装サブシステムは設計ユース・ケースの実現から割り出します。

「ビルド・セット」の定義 ページの先頭へ

実装サブシステムが 100 近くもある大規模なサブシステムでは、統合計画を立てることは複雑なタスクになります。

統合計画を円滑にし、複雑さを管理するには、検討の必要な事柄の数を減らす必要があります。統合の観点から互いに属していると考えられる、意味のある一連のサブシステム (ビルド・セットまたはタワー) を定義することをお勧めします。「互いに属している」とは、これらのサブシステムがグループとして統合される場合があるという意味で、1 つのサブシステムだけが統合されるという意味ではありません。例えば、サブシステムが実行する (直接的または間接的にインポートする) 必要がある、下位レイヤーにあるすべてのサブシステムが意味のあるビルド・セットになる可能性があります。

ビルド・セット図の例

これら 2 つのサブシステムがグループとして統合されることが多い場合、ビルド・セットは最下位のレイヤーについて定義されます。ビルド・セットは、サブシステム A をコンパイルして実行する必要があるすべてのサブシステムを使用して定義されます。

ビルド・セットは重複してもかまいません。所有するビルド・セットの種類とその内容は、プロジェクトの継続期間中に変化する場合があります。

ビルド・セットを定義する目的は、統合計画を簡単にできるようにすることです。個々のサブシステムについて考える代わりに、サブシステムのセットについて考えることができます。

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

一連のビルドを定義してシステムを段階的に統合します。これは通常、実装モデル内のサブシステムの階層構造でボトムアップで実行されます。各ビルドについて、含まれるサブシステムと、スタブとして利用できる必要のあるその他のサブシステムを定義します。次の図では、3 つのビルドが定義されています。

3 つのビルドを統合する計画のダイアグラム

3 つのビルドで実行されるように計画された統合

統合ビルド計画書の評価 ページの先頭へ

統合ビルド計画書を評価するには、次のチェックポイントを検討します。

  • エラーを特定しやすい統合の順序になっているか。
  • スタブの必要性が最小限で済むような統合の順序になっているか。
  • 統合の順序とコンポーネントの開発順序とは調整が取れているか。


Rational Unified Process   2003.06.15