RUP---统一软件开发过程

Posted 2020-07-29 dekevin技术博客

更详细的见：http://www.ibm.com/developerworks/cn/rational/r-rupbp/

本文引用：http://baike.baidu.com/view/2235832.htm#sub2235832

统一软件开发过程（Rational Unified Process,RUP)是一个面向对象且基于网络的程序开发方法论。它是用例驱动的，以架构为核心，迭代和增量的软件过程框架，它提供一种演进的特性。

 

二维结构

开发过程可以用二维结构或沿着两个坐标轴来表达：

• 横轴代表了制订开发过程时的时间，体现了过程的动态结构。它以术语周期（cycle）、阶段(phase)、迭代（iteration）和里程碑(milestone)来表达。
• 纵轴表现了过程的静态结构：如何用术语活动（activity）、产物(artifact)、 角色(worker)和工作流(workflow)来描述。

 

　RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段(Inception)、细化阶段(Elaboration)、构造阶段(Construction)和交付阶段(Transition)。每个阶段结束于一个主要的里程碑(Major Milestones)；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。

1． 初始阶段 

• 初始阶段的目标是为系统建立商业案例和确定项目的边界。
  为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。它包括识别所有用例和描述一些重要的用例。商业案例包括验收规范、风险评估、所需资源估计、体现主要里程碑日期的阶段计划。本阶段具有非常重要的意义，在这个阶段中，关注的是整个项目进行工程中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来说，初始阶段的时间可能很短。
  本阶段的主要目标如下：
  明确软件系统的范围和边界条件，括从功能角度的前景分析、产品验收标准和哪些做与哪些不做的相关决定
  明确区分系统的关键用例（Use-case） 和主要的功能场景
  展现或者演示至少一种符合主要场景要求的候选软件体系结构
  对整个项目做最初的项目成本和日程估计(更详细的估计将在随后的细化阶段中做出)
  估计出潜在的风险(主要指各种不确定因素造成的潜在风险)
  准备好项目的支持环境
  初始阶段的产出是:
  蓝图文档核心项目需求关键特色主要约束的总体蓝图
  原始用例模型(完成10%～20%)
  原始项目术语表(可能部分表达为业务模型)
  原始商业案例,包括业务的上下文、验收规范（年度映射、市场认可等等），成本预计
  原始的风险评估
  一个或多个原型
  里程碑：生命周期的目标
• 初始阶段的评审标准：
  风险承担者就范围定义成本日程估计达成共识
  以客观的主要用例证实对需求的理解
  成本/日程、优先级、风险和开发过程的可信度
  被开发体系结构原型的深度和广度
  实际开支与计划开支的比较
  如果无法通过这些里程碑，则项目可能被取消或仔细地重新考虑。

2． 细化阶段

• 　细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。
  为了达到该目的，必须对系统具有"英里宽和英寸深"的观察。体系结构的决策必须在理解整个系统的基础上作出：它的范围，主要功能和如性能等非功能性需求。
  容易引起争论，细化阶段是四个阶段中最关键的阶段。该阶段结束时，硬"工程"可以认为已结束，项目则经历最后的审判日：决策是否项目提交给构建和交付阶段。对于大多数项目，这也相当于从移动的、轻松的、灵巧的、低风险的运作过渡到高成本、高风险并带有较大惯性的运作过程。而过程必须能容纳变化，细化阶段活动确保了结构、需求和计划是足够稳定的，风险被充分减轻，所以可以为开发结果预先决定成本和日程安排。概念上，其逼真程度一致于机构实行费用固定的构建阶段的必要程度。在细化阶段，可执行的结构原形在一个或多个迭代过程中建立，依赖于项目的范围、规模、风险和先进程度。工作量必须至少处理初始阶段中识别的关键用例，关键用例典型揭示了项目主要技术的风险。通常我们的目标是一个由产品质量级别构件组成的可进化的原型，但这并不排除开发一个或多个探索性、可抛弃的原型来减少如：设计/需求折衷，构件可行性研究，或者给投资者、顾客即最终用户演示版本等特定的风险。
  本阶段的主要目标如下：
  确保软件结构、需求、计划足够稳定；确保项目风险已经降低到能够预计完成整个项目的成本和日程的程度。
  针对项目的软件结构上的主要风险已经解决或处理完成。
  通过完成软件结构上的主要场景建立软件体系结构的基线。
  建立一个包含高质量组件的可演化的产品原型。
  说明基线化的软件体系结构可以保障系统需求可以控制在合理的成本和时间范围内。
  建立好产品的支持环境。
  初始阶段的产出是：
  用例模型（完成至少80％）-- 所有用例均被识别，大多数用例描述被开发
  补充捕获非功能性要求和非关联于特定用例要求的需求
  软件体系结构描述_可执行的软件原型
  经修订过的风险清单和商业案例
  总体项目的开发计划，包括纹理较粗糙的项目计划，显示迭代过程和对应的审核标准
  指明被使用过程的更新过的开发用例
  用户手册的初始版本（可选）
  里程碑：生命周期的结构
•  
  细化阶段结束是第二个重要的里程碑：生命周期的结构里程碑。此刻，检验详细的系统目标
  和范围、结构的选择以及主要风险的解决方案。 主要的审核标准包括回答以下的问题：
  产品的蓝图是否稳定？
  体系结构是否稳定？
  可执行的演示版是否显示风险要素已被处理和可靠的解决
  构建阶段的计划是否足够详细和精确？是否被可靠的审核基础支持？
  如果当前计划在现有的体系结构环境中被执行而开发出完整系统，是否所有的风险承担人同意该蓝图是可实现的？
  实际的费用开支与计划开支是否可以接受？
  如果无法通过这些里程碑，则项目可能被取消或仔细地重新考虑。 

3． 构造阶段

• 　　在构建阶段,所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详尽的测试。
  构建阶段，从某种意义上说，是重点在管理资源和控制运作以优化成本、日程、质量的生产过程。就这一点而言，管理的理念经历了初始阶段和细化阶段的智力资产开发到构建阶段和交付阶段可发布产品的过渡。许多项目规模大的足够产生许多平行的增量构建过程，这些平行的活动可以极大地加速版本发布的有效性；同时也增加了资源管理和工作流同步的复杂性。健壮的体系结构和易于理解的计划是高度关联的。换言之，体系结构上关键的质量是构建的容易程度。这也是在细化阶段平衡的体系结构和计划被强调的原因。
  本阶段的主要目标如下：
  通过优化资源和避免不必要的返工达到开发成本的最小化
  根据实际需要达到适当的质量目标
  据实际需要形成各个版本（Alpha,Beta,and other test release）
  对所有必须的功能完成分析、设计、开发和测试工作
  采用循环渐进的方式开发出一个可以提交给最终用户的完整产品
  确定软件站点用户都为产品的最终部署做好了相关准备
  达成一定程度上的并行开发机制
  构建阶段的产出是可以交付给最终用户的产品。它最小包括：
  特定平台上的集成产品
  用户手册
  当前版本的描述
  里程碑：初始运作能力
•  创建阶段结束是第三个重要的项目里程碑（初始功能里程碑）。此刻，决定是否软件、环境、用户可以运作而不会将项目暴露在高度风险下。该版本也常被称为"beta"版。
  构建阶段主要的审核标准包括回答以下的问题:
  产品是否足够稳定和成熟得发布给用户?
  是否所有的风险承担人准备好向用户移交?
  实际费用与计划费用的比较是否仍可被接受?
  如果无法通过这些里程碑,则移交不得不被延迟。

4． 交付阶段

　

• 交付阶段的目的是将软件产品交付给用户群体。
  只要产品发布给最终用户，问题常常就会出现：要求开发新版本，纠正问题或完成被延迟的问题。当基线成熟得足够发布到最终用户时，就进入了交付阶段。其典型要求一些可用的系统子集被开发到可接收的质量级别及用户文档可供使用，从而交付给用户的所有部分均可以有正面的效果。这包括：
  对照用户期望值，验证新系统的"beta测试"
  与被替代的已有系统并轨
  功能性数据库的转换
  向市场、部署、销售团队移交产品
  构建阶段关注于向用户提交产品的活动。典型的，该阶段包括若干重复过程，包括 beba 版本、通用版本、bug 修补版和增强版。相当大的工作量消耗在开发面向用户的文档，培训用户。在初始产品使用时，支持用户并处理用户的反馈。开发生命周期的该点，用户反馈主要限定在产品性能调整、配置、安装和使用问题。
  本阶段的目标是确保软件产品可以提交给最终用户。本阶段根据实际需要可以分为几个循环。
• 本阶段的具体目标如下：
  进行 Beta 测试以期达到最终用户的需要
  进行 Beta 测试和旧系统的并轨
  转换功能数据库
  对最终用户和产品支持人员的培训
  提交给市场和产品销售部门
  和具体部署相关的工程活动
  协调 Bug 修订/改进性能和可用性(Usability)等工作
  基于完整的 Vision 和产品验收标准对最终部署做出评估
  达到用户要求的满意度
  达成各风险承担人对产品部署基线已经完成的共识
  达成各风险承担人对产品部署符合 Vision 中标准的共识
  该阶段依照产品的类型,可能从非常简单到极端复杂的范围内变化。例如，现有的桌面产品的新版本可能非常简单，而替代国际机场的流量系统会非常复杂。
  里程碑：产品发布
• 在交付阶段的终点是第四个重要的项目里程碑，产品发布里程碑。此时，决定是否目标已达到或开始另一个周期。在许多情况下，里程碑会与下一个周期的初始阶段相重叠。
  发布阶段的审核标准主要包括以下两个问题：
  用户是否满意？
  实际费用与计划费用的比较是否仍可被接受？

　

RUP中有9个核心工作流，分为6个核心过程工作流(Core Process Workflows)和3个核心支持工作流(Core Supporting Workflows)。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期中一次又一次被访问。9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。

1． 商业建模(Business Modeling)

　　商业建模工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用例模型和商业对象模型中定义组织的过程，角色和责任。

2． 需求(Requirements)

　　需求工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围。蓝图被创建，需求被提取。代表用户和其他可能与开发系统交互的其它系统的 Actor 被指明。Use case 被识别,表示系统的行为。因为use case 根据 actor 的要求开发,系统与用户之间的联系更紧密。系统展示了用于再生系统的用例模型。

3. 分析和设计(Analysis & Design)

　　分析和设计工作流将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。分析设计的结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象，由设计类和一些描述组成。设计类被组织成具有良好接口的设计包(Package)和设计子系统(Subsystem)，而描述则体现了类的对象如何协同工作实现用例的功能。 设计活动以体系结构设计为中心，体系结构由若干结构视图来表达，结构视图是整个设计的抽象和简化，该视图中省略了一些细节，使重要的特点体现得更加清晰。体系结构不仅仅是良好设计模型的承载媒介，而且在系统的开发中能提高被创建模型的质量。

4． 实现(Implementation)

　　 　实现工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式(源文件、二进制文件、可执行文件)实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。

5． 测试(Test)

　　测试工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现, 识别并确　认缺陷在软件部署之前被提出并处理。RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。测试类似于三维模型，分别从可靠性、功能性和系统性能来进行。

6． 部署(Deployment)

　　 　部署工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下，还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。

7． 配置和变更管理　(Configuration & Change Management) 

 

　　配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。同时也阐述了对产品修改原因、时间、人员保持审计记录。

8． 项目管理(Project Management)

　　 　软件项目管理平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。其目标包括：为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。

9． 环境(Environment)

　　 　环境工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。环境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。