RUP 生命周期
此页面描述了典型 RUP 项目生命周期的阶段和里程碑。
关系
主要描述

项目的阶段和里程碑

从管理角度,Rational Unified Process(RUP)的软件生命周期按时间分成四个顺序阶段,每个阶段以一个主要里程碑结束;每个阶段必须跨越两个主要里程碑之间的时间段。在每个阶段结束时执行一个评估,确定是否符合该阶段的目标。如果评估令人满意,则允许项目进入下一个阶段。

计划阶段

所有阶段在进度安排和工作量方面是不相同的。虽然这根据项目不同而有相当大的变化,但一个中等规模的项目的典型初始开发周期应预见到在工作量和进度安排之间的以下分发:

  先启 精化 构造 移交
工时 ~5 % 20 % 65 % 10%
进度安排 10 % 30 % 50 % 10%

可以用图形方式描述如下:

移交 构造 精化 先启 单击某个阶段以获取更多信息

该分发可以有多种。例如,生成代码和测试用例的工具可缩短构造阶段。另外,对于演进周期而言,先启和精化阶段相当短,因为基本远景和体系结构已经建立。

规划策略

在此部分中,我们将介绍与常用项目概要文件相对应的多个生命周期模式。

生命周期模式:递增

“递增式策略确定用户需要并定义系统需求,然后以一系列工作版本执行剩余开发。第一个工作版本合并计划的功能的各部分,下一个工作版本添加更多功能等,直到系统变成完整的。”[DOD94]

以下迭代是典型的:

  • 简短的“先启”迭代,建立范围和远景并定义业务案例
  • 一个“精化”迭代,在此期间定义需求并建立体系结构
  • 几个“构造”迭代,在此期间实现用例并填充体系结构
  • 几个“移交”迭代,将产品移交给用户团体

附带文本中描述的图。

此策略在以下情况下适用:

  • 问题域是熟悉的。
  • 很好地理解了风险。
  • 项目团队是有经验的。

生命周期模式:演进方式

“演进方式策略在以下方面不同于递增方式:没有完全理解用户需要,并且不能预先定义所有需求,而在每个后续工作版本中优化需求。”[DOD94]

以下迭代是典型的:

  • 简短的“先启”迭代,建立范围和远景并定义业务案例
  • 几个“精化”迭代,在此期间在每个迭代中优化需求
  • 一个“构造”迭代,在此期间实现用例并扩展体系结构
  • 几个“移交”迭代,将产品移交给用户团体

附带文本中描述的图。

此策略在以下情况下适用:

  • 问题域是新的或不熟悉的。
  • 团队是缺乏经验的。

生命周期模式:递增交付 

一些作者也已对客户逐步采用了交付递增功能[GIL88]。当在产品面市时间上存在很大压力时,这可能是必需的,尽早交付某些关键功能可产生重大业务利益。

按照分阶段迭代的方法,移交阶段在早期开始并具有大多数迭代。此策略需要非常稳定的体系结构,对于“崭新的”系统,在初始开发周期中这是很难实现的。

以下迭代是典型的:

  • 简短的“先启”迭代,建立范围和远景并定义业务案例
  • 一个“精化”迭代,在此期间以稳定的体系结构作为基线
  • 一个“构造”迭代,在此期间实现用例并填充体系结构
  • 几个“移交”迭代,将产品移交给用户团体

附带文本中描述的图。

此策略在以下情况下适用:

  • 问题域是熟悉的:

    • 体系结构和需求可在开发周期早期稳定下来
    • 问题的新鲜程度低
  • 团队是有经验的。
  • 递增功能发行版对于客户有很高价值。

生命周期模式:“重要设计”

传统的瀑布式方法可看作已退化的情况,其中在构造阶段只有一个迭代。在[DOD94]中它被称为“重要设计”。实际上,在移交阶段中很难避免附加的迭代。

以下迭代是典型的:

  • 简短的“先启”迭代,建立范围和远景并定义业务案例
  • 一个非常长的“构造”迭代,在此期间实现用例并填充体系结构
  • 几个“移交”迭代,将产品移交给用户团体

附带文本中描述的图。

此策略在以下情况下适用:

  • 将定义良好的功能的一点新增部分添加到非常稳定的产品
  • 新功能是定义良好的并很好理解
  • 团队是有经验的,无论在问题域还是现有产品方面

生命周期模式:混合策略

实际上,很少有项目严格遵循一个策略。您通常会最终使用混合策略,开始时的某个演进策略、构建时的某个递增策略和多个交付策略。分阶段迭代模型的好处在于它可使您适应混合方法,只需增加特定阶段中的迭代长度和个数:

  • 对于复杂或不熟悉的问题域,很大程度上存在着探索:增加精化阶段中的迭代数量及其长度。
  • 对于更复杂的开发问题,将设计转换成代码很复杂:增加构造阶段中的迭代数量及其长度。
  • 在一系列递增式发行版中交付软件:增加移交阶段中的迭代数量及其长度。


从一个周期转移到另一个周期

经历了四个阶段的整个过程是一个开发周期;每个经历了四个阶段的过程产生某一代软件。除非产品“死亡”;否则它将通过重复“先启、精化、构造和移交阶段”这同一顺序来演进为下一代,但此时对各阶段的强调点有所不同。后面的这些周期称为 演进周期。随着产品经过若干周期,将产生新的一代。

初始开发图

用户建议的增强、用户环境中的更改、底层技术中的更改以及对竞争的反应等都可能触发演进周期。演进周期的先启和精化阶段通常要短得多,因为先前的开发周期已确定了基本产品定义和体系结构。该规则的例外情况是发生重大的产品或体系结构重定义的演进周期。