在最近的一次朋友聚會中，被一些擔任「甲方」的友人問到，是否CMMI在今年將會成為廠商評選的標準？CMMI到底有什麼好處？

　　其實這類的問題筆者常常被朋友或一些學員問到，顯示大家對於CMMI這個話題仍然是非常關切的，但是儘管關切卻一直在觀望而沒有採取具體的行動。

　　儘管筆者對於前者的問題答覆會是：「應該不會，因為現在的景氣不佳，這麼做只會讓更多的軟體企業遭到經營上的困難，而且，在財務拮据的情況下，再花筆錢導入CMMI，以便能夠取得標案的入場券，恐怕也不是件容易的事情。」而對於後面的問題，我的答覆也會是：「透過CMMI可以改善軟體企業的體質，讓軟體企業更具有競爭力」。但是在此時此刻，生存似乎比改變體質更為當務之急。這麼說或許有些同業非常的不認同，但是就一個管理顧問來說，不也常常會告訴我們的客戶要審時度勢，找到最有利的做事方法嗎？

　　雖然我們知道，在這個當口，刺激景氣的方式是增加消費，但主要的問題在於錢從何處來？政府部門會是一個資金流動的很好起點。而每一年，政府部門也花費許多的預算在於資訊系統的提升、新建與維護等工作上。因此，若要在這景氣不好的環境之下，協助企業成長、改善體質，從各種角度來說，政府部門需出更多的力量。

　　筆者個人認為，儘管目前的情況，CMMI在標案的選商是一個加分項目，但，不代表CMMI的廠商一定可以取得合約，因此，我們還是可以假定取得合約的廠商可能是沒有CMMI評級證明的，另外，即使通過CMMI的任何評級，亦不代表在專案中，他們真的可以用CMMI的實務去完成所有的專案工作，交付出品質符合要求的產品。因為，在整個供需的過程中，需要甲乙雙方密切配合的。（目前國內僅有一個政府部門取得CMMI-ACQ評級。）

　　SEI在接受美國國防部委託發展CMMI-ACQ時，其實也提出了獲取者(合約甲方)在系統/軟體工程專案裡，具備獲取(acquisition)能力成熟度的重要性。在過往的例子中，許多專案的問題在於專案時程規劃與預算編列不夠確實，在極短的專案時間內(例如，資訊系統發展案於半年內)要完成所有的專案活動並交付各種產品(含硬軟體與文件)，預算可能僅佔合理預算的六成而已，若再加上獲取單位經辦人心態不正確，認為最終的責任都可以推卸給乙方，只要咬住乙方不放，自己就沒有任何責任，使得專案無法結案甚至於無限期延長。這種不合理的情況，反映的是獲取單位的規劃與管理能力不足。因此，筆者較傾向，在這個金融海嘯衝擊之下，最需要先提升的應該是政府部門的資訊業務委外的服務獲取單位。這些單位應該多花錢與工作量在獲取實務的學習與獲取管理能力的提升上。

　　政府部門開始改善獲取管理能力的意義在於「以身作則」「刮別人鬍子之前先把自己的鬍子刮乾淨」，也為未來擴大CMMI成為選商標準打好基礎。政府部門導入與建立專案管理的能力，將有助於在資訊系統建置或運維委外專案的規劃，能夠有一套正規的方法，獲取單位可以更有機會規劃出專案合理的時程與預算，並且依據實際需要規劃出相關的產品(含最終的軟體產品、硬體及相關的系統文件、專案管理文件)。另外，也由於獲取單位具有全生命週期視野，以及獲取管理成熟度，可以有效配合已取得CMMI-DEV評級之廠商，確實做好產品發展或維運專案的所有活動，產生符合需求的產品，使甲乙雙方雙贏；對於沒有取得CMMI-DEV評級的廠商，也可以起指導的作用，因為在專案中，不可諱言「甲方為大」，甲方可以發揮其影響力，以其正確的工程管理認知，指導廠商做好應有的工程活動，必要時提供相關的教育訓練，並嚴格要求，這同時也可以讓廠商體驗、並認同按照CMMI所要求之實務所獲得之好處，在未來經濟情勢好轉時，更願意取得CMMI-DEV評級。

　　在經濟環境不佳時，政府部門除了設法刺激消費之外，也應該先於廠商，設法追求自身業務能力的成熟度，這不僅在CMMI，更應擴及資訊安全管理(ISMS)、資訊技術服務(ITSM)，甚至於業務持續性管理(BCM)等等能力的建立與成熟化，當政府部門的相關能力均建立起來，並能劍及履及，相信相關廠商也會受到感染，自我要求於體質的改進，而不需等到這些要求成為選商的標準。

----------------
引文:

關於「政府部門應提升廠商管理與要求的能力」，我舉雙手贊成。拜讀了今天 貴會程家麒前理事長在中國時報的投書，更是感觸良深，文章中有段話 :「國內資訊服務廠商由於過去多半獲利不佳，素質參差不齊，加上政府採購與管理經驗不足，雖然經濟部標準局已經參照國際規範訂定了相關的軟體工程國家標準，可惜 ...... 在需求採購單位不願增加軟體品質與管理成本預算的情況下，絕大多數的資訊軟體開發專案都沒有遵照國家標準，仍以傳統磚瓦屋的方式建造現代化辦公大樓，以致問題叢生。如果有機關嚴格要求遵照軟體工程標準及撰寫相關技術文件，但預算卻未增加，業者最後不是利潤微薄就是導致虧損。」真是述說出了今天台灣許多資訊服務廠商的無奈。

所以，我認為政府機關如果能夠導入CMMI或CMMI-ACQ固然很好，但是如果大多數的政府機關連最起碼的CNS14837國家標準都不知道遵循，編列預算也還是用蓋傳統磚瓦屋的觀念，還奢談什麼CMMI或CMMI-ACQ呢 ? 還是趕緊先把基本功課做好了再說吧 !

CMMI-ACQ / CMMI- DEV與CNS14837其實是不衝突的，因為CMMI是指導組織改善能力時應依循的改善路徑，也就是先要於那些“流程領域”進行改善，改善時要達到什麼目標。因此，它本身不是流程，它只是組織改善能力的“地圖”。由此可知，組織是藉著“建立流程”與“改善流程”，來提昇其能力。對一個軟體籌獲(或開發)組織要建立其流程，最便捷的方式就是遵循國際(或國家)有關軟體生命週期的標準，即IEEE 12207、ISO/IEC 12207 (CNS 14837)。因此，CMMI與CNS14837是不衝突的，甚且是相輔相成的。

其實，組織藉由推動CMMI以提昇其籌獲(或開發)軟體的能力時，僅使用這兩個標準(CMMI、CNS14837)是不夠的，它應該還要加上PMBOK Guide(專案管知識體指南)。因為，CMMI中的成熟度等級2(Managed)表示組織於專案層級是有管理的，也就是組織具有基本的專案管理能力。所以，個人以為組織要達到Level 2的能力成熟度，遵循PMBOK建立其專案的管理過程是另一必經的捷徑。

一個組織藉由遵循CNS14837建立其產品導向的流程，與PMBOK建立其專案的管理過程就可以了嗎？當然這還是不夠的，因為CNS14837開宗明義就說說：「本標準目的並非用來規定所要產生的文件的名稱、格式及明確的內容。」因此，組織必須依循其它的國際標準，規範過程中各活動的產出(如：依據IEEE 830撰寫軟體需求規格書)。所以，組織於推動CMMI的過程，應同時多方參考、引用國家與國際標準。

除此之外，組織於提昇其軟體籌獲與開發能力時，個人以為，還有一件更為重要的事情，就是“採用一個好的生命週期模型”。什麼是好的生命週期模型？個人以為一個能促進專案成功，也能促進組織持續發展其能力的生命週期模型就是一個好的生命週期模型。以此標準，“瀑布式”生命週期就不是一個好的生命週期模型。其不能促進專案成功的理由，散見各軟體工程相關的文獻與書籍中，在此就不再贅言，以下僅就其會妨礙組織發展專業能力一事，表達一下個人的看法。

“瀑布式”生命週期模型的特色是將專案階段與軟體開發活動合而為一，也就是在軟體開發時期，任何一個時點上幾乎只進一種軟體開發活動，因此，也就只須要一種角色的工作人員。更明白地講：就是分析階段，只要分析的人員；設計時只須要設計人員；編碼時只須要程式設計師…餘類推。此一特性，會誘使不肖廠商基於階段成本的考量(殊不知此一做法卻造成專案總成本的最大化)，於分析階段不雇用合格的分析師，設計階段不雇用合格的設計師…等；而只雇用一名或一批程式計師，於專案的不同階段扮演不同的角色。此一現象，長久以來已造成台灣軟體業界，幾乎只有Coding的專業人員，其它軟體專業人員(如：系統分析師或需求工程師、軟體架構設計師、軟體測試工程師、軟體專案經理…)嚴重缺乏。

請看看其它各行各業為求更大的發展，無一不走上專業分工，而且是愈分愈細。為何獨獨台灣的軟體業，數十年發展下來，還無法走上專業分工？個人以為個中原因，與採用此一生命週期模式有其密不可分的因果關係存在。

因此，在此個人要大聲呼籲政府單位：『以後發包軟體開發專案時，不要再於RFP中有意或無意地、明示或暗示地、導致或誘使供應商使用“瀑布式”生命週期模型，進一步明訂禁止使用此一生命週期模型。』

果真如此，則台灣軟體產業將“還有明天”。

最後，僅虔誠地為台灣軟體業祝禱！

筆者原本的想法只是在呼龥政府在要求廠商把產品與服務的品質做好前，應該以身作則，起帶頭做用，因為依照SEI的研究，專案做不好的原因，其實有很大一部分是因為獲取者本身的成熟度不夠。而現在經濟不景氣，政府在刺激消費的同時，也應該編列相關預算，提升本身的獲取管理能力，並帶領廠商做好專案的工作，交付符合品質的產品與服務。

-----------------------
這些年來筆者也聽到很多「CMMI與ISO 12207相輔相成」的說法。其實，筆者個人極力避免這樣的概念，即使兩者對於軟體組織能力的提升真的有幫助(因為第一個說出這句話(「CMMI與ISO 12207相輔相成」)的人，其目的是希望為CMMI找到立足點)。主要原因在於，兩者的命題與出發點是不同的，ISO/IEC 12207主要是從軟體工程的角度出發，從做出具備品質之軟體產品，組織應該執行的過程有哪些，而CMMI則是從組織的角度，CMMI是一個模型，用來看組織在執行工程與工程管理上成熟程度的模型。前者用於指導專案或從事專案活動的組織在軟體開發上要做的活動與工作，而後者則是給組織的管理階層內省或外部評鑑員評估組織工程能力成熟程度的一個指導綱要。在工作流程的方向性與整體感上，CMMI是較ISO/IEC 12207不足的，因此，筆者在協助客戶建立流程文件時，會建議客戶以ISO/IEC 12207為經，而以CMMI為緯，當然，從CMMI的過程領域在實務流程的ISO/IEC 12207過程活動與工作的對映上，需要花點時間的。一個公司在建立CMMI的過程文件時，在沒有ISO/IEC 12207當骨架的情況下，如果先前沒有任何ISO 9001的經驗，會花相當長的時間。其原因就是我前面所提到的，兩者的切入角度是不同的。當然，以ISO/IEC 12207的角度來說，其深度是不夠的，主要原因在於要留給組織彈性的空間，可以依組織的特性、組織結構、文化、業務特性等角度來裁適(可以向上與向下裁適)。

CMMI的角度與ISO 15504的角度是相同的，但是，ISO 15504(軟體過程評鑑標準)有ISO/IEC 15288(系統生命週期過程)、ISO/IEC 12207(軟體生命週期過程)為過程參考模型(PRM)。而在ISO架構之下，對於專案管理的指導(在ISO/IEC 12207:2008年版本中，亦明確提列了與專案相關的過程)、系統與使用者文件、風險管理、組態管理、決策管理等等，亦均有國際標準得以遵循，而且相互連貫。所以，如果不看潮流的走向，而以完整性來看，CMMI其實相對是較弱的。對於導入CMMI-DEV的組織來說，要借重顧問與其他行業的標準的協助更多，因為，CMMI-DEV就僅僅是一本技術報告而已。

----------------
引文:

過去國內在推CMMI-DEV(或其較早版本) 時，有一些缺失，如下：
1. 組織以通過評鑑為目的，而不是以改善組織能力為目的；
2. 以CMMI為萬靈丹，也就獨尊CMMI，而不知還有其它國際標準亦可助其提昇能力；
3. 不知組織的能力是以成員的能力為基礎，組織成員能力不足，是不可能有組織能力的。

因此，政府部門其本身如果希望藉由導入CMMI-ACQ來改善其籌獲系統或軟體產品的能力，不應再蹈此一覆轍。所以，個人才會對此一事件提出之前的看法，現在再彙整如下：
1. 於組織中推動CMMI-ACQ之同時，若能借助其它國際標準(如：PMBOK Guide、ISO/IEC 12207(或CNS 14837)、及其它IEEE 之標準)，做為文件產出與過程的標準，才能收事半功倍之效。
2. 12207中規定籌獲組織與供應組織(即使用標準的雙方)需為軟體專案選擇生命週期模型亦負有選定及應用軟體開發方法之責。因此，籌獲方應於選擇生命週期模型與軟體開發方法上，更積極主動才能達成預期之目標。
3. 積極訓練組織成員，提昇個別成員的能力，以使組織擁有足夠數量的具有專業能力的成員。

政府組織若於籌獲系統或軟體產品/服務的專案中，懂得“要求自己、要求其供應商、再要求供應商的下包商”時，那麼台灣的系統/軟體產業才會“有明天”。

新的一年剛開始，願您我發揮 最“牛”的精神 只問耕耘不問收穫
最後，牛年一定會帶著您我犇向成功！

祝福大家!