为什么瀑布法难以成功？

瀑布法，和其变种V模型等等，总是把软件过程分成很多个阶段，并假设，我们只要在需求阶段进行分析，在设计阶段进行设计，只要在本阶段能够产生出正确无误的文档，就能保证软件项目的成功。

然而，即使我们假设，能够得到一份非常正确和完备的，覆盖所有需求和隐含需求的设计文档 - 虽然这在现实中是不可能发生的 - 瀑布法仍然难以保证软件项目达到它真正的目标。因为，瀑布法不能够保证各阶段的文档能够被正确的转换。各阶段的文档转换必须依赖于对需求和系统的理解，并不存在一种文档间或文档与代码间完全映射的表示法来帮助我们进行这种转换。瀑布法假定我们可以完全不需要其他任何东西，只根据需求文档就写出完备的覆盖所有需求的设计文档；同样的，瀑布法假定编程人员可以对系统和需求一无所知，只要根据一份详细设计文档就能把正确的代码写出来。但是，任何一个了解软件开发的人都不会乐观的认为这种假设真的行得通。这种转换步骤耗费大量时间并且会引入错误，并且我们没有任何的测试手段来对这种转换过程进行测试，从而保证其正确性。

另外一个重要原因就是我们最初的假设并不可能存在。不可能在分析设计阶段结束后就得到一份完备的毫无错误的分析设计文档。软件项目本质上就是管理复杂性。瀑布法承认这种复杂性，也通过划分阶段来分散复杂性，但正是这种对各个阶段的严格划分，不但提高了过程的复杂性，也引入了一个最大的隐患，即无法在分析设计阶段对其结果进行测试。我们已经有了很多行之有效的手段对我们的代码，也就是软件产品的最终实体进行测试以保证其正确性，可是对分析设计文档的测试，只能停留在参与者互相的评审和想像中，只能进行在大脑构建出来的一个虚拟的环境里。瀑布法乐观的认为，运行在计算机中的01序列可以将这种空中楼阁作为建立的基础，而实际的结果往往是无根之木，无源之水。