Back to Software Engineering

Unified Process

统一软件开发过程(Unified Software Development Process)或统一过程(Unified Process)是一个受欢迎的迭代和增量的软件开发过程框架,它包括了一系列预定义的交付物和步骤,用来帮助项目团队构建、规划和控制开发过程。最有名且广泛记载的一个统一过程是IBM Rational统一过程(RUP );另外还有OpenUP和 Agile Unified Process。

1. 过程概述

统一过程不仅是一个过程,而是一个可扩展的框架,可以根据组织或项目特定进行订制。以上说法同样适用于Rational统一过程。其结果往往是很难说该方法的细化是否来源于UP或来自RUP ,因为这两个名称往往可以互换使用。UP和RUP基本就是一回事,使用统一过程(UP)主要被用来避免潜在的侵权问题,因为Rational统一过程包括简写的RUP都是IBM的商标。

第一本书描述统一过程的书出版于1999年,书名是《统一软件开发过程(The Unified Software Development Process)》( ISBN 0-201-57169-2 )作者是Ivar Jacobson, Grady Booch 和 James Rumbaugh。从那时起,非Rational的作者出书写文章就都用统一过程了;而和Rationa有关的作者更青睐使用Rational统一过程。

2012年,纪律敏捷交付框架(Disciplined Agile Delivery Framework)发布,这是一个混合框架,采用和扩展了Unified Process、 ScrumXP和其他软件过程。

2. Unified Process特征

统一过程软件开发生命周期是一个二维的软件开发模型:

UP_disciplines_420x280.png

概况的说,UP具备以下主要特征:

2.1. 迭代与增量

统一过程是一个迭代和增量的开发过程。细化、构建和交付阶段被划分成一系列时间明确的迭代(对大型项目来说,初始阶段也可以分成多个迭代 。)每次迭代产生一个增量,发布内容包含新增功能或与以前的版本的改进功能。

大多数迭代的工作内容都包含大多数规范中的活动(如需求、设计、实现、测试),但相对开销和重点在不同项目过程中是不同的。

2.2. 用例驱动

在统一过程中,用例是用来捕获功能要求并用来确定迭代的内容。每次迭代都需要一组用例或场景,用来支持实现、测试和部署。

2.3. 以架构为中心(Architecture Centric)

统一过程坚持项目团队要以架构为中心塑造系统。由于没有单个模型能够覆盖系统全貌,统一过程支持多种体系结构模型和视图。

该方法最重要的成果就是在细化阶段创建的可执行构架基线。这部分系统实现为验证架构和后续发展奠定了基础。

2.4. 聚焦风险(Risk Focused)

统一过程要求项目团队在项目生命周期的早期就找到最关键的风险。每次迭代,尤其是在细化阶段,必须确保最大的风险是首先选择处理的。

3. UP模型概述

统一过程软件开发生命周期是一个二维的软件开发模型:

UP_disciplines_420x280.png

3.1. 基本元素

3.2. 项目生命周期

UP中的软件生命周期在时间上被分解为四个顺序的阶段,分别是:

3.2.1. 初始阶段(Inception)

初始阶段是项目中最小的阶段,在这个阶段需要开发系统愿景(vision)、确定业务用例、定义范围,并粗略估算项目成本、初步制定项目日程。理想情况下应该是相当短的。如果过度制定前期规范造成初始阶段很长,那么这是违背统一过程精神的。

以下是初始阶段的典型目标:

确定好生命周期目标里程碑,标志着初始阶段的结束。

3.2.2. 细化阶段(Elaboration)

在细化阶段,项目团队期望能够获取到绝大部分系统需求(System Requirements)。然而,细化阶段的主要目标是确定风险因素、建立并验证系统架构。在这个阶段进行的通用流程包括建立用例图、概念图(只有基本概述的类图)和包图(架构图) 。

通过实现一个可执行的架构基线来验证系统架构。这个基线架构是对系统核心和最关键部分组件的部分实现。 实现过程是通过一系列小时间段迭代完成的(small, time boxed iterations)。在细化阶段结束时,系统架构必须具备稳定可执行构架基线,用来证明该架构确实支持关键系统功能,并在性能、可扩展性和成本方面具有合理的表现。

细化阶段最后的交付是构建阶段的计划(包括成本和进度估算) 。此时的计划应该是准确且可信的,因为它应该是基于细化阶段的经验,并且显著风险因素也已经得到了解决。

因此,细化阶段的目标是分析问题领域,建立健全的体系结构基础,编制项目计划,规避项目中最高风险的元素。为了达到该目的,必须在理解整个系统的基础上,对体系结构作出决策,包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境,包括创建开发案例,创建模板、准则并准备工具。

3.2.3. 构造阶段(Construction)

构造实现是项目过程中最大的阶段。在这一阶段,系统在细化阶段的基础上构建余下的部分。这些系统功能也是通过一系列小时间段迭代完成的(small, time boxed iterations)。每次迭代都产出软件的可执行版本。按照惯例,在构建阶段要编写纯文字的用例规约,每个规约都是一个新迭代的开始。

在构建阶段,所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详细测试。从某种意义上说,构建阶段是一个制造过程,其重点放在管理资源及控制运作以优化成本、进度和质量。

3.2.4. 交付阶段(Transition)

项目生命周期的最后一个阶段是交付。在这个阶段,系统部署到目标用户。从初始版本(或n个初始版本)收到的反馈意见,可能会导致交付阶段出现多个迭代。交付阶段还包括系统集成和用户培训等工作。

交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代,包括为发布做准备的产品测试,基于用户反馈的少量的调整。在生命周期的这一点上,用户反馈应主要集中在产品调整,设置、安装和可用性问题,所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。

3.3. 任务规范(Discipline)

3.3.1. 业务建模方法

产品的第一个产出:愿景

业务建模方法

3.3.2. 需求方法

需求方法

4. UP的变种

改进的统一过程主要区别在于如何对项目流程进行分类。Rational Unified Process中定义了九个规范(disciplines):业务建模,需求,分析和设计,实现,测试,部署,配置和变更管理,项目管理,以及环境。 企业统一过程(Enterprise Unified Process)通过增加八个“企业”规范来扩展RUP 。 统一过程的敏捷改进,如OpenUP/Basic UP/Agile UP等,通过减少减少规范的数量来简化RUP 。

改进的另外一个区别在于强调不同的项目工件(artifacts)。Agile统一过程通过简化工作流程减少预期工件的数量来简化RUP 。

改进的不同之处也体现在交付阶段之后的规范。在RUP的交付阶段之后通常是一个新的初始阶段;而在企业统一过程却是一个生产阶段。

UP有无数的变种,组织总是根据自己的需要对UP进行修改和扩展。下面是一些比较有名的变种:

5. Reference


CategoryProcess

MainWiki: Unified_Process (last edited 2014-06-30 08:07:35 by twotwo)