软件工程学习笔记2——瀑布模型及其衍生模型

一、瀑布模型

瀑布模型算是现代软件工程的起源，软件工程的发展，很大部分都是构建于瀑布模型的基础之上的。

思考一下：大的软件系统是如何开发出来的？那么多人一起开发一个软件，系统是如何分工协作的？

1、 瀑布模型发展

在软件开发刚开始起步时，开发模式就是边写边改模型。
边写边改的开发模式主要缺点：

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

为了解决软件危机中的问题，在 1970 年，提出了瀑布开发模型，指出软件开发应有完整之周期，并将软件开发过程分成了若干阶段。像瀑布一样，从上往下，完成一个阶段继续下一个阶段。

瀑布模型在提出后，一直到 2000 年前后，都是最主流的软件开发模型，即使到现在，你也能在很多软件项目中看到它的影子。

2、 瀑布模型优缺点

优点：

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

缺点：

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

二、其他开发模型

瀑布模型的衍生模型都有哪些，又该如何选择呢？

1、快速开发快速改

（1）快速原型模型

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

先迅速建造一个可以运行的软件原型，然后收集用户反馈，再反复修改确认，使开发出的软件能真正反映用户需求，这种开发模型就叫快速原型模型，也叫原型模型。

优点：

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

缺点：

• 往往以牺牲质量为代价，没有经过严谨的系统设计和规划，可靠性和性能都难以保障。

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

• 抛弃策略是将原型只应用于需求分析阶段，在确认完需求后，原型会被抛弃，实际开发时，将重新开发所有功能。如果客户对可靠性、性能要求高，那么就最好是抛弃策略。
• 附加策略则是将原型应用于整个开发过程，原型一直在完善，不断增加新功能新需求，直到满足客户所有需求，最终将原型变成交付客户的软件。如果客户对质量要求不高，有简单功能就够了，那么可以试试附加策略。

补充：

• 快速原型模型即使到现在还一直有在用，用于低成本快速的确认需求。
• 原型制作并不一定要像传统代码一样进行设计编码，有很多原型工具，像 Axure、墨刀等。

2、大瀑布拆小瀑布

瀑布模型的很多问题，根源都是周期太长。如果能将周期变短，那么很多问题就迎刃而解了。

基于这种思路，产生了很多开发模型，比较典型的主要是：增量模型 和 迭代模型。

（1）增量模型——按模块分批次交付

增量模型是把待开发的软件系统模块化，然后在每个小模块的开发过程中，应用一个小瀑布模型，对这个模块进行需求分析、设计、编码和测试。

优点：

• 相对瀑布模型而言，增量模型周期更短
• 不需要一次性把整个软件产品交付给客户，而是分批次交付。

缺点：

• 因为增量模型的根基是模块化，所以，如果系统不能模块化，那么将很难采用增量模型的模式来开发。
• 对模块的划分很抽象，这本身对于系统架构的水平要求很高。

适用场景： 需求比较清楚，能模块化的软件系统，并且可以按模块分批次交付。

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

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

举例理解如：毛胚房（迭代1）——粗略装修的房（迭代2）——精装修的房（迭代3）

在迭代模型中，整个项目被拆分成一系列小的迭代。通常一个迭代的时间都是固定的，不会太长，例如 2-4 周。每次迭代只实现一部分功能，做能在这个周期内完成的功能。

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

优点：

• 在较小的迭代中进行测试和调试很容易。
• 并行开发可以计划。
• 对于不断变化的项目需求而言，这是很容易接受的。
• 在迭代过程中识别并解决风险。
• 在文档上花费的时间有限, 在设计上花费了额外的时间。

缺点：

• 它不适用于较小的项目。
• 可能需要更多资源。
• 由于不完善的要求, 可以一次又一次地更改设计。
• 需求变更可能会导致预算超支。
• 由于需求变更, 未确认项目完成日期。

（3）增量模型和迭代模型的区别

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

用盖房子来理解

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

3、根据场景选择开发模型

除了上面提到的这几种模型，还有很多其他开发模型，要记住所有的开发模型很难。搞透了瀑布模型，搞清楚了其阶段划分，结合一些应用场景，你就可以举一反三，了解绝大部分衍生模型。

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

假如你现在是一家外包公司，你可以采用瀑布模型开发，但是甲方需要对你项目的每个阶段进行验收测试，以确认你是不是达到要求。

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

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

假如你现在要做一个风险很高的项目，客户可能随时不给你钱了。

可以使用螺旋模型，就是基于增量模型或者迭代模型，在每次交付的时候，要同时做一个风险评估，如果风险过大就不继续后续开发了，及时止损。

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

其实软件行业山寨的案例不少，山寨项目的特点是，项目需求是明确的，不会有什么变化。

可以选择增量模型，划分好模块，先实现核心模块，发布可运行版本，再增量发布其他模块。多模块可以同步开发。

（4）场景四：产品已经上线，但是需要持续更新维护

很多产品在上线后，还在保持不停的更新维护，修复 Bug、增加新功能，每个月甚至每周更新。

在这种情况下，迭代模型是比较合适的。固定时间周期，在固定的周期内选择适合的需求开发任务和 Bug 修复任务去完成，按时发布。

4、总结

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

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

同时，也不必拘泥于这几种开发模型，还可以借鉴其他模型做的好的地方，甚至创造自己的开发模型。