项目启动－起始阶段

    对于新的开发项目来说，起始阶段是很重要的，在项目继续进行前，您必须处理重要的业务与需求风险。对于那些增强现有系统的项目，起始阶段是比较短暂的，但是其目的仍是确定该项目的实施价值及可行性。

    在起始阶段中，为了构建软件您可以创建业务案例。视图是起始过程中的关键工件。它是系统的高级描述。它为每个人解释该系统是什么、可能使用系统的用户、使用系统的原因、必须具备的功能，以及存在的约束。视图可能很短，也许只有一两段。视图往往包括软件必须为客户提供的关键功能。

    下面的例子展示了一个项目的很短视图，该项目对 Rational 的外部网站进行了改造。

    为使 Rational 的地位达到电子开发（包括工具、服务和非常好的实践）的世界领先程度，可以通过动态的、个性化的网站加强客户关系，为访问者提供自助服务、支持和目标内容。新的过程和技术启用可以使内容供应商通过一种简化的、自动的解决方案加速发布并提高内容的质量。

    RUP 起始阶段中 4 个重要活动为：
   
    制定项目的范围。如果我们打算构建一个系统，我们需要知道其内容以及它如何满足涉众的需要。在这个活动中，我们捕获内容和最重要的需求的足够详细的信息，从而得出产品可接受的标准。

    计划并准备业务案例。我们使用视图作为指导，定义风险缓和策略，开发起始的项目计划，并确定已知成本、日程计划，以及盈利率平衡。

    综合得出备选构架。如果正在计划中的系统没什么新颖性，而且使用的框架广为人之，那么您可以跳过这一步。我们一旦知道客户的需求，就要开始分配时间研究可行的备选构架。新技术能够带来解决软件问题的新的并且经过改进的解决方案。在过程的早期花些时间评估购买还是创建系统，并选择技术，也可以开发出一个起始原型，这些都可以减少项目的一些主要风险。

    准备项目环境。任何项目都需要项目环境。不论您使用 XP 技术（例如结对编程），还是较传统的技术，您都需要确定团队将要使用的物理资源、软件工具以及步骤。

    进行小型项目开发时，并不需要太多的"过程时间"来执行起始过程。您往往可以在几天中或者更少的时间里完成，下面的内容说明了本阶段除了视图之外的预期工件。

    一个经批准的业务案例

    涉众有机会从业务的角度认定项目是值得进行的。RUP 和 XP 都承认最好在早期就得出项目是否值得进行的结论，以免在一个注定将要失败的项目中花费宝贵的资源。如同在"Planning Extreme Programming" 一书描述的那样，XP 对于项目是如何形成的以及涉及哪些角色这两个问题的回答是比较模糊的（似乎在现有项目或系统的环境中是最清晰的），但是在研究阶段，XP 处理的工件与 RUP 起始过程中的是相同的。

    不论您在 XP 中非正式地考虑业务问题，还是在 RUP 中将业务案例做成一流的项目工件，您都需要考虑这些问题。风险清单您应该在整个项目开发过程中都保持记录 Risk List（风险清单）。使用有风险清单可以是一个具有经过计划的风险缓和策略的简单清单。为各个风险设定优先级。任何与项目有关的人员都可以随时看到风险的内容以及如何处理风险，但是没有提供解决风险的一般方式 。

    初步项目计划

    本计划包括资源估算、规模以及阶段计划。对于任何项目，这些估算都是不断变化的，您必须监控它们。

    项目验收计划

    您的计划正式与否依赖于项目的类型。您必须判断客户会如何才能认为您的项目取得了成功。对于一个 XP 项目，客户会采取验收测试的形式。在更普遍的过程中，客户可能不会真正地进行测试，但是接受的标准必须直接由客户作出，或者由另一个角色作出，例如与客户直接接触的系统分析员。也可能存在其他的验收标准，例如创建最终用户文档和帮助，但是XP并不涉及此内容。

    起始细化迭代计划

    在基于 RUP 的项目中，在上次迭代的最后，您将详细计划下次迭代。在迭代的最后，您可以评估迭代开始时设立的标准。XP 提供了探监控与衡量迭代成功的一些优秀技巧。衡量标准是简单的，您可以轻松地将它们合并到迭代计划和评估标准中。

    起始用例模型

    虽然这听起来比较正式而让人望之却步，但是它却相当简单。用例与客户在XP中编写的"故事"相对应。其间的差异就是一个用例就是一套完整的动作，由参与者或系统外部的人员或事物发起，这正是用例的价值所在。用例可能包括若干个XP"故事"。RUP 为了定义项目的边界，推荐在起始过程中确定用户与角色。从用户的观点关注整套操作有助于将系统分为有价值的部分。这有助于判定恰当的实施特性，因此我们能够在每次迭代的最后向客户交付一些成果（可能在起始迭代与细化迭代早期除外）。

    RUP 与 XP 都可以帮助我们确保避免一种情况，即整个项目已完成 80％，但都不是可交付的形式。我们一直希望发布的系统对用户都是有价值的。

    在这一点上，用例模型在识别用例和参与者方面几乎没有或只有很少提供支持的细节。它可以是手工或使用工具绘制的简单的文本或者 UML（统一建模语言）图。该模型帮助我们确保已经包含了涉众所关心的正确的功能，并且没用忘记任何功能，并允许我们轻松地查看整个系统。用例根据若干因素设定优先级，这些因素包括风险、对客户的重要程度以及技术难点。起始阶段中不需要过于正式的或过大的工件。按照您的需求让它们保持简单或者正式就可以。XP 包括对计划与系统验收的指南，但是 RUP 需要在项目的早期添加更多的一些内容。这些少量添加可能通过处理一套更完整的风险而为项目提供很大的价值。

    细化阶段

    细化阶段的目标是为系统构架设立基线，为在构建阶段大量的设计与实施工作打下坚实的基础。构架通过考虑最重要的需求（那些对系统构架影响最大的需求）与评估风险演进而来。构架的稳定性是通过一个或多个构架原型进行评估的。

    在 RUP 中，设计活动主要关注系统构架的概念，对于软件密集型的系统来说，就是软件构架的概念。使用组件构架是在 RUP 中体现的软件开发 6 项非常好的实践其中之一，该实践推荐在开发与所作所为构架上要投入一些时间。在这项工作花费的时间可以减缓与脆弱的、僵化日系统有关的风险。

    XP 使用"隐喻"替换了构架的概念。隐喻只捕获构架的一部分，而其余构架部分则随着代码开发的自然结果而演进。XP假定构架的形成是从生成简单的代码开始，然后进行持续的代码重构。

    在 RUP 中，构架不只是"隐喻"。在细化阶段中，您构建可执行的构架，从中可能降低与是否满足非功能性需求相关的许多风险，例如性能、可靠性以及健壮性。通过阅读XP文献，很可能推断出一些 RUP 为细化阶段所描述的内容，尤其是过于 XP 所称的基础设施的过分关注，都是徒劳无功的。XP 认为在没有必要的情况下创建基础设施所做的工作导致了解决方案过于复杂，并且所创建的结果对客户没有价值。在 RUP 中，构架与基础设施不是等同的。

    在 RUP 与 XP 中创建构架的方法是截然不同。RUP 建议您关注构架，避免随时间变化而产生的范围蔓延、增加项目规模以及采用新技术带来的风险。XP 采用足够简单或是很好理解的现有构架，该构架能够随着代码而演进。XP 建议您不要为明天而设计，而要为今天而实施。XP 相信如果您尽可能地保持设计简单，那么将来管理起来也轻而易举。RUP 希望您考虑该主张带来的风险。如果系统或者部分系统在未来不得不重写，那么 XP 认为这种举措比现在就计划这种可能性更明智而且花费更少。对于一些系统，这是千真万确的，而且使用 RUP 时，在您细化阶段考虑风险也会得出同一结论。RUP 并不认为对于所有系统这都是正确的，而且经验表明对于那些较大型、较复杂和没有先例的系统来说，这可能是灾难性的。

    虽然为未来的可能性（可能永远不会生生）花费太多的精力可能是一种浪费但是对未来进行足够的关注不失为一件精明之举。多少公司能花得起代价不断重写或者甚至是重构代码呢？

    对于任何项目，在细化阶段您应该至少完成这三项活动：

    定义、验证并且设定构架的基线。使用风险清单从起始阶段开发备选构架。我们关注是否能够保证构想中的软件具有可行性。如果选定技术对于系统没什么新颖性或者复杂性，这项任务不会花费太长时间。如果您正在向现有系统中添加内容，那么如果现有构架不需要进行变更，这项任务就不是必要的。但是当真正出现构架风险时，您并不想让您的架构来"碰运气"。

    作为这项活动的一部分，您可能执行一些组件选择，并且做出决定进行购买/创建/重用组件。如果这需要大量工作，您可以将其分为单独的活动。

    精化视图。在起始阶段，您开发了一个视图。因为你要确定项目的可行性，并且涉众有时间检查和评价系统，因此可能要对视图文档及需求作出一些变更。对视图与需求的修改一般在细化阶段进行。在细化阶段的最后，您已经深刻理解了用来构建和计划的最关键的用例。涉众需要得到认可，在当前构架的环境中，只要按照当前的计划开发整个系统，就能实现当前的设想。在随后的迭代过程中，变更的数量应该有所减少，但是您可能会在每次迭代中花一些时间进行需求管理。

    为构建阶段创建迭代计划并且设定基线。现在，可以为您的计划填充细节了。在每次构建迭代的最后，您可以按需要重新考虑计划并且进行调整。调整过程经常是必需的，因为需要进行的工作往往被错误地估算，业务环境也会常常变化，有时需求也会发生变更。为用例、场景以及技术工作设定优先级，然后将它们分配到迭代过程中。在每次迭代过程的最后，您计划产生一个能够为涉众提供价值的工作产品。

    您可以在细化阶段执行其他活动。我们推荐您建立测试环境并且开始开发测试。虽然详细的代码还没有完成，但是您仍然可以设计测试，也许可以实施集成测试。程序员应该随时准备进行单元测试，并且了解如何使用项目选定的测试工具。XP 推荐您在编写代码前先设计测试内容。这是个独到的见解，尤其是当您向现有代码主体中添加内容时。不过，无论您选择如何进行测试，都应该在细化阶段建立常规测试体制。

    RUP 描述的细化阶段包括 XP 中的研究阶段和投入阶段。XP 处理技术风险（例如新颖性和复杂性）的方式为使用"spike"解决方案，例如花费一些时间进行试验以对工作量进行估算。这种技术在许多案例中都是有效的，当较大风险没有体现在单个用例或"故事"中时，您就需要花些工夫确保系统的成功而且对工作量进行精确的估算。

    在细化阶段，您会经常更新工件，例如起始阶段的需求与风险清单。在细化阶段可能出现的工件包括：

    软件构架文档（SAD）。SAD 是一个复合型的工件，它提供了整个项目的技术信息的单一来源。在细化阶段的最后，该文档可能会包含详细的介绍，描述在结构上很重要的用例，并且确定关键的机制和设计元素。对于增强现有系统的项目，您可以使用以前的 SAD，或者如果你觉得不会带来什么风险，那么就决定不使用该文档。在所有的情况下，您都应该深思熟虑并且记录于文档中。

    构建过程的迭代计划。您可以在细化阶段计划构建迭代的次数。每次迭代都有特定的用例、场景以及其他分配的工作项目。这些信息都在迭代计划中有所体现并且设定基线。评审与核准计划可以作为细化阶段的出口标准的一部分。对于非常小的短期项目来说，您可以将细化阶段的迭代与起始过程和构建过程合并。关键性的活动仍然可以进行，但是迭代计划和评审所需的资源都会有所减少。