系統開發方式眾多，項目管理者只需決定何時採取何種開發模式即可。瀑布開發模式就是一種最常用的開發模型，因為這種開發方式不但簡單直觀而且大大便利了項目管理的運作。 瀑布開發模式可以令項目管理人員非常方便地把整個項目置於自己的掌握之下。瀑布開發模式限制了開發期間團隊間的互動，評估起來相當方便，由於開發計畫穩定而且幾乎不會發生經常性的變化從而有效地簡化了項目開發的管理工作。
基本介紹
模式,階段劃分,適用場合,缺點,
模式
瀑布開發也有一些缺點，但是，在你初履新職，剛剛接手管理一個新的團隊，同時獲得了一種支持瀑布開發模式的解決方案的情況下，這種開發模式可以令你很快進入角色把工作開展起來，從而為將來採用更高級的開發方式做好了準備。
瀑布開發過程在政府項目中特別受到歡迎，在這樣的軟體開發項目中，其規劃階段超出了大多數企業部署階段的時間和力度。採用這種方式的其他用戶包括那些理解比較全面和深入的軟體項目，相關的解決方案對團隊而言非常熟悉，或者只需要小小的改動。
階段劃分
瀑布開發也被稱作系統開發生命期模式，簡稱SDLC（Systems Development Lifecycle Model），這是一種軟體開發途徑，它把項目分解為有限的階段。每一個階段都有序執行，並且依賴於先前已完成的階段。在採用瀑布開發方法的情況下，開發工作的各個部分必須分別評估，而且通常由不同的開發隊伍來實施。具體開發階段的劃分存在一定的爭議，但各個階段基本上取決於任務相對繁重的預先規劃。以下就是瀑布開發過程的常見階段劃分：
問題評估—也就是概念形成階段。明確現有解決方案所存在的問題同時收集相關信息。
計畫解決方案—提出解決方案的詳細說明，包括軟體的優點和缺點以及試圖解決的問題。確定開發時序，工作結構分解以及其他支持文檔。最重要的是明確和分析軟體需求。
設計系統架構—提案獲得接受之後即可創建解決方案模式，包括工作流和數據流圖、模組和功能層次已經其他由解決方案所需要的說明。在這一階段通常總是伴隨一個有力度的檢查過程。
開發代碼—用以上階段創建的藍圖編寫、調試和單元測試軟體代碼。接著，集成系統的代碼和測試部分。最後測試整個系統。該階段要到測試完全通過才能結束。
部署和使用系統—部署最終功能，同時向用戶提供所需的培訓和文檔。
維護解決方案—在必要的時候指出和升級軟體並且修補軟體錯誤。
有時測試會成為單獨的一個階段，其中包括軟體調試而不是在開發階段進行代碼調試。此外，獲取軟體需求也可能成為獨立的階段。無論採取怎么樣的開發路線，以上過程都是一次實施的，同時還要整合到整個解決方案中來。
適用場合
採用瀑布開發模式是需要一定條件和場合的，並不是所有的解決方案都能採用這種比較嚴格的開發方式獲得成功。
採用瀑布開發方式的用戶常見於新負責的項目經理因為這種方式對項目的估計非常方便。項目開發中涉及到的幾乎一切都預先計畫，從而便於確定預期的開發成本和開發時間。另一項好處是所有的需求都必須得到確認，在代碼編寫之前項目結束標準就能確定項目是否成功。這樣就保證了項目開發的目的明確性。
由於項目開發工作分階段實施，一次只有一個團隊管理項目。從而簡化了項目經理的工作，使得項目經理可以更深入地同每一位團員協作。這樣的成員間交流對項目開發的最終成功自然大有裨益。
缺點
瀑布開發方式的缺點也是明顯的。如果期間的每一階段沒有得到堅決貫徹和實現，那么隱藏的問題最終會影響項目的成功。雖然瀑布管理方式對項目經理而言非常方便，但是對開發人員而言就可能顯得太嚴酷了。因為測試過程在開發階段之後實施，子系統測試所暴露的問題可能需要立即修改代碼，這樣就顯著增加了計畫架構的成本。
調試過程可能非常複雜，原因在於，開發人員在同一階段通常還可以從事其他項目的開發工作，而所需要的軟體修改可能會降低開發人員的生產率和工作質量。有時工作區還必須集中到一個地方來，從而威脅到解決方案的完整性。
另一可能的危險是你只有到解決方案啟動的時候才能知道當初所預計的是否成功，所以餘下用來改正問題的時間和空間都非常有限。而設計工作上的疏漏和缺陷可能會嚴重地影響解決方案的啟動日期。
這種模式的另一問題在於，除了到階段終止之時，其他時候幾乎沒有獲取反饋的時間，還有，一旦開發工作開始啟動那么修改的空間也就沒有了。最後，假如系統測試表面功能或者性能沒有達到要求也許到這個時候已經沒有糾正問題的可能了。
在部署瀑布開發模式之前你必須仔細評估自己所處的環境和條件。如果客戶希望在開發工作開始之後加入進來或者你要處理很多未知的問題，那么你或許最好採用一種更具重複性的開發過程。
