プロジェクトの拡張および複雑度の増大に伴い、「プロジェクト拡大」のためのいくつかのオプションが用意されています。場合によっては、新規要素を単一の IBM® Rational® Rhapsody® プロジェクト内に継続して追加することが最良の方法となります。新規プロジェクトを作成するほうがより効果的な場合もあります。
すべてのシナリオに合うような単一の解決方法はありません。プロジェクトの拡大および拡張に備えて計画を立てる場合は、以下の点を考慮してください。
- 単一プロジェクトの場合、1 つのプロパティーまたはプロパティーのセットをすべてのモデル要素に適用することは簡単です。複数のプロジェクトの場合は、プロセスをプロジェクトごとに実行する必要があります。
- プロジェクトに関連付けられた構成管理アーカイブは、プロジェクト・レベルのプロパティーに保管されます。そのため、プロジェクトを複数のアーカイブに保管する場合は、アーカイブごとに個別のプロジェクトを作成する必要があります。
- すべてのチーム・メンバーがすべての設計パーツ (メンバーに直接関係のないパーツを含む) を認識している状態にさせる場合、プロジェクトを 1 つにすることをお勧めします。
- 各メンバーが自分の作業に関連する要素のみを表示するように、別のチーム・メンバーの作業を分離させたい場合は、複数のプロジェクト (各チーム・メンバーに対して 1 つ) を作成してください。
- システムのさまざまなコンポーネントに携わる分散チームは、プロジェクト全体を複数のより小さいプロジェクトに分割することで、メリットを得ることができます。
- プロジェクトの複雑さを軽減する必要がある場合は、複数のプロジェクトを作成して、プロジェクト全体に対する各機能を定義してカプセル化することができます。
この方法では、すべてのチーム・メンバーがプロジェクト全体のすべての要素にアクセスできます。
- プロジェクトがバイナリーの再利用パターンで実行されている場合は、複数のプロジェクトに分割します。
モデルの再利用パターンを使用している場合は、分割しないでください。
- 最終製品を作成するためにインターリーブされた複数のバイナリー・コンポーネント (例えば、1 つ以上の実行可能ファイルで使用される一連のライブラリー) にプロジェクトがマップされる場合に、これらのコンポーネントを単一のプロジェクトに配置すれば、チーム・メンバーが、コンポーネントの内部だけでなく、コンポーネント図を使用してコンポーネント間の関係を設計する際に便利です (Make ファイルでは、コンポーネント間の関係が考慮されます)。
以下の点は、通常、1 つのプロジェクトを複数のプロジェクトに分割する決定に影響しません。
- プロジェクトを Rational Rhapsody 内にロードする時間。部分ロード・フィーチャーを使用すれば、プロジェクト全体ではなく、現行タスクに必要なユニットのみをロードすることができます。
- オペレーティング・システム。複数のオペレーティング・システムをターゲットとする 1 つの設計を再生成する必要がある場合は、複数のプロジェクトを作成する必要はありません。
プロジェクト全体の構成方法の決定は変更することができます。1 つのプロジェクトを 2 つのプロジェクトに簡単に分割することができ、また 2 つのプロジェクトを 1 つのプロジェクトにマージすることもできます。