2.2.1.2 多開發(fā)流模式
項目中有多個不同的開發(fā)流，每個開發(fā)流都是一個獨立的分支，如果項目需要還可以建立多層次的分支，支持并行開發(fā)，適于超過10人，較復雜的項目。如果項目極復雜，可以分為多層開發(fā)流與集成流，如圖二。優(yōu)點：可以并行開發(fā)，每個Stream都相當于一個獨立的開發(fā)環(huán)境，每個人之間的工作不會互相產(chǎn)生干擾；可以通過Policy的設置更好的進行配置管理。
缺點：不同的Stream之間的Deliver與Rebase會產(chǎn)生問題；在merge時也有可能會產(chǎn)生問題，而且對Word等二進制文件的merge支持不好；在修改完成之后，每個Stream上的修改只有deliver與Rebase才能被其他的stream應用，不能及時反映變化；Policy的設置較復雜。
在多開發(fā)流模式下可以根據(jù)需要將某個stream設置為只讀模式。
建議：可以根據(jù)需要建立一個多開發(fā)流模式的Project，但是在初期階段不設立開發(fā)流，在進行詳細設計階段后再建立相應的開發(fā)流。
2.2.1.3 Project組模式
Project組模式是以上兩種模式的組合，適用于產(chǎn)品類項目，在這種類型中，設立一個主干Project，針對不同的客戶或不同的變更，在相應的baseline上建立新的共享流Project去處理，而不是在多開發(fā)流中的Project新建一個開發(fā)流。如果其中某個客戶的要求或變更比較復雜，也可以建一個多開發(fā)流的Project進行處理。
優(yōu)點：可以根據(jù)任務的實際情況靈活處理變更等，而且如果發(fā)現(xiàn)對所有用戶都需要的變更可以在主干上修改并發(fā)布到各個子Project上，也可以在一個子Proejct上修改，經(jīng)驗證后再發(fā)布到其他子Project，對于有長遠規(guī)劃的產(chǎn)品非常適合。
缺點：如果在初架構(gòu)師考慮不周，Component劃分不合理在后期會比較困難；不同Project之間的Deliver需要更復雜的Policy，需要配置管理工程師極有經(jīng)驗。
2.2.2 Activity的命名準則
建議對不同類型的工作可以通過Activity的命名直接區(qū)分，建議如下：
新加功能為：Feature_功能名
變更的執(zhí)行：CR_變更號
注：如果變更中涉及到文檔的修改，則文檔修改也應用此Activity
修改Bug：Bugfix_BUG號
注：BUG號來自ClearQuest
文檔：Doc_文檔名
注：在變更及Bugfix中文檔的修改activity應用變更的activity
計劃的更新：Plan_Tracking_時間
另一建議為選用ClearQuest為缺陷管理工具，并將ClearCase與ClearQuest集成，這樣所有的Activity可以通過ClearQuest獲得。
2.2.3 Deliver與Rebase的準則
項目中需要明確Deliver與準則，包括什么情況下可以Deliver，Deliver前是否全部文件都Check in，是否可以向非本項目的Stream進行Deliver等，這些需要根據(jù)實際情況確定，但是為了盡量避免沖突，建議在Deliver前要求進行Rebase。
2.2.4 配置存儲的邏輯視圖與物理視圖
項目經(jīng)理、架構(gòu)師與配置管理工程師要一起確定項目配置的邏輯視圖，配置管理工程師要根據(jù)情況確定配置的物理視圖。ClearCase的UCM模式中的Component可以理解為配置的邏輯視圖，而VOB的設置可以理解為配置的物理視圖。
2.2.4.1 配置存儲的邏輯視圖：Component
Component可以從系統(tǒng)的架構(gòu)導出，如果應用RUP或項目有Deploy View或Implementation View則可以從中導出Component。
大多數(shù)從其他配置管理工具切換到ClearCase的項目將所有的代碼作為一個Component，這樣雖然簡單，但是失去了使用ClearCase的意義，可以按模塊或3-Tier架構(gòu)來分解代碼，這樣也利于項目組成員理解項目。Component的主要作用是用于重用；設置Component的另一個目的是代碼的權(quán)限控制，如果有外包或?qū)嵙暽煌ぷ�，可以將核心代碼設置為一批Component，將可以由外包或?qū)嵙暽佑|的代碼設置為一批Component，通過對Component的權(quán)限進行設置，可以防止惡意獲取或修改代碼的可能性。
文檔可以按以下兩種方式進行管理：
單獨設置一個文檔VOB，所有的文檔都放在一起，優(yōu)點是權(quán)限控制簡單，可以將文檔提供給其他人員而不用擔心代碼的泄漏，缺點是代碼與文檔分離，工作中可能會出現(xiàn)兩者不一致的問題。
根據(jù)架構(gòu)，同一模塊或Tier的代碼與相應和文檔一個Component中，優(yōu)點是可以保證文檔與代碼的一致性，但是這時要保證代碼與文檔的安全性要繁瑣一些。
