文章目录软件开发模型系列三螺旋模型 —— 让风险来驱动一切1、什么是螺旋模型2、为什么需要螺旋模型3、风险分析螺旋模型的灵魂3、历史实例TRW-SPS 项目4、螺旋模型的优点风险管理是内置的不是附加的适合高风险、高不确定性项目支持早期决策兼顾多种方法的优点5、螺旋模型的局限复杂且昂贵依赖有经验的团队不适合合同驱动的外包项目终止条件模糊6、螺旋模型的当代影响7、本篇要点速记补充软件开发模型系列三螺旋模型 —— 让风险来驱动一切瀑布和 V 模型都假设需求是确定的但现实中有些项目从一开始就充满未知。螺旋模型的创造者 Barry Boehm 说既然风险不可避免那就让风险来主导开发过程。1、什么是螺旋模型螺旋模型Spiral Model由美国软件工程大师Barry W. Boehm于 1986 年在论文“A Spiral Model of Software Development and Enhancement”中正式提出。它是软件工程史上第一个风险驱动Risk-Driven的开发模型。想象一个从中心向外不断扩大的螺旋进入下一圈半径更大① 确定目标方案与约束② 风险评估识别 · 分析 · 缓解 · 原型验证③ 开发验证设计 · 编码 · 测试④ 评审规划评估成果 · 规划下一轮说明Mermaid 画不出半径递增的螺旋线这里用四象限闭环 下一圈半径更大的回环来表达。若要忠实还原 Boehm 论文里的经典螺旋形需要单独的 SVG 图。每一圈螺旋包含四个阶段象限活动核心问题第一象限确定目标、方案与约束这一轮要达成什么有哪些选项第二象限风险识别与评估、原型开发最大的风险是什么怎么降低它第三象限工程开发与验证设计、编码、测试本轮要交付的内容第四象限评审与规划下一轮干得怎么样下一轮做什么2、为什么需要螺旋模型瀑布和 V 模型面对的是这样的项目需求明确 → 流程清晰 → 按时交付但有一类项目是这样的技术可行性未知这个算法真的能跑吗 性能目标不确定能做到实时吗 需求随时可能调整市场还在验证中 外部依赖不可控供应商的 SDK 稳定吗这类项目如果硬套瀑布模型大概率会翻车。Boehm 自己的总结很精准“瀑布模型是文档驱动的增量模型是代码驱动的螺旋模型是风险驱动的。在每一个决策点你先问的不是’下一步该做什么’而是’什么最可能让这个项目失败’。”3、风险分析螺旋模型的灵魂螺旋模型和其他模型最本质的区别在于第二象限风险评估。在每个螺旋周期开始团队必须系统性地回答┌────────────────────────────────┐ │ 风险识别 │ │ - 技术风险算法可行吗 │ │ - 人员风险关键人才会离职吗 │ │ - 进度风险供应商能按时交付吗 │ │ - 需求风险用户真的需要这个吗 │ ├────────────────────────────────┤ │ 风险评估 │ │ - 发生概率有多高 │ │ - 影响有多大 │ │ - 哪些风险必须优先处理 │ ├────────────────────────────────┤ │ 风险缓解 │ │ - 原型验证 │ │ - 技术预研Spike │ │ - 备选方案 │ │ - 如果无法缓解 → 终止项目 │ └────────────────────────────────┘螺旋模型有一个看似残酷但实际很理性的设计如果某个风险无法被有效缓解就应该尽早终止项目。比起瀑布模式下开发两年才发现项目不可行这种早死早超生反而更节省资源。3、历史实例TRW-SPS 项目Boehm 在他的论文中详细描述了螺旋模型的首次实践——TRW 软件生产力系统TRW-SPS一个 130 万行代码的超大型系统。第 0 轮最内圈可行性研究 → 这个项目值不值得做 → 产出概念文档 风险评估报告 第 1 轮概念验证 → 关键技术上能走通吗 → 产出概念原型 更新的风险清单 第 2 轮顶层设计 → 架构能不能支撑预期的规模 → 产出软件需求规格 架构原型 第 3 轮详细设计与实现 → 开始正式开发 → 产出可运行的产品增量每一轮都是前一轮的放大版风险逐层被消化。不是等所有需求都决定了再动手而是先解决最不确定的部分。4、螺旋模型的优点风险管理是内置的不是附加的在瀑布模型中风险管理通常是项目经理自己默默担心、偶尔在周会上提一嘴。螺旋模型把它变成了正式的、必须执行的流程步骤。适合高风险、高不确定性项目典型场景风险来源自动驾驶系统技术可行性、安全标准航天软件极端环境、不可维护金融交易系统性能、数据一致性AI/ML 产品模型效果不可预测机器人系统硬件-软件协同不确定性支持早期决策因为每一轮结束都要重新评估值不值得继续螺旋模型天然支持止损决策。对于探索性项目这个特性非常重要。兼顾多种方法的优点Boehm 有意将瀑布模型的系统性、原型法的探索性和增量模型的迭代特性都融合进了螺旋模型中。5、螺旋模型的局限复杂且昂贵四个象限的完整执行需要大量文档、评审和分析工作。对小型项目来说风险管理本身的成本可能就超过了项目预算。依赖有经验的团队风险评估不是一个初级程序员或初级项目经理能胜任的工作。螺旋模型要求团队中有经验丰富的系统架构师和风险管理专家。不适合合同驱动的外包项目螺旋模型假设项目目标和范围可以灵活调整但这与固定价格、固定工期的外包合同天然冲突。客户会说“你别跟我谈螺旋我就要这个功能、这个时间、这个价格。”终止条件模糊什么时候可以停止螺旋没有一个明确的答案。如果风险评估团队过于保守项目可能永远在原型阶段打转。6、螺旋模型的当代影响虽然今天很少有人完全按照 Boehm 的四象限模型来做项目但螺旋模型的核心思想已经渗透进了几乎所有现代开发方法中螺旋模型的影响可见于 Agile 的 Sprint → 每个 Sprint 本质上是一个迷你螺旋 计划→开发→评审→回顾 确定目标→开发→评审→规划下一轮 Design Thinking → 先做原型验证最关键的假设 螺旋的第二象限 Lean Startup 的 Build-Measure-Learn → 风险驱动的快速迭代 技术 Spikes → 敏捷团队做技术预研时本质上在跑一个单圈螺旋7、本篇要点速记螺旋模型 风险驱动 四象限循环 原型验证 诞生于 1986 年Barry Boehm 提出。 核心循环目标 → 风险分析 → 开发 → 评审 → 下一轮 灵魂所在第二象限的风险评估识别、分析、缓解、必要时终止 优点 → 风险管理内置、适合高风险项目、支持早期止损 局限 → 复杂昂贵、依赖经验、不适合合同外包 一句话什么时候开始编码不重要什么时候确定最大的风险已经解决了才重要。补充第一性原理结论软件开发/算法研发的本质是一个信息熵减的过程。螺旋模型通过高频的“假设-验证-反馈”闭环用最小的成本原型去换取最大的信息量风险消除从而在混沌中逐步逼近最终的正确解。在目标检测任务中螺旋模型体现为“不要试图一次性设计出一个完美的网络”。而是通过不断构建 Baseline - 分析 Bad Case暴露风险- 针对性修改网络结构/数据策略消除风险- 评估部署可行性像螺旋一样一圈圈将模型的精度、鲁棒性和工程落地能力提升到目标水平。上一篇V 模型下一篇迭代开发 —— 先让东西跑起来再慢慢变好