简介 本章将概括案例研究在迭代1的需求，然后简要讨论初始和细化阶段的过程思想。为理解后续章节对本次迭代的讨论，阅读选择需求很重要。
迭代1的需求和重点：OOA/D技术的核心
在这些案例中，细化阶段打得迭代1强调的是基础范围和在构建对象系统中所使用的常见OOA/D技术。当然，构建软件还需要其他许多技术，例如数据库设计、可用性工程、UI设计等，但是本书主要关注OOA/D和UML应用，其他技术不在本书涵盖范围之内。
在迭代开发中，我们并非一次就实现所有需求
对迭代生命周期方法（例如UP、XP、Scrum等）的关键理解就是：我们对需求子集开始具有产品品质的编程和测试，并且我们在完成所有需求分析之前开始这些开发，这与瀑布过程相反。
在多个迭代里对同一用例进行增量式开发 注意，并不是在迭代1里要实现处理销售用例中的所有需求。通常是在若干迭代内对同一用例的各种场景进行开发，并且逐渐地扩展系统直到最终完成所有需要的功能性（图8-1）另一方面，简短的用例可以在一次迭代中完成。
过程：初始和细化 在初始阶段发生了什么
案例研究的初始阶段大概只持续了一周。因为这不是项目的需求阶段，所创建的制品应该是简明和不完整的，该阶段用时很短，并且只经过轻量级的调查。
初始阶段是迈向细化阶段的一小步。在该阶段决定基本的可行性、风险和范围，对项目是否值得进行更深入的调查进行决策。并不是所有适合于初始阶段的活动都要涵盖在其中，这一阶段强调面向需求的制品。初始阶段中可能的活动和制品包括：
- 简短的需求讨论会
- 大多数参与者、目标和用例名称。
- 大多数以摘要形式编写的用例。以详述形式编写10%~20%的用例，以加深对范围和复杂性的理解
- 确定大多数具有影响和风险的质量需求。
- 编写设想和补充性规格说明的第一个版本
- 风险列表
- 技术上的概念验证原型和其他调查，用以揭示特殊需求的技术可行性
- 面向用户界面的原型，用于确定对功能需求的设想
- 对购买/构建/复用构建的建议，在细化阶段进行精化。
- 对候选的高层架构和构件给出建议。
- 第一次迭代的计划
- 候选工具列表
细化之所在
细化阶段是最初的一系列迭代，在这一阶段，小组进行细致的调查、实现（编程和测试）核心架构、澄清大多数需求和应对高风险问题。在UP中，“风险”包含业务价值。因此，早期工作可能包括实现那些被认为重要的场景，而不是专门针对技术风险。
细化阶段通常由两个或多个迭代组成，建议每次迭代的时间为2~6周。
在这一阶段，不是要创建可以丢弃的原型。与之相反，该阶段产生的代码和设计是具有产品品质的最终系统的一部分。在一些UP的描述中，会误解"架构原型"(architectural
prototype)这一术语用来描述局部系统。该术语不是指可废弃的、实验性的原型，在UP中，它表示最终系统的产品化子集。该术语更常见名称是可执行架构(executable architecture)或架构基线(architectural baseline)。 用一句话来概括细化：构建核心架构，解决高风险元素，定义大部分需求，以及预计总体进度和资源。
在细化阶段可能出现的一些关键思想和最佳实践包括：
- 实行短时间定量、风险驱动的迭代。
- 及早开始编程
- 对架构的核心和风险部分进行适应性的设计、实现和测试。
- 尽早、频繁、实际地测试。
- 基于来自测试、用户、开发者的反馈进行调整。
- 通过一系列讨论会，详细编写大部分用例和其他需求，每个细化迭代举行一次。
在细化阶段会开始构建哪些制品 表8-1列出的是可能在细化阶段开始构建的制品样例，同时指明这些制品要解决的问题。
何时知道自己并没有理解细化阶段
- 对于大部分项目，细化阶段都比“几个”月更长。
- 只有一次迭代（除极少数易于理解的问题外）
- 在细化开始前就定义了大部分的需求
- 没有处理具有风险的元素和核心架构。
- 没有产生可执行架构，没有进行产品代码的编程。
- 认为细化阶段主要是需求或设计阶段，为构造阶段的实现进行准备。
- 试图在编程之前进行彻底和细致的设计
- 只有少量的反馈和调整；用户没有持续地参与评估和反馈。
- 没有尽早和实际的测试
- 在编程之前推测性地结束架构设计
- 认为细化阶段是进行概念验证编程的阶段，而不是对产品化核心架构编程的阶段。
如果在项目中出现这些现象，则表明你对细化阶段的理解是错误的，并且已经在UP之上强加了瀑布思想。
过程：计划下一个迭代 通过风险、覆盖范围和关键程度组织需求和迭代。
- 风险既包括技术复杂性、也包括其他因素，例如工作量或可用性的不确定性。
- 覆盖范围意味着在早期迭代中至少要涉及系统的所有主要部分--或许是对大量构建进行“广泛和肤浅”的实现。
- 关键程度是指客户认为具有高业务价值的功能。
在迭代1之前完成等级划分，但是在迭代2之前要重新划分，依此类推，因为新需求和新理解会对等级排列产生影响。也就是说，迭代的计划是可适应的，并不是项目开始之时必须固定下来的。