最近學習軟件工程，發現項目開發中最經常用的開發模型還是：
瀑布模型(Waterfall Model)
|
可行性研究與計劃
|
|
需求分析
|
|
設計
|
|
編碼
|
|
運行維護
|
|
測試
|
|
測試已經開始 |
|
返回上級，再….. |
l 所有過程模型的鼻祖。---- Royce,1970
l 瀑布模型把軟件開發過程劃分成若干階段，每個階段的任務相對獨立，便於不同人員分工協作，從而降低了整個軟件開發工程的困難程度。在軟件生存期的每個階段都採用科學的管理技術和良好的方法與技術，而且每個階段結束之前，都從技術和管理兩個角度進行嚴格的審查，經確認之後纔開始下一階段的工作。---- 項目是按照一定的順序執行。
l 瀑布模型是文檔驅動的，各個階段不連續也不交叉。
特點：
l 階段間具有順序性和依賴性。
l 推遲程序的物理實現。
l 質量保證：每個階段必須完成規定的文檔；每個階段結束前完成文檔審查,及早改正錯誤。
l 易於組織，易於管理：因爲你可以預先完成所有計劃。
l 是一種嚴格線性的、按階段順序的、逐步細化的過程模型（開發模式）
適用場合：
l 當有一個穩定的產品定義和很容易被理解的技術解決方案時，純瀑布模型特別合適。
l 當你對一個定義得很好的版本進行維護或將一個產品移植到一個新的平臺上，瀑布模型也特別合適。
l 對於那些容易理解但很複雜的項目，採用純瀑布模型比較合適，因爲可以用順序方法處理問題。
l 在質量需求高於成本需求和進度需求的時候，它尤爲出色。
l 當開發隊伍的技術力量比較弱或者缺乏經驗時，瀑布模型更爲適合。
缺陷：
l 在項目開始的時候，用戶常常難以清楚地給出所有需求；用戶與開發人員對需求理解存在差異。
l 實際的項目很少按照順序模型進行。
l 缺乏靈活性：因爲瀑布模型確定了需求分析的絕對重要性，但是在實踐中要想獲得完善的需求說明是非常困難的，導致“阻塞狀態”。反饋信息慢，開發週期長。
l 雖然存在不少缺陷，瀑布模型經常被嘲笑爲“舊式的”，但是在需求被很好地理解的情況下，仍然是一種合理的方法。
