瀑布式開發方法的基本原則

1、採用階段式開發：軟體開發過程被事先分成固定的幾個階段，撰寫書面的需求說明文件、設計高層軟體架構、設計低層細節、編寫程式碼、測試、部署

2、採用階段式評審：每個階段結束後，對該階段提交的成果進行評審，評審通過後才能進入下一階段

瀑布式開發方法有正式和非正式兩種形式

1、正式的形式：可以參考美國國防部軟體開發標準2167A及後來的標準498，其中詳細地描述了該方法所有階段的流程，以及需要提交的文件

2、非正式的形式：首先由市場人員收集市場需求，提交給開發人員；接著由開發人員制訂開發計劃，設計軟體架構，進一步完善設計細節；然後進入開發測試階段，完工後邀請使用者測試產品，最後部署

瀑布式開發方法經久不衰的原因

1、流程具有可預測性，因而深受管理層歡迎。只要能準確理解需求和技術，而且需求不再變更，開發團隊就能制訂精確的開發計劃

2、每個階段結束時都會提交書面材料。這些材料可以從一定程式上增強人們對專案的信心（雖然把書面材料當成定心丸多少有些靠不住）

瀑布式開發方法讓產品經理頭痛的地方

1、產品驗證嚴重滯後：這是最嚴重的問題。產品經理必須竺並不能軟體開發的尾聲，才能看到可以執行的軟體。也就是說，在投入大量人力和資金之前，軟體的可用性無法得到驗證

2、變更計劃代價不菲：任何對前期決策的修改都會打亂開發流程，大量工作需要從頭來過，不僅浪費資金，而且耗費精力。此外，在開發和測試過程中常常會發現前期設計中的缺陷，臨時修補也會嚴重延誤開發進度

3、無法適應快速的市場變化：嚴重依賴文件和流程，在這方面開銷很大。哪怕是一點小小的改動都要花費不少的工夫