2.2 瀑布模型
1970年，溫斯頓·羅伊斯（Winston Royce）提出了著名的“瀑布模型”，直到20世紀80年代早期，它一直是唯一被廣泛采用的軟件開發模型。直至今日，該模型仍然具有強大的生命力。
瀑布模型（Waterfall Model）又稱流水式過程模型，它形象地用階梯瀑布描述，水由上向下一個階梯一個階梯地傾瀉下來，最后進入一個風平浪靜的大湖，這個大湖就是軟件企業的產品庫，如圖2-1所示。
圖2-1 瀑布模型示意圖
1.模型的本意
在瀑布模型中，軟件開發的各項活動嚴格按照線性方式進行，當前階段的活動接受上一階段活動的工作結果，實施完成所需的工作內容。需要對當前階段活動的工作結果進行驗證，如果驗證通過，則該結果作為下一階段活動的輸入，繼續進行下一階段的活動，否則返回上一階段修改。
在瀑布模型中，軟件生命周期的過程是由需求、設計、編碼、測試、發布等階段組成的，把每個階段當作瀑布中的一個臺階，把軟件生存過程比喻成瀑布中的流水，軟件生存過程在這些臺階中由上向下地奔流。瀑布模型規定了各項關鍵軟件工程活動，自上而下、相互銜接、逐級下落，如同瀑布的固定次序。當發現某一階段的上游存在缺陷時，可以通過追溯，予以消除或改進，但要付出很大代價，因為水要在瀑布臺階上倒過來向上流動，需要消耗很多能源或動力。
由瀑布模型可知，項目經理或軟件管理人員，只要控制好每級臺階的高度和寬度，在每個臺階處設立里程碑或基線，并組織好對基線的評審與審計，就可以控制好項目的開發成本、進度和質量。
早期的面向過程的結構化分析、設計、編碼、測試、維護方法，很適合瀑布模型。或者說，瀑布模型適合于結構方法，即面向過程的軟件開發方法。
2.模型的特點
瀑布模型將軟件開發過程規劃為“需求—設計—編碼—測試—發布”的線性過程，其最大特點就是簡單直觀。也就是說，必須首先把軟件要干的每一件工作都分析得徹徹底底，再對每一個模塊、每一個接口，事無巨細地都設計得非常完美，才開始編碼工作，并且編碼時就像在對著圖紙砌模型，根本不用再回頭做任何修改。當然，需要把所有代碼都寫完以后才開始測試。它完全忽視了軟件開發過程的動態變化。瀑布模型的特點是：
（1）里程碑或基線驅動，或者說文檔驅動。
（2）過程逆轉性很差或者說不可逆轉，根據上游的錯誤會在下游發散性傳播的原理，逆轉將會延誤工期，增加成本，造成重大損失。
3.選擇模型的條件
不是任何軟件都適合采用瀑布模型，軟件項目或產品選擇瀑布模型，必須滿足下列條件：
（1）在開發時間內需求沒有或很少變化。
（2）分析設計人員對應用領域很熟悉。
（3）低風險項目（對目標、環境很熟悉）。
（4）用戶使用環境很穩定。
（5）用戶除提出需求以外，很少參與開發工作。
盡管上述條件比較苛刻，但是軟件企業在開發新產品或新項目時，往往還是采用瀑布模型。系統軟件和工具軟件的開發，也常常采用瀑布模型。
4.模型的優點
首先，瀑布模型這個階段性的軟件開發模型制定了以下規則：每個階段都有指定的起點和終點，過程最終可以被客戶和開發者識別（通過使用里程碑），在編寫第一行代碼之前充分強調了需求和設計，避免了時間的浪費，同時可以盡可能保證實現客戶的預期需求。
需求和設計階段能提高產品質量，因為在設計階段捕獲并修正可能存在的漏洞要比測試階段容易得多，在組件集成之后來追蹤特定的錯誤要復雜很多。最后，因為前兩個階段生成了規范的說明書，當團隊成員分散在不同地點的時候，瀑布模型可以幫助實現有效的知識傳遞。
瀑布模型的優點是：開發階段界定清晰，便于評審、審計、跟蹤、管理和控制。它一直是軟件工程界的主流開發模型。
5.模型的缺點
瀑布模型的缺點是：傳統的組織方法是按順序完成每個工作流程，即瀑布式生命周期。瀑布只能一個個臺階地往下流，不可能倒著往上流，這就是它致命的缺點。瀑布式生命周期通常會導致項目后期，如實施階段（當第一次構建產品并開始測試時）出現“問題堆積”，在整個分析、設計和實現階段隱藏下來的問題，會在這時逐步暴露出來。更可怕的是，錯誤的傳遞會發散擴大，比如，在需求階段中的一個錯誤或遺漏，在編碼階段可能引發幾十個錯誤或遺漏。因為項目有較長的開發周期，其進度會被嚴重拖延，最終導致成本和質量的失控。世界軟件巨人微軟公司和IBM公司，有時也不可避免地會犯這種錯誤。盡管如此，直到今天，該模型仍然是應用最廣泛的模型之一。
為了克服該模型的缺陷，微軟公司采取嚴格的里程碑管理制度。CMM/CMMI則采取階段評審和不符合項（Noncompliance Items）動態跟蹤制度，只有前一階段的不符合項全部改正后，才允許開發人員進入后一階段的工作。所謂不符合項，是在評審中發現的問題項，它與Bug既有聯系，又有區別。對于這些不符合項，軟件管理部門要列出表格，記錄在案，確定責任人，限定改正時間，動態跟蹤到底。