如果你正在使用Rational^® RequisitePro^®中的基于文档的需求，并且你已经在你的公司里成功地实施了Rational Unified Process^®和Rational工具，那么你就已经有了一个“团队组的团队”如何学会在RUP的工作流程之下一起工作的第一手经验。当我们的几个项目经理自告奋勇地按照一个方案，通过并行的、非重叠的迭代来缩短开发时间，并且更好地利用他们的开发资源时，我们就处于这个阶段了。他们不断地问，“为什么我们要在分析师编写用例时让开发人员无所事事，并且在开发人员编写代码时让分析师无所事事呢？”这听起来的确像一个合理的问题。但是对于并行地开发需求，还有其它的，甚至更引人关注的争论。

首先，如果有多个分析师，他们必须对相同的需求工件，或者是相同的迭代和项目中的，或者是不同的迭代和项目中的，更新些什么吗？在我们的集成系统中，这个场景是有可能的。另外，我们经过了创建所有新的用例的阶段，并且已经在Rational RequisitePro中不断开发出用例集和相关的工件。我们如何为了下一个发布包，处理这些已有工件的变更？

当我们考虑整个变更管理流程以及其如何影响我们已有的业务建模和需求工件集时，我们看到了几个相互冲突的要求：

• 我们已经知道，我们需要对我们在RequisitePro中已有的用例和相关工件进行变更，并让业务经理、测试人员和开发人员对他们进行评审－－并最终被批准。
• 尽管我们知道我们想进行的一些变更，但是由于在用例讨论和评审过程中出现的需求易变性，我们也想延迟直接地编辑现有的用例和相关工件。对需求的变更影响到已有的标记和追踪，并且我们想要确定我们的变更在我们开始编辑之前是稳定的。
• 我们想要延迟的另一个原因是已有的用例和相关工件表示的是当前的产品发布版本，因此我们想要每个人都能访问他们。我们知道如果在生产过程中发现需求缺陷的话，我们以后可能不得不修改他们。

认识到这些需求都是相互关联的，并且我们将必须找到对他们全部作出响应的方法，我们要接受这些挑战。我们决定不只是指出如何版本化我们的需求工件，而且还有如何并行地开发需求工件。

你可能会问，为什么是“需求工件”而不是“需求”呢？Rational RequisitePro有能力指出你正在查看一个需求的哪一个版本吗，是通过属性吗？需求可以存在于相同用例的不同级别中吗？

这两个问题都问得很好。但是坦率地说，我知道从开始，我不想在需求级别进行版本化。我总是将一个用例认为是一个完整的需求工件，类似于一个组件。相反，我的本能告诉我，要注意已经有多年并行开发代码经验的编程人员，并以他们为榜样。如果需求通过配置管理工具和技术来进行管理，我们所发现的就有益于开发组织。

程序人员了解什么是：串行和并行开发

如果你现在或曾经是一个程序员，那么你就已经熟悉串行和并行开发的概念了。串行开发在开发一个单独的软件发布版本，并且同时只有一个人工作在一个特定文件上时出现。在软件维护期间修复的缺陷被包含在下一个发布版本中。并行开发在多个个人或团队工作在不同的发布版本，并对同时对相同的文件进行修改时产生。并行进行的修改随后和维护时修复的缺陷合并在一起。^® ClearCase^®通过支持分支 和 合并管理并行开发的复杂性。

用简单的语言来说，一个分支是一个线性的版本序列。合并是一种技术，通过合并，一个文件的不同版本被协调和合并在一起，产生文件的一个新版本（参见图1）。在ClearCase中，有一个diff/merge工具，其并排显示两个文件，高亮显示差异，并允许一个开发人员选择哪些变化将被合并到文件的新版本中。

图1：Rational ClearCase带有合并的版本树

一个串行例子

现在，我们已经理解了分支和合并的概念，我们可以将他们应用于Rational RequisitePro中的需求工件。比方说，我们的软件的发布版本5处于开发中，我们的项目经理正在计划开发发布版本6的迭代。在发布版本6中的新功能将需要对Create Lead用例进行变更。为了使讨论简单化，我们将限制我们的场景为此用例的串行开发，并且紧记在一个实际的开发周期中，我们将必须作出如何管理所有相关工件变更的决策。

基线化用例

当发布版本6正式开始时，我们想要进行的第一件事情就是确保Create Lead用例已经被基线化了。依照RUP，一个基线是项目存储库中某个时间的每一个工件的一个版本的“快照”。一个基线化的用例表示的是与当前在开发的代码协调一致的需求。 ¹ 它提供了一个正式的标准，后续的工作就是基于它进行的，并且只有经过审核的变更才能修改它。一旦我们基线化了我们的用例，我们就可以继续修改它，我们知道这是安全的，因为我们有一个已存档的原始需求的副本。

要基线化Create Lead用例，我们使用我们的一个Rational顾问用Visual Basic编写的存档工具。这个存档工具使用Rational RequisitePro和ClearCase COM APIs（组件对象模型应用程序接口），其提供的功能可以将我们的RequisitePro的一些文档存档到ClearCase视图中的一个目录下，并且在它们被加入到视图时可以将标签应用到存档后的文件上。这些ClearCase存档视图允许分析师访问存档后的文件所存放的ClearCase的目录结构。

准备一个用于存档的工件

在我们进入到存档工具之前，必须要在Rational RequisitePro中做一些事情以准备要存档的文档。在Project Properties菜单中，我们取消“Save documents in RequisitePro Format”复选框，这样可以阻止RequisitePro中的文档在RequisitePro之外被成功地打开（参见图2）。我们想要将Create Lead用例的存档副本用Microsoft Word格式进行存储，因此它可以在任何时候都被检出和查看。在存档工具运行起来之后，我们应该重新设置Project Properties，重新选中“Save documents in RequisitePro Format”复选框。这样做失败的话将会导致RequisitePro中的文档的损坏。因此我们鼓励我们的分析师创建他们自己的存档活动的检查单，以确保此步骤不会被忘掉。（可能此存档工具以后的版本将会通过RequisitePro API来做这件事情。）

图2：在存档后，记住重新选中“Save documents in RequisitePro Format”复选框

存档Create Lead Use Case用例

下一步是启动存档工具的可执行程序，我们可以通过桌面上的一个快捷方式进行。图3显示了在启动存档工具程序后立刻出现的画面。

图3：启动之后的存档工具程序

一旦启动了存档工具程序：

• 输入Create Lead用例的版本名称作为ClearCase标签，并输入存档目录的完全路径名作为存放位置。同样选中复选框，表示此目录是在ClearCase视图中。
• 下一步，使用驱动器和目录浏览特性，选择合适的Rational RequisitePro项目文件（*.rqs）。
• 选中了RequisitePro项目之后，点击“Get Docs”按钮，调出RequisitePro项目中的所有文档。完成这些工作时，你将被要求登录到RequisitePro数据库中，即使你没有进入的安全权限。这是因为你必须提供一个用户名和密码来通过API连接到RequisitePro数据库中。
• 只要取得了文档，你就可以使用工具程序右下角的Document Type选择器来通过文档类型过滤他们。图4显示了文档类型UC（用例），TWA（测试工作量分析）和TPL（测试计划）。
• 浏览项目文档列表，并在Create Lead用例上点击选中它。
• 然后点击Archive按钮，存档工具程序将Create Lead用例复制到ClearCase视图目录下，对其应用标签，并检入文档。存档工具程序将允许在存档时选择多个文档。

图4：带有Rational RequisitePro列表的存档工具程序

在存档工具程序完成之后，并且你已经在RequisitePro中重新选中了Project Properties，你就可以很容易地验证到，你的文档已经通过使用ClearCase Explorer存档到了ClearCase中，并可以定位到此文件和检查其标签。我们通过右键点击此文件并选择菜单“Version Tree”，可以做这件工作。这会启动ClearCase 版本树浏览器，并显示你的文档的版本1的树状视图。参见图5。（说明：尽管在ClearCase中用例的副本已经有了一个UC后缀，但是它已经用Microsoft Word格式被保存下来，并可以被检出，以及任何时候都可以在RequisitePro外部用Word打开。）

图5：Rational ClearCase Explorer 和版本树浏览器

创建TEMP用例

由于你已经存档了Create Lead用例，你就可以在Rational RequisitePro中继续创建Create Lead用例的修改版本。考虑到这一点，你需要在RequisitePro中定义一个额外的文档类型来处理变更的工件。在Sears，我们选择TEMP作为此文档类型，并在RequisitePro中创建TEMP文档类型。TEMP文档类型可以用于在开发期间修改的任何文档（参见图6）。

图6：TEMP文档类型定义

接下来，用MS Word的“Save As”产生一个Create Lead用例的副本，并且随后将其导入成一个RequisitePro中的新的TEMP文档。Create Lead用例的TEMP版本与基准版本基本上是完全相同的，除了用下划线显示的需求文本替代了标记的需求。这个TEMP用例是你的“分支”，用于分支和合并功能（参见图７）。

图7：Rational RequisitePro的“分支和合并”

在Create Lead用例的TEMP版本中，我的团队进行了下一个发布版本的所有变更。TEMP文档会被我们用于用例讨论会和评审，并且TEMP文档也是在签发时的业务协定。

为了帮助确定在基准和TEMP用例中进行删除和变更，我们的分析师创造了他们自己的方法，即在Microsoft Word中用颜色显著标记，这改善了沟通理解并加速了评审过程。一个分析师（其具有编程背景）使用MS Word比较功能来核实是否有变更被遗漏了，但是如果你这样做的话，记住Word比较并不识别颜色显著标记。

要识别变更了什么，首先要看一下基准用例（参见图8）。

图8：基准用例

图９显示了在编辑和颜色显著标记之后的TEMP用例的一个简单例子。黄色表示变更的文本，蓝色表示即将被删除的文本。分析师最好还是使用用例工件的文档修订历史来记录变化。注意，本例子并没有使用Microsoft Word的修订标记特性，因为这是与Rational RequisitePro有冲突的。

图9：编辑和颜色显著标记TEMP用例

一旦我们为此用例完成了需求工作，并且准备好将此用例移交给开发人员和QA，我们就可以将TEMP文档手动地合并到Rational RequisitePro中的基准文档，以创建基准文档的一个新版本。

进行手动合并

合并过程有三个基本活动：

1. 第一个活动是确定对基准用例进行的所有变更，这取决于在开发过程中发现的需求缺陷。
2. 第二个活动是确定已经对TEMP用例进行的所有变更，TEMP用例将必须被应用到基准用例中。
3. 第三个活动是将这些变更应用到基准用例中，包括需求的标记和追踪，要创建新的基准用例的一个新版本。要意识到，这意味着在批准对TEMP用例的变更和基准用例的实际更新之间的过程中有一个延迟。不要这个延迟导致忘记一些事情。

只要基准用例被更新完成，它就正式成为一个更高的版本。从基准用例的新版本中，开发人员可以在Rational Rose®中更新序列图，并且测试人员可以更新测试用例。 ² 在分析和设计以及测试期间，新的基准用例可能被直接更新，以响应来自开发人员和测试人员的反馈。这可能会再次引起对模型和测试用例的变更。一旦新的代码通过了集成测试和QA测试，对于最终的构造和用户验收测试来说，代码已经准备好部署了。

一旦进行了部署，就该再次对Rational　ClearCase中的基准用例进行存档了，为下一个发布版本的新的变更集做好准备。当用例在部署之后被基线化时，包开发就正式结束了（参见图10）。记住：为了方便起见，在ClearCase中的用例副本具有UC后缀，但是用Microsoft Word格式来保存的；它可以被检出，并在Rational RequisitePro之外用MS Word打开。

图10：串行开发周期

一个并行例子

现在，让我们假定一下，对于发布版本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：并行开发周期

作出决策：串行或并行开发？

以下的考虑事项可能帮助你对Rational RequisitePro中的需求工件进行版本化和并行开发作出决策。

需求工件的版本化是可选的，当

• 修改对基本需求的影响是可以忽略的。
• 需求修改的时间选择对按照需求来执行的其它工作流的影响是可忽略的。
• 修改对已有的工件没有影响，或者是因为没有已有的工件，或者是当前的迭代不会影响到已有的功能。

需求工件的版本化是被强烈推荐的，当：

• 并行地完成需求的一个迭代，并按照完整的需求工件执行其余的工作流，你正在捕获需求的下一个迭代－－并且影响到当前正在被实现、构造、测试等等的工件。
• 需求工件正在被一个当前项目修改，并且由于开发中的需求缺陷需要被修改。
• 多个分析师正在更新相同的需求工件，或者是对相同的迭代和项目，或者是对不同的迭代和项目。

如果你发现自己处于以上描述的“强烈推荐”场景的任何一个，那么我希望在Rational RequisitePro 和 Rational ClearCase中进行需求工件的版本化和并行开发的这些说明已经激起你足够的兴趣，对其尝试一下。尽管有一定量的手工工作和复杂性，但是我的团队的分析师能够将这些步骤成功地合并到他们的RUP下的需求管理活动，并对我们整个团队产生受益：我们能够更有效地使用我们的资源，并更有效地管理变更的影响。

附录：存档工具程序

下载本文所提到的存档工具程序（在Rational ClearCase 5.0 和 Rational RequisitePro 2002中测试过）。

感谢

我希望感谢Empowered Software Solutions的Suzette Boyce对并行开发提供她的信息，她在The Great Indoors/Sears作为系统分析师工作时引导了这些并行开发技术。Empowered Software Solutions的Guy Thier提供了一个项目经理对并行开发的观点。Sears Roebuck and Co.的系统分析师Wendy Smith 和 Joe Mack 对编辑本文提供了帮助。

说明

¹ 已经达成一致的需求通常，但不总是，完全与产品代码同步。例如，在由需求的一个缺陷引起的一个产品修复和对相应用例的必要更新之间，可能会有一个时间滞后。

² 由于开发人员和测试人员参与了用例评审，他们非常熟悉这些变更。他们也要打印TEMP工件的副本，并且可以在RequisitePro中访问TEMP工件。在删除TEMP用例之前，我们要确保不再会有任何的使用。