1 瀑布模型怎麼來的？
(1)所謂軟件危機
瀑布模型算是現代軟件工程的起源，軟件工程的發展，很大部分都是構建於瀑布模型的基礎之上的。在校期間做的項目相對簡單，通常不會涉及到諸如性能測試等，通常爲邊寫邊改，但是一旦
項目變複雜，開發人員水平參差不齊，從而導致軟件開發與維護過程中出現一系列嚴重問題，這個現象也被稱之爲“軟件危機”。
(2)邊寫邊改的缺點
- 開發的過程不可控
- 項目的人數多了以後，不方便協作分工
- 對需求分析的理解誤差，導致返工，從而影響項目交付
- 沒有有效的測試，上線問題一堆
(3)瀑布模型的誕生
1970 年，Winston Royce 博士借鑑了其他工程領域的思想，比如建築工程，提出了瀑布開發模型，指出軟件開發應有完整之週期，並將軟件開發過程分成了若干階段。像瀑布一樣，從上往下，完成一個階段繼續下一個階段
2 瀑布模型案例
按照一個我曾經畢業設計的案例
(1) 項目的定義和規劃
畢業設計是做一個c++的網絡嗅探器，所用庫爲libpcap，可行性沒問題，老師大概給我說了下需要做哪些功能，然後說兩個月完成吧。啊，你怕是在開玩笑，當時讀本科一天天都是在摸魚。。初步定下時間吧
需求分析——1 周；
軟件設計——1周；
程序編碼——4 周；
軟件測試——1周。
的確如此，軟件測試在當時開來就是功能測試，實現功能就完事，哎！！！
(2) 需求分析階段
通過查看論文文獻，使用viso畫了一個項目的結構圖，然後去和老師討論，然後加了一些需求，並需要形成文檔，然後再和老師談論，最終確定了需求的文檔，現在的時間變成這個樣子。
需求分析——2周；
軟件設計——1周；
程序編碼——3 周；
軟件測試——1周。
需求階段多花了一週時間，這樣子程序的編碼就被壓縮了一週，因爲需要在規定的時間儘量完成任務嘛，畢業要緊！！
(3) 軟件的設計
這個時候，老師就對應公司裏面的架構師角色，畫了一個圖說明採用什麼架構，用什麼來界面展示，數據庫採用什麼。差不多就確定了，但是我寫了差不多一週代碼後，老師問我進展，需要我加上一些數據包統計功能等
這樣子前前後後，軟件的設計花了兩週的時間。
需求分析——2周；
軟件設計——2周；
程序編碼——2 周；
軟件測試——1周。
(4)編碼
有了文檔，開始編碼，時間壓縮了很多，加班呀，使勁加班！！但是身體受不了，只好問老師能不能往後延遲兩週，編碼，調試，有時候老師還要加功能，前前後後差不多花了4周時間。這樣子相當於項目延期2周。
需求分析——2周；
軟件設計——2周；
程序編碼——4周；
軟件測試——1周。
(5)測試
前期需求多了一週，軟件設計多花了一週，在既定的時間裏，只能壓縮編碼和測試的時間，加班！！
綜上可知，這樣子分層的思想，的確可以在每一步的實施上面可以效率比較高，這種編碼前先設計、編碼後測試、整個過程重視文檔的方式，開發出來的產品，質量相對是有保障的。但是一旦前面某個環節出了問題，返工的操作不是延期就是壓縮編碼測試的時間。從而成了9116.。。。。。
3 瀑布模型的優缺點
最大的問題就是不能及時響應需求變更，越到後期變更代價越大
優點
- 簡單易行
- 可以進行階段檢查，能夠及時發現問題
- 較好的分工協作，不同階段不同職位，架構師，項目經理，開發工程師，測試工程師，運維工程師
- 對質量有一定的保障，因爲每個階段有詳細的文檔
缺點
- 難以響應需求的變更
- 工作量分配不均勻
- 前期階段受阻壓縮後期進展
4 總結
瀑布模型的出現，也解決了軟件項目開發中的幾個重要問題。進行了模塊劃分，各個階段負責各個階段的內容，所謂分工明確。質量有了保證，每個階段都有相應的文檔評審，可以幫助大家少走彎路，提高工作效率。
