淺談資訊軟體品質與淺談資訊軟體品質與淺談資訊軟體品質與淺談資訊軟體品質與CMMI能力成熟度整合模式能力成熟度整合模式能力成熟度整合模式能力成熟度整合模式

國際上，印度以優越的軟體品質，在委外市場獨步全球；國內，行政院主計處電子處理資料中心

去年針對政府機構的問卷調查，卻發現高達68%的機關於驗收軟體專案時，曾因品質不符而發生爭議。

為了提升軟體品質，落實軟體工程，目前產官學界正大力推廣CMMI (Capability Maturity Model Integrated)能力成熟度整合模式。本文就從基本的軟體品質觀念，帶領讀者瞭解CMMI是為何物。

壹、前言 全面品質管理的觀念在美國萌芽，卻在日本發揚光大，造就日本產品高品質的形象；後來日本的

經驗反過來刺激美國做出「日本能，我們為何不能」的反省。在美、日兩大經濟強國的推動下，促使

全面品質管理推展到各行各業。像在國際上，ISO(International Organization for Standardization, 國際標

準組織)就定義一系列的品管標準及認證。而在國內，像日常食用的農產品就有CAS優良農產品認證標

章，是國產農產品及其加工品最高品質的代表標幟；為促進國內各企業或組織能推行全面品質管理而

設立的國家品質獎，代表品質的至高榮譽。最近幾年，國內也極力推廣資訊軟體品質的觀念，希望產

官學界能共同透過對品質的要求，落實軟體工程，持續改善軟體開發流程，希望台灣的軟體產業能成

功躍上國際舞台。 貳、資訊軟體品質的基本觀念

今年7月，日本豐田汽車(Toyota)社長渡邊捷昭(Katsuaki Watanabe)針對近期數起汽車召回事件，公

開向消費者道歉，並宣示將盡力預防日後再發生大規模召回事件[1 ]。如果您瞭解豐田汽車的話，應該

知道該汽車之品質素來良好，也是該公司一直引以為豪的品牌形象。管理高層的公開道歉、新的品管

人事佈局及一連串的品質重整計畫展現豐田汽車對品質嚴謹的態度。 上則新聞反應汽車產業對品質的要求；相對的，有一則網路笑話，也許可以反應大家對軟體品質

的印象。話說在一個資訊展覽會上，微軟公司的創辦人比爾蓋茲說：「如果通用汽車(美國最大的汽車

製造商)能使他們的科技進展速度如同資訊產業的進展速度，那麼我們今天的汽車售價僅需廿五美元，

每一加侖汽油可以跑一千英哩。」全場來賓給予他熱烈的掌聲。但事後通用汽車的總裁發佈一篇新聞

稿，臚列13條如果通用汽車發展科技的方式如同微軟一樣，那麼我們今天的汽車就有以下特色：(礙於

篇幅，僅列3條供大家參考) 一、汽車每天會毫無理由的撞毀(Crash)兩次。 二、每一次道路標線重漆或是交通標誌改變時，你就必須買一輛新車。 三、有時候你的汽車會毫無理由在高速公路上停下來，你只好接受事實，然後重新發動、重新上路。

這一則網路笑話反應大家對微軟作業系統品質的質疑。在一般人的印象裡，總認為軟體的品質好

像比較低落，甚至懷疑自己怎麼對軟體瑕疵如此包容。我們若要探究其原因，恐怕不是三言兩語可說

明清楚的；況且比較不同產業之品質水準也不見得恰當。但原則上，我們可以從軟體與硬體產業本質

上的差異，來思考軟體品質的問題[2]： 一、生產方法的不同 硬體製造的過程運用許多自動化機具，經過有形的生產過程，基本上較容易監控；而軟體是

高度腦力密集的產業，無形的思考過程，其生產過程不易被瞭解與監控。 二、品保的重點不同 硬體通常先經設計完成後，再投入生產，其製造過程(或說量產技術)對品質有極大的影響；而

軟體的品質主要來自設計及開發的流程，其複製包裝之技術對品質之影響程度相對較小。 三、產品故障的成因不同 硬體產品的故障原因通常是設計不良或耐用年限到期；而軟體的故障則通常是設計開發過程

中產生，或者說在開發過程中未被發現或測試出的錯誤。 四、設計工作複雜度不同 軟體設計較硬體設計通常有較高的複雜度，尤其是模組間的關係，經常是牽一髮而動全身，

即使軟體技術的進步(譬如物件導向技術等)，仍有許多問題待克服。 從上述的比較，我們大致可以瞭解軟體的設計開發流程影響品質甚深。因此，就有許多協助

組織改善軟體開發流程的制度出現，而CMMI模式即是其中之一。 參、CMMI簡介

一、緣起 CMMI(Capability Maturity Model Integrated, 能力成熟度整合模式)制度是目前國內大力推行用

以改善軟體流程的模式。為何國內產官學界通力合作提升國內軟體品質時，會選用CMMI模式呢？

這要從最近金光閃閃的「金磚四國」中的印度說起。有許多報告指出印度崛起的背景，其中之一

便是軟體代工業(Software Outsourcing)，從1990年至2000年，印度製造的軟體已經外銷世界75個國

家，在2000年時已成為全世界第二大軟體生產國[3]。近幾年的產值，以二位數的成長率快速成長。

而最令人津津樂道的是印度的軟體產業導入CMM及CMMI模式，造就其高水準之軟體品質，讓世

界各國願意將軟體開發工作外包至印度，造就印度軟體產業的榮景。 反觀台灣目前的狀況，行政院主計處於民國94年4月辦理「政府機構資訊系統委外開發之專案

管理概況」問卷調查，赫然發現有高達78%的受調查政府機構委外過程中曾發生問題，有68%於專

案驗收時因品質不符發生爭議的情形[4]。而資訊傳真電子報也針對這樣的調查結果，並訪談多位

軟體界資訊主管，發表一篇「委外爭議多，品質不符是元凶」的報導[5]。 1990年初，台灣部分學者曾大力鼓吹CMM(CMMI的前身)，不幸未獲重視[6]。十幾年後，因

印度軟體產業成功躍上國際舞台，讓台灣驚覺錯失良機。如今台灣產官學界已有共識，生產高品

質的軟體雖然是條漫長而艱辛的道路，還是得一步一步、實實在在走下去。 二、CMMI的歷史 1984年美國國防部執行軟體委外專案時，因無法評估軟體公司對軟體標案之承接及執行能

力，於是委託卡內基美隆大學 (Carnegie Mellon University, CMU)的軟體工程學院 (Software Engineering Institute, SEI)進行研究。1991年SEI正式發表CMM 1.0。其中在軟體領域，提出SW-CMM等模式，其主要目的是用以評估某一組織的軟體開發能力、協助持續改善軟體流程與軟體品質及

提升專案與開發管理能力。但因為有許多組織發佈各種不同的模式，範圍有重疊，架構、術語和

評估方法缺乏一致性，讓採用一種模式以上的組織必需採取不同的訓練、不同的評估方法等，增

加大量的成本。因此，SEI發展一個共通性之整合架構，以支援整合不同專業領域之特定能力成熟

度模式及相關產品，終於在2000年12月正式公佈CMMI。 三、CMMI的架構 不可諱言的，CMMI架構之複雜令人生畏，在此只能簡略描述。CMMI有二種表述架構，在台

灣主要推行分段式表述(Staged Representation)。其成熟度共分五級： 第一級：初始(Initial) 第二級：已管理(Managed) 第三級：已定義(Defined) 第四級：數量化管理(Quantitatively Managed) 第五級：最佳化(Optimizing) 看到這五種分級，大概可以知道這是一種成長性的架構，也就是第二級比第一級成熟，第三

級又比第二級成熟，依此類推。通過該級評鑑之組織，可以取得認證。要如何導入某一等級成熟

度並通過認證，都有一系列的規範。就以第二級成熟度而言，該組織必需在幾個流程領域(詳表1)，按照CMMI規範的原則，制訂相關的執行方法，在軟體專案開發時落實，並持續檢討修正。

表1：第二級成熟度流程領域

流 程 領 域 意 義

需求管理(Requirements Management) 管理專案產品與產品組件之需求，並且界定專案

計畫、工作產品與需求這兩者之間，是否有不一

致的情形。 專案規劃(Project Planning) 建立並維護定義專案活動的計畫。 專案監控(Project Monitoring and Control) 提供對專案進度的瞭解，使得當專案績效明顯偏

離原先計劃時，能採取適當的矯正措施。 供應商協議管理 (Supplier Agreement Management)

管理和專案有正式協議的供應商之產品與服務的

採購。 度量與分析(Measurement and Analysis) 發展並維護支援管理資訊所需的度量能力。 流程與產品品質保證 (Process and Product Quality Assurance)

提供員工和管理階層，對於流程與相關工作產品

客觀的觀察。 建構管理(Configuration Management) 建立並維護藉由建構識別、建構管制、建構狀態

記錄及建構稽核，使工作產品具完整性。

初次見到CMMI文件的人，大概會有丈二金剛摸不著頭緒的感覺，即使國內已有翻譯成中文的

書籍。所以，初次入門可先看模式架構圖(詳圖1)[7]，瞭解架構再看其文字說明，而其繁複的程序

無非是為了要求整個軟體開發過程的確按照定義的流程進行。當累積足夠的標準文件、流程、制

度、量化資訊等，便會形成流程標準，在軟體發展的過程中，就會產生許多有用的資訊可供管理

及決策參考。

圖1：CMMI流程領域結構

四、預期的效益與遭遇的困難 這些繁複的工作有何用處？就以文章前面提到的資訊通報的問卷調查結果，其中委外專案無

法如期完整驗收的前二項主要原因─需求不明確及需求變更等問題[4]。這些問題要在需求管理的

流程領域中定義地一清二楚，需求訪談及確認的程序，需求變更的程序，都應該明確定義一套可

供合約雙方遵循的制度，合約雙方才可合理地評估時程、費用、人力等等相關資源的變動。如果

相關可供決策的資訊不足，就難以做出合理且正確的決策，也就難保軟體可以如期完成。 根據SEI的分析報告指出，導入CMMI廠商的平均效益如下：

生產力提高35% 產品上市時間縮短19% 產品發行後缺失率減少39% 節省成本對投入軟體流程改善成本的比例為5：1

目前台灣已有國內企業導入CMMI之效益調查報告出爐[8]，已通過評鑑之企業大致上皆認同導

入CMMI後的確帶來效益；而此報告同時彙編國內企業導入時所遭遇的困難，從報告中顯示最大的

困難點仍然在「人」。不論是流程改善推動團隊的經驗或是員工態度等問題，都是國內長期以來

未落實軟體工程的結果。 五、CMMI的評鑑制度 至於CMMI的評鑑制度，是由SEI授權的主評鑑員(Lead Assessor)負責依SEI的方法及資料執

行，透過SEI提供的鑑定工具，並將執行結果回報給SEI。此評鑑制度並無第三者認證機構，但因

於評鑑的規範深入而詳盡，且主評鑑員需經嚴格訓練與換證的要求。因此，鑑定結果的可信度及

一致性仍被廣為接受。另外，根據SEI統計的資料，要達到第二級成熟度約需21個月、第三級成熟

度約需22個月。這對軟體業而言也是項漫長的考驗。而整個導入的費用，包含人員的訓練及評鑑

的費用也相當可觀。幸而，經濟部工業局有補助計畫，可稍減導入組織的經費壓力。 肆、結語

筆者今年參加二次CMMI研討會，第一次研討會是檢視截至去年，CMMI在國內推動的成果。截至

94年9月為止，台灣軟體廠商通過評鑑且在SEI完成登錄已有18家，全球排名第8位，結果尚令人滿意。

但與會人士強烈呼籲，請大家務必務實導入CMMI，不要做假、不要打壞這塊招牌。這是因為與會人士

體認到台灣在引進國際標準時，時常求速成、抄短線，結果造成空有認證，卻無實質用途的情況。第

二次研討會，則是業界在提升軟體品質，積極爭取政府軟體委外案時，也希望政府機構重視軟體委外

時所扮演的角色，畢竟政府軟體委外經費每年約有70億元左右，約佔國內軟體委外市場總值之三成多

[9]，對國內軟體業者而言，這是一塊重要的市場。但在整個軟體委外開發專案中，如果只有供應商改

善軟體開發流程，但不見掌握需求提供及軟體驗收權力的委託單位配合改善，較難收到良好效果。因

此，為求政府(甲方)與供應商(乙方)良性的循環，希望引進CMMI-AM(Acquisition Module, 籌獲模組)，並期望政府機構能檢討軟體採購時採用的決標方式，以全面提升國內的軟體品質水準，創造雙贏的結

果。 （本文由行政院主計處電子處理資料中心設計師陳志良 提供）

參考文獻：

1. http://news.u-car.com.tw/news-detail.asp?nid=4558 2. 胡佑長(2002)，淺談軟體品保與國際品保標準，軟體工業生產力提升特輯，第13-23頁。 3. 張振接(2001)，軟體產業通訊，第42期，第29-36頁。 4. 行政院主計處，政府機關資訊通報，第212期專題報導，

http://www.dgbas.gov.tw/lp.asp?CtNode=418&CtUnit=281&BaseDSD=7&nowPage=16&pagesize=25 5. 資訊傳真電子報第56期(2005)，http://cpro.com.tw/channel/news/content/index.php?news_id=4552 6. 軟體工業起飛，資訊與電腦，第306期(2006年1月) 7. 朱慧德(2002)，CMMI模式表述架構與選擇，軟體產業通訊，第47期，第28-34頁。 8. 經濟部工業局，提升資訊軟體品質計畫網站─CMMI的效益， http://www.cmmi-taiwan.org.tw/cgi-bin/big5/cmmi/po00?q1=picdata&q22=6&q3=ea055 9. 行政院主計處，電腦應用概況報告(92年~94年)， http://www.dgbas.gov.tw/ct.asp?xItem=16141&CtNode=4825

CMMI相關網站：相關網站：相關網站：相關網站： 1. 卡內基美隆大學軟體工程學院(SEI/CMU)：http://www.sei.cmu.edu/sei-home.html 2. 經濟部工業局—提升資訊軟體品質計畫：http://www.cmmi-taiwan.org.tw/ 3. CMMI技術服務網／SPIN-Taiwan：http://www.cmmi.org.tw/default.asp