概念: 迭代
主题
传统上,对项目进行组织来顺序通过每个规程(每个规程有且仅有一次)。这会导致瀑布方式生命周期:

在实施后期,当首次建立产品并开始测试时,这通常会导致集成“堆积”。一直隐藏于整个分析、设计和实施过程中的问题浮现出来,然后项目就逐渐停下来,因为冗长的错误修正周期开始了。
更灵活(并更少风险)的进展方法是几次通过各种开发规程,更好地理解需求,设计健壮的体系结构,发展开发组织并最终交付逐步完整的一系列实施。这被称为迭代方式生命周期。
将每一次通过进程规程序列称为迭代。

因此,从开发的角度来看,软件生命周期是连续的迭代,通过迭代递增地开发软件。每个迭代都以得出可执行产品的发行版为结束。此产品可以是完整远景的子集,但从某个设计或用户角度来说是有用的。每个发行版带有支持工件:发行版描述、用户文档、计划等,以及更新的系统模型。
此迭代方法的主要结果是早前描述的工件集合,随时间的推移而发展和完善(如下图所示)。

信息集随开发阶段演进。
迭代包含开发活动,这些活动产生产品发行版 - 一个稳定、可执行的产品版本,包括使用此发行版必需的所有其它外围元素。因此在某种意义上,开发迭代是至少通过以下所有规程的完整过程:需求、分析与设计、实施和测试。它本身很像一个小型的瀑布式项目。请注意,在计划每个迭代时建立评估条件。发行版将计划可论证的功能。迭代的持续时间将随项目规模和性质的不同而不同,但可能每个迭代中都将构造多个工作版本,如集成构建计划中对迭代所指定的。这是 Rational Unified Process(RUP)中建议的持续集成方法的结果:当单元测试的组件可用时,集成它们,然后产生工作版本并用于集成测试。这样,集成软件的功能随迭代发展而向着计划迭代时设置的目标发展。您可能会争辩说每个工作版本本身就表示一个小型迭代,但不同之处在于所要求的计划和所执行评估的正式程度。每天构造工作版本在某些项目中可能是适合且方便的,但它们不能代表 RUP 定义的迭代 - 除了可能有极小的一个人的项目。即使对于小型的多人项目(例如,五个人建立 10000 行代码),也很难在少于一周的时间内实现迭代。
发行版
发行版可以是内部的,也可以是外部的。内部发行版仅由开发组织使用,作为里程碑的一部分,或者用于向用户或客户进行演示。外部发行版(或交付产品)则要交付给最终用户。发行版不必是一个完整的产品,而可以只是全过程的一个阶段性成果,它的有用性只是从工程角度来衡量的。发行版充当强制的功能,它迫使开发团队定期结束任务,从而避免“完成了 90%,还剩下 90%”这种情形的出现。
迭代和发行版可随时间的推移而更好利用团队中的各种专业人员:设计人员、测试人员、编写人员等。定期发行版可使您分解集成和测试问题并将这些问题分散到各开发周期中。这些问题通常会破坏大型项目,因为所有问题都是在单个大规模集成步骤中同时发现的,并且发生在周期快结束时,这时一个问题就会终止整个团队。
在每个迭代中更新工件。据说这有点像“不断发展的”软件。工件不是以流水线的形式一个接一个开发的,它们在整个周期内演进(尽管速度不同)。
次要里程碑
每个迭代以次要里程碑为结束,在此相对于此特定迭代的目标成功条件来评估迭代的结果。

阶段内的每个迭代产生系统的可执行发行版。
RUP 中的每个阶段可进一步分解成迭代。迭代是完整的开发循环,生成的是可执行产品的发行版(内部或外部),这是开发中的最终产品的一部分,会通过一次次的迭代逐渐发展为最终系统。
迭代模式:递增方式生命周期 
“递增式策略确定用户需要并定义系统需求,然后以一系列工作版本执行剩余开发。第一个工作版本合并计划的功能的各部分,下一个工作版本添加更多功能等,直到系统变成完整的。”[DOD94]
以下迭代是典型的:
- 简短的“先启”迭代,建立范围和远景并定义业务用例
- 一个“精化”迭代,在此期间定义需求并建立体系结构
- 几个“构造”迭代,在此期间实现用例并填充体系结构
- 几个“移交”迭代,将产品移交给用户团体

此策略在以下情况下适用:
- 问题领域是熟悉的。
- 很好地理解了风险。
- 项目团队是有经验的。
迭代模式:演进方式生命周期 
“演进方式策略在以下方面不同于递增方式:没有完全理解用户需要,并且不能预先定义所有需求,在每个后续工作版本中优化需求。”[DOD94]
以下迭代是典型的:
- 简短的“先启”迭代,建立范围和远景并定义业务用例
- 几个“精化”迭代,在此期间在每个迭代中优化需求
- 一个“构造”迭代,在此期间实现用例并扩展体系结构
- 几个“移交”迭代,将产品移交给用户团体

此策略在以下情况下适用:
迭代模式:递增交付生命周期 
一些作者也已对客户逐步采用了交付递增功能[GIL88]。
当在产品面市时间上存在很大压力时,这可能是必需的,尽早交付某些关键功能可产生重大业务利益。
按照分阶段迭代的方法,移交阶段在早期开始并具有大多数迭代。此策略需要非常稳定的体系结构,对于“崭新的”系统,在初始开发周期中这是很难实现的。
以下迭代是典型的:
- 简短的“先启”迭代,建立范围和远景并定义业务用例
- 一个“精化”迭代,在此期间以稳定的体系结构作为基线
- 一个“构造”迭代,在此期间实现用例并填充体系结构
- 几个“移交”迭代,将产品移交给用户团体

此策略在以下情况下适用:
- 问题领域是熟悉的:
- 体系结构和需求可在开发周期早期稳定下来
- 问题的新鲜程度低
- 团队是有经验的。
- 递增功能发行版对于客户有很高价值。
传统的瀑布式方法可看作已退化的情况,其中在构造阶段只有一个迭代。在[DOD94]中它被称为“重要设计”。实际上,在移交阶段中很难避免附加的迭代。
以下迭代是典型的:
- 简短的“先启”迭代,建立范围和远景并定义业务用例
- 一个非常长的“构造”迭代,在此期间实现用例并填充体系结构
- 几个“移交”迭代,将产品移交给用户团体

此策略在以下情况下适用:
- 将定义良好的功能的一点新增部分添加到非常稳定的产品
- 新功能是定义良好的并很好理解
- 团队是有经验的,无论在问题领域还是现有产品方面
实际上,很少有项目严格遵循一个策略。您通常会最终使用混合的策略,开始时的某个演进策略、构建时的某个递增策略和多个交付策略。分阶段迭代模型的好处在于它可使您适应混合方法,只需增加特定阶段中的迭代长度和个数:
- 对于复杂或不熟悉的问题领域,很大程度上存在着探索:增加精化阶段中的迭代数量及其长度。
- 对于更复杂的开发问题,将设计转换成代码很复杂:增加构造阶段中的迭代数量及其长度。
- 在一系列递增式发行版中交付软件:增加移交阶段中的迭代数量及其长度。
|