应用 Rational 工具简化基于J2EE的项目 第二部分: 启动项目

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

第 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 基础设施推动我们作快速的决定。

综上所述，我们并不觉得我们时间进度计划是过分自信的，并且我们有信心在客户的成本期望之内完成任务。关于我们能够满足时间进度的能力来自于我们的团队结构，在项目团队中我们与 ASDI 一起对项目进行审查。如表1所示，我们计划了包括一些兼职角色的人员。例如，我们有单独的一个 QA 人员在我们的项目中，这个人同时也在其她项目中扮演角色；在我们的项目中显示她作为一个20％的角色，这就以为着在我们的项目中她一周工作一天：

总的来看，我们计划需要450个人天的工作量来创建这四个月之久的系统演示。在项目的进展过程中，我们将知道是否我们需要增加时间或者提前完成，我们也将通知 ASDI 项目的情况。在展示系统演示的时候，我们也要对深入的设计审查做好充分的准备，并且能过向客户展示对项目第2阶段的估计。如果 ASDI 对我们在第1阶段的概念检验(POC)的工作表示满意，他们将与我们启动项目的第2阶段的工作来开发产品化的系统。

虽然我们还在创建了ASDI 的第1阶段的演示，但 ASDI 非常高兴的看到了我们所作的工作将是进一步开发产品化系统的良好输入。至少他们已经接近可需求的审查、屏幕的模式、OTS 评估、架构审查、两个实际的版本和一个系统演示。

管理风险
从一开始就跟踪风险是极其重要的。在之前的项目中，我们使用 Microsoft Excel 来管理风险，这次我们决定使用 Rational ClearQuest 以简化风险的输入、管理和报告。 ClearQuest 不是一个便宜的工具，而且它对风险管理不是独一无二的成本有效的工具。然而，它同时还可以集中的管理我们的集成和测试方面的问题。此外，我们计划在 Lookoff 的其他项目中共同承担这个成本。

使用 ClearQuest Designer 可以非常方便的设计新的数据结构和表单。比如，创建一个风险录入表单就类似与已经在 ClearQuest Designer 中显示的缺陷表单，我们可以根据缺陷跟踪计划（DefectTracking schema）来新的计划（schema），也可以删除一些不必要的条目和重命名其他的条目，类似的更新相应的表单，删除或者重命名必要的提示和域。

这里是你如何能够自己进行试验：假设你已经安装了 ClearQuest 并具有管理员的权限，你应该可以很容易的找到 ClearQuest Designer 应用程序。从文件菜单中，选择 创建计划（New Schema ），并且选择一个已存在的你想修改的计划（Schema）。我们选择修改缺陷跟踪计划（DefectTracking schema）。一旦你给你的新计划（schema）一个名字，你将被提示创建一个与这个计划（schema）相关联的数据库。除非你制定一个特殊的方法，否则你将以 Microsoft Access 数据库的形式创建这个数据库。当被要求将这个新建的数据库与一个计划（Schema）关联时，选择你刚刚创建并命名的计划（Schema）。然后你可以检查编辑和修改的表单和数据类型以符合你的要求。比如，你可以展开记录类型和目录树的表单节点来查看存在的 Defect_Base_Submit 表单。这些表单可以被重命名，一些域可以被删除、添加等等。更多创建和修改 ClearQuest 表单的信息，请参考 ClearQuest 文档。

我可以很快的在我们的桌面将我们项目的风险输入到 ClearQuest 中。整个团队的所有成员都可以访问风险数据库，并且可以输入他们观察到的风险。虽然只有项目经理(PM)和项目工程师(PE)应该具有权限关闭风险，但是给团队的每一个成员提出风险的权限是没什么不对的。项目经理首先会希望查看对于客户可见的风险，因为其中的某些风险也许不是相关联的或者是可以很快被解决的。例如，图1显示了一个被用来输入我们讨论过的项目早期遇到的风险的表单。

对于项目的开始我发现并输入和一共17个风险。这并不是一个非常大的数字，其中的一些风险（比如有挑战的时间进度计划）直到项目的最后时期都会存在。

图2显示了我们所查询的项目风险的一个部分的列表的 ClearQuest 界面。风险被列在最上方，并且严格的按照顺序排列。通过点击列表中的风险项可以得到更加详细的单个风险的信息。

跟踪进展
管理需要工具来跟踪项目的进展。在项目的早期阶段，我们不能依赖任何象缺陷、变更请求和测试结果来衡量项目的成功。相反，我们必须根据工作分解结构(WBS)项和我们的进展来估计实际完成的比例。

好的工作分解结构(WBS) 对于跟踪项目进展是十分重要的。第1部分中的干特图 描述了我们第1阶段的工作任务包 。为了使我们可以精练出有用的矩阵，这些工作任务包必须被清晰的定义并也适当的规划每个工作任务包的大小。我们典型的为这些工作任务包分配10到40天的工作工作量。

此外，ClearQuest 也可以帮助我们跟踪那些系统中可变的部分—在这些可变的部分中，变更请求却是极其的偏高。在一些之前的项目中，我们发现在细化阶段出现的过多的变更请求通常是下列方面中的一项或者多项的征兆：不够充分的分析、难相处的客户、脆弱的工程团队、不良的过程执行或者复杂的再工程。如果在系统的某些方面出现了一点这些症状，就需要管理人员和组长对这些部分有额外的注意。

管理客户期望
有时减少与客户开会和接触开起来是很容易的；然而，实际上是你的项目团队成员中最重要的成员之一，并且客户应该被从始至终的包括在整个项目中。这不仅仅可以产生更好的分析和改进每个迭代所获得的结果，而且可以通过让客户看到进化中的产品和理解面临的挑战更好的管理客户的期望。尤其是当客户对技术不是非常精通时，他们对最终产品的期望肯能会很大程度的超出现实的成本、时间进度和可行性。

我们怀疑真正的项目优先级和动机并没有反映客户的工作现状，我们还需要理解客户关心的主要优先级和期望。为了实现之一点，我们起草了一份概要的远景文档来帮助谅解更多的客户期望。（由于时间的限制，我们将业务远景和项目远景合并成了一个文档。）不论是工作现状（SOW）还是远景文档都要与客户一起进行多次的修订。

远景文档是基于在几个由 RUP 安装包提供的 Microsoft Word 模板其中的一个创建的。我们将这些模板安装在 Word 指定的地方（通过 工具 > 选项 > 文件位置）。如图3所示，我们为每个模板生成了预览（通过打开每个 .dot 模板文件，选择文件 > 属性 > 总结，检查 “保存预览画面” ，保存文件）并对模板的标题重命名 *.dot 文件以使他们更容易浏览。

管理需求
需求对于系统来说不是微不足道的。同样，因为 ASDI 有很少的 IT 基础设施，因此系统需求向详细的软件需求的转换就需要充足的时间和劳动的付出。Rational RequisitePro 可以非常好的帮助我们完成这个任务，它允许我们在整个项目中管理我们的需求和跟踪项目范围的变化。

客户已经开始的工作现状（SOW）可以作为我们的系统需求基线。在许多的情况下，我们按照 RUP 中描述的从业务建模和需求分析开始。这应该包括业务用例的集合、补充的系统规范和业务对象模型。但是对于我们来说从客户的工作现状开始来满足他们的期望并建立在他们的工作之上是十分重要的。我们将按照的工作现状生成了一个叫作软件需求说明书 (SRS) 的 RUP 产物，并且把它作为需求的基础集合，根据它我们可以跟踪我们后来的分析和建模产物。

RequisitePro 的能力可以非常容易的帮助我们从客户的工作状态（SOW）插入需求。我们创建需求的规则要与我们“子弹”的样式相配，或者与任何或所有的关键字 "must"、 "will" 和 "should" 相配。其他可以帮助我们建立需求层次的诀窍包括在相同的级别上获取需求块，在需求块创建标签下对适当的父需求设置缺省值，然后让创建工具完成接下来的工作。（起先我们使用需求块创建时没有设置父需求，所以我们必须返回到每一个需求并对每一个需求设置父需求 — 对于成百上千的需求来说这是单调乏味的工作。）

图4显示了来自于客户服务子系统需求的一页（一共大约40页）。就象你看到的一样，RequisitePro 的界面被紧密的集成到了 Word 应用程序中，因此你可以同时使用 Microsoft Word 和 RequisitePro 的特性。

我们与客户紧密的沟通什么样的信息是被需要的，但是我们让他们在需求文档上作了大量的工作。这被证明是一个非常有效的方式；我们能够向他们的团队传授过程的技能，而他们能够给我们的团队他们学科的专家意见。我们趋向于非常细节的投入到一些领域中，而在其他的一些领域只是在非常高的层面上。在一些情况下这是非常合理的，但是在另一些情况下他们却对系统的一个特定的领域过分的狂热。通过对文档的审查，我们可以指导 ASDI 写出适当并足够详细的需求集合。因为我们正在处理的是 Word 文档，因此规格上的互操作是容易的，当我们对这个文档感到满意时，我们就可以在文档上运行 RequisitePro 。

同样在这个时候我们关注系统的 非功能 需求，这就意味着这些需求不会被系统的功能规格说明描述。这些非功能需求包括关注人的因素的可用性需求（比如学习和使用的舒适性）和可靠性需求等等。

总结
在项目的这个点上，我们运作着一个很小的团队。制定计划和获得资源是我们首要的任务。直到我们知道了我们应该朝什么方向努力并知道如何可以实现目标，我们的团队才会越来越有斗志。对于我们来说首先最重要的是我们必须完成客户的工作状态（SRS），它规定了项目的基本系统和软件需求。

计划未来
我们希望尽快的组成工程团队，但是我们接下来的任务需要一个高级的分析师以使 RUP 的初始阶段更有进展。首先，被显示在我们的工作状态（SOW）中的需求本质上是一系列被分解的规格说明，这些规格说明不能引导清晰的工作分解，或者甚至不能会产生许多架构的线索。我们一直认为以平白的文字表示的需求不会带来以统一建模语言（UML）表达的需求带来同样的好处，因此我们计划将我们的需求转化成用例（在 Rational Rose 中使用 UML）。

同样，我们需要一种正式的方式来管理客户的变更请求、客户所关心的地方和客户的反馈。虽然之前我们没有使用 ClearQuest 的 Web 界面，但是它看起来像是一个完美的工具使开发团队和客户保持同步。建立 ClearQuest Web 对我们来说是下一周或第二周最高优先级的事情。

主要风险
我们的风险没有明显的变化：我们必须继续把精力放在建立有效的客户关系和快速的使项目沿着正确的方向前进。我么们现在有一个问题数据库，因此我们可以关闭这个风险了；然而，直到我们建立了 ClearQuest 的 Web 界面，客户才可以对项目的风险和他们可以支持我们的领域看得更加清楚。（后来当我们关闭这个风险时，我们不能提供时间或者基础设施来建立 ClearQuest，但是一个大的项目将很明确的会从 ClearQuest 中受益。）

客户很高兴我们的进展如期完成，一部分是因为我们的工作产物对他们来说不是感觉不相关的。当我们继续的移到 RUP 的产物时我们必须通过大量的指导来维护客户的舒适感觉并温和的进入新的概念：用例、业务对象等等。

我们觉得我们的时间进度是切合实际的并且设计是良好的除了有非常小的意外。这就意味着资源必须尽快的到位，并且审查返回必须是及时的。我们也必须从一开始就关注高级别的风险，因为我们不能让他们在晚些时候遛进项目的第1阶段。

资源

• 快速开发: 驯服疯狂的软件时间进度 作者 Steve McConnell (Microsoft 出版, 1996)