作業:
|
目的
|
|
ステップ | |
入力とする成果物: | 結果となる成果物: |
頻度: 通常この作業は、各フェーズの最初に行われます。場合によっては、方向づけフェーズに 1 度行うだけでよいこともあります。 | |
役割: 構成管理者 | |
ツール メンター: |
ワークフローの詳細: |
目的: | 構成管理ツールのインストールと構成に必要なハードウェア リソースを割り当てる。 |
構成管理者はシステム管理者と共同で、コンピュータ リソースの割り当てと、必要なソフトウェア ツールのインストール作業を行います。
プロジェクト リポジトリ内の実際のデータへのアクセスを仲介するサーバーを実行する専用のコンピュータに対して、次の事項を考慮します (優先順)。
これらの各項目についての情報は、「成果物: プロジェクト リポジトリ」に用意されています。
目的: | 製品ディレクトリ構造を論理的に組織して、プロジェクトに関連するすべての成果物のためのプレースホルダーを確実に用意する。 |
製品ディレクトリ構造は、すべての製品関連の成果物に、論理的にネストされたプレースホルダーを提供します。ディレクトリ (プロジェクトのリポジトリとして機能) の形は、システム全体に含まれるサブシステムの数と各サブシステムに含まれるエレメントの数によります。
分析 / 設計の作業を開始するまで製品の論理構造は現れないにしても、管理と計画の成果物のために初期プロジェクト リポジトリを作成する必要があります。
構造の残りの部分は、設計の決定がなされ、多様な設計のエレメントを実装のためにパッケージする方法について実装ビューの本質がより明確になった時点で考案できます。
実装する各サブシステムのプレースホルダーをディレクトリ構造に作成します。開発する成果物に必要な容量を見積もり、十分な容量の物理記憶領域を確保します。構成管理の目的のためには、ディレクトリ構造の内部エレメント間に高度の結合性が必要です。サブシステムは、システムのそのほかの部分との明白に定義されたインターフェイスを持ち、ビルドおよびテストを独立して実行できる必要があります。その主な理由は、別々のチームによるシステムの並行開発を可能にすることです。この目的は、開発の速度を大幅に上げ、再利用を推進し、システムの保守を容易にすることにあります。
目的: | プロジェクト成果物の初期ベースラインを作成する。 |
構成管理を行わないプロジェクトにおいても、ディレクトリ構造の概念や、プロジェクトで継続的に使用される既存の部品群は存在します。この目的は、その構造に、製品開発のために作成された既存の部品をエクスポート / インポートすることにあります。
目的: | プロジェクト リポジトリに格納されたすべてのエレメントが一連の同じ「正当な」プロモーション レベルを共有するようにする。 |
ベースラインは、プロジェクト リポジトリの 1 つのバージョンです。そのベースラインの品質すなわち状態は、ベースラインのプロモーション レベルによって示されます。プロジェクト リポジトリに格納されたすべてのエレメントは、一連の同じ「正当な」プロモーション レベル (複数のプロジェクトにわたって一貫した定義を持つのが望ましい) を共有します。
Rational Unified Process
|