什么是瀑布模型

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

边写边改的开发模式，为什么说不能满足复杂软件项目的需要呢？主要是有几方面的原因：

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rwbDkJmP-1632384589159)(瀑布模型.assets/瀑布模型定义.jpg)]

瀑布模型把整个项目过程分成了六个主要阶段：

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

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

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

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

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

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-21bmyzPi-1632384589160)(瀑布模型.assets/瀑布模型优缺点.jpg)]

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

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

瀑布模型之外，还有哪些开发模型？

快速开发快速改

• 快速原型模型

快速原型模型，就是为了要解决客户的需求不明确和需求多变的问题

原型模型因为能快速修改，所以能快速对用户的反馈和变更作出响应，同时原型模型注重和客户的沟通，所以最终开发出来的软件能够真正反映用户的需求。

但这种快速原型开发往往是以牺牲质量为代价的

针对原型模型的这种快速、低质量的特点，通常有两种处理策略：抛弃策略和附加策略。

抛弃策略 是将原型只应用于需求分析阶段，在确认完需求后，原型会被抛弃，实际开发时，将重新开发所有功能。类似于用彩钢房盖房子，确认完客户需求后，拆掉重新建。

附加策略 则是将原型应用于整个开发过程，原型一直在完善，不断增加新功能新需求，直到满足客户所有需求，最终将原型变成交付客户的软件。类似于用彩钢房盖房子，最后还要做一番精装修，交付客户。

大瀑布拆小瀑布

瀑布模型的很多问题，根源都是周期太长,如果能将周期变短，那么很多问题就迎刃而解了。基于这种思路，产生了很多开发模型，比较典型的主要是：增量模型 和 迭代模型。

• 增量模型——按模块分批次交付

增量模型是把待开发的软件系统模块化，然后在每个小模块的开发过程中，应用一个小瀑布模型，对这个模块进行需求分析、设计、编码和测试。相对瀑布模型而言，增量模型周期更短，不需要一次性把整个软件产品交付给客户，而是分批次交付。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mItfOyT7-1632384589161)(瀑布模型.assets/增量模型.jpg)]

如果系统不能模块化，那么将很难采用增量模型的模式来开发基于这样的特点，增量模型主要适用于：需求比较清楚，能模块化的软件系统，并且可以按模块分批次交付。

• 迭代模型——每次迭代都有一个可用的版本

迭代模型每次只设计和实现产品的一部分，然后逐步完成更多功能。每次设计和实现一个阶段叫做一个迭代。

在一个迭代中都会包括需求分析、设计、实现和测试，类似于一个小瀑布模型。迭代结束时要完成一个可以运行的交付版本

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4gr99k0E-1632384589163)(瀑布模型.assets/迭代模型.jpg)]

增量模型是按照功能模块来拆分；而迭代模型则是按照时间来拆分，看单位时间内能完成多少功能。

	还是用盖房子来理解，增量模型则是先盖厨房，再是卧室，这样一个个模块来完成。而迭代模型则是先盖一个简单的茅草房，有简易的土灶和土床，然后再升级成小木屋，有更好的灶和更好的卧室，这样一步步迭代成最终的房子。

我该选择什么过程模型？

场景一：外包项目，需要阶段验收

假如你现在是一家外包公司，你可以采用瀑布模型开发，但是甲方需要对你项目的每个阶段进行验收测试，以确认你是不是达到要求。针对从需求定义一直到编码阶段，每个阶段都有对应的测试验收。如果画成图，就是下面这个样子的。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZKMrXdHc-1632384589164)(瀑布模型.assets/V模型.jpg)]

这个模型就是 V 模型，本质上它还是瀑布模型，只不过它是更重视对每个阶段验收测试的过程模型。

场景二：项目风险高，随时可能会中断

如果你现在要做一个风险很高的项目，客户可能随时不给你钱了。这种情况下，如果采用传统瀑布模型，无疑风险很高，可能做完的时候才发现客户给不了钱，损失就很大了！这种情况，基于增量模型或者迭代模型进行开发，就可以有效降低风险。你需要注意的是，在每次交付的时候，要同时做一个风险评估，如果风险过大就不继续后续开发了，及时止损。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-82QF0P8d-1632384589165)(瀑布模型.assets/螺旋模型.png)]

这种强调风险，以风险驱动的方式完善项目的开发模型就是螺旋模型。

场景三：山寨一款软件产品，希望能快速上线发布

其实软件行业山寨的案例不少，山寨项目的特点是，项目需求是明确的，不会有什么变化，这时候就可以选择增量模型，划分好模块，先实现核心模块，发布可运行版本，再增量发布其他模块。多模块可以同步开发。

场景四：客户都没想清楚想要什么，但是个大单子

很多项目，客户一开始都没想清楚想要的是什么，需要花很长时间去分析定义需求，但是单子很大，值得认真去做好。那么这样的项目，你可以考虑拆分成四个阶段：1. 初始阶段主要是确定需求边界和主要风险，几乎没有什么开发工作。2. 细化阶段这个阶段主要是确定需求，可以采用快速原型模型开发，和客户对需求反复确认，需要辅助一定量的开发和测试工作。对代码质量可以要求比较低，重点是确认需求。可能需要一个或多个版本迭代。3. 构造阶段在需求确认清楚后，现在可以使用迭代模型来开发，逐步交付产品。这个阶段的重点是开发和测试。如果迭代中，有新的需求加入或者需求变更，也可以在新的迭代中加入。4. 交付阶段在开发和测试完成后，产品可以交付客户，根据线上运行情况还需要修复一些 Bug。这个阶段重点是测试和部署。也会有多个迭代。整个过程看起来就像下图这样。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IiGAa5r1-1632384589166)(瀑布模型.assets/迭代开发.png)]

上面这种开发方式来源自统一软件开发过程（Rational Unified Process，RUP），适用于复杂和需求不明确的软件系统。

场景五：我的产品已经上线，但是需要持续更新维护

很多产品在上线后，还在保持不停的更新维护，修复 Bug、增加新功能，每个月甚至每周更新。在这种情况下，迭代模型是比较合适的。固定时间周期，在固定的周期内选择适合的需求开发任务和 Bug 修复任务去完成，按时发布。另外还可以尝试敏捷开发，也是基于迭代的开发模型，它也强调快速交付，每次交付系统的部分功能，来保证客户满意度。在敏捷开发中，系统交付的周期称之为冲刺（Sprint）。严格来说，敏捷开发并不算是一种开发模型，更像是框架或指南。有各种开发模型来实现敏捷开发，比如说极限编程（Extreme programming），看板（Kanban）和 Scrum。有关敏捷开发，我将在下一篇中向你详细讲解。

总结

现在的软件项目，各种类型都有，根据项目特点，选择好合适的开发模型，可以让你事半功倍，降低项目风险，提高项目开发效率，控制项目成本。比如说：

1一个以确认需求为主要目的的项目，就可以不用花太多时间在代码质量上面，低成本、高效做出来才是最重要的；一个高风险的项目，则可以采用螺旋模型，出现问题及时止损；一个很长时间加班加点，却一直没法上线，导致士气低落的项目，可以改成增量模型，先上线一个小模块，让大家看到成绩提升士气，然后再迭代，逐步上线其他模块。