UML精粹2

迭代和瀑布过程

两者的本质区别是，你如何将一个项目分解为更小块。

• 瀑布风格基于活动来分解项目。为了构建软件，你不得不做某些活动：需求分析、设计、编码和测试。为期一年的项目可能有2个月的分析阶段，然后是4个月的设计阶段，接着是3个月的编码阶段，再接着是3个月的测试阶段。
• 迭代风格根据功能子集来分解项目。你可能会把一年分解为3个月的迭代。第一个迭代，处理1/4的需求，并对这1/4做完整的软件生命周期：分析、设计、编码和测试。在第一个迭代结束时，你拥有了一个做1/4所需功能的系统。然后，你再做第二个迭代，这样在6个月结束时，你拥有了一个完成一半功能的系统。

在进行瀑布开发时，每个阶段之间通常有正式的交接，但也经常有回溯。在编码期间，会有一些情况导致你需要回头看看分析和设计。当然，在开始编码时，你不应该假设所有设计完成了，后续阶段回头看看分析和设计决策时不可避免的。然而，这种回溯是一种异常，应该尽可能减少。

进行迭代开发时，在真正的迭代开发之前，通常会有一些探索活动。至少，这会让我们得到需求的高级别视图：足于让我们把需求打碎，放进接下来要进行的迭代中。每个迭代应该产出准备产品化的集成软件，但是通常很难严格达到这个地步，我们经常会听到一个项目有多个发布release，每一个发布分解为若干个迭代iteration。迭代有许多的名字：增量、螺旋、演进等。

你也可以使用杂化的方法。阶段交付staged delivery生命周期，先以瀑布风格完成分析和高级设计，然后把编码和测试放到迭代中。这样一个项目可能有4个月的分析和设计，紧跟着4个两个月的迭代来构建系统。

迭代的常见技能是使用时间盒time boxing。时间盒前调每个迭代有固定长度的时间。如果不能在规定时间内完成预计的功能，可以推迟一些功能到下一个迭代，而不能延迟迭代结束时间。一般我们可以发布一个功能少一点的软件，但不可以推迟发布时间，时间盒可以帮助控制时间。

迭代中用到的技术：自动化回归测试automatic regression test，重构refactoring，持续集成continuous integration。

预测性和自适应计划

预测性方法指望在项目早期做点工作，以便更好地理解后面不得不做的事情，这样，项目可以进行相对准确的估算。然而，事实是需求经常变动，计划赶不上变化。自适应计划认为预测性看起来就是错觉，要面对现实，把处理改变看成软件项目的常态。这样，改变得到控制，项目交付所能交付的最好的软件；虽然项目不是可预测的，但项目是可控的。自适应方法绝对需要迭代方法，预测性方法两种方式都行，不过，采用瀑布和阶段交付更容易看到项目如何进行。

敏捷过程

敏捷过程的例子有：极限编程XP，Scrum，特性驱动开发FDD，Crystal，动态系统开发方法DSDM。敏捷过程本性是非常自适应的，也非常注重以人为本。敏捷方法假设项目成功的最重要因素是项目中人的素质，以及他们一起工作时人际关系有多好，使用什么过程和工具绝对是次要因素。敏捷方法倾向于使用短的、基于时间盒的迭代，和更少的仪式ceremony（注重仪式的过程项目期间有许多文档和控制点）。敏捷过程经常被刻画为轻量的，但是要注意缺少仪式是自适应和以人文本的结果，而不是基本性质。

Rational统一过程（RUP）

RUP实际上是一个过程框架，提供了一个用来谈了过程的词汇表和松散结构。当你使用RUP时，第一件需要做的事情是选择一个开发案例（development case）：你打算在项目中使用的过程。RUP本质上是迭代的过程。所有RUP项目遵循4个阶段：

1. 初始inception阶段。对项目进行估算，决定是否投入足够的资金来做细化阶段。
2. 细化elaboration阶段，识别项目的首要用例，并迭代构建软件，以便使系统的架构成型。细化阶段的最后，你应该对需求有好的体会，并且有大致可以工作的系统来扮演开发的种子。特别是，你应该发现并解决了项目的主要风险。
3. 构造construction阶段。继续构建软件，开发足够发布的功能。
4. 移交transition阶段。包含后期阶段的活动，这些活动不用迭代去做，可能包括部署到数据中心、用户培训等。

在阶段之间，有相当多的模糊地带，特别是细化阶段和构造阶段之间。对某些人来说，到构造阶段说明可以使用预测性计划模式，对其他人来说，它只说明你对需求有了全面的理解，并且有了一个项目使用的架构。

为项目裁剪过程

随着项目的进行，你可能需要裁剪项目过程，迭代支持频繁的过程改进。在迭代的末尾举行一次迭代回顾（iteration retrospective），团队聚在一起讨论：做得好的要保存，做得不好的要改进。在项目末期的时候或有主要发布时，考虑一次更正式的、持续两三天的项目回顾project retrospective。

为过程裁剪UML

考虑在项目过程的各个阶段使用什么类型的UML图。

1. 需求分析。可以使用：用例，类图，活动图，状态图。
2. 设计。类图，序列图，包图，状态图，部署图。