用Rational对需求工件进行版本化和并行开发

一个串行例子

    现在，我们已经理解了分支和合并的概念，我们可以将他们应用于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：串行开发周期