2 つ目は、共通プロジェクトを使用することです。3 つのプロジェクト (team1.pj、team2.pj、および header.pj) がサブプロジェクトとして含まれるマスタ プロジェクトを作成できます。

この構造では、共有リソースの所有者に柔軟性があります。共通プロジェクトの所有権と変更権限を、両方のチームに与えることができます。

また、ACL 権限を使用して、所有権と変更権限を一方のチームだけに与えることもできます。この解決方法からさらに、共通プロジェクトのすべての変更に責任を持つチームを別個に作成する方法も考えられます。この方法では、共通プロジェクトをサブプロジェクトとして持つ他のプロジェクトについて、共通プロジェクトを変更するチームが認識しておくことによって、互換性の問題にも対処できます。これによって互換性が確保されます。

チーム 1 とチーム 2 は、それぞれのコードの更新に集中でき、共有ファイルにコードとの互換性があるという確信を持つことができます。互換性に関する問題があれば互換性チームに報告され、このチームが対応します。

この構造で開発を行うとき、ユーザーはマスタ プロジェクトのサンドボックスを作成し、対応するサブプロジェクトに再帰します。複数のサブプロジェクト内のファイルを操作するという発想には抵抗があるかもしれません。こうした作業環境の変更の際には、新しい操作手順に慣れるための時間が必要です。

マスタ プロジェクトから再帰すると、更新とリリースの条件が問題となります。ただしこの解決方法では、この問題もある程度まで制御できます。チーム内のユーザーは、マスタ プロジェクトから作業を開始する必要はありません。代わりに、自分のチームのプロジェクトのサンドボックスを作成し、共通プロジェクトのサンドボックスも別途作成できます。このように分離することで、共通プロジェクトのバージョンを自由に選択できます。

この場合、共通プロジェクトは独自のリリース サイクルを持ち、サイクルごとにチェックポイントが作成されます。各チームは、共通リソースの特定のリリースに基づいて共通プロジェクトのビルド サンドボックスを作成し、開発に使用できます。

一方、自チームの変更を他チームから分離し、他チームの変更を共通プロジェクトから分離しながら、共通プロジェクト内で特定のリリース ベースラインから開発を続行する場合も考えられます。この場合は、共通プロジェクトのバリアント サンドボックスを作成して使用できます。

最後の方法は、共通プロジェクトから標準サンドボックスを作成し、状態が流動的である可能性を認識したうえで、そのまま使用することです。開発の初期段階では、この方法でも差し支えない場合や、かえって望ましい場合もあります。このタイプのプロジェクト構造には柔軟性があり、開発途中の方針変更も可能です。

共通プロジェクトでは開発プロセスを柔軟に管理できますが、この方法を使用すると次の 2 つの問題が発生する可能性があります。

Windchill RV&S では、サーバーのリポジトリ上のどの場所にあるソース ファイルも管理できます。Windchill RV&S では、プロジェクト ファイルへの相対パスを使用して、同じディレクトリ内やそのサブディレクトリ内のプロジェクト メンバーを特定します。