常用软件过程——RUP

RUP是用例驱动，以架构为中心，迭代式开发过程。

一、用例驱动

用例（Use Case）是一种通过用户的使用场景获得需求的技术。区别于传统的功能分解获取需求的办法，用例方法强调用户是如何使用系统的，即描述用户与系统之间的交互，而不涉及系统内部的行为。用例的一般表示法是UML用例图。

用例方法的主要特点有：

需求表述的抽象性。用例方法以UML用例图的形式表示，对于用例、参与者之间的关系一目了然，能更在一个高的抽象级别上理解系统。
需求表述的完整性。某些用户可能并不了解他会使用到系统的某个功能，但UML用例图将有助于发现这些问题。
用例驱动指的是在软件开发过程中，采用用例方法捕获及分析业务需求，并确保由它们来驱动软件的设计、实现和测试，使最终系统更能满足最终用户的需要。

二、以架构为中心

软件架构（体系结构）是构成软件各部分的组件、组件之间的交互及组件组合的约束。软件架构也关系到功能性、可用性、系统弹性、性能、可重用性、可理解性等方面。

在RUP开发的细化阶段，建立一个健壮架构的基础。在构造阶段和交付阶段，再进一步完善架构。在整个开发过程中，架构进一步完善。RUP强调以架构为中心，有利用打造一个可持续开发、可持续维护的软件；且最大限度规避了项目的技术风险。

三、迭代式开发

RUP是一个基于迭代式生命周期模型定义的软件过程。RUP分为4个阶段，即初始阶段、细化阶段、构造阶段、交付阶段。每个阶段可以有多次迭代。在每次迭代中，包含商业建模、需求、分析及设计、测试、部署等依次进行的活动（核心过程工作流），以及配置和变更管理、项目管理、环境（核心支持工作流）。

由于是迭代式开发，在后一阶段就有机会更正前一阶段的错误和疏漏。但是，这样会不会产生惰性，导致把更多问题遗留到后续的迭代中呢？RUP明确定义了各阶段的目标，必须在达到目标后，才能进入下一阶段：

初始阶段，目标是确定项目边界。
细化阶段，目标是分析业务领域以确定架构，并编制明细项目计划。
在构建阶段，目标是构造可运行的代码，并集成测试。
交付阶段的重点是确保软件对最终用户是可用的。
RUP的缺点：

RUP的优点很多。用例驱动对需求管理非常有利，能够确保需求在与用户交互时、系统实现时均不被遗漏；以架构为中心有利于打造一个强健的系统，而不会因系统规模增大而倒塌；迭代式开发有效消解了风险。那么，RUP还有什么不完美的吗？

对于我们这些行业应用软件开发者来说，RUP过于复杂。

用例驱动。用例分析作为一项软件技术，远远比功能分解复杂。大部分需求人员不具备编写用例的能力，用户多数看不懂用例。因此，在交互过程中，传统以功能列表描述为主的《需求规格说明书》应用更加广泛。

以架构为中心。对于业务逻辑非常复杂的系统，打造一个强健的架构是必须的。但对于一些业务逻辑相对简单，而用户交互逻辑复杂的系统，过于强调架构似乎没有必要。例如，对于一个有着很多模块的网站，各个模块相对独立，访问各自的表，维护一套用例图、类图、时序图就成为累赘。

迭代式开发。迭代式开发作为消解风险是非常必要的。RUP迭代中的6个核心工作流和3个核心支持工作流过于繁杂，必须为每个工作流指定其执行者。虽然RUP指出这些工作流在每次迭代中并不都是必须的，但对于一个严谨的软件过程来说，给予项目经理过多的裁剪权，也意味着为项目引入新的风险。