CMMI與框架沼澤（Frameworks Quagmire）

1.197x年末198x初美國國防部面對層出不窮軟體問題制定出軟體流程標準，其目的希望能由買方角度增加賣方在Process方面的透明度，俾儘早對於不良流程採取改善措施。因此1985年制定了DOD-STD-2167，雖然在1968年有海軍公佈的DOD-STD-1679 Weapon System Software Development Standard，但因為DOD-STD-2167包括有生命週期之文件撰述說明Data Item Description （DID），可將之歸類為流程標準（Process Standards）框架（Framework）。此等框架包括後續產生之MIL-STD-498、ISO/IEC-12207、ISO/IEC-15288、EIA-632….等。彼時所制定之標準皆以 “shall”規範承約商必須執行之事項或工作，所以從Proposal角度解讀Standard，只要看到shall一字就應該有相對應的traceability以及報價。

2.所謂框架，如果以1999年頒定Federal Enterprise Architecture Framework (FEAF)的定義為“A logical structure for classifying and organizing complex information.”。但無論何種Process Standards，皆難以敘述專案起頭之Problems and Needs，以致經常發生RFP之需求（Requirements）與使用單位之需要（Needs）有偏異之現象，因此美國管理與預算辦公室(Office of Management and Budget，OMB)針對聯邦政府單位採購資訊系統時規定必須將需要(needs)、資訊系統功能(information content)、及資訊系統技術能力(information technology capabilities)予以串接在一起；由於各行政單位之資訊系統有其Domain之差異性，因此衍生有聯邦政府企業資訊架構框架(FEAF)、國防資訊架構框架(DODAF)、財政部企業資訊架構框架(TEAF)、…。一般專案所將完成的Products，以及發展該等專案所應引用的Process Standards皆屬於AF之下的Components，但一般不會包括以下所敘述的Appraisal Method（Assessment Standard）、Maturity or Capability Model。事實上對於美國政府資訊系統採購，現在已不個別敘述Frameworks，因為整個資訊系統架構已提升為Architecture Framework （AF），Software也以Software Intensive Systems of Systems (SISOS)來取代，整體架構框架（AF）集中在ISO/IEC-9126的Interoperability。

3.在DOD-STD-2167文件亦包括有 “5.8 Software Quality Evaluation”之章節，其後在新版之DOD-STD-2167A將之分離另訂DOD-STD-2168，可歸類為品質標準（Quality Standards）之框架。此包括後續產生之ISO-9000、TL-9000等。

4.但在日趨複雜之流程標準、甲方希望了解賣方是否落實流程標準、或乙方希望確認公司執行流程標準之能力等因素下產生了由第三者對於乙方進行評鑑之需求，此需求包括有評鑑標準(Assessment Standard) 或稱之為評鑑方法（Appraisal Method）的框架，此包括有ISO/IEC-15504、EIA/IS-731、SCAMPI、CBA IPI、SDCE、..，以及成熟度或能力模式（Maturity or Capability Model），此包括有xx-CMM、CMMI-xx、FAA-ICMM、…。

5.另有於不屬於上述四種的Frameworks，但對於工程執行、專案合約等可歸於執行方法且會影響專案組織架構的文件，歸之為導引（Guidelines），此包括有PSP、TSP、RTCA DO-178B、Six Sigma、PSM、…。(美國政府的採購層次為Policy→ Requirements→ Guidance→ Technical Standards)。

6.在陸續產生各種Quality Standards、Appraisal Method (Assessment Standard)、、Maturity or Capability Model、Guidelines以及架構框架(AF)等環境下，已讓甲乙雙方陷入極度困擾之狀況，因此 www.software.org 於1997年繪製出Frameworks Quagmire，並於2001年於IEEE Computer Society發佈新版The evolution of Frameworks Quagmire ( http://g2sebok.incose.org/app/qualsys/view_by_id.cfm?ID=INCOSE%20G2SEBOK%205.1410&ST=F) 。如果你可以由上圖體會作者以顏色區隔出Process Standards、Quality Standards、Appraisal Method (Assessment Standard)、Maturity or Capability Model、Guidelines等之差異，就達到作者希望你不會陷入泥沼（Quagmire）之用意，也將易於了解Standards與Maturity or Capability Models/Appraisal Method之關係以及差異或關係。

7.SEI教材中亦引用上圖http://www.sstc-online.org/Proceedings/2002/SpkrPDFS/WedTracs/p931.pdf 但可惜SEI除拿掉代表 Frameworks 分類的顏色註解，甚且將原有Framework屬性予以混淆，如原屬於Quality Stds的DOD-STD-2168被混入代表Process Stds的綠色類別，所以你若未參考原圖仍將持續陷在Quagmire中(SEI本身似乎已陷入泥沼之中)。但由SEI的圖中可以確定的是持續保持有Process Standards與Quality Standards，CMMI 並不能取代IEEE/EIA-12207、ISO-9000等Standards。當你聽到國內產、官、學、研在推動CMMI時使用“CMMI為國際間普遍認同的一種軟體開發程序標準”之措詞 ( http://www.moeaidb.gov.tw/portal/ePaper/mail/SendPaperReview.jsp?num=43) ，你就可以體會該措詞適宜與否或可視之為笑話一則（對於國內而言實等於輔導單位將該圖的Process Stds、Quality Stds予以刪除）。但其更大的風險在於無Process Standards、Quality Standards環境下，大力推動Appraisal Method (Assessment Standard)、Maturity or Capability Model甚且誤導產業界將CMMI視為發展標準，等於將國內IT產業帶入泥沼之中（產生無法脫身的困境，甚且已將國內資訊業帶入Fred Brooks 1975年所撰述The Mythical Man Month一書之Tar Pit的境界）。

8.Standards一辭不可濫用，其定義可參考美國政府文件OMB Circular A-119 （CMMI是在美國採購環境下之產物，所以最好以美國的定義做解釋）；由採購角度觀之，甲方的RFP Requirements僅需敘述“What to do”，不要過度侵入設計領域，乙方要在Proposal中Propose出“How to do”的Technical Standards，否則無助於整體採購品質之提昇。

我呼應林秘書長前文的意見，透過 貴協會網站過去的討論，相信大家對於 CMMI 推導與評鑑存在的問題應該已經多有瞭解，但僅談論問題與解析病理是於事無補的，現在大家應該要討論的是改善問題的藥方 !

我綜合各位先進前面的討論，認為現在當務之急需要檢討改善的課題包括：
(1) 如何提升 CMMI 輔導結案的品質 ?
(2) 如何確保 CMMI 通過評鑑的品質 ?
(3) 如何健全企業主導入 CMMI 評鑑的正確觀念 ?
(4) 如何改善資訊委外機關的成熟度 ?
(5) 儘速公佈通過 CMMI 評鑑之企業及其評鑑組織範圍的詳實官方資訊，以免魚目混珠 !
(6) 打破文憑主義的迷思－「文憑不是檢驗真理的唯一標準」，雖然通過 CMMI 評鑑應該代表其具有一定的成熟度，但其是否落實執行還是需要輔以其它務實的要求，何況 CMMI 評鑑還有三年效期的限制。文憑主義是創造「補習文化」的溫床 !

我非常同意Joker所說的：「...以我參與CMMI的經驗，可以確定的是輔導公司的顧問或LA本身並未有涵蓋Level-2/3 的全部工作實務，大部分連Design Review或Change Request都未有過實務經驗，就敢上台輔導，...」云云。

身為一個過程改善顧問，我必須說的是，一般顧問他只是在告訴客戶如何去達到那個框架制度的要求，而不管客戶的基本功如何，客戶自己本身的對於獲利認知為何，以個人服務的公司而言，顧問被要求要尊重客戶的文化，要與客戶維持良好的關係，我們儘可能不去觸及這些問題(否則就會與我之前對另一個合作公司的客戶的老闆說：「我認為你們公司沒有能力導CMMI！」，然後調頭走人)。因為那是客戶自己要負責的。當然，如果客戶有了解工程與專案管理上"How to do"的需求，就需要另外計價提供，或者協助找到好的講師提供教學服務。像去年個人受公司指派到大陸去上幫兩個客戶上Software Estimation及Requirement Development的課程，就是一個例子。所以就算顧問沒有相關工程實務經驗，沒有做過專案、沒有規劃過專案生命週期過程、沒有真正去做過估算，沒有關係，需要的時候找到一個有能力的人提供這些知識、經驗與專業就可以了，但如果顧問說：我不會寫程序文件，我不懂什麼是ETVX，不會訂制度，我不懂得裁適該怎麼做，那才真的是很扯的事。

其實之前我與理事長曾經也談過能不能在協會的網站上公布軟體系統專案執行有瑕疵的軟體公司，但是這個不太容易達成，有主客觀因素影響(例如，甲方不太容易承認專案是失敗的，這是因為除了承辦人的前途外，說專案失敗其實也會波及到長官的政績，所以....像台灣高鐵這種案，因為藏不住所以是不得不承認，要不然真的舉目皆是，不勝枚舉。某專案延宕兩年，應於九十四年底就該驗收，到了九十五年第三季還沒驗收就剪綵啟用，還獲得首長肯定，並且得到兩個有關資訊應用的獎項，系統到現在還有近百項問題待解決而不能驗收，是不是夠諷刺？實質上這不也是失敗的專案？但承辦人會承認嗎？其長官會承認嗎？)，而且可能引發很大的問題，所以這件事就作罷了。

另外我想說的是，去年我到大陸去上課，順便看看他們執行的狀況，我覺得台灣的軟體業真的沒有什麼競爭力了，大陸做得真的是比台灣好。這個產業需要有理想的人去貢獻，例如，大家認為做得不好，或者拿CMMI評鑑是在作秀，大可以前進到第一線去帶領，有機會的話就該去爭取當大案子的專案經理，去說服甲乙雙方去運用良好的工程與專案管理常規在專案裡，然後由有心人士來帶領大家去學習真正的工程與專案管理的精髓，為甲乙雙方帶來制度的利益(不論是在財務方面或者競爭能力上的)。我想總比在這邊談這個不好那個怎樣，現在是有問題沒錯，這個大家都知道，但是解決之道在何處？

我們的甲方不夠成熟，我覺得才是問題的最大決定因素。以美國軍方為例，美國軍方長久以來一直做一件事情：由美國軍方制訂標準，要求業界去遵循，美國軍方還成立國防獲取大學(Defense Acquisition University, http://www.dau.mil)，來提升獲取的相關能力。反觀我們國內的環境又是如何呢？

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

謝謝alexyin以實例幫我點出問題，我也參與過高鐵售票系統開發，只能講公司的實際做法就是CMMI歸CMMI，專案歸專案。

也謝謝jeffery所說的“ 台灣導CMMI好像在準備考試, 只要過關拿到認證即可, 我不曉得這是CMMI本身有問題? 還是幫忙推導CMMI顧問的問題? 還是評鑑CMMI顧問的問題?”

希望這個高鐵案例能讓工業局對於CMMI做個檢討。

以我參與CMMI的經驗，可以確定的是輔導公司的顧問或LA本身並未有涵蓋Level-2/3 的全部工作實務，大部分連Design Review或Change Request都未有過實務經驗，就敢上台輔導，公司等於是花錢買考古題的解答，拿錢幫顧問公司建能量，至於類似CCB如何舉行，沒人管，反正只要有文件紀錄即可(一天完成也無所謂)，這才是最大笑話。

答案不是已經回應了嗎？那是一個集體造成的問題，而非單純一家公司的問題。

社會充斥太多病理學家論述，獨缺針砭之作。
紛亂的世代，需要的是正確的方向與力挽狂瀾的氣魄。

CMMI框架本身並沒有問題，因為它是一個最佳常規的集合，而導入CMMI的公司沒有辦法把事情做好，固然是事實，主要是因為執行的人有問題，但不應該就去推翻這個框架的價值。

今天，個人以為該談的不應是再去找出更多的坑坑疤疤，因為這些都是老生常談了，反而應該是貢獻一己之力，思考一下如何興利與防弊，否則只是讓整個市場更為混亂，採購單位動則得咎，更加趨於保守，寧可相信自己，也不願意去相信良善的制度，或者引用良好的制度在管理上，如此，什麼ISO/IEC 12207, CNS 14837, ISO/IEC 15288, CNS 15508都將只是參考，本協會也沒有任何存在之價值了。

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

這種現象為何會發生在CMMI SW/SE Level-3 的公司?

新聞 1.「抱歉、不知道」　高鐵大當機！手足無措

從1月5日到1月14日高鐵試營運一連10天，車票半價，今天起開放民眾預購，一早就有大批民眾前往高鐵車站買票，不過卻是狀況頻傳，電腦系統連連出錯，引起民眾不滿。

新聞 2. 首日賣票：亂！慢！塞！旅客怨 高鐵道歉

高鐵售票上午正式開跑，不到六點就有大批民眾湧進高鐵沿線車站，希望搶購到具有收藏價值的紀念車票，可惜高鐵委託「XX 公司」設計的票務系統不爭氣，讓旅客大排常龍，北部三個車站都傳出無法使用信用卡的現象，高鐵台北站專員丁莉華說上午六點三十分，發現不能使用信用卡，勸導民眾改用現金。
http://tw.news.yahoo.com/article/url/d/a/070102/1/8uwd.html

看完各位對於CMMI的所謂笑話，顯然業界是需要更多的工程與管理再教育的。因為這些所謂的笑話，當你更了解這個模型的目的，以及從企業目標的角度去思考的時候，這些根本「不是笑話」，而是「悲哀」。 而悲哀的是，在一些錯誤的期許下，國內的資訊產業競爭力每況愈下。

不知道各位看倌是否了解為什麼ISO 9000:1994要進化到ISO 9000:2000年版？這其中的一個因素就是成本的問題，因此，在新的一個版本早已就不再盲目追求「零缺點的品質」，而是滿足要求。

CMMI ML3，在產品品質上追求的也是「滿足要求」，在組織流程上是要持續改善，透過流程的持續改善，提升產品品質降低成本與風險。但是我們要注意到的一件事是，每一件事都是要成本的。當大家在看這篇短文裡的所謂「笑話」時，大家是否想過，我們的客戶在外包資訊系統開發與維運服務案時，是不是已經估算到所有可能的成本，並且提列出來？事實上是沒有的，廠商在看到客戶RFP的時候，最多只看到一個預算金額及工作條款(SOW)(包括需求，甚至於工作條款都是不清楚的)，這樣子的RFP其實根本不合格，而且嚴格來說，這樣的RFP，包商應該可以就把這些當作專案的範圍，而沒有提列清楚的，都不算是RFP裡的需求，除非是一些明顯可以確認屬於衍生需求者，而且客戶如果要求得更多，應該是要有超然獨立的單位來認定，確認是屬於衍生需求，否則都應該是被視為在範圍之外的需求。另外，RFP當中也應該有一個相對於SOW項目的預算分配，這個預算分配除了給最終產品的預算金額之外，還應該包括所有專案管理(管理性文件及各項報告)及支援性工作(建構管理、品質保證、驗證與確認、測試、稽核、審查等等)的預算，而廠商要根據這些項目，提出廠商自己基於過往專案經驗，在這些項目上，以符合專案品質要求為前提的預算分配。這樣的說法，看似對於政府部門不公平，但是實際狀況是，對於客戶方如果沒有這樣子的要求，政府部門的最高管理階層並不會重視這些事項，而永遠只是看著一個數字在做管理，不會設法訓練出合格的人員，以從事資訊服務外包專案規劃與管理的工作，而把這些專案的規劃、執行、管制的工作，託付給非資訊服務獲取規劃與管理的專業人員來執行。

個人參加了數次由工業局主辦，資策會與中華軟協協辦的獲取管理的研究成果報告，根據統計分析結果，政府部門總認為自己的採購作業是有一定的流程的，而且所做所為都符合那個流程的要求，但是，實際的狀況是，就算形式上滿足了採購流程與相關法規的要求，但是實質上產品的內涵是沒有辦法滿足專案執行的要求的，但是大家也許會質疑，政府部門在辦理採購前，不是會經過層層關卡的內審作業嗎？相關的主官、管，會計部門、資訊部門的人不是都會參與審核及簽署的嗎？但問題是，會計人員管的只是那個預算數字及預計的預算執行時程有沒有問題，階段裡有沒有產出可以當驗收標的，在預算編列上合不合規定；招標訂約單位的工作，則是以其他案子的金額為標準，透過砍案子的金額來顯示自己的績效；資訊人員只管資訊技術的問題；那專案管理的問題誰管？工程管理的問題誰管？事實是根本沒有人可以管。不是有資訊人員嗎？個人相當懷疑(至少我所遇過的政府資訊人員承辦人員，對於專案管理、工程管理就沒有很完整的觀念，並具備良好的知識與技能)。事實上，通常不會有政府部門的人員，在專案外包簽約前去關心，並且完整地思考可能問題的解決方案(風險管理)，而是在專案開始之後，才被動地嘗試解決問題，但一切都為時已晚，同時也由於政府部門人員能力不足，沒有辦法事先看清楚這些問題，並做好預先的規劃，因此造成需求不斷變更、專案延遲、甚至於案子驗收不了，最後會由誰來承擔責任與後果？承辦人要承擔嗎？當然不會，因為承辦人有問題，就表示主官、管有問題(沒有盡到監督與管制之責)，所以最好的方式，不是粉飾太平(對stakeholders 撒個天大的謊話，說一切符合要求，甚至宣傳為主官的政績)，就是迫使廠商去全盤接受所有的問題(這還是有風險的，因為不知道廠商會如何反撲)。當然，迫使廠商接受所有的問題是相當的不公平的，因為「公務人員的薪水來自於政府總預算，總預算來自於稅收，稅收來自於廠商所創造的價值」，而擔任公務人員者，透過政府部門拿到了薪資(廠商經由稅收，提供給政府部門公務人員)，卻沒有做到 身為國家一份子之廠商 透過立法部門立法，期望該等公務人員應該盡好的本務，在造成問題後，卻仍要廠商賠錢去承受所有的政府部門在缺乏規劃與管理能力下所造成的惡果。這樣的惡性循環下，所產生的問題會是：廠商無法繼續經營下去，因此，政府稅收短缺，無法承擔更多的公務人員人事成本以及後續的退休給與，財政日益困難，於是人力不斷精減，但是，事情並沒有因此而減少，相對於人力的精減，每位公務人員所承擔的事情越來越多，責任越來越大，進而行政品質越來越低落，問題越來越多，公務人員越來越怕自己會出問題而領不到退休金，因此只好一味往廠商身上去推諉。

我們再拉回「笑話」的議題吧，「CMMI笑話」的問題，個人認為並不在於CMMI本身，也不認為有些要求沒有做到就是一種笑話，但那是一個悲哀。悲哀來自於政府部門人員的人力與能力不斷流失，以及相關人員的心態問題。個人認為，在政府部門也應該建立起一些文化，例如，對於問題溯及既往，不論該案完成的時間多久遠，在檢討出問題的原因後，要對有問題的人員追回因該案得到的獎勵或者陞遷，並且負起必要的法律責任，而不要因為時過境遷，以當時已經「安全下莊」，問題不是發生在該員任內，而輕易放過，如此，才不會讓主事者(原承辦人及其當時的決策主官、管)有僥倖的心態，只追求一時自利的表面績效。

另外有些看似笑話，但是從事情的過程與時序來看，其並不值得評論，因為有些事項從CMMI的架構下是可以裁適與豁免的。在談到CMMI時，應該要了解CMMI評鑑，要看的到底是什麼？CMMI要看的是制度的建立與執行。以可靠度需求這件事來說， CMMI評鑑不會去看單項需求有沒被實作出來，而是看相關的需求管理、需求發展、風險管理、品質保證、建構管理、專案監控與管制、DAR執行的狀況，進而找出組織能力提升與流程改善的方向。對於上述的「笑話」，其實所代表的是我們資訊業界的整體工程與管理能力的薄弱，屬於我們學校教育，應該加強的部分。這樣的哀悲，個人曾經也在大學或學院執教鞭者身上看到，明明資訊技術與工程為其主要的領域，卻對於這些工作上的知識與技術一無所知，當然就更不會教給從業人員了。

就個人的理解CMMI所提供的是一個品質管理(包括組織體質、組織基礎建設及組織流程)與改善的框架。像品質因子、工程管理、專案管理的知識與技術等，這些是不在CMMI框架裡的，CMMI框架只是提示要運用這些知識技術於工作上，這與每一個從業人員的本職學能有關，是要由組織基於自己能力經營與發展的考量，在人力資源上建立與培養這些知識技能的。

再找工作的時候不再找有CMMI評鑑的公司？這樣的說法，會不會太自暴自棄了？事實上，通過CMMI ML3評鑑的公司，如果願意遵循的話，會比完全沒有制度的公司要好很多，當然這也是需要我們最大的市場—政府部門，好好把能力提升起來，並對其他行業的資訊服務採購起帶頭作用。要不然，沒日沒夜的工作，永遠是資訊軟體業的夢靨。

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

有關 Terry 所提的“據說美國國防部的許多大型軟體購案，除了要求承包商 CMMI 評鑑資格外，還是會事前組成稽核小組去實訪廠商進行深入評估的”，以下是個人所知資訊：
1. 依據美國採購法PART 10 MARKET RESEARCH 一節，甲方可進行乙方之 On-site Evaluation，以了解乙方之能量，一般是在發RFP之前進行；
2. 美國國防部曾於 1999 年之 DOD 5000.2R 規範承約商資格為 :
甲、完全符合SEI SW-CMM Level-3，或等同（Equivalent）之評鑑模式，
乙、對於未滿足上述條件者可提出風險規避計畫(Risk Mitigation Plan for Deficiencies)，
丙、等同之評鑑模式須經核可。
但此等規定已於2006年刪除。
美國國防部的 Evaluation Model Best Practices 清單有 CMMI、ISO-9001、EIA-731、SDCE、J-STD-016、ISO/IEC-12207、BOOTSTRAP、Lean Aerospace、Six Sigma…，非僅限於 CMM 或 CMMI。

拜讀各位先進的「笑話」或高見後，似乎可以歸納為二類：

1.「期望太高，失望也大」－ 其實 CMMI 本身無罪，罪在導入者的心態不對，未認真落實執行，只是拿 CMMI 當「文憑」唬人。平心而論，這種現象也非僅台灣才有，印度與中國大陸也是很多的，就好像每年考上台大的人很多，但台大畢業生也不見得每個都很優秀，畢竟「文憑」只能參考，是否「名實相符」還是要實測才穩當。據說美國國防部的許多大型軟體購案，除了要求承包商 CMMI 評鑑資格外，還是會事前組成稽核小組去實訪廠商進行深入評估的 !

2.「魚目混珠，誤會一場」－ 3323052 所舉的案例，有可能是屬於上一類，但以我個人的經歷，也很有可能是：該公司其實只是拿某個「實驗部門」去通過 CMMI 評鑑，其他「作戰部門」根本沒碰過 CMMI ，但是該公司卻對外宣揚「本公司已通過 CMMI Level X 評鑑」，而資策會、軟協、甚至工業局為了宣揚其輔導績效，也都爭一眼閉一眼，大家只有到美國 SEI 的官方網站才能看到事實的真像 ( 連 SPIN Taiwan 的網站也不公佈 )，放任「魚目混珠」的結果，反而造成大家對 CMMI 的質疑，真是 CMMI 何辜啊 !

為響應alexyin的提議，我也來講一個CMMI的笑話

有一家ERP公司承接某政府財團法人單位的94年ERP建置案，應於95年6月30日結案，由於乙方作完需求訪談也不撰寫需求文件，到了今年2月開始進入Beta Test時，軟體與甲方預期差很多（但因為乙方不寫需求文件，所以乙方不認甲方曾提出需求的帳），乙方堅持不改，其理由是甲方應該知道乙方承接該案的價錢過低所以不可能完成甲方全部需求，且責怪甲方的流程與組織架構未配合乙方所使用的ERP COTS軟體（乙方僅寫界接程式或中介軟體(Middleware）)，由於6/30日未驗收就要罰款，所以乙方在6/29日確定甲方不肯驗收，只好修改軟體，且要甲方在6/30日中午前完成測試。該笑話是乙方在當時已導入CMMI Level-3近一年，上述之修改似乎是不須提Change request、不舉行CCB、不執行Regression Test即交付新版軟體給甲方，且將客戶測試當成軟體整合測試，交軟體也不須一併提供測試報告，堅持甲方如果測不出問題代表乙方軟體沒問題。