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