RUP---统一软件开发过程
更详细的见：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)来描述。
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个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。
