百花齐放的统一软件过程

  • Shane Hastie
  • 金毅

2010 年 3 月 25 日

话题:敏捷文化 & 方法

20 世纪 90 年代,Rational 统一软件过程(RUP)作为一个集结了软件工程最佳实践的框架,被逐步建立起来。其中的一些理念,如迭代、简单、关注价值和定期反馈,都被认为对软件工程的成功至关重要。很多人都借鉴统一过程,在不同的项目领域构建了方法论。

统一软件过程背景介绍

设计 Rational 统一软件过程(RUP®)的初衷是想为软件工程提供一个框架。到 1997 年,Rational 软件公司宣称已经整合了 7 类最佳实践:

  1. 迭代式开发,并以风险作为迭代的主要驱动因素
  2. 管理需求
  3. 运用基于组件的构架
  4. 软件可视化建模
  5. 持续质量验证
  6. 变更控制
  7. 定制化

Rational 构建的框架包含相关过程和实践,可以运用在商业产品开发中,它主要包括 3 部分:

  • 一个指导开发的可裁剪的过程
  • 一些能使这些过程应用自动化的工具
  • 一些能加快实施过程和工具的服务

RUP 基于迭代理念,定义了一套能够贯穿项目生命周期的核心及辅助准则。下面的图表(参考驼峰图)显示了核心准则在四个阶段中可能的焦点和强度。

Image source 图片来源: http://en.wikipedia.org/wiki/File:Development-iterative.gif

除了核心准则,RUP®也定义了一些关于配置及变更管理、项目管理和环境支持的辅助原则。有关 RUP®的更多内容请参考这里

2003 年,IBM收购了 Rational 软件公司,并继续对 RUP®进行商业开发和包装。

2002 年,RUP 框架最初的设计师Philippe Kruchten写了一篇名为“敏捷与 RUP”的文章。文中他提到:

对于软件开发组织来说,在面临环境变化和环境施加的需求时,敏捷能够快速且恰当地应对、调整,并做出反应。敏捷过程就是对这一适应性水平的欣然拥抱和支持。因此,这绝不单单是过程规模或交付速度的问题;最主要的是灵活性。在本文中,我将阐述 Rational 统一软件过程(RUP®)作为一个过程框架如何带来灵活性。

他指出:除了那 7 个核心的实践,RUP®还基于一系列核心原则,包括

  • 只开发需要的东西。
  • 关注有价值的结果,而不是获得结果的过程。
  • 文档最小化。
  • 足够灵活。
  • 从错误中吸取教训。
  • 定期做风险回顾。
  • 为进度设定客观和可度量的条件。
  • 自动化需要大量人力投入且单调易错的工作。
  • 使用小而有自主权的团队。
  • 有计划。

他的结论是,RUP®提供的框架能够很好地支持敏捷技术及方法论。

离开 IBM 后,Kruchten 继而成为了不列颠哥伦比亚大学(University of British Columbia)电子和计算机工程系软件工程专业的教授。

核心统一过程

Rational 软件公司的创始人之一,Ivar Jacobson,提出了核心统一过程(ESSUP)这一概念:

核心统一过程(EssUP) 是实践的集合,这些实践组成了完整软件开发周期的核心知识体系。这个以实践为中心的方法学包含了现有的最佳实践,并以此为基石。EssUP 中的实践整合了统一软件过程、敏捷和过程成熟度阵营的很多成功原则,从而充分汲取了它们各自所长:结构、敏捷和过程改进。

ESSUP 以核心实践集的形式发布,免费下载的文档中描述了关于每个实践的交付物、需要做的事情和关键技能,并且附有相应的指南。

开放式统一过程——一个精益的统一过程

OpenUP同样定义了成功发布软件所需要的过程、实践、角色、工作产品和任务。OpenUp 要部署在 Eclipse 过程框架下。

OpenUP 是一种精益的统一过程,它在结构化的生命周期中使用迭代和增量式的方法。OpenUP 信奉务实主义和敏捷的思想体系,关注软件开发的协作性。它是一个与工具无关、不拘小节的过程,能够扩展运用到很多种类的项目中去。

Bjorn Gustafsson 在文章Methods & Tools 中这么描述 OpenUP:

EPF 是一个始于 2006 年的开源新方案,主要内容来自 IBM Rational 中部分 RUP 的内容和技术。在初期,项目就已经有 20 多家公司积极参与,并且在 2007 年 9 月第一次发布。尽管只是个 Eclipse 项目,EPF 却可以为任何开发类型来创建过程描述,包括在 Eclipse 上的 J2EE 和使用微软 Visual Studio 的.NET。

在文章中,他介绍了 EPF 的背景以及 OpenUP 如何实施的。他断言:

新的 OpenUP 过程综合了来自 RUP 和敏捷方法论的最佳实践,形成了相较于二者更轻便、敏捷的选择。有 RUP 做根基,它能提供迭代式、递增的、用例驱动、风险驱动和以架构为中心的过程,同时也支持敏捷项目的工作习惯。对很多项目来说,OpenUP 过程提供的实践可以投入使用,但它依然为引入第三方和私有的实践提供了扩展基础,可以应用 EPF Composer 工具来为每个项目做裁剪,以得到最适合的过程。

企业统一过程

RUP 的另一个衍生品是 Scott Ambler 的企业统一过程

企业统一过程(EUP)在 RUP 的基础上扩展了两个新的阶段:产品阶段和衰退阶段,这样就包括了软件项目开始之前和上线之后整个过程。EUP 的目的是使项目能够在更正式的环境中发布,这就要求监管和支持过程定义得更完备,且必须坚决执行。

EUP 的官网是这么介绍的:

尽管RUP定义了软件开发生命周期,EUP 则将它进行了扩展以覆盖整个信息技术(IT)的生命周期。扩展包括两个新的阶段,产品阶段衰退阶段,还有一些新的准则:运营和支持以及 7 个企业准则(企业商业建模资产组合管理企业架构战略重用人力管理企业行政软件过程改进)。

敏捷统一过程

在另一个极端,Ambler 也定义了敏捷统一过程,关注的是轻便的方法和一套能够用敏捷原则和价值观驱动的、最小化的实践。敏捷统一过程的网站提到,AgileUP:

是一个Rational 统一软件过程(RUP)的简化版。它描述了一个简单易懂的方法,该方法通过使用敏捷技术和概念来开发商业程序软件,但它依然忠于 RUP。我努力让 AgileUP 在方法和描述上尽量简单。那些描述单刀直入,如果你需要更详细的内容,网上都有链接。方法则致力于敏捷技术,包括测试驱动开发(TDD)敏捷建模驱动开发(AMDD)敏捷变更管理以及数据库重构,这些都可以改进生产率。

在网站上,他阐释了 RUP 准则和 AgileUP 准则的不同之处。

AgileUP 的整个产品都是免费提供下载的,下载下来的 ZIP 会安装整套 HTML 页面,它们描述了阶段、准则、里程碑、角色和交付物,也同样提供了技术实践指南。


以上就是一些统一软件过程的变形和衍生产物。

你在用它们中的某个吗?你的感受如何呢?它们是怎样融入到敏捷世界当中的呢?

查看英文原文:The Various Flavors of Unified Process

敏捷文化 & 方法