軟件工程之美3講——瀑布模型：像工廠流水線一樣把軟件開發分層化
瀑布模型的誕生
爲了解決軟件危機中的這些問題，在 1970 年，Winston Royce 博士借鑑了其他工程領域的思想，比如建築工程，提出了瀑布開發模型，指出軟件開發應有完整之週期，並將軟件開發過程分成了若干階段。像瀑布一樣，從上往下，完成一個階段繼續下一個階段。
瀑布模型把整個項目過程分成了六個主要階段：
- 一、問題的定義及規劃
這個階段是需求方和開發方共同確定軟件開發目標，同時還要做可行性研究，以確定項目可行。這個階段會產生需求文檔和可行性研究報告。
- 二、需求分析
對需求方提出的所有需求，進行詳細的分析。這個階段一般需要和客戶反覆確認，以保證能充分理解客戶需求。最終會形成需求分析文檔。 - 三、軟件設計
根據需求分析的結果，對整個軟件系統進行抽象和設計，如系統框架設計，數據庫設計等等。最後會形成架構設計文檔。
- 四、程序編碼
將架構設計和界面設計的結果轉換成計算機能運行的程序代碼。 - 五、軟件測試
在編碼完成後，對可運行的結果對照需求分析文檔進行嚴密的測試。如果測試發現問題，需要修復。最終測試完成後，形成測試報告。 - 六、運行維護
軟件開發完成，正式運行投入使用。後續需要繼續維護，修復錯誤和增加功能。交付時需要提供使用說明文檔。瀑布模型在提出後，因爲其簡單可行，切實有效，馬上就在很多軟件項目中應用起來，一直到 2000 年前後，都是最主流的軟件開發模型，即使到現在，你也能在很多軟件項目中看到它的影子。
瀑布模型的優點和缺點？
-
優點
簡單易行
可以按照階段檢查,能及時發現問題
前一個階段完成後,就可以重點關注下一個階段
有很好的分式協作
對質量有保障 -
缺點
難以響應需求的變更,當需求發生改變時,越到後期代價越大.
工作量分佈不均衡
例如前期開發、測試人員無法參與，而後期開發、測試人員又特別忙碌。
前期進度受阻，會一直壓縮後續階段時間，導致延期或影響質量。
一直到最後階段才能看到結果。