(困難與障礙,評鑑要點)
Dr. Chaw-Kwei Hung 洪肇奎
12/9/2009
本人於98年12月9日下午參加經濟部工業局舉辦「98年度提升資訊軟體品質(CMMI)計畫成果發表會」,並獲頒「贊襄良多」獎,非常高興得到這個肯定。對於我來說這次得獎具有格外的意義,因為我從美國NASA退休之後,特別回台協助輔導台灣的廠商,目前已輔導過台灣多家的廠商,日前成功輔導中冠、鼎升兩間公司通過CMMI ML 4認證,藉此機會跟大家分享CMMI高能力成熟度評鑑之困難與要點。
CMMI高能力成熟度評鑑,從主任評審委員的角度了解評鑑CMMI高能力成熟度所面臨的障礙,且將主任評審委員的看法清清楚楚地訴諸各位。首先提出台灣在進行CMMI高能力成熟度評鑑之時,主要的問題及重點之處為何?台灣目前不僅在產業升級面臨困難,且還須與中國、南韓等國家競爭,所以需藉由製造更高品質的產品,以提升國家產業的競爭力。
我曾帶領美國太空總署NASA的工程師執行許多計畫,也曾參與過台灣產業界及學術界之研究與發展,以豐富實務經驗看來,台灣跟西方之間主要不同之處為文化的差異,例台灣的工程師拿到計畫之後,馬上進行程式碼撰寫、缺乏進行細緻需求發展與規劃的工作,以致缺乏「真正的規劃面」,我們不重視計畫規劃的文化,面臨軟體系統工程的四大問題:
|
1). |
重工率太多:例台灣工程師工作時數長,在需求不明確、規劃及設計不佳的情況下就埋頭苦幹,以致之後不斷地修改與重工。不知須先產生需求文件及專案規劃文等。 |
|
2). |
重用率太少:專案經驗、程式文件、設計測試案例等的再利用率。舉例來說,各計劃皆有資料控管,但資料庫控管的設計不是基於專業分工的考量,以致於資料不能夠再利用,資料之間沒有知識的連結,也就是說每個人都有資料管理,但因不利用他人的資料管理,反而產生更多不必要之成本。 |
|
3). |
制度不落實:無按部就班,制度面與執行面不符合,中階主管的阻礙,造成上下標準不一,不能按部就班落實制度。 |
|
4). |
缺少橫向溝通:「官大學問大」,各部門之間的協調太少,包括硬體及軟體、開發與管理的團隊溝通做不好。 |
以上四大問題要如何解決?怎樣去避免重工率、提高重用率等等,這些都需利用到量化管理方法。所以,顯然地應落實高能力成熟度之量化管理方法方能解決上訴的問題。各位都了解CMMI ML2及ML3主要關鍵在於建立基礎的執行方法,但並無法確切掌控執行的品質與效能,直到ML4之時才能驗證是否在對的時間做出對的事情。
SEI最近二年,特別針對ML2、ML3及High Maturity(ML4、ML5)之間訂出不同的規定,SEI對於High Maturity100%完全審核,所以門檻相對提高,此外目前CMMI所使用的V1.2版又比V1.1版困難許多,實際上此次通過CMMI ML4中冠、鼎升二間公司花了相當的時間摸索CMMI-DEV V1.2版,同樣地SEI也在摸索,了解V1.2版所產出的文件還不夠詳細,進而產出1.2版A也就是將來的 V1.3版,將在未來二年內正式實施,而這次通過認證二間公司表面上使用1.2版但實際上已實施CMMI-DEV version 1.3版。
且SEI進行認證中清楚訂出高成熟度的方向必須跟公司營運目標一致,並不是為了Model而Model,必須實際依照公司營運目標而去執行,而依各公司的營運目標不同,例中冠要開發新產品,工研院要研發新技術等等,所以不能藉由他家公司的資料套用在自家公司裡,這些在CMMI高能力成熟度是不可能出現。
CMMI 高能力成熟度認證時重要的依據為何?而主任評審委員究竟希望看到什麼?台灣首要問題在於高階主管思維與管理模式須改變。中冠、鼎升皆進行二次的Class B,審查當時,主任評審委員表示二家公司距離通過認證的標準甚遠,主要因素在於台灣高階主管思維須改變,以下為本人針對高階主管思維必須改變歸納出七項看法: