工具和技术选择从来就不是微不足道的任务，虽然它常常被忽略。团队经常根据启动成本、“小工具因素”、好奇心或者对工具和技术的忠心来作出选择，相反，他们应该考虑生产成本、可靠性、可得到的培训、团队技能和特性标准。在评估过程中添加一些正式手续可以确保工具的选择使基于项目需要的而不是个人主观的意见。
一个在 RUP 中很少关注的地方是团队挑选现货（off-the-shelf）— 也称作商业现货供应 (COTS) — 工具的过程。可以了解这个过程领域知识的一个地方是卡内基－梅隆软件工程学院（SEI），那里有 COTS-Based Systems Initiative关注于 COTS 产品的选择和采纳的策略。特别有趣的是 SEI 的 product feature checklist；虽然它更关注于选择软件系统的组件和框架，但是其中的很多策略也可以被用于选择软件开发工具、Web 服务、数据库等等。
ASDI 向我们展示了这些他们觉得将影响我们的工具选择的标准：
- 他们最终承担系统的核心开发和维护团队包含 3 到 5 个人。
- 系统能够被 4 到 7 个内部用户和 1 到 5 个来自于 20 到 30 个公司的外部用户访问（虽然系统的将来版本将支持数千人在线用户）。
- 跨平台技术是重要的， 因为 ASDI 期望在数年中这个系统仍然是可用的。
- 对所有技术的培训必须是容易得到的。
- 他们强烈首选基于 Java 的解决方案。
- 他们首选 OODB （面向对象的数据库）作为数据的存储。
- 系统的早期版本将运行在 Linux 系统上，虽然之后将运行在 Solaris 系统之上。
- 开发人员需要能够在 Windows 2000 的机器上有效的使用软件。
- 性能不会是重要的挑战，因为在同一时刻仅有少数的用户与系统进行交互。
我们拥有 J2EE 应用服务器的经验，因此我们非常幸运 ASDI 选择基于 Java 方案。不过在我们还是快速的评估了象 Perl/CGI 和 PHP 这样的入门级的 Web 方案之后的计算技术（主要是 Microsoft .NET/DNA）。
我们一致发现 Orion Application Server是友好的并是最成本有效的开发环境。在那里 Orion 唯一评分低的方面是 供应商的稳定性和支持。提供 Orion 产品的公司是非常小的并且不具备象 BEA 的 WebLogic或者 IBM 的 WebSphere的能力和信誉。然而在与 ASDI 的检查人员讨论后，我们互相同意 Orion 的 J2EE 标准遵从的好处足以抵消这些风险。如果第二阶段开发需要，仔细的开发将可以确保我们拥有轻便的可以移植到其他应用服务器方案的代码。因此我们选择了 Orion — 这意味这启动成本为零，因为 Orion 是免费的。
Orion 带有高速的内建的 Web 服务器，因此当 Orion 被选定后 Web 服务器的选择过程也就有了结论。它主要的竞争对手是 Apache。然而，在 Orion 网站上显示 Orion 已经在某些测试方面达到并超过了 Apache 。
使用哪一个数据库的选择不是显而易见的。数据库通常不会执行高负载，但是它需要有丰富的特性支持。比如，复杂的数据关系要求有完全的引用完整性限制。同时，系统必须可以 24 小时不间断运行，因此我们希望它具有热备功能、复制、其他的可用性和容错特性。我们是否会用到所有的特性将在以后被决定。
我们觉得 PostgreSQL仅仅是一个有资格的开放源码的候选者。它有很好的 ANSI SQL 支持和引用完整性，并且只要并发用户的增长不太大它可以保持良好的性能。然而，数据存储需要更多的来自于一个供应商的 committed 支持。此外，我们觉得 PostgreSQL 在线支持（比如用户社区讨论）对我们来说是不够的。 MySQL实际上是更加流行的开放源码的数据库，但是它缺少太多的特性（比如，外键支持）。
然后我们转到主流的数据库： DB2， Oracle， and Microsoft SQL。我们在 Oracle 上有着丰富的经验，但是新的处理器单元价格模式对于我们的这个应用来说是过于昂贵了。Oracle 的每 MHz 每 CPU 的基本负荷，意味着 ASDI 将为系统忍受高的生产环境成本，除非他们愿意将 Oracle 安装在一台 P-133 的机器上。Microsoft SQL 被淘汰了，因为它是基于私有平台的。如果创建一个基于 DNA 的方案，Microsoft SQL 自然是首选的，但是对于 J2EE 来说很少被选择的。
最后，我们选择了 DB2 ，我们的调查表明 DB2 对 SQL 有着非常优秀的支持、强大的容错特性、公道的价格模式和正在增长的和被培训的在线用户集合。 IBM 的 JDBC 驱动是高性能的，而且他们的个人版可以被免费的用于开发团队中。不幸的是，我们缺乏 DB2 的技能，这就意味着一些培训在原型活动期间被需要。
你也许正想知道对于 ASDI 首选的 OODB 的选择发生了什么。在通过原型和探索产品后，我们很快个到了结论，使用 OODB 得到的好处不足以抵消它带来的风险。
在这一点上，我们不想使用任何高端的 IDE 产品，有几个原因：
- 我们并不明确第 1 阶段概念的证明需要使用 Enterprise JavaBeans 。
- IDE 的投入是昂贵的。
- 团队的成员已经有了他们自己的选择。
- 因为第 1 阶段的时间是很紧的，使用如 IBM 的 VisualAge 所带来的学习曲线是我们无法承受的。
相反，我们混合使用了以下工具：
很自然，这些工具可通过使用 Rational 工具来弥补在测试、调优和代码覆盖上的缺乏。
