理性统一过程
理性统一过程（ RUP ）是由理性软件公司创建的迭代软件开发过程框架，自2003年以来， IBM的一个部门。RUP不是一个单一的具体规定过程，而是一个适应性的过程框架，旨在由该过程量身定制。开发组织和软件项目团队将选择适合其需求的流程元素。 RUP是统一过程的特定实现。
历史
理性软件最初将理性统一过程作为软件过程产品开发。该产品包括一个超链接的知识基础，其中包含样本伪像以及许多不同类型的活动的详细描述。 RUP包含在IBM Rational Method Composer（RMC）产品中，该产品允许自定义该过程。
经验丰富的理性技术代表Philippe Kruchten的任务是领导原始RUP团队。
这些初始版本将理性软件组织的广泛现场经验结合在一起，建立了面向对象的系统（理性现场人员称为理性方法）和Objiveory对用例等实践的指南，并结合了Jim Rumbaugh的对象建模技术（ OMT） ）建模方法，Grady Booch的Booch方法和新发布的UML 0.8。
为了帮助使这个不断增长的知识库更容易获得，菲利普·克鲁滕（Philippe Kruchten）的任务是为现代软件工程的明确过程框架组装。这项工作采用了基于HTML的工艺交付机制，由对方开发。由此产生的“理性统一过程”（RUP）完成了一个理性的战略三脚架：
- 可量身定制的过程指导开发的过程
- 自动化该过程应用的工具
- 加速采用过程和工具的服务。
根据理性获得的公司的经验，随后的版本中增强了该指南。
1997年，该方法添加了要求和测试纪律，这是迪恩·莱芬威尔（Dean Leffingwell）等人开发的大量其他材料。在Requisite，Inc。和SQA Process方法在SQA Inc.开发的SQA Process方法，这两家公司都是由Rational Software收购的。
在1998年，理性软件增加了两个新学科：
- 业务建模，大部分内容已经存在于对象过程中
- 通过纯粹的Atria Corporation获得的配置和变更管理学科。
这些增加导致了一组总体原则，这些原则是由理性定义的，并将RUP阐明为现代软件工程的六种最佳实践：
- 迭代发展，风险为主要迭代驱动程序
- 管理要求
- 采用基于组件的体系结构
- 视觉上模型软件
- 不断验证质量
- 控制更改
这些最佳实践与《理性的产品线》紧密地保持一致，并且都推动了Rational的产品的持续开发，以及Rational的现场团队使用的，以帮助客户提高其软件开发工作的质量和可预测性。
还包括包括性能测试，UI设计，数据工程在内的其他技术以及反映UML 1.1变化的更新。
1999年，引入了项目管理学科，以及支持实时软件开发和更新以反映UML 1.3的技术。此外，第一本描述该过程的书，统一软件开发过程（ISBN 0-201-57169-2）由伊瓦尔·雅各布森（Ivar Jacobson ），格雷迪·布赫（Grady Booch）和詹姆斯·伦贝（James Rumbaugh 。）发表于同年。
在2000年至2003年之间，许多更改还从持续的理性现场经验以及迭代开发中引入了指导，此外，除了制定RUP实例和自定义RUP框架的工具支持外，还引入了指导。这些更改包括：
- 从极端编程（XP）等方法引入概念和技术，后来将被统称为敏捷方法。这包括诸如配对编程，测试优先设计和论文之类的技术，这些技术解释了RUP如何使XP扩展用于大型项目。
- 对测试学科进行的全面大修，以更好地反映在不同的迭代开发环境中如何进行测试工作。
- 引入支持指南（称为“工具导师”），以制定各种工具中的RUP实践。这些基本上为理性工具用户提供了分步方法支持。
- 自动化RUP的自定义，以使客户可以从RUP Process Framework中选择零件，使用自己的添加来自定义选择，并且仍然在随后的Rational释放中进行了改进。
IBM于2003年2月收购了理性软件。
2006年，IBM创建了一个针对敏捷项目交付的RUP的子集 - 作为OpenSource方法通过Eclipse Web Site发布，称为OpenUP 。
理性统一过程主题
RUP构建块
RUP基于一组构建块和内容元素，描述要生产的内容，所需的必要技能以及分步说明，描述了如何实现特定的开发目标。主要的构建块或内容元素如下：
- 角色（WHO） - 一个角色定义了一组相关技能，能力和职责。
- 工作产品（什么） - 工作产品代表由任务产生的东西，包括在整个过程中生产的所有文档和模型。
- 任务（How） - 一个任务描述了分配给一个有意义结果的角色的工作单位。
在每次迭代中，任务分为九个学科：
四个项目生命周期阶段
RUP决定了一个由四个阶段组成的项目生命周期。这些阶段允许以与“瀑布”风格的项目相似的方式以高级别的方式呈现该过程，尽管从本质上讲，该过程的关键在于整个阶段中发展的迭代。同样，每个阶段都有一个关键的目标和里程碑，最终表示要完成的目标。随着时间的推移，RUP阶段和学科的可视化称为RUP驼峰图。
成立阶段
主要目标是充分范围作为验证初始成本和预算的基础。在此阶段，建立了包括业务环境，成功因素（预期收入，市场认可等）和财务预测的业务案例。为了补充业务案例，生成了基本用例模型，项目计划，初始风险评估和项目描述（核心项目要求，约束和关键功能）。完成后，根据以下标准检查项目：
- 利益相关者在范围定义和成本/时间表估计上的同意。
- 主要用例的保真度证明了要求的要求。
- 成本/时间表估计，优先级，风险和开发过程的可信度。
- 开发的任何建筑原型的深度和广度。
- 建立一个基准，以比较实际支出与计划支出。
如果该项目没有通过这个里程碑，称为“生命周期目标里程碑”，则可以在重新设计后可以取消或重复以更好地满足标准。
详细阶段
主要目的是减轻直到本阶段结束之前的分析确定的关键风险项。详细阶段是项目开始成形的地方。在此阶段，进行了问题域分析，并且项目的体系结构获得了基本形式。
详细阶段的结果是：
- 一个用例和参与者已经确定并开发了大多数用例描述的用例模型。用例模型应完成80％。
- 软件系统开发过程中软件体系结构的描述。
- 实现架构上重要用例的可执行架构。
- 经过修订的业务案例和风险清单。
- 整个项目的开发计划。
- 可以明显地减轻每个鉴定出的技术风险的原型。
- 初步用户手册（可选）
此阶段必须通过生命周期架构里程碑标准回答以下问题：
- 产品的愿景是稳定的吗？
- 建筑稳定吗？
- 可执行的演示是否表明已经解决并解决了重大风险要素？
- 施工阶段计划是否足够详细且准确？
- 所有利益相关者是否同意在当前架构的背景下使用当前计划来实现当前的愿景？
- 实际和计划的资源支出是否可以接受？
如果该项目无法通过这个里程碑，则仍然有时间取消或重新设计。但是，离开此阶段后，该项目将过渡到高风险的操作，在该操作中，进行时的变化更加困难和有害。
详细说明的关键领域分析是系统体系结构。
施工阶段
主要目的是构建软件系统。在此阶段，主要重点是系统的开发和系统的其他功能。这是大部分编码发生的阶段。在较大的项目中，可以开发几种构建迭代，以将用例划分为可管理的细分市场以生成可证明的原型。
过渡阶段
主要目的是将系统从开发转移到生产中，使其可用于最终用户并理解。此阶段的活动包括培训最终用户，维护人员和Beta测试系统以对最终用户的期望进行验证。该系统还经历了评估阶段，任何未产生所需工作的开发人员都将更换或删除。还针对在开始阶段设置的质量水平进行检查。
如果满足所有目标，则达到产品释放里程碑，并完成开发周期。
IBM合理方法作曲家产品
IBM有理方法作曲家产品是用于创作，配置，查看和发布过程的工具。有关更多详细信息，请参见IBM有理方法作曲家和开源版Eclipse Process Fracework （EPF）项目。
认证
2007年1月，发布了IBM认证解决方案设计师 - 合理统一流程7.0的新RUP认证考试，取代了先前版本的该课程，称为IBM合理认证专家 - 合理的统一流程。新考试不仅将测试与RUP内容相关的知识，还将测试与过程结构元素有关的知识。
要通过新的RUP认证考试，一个人必须参加IBM测试839：合理统一过程v7.0 。您有75分钟的时间参加52个问题考试。传球分数为62％。
六个最佳实践
为软件项目定义了六种最佳的软件工程实践，以最大程度地减少故障并提高生产率。这些都是：
- 迭代发展
- 最好提前了解所有要求；但是，通常情况并非如此。存在几种软件开发过程，这些过程涉及提供解决方案以最大程度地降低开发阶段的成本。
- 管理要求
- 始终请记住用户设定的要求。
- 使用组件
- 分解一个高级项目不仅建议，而且实际上是不可避免的。这促进了在将单个组件集成到较大系统中之前测试它们的能力。此外，代码重用是一个很大的优势，可以通过使用面向对象的编程更容易地完成。
- 在视觉上
- 使用图表表示所有主要组件，用户及其交互。 “ UML”（统一建模语言的缩写）是一种可以用来使此任务更可行的工具。
- 验证质量
- 始终在任何时间点使测试成为项目的主要部分。随着项目的进行，测试变得更重，但应该是任何软件产品创建的恒定因素。
- 控制更改
- 许多项目都是由许多团队创建的，有时在各个位置，可能会使用不同的平台等。因此，必须确保对系统进行的更改进行同步和验证。 （请参阅连续集成）。