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