推 meltice:程式越來越高階 API越來越多 218.211.16.154 03/04 11:36
→ meltice:寫程式真的有變簡單嗎 還是變更複雜 218.211.16.154 03/04 11:36
※ 引述《tester.bbs@bbs.csie.ncu.edu.tw (try or test)》之銘言：
: 有人認為軟體工程如果是增加工程師的生產力, 提升公司團隊獲利
: 的競爭力, 只是一種硬體的思惟, 那麼 "軟體工程" 的訴求又是甚麼 ?
: 如果 "品質好 => 物美" , "生產力夠 => 價廉" 僅止於硬體的想法, 那
: 麼軟體的訴求是甚麼 ? "高附加價值", "LV , Chanel 的品牌" "iPOD"
: 然道這些對購買者都不算是 "物美價廉, 買得值得" 嗎 ?
: SAP 的軟體產品可以賣給類似台積電, 中鋼這種大廠進行 ERP 自動
: 化, 可以獲得上億的價碼. 對這些公司言, 保證幾個月內上線正常運作,
: 比起搞上數年聘了一堆人還無法順暢運作不就是 "價廉物美" 嗎 ? 何況
: SAP 也不是三年不開張, 開張吃三年, 而是獲利能力高強者之一.
: 那麼, 究竟甚麼才是軟工的正確思惟 ?
再轉錄一篇文章
http://www.oreilly.com.tw/column_sleepless.php?id=j013
[技術短文]
沒人在乎軟體工程
書店裡，軟體工程的書靜靜地躺在一隅，身上的灰塵，似乎正述說著它們所受到的冷落。
在台灣，沒人在乎軟體工程。
「新技術一直冒出來，學都學不完了，那裡有空搞軟體工程」、「計畫趕著進行，做都做
不完了，那裡有空搞軟體工程」...... 就在這一個又一個的藉口中，原本可以幫助軟體
產業進步的軟體工程，竟然變成他們口中阻礙軟體產業進步的絆腳石似的，怎不令人對他
們的無知感到心寒。
會寫程式沒什麼了不起，畢竟程式語言越來越高階，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）：評估革新性的新技術，有規則地依序導入採用，以持續不斷
地改進程序。
你的公司是屬於那個 Level？
如果你是在印度的 Wipro 公司上班，恭喜你，貴公司是世界第一個取得 SEI CMM Level
5 認證的公司，而且還不是美國的公司，真的是很了不起；如果你是在中國大陸的東軟上
班，恭喜你，貴公司已經取得 SEI CMM Level 3 認證；但是既然你看到這篇文章，你最
有可能是在台灣的軟體公司上班，貴公司應該是 CMM Level 1 的公司，是不用認證的，
也就是最糟糕的那一種。沒去取得 SEI CMM 認證不是罪過，但完全沒有採行軟體工程，
並持續改進軟體開發方式的意願才是可悲。台灣的軟體公司往往只顧著 Java、.NET...
等程式設計的技術，卻忽略了最根本的工程，小學而大遺。程式員固然缺乏，但我們真正
最缺乏的是能把一堆程式員組織起來、做出大型軟體的工程與管理人才。
要比好，不要比爛
我們之所以如此忽視軟體工程，或許是因為台灣的軟體公司都不重視軟體工程，相形之下
，自己的公司也不會爛到哪裡去，所以就比較不擔心。但是我要警告，軟體產業的地域性
不高，是一個非常國際化的產業，不是國內的軟體公司互相競爭而已，我們的競爭對象是
國際上的所有軟體公司。當國外的軟體公司漸漸使用嚴謹的工程進行軟體開發，時程、經
費、品質都在他們的掌控之中，你能不對我們的軟體產業感到憂心嗎？
看了這篇文章，如果你是有影響力的主管，請你開始思索貴公司的軟體工程品質，嘗試開
始做出改變。如果你是屬於「孤臣無力可回天」的程式員，也不可以就這樣算了，不要讓
公司的顢頇影響到你的進步，你還是可以培養相關的知識，或者你乾脆跳槽到有意願採行
軟體工程的公司，...... 我看，去印度吧！
本文作者：蔡學鏞
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.124.43.93