作業:
|
目的
|
|
役割: 統合担当者 | |
頻度: 通常は作成と移行の反復、および可能ならば推敲の反復ごとに最低 1 回。 | |
ステップ | |
入力とする成果物: | 結果となる成果物: |
ツール・メンター: |
ワークフローの詳細: |
反復計画書では、反復で実装する必要のあるすべてのユース・ケースとシナリオが指定されています。現在の反復について、ユース・ケースとシナリオに含まれる実装サブシステムを割り出します。設計ユース・ケースの実現のシーケンス図やコミュニケーション図などを調べます。また、コンパイルを可能にするために、つまりビルドを作成するために必要な他の実装サブシステムを割り出します。
実装サブシステムは設計ユース・ケースの実現から割り出します。
実装サブシステムが 100 近くもある大規模なサブシステムでは、統合計画を立てることは複雑なタスクになります。
統合計画を円滑にし、複雑さを管理するには、検討の必要な事柄の数を減らす必要があります。統合の観点から互いに属していると考えられる、意味のある一連のサブシステム (ビルド・セットまたはタワー) を定義することをお勧めします。「互いに属している」とは、これらのサブシステムがグループとして統合される場合があるという意味で、1 つのサブシステムだけが統合されるという意味ではありません。例えば、サブシステムが実行する (直接的または間接的にインポートする) 必要がある、下位レイヤーにあるすべてのサブシステムが意味のあるビルド・セットになる可能性があります。
これら 2 つのサブシステムがグループとして統合されることが多い場合、ビルド・セットは最下位のレイヤーについて定義されます。ビルド・セットは、サブシステム A をコンパイルして実行する必要があるすべてのサブシステムを使用して定義されます。
ビルド・セットは重複してもかまいません。所有するビルド・セットの種類とその内容は、プロジェクトの継続期間中に変化する場合があります。
ビルド・セットを定義する目的は、統合計画を簡単にできるようにすることです。個々のサブシステムについて考える代わりに、サブシステムのセットについて考えることができます。
一連のビルドを定義してシステムを段階的に統合します。これは通常、実装モデル内のサブシステムの階層構造でボトムアップで実行されます。各ビルドについて、含まれるサブシステムと、スタブとして利用できる必要のあるその他のサブシステムを定義します。次の図では、3 つのビルドが定義されています。
3 つのビルドで実行されるように計画された統合
統合ビルド計画書を評価するには、次のチェックポイントを検討します。
Rational Unified Process
|