瀑布模型是一种按照需求分析、系统设计、详细设计、编码实现、测试验证和部署维护等阶段顺序推进的软件开发方法。它强调前期规划、阶段交付物、评审、项目基线和变更控制，适合需求稳定、验收标准明确、合规要求高或后期变更成本较大的项目。
本文核心结论
- 瀑布模型按照明确阶段和顺序推进研发工作。
- 每个阶段都应定义输入、工作内容、交付物和完成条件。
- 瀑布模型的优势是结构清晰、计划相对可预测、过程可追溯。
- 它的不足是对前期需求质量要求较高，面对频繁变化时调整成本较大。
- 需求稳定、验收明确、合规要求高的项目更适合瀑布模型。
- 需求持续探索、技术不确定、需要高频反馈的项目更适合敏捷或混合模式。
一、瀑布模型是什么？
瀑布模型是把软件开发生命周期划分成若干相对独立的阶段，并按照既定顺序逐步推进的研发管理方法。前一阶段的输出会成为后一阶段的输入。例如，经过评审的需求文档会成为系统设计的依据，系统设计又会成为详细设计和编码实现的基础。
一个完整的瀑布研发过程通常包含四个基本要素：
- 明确的研发阶段；
- 每个阶段的输入、活动和交付物；
- 阶段评审以及进入下一阶段的条件；
- 正式的需求、范围和计划变更机制。
1970年，Winston Royce在《Managing the Development of Large Software Systems》中讨论了大型软件开发中的需求、设计、编码、测试和运行过程。该论文经常被视为瀑布模型的重要历史来源，但Royce并不是在主张机械的单向开发，而是在强调大型项目需要更多反馈、验证、文档和风险控制。
因此，瀑布模型不应被简单理解为“进入下一阶段后绝对不能返回”，而应理解为：项目有明确的主流程，任何返回、调整和变更都需要经过评估与控制。
二、瀑布模型包括哪六个阶段？
瀑布模型通常包括需求分析、系统设计、详细设计、编码实现、测试验证和部署维护六个阶段。不同组织可以根据项目规模合并或细分阶段，但每个阶段都应有明确的交付物和完成条件。
阶段 | 主要工作 | 典型交付物 | 阶段完成条件 |
需求分析 | 明确项目目标、范围、功能和约束 | 需求规格说明书、范围说明、验收标准 | 需求通过评审，各方对范围和验收口径达成一致 |
系统设计 | 确定总体架构、模块、接口和数据方案 | 系统架构图、模块设计、接口设计 | 总体方案可行，关键技术风险得到处理 |
详细设计 | 将总体方案细化为可以开发和测试的设计 | 详细设计文档、数据库设计、接口定义 | 设计完整，并具备可实现性和可测试性 |
编码实现 | 完成开发、代码审查和单元测试 | 程序代码、构建产物、单元测试结果 | 功能实现完成，达到集成和测试条件 |
测试验证 | 验证系统是否符合需求与质量标准 | 测试用例、缺陷记录、测试报告 | 关键缺陷关闭，系统满足验收要求 |
部署维护 | 发布系统、迁移数据并持续运维 | 发布包、部署方案、运维手册 | 系统稳定运行，完成验收或转入运维 |
NASA的软件生命周期指南指出，软件项目应选择并记录适合的生命周期模型，并为每个阶段设置转换条件。需求评审、设计评审、测试就绪评审和客户验收，都可以作为阶段转换的判断依据。
1. 需求分析阶段
需求分析负责回答“项目究竟要解决什么问题”。团队需要明确：
- 项目目标与业务价值；
- 功能需求和非功能需求；
- 项目范围及不包含的范围；
- 性能、安全和合规约束；
- 可以验证的验收标准。
需求不能只写成“支持用户管理”或“提高系统性能”，而应尽可能转化成可以设计、开发和测试的具体条件。需求分析完成后，相关方需要确认需求是否清晰、完整、可实现、可测试，并决定是否允许项目进入设计阶段。
2. 系统设计阶段
系统设计负责将需求转化为总体解决方案，通常涉及：
- 系统架构；
- 功能模块划分；
- 数据模型；
- 外部接口；
- 技术选型；
- 部署方式；
- 安全与性能方案。
这一阶段重点回答“系统整体应该如何建设”，并识别可能影响开发和交付的关键技术风险。
3. 详细设计阶段
详细设计进一步说明每个模块如何实现，包括模块内部逻辑、接口参数、数据字段、状态流转、权限规则、异常处理和可测试性设计。如果系统设计类似建筑的总体蓝图，那么详细设计就更接近具体的施工图纸。详细设计不仅要让开发人员知道如何实现，也要让测试人员能够提前设计测试方案。
4. 编码实现阶段
开发人员根据详细设计完成代码编写、代码审查和单元测试。项目经理则需要持续跟踪：
- 任务完成情况；
- 前后置任务依赖；
- 实际进度与计划进度偏差；
- 关键任务和里程碑状态；
- 技术风险与缺陷；
- 人员投入和资源冲突。
即使采用瀑布模型，高风险模块、外部接口和核心技术方案也应尽早验证，避免所有问题都推迟到测试阶段。
5. 测试验证阶段
测试阶段负责验证系统是否满足需求和质量标准，通常包括：
- 集成测试；
- 系统测试；
- 性能测试；
- 安全测试；
- 用户验收测试；
- 缺陷修复与回归测试。
瀑布模型虽然通常设置相对独立的集中测试阶段，但质量工作不应只在项目后期开始。需求阶段需要检查需求是否可测试，设计阶段需要开展方案评审，编码阶段则应完成单元测试。
6. 部署维护阶段
完成测试和验收后，项目进入部署维护阶段，主要工作包括：
- 制定发布和回退方案；
- 配置生产环境；
- 完成数据迁移；
- 培训用户和运维人员；
- 监控系统运行状态；
- 处理上线问题；
- 持续修复缺陷和优化性能。
如果项目由研发团队移交给运维团队，还需要明确交接资料、责任边界和服务要求。
三、瀑布模型的核心特点是什么？
瀑布模型的核心特点是阶段相对明确、前期规划充分、交付物清晰，并通过评审、基线和变更流程控制项目偏差。
1. 按阶段顺序推进。当前阶段没有达到完成条件时，原则上不应直接进入下一阶段。这可以减少团队在需求尚未确定时大规模开发，或者在设计尚未完成时盲目排期。
2. 强调前期规划。项目开始阶段通常需要制定范围、WBS、进度计划、任务依赖、里程碑、资源安排和验收标准。计划不是为了保证项目永远不变，而是为了建立一个可以识别和解释偏差的参照。
3. 强调阶段交付物。每个阶段都需要形成能够支持后续工作的成果，例如需求说明书、设计文档、程序代码、测试报告和验收材料。文档的价值不在于证明“团队做过工作”，而在于为开发、测试、评审、交接和审计提供共同依据。
4. 设置评审和里程碑。阶段评审用于判断当前阶段是否达到进入下一阶段的条件。里程碑则用于标记重要事件、决策点或交付节点。有效的阶段评审需要回答：本阶段交付物是否完整？质量是否达到要求？风险是否可以接受？资源是否已经落实？是否允许进入下一阶段？
5. 通过基线和变更流程控制偏差。经过批准的需求、范围和项目计划可以形成基线。项目执行过程中，团队将实际情况与基线进行比较，以识别进度、范围和交付偏差。出现重大变化时，应先完成影响分析和审批，再调整任务与计划，而不是直接覆盖原有记录。
四、瀑布模型有哪些优缺点？
瀑布模型的主要优势是计划清晰、责任明确、过程可追溯；主要不足是依赖前期判断，在需求和技术频繁变化时调整成本较高。
维度 | 瀑布模型的优势 | 瀑布模型的局限 |
项目流程 | 阶段清晰，团队容易明确当前任务和责任 | 阶段交接可能形成等待和沟通损耗 |
计划管理 | 需求稳定时，容易估算周期、预算和资源 | 需求变化后，可能需要大范围调整计划 |
交付物 | 文档、成果和验收标准相对明确 | 容易出现为完成流程而编写文档的问题 |
进度控制 | 可以使用WBS、甘特图、里程碑和基线跟踪 | 前期判断错误可能持续影响后续阶段 |
质量管理 | 需求、设计、开发和测试之间便于追溯 | 缺少早期验证时，重大问题可能较晚暴露 |
团队协作 | 适合多部门、供应商和大型团队合作 | 部门之间可能因阶段交接产生信息损失 |
合规审计 | 重要评审、审批和变更可以保留记录 | 流程相对较重，不适合所有项目 |
瀑布模型的优势和局限往往来自同一个特点：通过前期确定性换取执行过程的可预测性。当项目确实具有较高确定性时，这种交换是有价值的；当项目高度不确定时，它就可能变成约束。
五、瀑布模型适合哪些项目？
瀑布模型适合需求相对稳定、验收标准明确、后期变更成本高，或者有严格合规和审计要求的项目。
1. 需求和范围相对稳定的项目。如果项目目标、业务范围和验收条件可以在前期基本确定，就有条件建立比较完整的需求和计划。常见场景包括旧系统迁移、标准化信息系统建设和既有产品的合规改造。
2. 合同及验收边界明确的项目。在客户交付项目中，甲乙双方往往需要按照合同、阶段、交付物和验收标准完成结算。瀑布模型可以为双方提供较清晰的责任与验收依据。
3. 合规和审计要求较高的项目。金融、政企、医疗、汽车、芯片和大型制造等领域，通常需要保留正式的需求、设计、测试、评审和变更记录。这类项目不仅要证明“系统可以运行”，还要能够说明为什么这样设计、由谁批准以及如何验证。
4. 软硬件协同研发项目。涉及硬件打样、器件采购、生产制造和供应商交付的项目，后期修改接口、规格和供应链计划的成本通常较高。充分的前期设计和阶段评审能够降低后期返工风险。
5. 多部门或多供应商协作项目。参与人员多、角色分工明确、跨部门交接频繁时，阶段、交付物、里程碑和评审机制有助于降低协作混乱。
示例：金融系统合规改造
假设某金融机构需要对已有业务系统进行合规改造。监管要求、改造范围、数据接口和验收标准在项目开始前已经基本明确，上线窗口也不能随意调整。
团队可以先确认并冻结需求范围，再按照系统设计、详细设计、开发、测试和上线阶段推进。每个阶段设置评审节点，项目执行过程中持续比较基线与实际进度；新增需求必须先完成影响分析和审批。
这个项目适合瀑布模型，并不是因为金融行业“比较传统”，而是因为它具有四个典型特征：需求边界相对明确；合规和审计要求高；上线失败风险大；后期变更成本高。
六、应该如何选择瀑布、敏捷或混合模式？
选择研发模式时，应重点判断需求稳定性、验收方式、变更成本、合规要求、技术确定性和用户反馈周期，而不是简单比较哪一种方法更先进。
判断问题 | “是”更倾向瀑布 | “否”更倾向敏捷或混合模式 |
核心需求能否在项目初期基本确定？ | 可以形成正式需求基线 | 需求需要持续探索 |
最终交付物和验收标准是否明确？ | 可以按合同或标准验收 | 需要通过反馈逐步定义 |
后期变更成本是否较高？ | 需要前期充分设计和评审 | 可以低成本快速试错 |
是否有严格的合规和审计要求？ | 需要完整文档和审批记录 | 过程记录要求较轻 |
是否涉及多个部门、供应商或硬件环节？ | 需要明确阶段和交接物 | 团队规模较小、协作紧密 |
用户能否接受较长的完整交付周期？ | 可以按照阶段推进 | 需要频繁获得可用版本 |
技术方案是否相对成熟？ | 可以进行较完整规划 | 需要持续试验和验证 |
可以采用以下判断：
- 多数答案为“是”：优先考虑瀑布模型；
- 两类答案数量接近：考虑瀑布与敏捷结合的混合模式；
- 多数答案为“否”：优先考虑敏捷或迭代开发。
这套判断方法不是正式行业标准，可以看成一种帮助团队讨论研发模式的实用检查工具。
七、落地瀑布模型需要哪些管理能力？
落地瀑布模型至少需要WBS、任务依赖、里程碑、项目基线、变更追溯、资源管理，以及需求与测试关联等能力。
具体包括：使用WBS拆分项目和工作；设置任务的前后置依赖；通过甘特图查看整体排期；标记里程碑和阶段评审点；保存项目计划或里程碑基线；对比计划与实际执行偏差；追溯需求、任务和计划变更；汇总项目进度与资源投入；关联需求、研发任务、测试和交付物。
例如，ONES瀑布项目管理解决方案支持使用项目计划创建WBS、设置任务依赖和里程碑，并通过计划与里程碑基线比较执行偏差；项目计划还可以与需求、迭代及研发任务关联，帮助团队连接计划和实际执行过程。
不过，工具不能代替管理制度。团队仍然需要先明确：阶段如何划分；每个阶段交付什么；谁负责、谁评审、谁批准；什么情况下可以进入下一阶段；发生变更时如何评估和审批。
瀑布模型常见问题FAQ
1. 瀑布模型的核心是什么？
瀑布模型的核心是按照明确阶段推进项目，并为每个阶段定义输入、工作内容、交付物和完成条件，通过评审、基线和变更流程控制项目风险。
2. 瀑布模型通常包括哪些阶段？
常见的六个阶段是需求分析、系统设计、详细设计、编码实现、测试验证和部署维护。企业可以根据项目规模和行业要求进行合并或细分。
3. 瀑布模型和敏捷开发最大的区别是什么？
瀑布模型倾向于前期确定需求并按阶段推进；敏捷开发通过短周期迭代持续交付，并根据用户反馈调整需求。前者重视计划和阶段控制，后者重视反馈和变化响应。
4. 瀑布项目可以修改需求吗？
可以。团队需要先提出变更申请，分析变更对范围、进度、成本、质量和资源的影响，获得批准后再修改任务、计划及相关基线。
5. 瀑布、敏捷和混合模式应该怎么选？
需求稳定、验收明确、变更成本高时，可以优先考虑瀑布模型；需求变化快、需要频繁反馈时，更适合敏捷；既需要阶段治理又需要迭代交付时，可以采用混合模式。
参考资料
- NIST：The System Development Life Cycle
- NASA：Software Life Cycle
- Winston Royce：Managing the Development of Large Software Systems
- ONES瀑布项目管理解决方案
