软件工程：瀑布模型，像工厂流水线一样把软件开发分层化

初期

边写边改（Code And Fix）模型不能满足复杂软件项目的需要，因为：

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

瀑布模型的诞生

为了解决软件危机中的这些问题，在 1970 年，Winston Royce 博士借鉴了其他工程领域的思想，比如建筑工程，提出了瀑布开发模型，指出软件开发应有完整之周期，并将软件开发过程分成了若干阶段。像瀑布一样，从上往下，完成一个阶段继续下一个阶段。

瀑布模型把整个项目过程分成了六个主要阶段：
一、问题的定义及规划

• 这个阶段是需求方和开发方共同确定软件开发目标，同时还要做可行性研究，以确定项目可
  行。这个阶段会产生需求文档和可行性研究报告。

二、需求分析

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

三、软件设计

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

四、程序编码

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

五、软件测试

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

六、运行维护

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

也是从那时开始，有了“软件生命周期”(Software Life Cycle,SLC) 的概念：软件生命周期是软件的产生直到报废或停止使用的生命周期。而像瀑布模型这样，通过把整个软件生命周期划分为若干阶段来管理软件开发过程的方法，叫软件生命周期模型。

瀑布模型的优缺点

用瀑布模型开发软件，就像建筑工程里，盖房子一样简单和自然。每个阶段都有侧重的事情，就像需求阶段专注于搞清楚需求，编码阶段专注于实现。

最重要的是，这种编码前先设计、编码后测试、整个过程重视文档的方式，开发出来的产品，质量相对是有保障的。

瀑布模型的出现，也解决了软件项目开发中的几个重要问题。

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

但用瀑布模式开发，也存在一些问题。最大的问题就是不能及时响应需求变更，越到后期变更代价越大。另外，通常要到最后阶段才能看到结果是什么样子。

鉴于瀑布模型存在的这些问题，后来又有很多人提出了其他的软件生命周期模型，比如快速原型开发模型、增量模型、迭代模型，以期保留瀑布模型的这些优点，克服瀑布模型中存在的问题。