用软件过程——瀑布模型

http://www.caixiaodong.com/archives/76.html

2009年10月11日 蔡晓东

瀑布模型在中国的普及度非常之高。这得归功于我们的大学教育，学生们还没有理解软件为什么复杂，却已经知道软件的问题必须用“软件工程”来解决，其 中最基础的就是瀑布模型。日复一日，年复一年，等到学生们就业了，成长为项目经理，制定项目计划，瀑布模型自然是首选。然而，事情并没有那么顺利……

一、使用瀑布模型的常见问题

对瀑布模型的抱怨是非常普遍的。需求的频繁变更，使得先进行需求分析，需求评审后再进行后续设计、编码的工作流程很难执行。另外，项目组成员一般相 对固定，很难按瀑布模型要求的时间点进入和退出。瀑布模型输出了大量文档，经常被发现大而无用，真正到了项目中期，多数项目成员根本不记得文档放在哪里， 更谈不上维护文档的准确性。

一些人转而批评瀑布模型，认为其它生命周期模型才是可行的，尤其是“敏捷”。但是，“敏捷”方法就没有问题了吗？让我们回到瀑布之前，领略瀑布模型的思想。

二、从边做边改模型（Build and Fix Model）到瀑布模型

尽管Project格式的项目计划普遍是按照瀑布模型编制的，但实践中，由于瀑布模型的种种问题，项目经理常常将Project抛在一边，一边开发 新代码，一边根据用户需求的变更修改代码。由于用户需求的频繁变更，预计需要3个月完成的项目，到期后发现还需要3个月才能完工。而当6个月过去，似乎还 有很多需求尚未实现，软件结构混乱，似乎应该重写一遍。

边做边改模型，是在软件工程概念提出之前的普遍情况。但是，软件工程提出40年后，软件作坊依然普遍存在。“边做边改”模型主要存在以下问题：

1. 项目范围不确定。软件产品定义或客户需求变更随意频繁，导致大量无效工作量。
2. 软件缺乏结构，由于是“边做边改”，缺乏系统架构，后期维护困难。
3. 项目无法计划，也无法跟踪执行。
4. 人员工作效率低下，团队士气不振。

瀑布模型，在一定程度上解决了上述问题：

1. 通过需求分析确定项目范围，并输出需求说明文档，与客户确认。
2. 通过概要设计及详细设计，提供系统结构，限定后续软件修改在一定范围内进行。软件始终是可维护的。
3. 将整体项目目标分解为一系列阶段，进而分解为各个人员的任务目标，使根据任务目标编排计划及跟踪管理成为可能。
4. 每个人员工作任务明确，工作效率和质量可以评估。

三、如何避免瀑布模型的工期风险

如前所述，瀑布模型是将软件开发的基本活动依次串行执行，即需求分析完成后，再进行概要设计、详细设计，然后进行编码、测试。经常发生的情况是，当 进入编码阶段后，发现前期工作的问题，特别是概要设计、详细设计文档考虑不全面，到编码阶段还有很多工作要做。“串行”执行的特点，要求每一个阶段的工作 成果（文档）输出必须正确，不能有返工。因此，需要在二方面加强：

1. 通过评审确保阶段工作成果的正确性和完整性。从而确保一个阶段的问题不会被带入下一阶段。
2. 在进行“需求分析”、“概要设计”等活动时，不能仅作为1个任务派给1个人员，然后到阶段末期进行评审。应当设置中间检查点，并尽可能让更多人参与工作。这样，在工期刚刚开始偏离的时候就发现并采取措施。

四、小结

瀑布模型的提出，是一个历史性的突破，使软件开发从完全无序的状态中摆脱出来。瀑布模型将一个软件开发的整体目标，分解为各个可执行的任务，并由具备一定技能的人员执行。人们对瀑布模型的指责，更多是因为对瀑布模型的误用而引起的，而不全是模型本身的问题。

瀑布模型的定义，请参阅百度百科。瀑布模型应是一种软件生命周期模型，与软件过程概念稍有差异；应用瀑布模型为基础，定义的软件过程，才适合与RUP、敏捷方法等比较。本文非学术专著，故不加区别将瀑布模型作为软件过程表述。