瀑布模型简介

瀑布模型（Waterfall Model）是一种经典的、线性顺序的开发方法，也称为传统模型。它的特点是项目活动严格按照预定顺序进行：需求定义→产品设计→研发实现→测试验证→发布维护，，每个阶段完成后才会进入下一个阶段，如同瀑布逐级下落。上一阶段成功完成后，才会移至下一阶段，相邻的两个阶段互为唯一的输入/输出。

尽管它在现代软件开发中被认为有些过时，但在某些需求明确、代码质量非常高、成本控制精准的项目中仍然有用。

瀑布模型优点

瀑布模型的优势在于，在前期的需求分析和产品设计阶段投入了充足的时间精力，较为全面深入地分析了**整个软件系统。**如果没遇到不靠谱的甲方频繁的变更需求，那么将顺利的完成软件开发与交付，投入最低的开发成本，得到较高质量的软件；

1. 总研发成本低（如果不因变更需求而返工的话，在众多软件开发生命周期模型中，瀑布模型的开发成功是最可控制的。 敏捷开发模型在成本控制方面不如瀑布模型）。
2. 软件质量高、软件可维护性高。（需要严格的执行和管理，确保每个步骤都得到充分验证。）
3. 团队（有可能）可以分布式异地办公。（敏捷开发模型在这方面则是不如瀑布模型，敏捷开发模型主张面对面的沟通）

瀑布模型使用说明

1. 概念开发：确定系统级需求，提交任务陈述。
2. 系统配置开发：明确所需的软硬件环境。
3. 开发阶段：需求定义→产品设计→研发实现→测试验证→发布维护。

瀑布模型适合的场景

• 传统项目（如航空航天软件、银行核心系统）

  • 适合模型：瀑布模型
  • 原因：这类项目通常要求文档完备性和代码质量非常高。瀑布模型通过严格的阶段划分和详细的文档记录，确保每个环节都符合高标准。

• 需求明确的项目（如政府系统）

  • 推荐模型：瀑布模型
  • 原因：当需求非常明确且不会轻易改变时，瀑布模型可以通过严格的阶段划分和文档记录，确保项目按计划顺利推进。

• 军工级软件

  • 推荐模型：瀑布模型
  • 原因：军工级软件对质量和安全性有极高的要求，瀑布模型通过严格的阶段评审和文档记录，确保每个环节都符合标准。

瀑布模型缺点

1. 需求固定难变：初期就需要全面准确的需求分析，这对许多应用来说非常困难。
2. 用户反馈延迟：用户只能在项目末期看到成果，增加了风险。
3. 不适合新项目：新的或复杂项目通常不适合使用瀑布模型，除非是在后期阶段。
4. 变更限制：一旦完成某个阶段，返回修改的成本很高。
5. 错误发现滞后：早期错误可能要到后期才发现，带来严重后果。

瀑布模型两个主要风险点

1. 不要遇到不靠谱的甲方频繁的变量需求，导致工期不可控。
2. 前期要把需求把握准确，防止系统开发完后，不是用户想要的。

瀑布模型的弊端

瀑布模型它成也结构化，败也结构化，很多时候甚至可以称之为僵化。每一阶段都依赖于上一阶段的正确、完整，一旦某个阶段出现问题，需要回到上一阶段补充修正重来，如果是需求变动或者需求误判，那么所有已完成的工作都要付诸东流，越到后期风险成本越大；各阶段的信息断层，又会使得队员们在“可能是……”的反复改改改中丧失信心与创造力。

瀑布模型还是一种理想化模型：需求要足够稳定甚至不变、设计者要有超强的前瞻性、实现者要有极强的业务能力及适应性。

针线互联网项目、变化快的项目（如互联网应用、电商APP、SaaS平台），都存在着大量的不可控风险：市场/客户需求每天都在随着商业发展、技术发展在变化，我们无法完全预料到未来会发生的所有问题，无法快速响应快速改变。