UML和模式应用5：细化阶段(1)--第1次迭代

1.前言

从本文开始进入细化阶段，讨论迭代技术的基础，本次讨论将着重讨论第一次迭代，以POS机为例。

2. 第一次迭代处理的需求（以NextGen POS项目处理销售用例）

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

3. 迭代过程，并非一次就实现所有需求

• 迭代生命周期方法的关键理解：对需求子集开始具有产品品质的编程和测试

4. 多个迭代里对同一用例进行增量式开发

图 用例的实现可能在多个迭代中展开

• 在多次迭代内对同一用例的各种场景进行开发，渐进的扩展系统直到最终完成此用例的所有功能。

5. 初始阶段和细化阶段的过程

5.1 初始阶段

初始阶段的特点再说明：

• 初始阶段持续较短时间，只经过轻量级的调查
• 所创建的制品是简明和不完整的
• 初始阶段是迈向细化阶段的一小步
• 初始阶段决定基本的可行性、风险和范围，是否值得进行更深入的调查进行决策
• 并非所有适合于初始阶段的活动都涵盖在其中

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

• 简短的需求讨论会
• 大多数参与者、目标和用例名称
• 大多数以摘要形式编写的用例。以详述形式编写10%左右的用例
• 确定大多数具有影响和风险的质量需求
• 编写设想和补充性规格说明的第一个版本
• 风险列表：如工作量
• 技术上的验证检验（如javascript是否可以在触摸屏上工作？）
• 面向用户界面的原型，用于确定对功能需求的设想
• 对购买/构建/复用构件的建议，在细化阶段进行精化（如建议购买税金计算器程序包）
• 对候选的高层架构和构建给出建议（这里只是概要向的推测，以作为细化阶段的起点）
• 第一次迭代计划
• 候选工具列表

5.2 细化阶段

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

• 对核心、有风险的软件架构进行编程和测试；
• 发现并稳定需求的主体部分
• 澄清大多数需求和规避主要风险
• 细化阶段通常由两个或多个阶段组成，建议迭代时间定量，结束日期固定
• 该阶段产生的代码和设计具有产品品质的最终系统的一部分

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

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

细化阶段可能构建的制品：

图 细化阶段的制品举例

上图并未包含初始阶段就开始构建的制品，而只是细化阶段开始的制品，这些制品不是在一次迭代完成，而是会跨越若干次迭代进行精化。

6. 计划下一个迭代

通过风险、覆盖范围和关键程度组织需求和迭代，划分工作等级，如POS示例中，处理销售被划分成高等级

• 风险：技术复杂性，工作量和其它不确定性
• 覆盖范围：早期迭代要涉及系统所有主要部分（肤浅和广泛）
• 关键程度：客户认为具有高业务价值