纯瀑布模型——读书有感+实践 = 有感（一）

对于那些已经被充分理解但很复杂的项目，采取瀑布模型比较合适，因为你可以用顺序的方法处理复杂的问题。在质量需求高于成本需求和进度需求时，它表现的尤为出色。
当开发队伍的技术力量比较弱或者缺乏经验的时候，瀑布模型更为合适，因为它给项目提够了一种结构以帮助你努力减少浪费。
但是它的缺点也显而易见：

例如：如果你做的是辆汽车。当开发到最后的时候，突然间用户告诉你还要加一个自动打开倒车灯的功能，在他看来这只不过是一个小小的要求......可是对于我们而言要花费很昂贵的代价弥补这些遗漏。

而对于软件任务进行说明的人，通常不是计算机专家，他们很可能一直等到看见可运行的产品，才想起来忘记了一些看起来很简单的事情，如果你采用瀑布模型，遗漏需求可能是代价高昂的错误。你一直要等到开始测试的时候才会发现一些需求忘了或是错了。

因此瀑布模型最主要的问题是缺乏灵活性。你必须在项目开始的时候说明全部需求。这一般来说是很困难的。而且前期花费的时间可能是几个月或者更长......


瀑布模型

软件概念——
    需求分析——
        架构设计——
            详细设计——
                编码和调试——
                    系统测试——

=============================================================
*:有人责备说瀑布模型不允许人们返回去改正错误，这是完全不对的。倒退不是不可能，只是很困难。