从瀑布型开发到迭代型开发的转变(4)

　　功能是应用的核心，或者它使用的关键的接口。系统的关键功能应该能够决定系统的体系架构。通常的情况下架构师通过分析很多因素来识别最重要的用例：冗余管理策略、资源争夺风险、性能风险和数据安全策略等等。例如，在一个 POS 系统中，检查(Check Out)和支付(Pay)是关键的用例，因为它验证了信用卡确认系统的接口 — 并且它从性能和负载方面也是重要的。

　　选择描述了 必须被交付功能的用例 。交付不包含关键功能的应用系统是没有意义的。例如，一个订单输入系统如果不允许用户输入订单将是不可接受的。通常，领域和问题专家能够从用户的角度理解被需要的关键功能(主要的行为、峰值数据处理、关键控制事务等等)，并且他们可以帮助定义关键的用例。

　　选择描述了系统体系架构方面的功能并且没有被其他关键用例所包含的用例。为了确保你的团队能够将注意力放在所有主要的技术风险上，他们必须理解系统的每一个区域。甚至如果一定的架构领域没有出现在高风险中，它也许是隐藏了技术上的难度，这种技术上的难度仅仅能够通过设计、实现和测试架构领域的一些功能才能够被暴露出来。

　　上面所列出的第一个和最后一个标准是架构师最关心的;项目经理主要关注于前两个。

　　对于每一个关键的用例，识别最重要的场景并用他们创建可执行的系统架构。换句话说就是设计、实现和 测试这些场景。

　　步骤 4 ：采用迭代式的和风险驱动的管理过程。

　　如果你将要遵循上面所描述的步骤 2 和步骤 3 ，那么你将会非常的接近“理想”迭代开发的模型。那么，你接下来的步骤应该是融合步骤 2 和步骤 3 ，并添加支持风险驱动和迭代开发的管理生命周期。这就是在 RUP 中被描述的迭代开式的生命周期。

　　RUP 对迭代开发提供了一个结构化的方法，它将一个项目划分成为四个阶段：初始阶段、细化阶段、构建阶段和转换阶段。每一个阶段包含了一个或者更多的迭代，每个迭代都关注于产生必要的技术上的可交付物以实现阶段的业务目标。团队经历的迭代次数与需要实现阶段的目标的数量是一样的，而不是更多。如果在团队计划的迭代次数内他们没有成功的实现这些目标，他们必须为那个阶段添加额外的迭代 — 并且推迟项目。为了避免这种事情发生，你一定要严格的将你的精力集中在每个阶段你需要实现的业务目标上。例如，在初始阶段将精力过于集中在需求上将会成生相反的效果。下面是典型的阶段目标的简要描述。

　　初始阶段: 通过获得对所有需求的高层次的理解和确立系统的范围来建立对系统将要构建什么的良好理解。减少多数的业务风险，为构建系统产生业务用例，并从所有项目决策人得到是否继续项目的确认。

　　细化阶段: 关心多数最具技术难度的任务：设计、实现、测试和基线化一个可执行的系统架构，包括子系统、他们的接口、关键组件和架构上的机制(例如，如何处理进程间通讯或者持久性问题)。通过实现和验证实际的代码，处理主要的技术任务，比如资源争夺风险、性能风险和数据安全风险。

　　构建阶段: 当你从一个可执行的系统架构迁移到系统的第一个可操作的版本时，需要完成大半的实现工作。部署数个内部和 alpha 版本以确保系统是可用的并且能够满足用户的需要。通过部署一个完全功能的系统 beta 版本来结束这个阶段，包括安装、支持文档和培训材料;然而，要记住功能、性能和系统总的质量将很可能需要调整。

　　转换阶段: 确保软件能够满足软件用户的需要。这个包括在系统发布的准备中测试产品，并且基于用户的反馈对系统进行小的调整。在软件开发周期的这个点上，用户反馈应该主要的关注在微调产品和配置、安装以及可用性的问题上;所有主要的结构问题已经在项目周期的早期被解决了。 1

　　回页首

　　应用这些步骤的多种方法

　　在本文中，我们已经描述了你如何能够使用四个步骤逐步的从瀑布型的开发方法转换到增量的迭代开发方法。每一个步骤都以最小的中断为你的开发工作添加了切实的价值。一些团队每次不止使用一个步骤;其他的团队可能在一个步骤上运作了几个项目，然后才执行下一个步骤。然而，你应该选择使用这种明智的实施方法，因为它能够帮助你在开发组织中减少由于过程变化所带来的风险。

原文转自：http://www.ibm.com/developerworks/cn/rational/r-iterative/