| 为了向初学者介绍 RUP 框架，软件开发的过程经常和建筑过程相比较。但是和建造房屋比起来，使用 RUP 进行软件开发更像是在制作电影，这正如文章题目所说的那样。 每个 IBM Rational Unified Process 框架的新用户都容易因为它的大小，因为它包含的上百个工件和活动而感觉到沮丧。但事实上理解 RUP® 框架的要点是相对容易的，特别是在介绍时把它们同一些熟悉的过程相类比。一个常用的类比是将使用 RUP 进行软件开发的过程和建造房屋的过程相比较。我感觉这种类比有一些缺乏考虑，而我在本文中打算使用另一个不同的类比。我认为使用 RUP 框架创建软件系统的过程在很多方面同构思并制作一部长的电影很类似。 用建造房屋类比的问题 土木工程师可能会不同意，并且认为建筑项目中和软件项目中的问题是共同的。然而事实是土木工程依靠的是一些众所周知的物理定律，而软件工程不是！ 考虑到这些问题，促使我们怀疑是否能够找到除了建筑过程以外更好的一个类比来向人们介绍 RUP 框架。我似乎觉得尽管RUP和工程过程一样有着基本的目标和策略，但事实上实现这些目标的过程和艺术领域内使用创造性方法的过程更有共同点，如拍电影，写书，甚至写一篇类似本文的文章。因此当我介绍了RUP的基本原理后，我将会阐述这些要点是怎样和电影制作相对应的。 RUP的基本原理 在任何类别的开发中使用任何工序的唯一目的就是为了减小风险。更具体的说，使用RUP是为了减小软件开发相关的风险。通过遵从精心设计并已被证明了的规则，我们的目的是增加成功的可能性。毕竟，如果软件设计是可以预测的事情，我们为什么要费如此的力气呢？ 一部分软件开发相关的风险和其他类型开发的风险一样，包括以下几点：
这些是管理风险的例子，可以由经济手段，结构改革，或教育方面的努力来解决。 但仍然有一些风险和软件开发不可预测的特点相关，如下所示：
后者是更加技术化的风险，必须用其他方法解决。为了处理这样的风险，RUP给出了以下这些主要的策略：
这些策略作为最佳实践在 Rational Unified Process 中经常提到。普遍的讲，这些规则并不局限于软件开发领域，而是更加通用和可以用来在不同的情况下处理问题。在下一节我们将深入的分析每一个最佳实践，讨论它们如何同电影制作相对应。在本文的最后我将提到一些其他的可能从RUP最佳实践中受益的项目类型。 开发迭代 使用瀑布式开发策略时（如图1所示），项目周期是顺序的，它将项目中潜在问题的发现时间推迟到项目完成和测试之时。所有隐藏在需求、设计和编写代码过程中的问题在项目结束时突然的显现出来，的确是很棘手的。而开发迭代允许项目小步进行或增长，逐渐完成整个系统。 如图2所示，RUP中的每一次迭代都要经过这些规程。（RUP中的规程可以被描述为相关的活动、工件或生成的可交付工件。）每一次的迭代都像是一个小的“瀑布”，发现需求中新的部分，提供改正错误的机会并且再次处理上一次迭代的结果。随着不断的迭代，越来越接近最终的产品。 你可能会认为电影制作是一个直进的过程，首先写剧本，然后解决如何将文字表现为动作，拍摄电影并剪辑，最后观看效果。这可能是一个传统的瀑布式方法。但正如这种瀑布式方法在编写软件时是失败的一样，在电影制作时这种方法也会失败。幸运的是（对于常看电影的人来说），电影不是这样拍成的。 电影拍摄的过程是更加迭代性的。演员的工作从剧本开始，由这种交互开始修改。例如，轰动一时的 指环王，它的剧本基于J.R.R. Tolkien的名著，几乎每天都在和演员的交互后进行修改。导演Peter Jackson把这一创新性的过程描述为控制下的混沌。在电影结束之前，剧本被修改了很多次。每一次修改（或迭代）都产生了一个更多的（也是更好的）版本，更加接近最终的版本。 管理项目需求 RUP在软件的开发周期内进行需求管理。这意味着项目需求会被反复和逐渐的确定，证明，评估和改进。功能性的需求用使用用例的术语来描述。软件系统中非常重要的非功能性的需求，也应该被确定和管理。这些需求是不是通过用例来描述的，但他们通常是对系统有很大影响的系统特性，包括系统可用性，可靠性，系统性能和可支持性。 当电影制作人工作时，他们必须考虑迎合观众的需要。他们需要电影激发起什么样的感情？何种体验是观众想要的？他们希望这个故事在哪里上映？电影剧本经过多次迭代，逐渐调整直到导演看来符合这些功能性的需求。 如果软件的功能需求已经在电影上有了对应部分，那么电影有非功能需求吗？答案（并不令人惊讶的）是有的。也许（出于商业上的原因）电影必须能被18岁以下的儿童观看并且不长于120分钟。尽管这些需求并不直接与故事情节相关，它们还是对最终的结果有着潜在的影响——正如计算机系统上必须有非功能性软件需求一样。同样的，这些需求必须在电影制作的过程中确定和提出。 使用基于组件的体系架构 在电影中最显而易见的是场景。一部电影一般由具有连贯情节的许多场景组成，这些场景实现导演的想法。每一个场景都是可替换的，意味着可以替换、修改，甚至删除这个场景而不影响到整个电影（如果导演需要的话）。 不使用基于组件的架构的原则来开发一个很大的计算机应用程序，像现在仍然有的作法那样，就如同仅仅拍摄一次就完成整个电影一样。这就是2002年Aleksandr Sokurov 的电影《俄罗斯方舟》的拍摄手法——整个电影（2小时16分）是一个连续的拍摄过程。由于即便是拍摄一段十分钟的连续场景都是非常困难的，Sokurov的成就的确是很了不起的。回到软件领域内，RUP基于组件的架构使软件开发者不再像英雄一样要完成不可能的需求。 电影和软件组件中另一个并不明显的对应例子来源于 Pixar 近期的成功之作。在制作电脑动画冒险片 Finding Nemo过程中，制作者面临的一个挑战是创造逼真的海浪和潮水。（Finding Nemo 这个故事或多或少的发生在海底世界中。）问题不仅在于准确的模拟海水的运动，更在于捕捉光线的反射，水珠的飞舞，不同类型海水的颜色，等等。在电脑动画中，从来没有人能够做到这种程度。 在项目开始时，设计部门开始对海水的模型作实验。他们进行了广泛的研究，咨询了海洋学专家，勾画了草图和画面，最重要的是，基于他们在这个问题上不断增长的知识创建了原始模型。原始模型经过导演挑剔的目光，这些繁重工作的最后结果是一个设计模板，它涵盖了对电影中各种可能的海水的模拟。这个模板是这部电影架构中的基本组件，其他的组件（模板）解决了不同的问题，比如鱼和植物的运动模式。 在软件开发领域，设计模板告诉设计者怎样处理最重要的问题。没有一个坚实的架构，或设计模板，就不会有项目大幅度的前进。设计者没法满足需求，直到解决了这些问题。 可视化建模 模型的类别描述了用户怎样和系统交互，它经常被作为用例被提及。创建用例模型的要点是减小错误构建系统的风险。在RUP中还有其他类别的模型，每一种用来减小特定的风险。潜在的假设是在系统模型中比在实物中更有利于发现错误和缺点。处理这些模型是犯错的最廉价方式。 通常来说，建模是有些理论性的实践，它有助于我们用简化的方法去理解复杂的系统。原型是一种非常有帮助的建模类型，它可以用于模拟，原理测试，或者设计的特定方面的实际工作。原型用于生成能够说明系统某方面或某种特性的信息。RUP鼓励架构设计组通过创建原型来证明他们的架构概念。 在拍摄电影的前期，只有剧本。但就和软件项目一样，导演需要在完成之前看到电影的样子。如同使用RUP一样，解决方法是建立一个故事的模型。在电影工业中这称为可视化，它可以用不同的技术来实现：传统的方式有演员扮演，木偶扮演，情节串连图板，甚至3D电脑图像。如果使用情节串连图板（顺便说一下，它同样是存在于RUP中的一个概念）的话，这个模型由一系列反映舞台或场景的草图组成。为了进一步增强这一模型的用途，情节串连图板可以被拍成电影并进行修改，可以加上临时的音效和配乐。 在软件开发和电影制作中，建模都是一个动态的，无序的，创性的过程。许多时候需要一次次的迭代进行，直到完成一个令人满意的结果。 持续的质量验证 在起始阶段，重点是理解项目的目的。通过探索需求来实现，确定可能会发生的主要风险以及之后可能会出现问题的地方。在这个阶段结束前需要回答的问题是，这个项目是不是值得去做。进行一个没有价值的项目只能浪费时间，浪费可以投到有价值项目上的金钱。这一类的问题必须尽早的得到处理。 当一个项目需要继续时，就进入了精化阶段。这里的重点是建立一个坚实的设计基础（架构）以及减小项目主要的风险。分析完需求之后，根据对架构影响最大的需求定制架构是很必要的。当架构已经确定并且被证明符合重要需求之后，填充系统功能就很安全了。因此，你必须停留在精化阶段直到你证明了你的架构是有效的。 概括地说，在RUP中，每一次迭代都要检验上一次增加的质量。我们首先检验我们是否已经理解了问题，并且存在一个可靠的业务场景。如果不是，我们或者继续直到达到了这一点，或者停止这个项目，节省时间和金钱。在我们填充系统功能之前，我们同时也检验是否已经建立了一个十分牢固的架构。持续的质量验证最佳实践可以使这样做变得容易。 在电影项目中，导演首先使用模型工具发现分期的故事情节，不吻合的场景，或不适当的节奏等问题。问题较早的发现之后，处理它们就比较简单了。电影制作和软件开发一样，普遍的规则是问题发现越早，修改成本越低。 管理变更 拍一部长片是一项浩大的任务，它包括管理一个巨大的团队和充足的预算。对于这样一个项目来说，和必须要做的变更保持良好的沟通是成功的关键。可以想象，导演希望改进最后一个场景。尽管它在电影的末尾，但改进的需要可以很早就确定下来，因为在每一个级别上都连续的检验质量。编剧必须修改剧本吗？谁去审查和改进影片？这个场景需要重新建模吗？如果是的话，要使用情节串连图板、3D图像、还是塑料模型？布景需要修改，还是重新建一个布景？我们需要寻找新的位置吗？我们需要请特技演员吗？这些变更对我们的预算影响如何？我们需要请求更多的时间和经费吗？这些就是在变更计划时遇到的种种问题，它们必须被处理，处理他们更适合使用迭代的方式。 一个电影项目计划 项目计划像RUP框架一样，很容易适用于软件开发之外的项目。作为一个例子，让我们看一看一个很粗略的电影项目计划。 在这个例子中，RUP规程被电影制作相关活动所取代。开发电影剧本和撰写需求类似，拍摄电影和实施类似，制作电影或多或少和项目管理类似。把时间表分为四个部分，这样在不同的时间将重点放在电影制作不同的方面。我们也能发现这些活动是并行的，通常高效的，跨功能的交换信息和工作成果——就像RUP中那样。 将RUP应用于其它类型的项目
以下是RUP原理可能有帮助的一些项目例子：
小结 |
