【软件工程】瀑布模型的价值
瀑布模型是最早出现的软件开发模型，提供了软件开发的基本框架，为后续出现的开发模型奠定了基础。
从1970年被温斯顿·罗伊斯（Winston Royce）提出后，直到80年代早期，一直是被广泛采用。现在仍旧是比较常见的开发方式。瀑布模型算是现代软件工程的起源。软件工程的发展，很大部分都是构建于瀑布模型的基础之上的。
如果连瀑布模型这种软件工程的理论基础都没能好好得掌握，那么恐怕自己的编码就是边改边写类型了。想想看边改边写的方式能够完成大型项目的开发吗？实际上，在瀑布模型还没有提出来之前，有大型软件需求的出现，却没有大型项目开发的指导理论而加剧第二次软件危机。
瀑布模型就像工厂中的流水线，它把整个项目过程分成了六个主要阶段：
一、问题的定义及规划 这个阶段是需求方和开发方共同确定软件开发目标，同时还要做可行性研究，以确定项目可行。这个阶段会产生需求文档和可行性研究报告。
二、需求分析 对需求方提出的所有需求，进行详细的分析。这个阶段一般需要和客户反复确认，以保证能充分理解客户需求。最终会形成需求分析文档。
三、软件设计 根据需求分析的结果，对整个软件系统进行抽象和设计，如系统框架设计，数据库设计等等。最后会形成架构设计文档。
四、程序编码 将架构设计和界面设计的结果转换成计算机能运行的程序代码。
五、软件测试在编码完成后，对可运行的结果对照需求分析文档进行严密的测试。如果测试发现问题，需要修复。最终测试完成后，形成测试报告。
六、运行维护在软件开发完成，正式运行投入使用。后续需要继续维护，修复错误和增加功能。交付时需要提供使用说明文档。
注意箭头指向，这个是可以进行迭代的。
虽然现在瀑布模型已经不是最主流的开发模式，但是因为不管什么软件项目，不管采用什么开发模式，有四种活动是必不可少的，那就是需求、设计、编码和测试，而这四项活动，都是起源自瀑布模型，也是瀑布模型中核心的部分。学好瀑布模型，才可以帮助你更好的理解这些内容。
假如你要建立一个二手交易网站
问题的定义及规划：确定事什么样的二手交易网站，也就是比较明确的最终目的。什么时间上线，像需求分析， 软件设计， 程序编码， 软件测试 这四个阶段分别大致分配多长时间？
需求分析阶段：充分了解要做一个什么样的二手交易网站：调研一下类似网站的情况，明确自己做的这个二手交易网站的功能都是有哪些，用原型工具设计了网站的原型，原型可以做得很简陋，但是从原型可以看出来，项目要做成什么样子，便于确认需求。需求确认之后，将原型设计落实到文档，将整个网站划分成不同的功能模块，例如支付、登录、添加购物车等，确定每个功能模块需要哪些功能。
软件设计：接着架构师开始做架构设计，UI 设计师开始设计 UI，测试经理开始针对产品设计文档写测试用例，产品经理还要进一步设计交互。
程序编码，软件测试 ，运行维护 这三个就是技术能力了
当然整个过程不可能一帆风顺，伴随着迭代。
瀑布模型的缺点：
- 难以响应需求的变更，当需求发生改变时，越到后期代价越大。
- 工作量分布不均衡。
例如前期开发、测试人员无法参与，而后期开发、测试人员又特别忙碌。 - 前期进度受阻，会一直压缩后续阶段时间，导致延期或影响质量。
- 一直到最后阶段才能看到结果。
优点：
- 简单易行。
- 可以按照阶段检查，能及时发现问题。
- 前一个阶段宗成后，就可以重点关注下一个阶段。
- 有很好的分工协作。
- 对质量有保障。
瀑布模型的出现解决了软件项目开发中的几个重要问题：
- 让软件开发过程有序可控。瀑布模型的每个阶段都有明确的任务，每个阶段都有明确的交付产物，都有相应的里程碑。这些让整个过程更可控，而且能及早发现问题。
- 让分工协作变成可能。瀑布模型的六个阶段，也让软件开发产生相应的基础分工：项目经理、产品经理、架构师、软件工程师、测试工程师、运维工程师。
-
质量有保障。瀑布模型每个阶段都需要交付相应的文档，而文档的撰写和评审，可以帮助在动手之前把问题沟通清楚，想清楚。瀑布模型在编码结束后，会有严密的测试，只有测试验收通过后，才能上线发布。这些措施都让软件的质量更有保障。
补充：
历史上的软件危机：
第一次软件危机 （60年代~70年代）
这个时期主要的软件开发方式是使用机器语言或者汇编语言在特定的机器上进行软件的设计与编写。此时的软件规模较小，也不需要使用系统化的软件开发方法，基本上是个人设计编码、个人操作使用的模式。这个时代的程序一个典型特征就是依赖特定的机器，程序员必须根据所使用的计算机的硬件特性编写特定的程序。
然而从60年代中期开始，大容量、高速度计算机问世，程序设计的复杂度也随之增长。1968 年北大西洋公约组织的计算机科学家在联邦德国召开国际会议，第一次讨论软件危机问题，并正式提出“软件工程”一词，从此一门新兴的工程学科——软件工程学——为研究和克服软件危机应运而生，“软件危机”的概念也是在那次会议上由F. L. Bauer提出的。br>
当时业界最迫切的需求是需要在不损失性能的前提下获得更好的“抽象性”和“可移植性”。此时，比汇编和机器语言更高级的语言相聚诞生，典型的代表莫过于C语言（1972年）。C语言让程序员能让程序员编写的代码在没有或只有较少机器相关性的同时又有不输于汇编语言的性能，而且丰富的语言特性也使得编程难度大大降低，成功的解决了“抽象性”和“可移植性”的问题。
第二次软件危机（80年代~90年代）
这次危机可以归因于软件复杂性的进一步增长。这个时候的大规模软件常常由数百万行代码组成，有数以百计的程序员参与其中，怎样高效、可靠的构造和维护这样规模的软件成为了一个新的难题。著名的《人月神话》中提及，IBM公司开发的OS/360系统共有4000多个模块，约100万条指令，投入5000人年，耗资数亿美元，结果还是延期交付。在交付使用后的系统中仍发现大量（2000个以上）的错误。
这时候人们典型需求的是更好的“可组合性”(Composability)、“可延展性”(Malleability)以及“可维护性”(Maintainability)。程序的性能已经不是一个大问题了，因为摩尔定律能帮你搞定它（70年代编写的C程序仍然能在现在的计算机上运行，而且它还更快！）。为了解决这次危机，面向对象的编程语言（C++、C#、Java等）诞生了，更好的软件工程方法（设计模式、重构、测试、需求分析等等）诞生了，而程序员们也越来越不需要知道硬件是怎么工作的了。软件和硬件的界限越来越牢固，Java编写的代码能在任何JVM支持的平台上运行，程序员也非常乐于享受这样的便利。