转化的四个步骤
多数的瀑布型的项目将开发工作划分为阶段或者时期；我们也可以将这个划分视为向迭代方法转换的第一步。但是为了实现向迭代开发方法的过渡，我们要使用下面四个步骤来应用不同的过程原则：
尽早的构建功能原型。
划分详细设计、实现和测试阶段到不同的迭代中。
在项目早期基线化一个可执行的架构。
采用迭代式的和风险驱动的管理过程。
让我们来更进一步的解释每一个步骤。
步骤 1 ：尽早的构建功能原型
作为向迭代开发转换的第一步，在需求和设计阶段考虑一个或者更多的功能原型。这些原型的目标是减少主要的技术风险和澄清项目涉众对系统应该做什么的理解。
通过识别最重要的三个技术风险和最重要的三个有必要澄清的功能部分开始。技术风险也许与新技术、对整个方案影响很多的未决定的技术选择或者你知道的很难满足的技术需求有关。功能上的风险也许与项目涉众为关键的功能性提供了模糊的需求或者几个需求对项目系统都是核心的有关。
对于每一个重要的技术风险，拟订你要原型化什么以减少风险。考虑一下下面的例子：
技术风险: 项目需要将一个已存在的应用移植到 IBM WebSphere Application Server 上运行。用户已经开始抱怨应用的性能，并且你所担心的是移植后也许性能会更加的慢。
原型: 构建一个架构的原型来找出移植你的应用的不同方法。要求一个专家级的 WebSphere 架构师来帮助你。评价结果并编写架构的和设计的指导方针为开发团队提供什么 应该做和什么 不应该做。这将增加你移植的应用的性能是足够好的以避免在项目后期返工的可能性。
技术风险: 你正在为安排和估计软件项目构建一个新的应用。你知道对于这个应用和购买的软件的关键区分将是如何能够很好的支持迭代计划。然而，这也是在你的需求说明中最模糊的部分之一。
原型: 基于你关于如何支持迭代项目计划的设想构建一个功能原型。通过向不同的项目涉中演示原型，你将可以鼓励他们更加注意项目的计划，并且他们能够告诉你他们对你的哪些设想是赞同的、哪些是不赞同的。原型将帮助你澄清计划的需求，也能够为你提供关于用户体验和对于你的应用的外表和感觉的有用的信息。这个原型甚至能够产生一些可重用的代码。
步骤 2 ：划分详细设计、实现和测试阶段到不同的迭代中
很多项目团队发现在他们知道项目是真正关于什么的之前划分一个项目成为有意义的迭代是困难的。但是，当你已经进入了详细设计阶段时，你通常对需求是什么和系统的架构看起来象什么样子有了很好的理解。这是我们试验迭代开发的时候了！
你能够使用两个主要的方法来确定你应该在什么样的迭代中作些什么事情。让我们从正反两方面讨论一下每一个方法。
方法 1 ：同时开发一个或者多个子系统。让我们假设你有九个子系统，每一个都有数量日益增加的组件。你可以划分详细设计、实现和测试阶段到三个迭代中，每个迭代瞄准实现九个子系统中的三个。如果在不同的子系统之间存在有限的依赖这将工作的相当的好。例如，如果你的九个子系统的每一个都为用户提供良好定义的一系列能力，你可以在第一个迭代中开发优先级最高的子系统，其次重要的子系统在第二个迭代中实现，以此类推。这种方法有很大的优点：如果你的进度落后了时间计划，你仍然可以交付可运行的具有最重要能力的部分系统。
然而，如果你有一个分层的体系架构，在上层的子系统依赖于底层子系统的能力，这种方法将不能够很好的工作。如果你必须要在一个时间内构建一个子系统，这样的体系架构将迫使你首先构建底层的子系统，然后构建越来越上层的子系统。但是为了构建在底层子系统的正确的能力，你通常需要在上层的子系统上进行大量的详细设计和实现的工作，因为他们决定了什么是你在底层子系统中需要的。这产生了 “catch-22”的现象；第二个方法解释了如何解决这个问题。
方法 2 ：首先开发最重要的场景。如果你使用方法 1 ，你一次只能开发一个子系统。使用方法 2 ，你将重点放在了重要的场景上，或者使用系统的关键方法上，然后再添加更多的不是那么重要的场景。这与方法 1 有什么不同呢？让我们来看一个例子。
假设你正在构建一个新的应用，这个应用将为用户提供管理缺陷的能力。这是一个分层的应用，被构建在 WebSphere Application Server 上，使用 DB2 作为底层的数据库。在首先的迭代中，你开发了一系列重要的场景，比如输入一个简单的缺陷。在第二次迭代中，你为这些场景添加了复杂性 — 例如，你也许使缺陷能够被一个工作流来处理。在第三次迭代中，你通过为非典型的用户提供完整的支持，比如保存部分的缺陷条目然后返回到这个条目中的能力等等。
使用这种方法，你在 所有的迭代中完成 所有的子系统的工作，但是在第一个迭代中你仍然关注最重要的场景，而将不是非常重要的或者最小难度的场景留到最后的迭代中实现。
如果你正工作在一个良好定义的体系架构的系统中时，方法 1 是更加适合的 — 比如，一个已存在系统的增进或者开发使用简单体系架构的新应用。多数构建复杂应用的项目应该使用方法 2 ，但是他们应该以这样的方式来计划迭代，这种方法能够削减后来迭代的范围以弥补可能的时间推延。
步骤 3: 在项目的早期基线化一个可执行的架构
你可以将这个步骤看作是更加正式和有组织的完成步骤 1 （ 尽早的构建功能原型）的方法。但是什么是“可执行的架构”呢？
可执行的架构是系统的部分的实现，它被构建以演示架构的设计所支持的关键的功能。更重要的是，它能够证明设计能够满足对于性能、生产能力、容量可靠性、可测量性和其他方面的需求。构建一个可执行的架构允许你在稍后的阶段中在一个坚实的基础上构建所有的系统功能性的能力。这个可执行的架构是一个 进化的原型，它的目的是当系统的架构成熟时，保持已经被证明的特性并保证他们最大可能的满足系统的需求。换句话说，这些特性将是交付系统的一部分。与你在步骤 1中构建的 功能原型相比，这个进化的原型覆盖了架构问题的所有方面。
生成一个进化的原型意味着你要设计、实现和测试一系统的个框架结构或者架构。在应用的角度上，系统的功能还没有被完成，但是大多数的构建模块之间的接口已经被实现了，你能够（并应该）在某种程度上编译并测试架构。指导初始的负载和性能测试。这个原型也会反映你的关键设计的决定，包括技术、主要组件和他们之间接口的选择。
但是你将如何为这个进化的原型提出系统的架构呢？关键是将重点放在最重要的百分之二十到三十的用例上（系统为用户提供的完全的服务）。这里是一些决定什么用例是最重要的方法。
功能是应用的核心，或者它使用的关键的接口。系统的关键功能应该能够决定系统的体系架构。通常的情况下架构师通过分析很多因素来识别最重要的用例：冗余管理策略、资源争夺风险、性能风险和数据安全策略等等。例如，在一个 POS 系统中，检查（Check Out）和支付（Pay）是关键的用例，因为它验证了信用卡确认系统的接口 — 并且它从性能和负载方面也是重要的。
选择描述了必须被交付功能的用例 。交付不包含关键功能的应用系统是没有意义的。例如，一个订单输入系统如果不允许用户输入订单将是不可接受的。通常，领域和问题专家能够从用户的角度理解被需要的关键功能（主要的行为、峰值数据处理、关键控制事务等等），并且他们可以帮助定义关键的用例。
选择描述了系统体系架构方面的功能并且没有被其他关键用例所包含的用例。为了确保你的团队能够将注意力放在所有主要的技术风险上，他们必须理解系统的每一个区域。甚至如果一定的架构领域没有出现在高风险中，它也许是隐藏了技术上的难度，这种技术上的难度仅仅能够通过设计、实现和测试架构领域的一些功能才能够被暴露出来。
上面所列出的第一个和最后一个标准是架构师最关心的；项目经理主要关注于前两个。
对于每一个关键的用例，识别最重要的场景并用他们创建可执行的系统架构。换句话说就是设计、实现和 测试这些场景。
步骤 4 ：采用迭代式的和风险驱动的管理过程
如果你将要遵循上面所描述的步骤 2 和步骤 3 ，那么你将会非常的接近“理想”迭代开发的模型。那么，你接下来的步骤应该是融合步骤 2 和步骤 3 ，并添加支持风险驱动和迭代开发的管理生命周期。这就是在 RUP 中被描述的迭代开式的生命周期。
RUP 对迭代开发提供了一个结构化的方法，它将一个项目划分成为四个阶段：初始阶段、细化阶段、构建阶段和转换阶段。每一个阶段包含了一个或者更多的迭代，每个迭代都关注于产生必要的技术上的可交付物以实现阶段的业务目标。团队经历的迭代次数与需要实现阶段的目标的数量是一样的，而不是更多。如果在团队计划的迭代次数内他们没有成功的实现这些目标，他们必须为那个阶段添加额外的迭代 — 并且推迟项目。为了避免这种事情发生，你一定要严格的将你的精力集中在每个阶段你需要实现的业务目标上。例如，在初始阶段将精力过于集中在需求上将会成生相反的效果。下面是典型的阶段目标的简要描述。
初始阶段: 通过获得对所有需求的高层次的理解和确立系统的范围来建立对系统将要构建什么的良好理解。减少多数的业务风险，为构建系统产生业务用例，并从所有项目决策人得到是否继续项目的确认。
细化阶段: 关心多数最具技术难度的任务：设计、实现、测试和基线化一个可执行的系统架构，包括子系统、他们的接口、关键组件和架构上的机制（例如，如何处理进程间通讯或者持久性问题）。通过实现和验证实际的代码，处理主要的技术任务，比如资源争夺风险、性能风险和数据安全风险。
构建阶段: 当你从一个可执行的系统架构迁移到系统的第一个可操作的版本时，需要完成大半的实现工作。部署数个内部和 alpha 版本以确保系统是可用的并且能够满足用户的需要。通过部署一个完全功能的系统 beta 版本来结束这个阶段，包括安装、支持文档和培训材料；然而，要记住功能、性能和系统总的质量将很可能需要调整。
转换阶段: 确保软件能够满足软件用户的需要。这个包括在系统发布的准备中测试产品，并且基于用户的反馈对系统进行小的调整。在软件开发周期的这个点上，用户反馈应该主要的关注在微调产品和配置、安装以及可用性的问题上；所有主要的结构问题已经在项目周期的早期被解决了。
应用这些步骤的多种方法
在本文中，我们已经描述了你如何能够使用四个步骤逐步的从瀑布型的开发方法转换到增量的迭代开发方法。每一个步骤都以最小的中断为你的开发工作添加了切实的价值。一些团队每次不止使用一个步骤；其他的团队可能在一个步骤上运作了几个项目，然后才执行下一个步骤。然而，你应该选择使用这种明智的实施方法，因为它能够帮助你在开发组织中减少由于过程变化所带来的风。
