一些挑战

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

　　基础架构方面的挑战

　　因为我们的开发环境分布在各个不同的位置，针对顾客不同的网络带宽和连通性的站点和远程开发站点，这给我们带来了可能我们从未经历过的困难，即使所有的事情都被定位在一个局域网（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 工具，我们可以达到更到的生产力和效率。工具的集成、每个工具的生产力特性、处理并行开发的能力、有效分配和跟踪缺陷的能力，甚至网络特性：所有这些能力都允许我们达到更高的目标。也就是说，在您赶时髦之前，有很多问题需要考虑。但是如果您考虑到了所有这些因素，您的团队将实现这些工具所保证的收益。