ビルドとは、最終製品で提供されることになっている機能の一部を例示する、システムまたはシステムの一部の動作するバージョンのことです。ビルドは、それぞれ別の要素群から成る 1 つ以上の実装要素 (多くの場合実行可能ファイル) を構成し、通常はソース コードのコンパイルとリンクのプロセスによって作成されます。
役割:  統合担当者 
オプション度 / 使用時期:  各反復
テンプレートとレポート: 
 
例:   
UML の表現:  «build» としてステレオタイプ化される、実装モデル内のパッケージ (モデルの最上位のパッケージまたは実装サブシステムのどちらか) 
詳細情報:   
成果物を入力とする作業:    成果物を出力とする作業:   

目的 ページの先頭へ

実装内のほかの要素群から構成されるビルドの目的は、システムの実行時の機能と能力のテスト可能なサブセットを提供することです。RUP (Rational Unified Process) では、一連のビルドを反復の間に作成し、実装サブシステムの要素が追加または改良されるたびに、各ビルドにその機能を追加することを提案しています。ビルドは、単独のサブシステムまたは複合サブシステムを含む、システムのどのレベルにおいても作成できますが、RUP では特に成果物: 統合ビルド計画書で定義されるビルドを重視しています。これは、これらのビルドが反復を完了するための手段となっているためです。システムの規模または複雑さから見て妥当と考えられる場合には、統合ビルド計画書を、それぞれ個別のサブシステムを対象とする複数の計画書に分割することができます。

単体テストの実施などの適切な理由があれば、実装担当者が、自身の個人的な開発ワークスペースや、サブシステムとシステムの統合ワークスペースにある要素を使用して、非公式のビルドを作成してもよい、ということに注意してください。ただし、この文書で定義する用語としての正式なビルドは、実装担当者がサブシステムまたはシステムの統合ワークスペースに入れた正規の要素を使用して、成果物: 統合ビルド計画書に定義されている手順で統合担当者が作成します。

プロパティ ページの先頭へ

プロパティ名 

概要 

UML の表現 

Description  ビルドの簡単な説明のテキスト  「short text」型のタグ付き値 
Implementation Subsystems  ビルドで表されるサブシステム  メタ関連「represents」を通して、またはメタ集約「owns」を通して再帰的に所有される 
Elements  サブシステムに属するビルド内の実装要素  メタ集約「owns」を通して再帰的に所有される 
Integration Build Plan Reference  対応する統合ビルド計画書内の、ビルドの詳細な説明への参照  タグ付き値 

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

ビルドは毎回の反復を対象に、成果物: 統合ビルド計画書で定義されているとおりに作成されます。RUP では、特定のタイミングまたは頻度を指定する必要はありません。これらはプロジェクトの固有のニーズに応じて選択されます。もちろん、適度に自動化することによって、ビルドを毎日作成するという方針を採用することも可能です。その場合、あるストリーム上の安定した要素群を実装担当者から入手し、それらを統合し、夜間のビルドの結果をテストします。この方法はどのプロジェクトにも適しているわけではなく、特に、長時間の回帰テストを必要とする大規模なプロジェクトには不向きです。

責務 ページの先頭へ

統合担当者は、ビルドの作成に責任を持ちます。開発がサブシステム単位で (それぞれ担当のチームを決めて) 計画され、その後それらのサブシステムがシステムに統合される場合、統合担当者の役割を複数の人物が分担する場合があります。たとえば、(サブシステムレベルでの統合を行うために) 各サブシステム チームに 1 人ずつ統合担当者を置き、それとは別にシステムレベルの統合担当者を任命する、というケースが考えられます。

カスタマイズ ページの先頭へ

ビルドの作成は必須ですが、プロジェクトで作成されるビルドの種類は、ライフサイクルを通じて変化します。方向づけフェーズでは、問題の理解度や顧客とのコミュニケーションを向上させるための手段としてプロトタイプの作成に重点を置くかもしれませんし、推敲フェーズでは安定したアーキテクチャの確立に、作成フェーズでは機能の追加にそれぞれ重点を置くかもしれません。移行フェーズでは、ソフトウェアが納品可能な品質に到達していることの保証に焦点が移ります。



Rational Unified Process   2003.06.15