軟體開發流程模型 (Software Process Models)

1. 瀑布模型 (The Waterfall Model)

瀑布模型是第一個被公佈的軟體開發流程模型，源自於大型軍事系統工程。它是一種**計畫驅動（Plan-driven）**的流程，在開始開發前，必須先規劃與排定所有活動的時程。

核心階段：該模型將開發流程分為獨立的階段，包含：需求分析與定義、系統和軟體設計、實作和單元測試、整合與系統測試，以及運行與維護。
運作方式：每一個階段的產出通常是經過核准（簽核）的文件。原則上，前一個階段完成後，下一個階段才能開始，如同瀑布般向下流動。
優點：架構嚴謹，每個階段都有明確的產出與文件，對於硬體開發或管理規範嚴格的專案非常有用。
缺點：在實際運作中，各個階段往往會重疊且資訊會相互回饋。其最大的缺點是缺乏彈性，過早凍結需求會導致無法適應客戶不斷改變的需求，最終開發出不符期望的系統。
適用場景：需要與硬體介接的嵌入式系統、對安全性與可靠性要求極高（需經過詳細分析與記錄）的關鍵系統，以及由多家合作夥伴共同開發的大型軟體系統。

增量開發是目前應用程式和軟體產品中最常見的方法。它交錯進行規格制定、開發和驗證活動。

核心概念：系統透過一系列的版本（增量）來開發，每一個版本都比前一個版本增加新的功能。早期的增量通常會先實作最重要或最迫切需要的功能。
運作方式：可以採用計畫驅動、敏捷開發，或是兩者的混合。它反映了人類解決問題的常見模式：先採取出步解決方案，當發現錯誤時再回溯修改。
優點：
- 降低變更成本：修改需求的成本大幅降低，需要重做的分析與文件比瀑布模型少很多。
- 易於獲取回饋：客戶可以對軟體展示提出意見，比從設計文件中判斷進度容易得多。
- 及早交付：即便功能尚未完全，客戶仍能及早使用並從中獲得價值。
缺點：對於管理層而言「流程不可見」，缺乏定期產出的文件以衡量進度；此外，隨著增量不斷加入，系統結構容易退化，程式碼可能會變得凌亂。
適用場景：需求可能會在開發過程中不斷變化的業務系統或軟體產品。

V模型是瀑布模型與計畫驅動流程中的一個變體，它特別強調**驗證（Verification）與確認（Validation）**的階段。

核心概念：V模型將軟體的驗證活動與瀑布流程中對應的開發階段連接起來。
運作方式：在嚴謹的系統開發中，測試是由一系列測試計畫驅動的。V模型顯示了需求規格、系統規格、系統設計和元件設計等階段，如何分別對應並產生客戶測試計畫、系統整合測試計畫、以及子系統整合測試計畫。將傳統線性模型折疊成 V 字型後，可以清楚看出每一個開發階段都有一個對應的測試與驗證階段。
適用場景：需要嚴格品質控管與獨立測試團隊的關鍵系統開發。

為了克服重量級、計畫驅動方法（如瀑布模型）在應對變更時的龐大負擔，敏捷方法於1990年代後期被提出。

核心概念：敏捷方法將設計與實作視為軟體流程的核心活動，把需求引出和測試整合到設計與實作中，並以快速產出可用軟體為目標。
敏捷宣言核心價值：個人與互動重於流程與工具；可用的軟體重於詳盡的文件；客戶合作重於合約協商；回應變化重於遵循計畫。
代表實踐與框架：
- 極限程式設計 (Extreme Programming, XP)：將迭代開發推向極致，包含使用者故事 (User stories)、測試驅動開發 (Test-first development)、結對程式設計 (Pair programming) 以及持續重構 (Refactoring) 等實踐。
- Scrum：專注於敏捷專案管理的框架，包含衝刺 (Sprint)、產品待辦清單 (Product backlog) 和 ScrumMaster 等概念，是目前最廣泛使用的敏捷方法。
優點：能快速交付功能，適應需求的快速變更，將客戶納入開發團隊以確保系統符合真實需求。
適用場景：中小型軟體產品的開發，或是組織內部有客戶強力參與且法規限制較少的客製化系統開發。

這種模型建立在現有軟體元件與系統可以被重複使用的基礎上。

由軟體工程先驅 Barry Boehm 所提出，是一種**風險驅動（Risk-driven）**的增量開發模型。

核心概念：軟體流程不表示為一系列活動，而是表示為一個螺旋。螺旋中的每一個迴圈代表軟體流程中的一個階段（例如最內圈評估可行性，下一圈定義需求，再下一圈系統設計）。
特點：它結合了「避免變更」與「容忍變更」的概念，並假設所有變更都是專案風險所造成的。因此，該模型納入了明確的「風險管理活動」來降低專案風險。在開發過程中，螺旋模型可以根據細節程度容納不同的開發方法，甚至可以結合原型設計 (Prototyping) 以釐清需求並降低風險。
適用場景：高風險、大型、複雜，且在初期難以釐清所有潛在問題的軟體專案。