UML和模式应用2： 迭代、进化和敏捷

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）