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，否則無助於整體採購品質之提昇。