一个并行例子

    现在，让我们假定一下，对于发布版本6，对相同用例的变更被拆分给两个分析师，以减少开发时间。在这个场景中，需要基准版本的两个TEMP副本。此外，为了保持讨论的简单，我们将我们的场景限定为这一个用例的并行开发。在一个实际的开发周期中，必须作出决定，对于所有相关工件的变更如何进行管理。

决定起始点

    第二个分析师要做的第一件事情是从Rational　ClearCase中检出Create Lead用例的发布版本5的副本，并将其作为一个TEMP文档导入到Rational RequisitePro中。这就是我们的另外的“分支”。

更改Create Lead用例的第二个副本

    在Create Lead用例的第二个TEMP版本中，我们将把变更的其余部分放到用例中。一旦完成了需求工作，并且我们准备好将用例移交给开发人员和QA，分析师就可以一起工作，手动地将两个TEMP文档合并到Rational RequisitePro的基准文档中，以创建基准用例的一个新版本。

进行手动合并

    关于并行开发的合并过程有六个活动：

1. 确定对基准用例的版本5进行的任何变更，这取决于在开发中发现的需求缺陷。
2. 确定对第一个TEMP用例进行的所有变更。
3. 确定对第二个TEMP用例进行的所有变更。
4. 将第二个TEMP用例的变化应用到第一个TEMP用例中。
5. 将第一个TEMP用例的变化应用的基准用例的版本5，创建基准用例的新版本。
6. 更新需求标记和追踪。

    一旦所有的变更都已经被应用到基准用例的版本5，就可以正式地成为版本6。基于新的基准用例，开发人员可以在Rational Rose中更新模型，并且测试人员可以更新测试用例。在分析和设计以及测试规程期间，新的基准用例可能基于开发人员和测试人员的反馈直接被更新。这可能会再次引起模型和测试用例的变更。一旦新的代码被转到集成测试和QA测试，对于最终的构造和用户验收测试来说，代码就准备好内部或外部部署了。

    一旦进行了内部或外部的部署，就该再次对Rational ClearCase中的基准用例进行存档了，为下一个迭代或发布版本的可能的新变更集做好准备。当用例被基线化时，用例的发布就正式结束了（参见图11）。

图11：并行开发周期