统一软件开发过程（英语：Rational Unified Process，缩写为RUP）是一种软件工程方法，为迭代式软件开发流程。本文简单介绍了相关理论和知识。

RUP概述

RUP（Rational Unified Process）根据字面理解，可以知道RUP包括三方面的意思，即Rational、Unified和Process。Rational表示RUP是由Rational公司提出的，Unified表示RUP是最佳开发经验总结，而Process表示RUP是一个软件开发过程。

RUP的生命周期

RUP软件开发生命周期是一个二维的软件开发模型，RUP中有9个核心工作流，这9个核心工作流如下。

业务建模（business modeling）：理解待开发系统所在的机构及其商业运作，确保所有参与人员对待开发系统所在的机构有共同的认识，评估待开发系统对所在机构的影响。
需求（requirements）：定义系统功能及用户界面，使客户知道系统的功能，使开发人员理解系统的需求，为项目预算及计划提供基础。
分析与设计（analysis & design）：把需求分析的结果转化为分析与设计模型。
实现（implementation）：把设计模型转换为实现结果，对开发的代码做单元测试，将不同实现人员开发的模块集成为可执行系统。
测试（test）：检查各子系统的交互与集成，验证所有需求是否均被正确实现，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议。
部署（deployment）：打包、分发、安装软件，升级旧系统；培训用户及销售人员，并提供技术支持。
配置与变更管理（configuration & change Management）：跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。
项目管理（project management）：为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。
环境（environment）：为软件开发机构提供软件开发环境，即提供过程管理和工具的支持。

需要说明的是表示核心工作流的术语discipline，在RUP 2000以前用的是core workflow这个术语，但在最新的版本中已改为用discipline。discipline的中文意义较多，根据RUP的定义，discipline是相关活动的集合，这些活动都和项目的某一个方面有关，如这些活动都是和业务建模相关的，或者都是和需求相关的，或者都是和分析设计相关的等等。

RUP把软件开发生命周期划分为多个循环（cycle），每个cycle生成产品的一个新的版本，每个cycle依次由4个连续的阶段（phase）组成，每个阶段完成确定的任务。这4个阶段如下。

初始（inception）阶段：定义最终产品视图和业务模型，并确定系统范围。
细化（elaboration）阶段：设计及确定系统的体系结构，制定工作计划及资源要求。
构造（construction）阶段：构造产品并继续演进需求、体系结构、计划直至产品提交。
移交（transition）阶段：把产品提交给用户使用。
每一个阶段都由一个或多个连续的迭代（iteration）组成。迭代并不是重复地做相同的事，而是针对不同用例的细化和实现。每一个迭代都是一个完整的开发过程，它需要项目经理根据当前迭代所处的阶段以及上次迭代的结果，适当地对核心工作流中的行为进行裁剪。

在每个阶段结束前有一个里程碑（milestone）评估该阶段的工作。如果未能通过该里程碑的评估，则决策者应该做出决定，是取消该项目还是继续做该阶段的工作。

RUP中的核心概念

RUP中定义了如下一些核心概念，理解这些概念对于理解RUP很有帮助。

角色（Role）——who的问题：角色描述某个人或一个小组的行为与职责。RUP预先定义了很多角色，例如体系结构师（architect）、设计人员（designer）、实现人员（implementer）、测试员（tester）和配置管理人员（configuration manager）等，并对每一个角色的工作和职责都做了详尽的说明。
活动（activity）——how的问题：活动是一个有明确目的的独立工作单元。
制品（artifact）——what的问题：制品是活动生成、创建或修改的一段信息。也有些书把artifact翻译为产品、工件等，和制品的意思差不多。
工作流（workflow）——when的问题：工作流描述了一个有意义的连续的活动序列，每个工作流产生一些有价值的产品，并显示了角色之间的关系。
RUP 2003对这些概念有比较详细的解释，并用类图描述了这些概念之间的关系，除了role、activity、artifact和workflow这4个核心概念外，还有其他一些基本概念，如工具教程（tool mentor）、检查点（checkpoints）、模板（template）和报告（report）等。

RUP的特点

与别的软件开发过程相比，RUP具有自己的特点，即RUP是用例驱动的、以体系结构为中心的、迭代和增量的软件开发过程。下面对这些特点做进一步的分析。

用例驱动

RUP中的开发活动是用例驱动的，即需求分析、设计、实现和测试等活动都是用例驱动的。

以体系结构为中心

RUP中的开发活动是围绕体系结构展开的。对于软件体系结构，目前还没有一个统一的精确的定义，不同的人对软件体系结构有不同的认识。Mary Shaw和David Garlan对软件体系结构的定义是：软件体系结构是关于构成系统的元素、这些元素之间的交互、元素和元素之间的组成模式以及作用在这些组成模式上的约束等方面的描述。具体来说，软件体系结构刻画了系统的整体设计，它去掉了细节部分，突出了系统的重要特征。

软件体系结构的设计和代码设计无关，也不依赖于具体的程序设计语言。软件体系结构是软件设计过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计。体系结构层次的设计问题包括系统的总体组织和全局控制、通讯协议、同步、数据存取、给设计元素分配特定功能、设计元素的组织、物理分布、系统的伸缩性和性能等。
体系结构的设计需要考虑多方面的问题：在功能性特征方面要考虑系统的功能；在非功能性特征方面要考虑系统的性能、安全性和可用性等；与软件开发有关的特征要考虑可修改性、可移植性、可重用性、可集成性和可测试性等；与开发经济学有关的特征要考虑开发时间、费用、系统的生命期等。当然，这些特征之间有些是相互冲突的，一个系统不可能在所有的特征上都达到最优，这时就需要系统体系结构设计师在各种可能的选择之间进行权衡。
对于一个软件系统，不同人员所关心的内容是不一样的，因此软件的体系结构是一个多维的结构，也就是说，会采用多个视图（view）来描述软件体系结构。打个比喻，对于一座大厦，会有大厦的电线布线结构、电梯布局结构、水管布局结构等，对于大厦的建设和维护人员来说，有些人关心大厦的电线布局，有些人关心大厦的电梯布局，还有些人关心水管布局，对于不同类型的人员，只需要提供这类人员关心的视图即可（一个视图可以用一个或多个图来描述），所有这些视图组成了大厦的体系结构。至于采用多少个视图，采用什么视图较好，不同的人就有不同的观点了。
在RUP中，是采用如图4-6所示的“4＋1”视图模型来描述软件系统的体系结构。
在“4＋1”视图模型中，分析人员和测试人员关心的是系统的行为，因此会侧重于用例视图；最终用户关心的是系统的功能，因此会侧重于逻辑视图；程序员关心的是系统的配置、装配等问题，因此会侧重于实现视图；系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，因此会侧重于进程视图；系统工程师关心的是系统的发布、安装、拓扑结构等问题，因此会侧重于部署视图。

“4＋1”视图模型

迭代与增量

RUP强调要采用迭代和增量的方式来开发软件，把整个项目开发分为多个迭代过程。在每次迭代中，只考虑系统的一部分需求，进行分析、设计、实现、测试和部署等过程，每次迭代是在已完成部分的基础上进行的，每次增加一些新的功能实现，以此进行下去，直至最后项目的完成。软件开发采用迭代和增量的方式有以下好处：

在软件开发的早期就可以对关键的、影响大的风险进行处理。
可以提出一个软件体系结构来指导开发。
可以更好地处理不可避免的需求变更。
可以较早地得到一个可运行的系统，鼓舞开发团队的士气，增强项目成功的信心。
为开发人员提供一个能更有效工作的开发过程。

RUP裁剪

RUP是一个通用的过程模板，包含了很多关于开发指南、开发过程中产生的制品、开发过程中所涉及的各种角色的说明。RUP可用于各种不同类型的软件系统、不同的应用领域、不同类型的开发机构、不同功能级别、不同规模的项目中。RUP非常庞大，没有一个项目会使用RUP中的所有东西，针对具体的开发机构和项目，应用RUP时还要做裁剪，也就是要对RUP进行配置。RUP就像是一个元过程（meta-process），通过对RUP进行裁剪可以得到很多不同的软件开发过程，这些软件开发过程可以看作RUP的具体实例，这些具体的开发过程实例适合于不同的开发机构和项目的需要。
针对一个软件项目，RUP裁剪可分为以下几步：

确定本项目的软件开发过程需要哪些工作流。RUP的9个核心工作流并不总是需要的，可以根据项目的规模、类型等对核心工作流做一些取舍。如嵌入式软件系统项目一般就不需要业务建模这个工作流。
确定每个工作流要产出哪些制品。如规定某个工作流应产出哪些类型的文档。
确定4个阶段之间（初始阶段、细化阶段、构造阶段和移交阶段）如何演进。确定阶段间演进要以风险控制为原则，决定每个阶段要执行哪些工作流，每个工作流执行到什么程度，产出的制品有哪些，每个制品完成到什么程度等。
确定每个阶段内的迭代计划。规划RUP的4个阶段中每次迭代开发的内容有哪些。迭代是RUP非常强调的一个概念，可以进一步降低开发风险。
规划工作流内部结构。工作流不是活动的简单堆积，工作流涉及角色、活动和制品，工作流的复杂程度与项目规模及角色多少等有很大关系，这一步决定裁剪后的RUP要设立哪些角色。最后，规划工作流的内部结构，通常用活动图的形式给出。
在上面的5个步骤中，第（5）步是对RUP进行裁剪的难点。如果从“软件开发过程也是软件”的角度来看，对RUP进行裁剪可以看作是软件过程开发的再工程。