瀑布模型（Waterfall Model） 是一個專案開發架構，開發過程是透過設計一系列階段順序展開的，從系統需求分析開始直到產品釋出和維護，每個階段都會產生迴圈反饋，因此，如果有資訊未被覆蓋或者發現了問題，那麼最好 “返回”上一個階段並進行適當的修改，專案開發程序從一個階段“流動”到下一個階段，這也是瀑布模型名稱的由來。包括軟體工程開發、企業專案開發、產品生產以及市場銷售等構造瀑布模型。

定義

瀑布模型是將軟體生存週期的各項活動規定為按固定順序而連線的若干階段工作，形如瀑布流水，最終得到軟體產品。

1970年溫斯頓·羅伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被廣泛採用的軟體開發模型。

核心思想

瀑布模型核心思想是按工序將問題化簡，將功能的實現與設計分開，便於分工協作，即採用結構化的分析與設計方法將邏輯實現與物理實現分開。將軟體生命週期劃分為制定計劃、需求分析、軟體設計、程式編寫、軟體測試和執行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。

重要地位

瀑布模型

瀑布模型是最早出現的軟體開發模型，在軟體工程中佔有重要的地位，它提供了軟體開發的基本框架。其過程是從上一項活動接收該項活動的工作物件作為輸入，利用這一輸入實施該項活動應完成的內容給出該項活動的工作成果，並作為輸出傳給下一項活動。同時評審該項活動的實施，若確認，則繼續下一項活動；否則返回前面，甚至更前面的活動。對於經常變化的專案而言，瀑布模型毫無價值。

模型優缺點

瀑布模型有以下優點

瀑布模型

1）為專案提供了按階段劃分的檢查點。

2）當前一階段完成後，您只需要去關注後續階段。

3）可在迭代模型中應用瀑布模型。

增量迭代應用於瀑布模型。迭代1解決最大的問題。每次迭代產生一個可執行的版本,同時增加更多的功能。每次迭代必須經過質量和整合測試。

4）它提供了一個模板，這個模板使得分析、設計、編碼、測試和支援的方法可以在該模板下有一個共同的指導。

瀑布模型有以下缺點

1）各個階段的劃分完全固定，階段之間產生大量的文件，極大地增加了工作量。

2）由於開發模型是線性的，使用者只有等到整個過程的末期才能見到開發成果，從而增加了開發風險。

3）透過過多的強制完成日期和里程碑來跟蹤各個專案階段。

4）瀑布模型的突出缺點是不適應使用者需求的變化。

模型客戶需求

儘管瀑布模型招致了很多批評，但是它對很多型別的專案而言依然是有效的，如果正確使用，可以節省大量的時間和金錢。對於您的專案而言，是否使用這一模型主要取決於您是否能理解客戶的需求以及在專案的程序中這些需求的變化程度，對於經常變化的專案而言，瀑布模型毫無價值，對於這種情況，您可以考慮其他的架構來進行專案管理，比如名為螺旋模型（spiral model）的方法。

在瀑布模型中，軟體開發的各項活動嚴格按照線性方式進行，當前活動接受上一項活動的工作結果，實施完成所需的工作內容。當前活動的工作結果需要進行驗證，如果驗證透過，則該結果作為下一項活動的輸入，繼續進行下一項活動，否則返回修改。

瀑布模型強調文件的作用，並要求每個階段都要仔細驗證。但是，這種模型的線性過程太理想化，已不再適合現代的軟體開發模式，幾乎被業界拋棄，其主要問題在於：

（1） 各個階段的劃分完全固定，階段之間產生大量的文件，極大地增加了工作量。

（2） 由於開發模型是線性的，使用者只有等到整個過程的末期才能見到開發成果，從而增加了開發的風險。

（3） 早期的錯誤可能要等到開發後期的測試階段才能發現，進而帶來嚴重的後果。

按照瀑布模型的階段劃分，軟體測試可以分為單元測試，整合測試，系統測試。