哪些是我们要保留的相同内容？
从瀑布法到RUP，尽管我们改变了许多，但是我们并没有全部摒弃传统的设计方法。
对其它活动的关联。当我们将项目开发从瀑布法转到RUP方法时，有许多支持项目和子项目也在同时进行。在我们初始的瀑布法项目中，我们有了一个关键路径，将我们的项目中的关键活动与其它项目中的关键活动关联在一起。当把我们的项目转为RUP后，我们会记录下其它项目中关键活动的日期，然后在我们的项目中创建出与那些活动紧密相关的新活动。
角色与资源。在项目中我们扮演着同一个角色并且保持同样的资源，尽管项目的结构已经发生了变化。我们仍然想用相同的人员类型得到相同的设计、开发和测试量。还有，一些与应用程序开发无关的角色（例如，基础结构的开发）也被保留下来。
交付物以及其它文档。我们希望在瀑布项目中计划产生的文档在RUP项目中仍旧产生。不管我们使用什么方法，顾客仍然想要关键可交付物（例如，主测试计划），而不管我们的方法是什么。同样地，我们创建了一个文档，让团队为每个项目准确地创建基础结构，如何配置服务器、软件，等等，无论是瀑布法还是RUP方法，我们都要做这一步工作。
所需工作量。尽管由于从瀑布法到RUP方法的改变导致了构建解决方案的方法发生了变化，但是无论使用哪一种方法，完成相同的工作所需的工作量并没有改变。
结果是什么？
当从瀑布法改为RUP方法后，我们发现：
. RUP帮助我们管理客户的需求，尽管客户也许还不清楚他们最初提出的每一个需求。我们需要牢牢地管理变更并且增加额外的阶段用于满足新的需求。时间箱和多个迭代帮助我们管理变更。在精化阶段，多个迭代意味着如果因为时间箱而无法在一个迭代中完成任务，但客户仍旧想要进行这个任务，我们就要把它转移到另一个迭代中去。同样地，在精化阶段，如果我们发现项目中包含了比计划还要多的任务，我们就将把一些任务转移到其它迭代中去。我们甚至可以增加额外的迭代，如果客户觉得这样做是值得的。如果客户被预算所限制，他们将不会再继续增加迭代，因为他们已经从完成了的迭代中获得重要的价值。
. 在构建阶段中的多个迭代也会帮助进行需求管理。通过使用迭代进行应用程序的开发，我们可以让客户确认他们在每个迭代中的要求。如果应用程序没有和当初设想的一致，我们还可以在下一个迭代中将它改变。这对我们的管理也有所帮助。
. RUP帮助我们自始至终中地保证质量。因为我们在每一个迭代结束后都发布代码，所以RUP让测试变得简单，并且降低了在项目的后期发现重大问题的概率。
. 可视化建模帮助客户发现什么是他们想要的以及帮助我们了解什么是客户想要的。间接地，它还帮助我们拉近了与客户之间的关系。客户觉得可以更进一步参与到应用程序的开发中去，应用程序能够如期完成并且包含全部他们想要的东西，这些都让客户感到非常得满意。
. 采用组件架构使我们可以交付独立的、功能性软件用于较早的测试。它在帮助开发团队进行任务分解和分配工作时也显得十分有用。
你应当在何时考虑使用RUP方法替代瀑布法？
以下是在何时用RUP方法替代瀑布法的一些建议：
1. 使用瀑布法无法满足客户时。例如，客户对要花费很长时间才能看到结果感到不满时。或者客户抱怨他们需要更加灵活的应用程序，或者他们想在开发的早期就可以解决风险问题。或者当客户想在项目的开发初期就看到它的组成部分，不是简单的原型或者证实可行的概念，而是即将成为全部应用程序一部分的实际项目代码，RUP 就为以上这种开发方式提供了框架。
2. 客户当前已经普遍使用一个或多个Rational工具。如果真是如此，那么他们应经看到了IBM Rational软件的价值以及这种迭代方法所带来的好处了。你可以告诉客户，在不久的将来使用RUP可以使这些工具变得更加有价值。
3. 软件开发确实是项目的核心部分，并且/或者软件是面向对象的。如果你的项目主要是网络的重新设计或者是一个只有少许软件开发的服务器固化的项目，用传统的瀑布方法也许会更好。同样地，如果软件开发大部分是脚本或者过程语言的话，使用传统的方法就足够了。
4. 客户不确定他们的要求。也许是由于一些还未解决的争论，或者相关的项目还未着手动工，或者有一些迟滞或未确定的区域，这些因素导致全部的要求不能在同一阶段同时聚集在一起。
如果这些问题你的回答大部分是"是"的话，你就应当在项目中使用RUP了。
你首先应当作的事情是什么？
. 找一个RUP的高手来帮助你。 RUP的专家在从瀑布法转换到RUP的过程中可以为你进行指导。他们在使用RUP方面很有经验，并且可以帮助你找出且应对转换过程中出现的挑战。
. 了解RUP和迭代开发的好处。当你进行转换时，你也许会问：只是为了变化而变化么？所以，学习RUP的课程，利用现有的知识(这也是另一个RUP专家可以帮助的领域)，同时阅读文章，尤其要对那些成功使用RUP的个案进行研究。
. 利用集成的IBM Rational工具的优势。RUP构架通过工具指南来指导如何使用这些工具。尽管 Rational 工具和方法可以彼此相互独立使用，但当它们综合在一起使用的时候会变得极为强大，毕竟整体大于部分的总和。
. 采用 RUP 最优方法并且使用RUP作为导向重构你的项目计划还不够。为了取得成功，你还需要RUP作为导向 1 并且你要使用RUP的最优方法获得最大的收益。
. 了解客户以及客户企业文化以便成功地完成RUP项目。一些客户也许不想采用全部的或者部分RUP，尽管种种迹象表明他们可以获得利益。要对这些事情敏感从而采取办法。
结论
关于为什么瀑布法成为我们项目开发的一部分，这里有许多原因。偶尔，我们会遇到这种情况，一个使用瀑布法的团队在项目开发中竞标并且中标。有些时候，IT设计师使用相同的设计方法来开发新项目。也有时，客户想要用瀑布法运行他所有的项目，或者含蓄地使用他们所惯用的方法。在以上这些情况中，瀑布法多少显出了一些问题，如果客户坚持采用这种方法，我们也将全力照做。
就算采用一个好的瀑布法计划，但是如果换作使用 Rational Unified Process将会带来更多的好处。为了实现这个改变，你需要找到一个标记，用于说明客户和项目对于改变都是好的候选者。如果有这种迹象，在你进行项目之前，它将帮助你了解你应当改变什么以及你应该留下些什么。然而，作为明智的改变，你可以在项目中结合使用这两种方法的精华，这样就可以获得更好的结果。
