一、瀑布模型
1970年温斯顿.罗伊斯提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型
瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落
瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动
从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来
对于经常变化的项目而言，瀑布模型毫无价值
1、阶段间具有顺序性和依赖性
该阶段具有两重含义
必须等前一阶段的工作完成后，才能开始后一阶段的工作
前一阶段的输出文档就是后一阶段的输入文档，因此只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果
2、推迟实现的观点
对于规模较大的软件项目来说，往往编码开始的越早，最终完成开发所需时间越长。因为前面阶段的工作没做或做的不扎实，过早地考虑进行程序实现，往往导致大量返工，有时甚至发生无法弥补的问题
瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，分析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现
清楚的区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想
3、质量保证的观点
为了保证所开发的软件的质量，在瀑布模型的每一个阶段都应坚持两个重要做法
每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务
每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误
传统的瀑布模型过于理想化，实际的瀑布模型是带"反馈环"的。如图所示（图中实线箭头表示开发过程，虚线箭头表示维护过程），当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品后再回来继续完成后面阶段的任务
瀑布模型是文档驱动的模型，遵守这个约束可使软件维护变得比较容易一些，从而显著降低软件预算
优点：
为项目提供了按阶段划分的检查点
当前一阶段完成后，您只需要去关注后续阶段
可在迭代模型中应用瀑布模型
缺点：
不适合需求模糊或需求经常变动的系统
由于开销的逐步升级问题，它不希望存在早期阶段的反馈
在一个系统完成以前，它无法预测一个新系统引入一个机构的影响
在用户可能需要较长等待时间来获得一个可供使用的系统，也许会给用户的信任程度带来影响和打击
最终产品往往反映用户的初始需求而不是最终需求
对项目而言，是否使用这一模型主要取决于是否能理解客户的需求以及在项目的进程中这些需求的变化程度；对于经常变化的项目而言，瀑布模型毫无价值，可以考虑其他的架构来进行项目管理，比如螺旋模型
瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：
各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量
由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险
早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果
