概述
咱们集中讨论怎样经过使用两个流行的方法获得过程的恰当级别：Rational Unified Process 或简称 RUP 以及极限编程（XP）。咱们展现怎样在小型项目中使用 RUP 以及 RUP 怎样处理 XP 没有涉及到的领域。两者融合为项目团队提供了所需的指南--下降风险同一时候完毕交付软件产品的目标。 RUP 是由 IBM Rational 开发的过程框架。它是一种迭代的开发方法，基于六个通过行业验证的最佳实践（參见 RUP 附录）。随着时间的推动，一个基于 RUP 的项目将经历四个阶段：起始阶段（Inception）、细化阶段（Elaboration）、构造阶段（Construction）、交付阶段 （Transition）。每个阶段都包含一次或者屡次的迭代。在每次迭代中，您依据不一样的要求或工做流（如需求、分析和设计等）投入不一样的工做量。 RUP 的关键驱动因素就是减小风险。RUP 经过数千个项目中数千名 IBM Rational 客户和合做伙伴使用而获得精化。下图展现了一个典型迭代过程的工做流： 典型迭代流
 做为风险怎样影响过程的一个样例，咱们应该考虑是否需要为业务建模。假设由于对业务的理解中没有考虑到一些重大风险，将致使咱们所构建的系统是错误 的，那么咱们就应该运行一些业务建模工做。咱们需要正式进行建模工做吗？这取决于咱们的涉众--假设一个小团队将非正式地使用结果，那么咱们或许仅仅进行非 正式的记录就可以。假设组织中的其它人也将使用结果或者查看结果，那么咱们可能就要投入更大的努力，并且确保该结果的正确性和可理解性。 您可以定制 RUP 使其知足差点儿不论什么项目的需要。假设没有知足您特定需要的即装即用的过程或路线图，您可以轻松地建立您本身的路线图。路线图描写叙述了该项目怎样计划使用过程， 所以表明了该项目的特定过程实例。这就意味着，RUP 可以按需要变得简单或复杂，咱们将在本文中详解。 XP 是一个用于小型项目中的以代码为中心的轻量级过程（參见 XP 附录）。它来自 Kent Beck 的创意，在大概 1997 年 Chrysler 公司的 C 3 工资单项目中获得软件界的关注。如同 RUP 同样，XP 也是基于迭代的，并且体现了诸如小规模公布、简单设计、測试以及持续迭代几项实践，。XP 为恰当的项目和环境引入了一些有效的技术；只是，当中也存在隐藏的若是、活动和角色。 RUP 和 XP 具备不一样的基本原理。RUP 是过程组件、方法以及技术的框架，您可以将其应用于不论什么特定的软件项目，咱们但愿用户限定 RUP 的使用范围。XP，从还有一方面来讲，是一个具备不少其它限制的过程，需要附加内容以使其适合完整的开发项目。这些不一样点解释了软件开发界的一个观点：开发大型 系统的人员使用 RUP 解决这个问题，而开发小型系统的人员使用 XP 做为解决方式。咱们的经验代表大部分的软件项目都处于二者之间--尽力找寻适用于各自状况的过程的恰当级别。单纯地使用二者之中的一个是不充分的。 当您在 RUP 中融合了 XP 技术时，您会获得过程的正确量，既知足了项目所有成员的需要，又攻克了所有基本的项目风险问题。对于一个工做于高信任环境中的小型项目团队，当中用户是团 队的一部分，那么 XP 全然可以胜任。对于团队愈来愈分散，代码量愈来愈大，或者构架没有很是好定义的状况，您需要作一些其它工做。在用户交互具备"契约"风格的项目中，仅有 XP 是不够的。RUP 是一个框架，您可以从 RUP 出发，在必要时以一组更健壮的技术来扩展 XP。 本文的下面部分描写叙述了一个基于 RUP 四个阶段的小型项目。在每个阶段中，咱们都肯定了所产生的活动和工件 。尽管 RUP 和 XP 具备不一样的角色和职责，但是咱们在这里不会处理这些差别。对于不论什么组织或项目，实际项目成员必须在过程当中与正确的角色关联起来。 项目启动－起始阶段
对于新的开发项目来讲，起始阶段是很是重要的，在项目继续进行前，您必须处理重要的业务与需求风险。对于那些加强现有系统的项目，起始阶段是比較短暂的，但是其目的还是肯定该项目的实施价值及可行性。 在起始阶段中，为了构建软件您可以建立业务案例。视图是起始过程当中的关键工件。它是系统的高级描写叙述。它为每个人解释该系统是什么、可能使用系统的用 户、使用系统的缘由、必须具有的功能，以及存在的约束。视图可能很是短，或许仅仅有一两段。视图每每包含软件必须为客户提供的关键功能。 如下的样例展现了一个项目的很是短视图，该项目对 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，或者假设你认为不会带来什么风险，那么就决定不使用该文档。在所有的状况下，您都应该深思熟虑并且记录于文档中。 构建过程的迭代计划。 您 可以在细化阶段计划构建迭代的次数。每次迭代都有特定的用例、场景以及其它分配的工做项目。这些信息都在迭代计划中有所体现并且设定基线。评审与核准计划 可以做为细化阶段的出口标准的一部分。对于很小的短时间项目来讲，您可以将细化阶段的迭代与起始过程和构建过程合并。关键性的活动仍然可以进行，但是迭代 计划和评审所需的资源都会有所下降。 构建阶段
构建的目标是完毕系统开发。构建阶段从某种意义上来看是一个制造过程，当中重点工做就是管理资源、控制操做以优化成本、日程和质量。从这个意义上来说，管理理念应该进行一个转换，从起始阶段和细化阶段的知识产权开发转换到构建和交付阶段的部署产品的开发。 XP 側重构建阶段。构建阶段是编写产品代码的阶段。XP所有阶段的目的都是为了进行计划，但是 XP 的关注焦点是构建代码。 构建阶段的每次迭代都具备三个关键活动： 管理资源与控制过程。 每个人都需要了解本身的工做内容和时间。您必须保证工做负荷不会超过您的能力，而且工做可以按计划进行。 开发与測试组件。 您构建组件以知足迭代中用例、场景以及其它功能的需要。您对其进行单元測试和集成測试。 对迭代进行评估。 在迭代完毕时，您需要推断是否已经达到了迭代的目标。假设没有，您必须又一次划分优先级并管理范围以确保能够按时交付系统。 不一样类型的系统需要使用不一样的技术。RUP 为软件project师提供了不一样的指导，以帮助他们建立恰当的组件。以用例和补充（非功能）需求的形式提出的需求是足够具体的，可以使project师开展工做。RUP 中的若干活动为设计、实施和測试不一样种类的组件提供了指南。一名有经验的软件project师不需要具体查看这些活动。经验稍欠缺一些的project师可以经过最佳实践得到 很是大的帮助。每个团队成员都可以按需要深刻研究过程或者仅仅是略微了解一下。只是，他们都參照一个单独的过程知识基础。 在 XP 中，"故事"驱动实施过程。在 Extreme Programming Installed 一书中，Jeffries等人以为"故事"是程序猿的"会话承诺"（promises for conversation）。 持续有效的交流大有裨益。尽管老是需要澄清一些细节，假设"故事"不够具体，而使程序猿不能完毕他们大部分工做，那么可以说"故事"尚未就绪。用例必须 足够具体以方便程序猿实施。在不少状况下，程序猿会帮助编写用例的技术细节。Jeffries 等人以为，会话应该记录在文档中并且附加到"故事"中。RUP 也容许这个观点，除了以用例规格说明的形式，可以按需要使用非正式的形式。捕获并管理会话的结果是您必须管理的任务。 XP 的好处在于构建阶段。对于大多数团队来讲，都存在适用于他们的"智慧与指南的结晶"。XP 中最显著的实践包含： 測试--程序猿不断地随着代码的开发编写測试。測试反映了"故事"。XP提倡您首先编写測试，这是一项优秀的实践，因为它可以迫使您深入地理解"故 事"，并且在必要的地方提出不少其它的问题。不论在编写代码以前仍是以后，必定要编写測试。将它们添�到您的測试包中，并且保证每次代码变动时都执行測试。 重构--不断重构系统的结构而不改变其行为，可以使其更加简单或灵活。您需要推断对您的团队来讲是否存在一个较好的实践。简单与复杂的判别否因人而 异。有这样一个样例，一个项目中的两个很是聪明的project师每晚都要重写对方的代码，因为他们以为对方的代码过于复杂。这产生了一个反作用，也就是他们老是干扰 次日其它成员的工做。測试是有帮助的，但是假设他们之间不陷入代码之争的话，那么团队的处境就会更好一些。 结对编程--XP 以为结对编程可以在更短的时间内建立出更好的代码。有证据代表这是正确的 。假设您遵守这项实践，就需要考虑不少人文与环境的因素。程序猿愿意对此进行尝试吗？您的物理环境可以知足这样的状况吗，即有足够的空间使两个程序猿在一个 单独工做站中有效地工做？您怎样对待远程工做或者在其它地点工做的程序猿？ 持续集成--集成与构建工做需要持续进行，可能天天不止一次。这是一种确保代码结构完整的很是好的方式，它还赞成在集成測试过程当中进行持续的质量监控。 集体代码所有权--不论什么人都可以随时改动不论什么代码。XP 依赖这样一个事实，即一组好的单元測试将会下降这项实践的风险。让你们将每一件事都搞清楚的优势不能局限在必定的尺度上--是 1 万行代码、2 万行代码仍是必定要少于 5 万行？ 简单设计--随着重构过程的进行，需要不断地改动系统设计使其变动简单。再一次重申，您需要推断这项工做进行到何种程度才刚好合适。假设您在细化阶段中花费了必要霎时间来设计构架，咱们相信简单的设计将会很是快完毕并且很是快变得稳定。 代码标准--这一直都是一项良好实践。标准是什么都不要紧，仅仅要您使用它们而且每个人都承认就可以。 RUP 与 XP 都以为您必须管理（和控制）迭代过程。衡量标准可以提供较好的计划信息，因为它们可以帮助您选择对于您的团队来讲什么是最适合的。需要衡量三件事：时间、 规模和缺陷。这样您就可以得到所有类型您所感兴趣的统计数字。XP 为您提供简单的衡量标准来推断进展并且预測成果。这些衡量标准环绕着完毕的"故事"数量、经过測试的数量以及统计中的趋势这些问题。XP 为使用最少许的衡量标准作出了一个优秀的表率，因为查看太多并不必定会添加�项目成功的机会。RUP 为您提供了对于您可以衡量的内容以及怎样衡量的指导，并且举了有关衡量标准的样例。在所有的状况中，衡量标准必须简单、客观、易于搜集、易于表达，并且不 易产生误解。 在构建阶段的迭代过程当中将会产生哪些工件呢？这取决于迭代是处于构建阶段的早期仍是后期，您可以建立下面工件： 组件--组件表明了软件代码中的一部分（源码、二进制代码或者可运行程序），或者包括信息的文件，好比，一个启动文件或者一个 ReadMe 文件。组件还可以是其它组件的聚合，好比由几个可运行程序组成的应用程序。 培训资料--假设系统的用户界面比較复杂，那么请在用例的基础上尽早编写用户手冊和其它培训资料的初稿。 部署计划--客户需要一个系统。部署计划描写叙述了一组安装、測试并且有效地向用户交付产品所需的任务。对于 以Web 为中心的系统来讲，咱们已经发现，部署计划的重要性又提升了。 交付阶段迭代计划--临近交付时，您需要完毕并且评审交付阶段迭代计划。 代码完整吗？
以为代码就是设计并且设计也就是代码。代码与自身老是一致的，这一点是千真万确的。咱们以为花费精力进行设计并且沟通设计是很是值得的，而不不过建立代码。如下的小故事会说明这一点。 RUP 与 XP 间的差别除了创建构架的方法之外，还包含其它方面的不一样。当中一点就是关于设计概念的沟通方式。XP 一名project师曾有两次这种软件项目经历，设计体现在代码中，并且仅仅能在代码中找到设计信息。这两个项目都是关于编译器的：一个是改进与维护用于 Ada 编译器的优化程序，还有一个项目是将一个编译器的前端移植到一个新的平台上，并且链接一个第三方的代码生成器。 编译器技术是比較复杂的，但也是广为人知的。在这两个项目中，该project师想要概览编译器（或者优化程序）的设计和实施。在每个案例中，他都接到一堆源 代码清单，大概有几英尺厚，而且被告知"查看这些信息"。他本应被提供一些带有支持性文字的构建很是好的图。优化程序的项目没有完毕。但是编译器项目确实取 得了成功，由于在代码开发过程当中进行了普遍的測试，因此代码质量很是高。这位project师花费了数天时间研究调试器中的代码以弄明确其做用。我的的损失尚在其次， 团队的损失代价就更不值得。咱们并无按 XP 所看到的的那样在 40 小时后完毕开发，咱们反而花费了大量我的努力来完毕工做。 仅仅开发代码带来的主要问题就是无论代码文档编写得多么好，它都没有告诉您它自己要解决的问题，它仅仅提供了问题的解决方式。一些需求文档在最初用户和 开发者继续工做很是长时间之后，仍然可以很是好地解释项目的原始目标。为了维护系统，您每每需要了解最初项目团队的设计目标。一些高级设计文档都是相似的 --代码经常没有通过高度的抽象，因此没法提供不论什么信息以代表整体的系统能够实现什么功能。在面向对象的系统中，这一点尤为是正确的，因为只查看里面的 类文件是很是难甚至没法得出运行线程。设计文档指导您在后期出现故障时该查看的内容--在后期经常会出现故障。 这个故事说明花费时间建立与维护设计文档确实会有所帮助。这可以减小误解的风险，并且加速开发过程。XP 的方式就是花费几分钟勾画出设计的大概内容或者使用 CRC 卡片。 但是团队不主张这样，而仅仅是进行代码开发。他们有一个隐含的若是，那就是任务很是easy，咱们已经知道该怎样进行了。即便咱们成功地完毕了任务，那么下一个新 来的人可能就不会如此幸运。RUP建议您多花费一些时间建立并维护这些设计工件。 交付阶段
交付阶段的焦点就是确保软件对于终于用户是可用的。交付阶段包含为公布进行产品的測试，在用户反馈的基础上作微小的调整等几方面内容。在生命周期的这个时刻，用户反馈主要集中在精确调整产品、配置、安装，以及可用性等问题上。 较早公布、经常性公布都是很是好的办法。但是，咱们经过公布要达到的目的是什么呢？XP 没有清楚地解释这个问题，也没有处理公布商业软件所必须制造问题。在内部项目中，您可以为解决这些问题找到捷径，但是即便这样，您仍然需要编辑文档、员工 培训等工做。那么技术支持与变动管理又怎样呢？但愿现场客户控制这些内容，这是可行的吗？Bruce Conrad 在他的 XP 的 InfoWorld 评论 中指出用户并不但愿获得的软件老是在持续变动。您必须对高速变动软件的利益和变动的劣势及可能带来的不稳定性进行权衡。 当您决定公布的时候，您必须为终于用户提供比代码多得多的东西。交付阶段的活动和工件会指导您完毕本部分软件开发过程。这些活动主要是为了向您的客户提供可用的产品。交付阶段的关键活动例如如下： 肯定终于用户支持资料。该活动比較简单，您仅仅需提供一个清单就能够。但是务必要确保您的组织已准备好对客户进行技术支持。 在用户的环境中測试可交付的产品。假设您能够在公司内部模拟用户环境，那是最好只是的。不然，就到客户的公司去，安装软件并且保证其能够执行。您必定不想尴尬地回答客户："但是在咱们的系统上工做很是正常。" 基于用户反馈精确调整产品。假设可能的话，在您向有限数量客户交付软件时计划一次或者屡次 Beta 測试周期。假设进行该測试，那么就需要对 Beta 測试周期进行管理，并且考虑您"收尾工做"中的客户反馈。 向终于用户交付终于产品。对于不一样类型的软件产品和公布版本号，需要处理不少有关打包、制造和其它产品问题。您确定不会只将软件拷贝到一个目录中，而后向客户发一封邮件告诉他们软件已经到位了。 与其它阶段同样，过程的格式与复杂度都有所不一样。只是，假设您没有注意部署细节，那么可能致使数周或数月的良好开发工做前功尽弃，从而在进入目标市场时以失败了结。 在交付阶段中您可以生成若干工件。假设您的项目涉及到未来的公布（有多少项目没有涉及到呢？），那么您就应该開始为下次公布肯定功能和缺陷。对于不论什么项目，下列工件都相当重要： 部署计划--完毕您始于构建阶段的部署计划并且将其做为交付的路线图。 版本号凝视--它是一个比較少见的软件产品，不包括对终于用户相当重要的指令。可以对其作出计划，对于凝视要有一个可用的、一致的格式。 交付阶段资料与文档--这类资料可以採取很是多形式。您可以在线提供所有内容吗？您会进行指导吗？您的产品帮助完整并且可用吗？不要以为您所了解的，客户也相同了解。您的成功就在于帮助您的客户取得成功。 结束语
构建软件的工做远远多于编 写代码所工做。一个软件开发过程必须集中处理向用户公布高质量软件的所有必需活动。一个完整的过程没必要是庞大的。咱们经过集中论述项目中的主要活动和工 件，已经向您展现了怎样进行一个小型但是完整的过程。假设运行某项活动或者建立某个工件对于缓解项目中的风险是有帮助的，那么就请进行。您可以按需要为您 的项目团队和组织使用或多或少的过程和格式。 RUP 和 XP 并没必要是互相排斥的。经过结合使用这两种方法，您全然可以获得一个过程，帮助您比方今更快地交付更高质量的软件。Robert Martin 描写叙述了一个叫作 dX 的过程，他将其做为 RUP 的附属品 。它就是一个从 RUP 框架中构建的过程的实例。 一个优秀的软件过程可以使用经业界验证的最佳实践。最佳实践已经在真实的软件开发组织中使用，并且经历了时间的考验。XP 是眼下广为关注的方法。它以代码为中心，并提供了一项承诺：花费最少的过程开销获得最大的生产力。XP 中的不少技术值得在恰当的状况中考虑和採用。 XP 关注"故事"、測试和代码--它以必定的深度讨论了计划，但没有具体阐述怎样获取计划。XP 意味着您可以完毕其它一些工做，好比"使用一些卡片进行 CRC 设计或者草拟某种 UML……"或者"请不要生成并不使用的文档或者其它工件"，但仅仅是一带而过。RUP 但愿您在定制和更新开发计划时，只考虑建立实用和必须的东西，并且指出了这些东西该是什么。 RUP 是一个可以处理整个软件开发周期的过程。它关注最佳实践，并且通过了数千个项目的洗礼。咱们鼓舞研究和发明新的技术以产生最佳实践。随着新的最佳实践崭露头脚，咱们但愿将它们归入 RUP 中。 附录：Rational Unified Process
Rational Unified Process，或者简称 RUP，提供了软件开发的规律性方法。它是由IBM Rational开发并维护的过程产品。它为来同类型的项目提供了几种即装即用的路线图。RUP 还提供了一些信息，帮助您在软件开发过程当中使用其它 Rational 工具，但是它不要求将 Rational 工具备效地应用于整个组织，您也可以将 Rational 工具与其它供应商的产品进行集成。 RUP 为软件项目所有方面提供了指导。并不需要您运行不论什么特定的活动或者建立不论什么特定的工件。它仅仅为您提供信息和指南，您可以决定将哪些应用于您的组织。假设没有特定的路线图适合您的项目或者组织，RUP 还提供了一些指南来帮助您量身定作你的过程。 RUP 强调採用现代软件开发的一些最佳实践，做为一种减小开发新软件所带来的内在风险的方式。这些最佳实践包含： 1． 迭代开发
2． 管理需求
3． 使用基于组件的构架
4． 可视建模
5． 持续的质量验证
6． 控制变动 这些最佳经验融合到 Rational Unified Process 的下面定义中： 角色--运行的系列活动和拥有的工件。
学科--软件project中的关键领域，好比需求、分析与设计、实施与測试。
活动--工件生成与评估方式的定义。
工件--在运行活动中所使用的、生成的或改动的工做产品。 RUP 是一个迭代过程，肯定了不论什么软件开发项目的四个阶段。随着时间的推动，每个项目都要经历起始阶段、细化阶段、构建阶段和交付阶段。每个阶段包含一次或屡次 迭代，当中您可以生成可运行文件，但是系统可能不完整（可能起始阶段除外）。在每次迭代过程当中，您以不一样的细节级别运行几个学科中的活动。下文是 RUP 的概述图。 RUP 概览图
The Rational Unified Process, An Introduction, Second Edition 一书是 RUP 的好的概述。您可以在 Rational 的 Web 网站 www.rational.com 上找到更进一步的信息和对于 RUP 的评价。 附录：极限编程
极限编程（XP） 是由 Kent Beck 在 1996 年开发的一种软件开发学科。它基于四个价值：沟通、简单、反馈和勇气。它强调客户与开发团队成员的持续沟通，在开发进程中设立一名现场客户。该现场客户决 定建立的内容和顺序。经过持续重构代码并建立最小的非代码工件集合而体现简单。不少短时间公布和持续单元測试创建了反馈机制。勇气意味着完毕正确的事情，即 使并不是最流行的事情。它还意味着诚实面对您能作的和不能作的事情。 12 个 XP 实践为这四个价值提供支持。它们是： 有计划的开发：经过结合使用优先级"故事"和技术估算，肯定下一版本号的功能。 小版本号：以小的增量版本号经常向客户公布软件。 隐喻：隐喻是一个简单、共享的"故事"或描写叙述，说明系统怎样工做。 简单设计：经过保持代码简单从而保证设计简单。不断的在代码中寻找复杂点并且立马进行移除。 測试：用户编写測试内容以对"故事"进行測试。程序猿编写測试内容来发现代码中的不论什么问题。在编写代码前先编写測试内容。 重构：这是一项简化技术，用来移除代码中的反复内容和复杂之处。 结对编程：团队中的两个成员使用同一台计算机开发所有的代码。一我的编写代码或者驱动，还有一我的同一时候审查代码的正确性和可理解性。 集体代码所有权：不论什么人都拥有所有的代码。这就意味这每个人都可以在不论何时变动不论什么代码。 持续集成：天天屡次建立和集成系统，仅仅要不论什么实现任务完毕就要进行。 每周 40 个小时：程序猿在疲劳时没法保证最高效率。连续两周加班是绝对不一样意的。 现场客户：一名真实的客户全时工做于开发环境中，帮助定义系统、编写測试内容并回答问题。 编码标准：程序猿採用一致的编码标准。 |