迭代1--基础

迭代1的需求和重点：OOA/D技术的核心

在这些案例研究中，细化阶段的迭代强调的使基础范围和在构件对象系统中所使用的常见OOA/D技术。

NextGen POS

NextGen POS 应用在第一个迭代要处理的需求如下：

• 实现处理销售用例中基本和关键的场景：输入商品并收取现金。
• 实现用于支持迭代初始化需要的启动用例。
• 不处理任何特殊和复杂的部分，仅仅针对场景的简单理想路径，并对此进行设计和实现。
• 不与外部服务进行协作
• 不应用复杂的定价规则

Monopoly案例

Monopoly应用在第一个迭代要处理的需求如下：

• 实现玩Monopoly游戏用例的基本和关键场景：游戏者围绕棋盘四周的方格移动。
• 四线用于支持迭代初始化需要的启动用例。
• 支持2-8个游戏者。
• 游戏通过一些列回合进行。每个回合中，每个游戏之轮的一次机会。在每一伦茨中，游戏这根据所抛掷的两个六面骰子的点塑综合，在微软期盼的放个上，按顺时针方向将妻子移动相应的格数。
• 游戏只能进行20回合。
• 抛掷骰子后，显示游戏之明或和掷骰子的结果。当游戏中移动并占据一个方格后，显示游戏之名字和所占方格的名字。
• 在迭代1中，不考虑进去、输赢、买进或支付租金以及任何种类的特殊方格。
• 每个方格都由相应的名称。游戏开始时，每个游戏者的妻子都在名为”GO“的方格上。方格的名称将一次为GO、方格1、方格2、...、方格39.

• 处理游戏这的数量外，游戏以模拟的方式运行，不需要任何用户输入。

  后续迭代将基于这些功能进行。

迭代开发中，我们并发一次就实现所有需求

注意，以上对迭代1的需求使所有需求或用例的子集。

还要注意，我们并没有完成NextGen POS系统所有的需求分析，我们只是详细地分析了处理销售用例，还没有对其他大量需求展开分析。

对迭代生命周期方法的关键理解就是：我们对需求子集开始具有产品品质的编程和测试，并且我们在完成所有需求分析之前开始这些开发，这与瀑布过程相反。

在多个迭代里对统一用例进行增量式开发

注意，并不是在迭代1里要实现处理销售用例中的所有需求。通常是在若干迭代里对同一个用例的各种场景进行开发，并且渐进地扩展系统指导最终完成所有需要的功能性。另一方面，简短的用例可以在一次迭代中完成。

过程：初始和细化

在UP开发和我们的案例研究中，假设我们以及结束初始阶段并且正在进入细化阶段。

初始阶段发生了什么

初始阶段中可能的活动和制品包括：

• 简短的需求讨论会。
• 大多数参与者、目标和用例名称
• 大多数以摘要形式编写的用例。以详述形式编写10%-20%的用例，以加深对范围和复杂性的理解。
• 确定大多数具有影响和风险的质量需求。
• 编写设想和补充i选哪个规格说明的第一个版本。
• 风险列表。
• 技术上的概念验证原型和其他调查，用以揭示特殊需求的技术可行性。
• 面向用户界面的原型，用于确定对功能需求的设想
• 对购买/构件/服用狗啊就的建议，在细化阶段进行精化。
• 对候选的高层架构和构件给出建议。
• 第一次迭代的计划。
• 候选的工具列表。

细化之所在

细化是一般项目中最初的一系列迭代，其中包括：

• 对核心、由风险的软件架构进行编程和测试。
• 发现并问电工需求的主题部分。
• 规避主要风险。

在这一阶段，小组进行细致的调查、实现核心架构、澄清大多数需求和应对高风险问题。在UP中，”风险“包含业务价值。因此，早期工作可能包括实现哪些被认为重要的场景，而不是专门针对技术风险。

细化阶段通常通常由两个或多个迭代组成。

细化不是设计阶段，在该阶段也不是要完成所有模型的开发。

在这一阶段，不是要创建可以丢弃的原型。在UP中，它标识最终系统的产品化子集。该术语更常见名称是可执行架构或架构基线。

用一句话来概括细化：构建黑犀牛架构，解决高风险元素，定义大部分需求，以及预计总体进度和资源。

细化阶段可能出现的一些关键思想和最佳实践包括：

• 实行短时间定量、风险驱动的迭代。
• 及早开始编程。
• 对架构的核心和风险部分进行适应性的设计、实现和测试。
• 今早、频繁、实际地测试。
• 基于来自己测试、用户、开发者的反馈进行调整。
• 通过一些列讨论会，详细编写大部分用例和其他需求，每个细化迭代举行一次。

在细化阶段会开始构建哪些制品

何时指导子集并没有理解细化阶段

• 对于大部分项目，细化阶段都比”几个“月更长。
• 只有一次迭代（除极少数已于理解的问题外）。
• 在细化开始前就定义了大部分需求。
• 没有处理具有分享的元素和核心架构。
• 没有产生可执行架构；没有进行产品代码的编程。
• 认为细化阶段主要是需求或设计阶段，为构造阶段的实现进行准备。
• 试图在编程之前进行彻底和细致设计。
• 只有少量的反馈和调整；用户没有持续地参与评估和反馈。
• 没有尽早和实际的测试。
• 在编程之前推测行地结束架构设计。
• 认为细化阶段是进行概念验证编程阶段，而不是对产品化核心架构编程的阶段。

过程：计划下一个迭代

通过风险、覆盖范围和关键程度组织需求和迭代。

• 风险既包括技术复杂性，也包括其他因素。
• 覆盖范围意味着在早期迭代中至少要设计系统的所有主要部分-或许是对大量构件进行”广泛和肤浅“的实现。
• 关键程度是指客户认为具有高业务价值的功能。

这些标准用来对不同迭代中的工作划分等级。为了实现对用例或用i常见进行登记划分--早期迭代用于实现高等级的场景。此外，有些需求被标识为与特定用例无关的高阶特性，此类需求也需要划分等级。

在迭代1之前完成等级划分，大师在迭代2之前要重新划分，一次类推，因为新需求和新理解会对等级排列产生影响。

基于这一等级，我们会看到，处理销售用例中一些关键的架构上重要的场景应该在早期迭代中进行处理。每次迭代将会暗处一个隐含的或外在的启动用例，以满足其初始化需要。