1.前言
本章主要介绍迭代、敏捷开发及UP(统一过程)的基本概念
2.基本术语
| Items | Note |
| 软件开发过程 | 描述了构造、部署及维护软件的方式 |
| 迭代开发 | 是一种软件开发过程的生命周期模型，依赖短快的开发步骤、反馈、改写不断明确需求和设计 |
| 统一过程（UP） | 一种迭代开发实践，是流行的构造面向对象系统的迭代开发方法，鼓励引进其它迭代方法中的有用实践 |
| 敏捷开发 | 多种软件开发项目管理方法的集合，敏捷开发要比迭代开发包含的内容宽泛 |
表 基本术语说明
软件开发过程、迭代开发、统一过程的关系：
. 迭代开发描述一种软件开发过程
. 统一过程是迭代开发的的代表性的实践
3. 迭代开发
- 迭代开发的特点
. 开发被组织成一些短期固定的小项目，称为迭代
. 每次迭代都产生经过测试、集成及可执行的局部系统
. 每次迭代都有各自的需求分析、设计、实现和测试活动
. 迭代生命周期基于对多次迭代的系统持续扩展和精化，以循环反馈和调整为核心驱动力
. 反馈和调整使得规格说明和设计不断进化
. 迭代开发是构造-反馈-调整的有序过程
. 迭代开发要求一开始只用较少的时间进行建模设计，用剩余的大部分时间完成需求分析、设计、实现和测试的迭代式开发
. 迭代开发的每次迭代是最终系统的产品子集
- 如何在迭代中处理变更
. 每次迭代选择一小组需求，并快速设计、实现和测试，这样可以快速的得到反馈，及时对系统做出调整
- 一次迭代持续时间
. 一次迭代时间建议控制在2~6周，时间太短不利于收集反馈，时间太长破坏了循环反馈和调整的核心驱动力，短时迭代为上
- 迭代时间定量
. 迭代时间定量选定好后，将依据时间定量进行集成、测试和稳定局部系统，推延时间则违约
. 如果有些需求难以达成，则将此需求推迟到将来的迭代中，而不是项目的延期
- 警惕瀑布模型
. 瀑布模型特点：编程之前详细定义所有或大部分需求，并创建出完整的设计，同时试图在开始前定义可靠的时间或计划表。瀑布模型错误的假设规格说明是稳定的和可预知的
. 杜绝瀑布模型：在迭代中出现在开发前确认大部分需求，编程前试图创建完整、详细的规格说明或UML模型和设计，说明迭代中出现了瀑布模型行为
- 反馈和改写的重要性
. 早期开发中的反馈，有助于开发人员理解规格说明，客户演示也有助于精化需求
. 测试中的反馈，有助于开发人员精化设计或模型
. 来自团队处理早期的反馈，有助于简化时间表
. 来自市场和客户的反馈，有助于重新定义下一次迭代实现的优先级
4. UP迭代开发
. UP提倡风险驱动和客户驱动相结合的迭代计划，早期的迭代目标是识别和降低最高风险，并构造客户最关心得可视化特性
. 风险驱动迭代开发早期的迭代致力于核心架构的构造、测试和稳定
5. 敏捷方法
- 敏捷方法的定义
. 敏捷方法都具备进化式精化的计划、需求和设计的短时间定量迭代，除此还倡导反映简易、轻量、沟通、自组织团队等更多敏捷性的实践和原则
. scrum敏捷方法和极限编程（XP）都是敏捷方法的一种实践，前者实践包括公共项目工作室和自组织团队，后者实践包括结对编程和测试驱动开发
- 敏捷宣言
个体和迭代，超越过程和工具；
代码，超越完整的文档
客户协助，超越合同谈判
响应变更，超越履行计划
- 敏捷原则（以持续性交付有价值的软件为最高纲领）
1. 优先级最高的是，通过早期和持续性的交付有价值的软件来满足客户；
2. 欢迎需求变更；
3. 以两周或两月为周期，频繁的交付可运行的软件，首推较短的时间定量；
4. 在整个项目开发过程中，每天开发人员与业务人员都要合作；
5. 由个体推动项目的建设，为个体提供帮助；
6. 面对面交谈来传递信息；
7. 衡量进展的最重要尺度是可运行的软件；
8. 敏捷过程提倡可持续性的开发，（因此以框架设计为优先？）；
9. 发起人、开发者和用户要步调一致；
10. 不断关注技术上优越的设计会提高敏捷性；
11. 简洁最重要，尽量减少工作量；
12. 最佳的架构、需求和设计来自于自组织的团队；
13. 团队要定期反省如何使工作更有效率，然后响应的调整行为
- 敏捷建模
. 建模的主要目的是为了理解问题，为良好的OO设计快速探索可选方法和途径
. 敏捷方法采用如上思想的建模，称为敏捷建模
. 敏捷建模的有用实践：
（1）敏捷方法都包含重要的建模期；
（2）建模和模型的目的是为了理解和沟通
（3）只对不常见、困难的一小部分问题建模和应用UML
（4）尽量使用简单的工具，如使用UML草图来建模，可以快速理解内部协作，为参与者提出问题和达成一致提供环境；
（5）结对建模，发现、理解和共享大家的理解
（6）并行的创建模型
（7）使用简单常用的UML元素
（8）模型图只是设计的一次探索，而非最终的设计
（9）开发者为自己进行OO设计建模
6. 敏捷UP
- 敏捷UP的定义和主要应用原则
. UP采纳和应用可适应性和轻量级的精神称为敏捷UP
. 敏捷UP的应用原则：
（1）推荐使用UP活动和制品的简集，选择关键的UP活动和制品；
（2）UP是迭代和不断进化的
（3）敏捷建模使用UML
（4）制定整个周期包括哪些阶段，并估计结束日期，并对其中一个迭代制定详细计划
- 敏捷UP应用的其它关键原则
早期迭代中解决高风险和高价值的问题
不断让用户参与评估和反馈需求
早期迭代中建立内聚的核心架构？
经常测试
适当的地方使用用例
进行一些可视化建模
认真管理需求
实行变更请求和配置管理
7. UP的阶段与科目
7.1 UP的阶段
| UP阶段 | 主要工作 |
| 初始 |
大体上的构想，业务案例，范围，和模糊评估。定义系统的业务模型，确定系统的范围； 此阶段不是需求阶段，而是研究可行性问题 |
| 细化 |
已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数需求和范围以及进行更为实际的评估； 此阶段迭代的实现核心架构并解决高风险问题 |
| 构造 | 对遗留下的风险较低和比较简单的元素进行迭代实现，准备部署 |
| 移交 | 进行系统部署，系统测试，最终移交给用户 |
表 UP阶段及主要工作
图 UP中面向进度表的术语
从上图可以看出：
（1）迭代主要发生在细化阶段、构造阶段和移交阶段；
（2）细化阶段主要完成核心架构和高风险任务的迭代，同时也进行少量的实现，相对构造阶段需求和设计的工作占多，实现占少；
（3）构造阶段主要完成细化阶段迭代的决策实现、测试与发布，同时完成遗留的低风险任务的迭代，相对细化阶段实现的工作占多，需求和设计的工作占少；
（4）移交阶段在每次构造迭代完成后移交给客户使用
7.2 UP的科目
| UP科目 | 制品 | 说明 |
| 业务建模 | 领域模型 | 应用领域中重要概念的可视化 |
| 需求 | 用例模型和规格说明 | 用例模型捕获功能需求和非功能需求 |
| 设计 | 设计模型 | 对软件对象进行设计 |
表 UP科目的制品及说明
图 多次迭代中UP科目的工作量分布
全部的UP科目如上图竖列显示，其中业务建模、需求和设计是本书重点关注的内容。
UP科目和UP阶段有如下的关系：
（1）一次迭代的工作会遍历大部分或全部的科目；
（2）这些科目的工作量会随着迭代而发生变化，早期迭代倾向于需求和设计，后期迭代倾向于实现、测试和部署
（3）细化阶段的迭代倾向于相对高级的需求和设计工作；构造阶段的迭代倾向于实现
7.3 UP科目与制品的关联
图 UP科目与制品及制品间的关系
8. 总结
通过如上的学习，总结如下的表：
| UP阶段 | 主要工作 | 是否参与迭代 |
| 初始阶段 | 完成可行性论证 | 否 |
| 细化阶段 | 注重架构和高风险问题的需求和设计，以及少量实现 | 是 |
| 构造阶段 | 细化阶段的大部分实现，以及剩余低风险问题的需求分析和实现 | 是 |
| 移交阶段 | 将最终软件产品的子集交付给客户试用 | 是 |
表 UP阶段的主要工作
9. 参考文档
[1] 统一过程模型（UP）