1．瀑布模型
最早出现的计算机软件开发模型就是瀑布模型，在软件工程中占有非常重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回上一页面，甚至更前面的活动。受此所限，对于那些变性较大的项目来说，瀑布模型没有多少价值。
“瀑布模型”是由温斯顿·罗伊斯于1970年提出来的，直到20世纪80年代早期，仍然是唯一被广泛采用的软件开发模型。
此“瀑布模型”的核心思想是按工序将问题简化，将功能的实现与设计分开，更有利于分工合作，也就是采用结构化的分析与设计方法把逻辑实现与物理实现分开。将软件生命周期划分为制订计划、需求分析、软件设计、程序编写、软件测试和运行维护等6项基本活动，并且规定它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
从其根本来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是“瀑布模型”开发名称的由来。
“瀑布模型”有以下优点：
（1）为项目提供了按阶段划分的检查点；
（2）当前一阶段完成后，只需要去关注后续阶段；
（3）可在迭代模型中应用瀑布模型。
增量迭代应用于“瀑布模型”。每次迭代产生一个可运行的版本，同时增加更多的功能。每次迭代必须经过质量和集成测试。
然而，“瀑布模型”也有如下缺点：
（1）在项目各个阶段之间极少有反馈；
（2）只有在项目生命周期的后期才能看到结果；
（3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
尽管“瀑布模型”引起了很多批评，但是它对于那些类型较多的项目来说依然是很有效果的，如果进行得当的使用，不仅可以节省大量时间，而且还会省下很多不必要的资金。
在“瀑布模型”中，软件开发的各项活动应严格按照线性方式进行，正在进行的活动必须接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下去，否则返回修改。“瀑布模型”非常强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太过理想化，已不再适合现代的软件开发模式，几乎已被业界抛弃，其主要问题在于：
（1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
（2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而在一定程度上增加了开发的风险；
（3）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
