瀑布模型简介

概述

20世纪70年代，洛克希德公司软件技术中心负责人温斯顿·罗伊斯（Winston Royce）在其白皮书《大型软件系统开发管理》中首次描述了瀑布模型。尽管这篇论文被视为瀑布方法的开端，但罗伊斯本人并不支持这一模型。相反，他将瀑布过程模型作为一种运行不畅的开发流程的典型案例。

瀑布模型的特点

瀑布模型是一种顺序化流程，所有软件构建活动按先后顺序逐一进行。

罗伊斯认为这些活动是成功实施和维护软件所必需的最小步骤。即使在今天，许多组织仍按照这种模式进行层级化分工。例如，设有需求分析或业务分析部门、信息分析部门、功能与技术设计部门，随后是开发人员和测试人员，还有负责功能和技术维护的团队。当然，还配备项目经理来协调其他角色的工作。

尽管罗伊斯并未使用“瀑布”一词，但该模型直接源于1970年的一张示意图。瀑布模型具有以下特征：

• 阶段划分：每个项目由多个阶段组成，如图所示。每个阶段仅执行一次，并按固定顺序推进。
• 角色分工：每个阶段有特定的角色。分析师负责分析，开发者负责开发，测试人员负责测试。
• 交付成果：每个阶段结束时都会产出一个最终产品，完成签字、封存并交付。这些被称为里程碑。例如信息分析或功能设计阶段的成果。
• 完全完成：下一阶段只有在前一阶段的产品完全完成后才开始。软件开发必须等到设计阶段结束后才能启动；只有当软件全部开发完毕，测试才开始。
• 固定不变：项目通常在固定的预算、时间表和范围下进行。

瀑布模型的问题

自1970年以来，大多数项目都采用（或变体形式的）瀑布模型执行，但多数项目以失败告终。几乎所有人都经历过那些严重超预算、未能按时交付、只实现了部分约定需求，甚至中途终止、多次重启的项目。

结合这类传统项目的特征，我们可以清楚地看到其失败的根本原因。以下是几个最常见的问题：

• 知识流失：每个阶段由特定角色负责。一旦某阶段的最终成果完成，该角色即退出项目。这样会导致大量知识在每个阶段结束后丢失。毕竟，不可能将所有内容都完整记录下来。

• 渐进式认知：在项目各阶段中，团队会逐步加深对项目范围、用户需求以及所选技术可行性的理解，这被称为“渐进式认知”。然而，由于前期阶段的成果已固定，这些新获得的认知无法被纳入后续工作。

• 需求变更：平均而言，项目进行过程中约有20%至25%的需求会发生变化。新的需求不断浮现，原有需求也可能被修改或过时。但由于所有需求已在早期阶段详细定义，这部分工作可能变得冗余，或需要重新完成，造成效率低下且成本高昂。

• 追求完整与彻底：由于前期阶段的成果无法更改，因此必须确保每个阶段，尤其是分析与设计阶段，做到彻底完成。如果在后续阶段发现新需求，就会被视为前期工作的缺陷。

这使得分析师和设计师难以交付最终成果，导致项目早期阶段经常严重延误。

• 文档过多：虽然文档对于全面性至关重要，但过度文档化反而可能导致软件根本无法构建，更不用说测试了。

曾有一个比利时银行的项目，两年时间都花在功能分析上，产生了超过2500页的文字文档。预期的开发团队却迟迟不敢估算工作量，更别提开始开发。当被问及原因时，他们表示不确定是否已经完整捕捉到所有功能。

• 难以估算：每个阶段的工作类型不同，节奏也各异。因此很难做出准确的进度预估。如果分析阶段耗时六个月，这对整个项目周期意味着什么？

• 风险暴露过晚：在瀑布模型中，实际的软件开发往往发生在项目后期。有时甚至几年后才写出第一行代码。这带来了巨大风险：所采用的技术可能已过时；软件测试通常直到代码完全完成后才开始。无论分析师、设计师或开发人员多么优秀，测试人员总会发现各种缺陷。

随着项目阶段的推进，已完成的工作越来越多，而修复错误的成本呈指数级增长。这就是著名的博姆定律。

一个典型例子是一家大型国际银行正在开发用于处理保单请求的新软件。架构师设计了一个精妙的架构：当用户移动到下一个字段时，验证逻辑会动态触发。项目进展顺利。18个月后，开发团队将软件交给测试团队。开发人员使用高性能开发机，而测试人员则使用与最终用户相同的设备。测试第一天，软件性能表现极差。为提升性能而对架构进行修改，导致项目交付推迟了六个月。