「新技術一直冒出來，學都學不完了，那裡有空搞軟體工程」、「計畫趕著進行，做都做不完了，那裡有空搞軟體工程」...... 就在這一個又一個的藉口中，原本可以幫助軟體產業進步的軟體工程，竟然變成他們口中阻礙軟體產業進步的絆腳石似的，怎不令人對他們的無知感到心寒。
會寫程式沒什麼了不起，畢竟程式語言越來越高階，API 越來越多，開發工具越來越好用，寫程式的門檻自然就大大地降低了。想要開發出有價值的中大型系統，軟體工程就很重要。這麼比喻好了，你可以隨便找一兩個工人用磚或木材來蓋一棟矮房，但是如果想蓋一百多層樓的紐約世貿雙星大樓，你非得有良好的工程規劃不可，軟體不也是如此？程式員名片上的頭銜都是工程師，雖然和建築工程師、機械工程師 ... 一樣都被稱為工程師，但比較起來，軟體產業的工程師卻是最不工程導向的。
國內的軟體公司需要開始重視軟體工程，不可以再用「家庭手工業」的心態來開發軟體了。如何評估一個公司採行軟體工程的成熟度如何，SEI 推出 CMM for Software。共分成五個等級，讓軟體公司有評估和改進的依據。透過這篇文章，希望能讓各位對 CMM 能有最基本的認識，並建立大家的危機感。
SEI 與 CMM
1984 年時，由美國國防部出資，由賓州（Pennsylvania）的卡內基美倫大學（Carnegie Mellon University）負責成立一個名為 SEI（Software Engineering Institute）的軟體研發中心，來自產官學的技術和管理專家陸續進駐該機構，開始對工、商、政府提供產品和服務。
SEI 試圖在軟體界建立一套工程般的制度，讓個人和組織在軟體開發上能有改進的依據。SEI 的 Capability Maturity Model (CMM) for Software 已經成為許多軟體公司所採行的標準，用作為改進公司內部軟體工程的依據。
根據 CMM 的定義，軟體工程的成熟度分成五個等級，簡單介紹如下：
- CMM-Level 1（initial）：軟體程序漫無章法，程序未被定義。專案計劃的成功仰賴於工作人員個別的努力。
- CMM-Level 2（repeatable）：已建立基本的管理程序，對成本、時程、和職務權責能加以追蹤、查詢。已有作業程序所須具有的紀律，所以有能力重覆使用相類似的專案成功的案例與經驗。
- CMM-Level 3（defined）：屬於管理和工程的活動都已設計、定義好，並且文件化，完整地整合成組織內的標準作業程序。各個專案計劃延用標準程序或被認可的標準程序修改程序。
- CMM-Level 4（managed）：組織可收集詳細的軟體程序以及軟體產品的量測資料。軟體作業程序和產品都有一組量測的數據，可讓工程師和經理們了解程序和產品的狀況。
- CMM-Level 5（optimized）：評估革新性的新技術，有規則地依序導入採用，以持續不斷地改進程序。
如果你是在印度的 Wipro 公司上班，恭喜你，貴公司是世界第一個取得 SEI CMM Level 5 認證的公司，而且還不是美國的公司，真的是很了不起；如果你是在中國大陸的東軟上班，恭喜你，貴公司已經取得 SEI CMM Level 3 認證；但是既然你看到這篇文章，你最有可能是在台灣的軟體公司上班，貴公司應該是 CMM Level 1 的公司，是不用認證的，也就是最糟糕的那一種。沒去取得 SEI CMM 認證不是罪過，但完全沒有採行軟體工程，並持續改進軟體開發方式的意願才是可悲。台灣的軟體公司往往只顧著 Java、.NET... 等程式設計的技術，卻忽略了最根本的工程，小學而大遺。程式員固然缺乏，但我們真正最缺乏的是能把一堆程式員組織起來、做出大型軟體的工程與管理人才。
要比好，不要比爛
我們之所以如此忽視軟體工程，或許是因為台灣的軟體公司都不重視軟體工程，相形之下，自己的公司也不會爛到哪裡去，所以就比較不擔心。但是我要警告，軟體產業的地域性不高，是一個非常國際化的產業，不是國內的軟體公司互相競爭而已，我們的競爭對象是國際上的所有軟體公司。當國外的軟體公司漸漸使用嚴謹的工程進行軟體開發，時程、經費、品質都在他們的掌控之中，你能不對我們的軟體產業感到憂心嗎？
看了這篇文章，如果你是有影響力的主管，請你開始思索貴公司的軟體工程品質，嘗試開始做出改變。如果你是屬於「孤臣無力可回天」的程式員，也不可以就這樣算了，不要讓公司的顢頇影響到你的進步，你還是可以培養相關的知識，或者你乾脆跳槽到有意願採行軟體工程的公司，...... 我看，去印度吧！
本文作者：蔡學鏞
張貼日期：10/15/2001
沒有留言:
張貼留言