1988 - 螺旋模式：Barry Boehm 的風險驅動開發#

案件摘要#

1988 年，Barry Boehm（巴利·玻姆）發表 "A Spiral Model of Software Development and Enhancement"。它把開發過程畫成一圈圈向外擴張的螺旋：每一圈都要先辨識風險、處理風險，再決定下一步要原型、要分析、還是直接開發。瀑布問「流程走到哪」、XP 問「測試過了沒」，螺旋模式問的是：下一輪最大的風險是什麼？

前因 -- 為什麼會有這個案子#

瀑布的罩門：線性流程把風險留到晚期（整合、上線）才引爆——需求錯了要整個回頭。
原型的先驅：Boehm 自己 1984 年的「prototyping」論文與 1981 年《Software Engineering Economics》已指出：早期用便宜的原型驗證關鍵假設。
大型專案的需求：國防與企業系統規模太大，XP 的小團隊迭代不夠用；但純瀑布又太脆——需要「可擴展且風險導向」的方法。
關鍵推理：開發不是線性而是螺旋——每圈經過四個象限：

\[ \text{每圈} = \underbrace{\text{目標設定}}_{Q_1} \to \underbrace{\text{風險評估}}_{Q_2} \to \underbrace{\text{開發與驗證}}_{Q_3} \to \underbrace{\text{規劃下一圈}}_{Q_4} \]

風險是方向盤：風險高就走重流程（原型/模擬），風險低就走輕流程——風險決定流程的重量。

線索與推理 -- 數學式、程式、理論#

1. 案件現場：螺旋的四個象限#

每一圈（cycle）經過四個象限，向外擴張（規模與完整度增加）：

目標設定（Determine objectives）：這一圈要解決什麼？成功的條件是什麼？定出約束與替代方案。
風險評估（Evaluate alternatives / identify risks）：辨識並正面處理風險——原型、模擬、benchmark、使用者測試。
開發與驗證（Develop and verify）：依風險處理結果，走最合適的流程（可能是一小段瀑布、可能是一次原型迭代）。
規劃下一圈（Plan next iteration）：檢視成果、承諾下一圈目標。

\[ \text{螺旋模式} = \underbrace{\text{瀑布的紀律}}_{\text{每圈有計畫}} \times \underbrace{\text{原型的回饋}}_{\text{早期驗證}} \times \underbrace{\text{風險的方向盤}}_{\text{決定流程重量}} \]

2. 風險決定流程重量#

\[ \text{流程重量} = f(\text{風險}),\qquad \text{風險} = \underbrace{P_{\text{failure}}}_{\text{失敗機率}} \times \underbrace{C_{\text{failure}}}_{\text{失敗代價}} \]

風險高（如新技術、效能瓶頸）→ 投入原型與模擬，先殺風險再開發。
風險低（如 CRUD 頁面）→ 直接開發，不必儀式化。
這是「風險驅動」與「儀式驅動」（純瀑布）的根本差異——資源花在刀口上。

3. COCOMO：Boehm 的估算理論#

Boehm 的《Software Engineering Economics》（1981）給出 COCOMO 估算模型：

\[ E = a \cdot (\text{KLOC})^{b} \quad\text{（人月）},\qquad \text{有機型}: a=2.4, b=1.05;\ \ \text{嵌入型}: a=3.6, b=1.20 \]

規模的指數 \(b > 1\) ：程式越大、每千行的成本越高（複雜度非線性）。
COCOMO II（2000）加入重用、風險係數與成本驅動因子——估算與螺旋的風險評估互相配合。

4. 螺旋 vs 瀑布 vs 敏捷#

	瀑布	螺旋模式	敏捷/XP
結構	線性階段	螺旋圈	短迭代
方向盤	計畫	風險	客戶回饋
回饋時機	晚期	每圈（風險處理後）	每 Sprint
適合規模	小而穩定	大型、風險高	小至中型
弱點	需求變更	風險分析要專家	規模擴展

螺旋模式是「大型專案的敏捷前身」：RUP（Rational Unified Process, 1998）直接繼承其迭代與風險思想。
敏捷（2001）與螺旋的差異：敏捷以客戶回饋為方向盤，螺旋以風險為方向盤——大型系統兩者都要。

5. Python 實作：風險驅動的螺旋模擬#

import math

def risk(pf, cf):
    return pf * cf                              # 風險 = 失敗機率 × 代價

def spiral_cycles(risks, budget_per_cycle=3):   # 每圈最多處理 3 項風險
    risk_list = sorted(risks, key=lambda r: -risk(*r))   # 風險高者先辦
    cycles, handled = [], []
    for i in range(0, len(risk_list), budget_per_cycle):
        batch = risk_list[i:i + budget_per_cycle]
        handled += batch
        remaining = sum(risk(*r) for r in risk_list[i + budget_per_cycle:])
        cycles.append((len(handled), sum(risk(*r) for r in batch), remaining))
    return cycles

risks = [('新技術選型', 0.4, 100), ('效能瓶頸', 0.3, 80),
         ('需求誤解', 0.5, 60), ('介面整合', 0.2, 50), ('安全漏洞', 0.1, 90)]
print("螺旋模擬（風險 = P × C，風險高者先辦）：")
for n, resolved, remaining in spiral_cycles(risks):
    print(f"  第 {n} 項風險處理後：本圈消除 {resolved:.0f}，剩餘風險 {remaining:.0f}")
# 第 3 項風險處理後：本圈消除 86，剩餘風險 39
# 第 5 項風險處理後：本圈消除 53，剩餘風險 0

def cocomo(kloc, a, b):
    return a * kloc ** b
for name, a, b in [('有機型', 2.4, 1.05), ('半分離型', 3.0, 1.12), ('嵌入型', 3.6, 1.20)]:
    print(f"COCOMO {name}（10 KLOC）= {cocomo(10, a, b):.1f} 人月")
# COCOMO 有機型（10 KLOC）= 26.9 人月
# COCOMO 半分離型（10 KLOC）= 33.7 人月
# COCOMO 嵌入型（10 KLOC）= 57.1 人月  ← 規模指數 b>1：越大越貴

結案 -- 後果與影響#

風險驅動成為學科語言：辨識→分析→處理→監控的風險管理流程進入 PMBOK 與 SE 學科。
RUP 的直系血親：Rational Unified Process（1998）的迭代與風險思想直接繼承螺旋模式；COCOMO II（2000）成為估算標準。
敏捷的互補面：敏捷管小回饋、螺旋管大風險——大型專案（國防、金融、汽車）至今仍用螺旋式思維。
Boehm 的雙遺產：估算（COCOMO）與風險（螺旋）——軟體經濟學的奠基人；2020s 的 AI 專案管理仍引用其框架。

關鍵人物與文獻#

Barry Boehm（USC/SEI/TRW）：《Software Engineering Economics》, 1981；"A Spiral Model of Software Development and Enhancement", IEEE Computer, 1988。
Winston Royce（1970）：瀑布模型的原始論文（見 1970-Waterfall瀑布模型.md）。
Walker Royce（RUP）：迭代式開發的商業化傳承。
B. Boehm et al., Software Cost Estimation with COCOMO II, Prentice Hall, 2000。
相關案件：1970-Waterfall瀑布模型.md、2001-Agile宣言.md、1975-神話人月.md。