瀑布模型
出自 MBA智库百科(https://wiki.mbalib.com/)
瀑布模型（Waterfall Model）
目錄 |
1970年溫斯頓·羅伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被廣泛採用的軟體開發模型。
瀑布模型將軟體生命周期劃分為制定計劃、需求分析、軟體設計、程式編寫、軟體測試和運行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。從本質來講，它是一個軟體開發架構，開發過程是通過一系列階段順序展開的，從系統需求分析開始直到產品發佈和維護，每個階段都會產生迴圈反饋，因此，如果有信息未被覆蓋或者發現了問題，那麼最好 “返回”上一個階段併進行適當的修改，開發進程從一個階段“流動”到下一個階段，這也是瀑布開發名稱的由來。
瀑布模型核心思想是按工序將問題化簡，將功能的實現與設計分開，便於分工協作，即採用結構化的分析與設計方法將邏輯實現與物理實現分開。瀑布模型將軟體生命周期劃分為軟體計劃、需求分析和定義、軟體設計、軟體實現、軟體測試、軟體運行和維護這6個階段，規定了它們自上而下、相互銜接的固定次序，如同瀑布流水逐級下落。採用瀑布模型的軟體過程如下圖所示：
瀑布模型是最早出現的軟體開發模型，在軟體工程中占有重要的地位，它提供了軟體開發的基本框架。其過程是從上一項活動接收該項活動的工作對象作為輸入，利用這一輸入實施該項活動應完成的內容給出該項活動的工作成果，並作為輸出傳給下一項活動。同時評審該項活動的實施，若確認，則繼續下一項活動；否則返回前面，甚至更前面的活動。
1、瀑布模型有以下優點：
1）為項目提供了按階段劃分的檢查點。
2）當前一階段完成後，您只需要去關註後續階段。
3）可在迭代模型中應用瀑布模型。
增量迭代應用於瀑布模型。迭代1解決最大的問題。每次迭代產生一個可運行的版本,同時增加更多的功能。每次迭代必須經過質量和集成測試。
2、瀑布模型有以下缺點：
1）在項目各個階段之間極少有反饋。
2）只有在項目生命周期的後期才能看到結果。
3）通過過多的強制完成日期和里程碑來跟蹤各個項目階段。
儘管瀑布模型招致了很多批評，但是它對很多類型的項目而言依然是有效的，如果正確使用，可以節省大量的時間和金錢。對於您的項目而言，是否使用這一模型主要取決於您是否能理解客戶的需求以及在項目的進程中這些需求的變化程度，對於經常變化的項目而言，瀑布模型毫無價值，對於這種情況，您可以考慮其他的架構來進行項目管理，比如名為螺旋模型（spiral model）的方法。
各種軟體過程模型的特點[1]
不同的軟體過程模型對軟體開發過程有不同的理解和認識，支持不同的軟體項目和開發組織。下表對比和分析了各個軟體過程模型的特點及其適用的軟體項目類型。
各種軟體過程模型的特點
| 模型名稱 | 技術特點 | 適用範圍 |
|---|---|---|
| 瀑布模型 | 簡單，分階段，階段間存在因果關係，
各個階段完成後都有評審，允許反饋，不支持 用戶參與，要求預先確定需求 | 需求易於完善定義且不易變更的軟體系統 |
| 快速原型模型 | 不要求需求預先完備定義，支持用戶參與，
支持需求的漸進式完善和確認，能夠適應用戶需求的變化 | 需求複雜、難以確定、動態變化的軟體系統 |
| 增量模型 | 軟體產品是被增量式地一塊塊開發的，
允許開發活動並行和重疊 | 技術風險較大、用戶需求較為穩定的軟體系統 |
| 迭代模型 | 不要求一次性地開發出完整的軟體系統，將軟體
開發視為一個逐步獲取用廣需求、完善軟體產品的過程 | 需求難以確定、不斷變更的軟體系統 |
| 螺旋模型 | 結合瀑布模型、快速原型模型和迭代模
型的思想，並引進了風險分析活動 | 需求難以獲取和確定、軟體開發風險較大的軟體系統 |
| RUP | 可改造、擴展和剪裁：可以對它進行設計、
開發、維護和發佈；強調迭代開發 | 複雜和需求難以獲取和確定的軟體系統；
軟體開發項目組擁有豐富的軟體開發和管理經驗 |
- ↑ 譚慶平,毛新軍,董威.軟體工程實踐教程[M].高等教育出版社,2009.04.
