第2章 迭代、进化和敏捷

本文为《UML和模式应用(原书第3版)》读书笔记

---

UP

软件开发过程描述了构造、部署以及维护软件的方式。
统一过程（Unified Process）是一种流行的构造面向对象系统的软件开发过程。
本章介绍UP的原因：
1.UP是迭代过程。迭代开发对OOA/D的最佳实践具有影响。
2.UP实践提供了如何实施OOA/D的示范结构。
3.UP具有灵活性，可以应用于轻量级和敏捷方法。

迭代开发

• 迭代开发（iterative development）是UP和大多数其他现代方法中的关键实践。在这种方法中，开发被组织成一系列固定的短期小项目，称为迭代（iteration）；每次迭代都产生经过测试、集成并可执行的局部系统；每次迭代都具有各自的需求分析、设计、实现和测试活动。
• 迭代生命周期基于对经过多次迭代的系统进行持续扩展和精化，并以循环反馈和调整未核心驱动力，使之最终成为适当的系统，随着一次又一次迭代的递进，系统增量式地发展完善，因此这一方法也被称为迭代和增量式开发。
• 因为反馈和调整使文档规格说明和设计不断进化，所以这种方法也称为迭代和进化式开发

在迭代项目中处理变更

• 一方面认同和稳定一组需求，另一方面接受需求不断变更的事实。
• 在早期迭代中，对需求和设计的选择对于最终期望来说可能不准确，但是快速地实施一小步的方式可以得到可能来自于用户、开发人员和测试的快速反馈，这种早期反馈具有极高的价值，可以从这些反馈中挖掘出至关重要和实际的观点，并修改和调整对需求或设计的理解。
• 最好及早解决和验证具有风险的、关键的设计决策，为迭代开发提供完成这项工作的机制。
• 因此工作是通过一系列有序的构造-反馈-调整循环向前进展的，因此变更是正常情况。

迭代开发的优点

• 减少项目失败可能性，提高生产率，降低缺陷率。
• 在早期缓解高风险。
• 早期可见的进展。
• 早期反馈、用户参与和调整，会产生更接近真实需求的精化系统。
• 可控复杂性；团队不会被分析瘫痪或长期且复杂的步骤所淹没。
• 一次迭代中的经验可以被系统用于改进开发过程本身，并如此反复进行下去。

一次迭代的持续时间和时间定量

• 2~6周之间，时间过长会破坏迭代开发的核心动机并增加项目风险。太短的迭代时间不足以获得有意义的产出和反馈。
• 迭代的一个关键思想是时间定量，假如分配好任务后看起来难以满足期限要求，那么应该去除一些任务和需求而不是推迟完成日期。

风险驱动和客户驱动的迭代计划

早期的迭代计划目标要能够识别和降低最高风险，并且能构造客户最关心的可视化特性。

瀑布生命周期

• 在瀑布（或顺序）生命周期过程中，试图在编程之前详细定义所有或大部分需求，而且通常于变成之前创建出完整的设计，定义“可靠的”计划或时间表，但常常事与愿违。

  如果出现开发前确认大多数需求，编程前试图创建完整、详细的规格说明或UML模型和设计，说明瀑布思维已经在无情地折磨着这个项目了

• 现在的研究表明，瀑布方法对于大多数软件项目是拙劣的实践，平均而言，瀑布方法需求中45%的特性从未被使用，其早期时间表和估计与最终实际情况可相差400%。

避免瀑布

“在开始编程前编写完所有的用例“或者“让我们在开始编程前用UM完成更多详细的OO模型”，这样的想法是不健康的瀑布思维。

反馈和改写的必要性

瀑布模型没有认识到变更对于软件项目来说是永恒的，是必然存在的事物，没有正视和包容它。在大多数软件项目中，反馈和调整是成功的关键要素。

敏捷宣言

个体和迭代，超越过程和工具。
工作的软件，超越完整的文档。
客户协作，超载合同谈判。
响应变更，超载履行计划。

敏捷开发

• 通常应用时间定量的迭代和进化式开发、使用自适应计划、提倡增量交付并包含其他提倡敏捷性（快速和灵活的相应变更）的价值和时间。
• 敏捷原则：
  
  • 优通过早期和持续交付有价值的软件来满足客户。
  • 欢迎变更需求，敏捷过程为客户的竞争优势而控制变更。
  • 以两周到两月为周期，频繁地交付可运行的软件，首推最短的时间定量。
  • 每一天开发人员都要和业务人员合作。
  • 由个体推动项目的建设，为个体提供所需的环境、支持和信任。
  • 团队间最为有效和高效的方法是面对面交谈。
  • 衡量进展的重要尺度是可运行的软件。
  • 敏捷过程提倡可持续的开发。
  • 发起人、开发者和用户应该步调一致。
  • 不断地关注技术上优越的设计会提供敏捷性。
  • 简洁是最重要的，简洁就是尽量减少工作量的艺术。
  • 最佳的架构、需求和设计来自于自组织的团队。
  • 团队要定期反省如何使工作更有效，然后相应地调整行为。

敏捷建模

• 建模的真正行为能够并且是应该能够对理解问题或解决方案空间提供更好的方式。所以“实行UML”，不是创建大量详细的UML图并递交给编程者，而是为良好的OO设计快速探索可选的方案和途径。
• 采用敏捷方法并不意味着不进行任何建模。
• 建模和模型的目的主要用于理解和沟通。
• 建模时只需对设计空间中不常见、困难和几首的一小部分问题建模和应用UML，对于简单的设计问题可以推延到编程阶段。
• 尽可能使用简单的工具。
• 不要单独建模，尽量使每个人参与其中。

敏捷UP

采纳和应用可适应性和轻量级实践的UP成为敏捷UP。

• 不断地让用户参与评估、反馈和需求。
• 在早期迭代中建立内聚的核心架构。
• 不断地难质量；提早、经常和实际地测试。
• 在适当的地方使用用例。
• 进行一些可视化建模。
• 认真管理需求。
• 实行变更请求和配置管理。

UP的阶段

• 初始：大体上的构想、业务案例、范围和模糊评估。（立项阶段）
• 细化：已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数需求和范围以及进行更为实际的评估。（功能需求）
• 构造：对遗留下来的风险较低和比较简单的元素进行迭代时限，准备部署。（开发实现）
• 移交：进行beta测试和部署。（交付使用）

UP科目

UP描述了科目中的工作活动。科目也称为流程。UP科目也就是UP流程。
- 业务建模：领域模型制品，使应用领域中的重要概念的可视化。
- 需求：用以不糊功能需求和肺功能需求的用例模型及其补充性的规格说明制品。
- 设计：设计模型制品，用于对软件对象进行设计