应用Rational 工具简化基于J2EE的项目 （二）启动项目

第二部分:启动项目

Steven Franklin
软件设计师和过程专家
2004 年 3 月

这个有多篇文章组成的系列讲述了如何逐渐的应用 Rational 统一过程（RUP）和其他的 Rational 工具，本文中样例项目的具体计划被围绕着治理需求和风险而讨论。

第 2 部分展示的工具和技术：

• Rational 统一过程 (RUP) — 支持项目计划的制定
• RUP Microsoft Word 模板 — 草拟项目远景文档
• Rational RequisitePRo v2001A — 用于需求数据库
• Rational ClearQuest v2001A — 用于风险治理

将被创建或者更新的产物：

• RequisitePro 数据库 — 被创建用来存储来自于客户的工作描述（SOW）的需求；之后需求会转化成直接面向分析工作的更为具体的系统需求规格说明书。
• ClearQuest 风险数据库 — （通过修改 ClearQuest 计划）被创建以跟踪项目风险

从开始进行计划或者计划失败
在一个软件项目中，获得一个良好的开始是十分要害的。你不仅会希望你的早期劳动确定整个项目的基调，而且你也希望快速的识别出系统中的高风险和挑战的部分。大概一半以上的项目的命运在项目的第一个月就已经注定了，决定的因素包括：

• 不够良好的客户关系
• 不充足的预算
• 糟糕的治理（包括不够好的治理能力、风险的优先级划分和糟糕的项目范围治理）
• 过于依靠银弹
• 工程技能和经验的缺乏
• 不切实际的时间进度

Rational 统一过程（RUP）通过改进团队的效率和指导提升团队的成熟性可以尽量的减少导致项目失败的因素。良好的数据可以影响项目的治理者对项目的治理，更好的工具可以支持工程团队，更好的过程能够帮助软件产品以一种可预见的方式发展。本系列的第2部分将把重点放在我们能应用的一些早期策略上以获得一些在我们的样例项目中摇摆不定的事情。

Note that project management involves some activities that aren't currently addressed in the RUP. I highly recommend the book 请注重项目治理包括一些目前在 RUP 中没有包含的活动。我强烈推荐这本书 快速开发: 驯服疯狂的软件进度 它可以作为在开发项目中减少风险因素的进一步的参考资料。

细化第1阶段时间进度
我们希望尽快启动软件工程，但是首先我们必须在一系列的日程安排问题上得到来自于客户的同意。我们拿来了 我们已经创建的第1阶段的时间进度 （在4个月的时间点以一个演示结束）并和客户更加紧密的审查时间进度。客户提出了以下的问题，所有的问题都是正当的并且一些讨论：

• “使用迭代开发，工程团队将如何知道需要多少次的迭代才能实现我们目标呢？”
• ”在分析和架构的必要条件被达到前开始设计架构和设计对我们来说是不舒适的。“
• “在4个月的时候我们将得到具有什么功能的系统演示呢？”
• “你们将使用什么工具来创建系统呢？我们希望开始采购和培训过程。”

这就是我们看到的客户的主要的关心点，并且我们对每一项作出了回答：

• 担心项目螺旋式的不断进展却没有清楚的交付产品 因为 ASDI 是一家十分遵循有循序的 ISO 标准的公司，因此他们倾向于在早期制定按照从一个到另一个的顺序的具体的时间底线。我们指出迭代可以减少风险并避免一次产生所有产物的与生俱来的问题。虽然迭代的次数可能会在项目过程中有所变化，但客户可以比仅仅一个单一的迭代更好的观测项目的进展。虽然一个单一的迭代看起来是更加简单的，但我们需要多个迭代以更加成本有效的创建系统。在早期的迭代中有 ASDI 的参与将使他们获得更多的好处，这使客户有机会对开发系统的输入提供他们自己的看法。
• 担心遗漏的需求和不充分的分析。 这里再一次提到，ASDI ISO 背景使他们更愿意相信分析应该在任何的设计开始之前被执行和文档化。我们向他们强调了 RUP 具有答应任务交迭执行的好处；也就是说，不同阶段的任务可以并行的被执行。比如，具体设计可以包括原型的创建和其他一些代码开发以验证设计的假设，减少性能风险等等。瀑布式的开发过程有很少的灵活性，并且不会为你提供高风险的很多早期警告。
• 担心项目进展的跟踪。 ASDI 中已经开始有对使用迭代开发方法的担心的声音了，并且他们需要看到能够在项目中产成系统演示的具体进展的保证。在这一点上我们不能告诉他们演示被限定成什么样子。这需要经过一个或两个月当我们对更多的理解了系统的要害的和高风险的领域时才能被确定。我们向他们解释说至少系统演示应该展示一些已经降低了我们已识别的主要风险的体系架构的深层次的部分。我们也预期系统演示可以显示整个系统的工作流、可用性问题和组件之间的交互性的问题。
• 担心我们选择的工具他们将来无法提供或支持。 这对于 ASDI 来说是十分重要的，因为他们计划在项目结束后自己承担维护系统的责任。他们不想看到过早的使用令人兴奋的但有风险的技术。在工具选择方面我们需要针对客户的技术需求、维护计划和其他的需要作一些早期的探索工作。 OTS 评估（包括我们所推荐的）将给 ASDI 一个时机来审查我们对工具和技术选择的标准和理由。在这一点上，ASDI 仍然对自己的执行条件没有信心，他们目前有很少的 IT 基础设施推动我们作快速的决定。