このワークフローの詳細の目的は、複数の実装担当者からの変更内容を統合して、実装サブシステムの新しい一貫性のあるバージョンを作成することです。


トピック


      実装要素
実装要素
  実装要素
実装要素
開発者テスト
開発者テスト
 
         
 
実装担当者
実装担当者
 

 
開発者テストの実装
開発者テストの実装

 
開発者テストの実行
開発者テストの実行

 
           
      開発者テスト
開発者テスト
     

      実装要素
実装要素
統合ビルド計画書
統合ビルド計画書
 
       
 
統合担当者
統合担当者
 

 
サブシステムの統合
サブシステムの統合

 
       
      実装サブシステム
実装サブシステム
ビルド
ビルド
 
      J2EE モジュール
J2EE モジュール
 


説明 ページの先頭へ

同一の実装サブシステムで複数の実装担当者が (チームとして) 作業している場合、個々の実装担当者からの変更内容を統合して、新しい一貫性のある実装サブシステム バージョンを作成する必要があります。その統合は、サブシステム統合ワークスペースに一連のビルドを生み出します。各ビルドは、開発者テストを実行するテスト担当者か実装担当者、またはその両方によって統合テストされます。テストした後に、実装サブシステムをシステム統合ワークスペースにデリバーします。

関連情報 ページの先頭へ

このワークフローの詳細に関連する追加情報へのリンクを提供します。

タイミング ページの先頭へ

推敲フェーズから始まり、作成と移行フェーズまで繰り返されます。

オプション度 ページの先頭へ

大規模システムの場合は推奨。小規模システムの場合はオプション。

要員配置方法 ページの先頭へ

通常、統合は 1 人の人 (ビルド プロセスが簡単である小規模プロジェクトの場合)、または小規模チーム (ビルド プロセスが複雑である大規模プロジェクトの場合) によって実行されます。統合担当者には、ソフトウェア ビルド管理、構成管理の経験と、統合されるコンポーネントを記述するプログラミング言語の経験が必要です。通常、統合には高度な自動化を伴うので、オペレーティング システムのシェルまたはスクリプト言語と、(Unix の) 「make」 のようなツールに関する経験も不可欠です。

作業ガイドライン ページの先頭へ

統合作業は通常は大幅に自動化されますが、ビルドが破壊したときは手動の作業が必要になります。よく利用される対策は、自動化された夜間のビルドと一部の自動化されたテスト (通常はユニット レベルで) を実行し、ビルド プロセスから頻繁にフィードバックが行われるようにするというものです。



Rational Unified Process   2003.06.15