2.2.1.2 多开发流模式

项目中有多个不同的开发流，每个开发流都是一个独立的分支，如果项目需要还可以建立多层次的分支，支持并行开发，适于超过10人，较复杂的项目。如果项目极复杂，可以分为多层开发流与集成流，如图二。优点：可以并行开发，每个Stream都相当于一个独立的开发环境，每个人之间的工作不会互相产生干扰；可以通过Policy的设置更好的进行配置管理。

缺点：不同的Stream之间的Deliver与Rebase会产生问题；在merge时也有可能会产生问题，而且对Word等二进制文件的merge支持不好；在修改完成之后，每个Stream上的修改只有deliver与Rebase才能被其他的stream应用，不能及时反映变化；Policy的设置较复杂。

在多开发流模式下可以根据需要将某个stream设置为只读模式。

建议：可以根据需要建立一个多开发流模式的Project，但是在初期阶段不设立开发流，在进行详细设计阶段后再建立相应的开发流。

2.2.1.3 Project组模式

Project组模式是以上两种模式的组合，适用于产品类项目，在这种类型中，设立一个主干Project，针对不同的客户或不同的变更，在相应的baseline上建立新的共享流Project去处理，而不是在多开发流中的Project新建一个开发流。如果其中某个客户的要求或变更比较复杂，也可以建一个多开发流的Project进行处理。

优点：可以根据任务的实际情况灵活处理变更等，而且如果发现对所有用户都需要的变更可以在主干上修改并发布到各个子Project上，也可以在一个子Proejct上修改，经验证后再发布到其他子Project，对于有长远规划的产品非常适合。

缺点：如果在初架构师考虑不周，Component划分不合理在后期会比较困难；不同Project之间的Deliver需要更复杂的Policy，需要配置管理工程师极有经验。

 2.2.2 Activity的命名准则

建议对不同类型的工作可以通过Activity的命名直接区分，建议如下：

新加功能为：Feature_功能名

变更的执行：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等，这些需要根据实际情况确定，但是为了尽量避免冲突，建议在Deliver前要求进行Rebase。

2.2.4 配置存储的逻辑视图与物理视图

项目经理、架构师与配置管理工程师要一起确定项目配置的逻辑视图，配置管理工程师要根据情况确定配置的物理视图。ClearCase的UCM模式中的Component可以理解为配置的逻辑视图，而VOB的设置可以理解为配置的物理视图。

2.2.4.1 配置存储的逻辑视图：Component

Component可以从系统的架构导出，如果应用RUP或项目有Deploy View或Implementation View则可以从中导出Component。

大多数从其他配置管理工具切换到ClearCase的项目将所有的代码作为一个Component，这样虽然简单，但是失去了使用ClearCase的意义，可以按模块或3-Tier架构来分解代码，这样也利于项目组成员理解项目。Component的主要作用是用于重用；设置Component的另一个目的是代码的权限控制，如果有外包或实习生一同工作，可以将核心代码设置为一批Component，将可以由外包或实习生接触的代码设置为一批Component，通过对Component的权限进行设置，可以防止恶意获取或修改代码的可能性。

文档可以按以下两种方式进行管理：

    单独设置一个文档VOB，所有的文档都放在一起，优点是权限控制简单，可以将文档提供给其他人员而不用担心代码的泄漏，缺点是代码与文档分离，工作中可能会出现两者不一致的问题。
    根据架构，同一模块或Tier的代码与相应和文档一个Component中，优点是可以保证文档与代码的一致性，但是这时要保证代码与文档的安全性要繁琐一些。