瀑布模型是現代軟件工程的起源，軟件工程的發展，很大部分都是構建於瀑布模型的基礎之上的。起源是1970年，Winston Royce博士借鑑了建築工程領域的思想，提出了瀑布開發模型，指出軟件開發應有完整週期，把軟件開發過程分成了若干階段，類似於瀑布一樣，從上往下，完成一個階段繼續下一個階段。
瀑布模型把整個項目過程分成了六個主要階段：
一、問題的定義及規劃
本階段是需求方和開發方共同確定軟件開發目標，同時做可行性研究，以確定項目可行，這個階段產生需求文檔和可行性研究報告
二、需求分析
對需求方提出的所有需求要進行詳細分析和反覆確認，以保證能夠充分理解客戶需求，最終形成需求分析文檔。
三、軟件設計
根據需求分析結果，對整個軟件系統進行抽象和設計，如系統框架設計、數據庫設計等，最終形成架構設計文檔
四、程序編碼
將架構設計和界面設計的結果轉換成計算機能運行的程序代碼
五、軟件測試
編碼完成後對可運行的結果對照需求分析文檔進行嚴密測試，提Bug單，最終形成測試報告
六、運行維護
軟件開發完成正式投入使用，後續需要繼續維護、修復錯誤和增加功能，交付時需要提供使用說明文檔
瀑布模型因其簡單可行，切實有效，在很多軟件項目中快速應用起來，也有了“軟件生命週期（Software Life Cycle,SLC）”概念。現在雖然瀑布模型已經不是最主流的開發模式，但是不管什麼開發模式，需求、設計、編碼和測試這四項活動都是起源於瀑布模型，也是瀑布模型中核心的部分。
瀑布模型最大問題也就是不能及時響應需求變更，越到後期變更代價越大，而且通常要到後期才能看到項目結果是什麼樣子；這樣會導致開發和測試階段加班特別嚴重。
總結：
瀑布模型的出現，解決了軟件項目開發中的幾個重要問題：
- 讓軟件開發過程有序可控。瀑布模型每個階段都有明確任務、交付產物和里程碑，整個過程可控，及早發現問題
- 讓分工協作變成可能。瀑布模型的六個階段，讓軟件開發產生基礎分工：項目經理、產品經理、架構師、軟件工程師、測試工程師、運維工程師。
- 質量有保障。瀑布模型每個階段都需要交付相應的文檔，文檔的撰寫和評審在動手之前都會把問題溝通清楚，編碼結束後有嚴格的測試，測試驗收通過才能部署上線，這讓軟件質量更有保障。