ワークフローの詳細:
|
このワークフローの詳細の目的は、実装サブシステムを統合して、システム全体の新しい一貫性のあるバージョンを作成することです。 |
|||||||||||||||||||||||||||||||||||||
|
|
統合担当者が、デリバーされた実装サブシステムをシステム統合ワークスペースに追加しビルドを作成することによって、統合ビルド計画に従ってシステムを統合します。各ビルドは、テスト担当者によって統合テストされます。最後の追加の後に、テスト担当者がビルドを完全にシステム テストすることができます。
このワークフローの詳細に関連する追加情報へのリンクを提供します。
推敲フェーズから始まり、作成と移行フェーズまで繰り返されます。
必須 (ただし、小規模システムでは、サブシステムの個別の統合がない場合もあります)
通常、統合は 1 人の人 (ビルド プロセスが簡単である小規模プロジェクトの場合)、または小規模チーム (ビルド プロセスが複雑である大規模プロジェクトの場合) によって実行されます。統合担当者には、ソフトウェア ビルド管理、構成管理の経験と、統合されるコンポーネントを記述するプログラミング言語の経験が必要です。通常、統合には高度な自動化を伴うので、オペレーティング システムのシェルまたはスクリプト言語と、(Unix の) 「make」 のようなツールに関する経験も不可欠です。
統合作業は通常は大幅に自動化されますが、ビルドが破壊したときは手動の作業が必要になります。よく利用される対策は、自動化された夜間のビルドと一部の自動化されたテスト (通常はユニット レベルで) を実行し、ビルド プロセスから頻繁にフィードバックが行われるようにするというものです。
Rational Unified Process
|