作業:
|
目的
|
|
ステップ | |
入力とする成果物: | 結果となる成果物: |
頻度: ビルドごとに最低 1 回 | |
役割: 統合担当者 | |
ツール メンター: | |
More Information: |
ワークフローの詳細: |
この作業が始まる時点で、成果物: 統合ビルド計画書に記述されている、次の (「ターゲット」) ビルドの要求を満たすために、既に実装サブシステムが提供されています。これは、統合ビルド計画書では、1 つの反復内に複数のビルドのニーズが定義される場合があることを示しています。統合するサブシステムの複雑さと数によっては、ステップごとにサブシステムを追加し、一連の中間「ミニ」ビルドを作成することによって、多数のステップで対象ビルドを作成するほうが効率的な場合があります。したがって、反復で計画される各ビルドが、独自の一時的な中間ビルドのシーケンスを持つ可能性があります。追加するものが、システム統合ワークスペースに既に存在するものと互換性があることを確認するために、これらは、最低限の統合テスト (通常、この対象ビルドの統合ビルド計画書に記述されているテストのサブセット) を受けなければなりません。この方法を使用して、問題を分離し診断するほうが簡単です。
統合担当者は、マージでの競合を解決するプロセスで、納品されたサブシステムをシステム統合ワークスペース内に段階的に受け入れます。サブシステムのバージョンが一貫していることを確認し、インポートを考慮に入れながら、レイヤ構造の下から上へ順に、この作業を行うことをお勧めします。サブシステムの追加が中間ビルド内でコンパイル、リンクされます。次に、この中間ビルドは、最小限のシステム統合テストを実行するためにテスト担当者に渡されます。
このダイアグラムは、3 回の追加で作成されるビルドを示しています。一部のサブシステムは、ほかのサブシステムをコンパイル、リンクできるようにし、重要な最低限の実行時の振る舞いを提供するスタブとしてのみ必要になります。
シーケンスの最終追加で、統合ビルド計画書に計画されているように、対象ビルドが作成されます。このビルドの最小限のテストが終わると、初期または暫定のベースラインが作成され、。この時点で、このビルドは、完全なシステム テストのためにテスト担当者に渡すことが可能になりました。このテストの性質と深度は、統合ビルド計画書で計画されているとおりになります。反復の最終ビルドは、反復テスト計画書に定義されたすべてのテストを受けます。
ビルドがテストのさまざまなレベルに合格するのに合わせて、その関連ベースラインもプロモートされます。 プロモーションとは、ベースラインが特定レベルのテストに合格または失格したことを示す手段です。プロモーション レベルの名前は、役割: 構成管理者で、。プロモーション レベルは、ベースラインを使用するユーザーにとって重要です。たとえば、実装担当者が、システム統合ワークスペース内のベースラインと一致させるためにプライベート開発ワークスペースを更新 (または「ベースラインを再作成」) する前に、ベースラインが安定していてテスト済みであることを知る必要が生じます。
Rational Unified Process
|