瀑布式軟體開發 (Waterfall Software Development) 我想大家應該都很熟悉,是由 Winston W. Royce 所提出. 它將開發活動分解為線性順序的階段, 每個階段都依賴前一個階段的可交付成果, 收到那個結果後, 會處理相對應的特定任務. 以下是相關的階段:
圖 11-1 瀑布式開發的階段
瀑布式模型認為,只有當前一階段經過審查和驗證後, 才應該進入下一階段. 但是後來業界在使用時, 過程中如有輕微變動或是發現不足, 會回上一個階段, 或是上幾個階段, 把相關資訊補足就可.
其實在 Royce 最初的文章中, 提到瀑布式開發的循序作法是有缺點的, 因此他最終的提議是這樣的
在編碼開始之前完成程式設計
文件必須是最新且完整的
如果可能的話,做兩次工作
Royce 認為是一次循環是有風險的, 他希望至少兩次.
必須規劃、控制和監控測試
測試很重要, 每個階段都要規劃相對應的測試.
讓客戶參與
即時回饋才能立刻調整, 不要等到最後才知道客戶的反應是什麼
所以他想做的事情, 跟後來出現的敏捷和 DevOps 是接近的, 後面這些作法幫他把細部處理給補齊了.
圖 11-2 Royce 最終的開發模型
接著我們詳細介紹一下每個階段在做什麼, 不過這邊先從開發角度來說明, 如圖 11-3 所示:
需求分析:
定義專案目標和範圍, 讓大家知道為何而戰. 並且記錄產品需求, 產生模型、模式和業務規則.
架構設計:
產生軟體架構, 設計模組之間要如何協作
細部設計:
產生模組的細部運作細節. 定義好相關呼叫介面
開發:
軟體的開發, 單元的驗證與整合
測試:
系統地發現產品的問題. 進行測試的執行, 找到 bug 要分析為甚麼出現, 以及要如何修復, 修復完後需要進行驗證, 並且確保原先功能不被影響
接案和維護:
如果是專案層級, 需要準備好專案結案報告, 把相關文件和程式準備好. 然後再看看客戶要如何進行維護案.
如果是產品層級, 需要準備系統的安裝部署, 後續會有維護和支援回應等問題.
圖 11-3 瀑布式開發階段的細部說明
Royce 有提到問間要最新且完整, 這雖然不容易做到, 但是至少要知道可能需要哪些文件. 在這些過程中, 我們需要產生的文件如下:
圖 11-4 瀑布式開發階段所需處理的文件
知道了這些開發階段以及產出的文件, 接下來我們就看看他們和測試的關聯, 基本上可以分成這些大的階段
圖 11-5 開發階段對應要做的測試項目
接下就是細部測試活動的介紹:
圖 11-6 開發階段對應的詳細測試活動
個人淺見,瀑布式開發有其成立的背景,用意很好,再加上長官們都熟悉的前提下,用瀑布式開發做為向上溝通,仍是個好方法;至於擁抱變革的工程師團隊們,還是可以用敏捷的精神和方式來進行,二式並用,應該可以一兼二顧吧