可视化建模
模型是现实世界实体或过程的简化表达，它帮助我们想象和勾画出现实世界的形象。在软件开发早期的一些时候，需要理解系统和用户之间的关系。开发者有两个选择：他们可以按照他们猜想的软件工作方式去实施软件，或者创建一个模型，这个模型会提供给潜在的用户，设计者和测试人员，由他们的反馈再对模型进行变更。
模型的类别描述了用户怎样和系统交互，它经常被作为用例被提及。创建用例模型的要点是减小错误构建系统的风险。在RUP中还有其他类别的模型，每一种用来减小特定的风险。潜在的假设是在系统模型中比在实物中更有利于发现错误和缺点。处理这些模型是犯错的最廉价方式。
通常来说，建模是有些理论性的实践，它有助于我们用简化的方法去理解复杂的系统。原型是一种非常有帮助的建模类型，它可以用于模拟，原理测试，或者设计的特定方面的实际工作。原型用于生成能够说明系统某方面或某种特性的信息。RUP鼓励架构设计组通过创建原型来证明他们的架构概念。
在拍摄电影的前期，只有剧本。但就和软件项目一样，导演需要在完成之前看到电影的样子。如同使用RUP一样，解决方法是建立一个故事的模型。在电影工业中这称为可视化，它可以用不同的技术来实现：传统的方式有演员扮演，木偶扮演，情节串连图板，甚至3D电脑图像。如果使用情节串连图板（顺便说一下，它同样是存在于RUP中的一个概念）的话，这个模型由一系列反映舞台或场景的草图组成。为了进一步增强这一模型的用途，情节串连图板可以被拍成电影并进行修改，可以加上临时的音效和配乐。
在软件开发和电影制作中，建模都是一个动态的，无序的，创性的过程。许多时候需要一次次的迭代进行，直到完成一个令人满意的结果。
持续的质量验证
日常生活中和软件项目开发中，每一件事都要占用时间和空间。RUP分为四个阶段，每一个阶段的重点放在开发周期内一个特定的方面：起始，精化，构建和产品化。在每一个阶段中RUP的非常好的实践给我们机会验证开发中项目的进度和质量，从而尽可能早的找到错误和潜在的改进。
在起始阶段，重点是理解项目的目的。通过探索需求来实现，确定可能会发生的主要风险以及之后可能会出现问题的地方。在这个阶段结束前需要回答的问题是，这个项目是不是值得去做。进行一个没有价值的项目只能浪费时间，浪费可以投到有价值项目上的金钱。这一类的问题必须尽早的得到处理。
当一个项目需要继续时，就进入了精化阶段。这里的重点是建立一个坚实的设计基础（架构）以及减小项目主要的风险。分析完需求之后，根据对架构影响最大的需求定制架构是很必要的。当架构已经确定并且被证明符合重要需求之后，填充系统功能就很安全了。因此，你必须停留在精化阶段直到你证明了你的架构是有效的。
概括地说，在RUP中，每一次迭代都要检验上一次增加的质量。我们首先检验我们是否已经理解了问题，并且存在一个可靠的业务场景。如果不是，我们或者继续直到达到了这一点，或者停止这个项目，节省时间和金钱。在我们填充系统功能之前，我们同时也检验是否已经建立了一个十分牢固的架构。持续的质量验证非常好的实践可以使这样做变得容易。
在电影项目中，导演首先使用模型工具发现分期的故事情节，不吻合的场景，或不适当的节奏等问题。问题较早的发现之后，处理它们就比较简单了。电影制作和软件开发一样，普遍的规则是问题发现越早，修改成本越低。
管理变更
我想我们都同意变更是必然的，但又是不容易处理的。需求总是随着时间不可避免的变化，由于许多不同的原因——项目的投资者改变了主意，开发者对需求有了更深的认识，设计决定产生的效果变得明显，等等。确定变更的必要性是一件事，但是做出变更是另一件事。瀑布式开发经常失败的一个原因是，他不能够处理变更。与此相对比，迭代和增量式方法使得连续的变更更加容易，迭代会得出更好的解决方案。
拍一部长片是一项浩大的任务，它包括管理一个巨大的团队和充足的预算。对于这样一个项目来说，和必须要做的变更保持良好的沟通是成功的关键。可以想象，导演希望改进最后一个场景。尽管它在电影的末尾，但改进的需要可以很早就确定下来，因为在每一个级别上都连续的检验质量。编剧必须修改剧本吗？谁去审查和改进影片？这个场景需要重新建模吗？如果是的话，要使用情节串连图板、3D图像、还是塑料模型？布景需要修改，还是重新建一个布景？我们需要寻找新的位置吗？我们需要请特技演员吗？这些变更对我们的预算影响如何？我们需要请求更多的时间和经费吗？这些就是在变更计划时遇到的种种问题，它们必须被处理，处理他们更适合使用迭代的方式。
一个电影项目计划
RUP框架中一个关键组件就是项目计划。项目计划详细描述了任务、时序、成本、资源、里程碑，和完成项目所需的可交付工件。进度按照计划来执行，并且根据已完成的工作来度量——根据达到的里程碑和交付的结果。在项目开始就构思了这个计划，并且在项目的生命周期内这个计划经常变更。
项目计划像RUP框架一样，很容易适用于软件开发之外的项目。作为一个例子，让我们看一看一个很粗略的电影项目计划。
在这个例子中，RUP规程被电影制作相关活动所取代。开发电影剧本和撰写需求类似，拍摄电影和实施类似，制作电影或多或少和项目管理类似。把时间表分为四个部分，这样在不同的时间将重点放在电影制作不同的方面。我们也能发现这些活动是并行的，通常高效的，跨功能的交换信息和工作成果——就像RUP中那样。
将RUP应用于其它类型的项目
RUP的原理并不仅仅针对软件开发或电影制作。在不可靠性是首要问题的情况下，这些原理都是可用的。在这种情况下，无论你花多少时间多少精力，预先计算出结果是不可能的。更普遍的讲，RUP的原理可以应用于具有以下特性的项目中：
. 产生可交付工件的项目
. 解决方法一定程度上未知的项目
. 不可预期性是关键因素的项目
以下是RUP原理可能有帮助的一些项目例子：
. 如果你要写一本有关C++编程的书，你首先的目标是可交付工件（这本书本身）。这本书的内容和结构，它的关键章节，教学方法都是这本书中未知或不可预期的例子。首先你要确定目标读者，并且为每一章写一个简短的描述。之后，你可能会细化关键章节，在进行其他部分之前检查这些章节。最后一步是完成全书，交送给出版商。
. 如果你要进行如何在软件组织中增强测试能力的研究，可能会期望你完成一些报告。首先你需要理解这些问题，制定一个粗略的时间安排和调查期间的资源保护。之后，在你能够更新并且随着对问题的深化交流计划之前，你会尝试用不同的方法来减小主要的不确定性。消除了高的风险后，你可以继续进行研究。最后，你撰写报告，获得客户的同意。并不是巧合，许多研究方法都基于同RUP类似的原理。
. 如果你要在一个组织中实施RUP，你通常应从确定风险、机会，和创建高级使用方案开始。你可能会在第一个项目中从实施最关键部分（依目标机构的情况而定）开始，而将并不重要的部分留到以后的项目中完成。对于一个更加有能力的开发组织，可交付工件将是一个文档化的RUP过程配置。
小结
RUP提供了带有规程和实践的框架，它可以减小软件开发的不可预知性。此外，RUP 的基本原理可以用来解决其它类型的不可预知问题，如电影制作或撰写书籍。遵从RUP 并不能使得软件开发——或电影制作——更加简单。总的来说，和传统的开发相比，这是一条艰苦的路。然而在这条路上的努力被证明是有价值的，因为我们可以得到回报：改善的产品质量和更加可预测的开发成果。
