目前軟體開發方法中有兩大流派，分別為瀑布式跟敏捷式。
瀑布式是比較早發展出來的開發模型，敏捷則是近十年來被大力的提倡。有許多公司或團隊，以採用敏捷開發做為賣點，認為敏捷可以打造出更好的產品，或是加快軟體開發速度，所以敏捷比瀑布式開發還要好。
但我們要理解，每一種方法論都有其適合的情境，並無絕對的優劣，例如，敏捷適合於需求不清、變動快速的場景，而相對的瀑布式開發也有其優缺點跟適合的情境。
瀑布流開發的優點
詳細的規劃
採用瀑布式開發的專案，其實很像建造的流程。一棟建築物在開始建造之前，會委由建築師來規劃設計、繪製藍圖，再經過技師的安全性評估或其他關係人的意見，來調整設計圖，最後工班根據完成的設計圖來建造。
採用瀑布式的軟體開發，在專案開始開發之前，會針對需求進行完整的訪談、調查與整理，再經過詳細的規劃與設計，最後產生完整的開發規格，例如文件、圖表、流程圖等等。而這些規格，也會經過各領域專家、或是不同部門同事的檢視，從不同的角度跟觀點來確保這些規格的合理性、可行性，同時也確保規劃符合需求。最後將規格提供給工程師，讓他們按照這些需求完成專案。
相較於敏捷通常缺乏規劃，瀑布式在規劃上是有其優勢的。
專案進度控管
由於瀑布流開發具有詳細的規劃與規格文件，因此一個專案的規模及複雜度，相較於敏捷式開發，是更容易被掌握的，也因此在人力以及時程的估算上，會更佳精準。
因此以管理者的角度來說，這樣的特性是有利於專案管理的，尤其在中長期規劃上。
開發品質可控
同樣由於有詳細的規劃，團隊成員對於專案有共同的認知，只要根據規格來做開發，基本上結果不會偏離太遠，完成品通常比較符合預期。也因為規格文件在早期就決定下來了，所以在做功能驗證的時候是有憑有據的，有不符合規格的地方，可以要求更改，比較有辦法控管品質。
瀑布流開發的缺點
開發時程長、初期及變動成本高
在瀑布式開發中，一個專案從需求開始到驗收結案，時程會拉的很長，整個專案所投入的人力資源及資金成本都相當的大。
相較於敏捷式開發，可以先處理一部分的需求，瀑布式開發在專案的一開始就會進行完整的考量，因此一開始需要投入的資源比較高。
並且，若在開發的過程中，有任何東西需要調整，並退回上一步的話，可能會需要重新檢視所有設計，甚至已經開發的東西可能都會面臨大部分都要重來的狀況，這樣的成本相當昂貴。
缺乏彈性，面對市場反應慢
瀑布式開發需要完整的規劃，後續的流程也根據規劃按部就班來進行，這是優點，但同時也是缺點。
由與目前的市場的競爭較為激烈，變化快速，動則一兩年的開發專案，在系統完成後可能已經跟不上當時的市場需求了。但是對於瀑布式開發來說，所有需求都要重新檢視，因此更動需求的成本都相當的大，而這樣缺乏彈性的狀況正是瀑布流開發的限制。
瀑布流開發的適用情境
需求明確
對於需求明確的系統來說，採用瀑布式開發是很適合的。因為這樣就不必面對彈性不足的問題。只要確立需求，進行完整的規劃，往下開發，這是相當有效率的。
例如，企業內部的 ERP 系統，由於企業內部的流程通常已經有完善的規範，不太會有變化，那就可以根據目前狀況進行設計，採用瀑布式的開發。
複雜系統
有些專案很複雜，要跟很多外部系統串接，或者是有許多繁雜的法規需要遵守。這些細節通常需要在開發初期就考慮進去，推遲是中後期再處理可能會面臨架構的大規模調整，或是有所遺漏。
像是銀行用的系統，要符合國家法規還有公司內部繁雜的流程，如果沒有進行事前的規劃，並且對規劃進行完整的檢視，後期會有很多問題。又或者是一個大型系統，如果開發出其沒有做好妥善的架構規劃，中後期雖然可以透過 refactor 的方式改善架構，但成本會高出許多。
結論
每一種開發都有其適用情境與限制，成熟的軟體開發團隊應該要根據專案特性評估，而不是一昧的擁護特定方法。
不過目前很多團隊會把瀑布流跟敏捷開發方法的特性混合在一起，調整成更適合團隊的模式，這樣的混合式開發，也許是更加有可行性的做法。