本文内容包括:

• 项目启动
• 工具选择
• 为什么不使用整个 Rational 工具包？
• 两个额外的优势
• 一些挑战
• Rational 工具集成
• 当在您的项目中使用 Rational 工具时需要注意什么呢?
• 结论

本文来自于 Rational Edge：许多项目经常忽略和低估了它所采用的工具的作用。尽管团队倾向于重复地使用熟悉的工具，但是对工具进行明智地选择、适当地采用和部署可以产生更大的效用和带来更高的生产率。

　We 我们最近正在进行一个高风险的应用开发项目，这个项目面临着很多挑战，包括：

• 有一个严格的时间限制（在两个月完成动这个应用的原型）
• 有一个非常紧迫的最终期限（在四个月内必须完成一个完全具有功能性、交互性和集成性的应用版本）
• 并不完整的需求
• 当进行软件应用开发时面对的是一个无经验的客户团队
• 这是一个地理位置分散的应用开发团队。
• 这个应用开发团队成员的技能水平参差不齐

尽管困难重重，我们仍然决定对这个客户积极做出相应，减小这个项目的风险，最终达到成功的目的。为了达到我们的目的，我们在思考如何最大化我们所具有的优势。我们的团队具有使用各种不同工具和方法的经验，这些工具是我们过去曾经使用过的，包括 IBM Rational 方法和工具包。我们本应该可以选择这些工具中的任何一种，然而，由于这个项目的特性，我们认为 Rational 方法和工具可以为我们提供最好的优势。

有了这个工具包，我们不仅可以从每个工具的单个能力上获得收益，还可以利用这个工具之间的良好集成获得额外的收益。基于这个项目的需求，我们选择了 IBM Rational 统一过程(RUP)，IBM Rational Application Developer (RAD)，以及 IBM Rational ClearCase 和 ClearQuest。这篇文章描述了我们是怎样利用这些工具来使我们的工作效率更高，同样重要的是，它还描述了一旦我们不能使用这些工具，这个团队将遭受什么样的挫折。

项目启动

我们的客户想尽快看到结果，但是他们对这个应用程序将看起来会是什么样子并没有一个清晰的想法，或者说对所做的一切都没有清晰的概念，他们只有强硬的时间限制和他们想要达到什么要求，以及他们收集的一些必要的用例。他们问我们，“您们最快能什么时候开始项目的开发？”

除了客户所要求的一些挑战外，我们还需要考虑我们工作环境的灵活性。我们是一个地理位置分散的团队。因为在客户工作场所中只有很有限的空间可以被我们的开发团队使用，一些工作人员在 IBM 公司，一些则在家中进远程办公。将开发团队的全体成员都集中在 IBM 意味着我们可以迅速扩大开发环境（但是在客户工作场所中并没有已经设立好的我们可以利用的开发环境）。

我们利用 Rational 统一过程 (RUP)来开始我们的项目，因为 RUP 是一个非常适合这个客户的工具，它可以处理我们的最大风险，并使我们尽可能早地交付最高的价值。我们为 RUP 项目的每个阶段都严格限定了时间，这意味着我们可以精确地说明这个项目的时间进度表，每个阶段需要的资源，这样这个项目的成本就可以在每个阶段的末尾显示。我们的客户将会发现这是一个颇有价值的方法。

我们很快开始了这个项目的开发工作。我们的客户不想我们的开发工作等到全面的设计工作完全完成之后才开始。他们有一些需求，并且想看到可运行的应用程序代码，可以尽可能快地将应用程序展示给他们的涉众来看。RUP 是这样帮助我们的：我们在多个有时间限制的迭代中开发应用程序，这意味着我们要为每一次迭代规划好确定的起始和结束日期（连同一个良好定义的设有目标的计划）。我们在每一个限制的时间段里都交付一些新的成果，有时我们可能不能在这个时间段完成任务，那就将剩下的部分转移到其它的迭代中去完成。这样保持这个项目不断向前进展。

工具选择

我们不需要 IBM 所提供的 Rational 包含的所有工具，但是我们的需求让我们来选择一定范围的工具能力。

首先，我们想要一个能够帮助我们使用 Rational 统一过程的工具。有些团队成员对 RUP 并不熟悉。从理论上讲，RUP 是一个不需要安装就能够被使用的概念框架。但是 RUP 工具在帮助我们管理过程和识别关键角色、工件以及我们所需的关联关系中的确有极其重要的作用。这个 RUP 工具帮助我们理解和沟通这个团队的角色、任务和职责。

我们需要一个强大的集成开发环境（IDE）来对我们的代码进行开发和单元测试。我们选择 Rational Application Developer (RAD)来进行应用开发和单元测试，不仅仅是因为它提供了完善的功能，而是因为它支持我们其它工具的选择。

我们需要一个有效管理代码的方法。假定我们的团队是地理位置分散的，并且我们需要支持并行开发流程,那么拥有一个有效管理我们软件开发工件的工具是十分有必要的。由于紧迫的时间期限，我们需要一个工具来支持开发人员在下一个版本上进行工作，同时让其它开发人员对当前的版本进行交付。另外，我们想要一个集中的存储库来为这个团队管理代码。ClearCase 为我们提供了所有这些。

我们需要一个更好的测试和修复我们代码的方法。客户承担了许多测试的责任。不管怎样，我们在这个项目的整个过程中都执行了质量保证的测试任务。在早期，我们将应用程序交给顾客之前，我们的开发人员就利用 RAD 进行了最初的单元测试。后来，我们使用 Rational Robot 和 Rational Test Manager 来确保这个应用程序的良好运行。

我们需要一个有效跟踪缺陷和管理变更的方法。对于这一点，我们选择了 ClearQuest。我们可以利用 ClearQuest Web 工具来提供对我们分布式团队的访问入口。1 这个工具允许我们的团队成员在分布式的位置，仅仅通过网页浏览器就可以访问整个 ClearQuest。在我们将工作版本交付给客户并由他们完成测试以后，我们在 ClearQuest 中获得报告的缺陷，对它们进行评估并将它们分配给开发人员，然后再在随后的版本中对这些修正进行打包和交付，所有这些在 ClearQuest 中都有跟踪。

有了 ClearQuest，我们可以向我们的客户提供最新的项目度量，这是一种在项目快要结束时变得非常重要的能力，此时我们处于交付最终构建版本的压力之下。因为客户可以访问我们的 ClearQuest Web 工具和缺陷库，客户就不必购买他们自己的 ClearQuest，并搭建他们的基础构架。

为什么不使用整个 Rational 工具包？

作为加拿大 Rational 的顾问，我们确定可以描述您在特定的环境下怎样来使用 Rational 所有的工具。然而，这只是一个案例研究，由于很多原因，我们不需要所有的工具。以下将列出一些具体的原因：

我们人工收集了这些需求。我们不需要使用 RequisitePro，因为我们的客户自己定义的需求已经足够开始开发工作了。另外，此时我们的业务分析师对工具并不熟悉，但是对这些需求的人工归档却很精通。由于我们时间的限制，我们权衡了正方与反方最后决定不使用这个工具。

对于构架：这个系统的大部分构架是使用标准文字处理和制图工具完成。这主要是由于我们想使用客户的架构师所熟悉的工具。同时，我们的构架师对使用 Rational 工具对这个 IT 系统的部分进行建模也不是很熟悉。

对于功能测试：我们人工进行功能测试。客户负责功能测试，他们已经有一个他们所偏爱的方法。

两个额外的优势

我们需要利用适当的应用程序开发工具快速提升我们的团队成员效率。然而 Rational 工具包已经具有非常强大的能力，这非常有利于我们进行设置和集成。这使我们有两个额外的优势。第一个是我们可以采购一个集中的 Rational 基础构架，它可以帮助我们快速扩展整个开发环境。整个基础构架在其它项目中已经被安装和测试过，所以我们可以直接利用。第二个优势体现在当我们能够为我们的团队增加一个 Rational 工具问题领域专家 （SME）的时候。因为这个工具的功能非常齐全，我们的一些新人需要大量时间来理解和很好地使用这些工具。但是为了提高生产力，我们的 SME 能够迅速帮助新人提升他们的技能，并将他们的培训集中在他们所需特殊领域上。

一些挑战

我们面临着许多挑战，包括技术上的和业务相关方面的。

基础架构方面的挑战

因为我们的开发环境分布在各个不同的位置，针对顾客不同的网络带宽和连通性的站点和远程开发站点，这给我们带来了可能我们从未经历过的困难，即使所有的事情都被定位在一个局域网（LAN）。虚拟私有网络（VPN）技术也限制了我们简单而高效地使用这些工具的能力。

除此之外，我们的一些测试服务器的某些性能受到限制，从而限制了我们团队的效率。理论上将，我们可以增加这些服务器的性能，但是在这个项目中我们并没有决定权。因此我们不得不尽我们最大努力来管理这些情境。

客户测试过程和工具

我们的客户想要负责测试这个应用程序。但是一些客户展示在我们面前的有关他们测试程序的选择却有问题。比如说，关于缺陷的跟踪，这个客户想要使用他们自定义的工具。虽然这个客户习惯于这种工具，但是这个决定却减缓了我们整体的跟踪、报告以及缺陷关闭的能力，因为在他们的测试工具和 ClearQuest 之间并没有自动集成。因此我们不得不从客户的工具中人工挑选出缺陷，然后将它们加入到 ClearQuest 中。

同时，由于顾客自己的报告工具的局限性，破坏了他们对测试过程的直觉。这个工具不能给他们提供一个清晰的测试过程的画面。这导致了其它的问题，比如他们何时可以对已经被修复的功能进行间断性测试，或者他们什么时候对已知的问题进行功能测试。

关于实际的测试程序，客户们有一个非正式的测试过程，并不能使用自动化的测试工具。客户们没有测试脚本，也没有对办法对他们所测试的内容追溯到最初的需求。他们在缺陷日志中不时地增加一些新的需求，而不是适当的缺陷。使得问题更复杂的是，一些新的测试人员在这个项目的中途被引入进来进行应用程序的测试，他们缺乏一个正式的测试过程或者有效的工具来进行测试，这使得他们的工作更加困难。

Rational 工具集成

我们的项目实现了高生产力的目标是因为在这个项目中我们采用了各种 Rational 工具，并注重了各个 Rational 工具之间的集成。这些集成使我们分布式的团队能够高效地工作，尽管他们身处不同的地理位置。

例如，在构建阶段的迭代过程中，我们的测试管理人员位于客户地点，而客户通过 ClearQuest 提交缺陷。我们的开发负责人将对这些缺陷进行审查，因为它们与被测试的版本是相互关联的，开发负责人通过 ClearQuest 将它们分配给适当的开发人员进行修正。那些位于 IBM 公司的开发人员将会在他们的 ClearQuest 窗口中看到这些分配给他们的缺陷，他们利用 ClearQuest 和 RAD 检验并修正这些代码。一旦这些缺陷在RAD中被修正并进行了单元测试，他们就可以利用 ClearCase 对代码进行准确无误的核对，并更新 ClearQuest 记录，简要说明这个缺陷已经被重新测试。在基础构架专家完成每日的工作版本以后，测试管理人员就可以使修复的缺陷生效并相应地更新 ClearQuest 记录。

最终的结果是一个拥有高质量软件版本的快速开发过程。

当在您的项目中使用 Rational 工具时需要注意什么呢?

基础构架：在基础构架中有很多问题需要注意 基础构架 的限制是一个关键的问题。在您的项目中尽您最大努力尽早确定您将使用的基础架构是否对您造成了一些限制，它将影响您工作的有效性。确定是否有一些网络或者防火墙的限制，它们将阻止工具被很好地利用。是否有一些性能问题需要被提出来（比如，缺少磁盘空间来安装这些工具）？您是否有合适的人选来担当网络管理员的角色？

您是否考虑到软件许可证、基础构架以及您在项目中可能需要支持的额外成本？例如，如果您需要另外的 ClearCase 服务器，或者您的机器需要更多的空间来运行其中一个 Rational 测试工具，您是否在您的预算中将这些因素考虑进去了？

培训：培训也需要考虑到。缺少培训或者在不恰当的时间进行培训将影响您团队的工作效率，并且可能会限制您对这些工具的有效利用。如果时间受到约束，通常会出现这样的情况，您可能会考虑到自学课程或者找一个有经验的指导者。另外，RUP 是有内置工具指导的，可以提供一些指导。记录是十分重要的，但无论如何，都比不上课堂教育。

使用模型：什么是您的使用模型？说到这一点，我们的意思是您的团队将怎样用一种可以最大限度提高生产力的方法来使用这些工具？您的方法支持您的使用模型吗？如果您没有考虑到这些也没有一个好的方法，那么您可能会遗漏 Rational 工具所能够提供的一些收益。

与其它工具的集成。一旦您开始引进了非 Rational 产品，将需要更多的时间和精力把各种工具集成到一起。比如，在我们的案例中，额外花费一些精力把客户和我们的工具集成到一起将会对我们更加有利。

新工具的采用率。正如服务器只有那么多的容量来运行软件一样，您的团队成员也只有那么多的能力来学习新的软件！您不想在您的团队中引进太多的新工具，尤其是受到时间的限制。考虑到可利用的团队培训时间和已经施加在团队成员身上的时间压力，使用这个来指导您决定您想要采用多少个 Rational 工具。

您的项目的规模和复杂性。时间长并且复杂性高的项目比规模小而简单的项目将受益更多。比如，由于您需要增加报告的数量（要么是报告的频率要么是复杂性），在集成 Rational 工具的时候，您将看到比人工做这些事情有更多的优势。关于投资回报率（ROI），您可以发现当您的软件开发项目的规模逐渐增加时，这些您为了学习使用工具而消耗的资源将通过您的所达到的生产效率而得到回报。

商业限制。当使用 Rational 工具的时候，您可能不会遭受技术限制的痛苦。在我们的案例中，我们有一个客户不愿意买新软件。在我们的项目中，您可能发现能够很好使用非 Rational 工具来完成他们工作的团队成员并不想转变他们使用这种工具的方式。

结论

总体来说，通过使用 Rational 工具，我们可以达到更到的生产力和效率。工具的集成、每个工具的生产力特性、处理并行开发的能力、有效分配和跟踪缺陷的能力，甚至网络特性：所有这些能力都允许我们达到更高的目标。也就是说，在您赶时髦之前，有很多问题需要考虑。但是如果您考虑到了所有这些因素，您的团队将实现这些工具所保证的收益。