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

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

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

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

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

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

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

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

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

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

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

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

1