传统瀑布模型：

 

 瀑布模型是所有模型的基础框架

特点：

线性的开发流程，不能够应对需求的变化。

必须等前一阶段的工作完成后，才能开始后一阶段的工作

前一阶段的输出文档就是后一阶段的输入文档，因此只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果

为了保证所开发的软件的质量，在瀑布模型的每一个阶段都应坚持两个重要做法

每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务

每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误

缺陷：

测试被后置（风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会，有足够的时间预留给测试活动，否则将导致测试不充分，从而把缺陷直接遗留给用户）

瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到.

适用场景：

需求固定的小项目。

需求易于完善定义且不易变更的软件系统

实际瀑布模型

        传统的瀑布模型过于理想化，实际的瀑布模型是带"反馈环"的。如图所示（图中实线箭头表示开发过程，虚线箭头表示维护过程），当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品后再回来继续完成后面阶段的任务

优点：

为项目提供了按阶段划分的检查点
当前一阶段完成后，只需要去关注后续阶段


缺点：

不适合需求模糊或需求经常变动的系统
由于开销的逐步升级问题，它不希望存在早期阶段的反馈
在一个系统完成以前，它无法预测一个新系统引入一个机构的影响
在用户可能需要较长等待时间来获得一个可供使用的系统，也许会给用户的信任程度带来影响和打击
最终产品往往反映用户的初始需求而不是最终需求（这将导致失去市场，别的公司开发的又快有好，用户都被抢走了）