1. 瀑布模型（Waterfall Model）

核心思想

实现方法

1. 完整完成当前阶段产出物（需求规格说明书、设计文档等）；
2. 组织评审，评审通过、基线固化；
3. 文档作为阶段交付物，传递给下一阶段；
4. 后期发现问题，回溯到前面阶段成本很高。

✅ 优点

1. 结构简单清晰，流程规范，便于管理、计划和跟踪；
2. 文档驱动，每个阶段都有完整产出，可审计；
3. 适合分工，不同角色（需求、设计、开发、测试）各司其职；
4. 基线明确，版本可控。

❌ 缺点

1. 无法适应需求变更，需求改动代价巨大；
2. 用户要等到项目末期才能看到可运行软件，前期无法验证；
3. 风险集中在后期，前期隐藏的缺陷最后才暴露；
4. 迭代能力差，不适合模糊、探索型项目。

使用场景

1. 需求非常明确、稳定，变更极少；
2. 安全、合规要求高，需要严格文档审计：军工、航空、医疗嵌入式、政府大型涉密项目；
3. 短周期、需求确认充分的小型项目。          
   ❌ 不适合：互联网产品、需求不确定、需要快速试错的项目。

2. 原型模型（Prototype Model）

核心思想

实现方法

1. 和用户沟通，提炼核心疑问点；
2. 使用快速工具（低代码、mock、简易 demo）快速构建原型；
3. 用户评审原型，提出修改意见；
4. 反复修改原型，直到需求达成共识；

✅ 优点

1. 需求模糊场景下，用户可以提前体验、快速反馈；
2. 减少需求理解偏差，避免后期大规模返工；
3. 降低需求风险，沟通更直观；
4. 适合 UI 交互、业务流程不确定的系统。

❌ 缺点

1. 如果管控不好，原型容易直接被当成正式系统交付，代码质量差；
2. 用户容易对原型性能、稳定性产生过高预期；
3. 原型开发容易陷入无休止的需求变更、范围蔓延；
4. 需要额外投入原型开发时间。

使用场景

1. 用户说不清需求、业务流程不明确；
2. 侧重交互界面、业务流程类系统（后台管理、C 端产品、信息化系统）；
3. 新产品预研、验证业务可行性。

3. 螺旋模型（Spiral Model）

核心思想

实现方法

1. 计划：确定本轮目标、需求、约束；
2. 风险分析：识别风险、评估风险、制定风险应对方案；风险高就先做原型验证；
3. 开发与验证：开发产品片段（原型 / 版本），测试；
4. 评审：客户、干系人评审，决定是否进入下一轮螺旋。          
   循环多轮，逐步完善产品，直到交付。

✅ 优点

1. 以风险为核心，高风险项目非常友好，风险提前暴露、提前控制；
2. 支持迭代，允许需求逐步明确；
3. 结合原型验证风险，兼顾规范和灵活性；
4. 适合大型、复杂、高风险项目。

❌ 缺点

1. 复杂度高，要求团队具备很强的风险分析能力；
2. 周期长、成本高；
3. 风险评估本身依赖经验，评估不到位会失效；
4. 管理难度大，小项目用它过重、浪费。

使用场景

1. 大型、复杂、高风险项目；
2. 软件需求、技术方案有很多不确定因素；
3. 大型系统、新项目技术预研 + 开发一体；          
   ❌ 不适合：小型、低风险、需求稳定的简单项目。

对比汇总表