业内权威人士 Craig Larman 和 Philippe Kruchten 所撰写的论文 How to fail with RUP: Seven Steps to Pain and Suffering 的确令人大开眼界。如果您认为您所在的机构正在使用 Unified Process(UP) ，那么该文可能会使您认识到，您所遵从的只是 UP 的表层，而不是 UP 的精神。该文使我认识到， UP 和 Rational Unified Process(RUP) 比大家公认的更为灵活。即使您并不使用 UP 或 RUP ，也应该阅读一下该论文。
下面是从该文中引用的可能“导致苦难”的内容。
首先是定义大部分的软件要求，这暗含着一个假定：用户可以很好地定义他们未曾见过的产品的要求。
这是许多项目所采用的模式。因分析而造成的耽搁将项目置于极大的危险之中。性能要求将不断细化。最终每个细节都非常精确。而您还不知道，情况已经改变了！
在还没有启动项目时进行可信的评估和详细的规划
如果没有令人信服的评估和详细的规划，就得不到预算批准，这样问题就产生了。没有预算，就没有项目！那么如何得出评估呢？如何产生详细的规划呢？这些问题很难回答。
创建大部分——甚至是全部的—— RUP 工件。
使项目和流程更加正式，甚至提交给项目委员会。
UP 流程描述了 100 多个工件，这些工件由 100 多个活动创建。 UP 流程是很古板的，也就是通常所说的注重格式。创建工件是一回事，维护它们则完全是另一回事。多数项目都有许多过时的（和错误的！）工件，他们为此而浪费了许多的时间和精力。您的项目认真地维护了用例吗？域模型呢？单元测试呢？
您可能认为细化 (elaboration) 阶段只创建了原型。实际上，生产质量的核心——架构元素——也应该在细化阶段编写。
在我的咨询工作中，我总是遇到这些情况。所创建的原型和其它东西很少或者根本没有瞄准现实系统。并不是原型不重要；问题是对原型的实现的错误理解。在原型和“真正的”应用程序之间还有一道鸿沟。对原型投入了大量的时间和精力，但是却都浪费了。我们使用的不再是迭代构建，而又回到了最原始的方法。
对照该论文所描述的七个步骤，看看您是否使用了这些通向苦难的步骤中的某些（无论您使用何种方法或过程）。请与我联系，分享您开发项目时的轶事和发现。
（T111）
