軟體開發的規模放大不是簡單的等比例擴張。一個 25,000 行的專案如果花 20 人月，擴大 10 倍到 250,000 行不會只花 200 人月，而是約 600 人月。更重要的是，建構、架構、系統測試等活動的放大比例各不相同，錯誤數量也會超比例增長。本章說明專案規模如何影響建構的各個面向。
27.1 交流和規模（Communication and Size）#
團隊人數增加時，溝通路徑數量以平方比例增長：
| 團隊人數 | 溝通路徑數 |
|---|---|
| 2 人 | 1 |
| 5 人 | 10 |
| 10 人 | 45 |
| 50+ 人 | 1,200+ |
溝通路徑越多，花在溝通的時間越多，溝通出錯的機會也越多。大型專案必須透過組織手段來精簡或限制溝通。
典型做法是將溝通正式化為文件（文字、圖形、紙本或電子），取代所有人兩兩交談。
27.2 專案規模的範圍（Range of Project Sizes）#
不存在「典型規模」。以團隊大小來看專案分布：
| 團隊規模 | 專案佔比 | 程式設計師佔比 |
|---|---|---|
| 1–3 人 | 25% | 5% |
| 4–10 人 | 30% | 10% |
| 11–25 人 | 20% | 15% |
| 26–50 人 | 15% | 20% |
| 50+ 人 | 10% | 50% |
雖然大型專案只佔全部專案的 10%，卻雇用了約 50% 的程式設計師。
27.3 專案規模對錯誤的影響（Effect of Project Size on Errors）#
錯誤來源隨規模變化#
- 小型專案：約 75% 錯誤來自建構活動，個人技術是品質最大影響因素
- 大型專案：建構錯誤可降至約 50%，其餘來自需求和架構；但某些超大型專案（500K 行）建構錯誤仍可達 75%
缺陷密度隨規模上升#
| 專案規模 | 典型缺陷密度（每千行） |
|---|---|
| < 2K | 0–25 |
| 2K–16K | 0–40 |
| 16K–64K | 0.5–50 |
| 64K–512K | 2–70 |
| 512K+ | 4–100 |
超大型專案的每千行缺陷數可達小型專案的 4 倍。規模越大，需要付出更多努力才能達到同樣的錯誤率。
27.4 專案規模對生產力的影響（Effect of Project Size on Productivity）#
小型專案（< 2,000 行）中，個人技術是生產力最大影響因素。專案規模增大後，團隊大小和組織方式成為主導因素。甚至 2 人團隊 vs. 3 人團隊就能觀察到 39% 的生產力差異。
| 專案規模 | 每人年程式行數 (COCOMO II 標稱值) |
|---|---|
| 1K | 2,500–25,000 (4,000) |
| 10K | 2,000–25,000 (3,200) |
| 100K | 1,000–20,000 (2,600) |
| 1,000K | 700–10,000 (2,000) |
| 10,000K | 300–5,000 (1,600) |
小型專案的生產力可達大型專案的 2–3 倍，最小與最大專案間差距可達 5–10 倍。
27.5 專案規模對開發活動的影響（Effect of Project Size on Development Activities）#
活動比例隨規模變化#
- 小型專案：建構佔總開發時間約 65%
- 中型專案：建構佔約 50%
- 大型專案：架構、整合和系統測試佔比上升，建構佔比持續下降
建構活動隨規模近乎線性增長，但其他活動（溝通、計畫、管理、需求、架構、整合、系統測試、文件產出等）以超線性速率增長。
隨規模超線性增長的活動
- 溝通（Communication）
- 計畫（Planning）
- 管理（Management）
- 需求開發（Requirements development）
- 系統功能設計（System functional design）
- 介面設計與規格（Interface design and specification）
- 架構（Architecture）
- 整合（Integration）
- 缺陷移除（Defect removal）
- 系統測試（System testing）
- 文件產出（Document production）
Boehm 和 Turner 發現：10K 行專案花約 5% 心力在架構和需求可得最低成本；100K 行專案則需花 15–20%。
程式、產品、系統、系統產品#
軟體的精緻度和複雜度也影響規模估算：
| 類型 | 說明 | 相對成本 |
|---|---|---|
| 程式（Program） | 個人使用的單一程式 | 1x |
| 產品（Product） | 供他人使用，需充分測試與文件 | 3x |
| 系統（System） | 多個程式協作，介面與整合複雜 | 3x |
| 系統產品（System Product） | 兼具產品的精緻度和系統的複雜度 | 9x |
flowchart TB
subgraph matrix["軟體四種精緻度 2x2 矩陣"]
direction TB
subgraph row1["多程式協作"]
C["系統<br/>System<br/>（3x）"]
D["系統產品<br/>System Product<br/>（9x）"]
end
subgraph row2["單一程式"]
A["程式<br/>Program<br/>（1x）"]
B["產品<br/>Product<br/>（3x）"]
end
end
row2 --- row1
style A fill:#d4edda,stroke:#28a745
style B fill:#fff3cd,stroke:#ffc107
style C fill:#fff3cd,stroke:#ffc107
style D fill:#f8d7da,stroke:#dc3545
style row2 fill:#f8f9fa,stroke:#6c757d
style row1 fill:#f8f9fa,stroke:#6c757d
style matrix fill:#ffffff,stroke:#343a40用寫「程式」的經驗來估算「系統產品」的時程，可能低估近 10 倍。
方法論與規模#
- 小型專案：方法論傾向非正式、直覺式
- 大型專案：需要嚴謹、有意識地選擇方法論
- 1,000 行專案平均花 7% 心力在文書作業；100,000 行專案則花約 26%
從輕量方法論往上擴展（scale up），效果通常優於從重量級方法論往下精簡（scale down）。最佳做法是找到「適當重量」（right-weight）的方法論。
更多資源#
- Boehm & Turner, Balancing Agility and Discipline (2004) — 敏捷 vs. 計畫驅動方法與專案規模的關係
- Cockburn, Agile Software Development (2002) — 第 4 章討論方法論選擇，第 6 章介紹 Crystal Methodologies
- Boehm, Software Engineering Economics (1981) — 規模對成本、生產力、品質的深入分析
- Jones, Estimating Software Costs (1998) — 大量表格和圖表剖析軟體開發生產力
- Brooks, The Mythical Man-Month (1995) — 大型專案管理的經典論述
要點#
- 專案規模增大時，溝通需求劇增；方法論的核心價值在於促進溝通
- 在其他條件相同下，大型專案的生產力低於小型專案
- 在其他條件相同下，大型專案的每千行錯誤數高於小型專案
- 小型專案中理所當然的活動，在大型專案中必須被仔細規劃；建構活動的佔比隨規模增大而下降
- 從輕量方法論往上擴展，效果優於從重量級方法論往下精簡；最有效的做法是採用「適當重量」的方法論