应用Rational 工具简化基于J2EE的项目（一）
第一部分 介绍
Steven Franklin
软件设计师和过程专家
2004 年 3 月
这个由多篇文章组成的系列文章讲述了如何在很紧的时间和预算的情况下通过应用 Rational 统一过程（RUP）以及 Rational 的其他工具来开发一个软件项目的。 文章的第一部分包含了高层次的计划和需求的引出。
Raional 的开发工具套件支持双向工程（RTE）、分布式的和协作的开发、高度迭代的开发周期和更多的一些特性。 这个由多篇文章组成的系列的第一部分将向大家展示 Rational 工具的作用，并显示你能够通过使用 Rational 的工具来简化分布式的 J2EE(Java 2 Platform, Enterprise Edition) 项目。我们将看一个将单的虚构的项目，并以高层次的计划和需求的引出作为开发，并将过渡到 Rational 统一过程（RUP）的各个阶段。 本文假设你已经对 RUP 有一定的了解；如果你并不了解 RUP 你可以查看文章最后列出的 相关资源.
为了简单起见，我们不想完成 RUP 中所有必要的迭代，而是只显示在项目各个阶段被用到的工具的特性。我们将跟随着我们的小的样例项目，完成它的第一个主要的构建，如下：
- 了解 RUP 的概念 和 Rational 工具的使用，应用它们来应对远程开发、很紧的时间计划和受限的预算的挑战
- 使用Rational 技术实现端对端的可以跟踪性和需求的管理
- 在 J2EE 项目中集成 Rational 工具，完成自动化测试、双向工程、地理分布的代码检查和质量保证（QA）
- Rational 技术与 J2EE 工具的集成，对于最终的解决方案尤其是应用 J2EE、象 DB2 或者 Oracle 这样的关系数据库和 Java 集成开发环境
这个系列文章的每一篇都有相似的组织形式 ，每篇文章都以一个路标开始，就像下面的一样，每一个链接会连到相应的文章部分。
- 第 1 部分: 项目介绍；高层次计划
- 第 2 部分: 风险管理；需求管理
- 第 3 部分: 模型创建和访问控制；需求分析
- 第 4 部分: 用例细化；产成报告；工具和技术选择
- 第 5 部分: 体系架构和设计
- 第 6 部分: 详细设计；早期开发；双向工程；早期单元测试
- 第 7 部分: 继续开发；早期的构建；演示
- 第 8 部分: 单元测试策略；功能测试；GUI 测试脚本
- 第 9 部分: 系统构建和测试；缺陷跟踪；产品交付
- 第 10 部分: 项目完成；结论；未来的工作
| 第一部分快照 |
第一部分中的工具和技术：
|
样例项目介绍
这篇文章中的虚拟假设是我们是一家软件公司，名字为 Lookoff Technologies Incorporated，我们的公司主要的业务是在 IT 系统，包括集成、支持和开发。我们的总部在多伦多，并且在遍布加拿大有一些小的办事处。因为我们的分析和开发团队距离我们大量的跨国客户非常近，这个公司的结构就允许我们以一种非常好的方式集中我们的专家（典型的后端开发和项目管理）。
我们假设另外一个虚拟的公司，Audiophile Speaker Design, Inc. (ASDI)，这个公司位于 New Brunswick 的附近。 ASDI 开始只是一家从事扬声器制造和设计的小公司，主要开发针对个人用户的一些定制的扬声器方案。随着 ASDI 公司的声望的增加，他们开发出更多主流的扬声器产品线，并向加拿大和北美国家的用户和电子商店供应产品。
ASDI 的技术设施不能满足他们的成长需要。他们已经难以管理定单，计划生产材料，跟踪部分需求和管理运输。更主要的是，ASDI 的客户抱怨他们缺乏浏览可用性和交付过程的能力。
ASDI 公司意识到了从纸张和电子表格到自动化的资产管理系统的转变是伴随风险的，ASDI 决定将他们的所有 IT 需求交给 Lookoff 一家来作。他们选择我们的主要原因是我们的良好声誉和距离他们的公司很近（便于支持）。
Note that although the sample project is fictional, it's based on my personal experiences, observation of other projects, and knowledge I've acquired through excellent books such as those listed under 注意：虽然样例项目是虚构的，但是它是基于我的个人经验、对其他项目的观察和我通过一些优秀的书籍（例如被列在文章结尾的相关资源）获取的知识。
引出高层次需求
象许多小的非 IT 公司一样，ASDI 意识到了他们的问题，但是他们并不十分清楚他们的需求究竟是什么样子。他们的原有工作状态仅仅有两页纸长，并且是契约的、功能的和编程的需求的混合。我们和他们坐下来讨论他们的每个需求点；这里最大兴趣的是契约的和编程的问题，讨论如下：
契约问题
客户(ASDI) 希望我们签署一份公司固定价格(FFP)合同，合同价值一百一十万加元（CDN），按照合同规定软件系统应在10个月之内交付。对于我们来说没有一个清楚的需求远景，签署这个合同是不可能的。这将给我们带来过多的风险，并且也许对客户来说是不公平的，并且我们能够确定他们的技术需求将被满足吗。我们开始了第一个会议，目的是讨论迭代和和增量的软件开发优于顺序（“瀑布”）开发的力量。
我们对客户强调的 RUP 的关键特性包括：
- 迭代工程，减少风险和聚合正确的方案
- 尽最大可能使用已有的工具、技术和已开发好的产品，以减少成本增强质量。
- 管理和控制变更
- 给客户对将产成产品的了解
- 创建高质量的产品
客户还是很关心软件交付的期限的缺乏。通过一些讨论，我们成功的显示了客户从项目的开始到结束都应该对项目的进展有足够的了解。他们也想项目的预算可以分阶段支付，并且要求我们在执行项目时履行一些义务。因此项目计划被划分为两给阶段：
- 阶段 1 — 创建系统的“概念校对”版本。客户将按照工时支付我们的费用，但是在第一阶段的预选之内。
- 阶段 2 — 创建系统的产品版本，按照 FFP 支付费用。
对于阶段1，客户要求250K CDN 的上限，我们觉得这个预算对于我们创建第一个原型系统的演示版本是很充裕的。我们创建了如图 1 的干特图，我们在四个月是标记这个点应该产生演示版本，并且与客户一起审阅以确保至少与第一阶段的时间表粗略的保持同步。（之后我们与他们更加紧密的一起检查了这个时间进度表）
 |
| 图 1: 阶段 1 干特图 |
图一中的图是用 Microsoft Visio 创建的，但是你可以很容易的使用 Microsoft Project 或者 一些类似的软件工具来计划你的项目。这个图表对我们的主要目的是对时间进对和里程碑达成一致，并且建立工作分解结构（WBS）的层次图，工作分解结构中的每一项我们都可以跟踪、估计和执行。
编程问题
ASDI 是一家通过了 ISO 认证的公司，并且他们非常信仰厚重的文档、连续的里程碑和广泛的质量控制。他们不是一家非常技术型的公司，他们在过程上有自己的想法。我们在与他们合作的作大挑战之一就是找到一个过程和可是使他们满意的可交付工作产物的集合，同时又不会使我们的团队感到多工作有防碍。他们进行了几次会议，并很强调要有大量的彻底详尽的文档。而且，他们的里程碑是有顺序性的，而且他们的思想是每一个任务必须在下一个任务开始前结束。 他们对过程的理解使我们在最可能的方法中应用 RUP 制造了更大的挑战。
虽然 ASDI 同意了我们使用迭代和增量的开发（基于 RUP）方法，但是他们对这种方法似乎不感兴趣。他们希望得到下面的东西：
- 固定的里程碑：
- 系统需求检查(SRR)，初步设计检查(PDR)，和关键设计检查(CDR)
- 两个软件的演示版本
- 工厂接受测试(FATs) 和 客户接受测试(CATs)
我们简单的将这些里程碑插到了我们的过程当中(如图 1 所示).
- 一个正式的需求文档、一个设计说明书和接受测试文档。这些对于基于 RUP 方法的面向对象的符号是全新的，ASDI 在工作中并不是十分的关心他们中的所有，但是 ASDI 还是同意将他们的交付工作产物的描述保持足够的高级别，以便我们可以使 RUP 的工作产物满足 ASDI 所期望的工作产物。我们觉得可以使用 Rational 的工具来生成如何需要的文档，不会对我们的过程造成很大的阻碍，并且可以成功的将信息传达给客户。具体的说是 Rational SoDA能够使我们更加容易的从模型中生成文档。
ASDI 也计划雇用一个 IT 经理与我们联络，同时也负责维护和管理完成的项目。我们需要 ASDI 的这样一个角色的人加入到项目中，这个人对于项目来说应该是一个技术上的权威。不幸的是， 这个 IT 经理（对公司来说是新兴的事物）缺乏客户运作的知识，就像我们的团队中的一样。
总结
在最开始与客户的一系列的会议中，我们取得了一些非常好的进展。ASDI 的对于交付产物和时间进对期望是有些灵活性的，并且允许我们使用基于 RUP 的方法进行开发。我们对项目达成了一个大致的时间进度结构，并且与客户建立了良好的关系。通过与客户的讨论，我们识别除了一些风险，之后这些风险被我们用来划分任务的优先级和项目管理。
计划未来
我们应该进行的最高优先级的事情之一的是与客户一起从客户的工作现状（SOW）开始建立项目的远景。我们已经获得了客户需求的大概的理解，但是我们还需要分析出需要我们作的具体的工作。
我们也必须细化我们的时间进度表，并尽快的开始我们探测好的起步阶段。在阶段1期间，要确保一个方案是有成本效益的和满足客户需求的，我们就必须找出如何能够满足客户需求。客户已经提到过，在决定是否将项目进行到第2阶段的主要因素是最终系统的维护和系统架构软件/硬件的成本。
总而言之，我们在前几周应该做的事情包括：
- 为项目详细描述的客户工作现状（SOW），并且在 Rational RequisitePro 中输入项目需求。
- 为阶段1细化时间进度表
- 在成功的进行了设计的检查后，创建项目计划以显示如何计划过渡到第2阶段。
- 制定详细的执行计划以减轻被识别出的风险
主要风险
项目进行的开始几周对于建立有效的客户关系和使项目保持在正确适当的技术方向上是非常关键的。我们没有太多的时间来寻找需要的技术并将这些技术集成到我们的团队中，因为客户期望的项目进度是非常快的。
我们认为我们必须建立一个问题的数据库，我们能够以一种集中查找数据库的方式提出行动条目、问题和风险。通过将这些信息发布到网上，这样就可以使不论是集中办公还是远程的开发团队都可以监视项目信息。如果有必要的话甚至远距离的工作者都可以跟踪和更新项目的风险。
- Rational Unified Process: 介绍, 第二版 作者 Philippe Kruchten (Addison-Wesley, 2000) 本书对 RUP 提供了一个非常好的介绍。 更加详细的信息可以在 RUP 产品中找到。
- 快速开发: 驯服疯狂的项目进度 作者 Steve McConnell (Microsoft Press, 1996).
- 人月神话, 周年纪念 版: 软件工程散文 作者 Frederick P. Brooks, Jr. (Addison-Wesley, 1995).
- Death March: The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects by Edward Yourdon (Prentice Hall PTR, 1999).