软件工程 - 瀑布模型

阅读此文章大约需要3分钟

一、关于瀑布模型

瀑布模型，像工厂流水线一样把软件开发分层化，可以这么说：瀑布模型算是现代工程的起源，软件工程的发展，很大部分都是构建于瀑布模型的基础之上。
瀑布模型是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始查到产品开发和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一阶段并进行适当的修改，项目开发进程从一阶段“流入”到下一个阶段，这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生成以及市场销售构建瀑布模型。
瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试、运行和维护等六个基本活动，并且规定了他们自上而下、相互衔接等固定次序，如同瀑布流水逐级下落。

二、瀑布模型的流程

1.问题的定义及规划
这个阶段是需求方和开发放共同确定软件开发目标，同时还要做可行性研究，以确定项目可行。这个阶段会产生需求文档和可行性研究报告。

2.需求分析
对需求方提出的所有需求，进行详细的分析。这个阶段一般需要和客户反复确认，以保证能充分理解客户需求。最终会形成需求分析文档。

3.软件设计
根据需求分析的结果，对整个软件系统进行抽象和设计，如系统框架设计，数据库设计等等。最后会形成架构设计文档。

4.程序编码
将架构设计和界面设计的结果转换成计算机能运行的程序代码。

5.软件测试
在编码完成后，对可运行的结果对照需求分析文档进行严密的测试。如果测试发现问题，需要修复。最终测试完成后，形成测试报告。

6.运行维护
在软件开发完成，正式运行投入使用。后续需要继续维护，修复错误和增加功能。交付时需要提供使用说明文档。

三、为什么选择瀑布模型

随着软件开发的需求越来越多，功能越来越复杂，从事软件开发的人员水平也参差不齐，这种落后的软件生成方式已经无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题，像这种边写边改的开发模式，为什么说不能满足复杂软件项目的需要呢？主要有几方面的原因：

• 整个开发过程不可控，想基于这种开发模型做项目计划太难；
• 项目的人数多了后，无法有效分工协作；
• 项目开始的时候对需求几乎没有进行有效分析，对需求的理解容易出现偏差，后期导致很多返工；
• 项目编码完成后，没有有效测试，运行时bug非常多。

瀑布模型在提出后，因为其简单可行，切实有效，马上就在很多软件项目中应用起来，一直到2000年前后，都是主流的软件开发模型，即时到现在，你也能在很多软件项目中看到它的影子，有了软件生命周期的概念。

四、瀑布模型优缺点

优点：

• 简单易行。
• 可以按照阶段检查，能及时发现问题。
• 前一个阶段完成后，就可以重点关注下一个阶段。
• 有很好的分工协作。
• 对质量有保障。

缺点：

• 难以响应需求的变更，当需求发生改变时，越到后期代价越大。
• 工作量分布不均衡。例如前期开发，测试人员无法参与，而后期开发，测试人员又特别忙碌。
• 前期进度受阻，会一直压缩后续阶段时间，导致延期或影响质量。
• 一直到最后阶段才能看到结果。

总结、

从瀑布模型提出将近50年过去了，虽然现在大家一提出瀑布模型，似乎已经成了落后的代名词，但在当时是有划时代意义的。如果类比一下，我觉得瀑布模型的价值相当于工业界第一次提出流水线作业。
同理，瀑布模型的出现，也解决了软件项目开发中的几个重要问题。

• 让软件开发过程有序可控。瀑布模型的每个阶段都有明确的任务，每个阶段都有明确的交付产物，都有相应的里程碑。这些让整个过程更可控，而且能及早发现问题。
• 让分工协作变成可能。瀑布模型的六个阶段，也让软件开发产生相应的基础分工：项目经理、产品经理、架构师、软件工程师、测试工程师、运维工程师。
• 质量有保障。瀑布模型每个阶段都需要交付相应的文档，而文档的撰写和评审，可以帮助在动手之前把问题沟通清楚，想清楚。瀑布模型在编码结束后，会有严密的测试，只有测试验收通过后，才能上线发布，这些措施都让软件的质量更有保障。