即使到了今天，在第一轮警报响起的十多年之后，仍有不少咨询公司、管理者、教师和作家们把瀑布型生命周期或观点当作一门优越的技术来提倡。克服有意识或无意识地在RUP和迭代式开发之上叠加瀑布价值观，是一个项目团队面临的最大挑战之一。真正掌握了RUP的一个最深刻的变化不在于诸如写用例、对象建模等技能上，也不在于在学习RUP提供的许多工件和活动上(所有这些都是可选的)，而在于对瀑布思维的根本态度和期望的转变。下面是RUP事实中四个典型的错误。
错误一：在RUP的阶段上叠加瀑布型阶段
RUP开发周期由四个阶段组成(起始、细化、构建和移交)，导致RUP实施失败的最常见策略就是把这四个阶段与瀑布阶段(需求、分析设计、实现和部署)直接等同起来。在此对RUP的四个阶段作一简短描述。
1. 起始：制定系统的业务依据；探查一小部分(大概占10%)但很重要的需求，以便对项目范围的大致规模和关键风险有比较准确的把握，并决定是否值得为细化阶段拨付资金。
2. 细化：迭代地构建核心架构，消除项目的主要技术风险。所谓的构建架构，是指真正地编程、集成和测试——决不是纸面上的练习或可抛弃的原型。为了达到这一目的，可能需要迭代地详细探查绝大部分的需求(可能占到80%)，并同时并行地实现系统中有风险的核心部分。在这一阶段中，通过反馈-适应周期不断地评估部分实现，需求则可能发生显著的变化。请注意与经典的瀑布式需求定义不同，RUP的绝大部分需求是在与开发核心架构的工作并发的过程中精化的，而且从实际的开发当中获得了反馈。在此阶段，还要决定是否为项目的最终完成拨付资金。
3. 构建：迭代地构建在细化阶段尚未完成的内容，进行迭代集成和质量保证，为部署作准备。在这一阶段需求变化较少，因为大部分需求的不稳定性已经在前面阶段得到了迭代式的澄清。
4. 移交：完成Beta测试，解决遗留问题并部署系统。
错误二：迭代不是太长就是太短
如果把计划的平均迭代长度定为6～12个月，在绝大多数情况下是很不适宜的。RUP有一条惯例：“在理想情况下，一个迭代的工期应该是2～6周。”迭代式开发与RUP方法的精华在于通过小规模的工作步骤逐步获得一个可能不完善的实现，接着快速集成，进行QA和测试，快速获得反馈，然后基于该反馈调整需求、设计和实现。短小的步骤、反馈和调整是关键的思想。过长的迭代则达不到这种效果，因而是使RUP实施失败的一个良好策略。
错误三：在设计前磨亮需求
迭代式方法允许有指导方向的试验和创造，而瀑布方法迫使我们从一开始就必须做到聪明绝顶，这种在没有反馈的情况下，把绝大部分需求定义并稳定下来的想法与软件开发的现实不符。
假设用瀑布方法建议我们购买软件的方式来购买衣服，那么，我们必须要在看不见能得到什么的情况下来确切地描述我们需要什么，甚至还不能先试穿一下，看看穿上这件衣服效果如何。我们必须要在真正收到这件衣服的几个月甚至几年之前，精确地指明每一个测度。一旦我们改变了主意，或者长胖了、变瘦了，那只有老天来帮忙了。不错，这恰恰就是瀑布方法的解决之道——在设计或实现之前确定绝大部分的需求。如果我们连买衣服都不想用这种办法，那么，凭什么让我们相信它对软件开发也是有效的呢？
错误四：项目刚开始就期望获得可信的估算和详细的计划
一位石油业高层主管对您说：“我听说FooBarKhan那里有石油，我太想要了！请您赶紧用一周的时间写一份报告，告诉我那里有多少石油，在那里建油田需要花多少钱、多少时间、多少资源。”在石油业中，这样的场景是很滑稽的，为什么同样的做法反而被软件工业接受了呢？理智的石油人士知道：没有预先在试验性钻探上大量投入是不可能获得答案的。只有通过调查发现了储量和地质情况的真相，作出估算或初步的计划才有可能。可是，在同样的不确定性和高复杂度的情况下，我们却奢望没有投入实际的“试验性钻探”调查就能对软件项目进行估算和计划，这不是很可笑吗？
仅仅因为我们能够作出计划显示出我们正取得进展，并不意味着我们真的能够做到。在没有获得任何关于未完成工作量的真实信息的情况下，在日程表上填上精确的日期是容易的。如果我们依赖完美的计划来交付一个项目，那么失败将是注定的。迭代方法允许我们边干边学，随着迭代的进行，我们获得了有关真实需求的更多信息，对真正的风险有了更好的了解，对我们应对项目的各项挑战的能力也有了更为清晰的认识。
