by白国风
（由蔡新宇、安昕瑜、贾子甲评审）
一、前言
瀑布模型于1970年在Winston Royce的论文《管理大型软件系统开发》（Managing the Development of Larger Software Systems）中被提出，将软件生命周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。自诞生之日起至80年代初期，瀑布模型都是唯一被广泛采用的软件开发模型。
它有许多优点：
- 为项目提供了按阶段划分的检查点；
- 前一阶段完成后，只需关注后续阶段；
- 提供了一个模板，使得分析、设计、编码、测试和支持的方法可以在该模板下接受共同的指导。
然而随着各种技术和理论的发展，软件体量、用户需求等等的变化，瀑布模型的一些缺点也饱受诟病：
- 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
- 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险；
- 不适应用户需求的变化。
这些缺点不可否认，但如果回顾Winston Royce的那篇论文，可以发现他提出的不是一个孤立的模型，而是一系列从简单灵活到完整稳健的模型的演化过程。如今广为大众所知的、严格前后步骤次序的瀑布模型，只是Winston Royce的模型演化过程中的第二或者第三个阶段，并不能完全代表他的理论与想法。
本文将回顾Winston Royce在《管理大型软件系统开发》中提出的模型演化过程。
二、所谓“瀑布模型”
1.最简单的理想状态
无论何种大小和复杂性，任何计算机程序的开发都有两个基本步骤，即分析和编码，如图1所示。这种非常简单的实现观点，在开发供编写人员自己使用的小型程序的过程中，可以满足基本要求。这也是客户理想的付费依据，因为分析和编码阶段都是创造性过程，对最终产品的贡献是直接而又直观的，不存在多余的工作。但大型软件的开发如果只按照这两个阶段进行，则注定会失败。除分析和编码之外的其他阶段，如设计、测试等，同样重要，但它们对最终产品的贡献并不那么直观和直接，客户不愿为这些并无明显贡献却需要大量资源和工作量的阶段而付费，结果就是开发人员默认地不去实现那些阶段。
图1 供内部人员使用的小型程序开发过程
2.更宏大的开发过程
图2描述了一个更宏大的软件开发过程，分析和编码阶段依然在其中，但多了系统需求、软件需求、程序设计、测试四个阶段。这四个阶段在执行的方式上显然有别于分析和编码，需要以其他方式计划并配备人员。
图2 为客户交付大型计算机程序的开发过程
图3展示了这种模式下前后两个阶段之间的交互关系。阶段的顺序遵循这样的理念，即随着过程的进展和设计的进一步细化，在前一阶段和后一阶段间存在一个循环，每个阶段不会与相隔一个阶段的其他阶段交互。这样做的好处显而易见，可以把变更限制在可控的范围内，如果发现前一阶段的工作需要改动，只需改动前一阶段，而无需改动更前面的阶段。这样也可以最大程度保留之前阶段的工作成果。
图3 理想地，阶段间的交互被限制在前后相继
此处所描述的，就是如今广为大众所知的瀑布模型的版本。值得注意的是，Winston Royce在介绍这种模式时用了“宏大的”（grandiose）一词，该词同时还有“浮夸的”的含义，表明他也认为虽然这种模式看上去很美很壮观，但却华而不实。
3.问题所在
上面所描述的模式很美很壮观，但充满风险并会招致失败。图4描述了问题所在。测试是开发过程的最后一个阶段，却也是最早发现时间、存储、输入输出转换等方面异常问题的阶段。在测试阶段发现的问题，往往不能仅靠返工到编码阶段改动几行代码就能解决，必须重新设计。设计上的改动可能是毁灭性的，甚至连需求分析阶段也会受到波及。此时，要么更改设计，要么从需求开始更改，导致开发过程倒退甚至回到起点，而这意味着高达100%的日程延期和额外投入。
图4 不幸地，阶段间的交互不可能被局限在前后相继的顺序上
三、改进的方面
1.设计先行
图5描绘了第一步改进，在需求生成阶段与分析阶段插入一个预设计阶段。这可能遭受非议，因为程序设计师在没有进行详细分析的情况下被迫设计，毫无疑问会比在分析后设计要更容易出错。批评有一定道理，但忽略了一点，设计师进行预设计，其真正目的，在于确保程序不会因为时间、存储或数据流等方面出现问题而失败。在后续的分析阶段，设计师必须把时间、存储、运营等方面的限制提交到分析师面前，让分析师在做分析时必须考虑这些限制。如此，如果资源不足或原型设计有误，会在更早的阶段发现，涉及的工作改动仅在需求和预设计阶段之间循环，直到开始真正的分析和设计。
图5 在分析阶段前先完成预设计
这种改进需要以下步骤：
- 让程序设计师进行预设计，而不是分析师或者编码人员；
- 设计，定义并分配数据处理模式
- 写一份可理解、及时、准确的概览文档，确保每个工作人员对系统有基本的理解
2.设计文档化
管理需要大量的文档，没有足够的文档，根本无法对项目做出有效的管理。
为什么文档这么重要？
- 每个设计师都需要与接口设计者、管理者甚至客户进行沟通交流。口头协议充满不确定性，必须有书面的记录，才能迫使设计师提供明确证据证明他的工作已完成，否则他们会一直处于“我已经完成了90%的工作”的状态，而无实际进展。
- 在项目开发的早期阶段，文档就是规格，就是设计。如果文档品质不佳，就不会产生好的设计。再进一步，如果没有文档，也就根本没有设计。
- 文档的实际价值在开发过程中顺流而下，经过测试阶段，运营阶段以及再设计阶段。而文档的价值可以描述成3种具体的、确定的情形：
- 在测试阶段，良好的文档帮助管理者关注涉及程序错误的相关人员，如果没有文档，所有的错误只能由一个人来分析；
- 在运营阶段，良好的文档帮助管理者安排人员更好地运营程序，如果没有文档，程序只能由亲自编写它的人来运营；
- 初始操作之后，当系统改进井然有序时，好的文档保证了高效的再设计、更新。
图6展示了应当具备的几种重要文档。
图6 保证文档的及时性和完整性
3.做两次
如果是第一次开发某个计算机程序，先整理相关问题，考虑设计/运营方面的问题，再做一次，确保交付给客户的实际上是第二个版本。这么做的好处在于，第一次的结果可以当作最终产品的一个模拟，通过观察第一次的结果中的各种问题以及试验性想法的实际表现，设计师有一定的依据对设计等进行改进。图7展示了这种过程。
图7 尝试把工作做两次
4.计划、控制、监测测试阶段
前面的3个改进步骤都旨在进入测试阶段前发现并解决尽可能多的问题。然而，测试阶段是不可避免的，它也毫无疑问是耗费项目资源最多的阶段。
在测试阶段，有很多需要考虑的问题：
- 测试过程的大部分应该由测试专家来负责，尽管他们并未参与软件设计。如果软件测试只能由设计软件的人来负责，意味着缺乏足够的文档。如果有好的文档，即使测试专家并未参与软件的设计，他们也能够变现出色，甚至比设计师本人负责时更有效；
- 有很多错误是可以通过视觉上的审查来发现的，应该把分析和设计提交给除分析者和编码者之外的人来评审；
- 测试每一条逻辑路径；
- 当小错误被移除后，及时测试以作检验。
图8是测试中应该关注的地方。
图8 计划、控制、检测测试阶段
5.使客户参与
即使经过了协商，对软件需求达成共识，开发人员在软件该做什么的问题上仍然存在多种解读的可能。使用户尽早参与开发过程，可以澄清一些不确定的问题。图9描绘了客户应该参与的3个关键事件，这种参与应该是正式、深层次、持续性的。
图9 使客户参与
四、开发模式改进总结
图10总结了上述5个改进步骤，也说明了如何把一个充满风险的开发过程转换成能提供理想产品的开发过程。每一个改进步骤都需要额外的开销，如果只采用一部分改进就可以良好地工作，那就没必要花费更多的资金。
图10 总结
五、回顾
通过以上的回顾，我们发现，Winston Royce清楚地知道广为人知的“瀑布模型”的优点与危害，为此他提出了5个步骤来改进这种开发模式。他认为，前后相继的开发模式在小型软件开发中可以起到良好的作用，但随着软件规模的不断扩大，有必要酌情引入一种或者几种改进方法来对瀑布模型做改进。
最终大众却只记住了Winston Royce认为存在风险的瀑布模型，并把它当作Winston Royce的全部理论主张，不能不说是极大的误解。