瀑布模型核心思想是按工序將問題化簡，將功能的實現與設計分開，便於分工協作，即採用結構化的分析與設計方法將邏輯實現與物理實現分開。將軟體生命週期劃分為制定計畫、需求分析、軟體設計、程式編寫、軟體測試和執行維護等六個基本活動，並且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。從本質來講，它是乙個軟體開發架構，開發過程是通過一系列階段順序展開的，
從系統需求分析開始直到產品發布和維護，每個階段都會產生迴圈反饋，因此，如果有資訊未被覆蓋或者發現了問題，那麼最好「返回
」上乙個階段並進行適當的修改，
開發程序從乙個階段「流動
」到下乙個階段，這也是瀑布開發名稱的由來。
瀑布模型是最早出現的軟體開發模型，在軟體工程中占有重要的地位，它提供了軟體開發的基本框架。其過程是從上一項活動接收該項活動的工作物件作為輸入，利用這一輸入實施該項活動應完成的內容給出該項活動的工作成果，並作為輸出傳給下一項活動。同**審該項活動的實施，若確認，則繼續下一項活動；否則返回前面，甚至更前面的活動。對於經常變化的專案而言，瀑布模型毫無價值。
1、瀑布模型有以下優點：
1）為專案提供了按階段劃分的檢查點。
2）當前一階段完成後，您只需要去關注後續階段。
3）可在迭代模型中應用瀑布模型。
增量迭代應用於瀑布模型。
每次迭代產生乙個可執行的版本
,同時增加更多的功能。每次迭代必須經過質量和整合測試。
2、瀑布模型有以下缺點：
1）在專案各個階段之間極少有反饋。
2）只有在專案生命週期的後期才能看到結果。
3）通過過多的強制完成日期和里程碑來跟蹤各個專案階段。
儘管瀑布模型招致了很多批評，但是它對很多態別的專案而言依然是有效的，如果正確使用，可以節省大量的時間和金錢。對於您的專案而言，是否使用這一模型主要取決於您是否能理解客戶的需求以及在專案的程序中這些需求的變化程度，對於經常變化的專案而言，瀑布模型毫無價值，對於這種情況，您可以考慮其他的架構來進行專案管理，比如名為螺旋模型（
spiral model
）的方法。
在瀑布模型中，軟體開發的各項活動嚴格按照線性方式進行，當前活動接受上一項活動的工作結果，實施完成所需的工作內容。當前活動的工作結果需要進行驗證，如果驗證通過，則該結果作為下一項活動的輸入，繼續進行下一項活動，否則返回修改。
按照瀑布模型的階段劃分，軟體測試可以分為單元測試
(模組測試
)，整合測試（組裝測試，或子系統測試），系統測試。具體測試如下：
瀑布模型開發階段
階段
主要工作
應完成的文件
應完成的文件質量控制手段
系統需求
調研使用者需求及使用者環境
可行性報告
規範工作程式及編寫文件
論證專案可行性
專案初步開發計畫
對可行性報告及專案初步
制定專案初步計畫
開發計畫進行評審
需求分析
確定系統執行環境
需求規格說明
在進行需求分析時採用成熟的技術與工具，如結構化分析
建立系統邏輯模型
專案開發計畫
規範工作程式及編寫文件
確定系統功能及效能要求
使用者手冊概要
對已完成的
4種文件進行評審
編寫需求規格說明、使用者手冊概要、
測試
計畫
測試計畫
確認專案開發計畫
概要設計
建立系統總體結構，劃分功能模組
概要設計說明書
在進行系統設計時採用先進的技術與工具，如結構化計
sd、結構圖
sc
定義各功能模組介面
資料庫
設計說明書（如果有）
編寫規範化工作程式及文件
資料庫設計（如果需要）
制定組裝測試計畫
組裝測試計畫
對已完成的文件進行評審
詳細設計
設計各模組具體實現演算法
詳細設計說明書
設計時採用先進的技術與工具，如結構圖
sc
確定模組間詳細介面
模組測試計畫
規範工作程式及編寫文件
制定模組測試方案
對已完成的文件進行評審
實現
編寫程式源**
程式除錯報告
在實現過程中採用先進的技術與工具，如結構圖
sc
進行模組測試和除錯
使用者手冊
規範工作程式及編寫文件
編寫使用者手冊
對實現過程及已完成的文件進行評審
整合測試
執行整合測試計畫
系統源程式清單
測試時採用先進的技術和工具
編寫整合測試報告
整合測試報告
規範工作程式及文件編寫
驗收測試
測試整個軟體系統（健壯性測試）
確認測試報告
試用使用者手冊
使用者手冊
編寫開發總結報告
開發工作總結
對測試工作及已完成的文件進行評審
維護
為糾正錯誤，完善應用而進行修改
故障報告
維護時採用先進的工具
對修改進行配置管理
修改報告
規範工作程式及編寫文件
編寫故障報告和修改報告
配置管理
修訂使用者手冊
對維護工作及已完成的文件進行評審
瀑布模式開發與敏捷開發的比較
最近在學習一些敏捷開發相關的知識，覺得有必要和傳統的瀑布開發模式做個比較。因為瀑布模式仍然被很大程度在使用著，作為技術開發出身我有較深的體會，相信有針對行的對比分析會有更好的理解。關於瀑布模式和敏捷開發的基本特徵可以參照 個人理解對比如下 瀑布模型 敏捷開發 工作方式 1.以文件驅動,將軟體專案開發...
從瀑布開發走向敏捷開發模式下的自動化測試隨筆 IV
後記 在做了一段時間的推廣自動化測試的工作，情不自禁地想把自己的眼光放得更遠一些，究其原因，我很清楚地認識到，測試的最終目的是還是為了提高軟體的質量，而無論是自動化測試，還是continous integration，都還是是軟體的外部看問題。但軟體為什麼一直有解決不完的bug，如果不對軟體的內部有...
從瀑布開發走向敏捷開發模式下的自動化測試隨筆 II
我先是自己來除錯原來一直跑不起來的case，發現之所以前面的case失敗了，會影響後面的case，其實是由於case之間的獨立性不好引起的。為了能解決這個問題，我還和team一起設計了乙個複雜的環境恢復的keyword，裡面判斷了不同情況下，如果有板子沒有起來，應該怎麼恢復的問題。用了這個方法，ca...