CMMI─專為軟體量身訂做的流程改善制度

CMMI真是一盞明燈嗎？

CMMI（Capability Maturity Model Integration，能力成熟度模式整合），以一句最簡單的話來說明，CMMI是一套為了系統工程與軟體工程量身訂做的流程改善制度。由於此次的焦點主要係針對軟體的部份進行探討，因此，可再簡化為『CMMI是一套為了軟體工程量身訂做的流程改善制度』。

若根據美國軟體工程學院（Software Engineering Institute，SEI）的文件，再進一步深究，自會衍生出「連續式」與「階段式」兩種不同表述方式，接著是「流程領域」的主題與不同的分類，而且每一個「流程領域」都務必達到「目標」、「執行方法」，最後才是看到「內容」。然而，軟體廠商在導入CMMI時，會碰觸到正反兩面的問題，讓我們試就此問題來做更深入的探討。

首先，不管是印度執行CMMI的公司或是國內現已導入CMMI的公司及輔導廠商，都將CMMI視為救星，寄予無窮的希望。CMMI搖身變為『人月神話』裡的「銀彈」，一槍就能讓狼人立即斃命。然而，事實情況真是如此嗎？其實不然。根據The Standish Group在2000年針對軟體專案準交率進行大規模調查，結果顯示軟體專案能順利準時結案的比例實在低的可憐，軟體專案的成功率不到30％。CMMI果真是一盞指引方向的明燈嗎？答案頗耐人尋味。

其次，一般輔導公司在介紹廠商如何利用CMMI來改善軟體品質問題時，都會提出三個維度，為「People」、「Technology」、「Process」，而其中尤以「Process」為其中的「槓桿點」最為重要。有趣的是，在談到導入CMMI遭逢的困難與風險時，卻一致將焦點對準「People」，如尋求高階主管的支持與同仁的配合與投入等，這對於風險管理來說並不太合理。

科技始終來自於人性

近來，許多企業管理方面的暢銷書，如管理大師Peter Drucker 的「有效的管理者」及Joan Magretta 的「管理是什麼？」，都有一個共同現象，即強調「人」的重要性。書中提及，現代經濟環境中的工作，絕大多數是知識工作和服務工作，過去強調監督與控制的管理工具已慢慢淡出企業管理的舞台。我們無法靠「監督」的方式來逼迫工程師寫出好的軟體程式，也無法藉以「命令」讓產品設計師一夕之間就變得更具創意，同樣的道理，CMMI也不行。曾有家知名科技業者打出一個響亮的口號：『科技始終來自於人性』，將這句名言套用在CMMI的品質改善是再適合也不過了。或許「Process」是「槓桿點」，但最根源的動力還是來自於「People」人性上。

一般而言，一件事情背後所隱藏的「動機」常是促使我們完成該事情的主要原因。既然如此，那麼導入CMMI的成功「人性」因素背後的動機是什麼呢？或許我們可以這樣假設：

Q：為何要導入CMMI？
A：當然是為了能擁有更好的軟體品質！
Q：為什麼導入CMMI就能創造更好的軟體品質？
A：因CMMI在軟體開發的各個「流程領域」裡，都
設定了務必達到的要求與目標，只要能達到要
求，就定能保障軟體的基本品質。
Q：若沒有CMMI的要求，在軟體開發過程中，對於
「流程領域」的要求是否就不再需要？
A：這，就是筆者所認為的關鍵性問題了！
又可依「需要與否」的角度，區分出兩個不同的問題：
第一個問題是「若沒有CMMI的要求，是否就無法寫出一個好的應用系統？（稱之為必要條件）

答案是「YES！」筆者以為CMMI導入成功與否的「關鍵」，同時也是「人」這個維度的所在。許多軟體開發人員甚至是客戶都不認為除「寫程式」之外的「軟體工程」所要求的內容，對於開發一個應用系統而言是有其「必要性」的。大多都是當有問題發生時，才回過頭將軟體工程的要求全數搬出檢討，如需求分析未確實執行、單元測試沒有做完整、風險管理未事先討論詳細等，實不勝枚舉。然而，當下個專案又開始執行時，同樣的問題還是會一再發生，無形中也形成一種不良的示範與循環。

既然軟體工程的程序是如此重要，為何仍無法受到軟體廠商及客戶的重視呢？究其原因在於，對軟體本質上的複雜度及對軟體缺乏足夠且深入的了解。因此，一旦客戶有不合理的要求提出時，軟體廠商大多選擇犧牲堅持立場而予以妥協，自然影響專案準交率的時間，進度一再被拖延。其結果就會陷入『人月神話』一書中所提的，在一個Delay的專案中再加入人手，只會使情況變得更糟。

一套軟體系統最明顯的錯誤是將問題過於單純化。但這並不單是開發人員或客戶會犯的錯誤，而是對於整個軟體產業環境的市場機制所產生的誤解。筆者發現有一種產業與軟體產業有極類似的情況，就是「減肥食品」。減肥食品的廣告不斷標榜著「不用運動」、「一週見效」、「無副作用」等誇張訊息，是否與研討會裡不斷向與會來賓灌輸的「5個步驟開發一個Web Services」、「又快又好」、「不用Coding就能開發系統」等訊息相類似？想當然爾，結果早在預料當中，軟體系統就好比人體的脂肪不斷地困擾著你我，但仍有數不清的人會對這樣的謊言深信不疑。

你大可不必會撰寫程式，但一定要了解開發一個軟體系統絕對不等於寫程式，就如同蓋一棟大樓，最後實際建造的工作僅佔整個工程的一小部份而已，但大多數的時間都必須花費在大樓的整體設計、驗證及與業主不斷溝通、修改設計藍圖的過程上，我們從沒聽過大樓蓋到一半才被業主臨時要求要多加蓋一層樓或少蓋一層樓的笑話，但軟體工程可就不同了。軟體在開發過程中，會不斷地被要求要修改程式，美其名是客製化才能讓系統更貼近使用者的真正需要，但實際情形卻是一支程式在經過超過10個人在不同時間修改過後，只是徒增軟體本身的複雜度。

在沒有CMMI時，我們不需製作許多文件來交待軟體開發的流程與時程，修改程式與功能的增刪修可以隨使用者調整，想改那裡就改那裡；但有了CMMI後，每一個動作都必須依據SEI制定的準則，隨意修改一行程式的事情恐將成為回憶，每一步都必須從專案管理的角度審視，如修改程式是否會影響開發時程及成本？是否要對應到哪一項需求或功能的變更？修改程式是否會影響其他的分析設計？有功能有哪些需重新測試？應留下什麼樣的記錄以利後續的追蹤修改等…凡此種種，影響甚深，在不斷要求修改需求的情況下，最終所賠上的代價與成本將是軟體廠商及客戶自己。

第二個問題是「如果完全遵照CMMI的要求，是否意謂著我們就可以寫出一個好的應用系統？」（稱之為充分條件）

答案是「NO！」這個問題還可以轉換成「除了CMMI外，一個好的應用系統還需具備什麼條件？」或是「CMMI真有這麼完美嗎？及有沒有什麼問題是CMMI無法解決的？」的形式來思考。

除了CMMI能帶來的好處及產生的正面效益外，導入CMMI的過程中可能遭遇的障礙或是CMMI的缺點也應在導入前納入考量，才能在事先規劃並避免可能發生的錯誤。然礙於篇幅限制，試提供幾點逆向觀點，如下：

CMMI僅要求軟體開發應達到什麼要求（What），卻未談及該如何去做（How）─因此，軟體廠商若只是為了達到CMMI的要求才設計出一堆文件來應付CMMI的評鑑，即便通過評鑑，所衍生的負面效益卻遠比導入CMMI帶來的好處還多，可謂得不償失！更有可能會流於形式，為文件而文件，最後工程人員仍沿用舊有習慣與方式開發軟體。曾經在網路上看到討論XP（eXtreme Programming，開發流程亦稱終極流程）與CMMI的差異。有人認為XP是講求最少的文件與重視程式設計本身是否能符合快速變動的專案需求；而CMMI卻恰好相反，不但要求準備許多文件，注重流程，並嚴格要求每個步驟，XP與CMMI兩者間是有衝突的。事實上卻非如此，有些公司採用XP的方式來從事軟體開發，也同時獲得ML5的CMMI評鑑資格。因此，軟體廠商應該思考如何設計一套最符合本身需求的最佳開發方式，遠比只想取得CMMI的評鑑來得重要。

CMMI沒有教導軟體廠商該「找出需要做什麼」，僅教導在流程上該做到什麼要求，這之間的差距甚大──在『最後期限』及『與熊共舞』的作者Tom DeMarco提到：「軟體的關鍵問題就是“找出需要做什麼”，而“怎麼做”則是次要問題—所有的技術、工具和過程解決的都是這個次要問題。」筆者完全認同此觀點。的確，在“怎麼做”的問題上，我們已獲得極大的進展，但在“做什麼”的問題上，幾十年來情況似乎仍未獲得太大的改善。

導入重點應著重在找出一個「好」的軟體過程─UML的創始人之一Ivar Jacobson明確的指出，「把一個好的軟體過程變得可度量非常容易，但是把一個可度量的軟體過程變成一個好的軟體過程卻很難。」由此可看出，軟體過程不應只是單純的滿足CMMI的各項要求，否則結果會適得其反，只是找出一個可以更快速開發出高品質的「壞」的軟體系統。

結論

在「人月神話」裡有則小故事，內容是敘述一家紐澳良百年老店Antoine餐廳的點菜單上有一段話「好菜都得多花些時間準備，為了能讓您享受到更美味、更可口的佳餚，請您務必耐心稍待。」這讓軟體開發人員打從心底相信，唯有透過CMMI導入過程的嚴謹要求與程序的落實，才能端出一盤軟體好菜，而客戶也能樂意等候與配合來回應，以獲得一個既滿足需求又高品質的軟體系統。這或許才是CMMI能帶給我們的真正價值。