制定IEEE定义的RUP把架构定义为‘环境中最高级别的系统概念。
该方法的结果是尽可能多地确定了RUP角色和工件的职责矩阵。
令人悲伤的是，RUP常常被认为与项目管理标准相竞争，比如PMBOK。
自己处理RUP的裁剪，让您的团队等着您的指导，在缺乏剪裁RUP的内行经验的情况下，这样做是很困难的。
对于MSF，单词“规程”指的是比RUP中更加全面和一般的过程集合。
工作总是按照30天的“疾跑”排列下来的，而不是定义一个RUP项目的一次迭代的长度。
RUP顾问从调查会议开始，在这个过程中，公司中所有的涉众都会出席。
但是，事情往往是团队成员在单个项目中往往只成为一个或一部分RUP角色。
但是，反过来就不总是对的了，因为RUP拥有许多MSF中目前不存在的工件。
对于一个更加有能力的开发组织，可交付工件将是一个文档化的RUP过程配置。
这篇文章仅仅是对RUP团队所追求的对方法开发过程形式化的一个初步尝试。
沿着这些思路，许多PM想要看到RUP初始阶段之间加上照顾这些问题的额外时期。
当企业开始采用RUP时，完成这一系列的开发案例是十分繁重且花费时间的过程。
基本的开发周期在图1中被显示出来（它大量的借用了RUP的内容）。
简单的说，RUP根据拥有迭代的阶段来描述开发过程。
项目计划像RUP框架一样，很容易适用于软件开发之外的项目。
RUP顾问应该设法使所有公司特有的工件和角色不覆盖已经在RUP中确定的内容。
许多企业使用一组RUP过程用于开发（往往配置RUP过程资产完全使用“现有的过程”）。
有大量的求职者具有所必需的工作经验，然而其中一部分人拥有IBM的RUP认证。
同样地，使用RUP作为一个企业信息构架的基础也未被证明是合理的。
事实上，您需要了解RUP的全部才能够以合理的方式对它进行剪裁，因此您将在将来的六个月中非常繁忙。
或者，你可以在你的插件中定义一个定义了你的变化的工作产品来取代原来的RUP工作产品。
许多开发团队选择用敏捷的方式举例说明RUP，而许多其他的团队选择到处借鉴一些敏捷的思想。
值得提到的是，将RUP的范围扩展到整个企业的尝试已经进行了许多了。
如果所有我们要裁剪的都是Rational统一过程项目管理规程，这样就好了。
更正式一点的说法是，您能够将其作为RUP软件架构文档的等价物。
MDA是一个新兴的方法，应用到RUP项目中重要的MDA最佳实践仅到现在才变得可以得到。
红色所示，映射到三个Rational统一过程活动：开始商业用例，启动项目，启动迭代（也是红色所示）。
RUP的定义测试方法工作流包含许多步骤，包括称为确定测试的必要深度的步骤。