私の同僚と私は、ClearcaseUCMを使用してアイデアをストリーミングする必要があります。現在、管理者は機能的なソフトウェアパッケージごとにストリームを作成しており、各パッケージにはインターフェイスが定義されており、階層化されたアーキテクチャ内に存在します。開発者は、作業しているパッケージに応じて子ストリームを作成し、コードを個別に開発しようとしますが、通常、初期開発時に他のパッケージに依存します。これにより、統合グループはシステムビルドを作成し、開発者はこれを使用して、ソフトウェアを開発し、依存関係（zipファイル、パッチなど）を手動で取り込むための適切な環境を作成しました。
私の主張は、これは間違っており、UCMの使用目的ではないということですが、私の信念を確認するには、UCMに精通した誰かが必要でした。
ストリームは機能的な観点から作成する必要があると思います（各パッケージは何らかの機能を果たしますが、複数のアーキテクチャパッケージは、「ABC」と呼ばれる顧客機能の実現に貢献します）。次に、機能「ABC」の初期開発を行っている各アーキテクチャコンポーネントのコンポーネントがストリームに追加されます。関数「ABC」のすべての開発者は、その関数を完了するためにストリーム（または子ストリームのセット）で作業するようになりました。完了すると、各UCMコンポーネントのベースラインが作成され、UCMの観点からコンポーネント間に「バインディング」は存在しません（アクティビティレコードが原因で、これがUCM内で何らかの形で発生する可能性があると誰かが主張しました）。
注：この方法で永遠に作業しないことに同意しますが、インターフェースが一般的に変更される初期開発では、すべての機能のすべてのインターフェースを実装していないため、複数のコンポーネントをストリームで連携させるのが最も理にかなっています。後で、各パッケージが別のパッケージの変更から独立している「アーキテクチャパッケージ中心」の作業方法に移行できます。
考え？長い投稿で申し訳ありませんが、詳細が必要だと感じました。