关于瀑布模型

在二三十年前，计算机软件的开发技术很落后，需求的变更，代码的重构，成本很高，于是有了在软件开发初期就把建模设计细节梳理清楚的想法，于是瀑布模型就诞生了，它赋予了软件成本与收益的平衡。

瀑布模型，也叫经典生命周期，是一个软件生命周期模型，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，项目开发进程是从一个阶段“流动”到下一个阶段，所以被称为“瀑布模型”。

1970年温斯顿·罗伊斯提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。

瀑布模型的核心思想将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

瀑布模型的优点：

1. 为项目提供了按阶段划分的检查点。
2. 当前一阶段完成后，只需要关注后续阶段。
3. 可在迭代模型中应用瀑布模型。
4. 提供的模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有共同特点。

在瀑布模型中，原则上是直到上一个阶段完成并经过评审下一阶段才可以启动。在实际过程中，这些阶段通常是重叠和彼此有信息交换的。在设计阶段可能发现需求中的问题，在编程阶段发现设计中的问题。软件过程不是简单的线性模型，包括了开发活动的多个反复，且反复过程的费用成本和时间成本都是很高的。

在过去的五十多年中，对瀑布模型的批评使它最热情的支持者都开始质疑其有效性。那是因为瀑布模型是由文档驱动，在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的。瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。也不适合需求模糊的系统。

人们遇到的问题大致同时也是瀑布模型的些许缺点：

1. 实际的项目很少遵守瀑布模型提出的顺序，随着项目组工作的推进，变更可能造成混乱。
2. 瀑布模型要求客户明确需求，但客户通常难以清楚地描述所有的需求，所以很多项目在初期就存在许多不定因素。
3. 客户只有在项目接近完成时才能得到可执行的程序。
4. 由于任务之间的依赖性，开发团队一些成员要等待另一些成员工作完成，等待的时间可能就超过了生产的时间。

 瀑布模型强调文档的作用，并要求每个阶段都要仔细验证，但这种模型的线性过程太理想化，已经不适合现代软件开发模式。如今情况完全不同技术进步，我们在面对需求变更的时候，是完全有办法用较低的成本控制风险的。现代软件系统需求的复杂性和不确定性越来越高，在软件开发的初期就将所有细节考虑清楚几乎不可能。顺应需求诞生了更多有价值的软件模型，瀑布模型似乎已成为了过去式。