軟體工程與瀑布模型
軟體工業似乎是高科技產業的一環，但其實目前絕大多份的公司並不是使用專業的方法來解決問題，導致生產效能低落，臭蟲四竄品質不足，專案時間每每向後延遲，以及開發經費大大增加。這些現象都是因為絕大多數的公司以及開發者都是使用「瀑布模型」進行開發所導致的。
瀑布模型，就像是有五座高低不等的湖泊，每個湖泊都有個瀑布連到下一個湖。
需求 (Requirements)
|——>高階設計 (High Level Design)
|———->細部設計 (Design)
|———–>編碼 (Code)
|———–>測試(Testing)
|———>出貨(Delivery)
|————->維護(Maintenace)
這個模型原先是份大學的論文，結果被美國軍方看上，結果就被採用了。奇怪的是，這篇論文的結尾指出，這個設計流程模型並不是很好的模型。至於為何它還是被採用了，只有天知道。根據調查，因為採用這個模型而導致的累計損失是工程歷史上的數一數二的。
這個模型認為寫程式的人能先作前導的設計，然後才開始真正的寫程式。但是在現實生活上，幾乎沒有一個程式是從頭到尾不需更改一直線進行的。畢竟客戶不知道電腦能做些啥，工程師也不知道客戶想要些啥，所以花幾個月寫好的需求報告書通常都必須一改再改。資料顯示這些需求有一半都不會真正被寫進程式裡。而在上層更改需求會產生雪球效應，如此一來在最底層（測試以及維護階段）就會不可避免的產生許多錯誤。換另一面來看，客戶在一開始交與需求報告書的時候，通常都必須簽訂合約。如此一來每當需求增加的時候，就必須多付些錢。許多軟體公司其實就是靠這些增加的需求來賺錢，一開始的報價反而不重要。
通常80%的資源都被用在測試之後的環節上，這是因為這種設計模型很容易寫出充滿錯誤的程式。
結論是：瀑布模型很爛。
該怎麼辦？使用XP程式設計