RUP

RUP是逐步规避风险的过程。越是重大的风险，越是要尽早处理掉，越是对系统关键的部分，越是要尽早完成。经常性的尽早的交付给用户可执行的版本，使用户可以较多的参与到软件的开发过程中来。根据用户的反馈，尽早调整需求，避免在最终交付时出现较大的偏差。RUP的中心思想就是尽可能的减少风险，而迭代是其主要的方法。

RUP的关键词是用例、迭代（增量），是一个系统从少到多，逐渐建立的过程。

l  用例

用例指的是系统的子功能，是一个黑箱，具备很浓厚的面向对象思想。用例贯穿着整个软件开发过程的始终。用用例来描述需求，再通过实现用例来完成代码编写，对用例进行组合来完成系统的设计，通过测试用例来完成测试任务。在RUP的四个阶段中，有些用例需要重复使用。因此，用例驱动是RUP的一大特点，也意味着RUP是一种面向对象的方法论。

用例模型主要包括两部分：一是用例图，包括了Actor、Use-case和通讯关联，用图的形式描述了系统外部和系统服务之间的相互关系。二是事件流，包括了基本流和备选流。基本流描述的是服务顺利进行的流程，而备选流则列举了可能发生的其它情况，称为用例的场景。

l  迭代

迭代思想，归根到底是一种积极面对变化的思想。通常来说，每一个迭代过程结束了之后，都会有一个新版本的产品。在初始产品的基础上，反复进行需求分析、设计、代码，逐渐便产品逼近于用户的需求。一次迭代必须有明确的目标：我们希望通过这次迭代达到什么目的。这就是所谓的“里程碑”。RUP分为四个阶段：初始阶段、细化阶段、构建阶段和交付阶段。每一个阶段存在多次迭代，而每个阶段的终止，是里程碑，表示这个阶段的迭代必须要完成“里程碑”所明确定义的目标，才进入下一个阶段。

RUP用迭代来化解风险，用迭代来达到对软件质量的持续验证。迭代周期是根据所解决的风险来划分的，RUP建议我们在迭代开始前列出一个风险列表，按照风险的严重程度排序，然后决定在哪次迭代要解决什么风险。同时RUP的四大阶段也是和风险紧密关联的。

 

初始阶段

 

l  初始阶段目标是建立一个粗略的系统草图。

这个草图，已经设计了系统最重要的部分，从用例出发，寻找那些稳定的、业务意义重大的部分。在初始阶段所要完成的用例占有10%-20%，这部分用例是整个系统中最重要的业务功能，即是Top10高级需求。为系统的开发建立一个牢固的基石，以便于在后面几个阶段逐渐对这一草图进行完善。以画画来比喻，就是先勾勒出草图、轮廓。这是初始阶段最重要的任务。

这个系统总体蓝图，包括关键用例（10%-20%）、至少一个软件体系结构，一个或者多个原型，这是初始阶段最重要的产出。

l  从风险的角度来说，初始阶段主要解决的是需求和商业上的风险。

需求风险主要是指在应用软件开发过程中，由于软件需求本身的隐含性、用户与开发者之间的沟通障碍，以及需求随着时间、用户的变化而变更等原因，可能使需求随着时间、用户的变化而变更等原因，可能便需求分析偏离实际需求而最终导致软件开发的失败。商业风险是指由于交易双方中的某一方，或与之关联的某一方的原因导致的风险:比如款式过时，价格过高，质量投诉，商业机密泄露都属于商业风险。针对软件开发，即是指成本过高、交付周期过长、验收不合格、市场不认可等等。

因此，初始阶段的产出还有风险评估和商业案例，包括业务的上下文，即系统的总体输入和输出、验收规范（年度映射、市场认可等等）、成本预计、粗略的日程估计等。在整个软件开发过程中风险最大的部分，将在最开始的阶段就得到解决。

此外，为了规范交流，规范项目术语，建立一个通用的词汇表，即是产出一个原始项目术语表。

 

细化阶段

 

l  细化阶段的主要目标是形成一个稳定的系统架构。

在初始阶段建立的用例和系统蓝图的基础上，不断发现和调整需求，逐步添加用例（80%以上），直到识别大部分的需求，用用例来表达。与此同时，梳理各种需求之间的关系，调整各构件之间的关系，寻找最佳的系统架构。尽早的形成一个可执行、可测试并且稳定的原型，这是细化阶段最重要的任务。一般而言，在细化阶段要经过2到4次迭代来完成这些任务，每一次迭代是2到6周的时间，直到达到里程碑中明确定义的目标。

这一阶段的产出是用例模型（完成至少80％），其中部分重要的用例被开发、稳定的系统架构和初步成型的软件原型，进入下一个阶段。

l  从风险的角度来说，细化阶段要解决的是架构风险。

避免在后期对系统大刀阔斧的改动从而加大成本、延迟交付日期。在这一阶段产出的系统蓝图、体系架构要足够稳定。经过多次的迭代，使系统的架构趋于稳定，能够保证绝大部分需求已经定义好了，而且不会有太大的变化。即使出现部分新的需求，原有的系统架构设计也不会产生太大的变动，只需要在原有的系统上添加或者删除，而不会影响到系统的其它功能。直到架构风险已经被化解，才会进入下一个阶段。

除此以外，还需要捕获非关联于特定用例和非功能性的需求，即如何使这个系统能够在实际环境中运行，包括可用性、可靠性、可维护性、可移植性等。

由于对系统的设计已经进一步细化了，因此可以有更精确的时间管理计划和成本控制计划，即在原有的初始阶段产出的粗糙的计划基础上做修改。

 

构建阶段

 

l  构建阶段的主要工作是形成一个可以提交的软件成品。

完成在细化阶段还未开发的用例，即编程、测试、性能的优化。有可能会有新的需求提出，但基本不会对系统的总体架构有影响。在这一阶段各部分的开发、测试工作是相对独立的，可以并行。主要目标是将系统逐渐完善，达到可以交付经客户的水准。经过这一阶段，软件原型经过步步修改，向成品逼近，为产品的交付、部署做好准备。这个阶段的迭代周期由于已经定义了大部分的风险和意外，迭代周期往往会比较短（一般在1－2周）。这阶段的主要产出是特定平台上运行的集成产品。也有可能根据需要形成了多个产品版本，对每个版本都进行测试。里程碑就是完成这个系统的全部。

l  这一阶段要解决代码和运行上的风险，构造出一个可运行的软件。

通过前两个阶段，已经处理掉了较大的风险，在系统大方向上不会出现较大问题。但是从软件原型，到软件成品，尚需要逐步完善，使软件在交付的时候，能够符合验收标准。

同样，时间成本、人员成本和预算要控制在计划范围内。与软件产品配套的用户手册、版本描述也将与软件成品一起完成。

 

交付阶段

 

l  交付阶段是系统的最终部署阶段。

需要发布一些beta版本进行审核和反馈，基于验收标准，评估产品，判断产品是否达到了用户的满意度。可能还需要几个迭代周期，去除BUG，形成软件的最终提交产品。最后就是部署上线的工作。这个阶段往往还包括向市场、部署、销售团队移交产品，渠道的发行，培训，新旧系统的并行运转，数据的转换。同时要向产品用户和产品支持人员提供技术培训。里程碑是完成这个系统的部署以及完成合同。

l  在这一阶段，将解决发布的风险，将软件正式交付。

即是，通过对产品各个版本的反复测试，包括发布给客户beta版本，让客户介入到测试中来，以确保产品最终提交的时候能够符合验收标准，达到客户的满意度，获取市场认可。

 

RUP与瀑布模型

与瀑布模型相比，RUP有其显著的特点。瀑布模型在编码之前试图做绝大部分需求分析和设计，将项目的主要测试和评估放到项目的最后。初始阶段不等于需求分析阶段，因为RUP的初始阶段只确定了最高级的需求，而还有更多的需求在细化阶段经过反复迭代多次修改才会最终确定。而在需求尚未全部确定的时候，一些系统的核心用例可能已经被开发了。

RUP裁剪

RUP裁剪步骤：1）确定软件过程需要哪些工作流；2）确定每个工作流产出哪些工件；3）确定阶段演进；4）确定阶段内的迭代计划；5）规划工作流内部结构。