如何正确使用应用Rational工具？

本文是演示了在分布式的、基于 J2EE 的项目中使用 Rational 工具的系列文章（如下面所列）的第 10 部分。

• 第 1 部分: 项目介绍；高层次计划
• 第 2 部分: 风险管理；需求管理
• 第 3 部分: 模型创建和访问控制；需求分析
• 第 4 部分: 用例细化；产成报告；工具和技术选择
• 第 5 部分: 体系架构和设计
• 第 6 部分: 详细设计；早期开发；双向工程；早期单元测试
• 第 7 部分: 继续开发；早期的构建；演示
• 第 8 部分: 单元测试策略；功能测试；GUI 测试脚本
• 第 9 部分: 系统构建和测试；缺陷跟踪；产品交付
• 第 10 部分: 项目完成；结论；未来的工作

本文中所虚构我们是一家软件公司 Lookoff Technologies Incorporated，我们的客户 Audiophile Speaker Design, Inc. (ASDI)，它雇用我们实现他们最初的 IT 需求。对于更详细的信息，参见 第 1 部分。

这个系列的文章的最后一部分讨论了一些为结束 ASDI 项目需要做的剩余的小事情。我们已经通过了验收测试，系统现在已经准备好移交到 ASDI（交付和维护）。这篇文章的结束部分我们来对我们在项目中所观察到的进行一个讨论，并希望能够从我们在这个项目的工作中学习到一些经验和教训。

项目交付
现在是时候将项目的第一阶段交付给客户了（并决定是否会有第二阶段）。我们将系统交付给了 ASDI 并帮助他们在他们的站点上安装了系统。他们通过真实世界的使用立即开始测试系统，开始输入管理和配置数据并将他们预期的“正在使用的”部分列表移植到了系统中。他们也尽力的输入订单并产生部分的报告。系统正常的运行了，客户感到非常高兴，而我们剩下的所有工作就是对系统进行维护。

维护
因为我们的和约是包括系统的所有部分的工作，并没有一个正式的担保期限。而 ASDI 仅仅向我们提出了一些新想法或者不适合的需求等方面的问题，我们将这些问题提交到了 Rational ClearQuest 缺陷数据库中。因为我们没有为 Rational ClearQuest 安装 Web 界面，因此客户的输入是通过硬拷贝的形式与我们进行沟通的。虽然这个过程对于整个开发的分析阶段作出的系统变更请求工作的很好，但它在维护阶段被证明是繁重的工作；我们的第一选择是让客户直接访问我们的数据库。其次的问题通过电话会议被讨论和确认，而其他的问题被推迟直到我们对项目维护的范围、影响和实施计划达成一致意见。

ASDI 没有基础设施或者资源来维护软件系统本身，因此我们在我们的公司保留了开发和测试环境。这也是有意义的，因为如果 ASDI 决定为这个项目继续第二阶段的开发，那么分解我们的环境将是浪费时间和资源的。

我们在我们的站点上修改了软件并将构建好的系统适当的交付给客户。这是稍微有点笨拙的安排，因为我们仍然有被分配的资源以全职的形式投入到项目中，但是在这个项目的维护中，并没有足够的工作可以保证工程和集成与测试团队进行全职的工作。然而，因为 ASDI 并没有合适的人员、软件或者硬件来执行他们自己的维护，这种安排还必须持续一段时间。

在第一阶段的维护期间被提交到 ClearQuest 数据库的问题有一个粗略的分配：

• 50% 的新特性请求
• 40% 可用性问题，对于新的或者改变的提示、消息、菜单等等问题
• 6% 不重要的 bug
• 3% 需求错误
• 1% 重要的 bug

问题的多数都是在“好看的外观”类别中，比如一个能够使应用更加便于使用的变更，但是他们都不是关键的。例如，在系统的用户界面上有一个区域，在那说明 ASDI 业务领域的术语是不正确的或者字母拼写错误。理想的情况是这些问题在早期的复审中被挑出来，但是在第一次复审中挑出所有的错误总是困难的。

大量对于新特性的请求简单的反映了这是一个未完成的产品 — 向没有从一开始被包括在项目中的用户展示系统的一个自然的结果。因为项目的第一阶段成生的只是一个概念验证的系统，我们的目的是验证系统的功能性，我们的大量工作是围绕着这个目的完成的。

被残留在系统中的不重要的 bug 不是与需求有很大的矛盾，他们是在比较底层上的不正确的实现。这些问题包括被系统产生的一些在金融数据报告上的不完善的数值的舍入。

我们没有必要太担心关于需求上的错误。我们的分析工作是非常彻底的，但是记住两件事是重要的：

• ASDI 的实际情况是将这个概念验证的系统当作真实世界的系统来评估，并且我们对需求的实现上只发现了少数的问题对我们来说是一个巨大的胜利。
• 多数的需求错误是小的并且很容易修复。在许多情况下，更新用例和相关的文档要比修改代码本身花费更多的时间。

第二阶段？
有一些关于是否、何时并且 ASDI 如何继续进行这个项目的第二阶段的讨论。下面有一些讨论中的观点：

• 一些使用系统的操作者不太会使用计算机，并且他们能喜欢用老的方式做事情。
• 一些喜欢新系统的操作者想使用它。
• 外部的 B2B 接口还不是十分的成熟、完全的自动化或者要捆绑多样化的平台。 在当前的情况下 ASDI 不能分发这些库和 API 给他们的客户。
• 第一阶段很好的控制在预算内，因此我们有信心在时间和预算内执行项目的第二阶段。
• ASDI 的技术领导觉得他们应该自己来完成第二阶段的工作，虽然他们目前还没有足够的能够支持这项工作的人员。
• ASDI 已经将他们的所有数据移植到可第一阶段的系统中了，并且担心这个工作会在项目的第二阶段版本中进行重复。
• ASDI 认为，虽然有一些事情可以证明第二阶段的项目能够比第一阶段更加高效，但是从第一阶段系统中获得的超过老系统的效力可能已经足够了。

当最初计划第一阶段和第二阶段时，我们就知道我们最终将面临这个岔路口。上面问题中的一些成为了在第一阶段的末期创建的一个精练的原型的结果，当你在一个概念验证的系统中进行预期时，系统中还存在一些不具备产品化质量的部分。就像上面所提到的，向 ASDI 提供的用于企业批量操作的 B2B 接口还没有完全的被实现。很多对于新特性的需求被记录在了 ClearQuest 数据库中，并且被设置为等待状态的动作。用户文档是不够充分的，存在一些对于操作者来说不够清楚的任务操作指示说明。

我们指出了一些定性的证据证明如果我们继续项目的第二个阶段，产出的系统将要比第一阶段产出的系统更加高效。很多特性将被加到第二阶段中 — 比如，通过与数据库集成的数据输入屏幕支持数据输入的能力，而不是通过命令行的接口 — 这将无疑意味着更高效率的增加。与此同时， ASDI 的项目经理觉得当前的系统已经有了巨大的改进，当我们将它向公司展示时，我们完全可以将它从一个“beta”版本重新命名为“完全版本 1”。

最后，ASDI 同意我们继续扮演系统维护的角色，虽然 ASDI 保证他们至少会从我们这里雇佣两个全职的支持角色的人员（一个开发人员，一个测试人员），而其他被需要的支持可以通过电话的方式实现。在 ASDI 有了他们自己的财政状况的更多数据和更加清晰的认识后，他们决定推迟第二阶段的工作直到一个比较靠后的时间。

观察
我们从这个项目中学到了相当多的东西，因为这个项目是我们在几个新技术上的第一次探索。作为我们首次广泛的实践 RUP ，它为我们提供了一系列的对于过程的项目观测和想法。

客户关系
在这个项目期间，我们与 ASDI 有着非常良好的关系。经过这么多年，我们发现能够成功的建立与客户的良好关系的是良好的沟通、对项目进展的可见性和具有实际意义的提议。与 ASDI 唯一棘手的问题是他们最初预期项目应该严格的按照瀑布型的开发方法进行。这与我们运作项目的方式截然不同，并且与 RUP 方法也有着巨大的差异。最后，我们能够执行我们觉得是必要的迭代，而尽量的向 ASDI 展示类似于瀑布型方法的结构以满足他们的需要。

客户对于项目范围的视角改变了大约三分之一的贯穿项目的路线。虽然变化不是强烈的（见图 1），但是也造成了从最初的 SOW 的一些转变。我们能够使用 Rational RequisitePro 来跟踪需求，但是他们对整个系统带来了影响。

图 1: 在项目范围上的变化

在范围上的改变添加了一些功能方面的区域，但是也删除了其他一些功能的区域。B2B 接口的重要性被降低时，而操作员屏幕的重要性被增加了，我们觉得这对 ASDI 是安全并且明智的决定。虽然我们已经被给了命令（和预算）来实现并测试一个安全的 B2B 接口，与此同时 ASDI 意识到他们所花费金钱的最大价值是在数据集成、基于 Web 的数据入口、报告和订单管理上。这不仅仅强调帮助 ASDI 向他们的潜在用户销售使用系统的思想，而且也提供了立即可用的结果（不要求他们等待业务伙伴采用 B2B 的接口）。

在我们的团队中 ASDI 的信心在项目的周期中不断的变化着。对此我们的非常主观的估计被显示在图 2 中，在图中在信心曲线上的主要的点与下面图中列出的被标号的条目是对应的。

图 2: 客户的信心

1. 信心相当的高； ASDI 基于我们的名气和提议授予我们和约。
2. 在项目的早期，随着被提议的时间表的推移、我们对不熟悉符号的介绍和看起来在分析和设计上的繁重工作的过程，一些担心出现了。我们进行了大量的解释和陈述以说服他们我们的方法是有价值的。
3. 当原型和详细的分析会议有所进展时，ASDI 对我们的进展变得更加满意了。他们也成为了复审和分析过程的主要贡献者，并且无疑是团队中非常有价值的成员。这导致更多的买进和对项目进度的增加的可见性，同时也给 ASDI 增加了信心。
4. 当我们仍然没有进入实现阶段，并且花费大量的时间在类图、原型、场景等等上时，ASDI 的信心有所滑落。看看时间进度表， ASDI 非常担心我们用了一半的时间，却仍然在进行详细的设计。
5. 团队开始进入了高效的产品阶段， ASDI 看到了快速的结果。我们快速的构建了软件，我们的演示已经是令人印象深刻的了，并且在我们如何执行初始和细化阶段的逻辑和价值看起来变得更加明显了。
6. 当演示的频率和成熟度增加时，ASDI 对我们所做的工作继续保持满意。虽然在过程中遇到了一些技术上的难题，但是很明显我们有足够的时间来解决缺陷和剩余的任务。
7. 当 ASDI 开始在他们的站点上使用第一阶段产生的系统版本时，他们继续对产品表示满意。我们能够容易的在我们自己的维护和测试环境中解决他们提出的新问题。

过程
我们之前的项目借鉴了一些 RUP 中的增量的和迭代的内容，但是这个项目是我们第一次真正大规模的实施 RUP 。我们没有完全的照搬 RUP 的内容，因为我们想避免对于项目团队通过太多新的步骤所带来的“过程工作”的风险。

Rational 的工具能够很好的帮助我们理解 RUP ，并且在线的 RUP 文档也是非常有价值的。 RUP 的文档在实施 RUP 的道路的每一个步骤上为我们提供了卓越的策略建议，并且 RUP 的工具指导也帮助我们理解 Rational 的每一个工具应该如何被应用。

RUP 的一个长处是它关注在降低风险上。迭代的方法，早期的原型、演示和大量的客户参与的合并，所有的这些可以帮助降低项目的风险。我们觉得我们项目的风险与图 3 中的路径比较相符（相应的标号条目在下面）。注意这个图不是图形，仅仅是 被识别风险的标号。显然，一个项目在开始时风险最大的，因为未知的总是在前面；在项目的一开始你几乎很少知道什么是项目的所有风险。

图 3: 项目风险

1. 项目风险在项目开始时是最大的。直到我们与客户形成良好的工作关系，我们所识别的核心技术能够验证我们的估计，我们还是仍然暴露在很多能够对我们的项目造成损害的风险中。
2. 通过这一点，我们与 ASDI 紧密的在一起工作，他们对过程的担心已经很大程度的得到可缓解，并且我们创建了多个早期的原型，这些原型引导了我们对系统架构的技术选择。
3. 当 ASDI 的技术领导开始力推一个面向对象的数据库方案时，我们对这个新技术的引入表示担心。更进一步的原型帮助了我们说服 ASDI 并且我们自信关系型数据库才是最安全的路线。
4. 额外的设计和架构，以及早期的开发可以帮助我们减少风险。我们有一个清晰的技术方案，更加可靠的估计和我们觉得能够完成的时间计划。
5. 经过构建阶段的中途，一些新的技术问题有些阻碍了我们的进度。这些问题都是一些低级别的；他们仅仅影响了在类和模块级别上的估计，并不会危害任何整体的线索或者子系统。
6. 对于构建阶段的剩余部分，有比较清晰的航线，因为技术方案显然是合理的，并且进度也加快了。到了这个时候我们执行了客户的验收测试，在验收测试中有非常少的问题在，ASDI 也对产品表示满意。

技术与工具
所有对于架构所选择的技术都按照预期执行了。在初始和细化阶段的早期原型帮助我们确认了这些技术的选择并给了我们在培训、 API 熟悉和开发上的良好开始。

回想一下，我们很高兴我们采用了使用 IBM DB2 数据库的路线。当我们面对来自于 ASDI 的将面向对象的数据库引入到架构中的压力时，我们进行了一个可选方案的仔细评估和对比，并能够演示了面向对象的数据库实际上是不够安全的，或者在产品上还有更好的选择。

Ratioanl 的工具在我们以老的方式做事情之上提供了一系列的好处。我们也许能够在相同的预算下以老的做事情的方法交付符合需求的产品。我们在第一阶段系统的改进从三个方面比较了新的方法是如何压倒老方法的：可用性、质量和性能。

• 系统是更加可用的，因为 ASDI 已经紧密的参与了很多个迭代和系统的构建。频繁的演示，丰富分析的阶段，和可用性专家的介入都对最终系统的易用性作出了贡献。实际上，操作者能够在没有在线文档或者用户手册的情况下就能够使用系统。
• 系统要比先前我们交付的系统具有更高的质量。不仅仅是我们的缺陷率更低了，而且架构和设计也是出众的。通过仔细的对架构和设计进行迭代的评估，我们在项目的早期发现了一系列的问题，而通常情况下这些问题要到实现阶段才会被发现。我们现在认为设计阶段是一种有价值的原型和风险降低的形式，我们并没有很快的跳到实现阶段。使用双向工程来确保在设计和代码之间的同步是非常有用的。
• 系统比以前的产品执行的更加一致并且可靠。不仅仅是具有高效的初始和细化阶段从而将更多的预算留给系统的测试，但是在构建一个健壮的系统上我们的设计是更加成功的。因为我们在 Rose 中的数据建模工作经过了严格的复审，甚至我们的模式被设计的非常高效和精确。我们适当的将数据访问进行了分层，简化了查询的优化（在之前的项目中数据访问有时会混合在业务逻辑中）。最终，我们从 Rational 的测试工具上获得了巨大的利益。Rational Quantify 能使我们查明瓶颈，Robot 和 SiteLoad 能使我们在极高的负载下测试软件以确保系统能够对最坏的条件进行响应。

团队生产力
团队之前一直在一起工作，因此在团队成员之间已经具有了良好的士气、沟通和协作。这允许他们将更多的精力放在项目和学习新的工具上。

我们发现在项目的过程上跟踪团队的生产力是有趣的。虽然我们不是度量分析的狂热者，比如，代码行陈述(SLOCs)，但是在这个例子中度量分析的确是很有趣的。在我们之前的项目中，在相同数量的金钱下，我们能够编写更多的代码；然而，在那些项目中对于同样的金钱我们从来没有提供过如此多的功能。因此，即使我们做了更加好的工作，但是我们的 SLOC 度量分析看起来却是更低的。我们将这归结于有一个更加清晰的设计、对购买软件的更好利用和极少的返工。工程团队也很少的感觉到时间的压力，因此他们能够花费一些时间在代码复审之前来重构代码。

图 4:团队生产力

1. 在项目的早期，本质上没有什么活动。我们只是开始建立我们的基础硬件，并且甚至不知道我们将使用什么样的工具。
2. 我们在项目的初始阶段的早期开始创建原型，以帮助我们识别一些使用的技术和软件开发工具。
3. 当我们将重点放在详细的分析和早期的架构上时，这将有很少的编码工作，任何被编写的代码在想要的结果被获得后都会被丢弃。
4. 一旦我们进入了细化阶段，我们就很快的开始细化并瞄准原型，这将帮助我们降低技术风险并且帮助我们做设计的决定。这里有一些代码在实现中可被重用；然而，在细化阶段的早期多数代码在服务于风险降低的目的之后就被抛弃了。
5. 在构建阶段期间，工程团队关注于构建系统，并且最高效的执行工作。
6. 在整个构建阶段工程团队将大量的极端性能测试留了下来。集成与测试团队执行一些非编码的工作，他们使工程团队将精力集中在构建系统上直到接近构建阶段的结束。
7. 在构建阶段的末端，工程团队仅仅必须修改在测试和更新剩余的构建版本和测试文档中被显示的缺陷。最后，工程团队编码工作的输出显著的下降了。

结束语
这个部分对这个小型的基于 J2EE 的使用 RUP 和 其他 Ratinoal 的虚构项目进行了总结。这个系列文章显示了一个项目能够采用 Rational 的工具和过程的很多可能的路径中的一个。这个特殊的路径包括了保持事情的简单性，并在决定之前尝试了每一种技术和工具。团队并不试图在一个单独的项目中精通 RUP 和所有的 Rational 工具，而是以一种稳定的、有纪律性的方式来采用 Rational 的过程和工具。

项目的技术、团队结构和时间计划非常有益于在不阻碍进度的情况下合并 RUP 和 其他工具。而你的项目中的情况也许有所不同，因为你使用的技术的合并可能比这篇文章描述的更加高效或者低效。对于能够给予他们的预算，有一些培训的机会能够帮助更加容易的将 Ratioanl 的工具引入和集成到项目中。你不应该有这样的感觉 －这些工具是能够挽救你的项目的“银弹”，他们只是能够使团队更加好的工作。

记住这篇文章不是我们以前工作的任何实际项目的说明，虽然它是基于我在实际项目中的经验的。被描述的新技术和 一些 Rational 工具对于我所从事的很多项目来说仍然是不能得到的。也要注意我不同意在 ASDI 项目中被做的许多决定，但是我将他们写入到文章中的目的是为了演示和开发不同的思想。

我百分之百同意这个文章的结论：正式的、现代的软件工程工具和过程能够为一个软件项目带来卓越的生产力和质量。虽然要对“银弹综合症”保持警惕，我还是一直在寻找简化工作的方法。Rational 的一系列工具恰恰能够做到这一点，并且这些工具良好的集成甚至能够提供更多的价值。