RUP 概述
Rational Unified Process 是当今使用中的实际标准的软件工程过程。1RUP 的目标是确保能够按时并在预算之内生成能够可预见地满足最终用户需求的高质量软件。RUP 为在开发组织内分配任务和职责提供规程式的方法，并已经应用到许多项目中，这些项目有各种大小和复杂度，开发团队有大有小，且开发时间有延续几周的，也有延续几年的。
图 1 以二维的形式说明 RUP 的整个体系架构。水平轴代表时间并显示了过程生命周期的各个方面。生命周期阶段的管理视图在顶部，迭代的软件工程和项目管理视图在底部。垂直轴代表按照逻辑分组的规程，表示过程的静态方面 —— 如何用过程部件、规程、活动、工作流，工件和任务来描述 RUP。
图 1. 规程、阶段和迭代的 RUP 概念
在基于 RUP 项目的任何时间点，都会有按照多种规程发生的活动。区别不同生命周期阶段的东西不是缺少某些规程，而是不同规程在整个工作流中所做出贡献的相对量。活动的混合会随着项目的重点和优先权的变更而随时变化。例如，在早期的迭代中，您将更多时间花费在需求上，而在晚期的迭代中，您将更多的时间花费在实现上。
RUP 阶段和迭代
从管理观点出发，RUP 软件生命周期包括四个顺序的阶段，每个阶段都以一个主要的里程碑结束。进行评估以确定是否达到阶段的目标。令人满意的评估结果可以使项目向下一个阶段进行。简要地说，RUP 生命周期的阶段是：
- 初始：初始阶段的目标是在所有涉众之间达成关于项目的生命周期目标的协议。具有代表性的是，在项目进行之前必须确定重要的业务和需求风险。对于那些少量增强现有系统的项目来说，初始阶段是简短的，但仍旧着重于确保项目即值得做又可能实现。生命周期目标里程碑是初始阶段的主要出口标准。它估计了项目的基本生存能力。
- 细化：细化阶段的目标是为系统体系架构设定基础，用来为构建阶段的大多数设计和实现工作提供稳定的基础。细化阶段会描绘出一个将必要的业务需求结合了技术体系架构的可执行的系统，并论证所选技术方法的生存能力。该体系架构进化了对最重要的需求（哪些需求对系统的体系架构有很大的影响）的考虑和对风险的评估。生命周期体系架构里程碑为系统的体系架构建立了一个受控的基线，并令项目团队在构构建段进行测量。
- 构建：构建阶段的目标是澄清剩余的需求并完成基于基本体系架构的系统的开发。构建阶段在某种意义上说是一个制造过程，在此阶段要强调对资源的管理和对操作的控制，用来优化成本、进度和质量。在这个意义上说，管理团队经历着一个从初始和细化阶段的知识产权的开发到构建和产品化阶段的可部署产品的开发的变迁。初始的操作能力里程碑确定是否可以将产品部署到用户能够接受的环境中。
- 产品化：产品化阶段的重点是确保软件对最终用户是可用的。产品化阶段可以跨越若干次迭代，该阶段包括为发布而进行的产品测试，以及根据用户反馈做出较小调整。在生命周期的这个阶段，用户的反馈应主要用于对产品进行微调、配置、安装和解决可用性问题，在项目生命周期的更早期就应该解决所有的主要结构问题。产品版本里程碑是一个您需要在此决定项目是否达到目标，及您是否应该开始另一个开发循环的位置。从软件工程和项目管理的观点出发，随着迭代的进行，事情会逐日的发生。阶段由若干迭代组成 —— 依照基本计划和评价标准的不同序列的活动会致使工件的发布（内部或外部的）。生命周期的每个阶段都由一系列迭代组成，迭代的特性根据您所在的生命周期的位置不同而不同。
RUP 和 MDA
目前，RUP 没有提供对如何将软件开发的 MDA 式样整合到整个过程中的具体指导。这不奇怪，RUP 反映当前行业的最佳实践，且只有在领域内很好地确定之后才能编制方法。MDA 是一个新兴的方法，应用到 RUP 项目中重要的 MDA 最佳实践仅到现在才变得可以得到。
然而从我们的经验中可以得来许多重要的方式，我们可以以这些方式用 MDA 项目的最佳实践来增强 RUP。特别是，RUP 的灵魂，即以体系架构为中心的迭代的开发过程，与 MDA 概念保持高度一致，并为在 MDA 方面取得成功提供极好的基础。
然而，存在着一些领域对 MDA 提供额外的适当指导。在此，我们考虑许多重要的关于将 RUP 应用到 MDA 项目中的重要方面。
- MDA 项目所影响的主要阶段是细化阶段。观察细化阶段的活动并简要地描述 MDA 改进是很重要的。
- 架构师是细化阶段的主要角色，需要对其进行额外的考虑。随着“架构师”的专业化，许多 MDA 项目都需要 MDA 架构师角色。从本质上说，该角色规定了具体的 MDA 活动和工件，创建转换等。因此，出自该角色的主要 MDA 工件是映射文档、转换和 UML profile 文件。
- MDA 如与模型驱动自动化一样与模型驱动体系架构有关。这提供了某种关于如何观察 MDA 和 RUP 的指导。有代表性的是，MDA 自动操作 RUP 中的活动。MDA 利用针对支持将许多主要 RUP 活动自动化的额外工作来扩充 RUP 活动，而不是改变它们。
- MDA 的应用涉及许多 RUP 任务，但它们不需要额外的活动。相反地，每个任务中的标准活动将要求加入关于那些活动如何利用所选的具体工具和 MDA 技术来实现自动化的细节。在 RUP 中，我们称这些额外的细节为 RUP Tool 指导。例如，一个进行关于对象的数据映射的团队可能会利用建模工具进行一组 MDA 转换。但在高级别上，他们关于“定义设计类”的工作流会基本上保持不变。
- 更深入的是，对 RUP 的主要变更包含对开发过程的视图的更微秒的改变。MDA 促使架构师和开发人员在比非 MDA 项目中期望的更高的抽象级别上工作。这在构建阶段是最明显的，在此阶段，MDA 的代码自动化方面较大地改变了实现工作的重点。开发人员能够在对 MDA 转换进行输入时继续进行更抽象的分析并设计模型。他们发现他们更少地处理实际的实现模型和源代码，而更多地进行针对解决方案的适当的着重于业务的工作流的设计。会有更少的开发人员实现模型到代码的转换。
- MDA 转换常常形成于预先建立的解决方案框架（也称为“参考体系架构”或“应用程序框架”）周围。MDA 转换用具体领域的业务逻辑扩充这些框架。这种将 MDA 和解决方案框架结合的方法具有很大的意义，因为完整的 MDA 方法是作为自动化一组可重复技术和资产的中心。然而，它更进一步地使开发过程更着重于重用、管理资产和增加了的解决方案的交付。
使用 MDA 定制解决方案框架
当今的企业软件系统很少是（如果有的话）在集成开发环境（IDE）中从零开始，一行行地被开发出来的。相反，它们是通过用具体领域的业务逻辑来扩展现有解决方案框架，通过连接（并利用）来自不同源头的信息，并通过设计丰富环境的用户显示和迭代服务创建而成的。因此，随后的开发方法不是典型的“瀑布”方案，在瀑布方案中，收集需求之后进行分析和设计，并进行系统的实现。相反，此种开发方法是连续地扩展并细化现有的部分解决方案，通过一组迭代向解决方案中添加值来达到所期望的目标。
文章来源于领测软件测试网 https://www.ltesting.net/
