2.2 瀑布模型
1970年，温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到20世纪80年代早期，它一直是唯一被广泛采用的软件开发模型。直至今日，该模型仍然具有强大的生命力。
瀑布模型（Waterfall Model）又称流水式过程模型，它形象地用阶梯瀑布描述，水由上向下一个阶梯一个阶梯地倾泻下来，最后进入一个风平浪静的大湖，这个大湖就是软件企业的产品库，如图2-1所示。
图2-1 瀑布模型示意图
1.模型的本意
在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前阶段的活动接受上一阶段活动的工作结果，实施完成所需的工作内容。需要对当前阶段活动的工作结果进行验证，如果验证通过，则该结果作为下一阶段活动的输入，继续进行下一阶段的活动，否则返回上一阶段修改。
在瀑布模型中，软件生命周期的过程是由需求、设计、编码、测试、发布等阶段组成的，把每个阶段当作瀑布中的一个台阶，把软件生存过程比喻成瀑布中的流水，软件生存过程在这些台阶中由上向下地奔流。瀑布模型规定了各项关键软件工程活动，自上而下、相互衔接、逐级下落，如同瀑布的固定次序。当发现某一阶段的上游存在缺陷时，可以通过追溯，予以消除或改进，但要付出很大代价，因为水要在瀑布台阶上倒过来向上流动，需要消耗很多能源或动力。
由瀑布模型可知，项目经理或软件管理人员，只要控制好每级台阶的高度和宽度，在每个台阶处设立里程碑或基线，并组织好对基线的评审与审计，就可以控制好项目的开发成本、进度和质量。
早期的面向过程的结构化分析、设计、编码、测试、维护方法，很适合瀑布模型。或者说，瀑布模型适合于结构方法，即面向过程的软件开发方法。
2.模型的特点
瀑布模型将软件开发过程规划为“需求—设计—编码—测试—发布”的线性过程，其最大特点就是简单直观。也就是说，必须首先把软件要干的每一件工作都分析得彻彻底底，再对每一个模块、每一个接口，事无巨细地都设计得非常完美，才开始编码工作，并且编码时就像在对着图纸砌模型，根本不用再回头做任何修改。当然，需要把所有代码都写完以后才开始测试。它完全忽视了软件开发过程的动态变化。瀑布模型的特点是：
（1）里程碑或基线驱动，或者说文档驱动。
（2）过程逆转性很差或者说不可逆转，根据上游的错误会在下游发散性传播的原理，逆转将会延误工期，增加成本，造成重大损失。
3.选择模型的条件
不是任何软件都适合采用瀑布模型，软件项目或产品选择瀑布模型，必须满足下列条件：
（1）在开发时间内需求没有或很少变化。
（2）分析设计人员对应用领域很熟悉。
（3）低风险项目（对目标、环境很熟悉）。
（4）用户使用环境很稳定。
（5）用户除提出需求以外，很少参与开发工作。
尽管上述条件比较苛刻，但是软件企业在开发新产品或新项目时，往往还是采用瀑布模型。系统软件和工具软件的开发，也常常采用瀑布模型。
4.模型的优点
首先，瀑布模型这个阶段性的软件开发模型制定了以下规则：每个阶段都有指定的起点和终点，过程最终可以被客户和开发者识别（通过使用里程碑），在编写第一行代码之前充分强调了需求和设计，避免了时间的浪费，同时可以尽可能保证实现客户的预期需求。
需求和设计阶段能提高产品质量，因为在设计阶段捕获并修正可能存在的漏洞要比测试阶段容易得多，在组件集成之后来追踪特定的错误要复杂很多。最后，因为前两个阶段生成了规范的说明书，当团队成员分散在不同地点的时候，瀑布模型可以帮助实现有效的知识传递。
瀑布模型的优点是：开发阶段界定清晰，便于评审、审计、跟踪、管理和控制。它一直是软件工程界的主流开发模型。
5.模型的缺点
瀑布模型的缺点是：传统的组织方法是按顺序完成每个工作流程，即瀑布式生命周期。瀑布只能一个个台阶地往下流，不可能倒着往上流，这就是它致命的缺点。瀑布式生命周期通常会导致项目后期，如实施阶段（当第一次构建产品并开始测试时）出现“问题堆积”，在整个分析、设计和实现阶段隐藏下来的问题，会在这时逐步暴露出来。更可怕的是，错误的传递会发散扩大，比如，在需求阶段中的一个错误或遗漏，在编码阶段可能引发几十个错误或遗漏。因为项目有较长的开发周期，其进度会被严重拖延，最终导致成本和质量的失控。世界软件巨人微软公司和IBM公司，有时也不可避免地会犯这种错误。尽管如此，直到今天，该模型仍然是应用最广泛的模型之一。
为了克服该模型的缺陷，微软公司采取严格的里程碑管理制度。CMM/CMMI则采取阶段评审和不符合项（Noncompliance Items）动态跟踪制度，只有前一阶段的不符合项全部改正后，才允许开发人员进入后一阶段的工作。所谓不符合项，是在评审中发现的问题项，它与Bug既有联系，又有区别。对于这些不符合项，软件管理部门要列出表格，记录在案，确定责任人，限定改正时间，动态跟踪到底。