A. CMM/CMMI是什麼
CMM是指「能力成熟度模型」，其英文全稱為Capability Maturity Model for Software，英文縮寫為SW-CMM，簡稱CMM。它是對於軟體組織在定義、實施、度量、控制和改善其軟體過程的實踐中各個發展階段的描述。CMM的核心是把軟體開發視為一個過程，並根據這一原則對軟體開發和維護進行過程監控和研究，以使其更加科學化、標准化、使企業能夠更好地實現商業目標。
CMMI認證是由美國軟體工程學會(software engineering institue,簡稱SEI)制定的一套專門針對軟體產品的質量管理和質量保證標准. CMMI 的全稱為：Capability Maturity Model Integration，即能力成熟度模型集成。
CMMI的五個台階（五個等級）： 台階一：CMMI一級，完成級。 在完成級水平上，企業對項目的目標與要做的努力很清晰，項目的目標得以實現。但是由於任務的完成帶有很大的偶然性，企業無法保證在實施同類項目的時候仍然能夠完成任務。企業在一級上的項目實施對實施人員有很大的依賴性。 台階二：CMMI二級，管理級。 在管理級水平上，企業在項目實施上能夠遵守既定的計劃與流程，有資源准備，權責到人，對相關的項目實施人員有相應的培訓，對整個流程有監測與控制，並與上級單位對項目與流程進行審查。企業在二級水平上體現了對項目的一系列的管理程序。這一系列的管理手段排除了企業在一級時完成任務的隨機性，保證了企業的所有項目實施都會得到成功。 台階三：CMMI三級，定義級。 在定義級水平上，企業不僅能夠對項目的實施有一整套的管理措施，並保障項目的完成；而且，企業能夠根據自身的特殊情況以及自己的標准流程，將這套管理體系與流程予以制度化這樣，企業不僅能夠在同類的項目上生到成功的實施，在不同類的項目上一樣能夠得到成功的實施。科學的管理成為企業的一種文化，企業的組織財富。 台階四：CMMI四級，量化管理級。 在量化管理級水平上，企業的項目管理不僅形成了一種制度，而且要實現數字化的管理。對管理流程要做到量化與數字化。通過量化技術來實現流程的穩定性，實現管理的精度，降低項目實施在質量上的波動。 台階五：CMMI五級，優化級。 在優化級水平上，企業的項目管理達到了最高的境界。企業不僅能夠通過信息手段與數字化手段來實現對項目的管理，而且能夠充分利用信息資料，對企業在項目實施的過程中可能出現的次品予以預防。能夠主動地改善流程，運用新技術，實現流程的優化。 由上述的五個台階我們可以看出，每一個台階都是上面一階台階的基石。要上高層台階必須首先踏上較低一層台階。企業在實施CMMI的時候，路要一步一步地走。一般地講，應該先從二級入手。在管理上下功夫。爭取最終實現CMMI的第五級。
B. 管理中的CMM是什麼意思
是一種對軟體組織在定義、實施、度量、控制和改善其軟體過程的實踐中各個發展階段的描述形成的標准。
CMM是由美國卡內基梅隆大學軟體工程研究所1987年研製成功的，是國際上最流行最實用的軟體生產過程標准和軟體企業成熟度等級認證標准。
其所依據的想法是：只要集中精力持續努力去建立有效的軟體工程過程的基礎結構，不斷進行管理的實踐和過程的改進，就可以克服軟體生產中的困難。
CMM已經得到了眾多國家以及國際軟體產業界的認可，成為當今企業從事規模軟體生產不可缺少的一項內容。
(2)CMM怎樣均勻自動取點擴展閱讀
CMM的基本思想是，因為問題是由管理軟體過程的方法引起的，所以新軟體技術的運用不會自動提高生產率和利潤率。CMM有助於組織建立一個有規律的、成熟的軟體過程。改進的過程將會生產出質量更好的軟體，使更多的軟體項目免受時間和費用的超支之苦。
軟體過程包括各種活動、技術和用來生產軟體的工具。因此，它實際上包括了軟體生產的技術方面和管理方面。CMM策略力圖改進軟體過程的管理，而在技術上的改進是其必然的結果。
C. PROE如何像三次元一樣取點
你說的是proe的cmm模塊吧，配合三座標測量使用的
proe模塊介紹推薦
http://hi..com/proe_creo/blog/item/98bcc110df6f9c0a962b435a.html
D. CMM的等級以及各等級的評價標准
CMM的具體級別劃分如下：第一級：初始級（The Initial Level）：初始級的軟體機構缺乏對軟體過程的有效管理，其軟體項目的成功來源於個人英雄主義而非機構行為，因此它不是可重復的。P.S. 初始級的軟體過程是未加定義的隨意過程，項目的執行是隨意甚至是混亂的。也許，有些企業制定了一些軟體工程規范，但若這些規范未能覆蓋基本的關鍵過程要求，且執行沒有政策、資源等方面的保證時，那麼它仍然被視為初始級。
在初始級，企業一般不具備穩定的軟體開發與維護的環境。常常在遇到問題的時候，就放棄原定的計劃而只專注於編程與測試。處於這一等級的企業，成功與否在很大程度上決定於有傑出的項目經理與經驗豐富的開發團隊。因此，能否雇請到及保有能乾的員工成了關鍵問題。項目成功與否非常不確定。雖然產品一般來說是可用的，但是往往有超經費與不能按期完成的問題。第二級：可重復級（The Repeatable Level）第二級軟體機構的主要特點是：項目計劃和跟蹤的穩定性，項目過程的可控性和以往成功的可重復性。更具體的說： 機構建立了管理軟體項目的策略和實現這些策略的過程。 新項目的計劃和管理基於類似項目的經驗。 過程能力的增強基於以各個項目為基礎的有紀律的基本過程管理。 不同的項目可有不同的過程，而對機構的要求是具有指導項目建立適當管理過程的策略。 每個項目都確定了基本的軟體管理控制，包括：基於前面項目的經驗和新項目特點，做出現實的項目承諾（如預算、交付期、軟體質量等）；軟體項目管理者要跟蹤開支、日程、軟體功能； 滿足承諾的過程中的出現的問題要及時發現，妥善解決； 定義了軟體項目標准，且機構確保其被遵守。本級的關鍵過程領域（KPA）包括： 需求管理（Requirements Management）——客戶的需求是軟體項目的基礎。軟體需求管理的目的是在客戶和軟體項目之間達成對客戶需求的一致理解。 軟體項目計劃（Software Project Planning） ——為軟體工程和項目管理建立一個合理的計劃。 軟體項目的跟蹤和監督（Software Project Tacking and Oversight） ——使管理者對實際的軟體項目進展過程有足夠的了解，以在項目效能偏離計劃太多是採取有效措施。 軟體子合同管理（Software Subcontract Management）——選擇合格的分包商，並有效管理之。 軟體質量保證（Software Quality Assurance） ——對軟體項目過程及其間生產的各個產品進行監管以保證最終軟體質量。 軟體配置管理（Software Configuration Management） ——在整個軟體生命周期里建立並維護軟體項目的工作產品的完整性。P.S.根據多年的經驗和教訓，人們總結出軟體開發的首要問題不是技術問題而是管理問題。因此，第二級的焦點集中在軟體管理過程上。一個可管理的過程則是一個可重復的過程，一個可重復的過程則能逐漸進化和成熟。第二級的管理過程包括了需求管理、項目管理、質量管理、配置管理和子合同管理五個方面。其中項目管理分為計劃過程和跟蹤與監控過程兩個過程，通過實施這些過程，從管理角度可以看到一個按計劃執行的且階段可控的軟體開發過程。
在這一級，建立了管理軟體項目的政策以及為貫徹執行這些政策而定的措施。基於過往的項目的經驗來計劃與管理新的項目。企業實行了基本的管理控制。符合實際的項目承諾是基於以往項目以及新項目的具體要求而作出的。項目經理不斷監視成本、進度和產品功能，及時發現及解決問題以便實現所作的各項承諾。
通過具體地實施這一級的各個關鍵過程領域的要求，企業實現了過程的規范化、穩定化。因而，曾經取得過的成功成為可重復達到的目標。 第三級：已定義級（The Defined Level） 第三級的主要特徵在於軟體過程已被提升成標准化過程，從而更加具有穩定性、可重復性和可控性。處於第三級的企業具有如下一些特徵：機構採用標準的軟體過程，軟體工程和管理活動被集成為一個有機的整體。標准化的目的是使之可使管理者和技術人員有效工作。 有一組人員專門負責機構的軟體過程，並且在機構中有培訓計劃來確保stuff和manager有知識和技能完成所賦予的角色。 標準的軟體過程結合項目的特點即形成定義的軟體過程，它包括一組集成的定義良好的軟體工程和管理過程。 一個定義良好的過程包括就緒准則、輸入、完成工作過程、驗證機制、輸出和完成准則。 在已建立的產品線上cost, schele, functionality 均可控制，軟體質量被加以跟蹤。 過程能力體現在在機構范圍內對一個定義的軟體過程活動、角色和責任的共同理解。 第三級主要處理以下的KPA： 機構過程關注（Organization Process Focus） ——機構對於改進機構的軟體過程能力的軟體過程活動的責任。 機構過程定義（Organization Process Definition） ——維護一組有用的軟體過程assets和提供一個用於定義定量過程管理的有意義的數據的基礎 培訓計劃（Training Program）——個體的技能和知識以使他們能夠更加有效的完成他們的角色 集成軟體管理（Integrated Software Management） ——業務環境和項目的技術需要，從機構的標准軟體過程和相關的過程assets經過剪裁，將軟體工程和管理活動集成為一個有機的定義的軟體過程。 軟體產品工程（Software Proct Engineering） ——地完成定義良好的工程過程。它描述了項目的技術活動，如需求分析，設計，編碼和測試。 組間協調（Intergroup Coordination） ——軟體工程組主動介入其它工程組以便項目能更好滿足客戶要求的手段 同行評審（Peer Reviews） ——且有效的排除軟體工作產品中的缺陷。它可通過inspection,structured walkthrough等手段進行。 P.S.在第二級僅定義了管理的基本過程，而沒有定義執行的步驟標准。在第三級則要求制定企業范圍的工程化標准，而且無論是管理還是工程開發都需要一套文檔化的標准，並將這些標准集成到企業軟體開發標准過程中去。所有開發的項目需根據這個標准過程，剪裁出與項目適宜的過程，並執行這些過程。過程的剪裁不是隨意的，在使用前需經過企業有關人員的批准。
在這一級，有關軟體工程與管理工程的一個特定的、面對整個企業的軟體開發與維護的過程的文件將被制訂出來。同時，這些過程是集成到一個協調的整體。這就稱為企業的標准軟體過程。
這些標準的過程是用於幫助管理人員與一般成員工作得更有效率。如果有適當的需要，也可以加以修改。在這個把過程標准化的努力當中，企業開發出有效的軟體工程的各種實踐活動。同時，一個在整個企業內施行的培訓方案將確保工作人員與管理人員都具備他們所需要的知識與技能。非常重要的一點是，項目小組要根據該項目的特點去改編企業的標准軟體過程來制訂出為本項目而定義的過程。
一個定義得很清楚的過程應當包括：准備妥當的判據，輸入，完成工作的標准和步驟，審核的方法，輸出和完成的判據。因為過程被定義得很清楚，因此管理層就能對所有項目的技術過程有透徹的了解。第四級：已管理級（The Managed Level） 第四級的軟體機構中軟體過程和軟體產品都有定量的目標，並被定量地管理，因而其軟體過程能力是可預測的，其生產的軟體產品是高質量的。具體地說，第四季的機構具有如下特徵：軟體過程和產品有定量質量目標。 重要的軟體過程活動均配有生產率和質量度量； 資料庫被用來收集和分析定義軟體過程的數據； 項目的軟體過程和質量的評價有定量的基礎； 項目的產品和過程式控制制具有可預測性。 縮小過程效能落在可接受的定量界限內的偏差； 可區分過程效能的有效偏差和隨機偏差； 面向新領域的風險是可知並被仔細管理； 本級的關鍵過程領域包括： 定量過程管理（Quantitative Process Management） ——地控制軟體項目的過程效能。 軟體質量管理（Software Quality Management） ——定量了解項目軟體產品的質量，並達到既定的質量目標。P.S.第四級的管理是量化的管理。所有過程需建立相應的度量方式，所有產品的質量(包括工作產品和提交給用戶的產品)需有明確的度量指標。這些度量應是詳盡的，且可用於理解和控制軟體過程和產品。量化控制將使軟體開發真正變成為一種工業生產活動。
在這一級，企業對產品與過程建立起定量的質量目標，同時在過程中加入規定得很清楚的連續的度量。作為企業的度量方案，要對所有項目的重要的過程活動進行生產率和質量的度量。軟體產品因此具有可預期的高質量。
一個企業范圍的資料庫被用於收集與分析來自各項目的過程的數據。這些度量建立起了一個評價項目的過程與產品的定量的依據。項目小組可以通過縮小他們的效能表現的偏差使之處於可接受的定量界限之內，從而達到對過程與產品進行控制的目的。
因為過程是穩定的和經過度量，所以在有意外情況發生時，企業能夠很快辨別出特殊的原因並加以處理。第五級：The Optimizing Level 概括來說，第五級的主要特點是技術和過程改進被作為常規的業務活動加以計劃和管理。處於第五級的企業具有如下一些特徵： 機構集中於連續的過程改進 具有標識弱點和增強過程的手段。 採用過程數據分析使用新技術的代價效益並提出改進。 項目隊伍能夠分析出錯原因並防止其再次出現。 防止浪費是第五級的重點。 改進的途徑在於已有過程的增量改進和使用新技術和新方法的革新構成 ：陷預防（Defect Prevention） ——出錯原因，防止錯誤再現(通過改變定義的軟體過程) 技術變更管理（Technology Change Management） ——有益的新技術(工具、方法和過程)，並按有序的方式將其轉移至機構之中。其重點在於在變化的世界中有效的完成革新。 過程變更管理（Process Change Management）——改進機構所採用的軟體過程，以改進軟體質量，提高生產率和減少產品開發時間。
概括來說，第五級企業的重點是連續的過程改進。 P.S.第五級的目標是達到一個持續改進的境界。所謂持續改進是指可根據過程執行的反饋信息來改善下一步的執行過程，即優化執行步驟。如果一個企業達到了這一級，那麼表明該企業能夠根據實際的項目性質、技術等因素，不斷調整軟體生產過程以求達到最佳。
在這一級，整個企業將會把重點放在對過程進行不斷的優化。企業會採取主動去找出過程的弱點與長處，以達到預防缺陷的目標。同時，分析有關過程的有效性的資料，作出對新技術的成本與收益的分析，以及提出對過程進行修改的建議。整個企業都致力於探索最佳軟體工程實踐的創新。
項目組分析引起缺陷的原因，對過程進行評鑒與改進，以便預防已發生的缺陷再度發生。同時，也把從中學到的經驗教訓傳授給其他項目。降低浪費與消耗也是這個等級的一個重點。
處於這一等級的企業的軟體過程能力可被歸納為不斷的改進與優化。它們以兩種形式進行。一種是逐漸地提升現存過程，另一種是對技術與方法的創新。雖然在其他的能力成熟度等級之中，這些活動也可能發生，但是在優化級，技術與過程的改進是作為常規的工作一樣，有計劃地在管理之下實行的。縱觀整個CMM，軟體企業提高自身成熟度的歷程是一個從無序到有序，從特殊到一般，從定性到定量，最後不斷自我完善的過程。CMM與績效提高從提高績效的角度分析，企業實施CMM後將受益匪淺。企業實施CMM，可從如下幾個步驟進行：1、提高思想認識，了解必要性和迫切性；2、確定合理的目標；3、進行CMM培訓和咨詢工作；4、成立工作組；5、制定和完善軟體過程；6、內部評審；7、初期評估；8、正式評估；9、根據評估的結果改進軟體過程。CMM 為了評價當前的水平，找出問題所在，指導如何改進和了解軟體承包商的軟體能力。目前針對CMM開發出許多的評估方法，其中公認評估方法有兩個：一是用於內部過程改進的CMM評估稱為CBA-IPI；二是用於選擇和監控分承包方的CMM評估，稱為SCE方法。這兩種方法基於不同的目的，但評估的結果應一致。評估包括三個階段：准備階段、現場階段和報告階段。可以預言：組織對軟體開發過程及其有效性的控制在上述五個等級的規范和要求下肯定能得到提高。
E. 關於CMM的問題
什麼是CMM
日前，國務院發布的《鼓勵軟體產業和集成電路產業發展的若干政策》中第17條中表示，將對軟體出口型企業CMM認證費用予以適當支持，那麼CMM是什麼呢？ CMM是能力成熟度模型（capabilityMaturityModel）的縮寫，是一種用於評價軟體承包能力並幫助其改善軟體質量的方法，側重於軟體開發過程的管理及工程能力的提高與評估。CMM分為五個等級：一級為初始級，二級為可重復級，三級為已定義級，四級為已管理級，五級為優化級。 CMM是由美國卡內基梅隆大學軟體工程研究所1987年研製成功的，是目前國際上最流行最實用的軟體生產過程標准和軟體企業成熟度等級認證標准。目前，我國已有軟體企業通過了CMM標准認證。
********************************************
CMM是軟體過程能力成熟度模型（Capacity Maturity Model）
不過這東西被上一期csdn雜志上一篇文章鄙視過。
CMM簡介
CMM是軟體過程能力成熟度模型（Capacity Maturity Model）的簡稱，是卡內基－梅隆大學軟體工程研究院為了滿足美國聯邦政府評估軟體供應 商能力的要求，於1986年開始研究的模型，並於1991年正式推出了CMM 1.0 版。CMM自問世以來備受關注，在一些發達國家和地區得到了廣泛應用，成為衡量軟體公司軟體開發管理水平的重要參考因素和軟體過程改進事實上的工業標准。據了解，美國、印度、日本等國家已有數十家公司通過了CMM不同等級的認證。
1986年11月，SEI應美國聯邦政府的要求，在Mitre公司的協助下，於1987年9月開發了一套軟體能力成熟度框架和一套軟體成熟度問卷，用來評估軟體供應商的能力。這就是最早用於探索軟體過程成熟度的一個工具。
四年以後，也就是1991年，SEI自己總結了CMM成熟度框架和初版成熟度問卷的實踐經驗，並以此為基礎推出民用CMM1.0版。
CMM1.0版合用兩年之後，1992年4月，SEI舉行了CMM一個的研討會，參加研討會的有大約200名富有經驗的軟體專家。SEI在廣泛聽取他們的意見之後，又於1993年推出 CMM1.1版。這也是目前世界上比較流行和通用的CMM版本。
十幾年來，此項工作一直在不斷進行。按照SEI原來的計劃，CMM的改進版本2.0應該在1997年11月完成，然後在取得版本2.0得實踐反饋意見之後，在1999年完成准CMM2.0版本。但是，美國國防部辦公室要求SEI推遲發布CMM2.0版本，而要先完成一個更為緊迫得項目CMMI。
CMMI（Capability Maturity Model Integration）即能力成熟度模型集成，這也是美國國防部的一個設想，他們想把現在所有的以及將被發展出來的各種能力成熟度模型，集成到一個框架中去。這個框架有兩個功能，第一，軟體獲取方法的改革；第二，建立一種從集成產品與過程發展的角度出發、包含健全的系統開發原則的過程改進。
隨著人們對CMM研究的不斷深入，其他學科也結合本系統的特點，陸續推出了自己的CMM模型。例如，人力資源能力成熟度模型、系統工程能力成熟度模型等等。為了以示區別，國內外很多資料把CMM叫做SW-CMM。
軟體過程成熟度的提高是一個漸進的過程，需要一個長遠的、可持續發展的過程作為保證。為建立一個面向過程持續提高的基礎和文化，有些軟體企業可能要花費很大的精力和時間。但是這種努力對任何一個軟體企業來說都是非常必要的。
CMM目前代表著軟體發展的一種思路，一種提高軟體過程能力的途徑。盡管它存在著某些不足。例如，成熟級別、關鍵過程域、公共屬性和關鍵實踐還需要在軟體行業進一步深入地討論和修訂，但它確實為軟體行業的發展提供了一個良好的框架，而且是濃度軟體過程能力提高的有用工具。
增強我國軟體企業的競爭力，提高國產軟體的水平是國人的共同願望，但目前我國軟體水平，尤其是軟體開發能力和軟體生產能力還很差，這也是不爭的事實。那麼，如何提高我國軟體的開發和生產能力，從而提高軟體整體水平？軟體企業實施CMM也許不失為一條有效的途徑。
一個企業的軟體能力更取決於該企業的過程能力，特別是在軟體開發和生產中的成熟度。其過程能力越是成熟，該企業的軟體生產能力 就越有保證。目前，我國已有一些軟體企業正在嘗試實施CMM。
當然，CMM不是萬能的，並不一定對所有的軟體企業都適合，實施CMM的企業也有失敗的例子。我們希望通過本專欄能使更多的企業了解CMM，盡快找到適合本企業的發展之路，從而提高中國軟體企業的競爭力。
**********************************************
畫一個圖吧：（CMM的五層結構圖）
-----------------
/ 優 化 級 /
/ (5) /
-----------------
↑
| 不斷改進的過程
|
-----------------
/ 可 管 理 級 /
/ (4) /
-----------------
↑
| 能預見的過程
|
-----------------
/ 確 定 級 /
/ (3) /
-----------------
↑
| 標准一致的過程
|
-----------------
/ 可 重 復 級 /
/ (2) /
-----------------
↑
| 有紀律的過程
|
-----------------
/ 初 始 級 /
/ (1) /
-----------------
*********************************************
CMM即Capability Maturity Model,中文翻譯為能力成熟度模型", 是軟體工程研究的一個重要里程碑。CMM的研究始於1986年11月，當時為了滿足美國聯邦政府評估軟體供應商能力的要求，美國卡內基·梅隆大學的軟體工程研究院(SEI)牽頭，在Mitre公司的協助下，用不到一年的時間，於1987年9月發布了一份能力成熟度框架(Capability Maturity Framework),以及一套成熟度問卷(Maturity Questionnaire).
很多人認為這套問卷就代表了CMM模型，其實它只是用於探索軟體過程成熟度的一個工具，真正的模型出現在四年以後。SEI總結了自1987年以來對成熟度框架和初版成熟度問卷的實戰經驗，並以此為基礎，推出了CMM1.0版。這個推出於1991年的CMM1.0 集中了四年來對軟體公司評估的經驗以及廣泛的用戶反饋，在成熟度框架的基礎上建立了一個可用的模型，這個模型可以更加有效地幫助軟體企業建立和實施過程改進計劃。
CMM1.0版使用兩年之後，於1992年四月進行了一個研討會，參加研討會的有約兩百名富有經驗的軟體專業人員。在廣泛聽取了他們的反饋意見之後，SEI於1993年推出了CMM1.1版。近幾年來，CMM又推出了2.0版本，同時進入了ISO體系，稱為ISO/IEC15504或SPICE. SPICE從1995年起進入實地測試階段，可能於2001年發布。
CMM致力於軟體開發過程的管理及工程能力的提高與評估。該模型在美國和北美地區已得到廣泛應用同時正在被越來越多的歐洲和亞洲等國家的大型信息技術企業所採納，實際上已成為軟體開發過程改進與評估的事實上的工業標准。
CMM將軟體過程的成熟度分為5個等級,以下是5個等級的軟體機構的特徵：
（1）初始級(initial) 工作無序，項目進行過程中常放棄當初的計劃。管理無章，缺乏健全的管理制度。開發項目成效不穩定，優秀管理人員的管理方法可能取得有效，但他一離去，工作秩序面目全非，產品的性能和質量依賴於個人能力和行為。
（2）可重復級(Repeatable) 管理制度化，建立了基本的管理制度和規程，管理工作有章可循。 初步實現標准化，開發工作較好地實施標准。 變更依法進行，做到基線化。穩定可跟蹤，新項目的計劃和管理基於過去的實踐經驗，具有重復以前成功項目的環境和條件。
（3）已定義級(Defined) 開發過程，包括技術工作和管理工作，均已實現標准化、文檔化。 建立了完善的培訓制度和專家評審制度 全部技術活動和管理活動均可控制 對項目進行中的過程、崗位和職責均有共同的理解 。
（4）已管理級(Managed) 產品和過程已建立了定量的質量目標。過程中活動的生產率和質量是可量度的。已建立過程資料庫。已實現項目產品和過程的控制。可預測過程和產品質量趨勢，如預測偏差，實現及時糾正。
（5）優化級(Optimizing) 可集中精力改進過程，採用新技術、新方法。擁有防止出現缺陷、識別薄弱環節以及加以改進的手段。可取得過程有效性的統計數據，並可據進行分析，從而得出最佳方法。
軟體大國印度，十分重視軟體開發過程的管理及與其相關的理論與標準的發展。據統計，在印度的2000多家軟體公司中有75家軟體公司通過了ISO9000認證， 60多家軟體公司通過了CMM認證，其中達到CMM5級一家，4級三家，3級4家。
CMM與ISO9000的區別主要有以下幾點：
1.CMM是專門針對軟體產品開發及服務的，而ISO9000則有寬得多的范圍。
2.CMM強調軟體開發過程的成熟度，即過程的不斷改進和提高，而ISO9000則僅描述可接收的質量體系的最低標准。
3.CMM3級的覆蓋范圍要大於ISO9000的覆蓋范圍
引進CMM的意義：
1. 對軟體企業：
提高軟體開發的管理能力：CMM提供了軟體企業自我評估的方法和自我提高的手段
提高軟體生產率
加強軟體生產的國際競爭力
2. 對軟體項目發包單位和軟體用戶：
提供了對軟體開發商開發管理水平的評估手段，有助於軟體開發項目的風險識別。
***********************************************
隨著人們對CMM研究的不斷深入，其他學科也結合本系統的特點，陸續推出了自己的CMM模型。例如，人力資源能力成熟度模型、系統工程能力成熟度模型等等：
（1） SW-CMM (Software CMM) 軟體CMM
（2） SE-CMM (System Engineering CMM) 系統工程CMM
（3） SA-CMM (Software Acquisition CMM) 軟體采購CMM
（4） IPT-CMM (Integrated Proct Team CMM) 集成產品群組CMM
（5） P-CMM (People CMM) 人力資源能力成熟度模型
為了以示區別，國內外很多資料把CMM叫做SW-CMM。按照SEI原來的計劃，CMM的改進版本2.0應該在1997年11月完成，然後在取得版本2.0得實踐反饋意見之後，在1999年完成准CMM2.0版本。但是，美國國防部辦公室要求SEI推遲發布CMM2.0版本，而要先完成一個更為緊迫的項目CMMI。
CMMI（Capability Maturity Model Integration）即能力成熟度集成模型，這也是美國國防部的一個設想，他們想把現在所有的以及將被發展出來的各種能力成熟度模型，集成到一個框架中去。這個框架有兩個功能，第一，軟體采購方法的改革；第二，建立一種從集成產品與過程發展的角度出發、包含健全的系統開發原則的過程改進。就軟體而言，CMMI是SW-CMM的修訂本。它兼收了SW-CMM 2.0版C稿草案和SPA中更合理、更科學和更周密的優點。SEI在發表CMMI-SE/SW 1.0版時，宣布大約用兩年的時間完成從CMM到CMMI的過渡。
CMMI項目更為工業界和政府部門提供了一個集成的產品集，其主要目的是消除不同模型之間的不一致和重復，降低基於模型改善的成本。CMMI將以更加系統和一致的框架來指導組織改善軟體過程，提高產品和服務的開發、獲取和維護能力
*********************************************
CMM的發展過程
1984年美國國防部為降低采購風險，委託卡耐基—梅隆大學軟體工程研究院（SEI）制定了軟體過程改進、評估模型，也稱為SEI SW-CMM。該模型於1991年正式推出，迅速得到廣大軟體企業及其顧客的認可。從1987年SEI推出SW－CMM框架開始，1991年推出 CMM 1.0 版，1993年推出CMM 1.1 版，2000年推出CMMI-SE/SW 1.0版。我國也於2001年4月發布了《SJ/T 11234-2001 軟體過程能力評估模型》和《SJ/T 11235-2001 軟體能力成熟度模型》兩個標准。我國政府一直重視軟體產業的規范和發展，國務院於2000年6月頒發的「18號文件」第五章第十七條明確提出鼓勵軟體出口型企業通過ISO9000系列質量保證體系認證和CMM認證，其認證費用通過中央外貿發展基金適當予以支持。目前各省市、高新區、軟體園都有對通過CMM的企業給予資金獎勵的制度。
**********************************************
CMM的含義與作用
CMM是Capability Maturity Model for Software的簡稱，中文叫「軟體能力成熟度模型」，是對組織軟體過程能力的描述。CMM的核心是把軟體開發視為一個過程，並根據這一原則對軟體開發和維護進行過程監控和研究，以使其更加科學化、標准化，使企業能夠更好的實現商業目標。它側重於軟體過程開發的管理及軟體工程能力的改進與評估，因此CMM被用作評價軟體承包商能力並幫助組織改善軟體過程質量，是目前國際上最流行、最實用的一種軟體過程改進模型，成為當今企業從事規模軟體生產不可缺少的一項內容。CMM的目的是幫助軟體企業對軟體工程過程進行管理和改進，增強開發與改進能力，從而能按時地、不超預算地開發出高質量的軟體。企業實施CMM模型並評估可為企業帶來如下好處：指導軟體組織提高軟體開發管理能力；降低軟體承包商和采購者的風險；評估軟體承包商的軟體開發管理能力；幫助軟體企業識別開發和維護軟體的有效過程和關鍵實踐；幫助軟體企業識別為達到CMM更高成熟等級所必須的關鍵實踐；增加軟體企業的國際競爭能力。
**********************************************
什麼是CMM的核心？這是長期在有志於軟體工程與過程改進的人中存在的一個問題。本人在一次CMM培訓中准備了一個案例，希望能夠生動而淺顯地解釋這個問題，在此與大家共享，也希望大家能提出更多問題。如要轉載，請順手給我發個Email:[email protected]，非常感謝。案例背景：有一間房子，裡面有一些人，一些杯子和水壺，以及用於燒水的用具，所有的人都需要喝開水。CMM 1級：過程：找到杯子和水壺倒水喝問題：找不到杯子，沒水喝找不到水壺，沒水喝水壺沒水——不知道該怎麼辦一天要喝多少水——不知道倒一杯水要花多少時間，每個人每天為倒水花多少時間——不知道思考：買個飲水機能解決問題嗎？CMM 2級：過程：杯子放在茶幾上水壺放在餐台上如果水壺沒水，在廚房燒水杯子用完要清洗，並放回茶幾培訓：廚房燒水，清洗杯子度量一天要燒幾壺水，每個人每次/每天倒水要花多少時間有人檢查是否所有人用完杯子後都清洗並放回餐台管理者關注這些活動的執行狀態與成效問題：燒水太花時間水要等涼了才能喝效率不穩定：有人每天花20分鍾倒水，有人每天花80分鍾思考：買個飲水機能有幫助嗎？CMM 3級：過程：所有人都先在茶幾取杯子，再去餐台倒水統一用大杯子每人每次倒兩杯水，與人分享指派專人定時燒水，放在涼水壺里指派專人定時收集和清洗杯子問題：怎樣才能做得更好？思考：買個飲水機劃算嗎？CMM 4級：過程：建立評價模型：節省1分鍾=節省1元錢，如果每人每天節省1分鍾，則100個人1個月（30天）可以節省3000元——只要每月花費不超過3000元，我們就可以嘗試新過程定義量化的管理目標：3個月內將每人每天用於倒水的時間減少2分鍾以現在每人每天用於倒水的時間建立基線：平均10分鍾，最少5分鍾，最多20分鍾每個人為自己制定優於平均值的目標：本人每天用於倒水的時間不超過6分鍾度量並監控每天用於倒水的時間，一旦超過6分鍾，要分析根本原因，並制定調整措施；最後結果是8分鍾，超出預定的目標，但比平均值要好3個月後調整基線：平均8分鍾，最低4分鍾，最高15分鍾問題：不改進不行了！思考：買個飲水機是最好的方案嗎？CMM 5級：過程：發現問題的根本原因：倒水的時間之所以不能再少，是因為房間太大，走到餐台太遠找出能夠解決根本原因的所有方法，用評價模型進行評價選擇一種方法，並制定改進的目標：買10個飲水機放在客廳里，每人每天節省2分鍾制定相應的過程：如果買飲水機，則需要定期定購桶裝水，定期對飲水機出水口進行清洗和消毒，請人及時更換空水桶試行過程：先找幾個人試用，看看是否能達到預期目標推廣：讓所有人都用飲水機繼續發現其它的根本原因……問題：怎樣發現更多根本原因怎樣引進更多新方法思考：還有什麼比飲水機更好的方法嗎？
比喻二：
一級：一群人沒有經過訓練，也不知道有沒有經驗，下水之後亂撲騰，有的人浮起來，有的人沉下去了。這就是一級的無序狀態，結果是不可知的二級：大家都在游泳池或者小池塘里下過幾次水，基本上在這樣的條件下不會出事了。但是動作亂七八糟，有狗刨有說不出名字的動作。也就是二級的能夠重復以前的成功經驗三級：經過研究，確定了幾種標准泳姿，知道自由泳最快，蛙泳最省力等等。這就是三級，有了標準的過程定義四級：大家都掌握標准動作之後，互相之間的成績就可以比較了。通過測量大家的游泳成績（當然不同泳姿的成績要分開）、肌肉力量等等，分析特別好的和特別差的，找出好的原因和差的原因，大家的技術水平不斷提高。這就是四級的量化控制，通過數據來管理和改進五級：大家的技術水平都很高了，動作都很完美。我們就通過創造新的泳姿，引入新式游泳衣等等創新來提高成績。這就是五級的持續改進
**********************************************
CMM的結構
SW-CMM為軟體企業的過程能力提供了一個階梯式的進化框架，階梯共有五級。第一級實際上是一個起點，任何准備按CMM質進化的企業一般都處於這個起點上，並通過這個起點向第二級邁進。除第一級外，每一級都設定了一組目標，如果達到了這組目標，則表明達到了這個成熟級別，可以向下一個級別邁進。CMM系不主張跨越級別的進化，因為從第二級起，每一個低的級別實現均是高的級別實現的基礎。
SW-CMM提供階梯式的進化框架
1.初始級 初始級的軟體過程是未加定義的隨意過程，項目的執行是隨意甚至是混亂的。也許，有些企業制定了一些軟體工程規范，但若這些規范未能覆蓋基本的關鍵過程要求，且執行沒有政策、資源等方面的保證時，那麼它仍然被視為初始級。
2.可重級 根據多年的經驗和教訓，人們總結出軟體開發的首要問題不是技術問題而是管理問題。因此，第二級的焦點集中在軟體管理過程上。一個可管理的過程則是一個可重級的過程，一個可重級的過程則能逐漸進化和成熟。第二級的管理過程包括了需求管理、項目管理、質量管理、配置管理和子合同管理五個方面。其中項目管理分為計劃過程和跟蹤監控過程兩個過程。通過實施這些過程，從管理角度可以看到一個按計劃執行的且階段可控的軟體開發過程。
3.定義級 在第二級僅定義了管理的基本過程，而沒有定義執行的步驟標准。在第三級則要求制定企業范圍的工程化標准，而且無論是管理還是工程開發都需要一套文檔化的標准，並將這些標准集成到企業軟體開發標准過程中去。所有開發的項目需根據這個標准過程，剪裁出該項目的過程，並執行這些過程。過程的剪裁不是隨意的，在使用前需經過企業有關人員的批准。
4.管理級 第四級的管理是量化的管理。所有過程需建立相應的度量方式，所有產品的質量(包括工作產品和提交給用戶的產品)需有明確的度量指標。這些度量應是詳盡的，且可用於理解和控制軟體過程和產品，量化控制將使軟體開發真正變成為工業生產活動。
5.優化級 第五級的目標是達到一個持續改善的境界。所謂持續改善是指可根據過程執行的反饋信息來改善下一步的執行過程，即優化執行步驟。如果一個企業達到了這一級，那麼表明該企業能夠根據實際的項目性質、技術等因素，不斷調整軟體生產過程以求達到最佳。
從效果而言，在上述不同階段，軟體開發生產的成熟程度給軟體企業帶來了完全不同的效果。第一階段到第五個階段，軟體開發生產的計劃精度越來越高，每單位工程的生產周期越來越短，每單位工程的成本越來越低。
關鍵過程域(KPA)
除第一級外，SW-CMM的每一級是按完全相同的結構成的。每一級包含了實現這一級目標的若干關鍵過程域(KPA)，每個KPA進一步包含若干關鍵實施活動(KP)，無論哪個KPA，它們的實施活動都統一按五個公共屬性進行組織，即每一個KPA都包含五類KP。
1.目標 每一個KPA都確定了一組目標，若這組目標在每一個項目都能實現，則說明企業滿足了該KPA的要求。若滿足了一個級別的所有KPA要求，則表明達到了這個級別所要求的能力。
2.實施保證 實施保證是企業為了建立和實施相應KPA所必須採取的活動，這些活動主要包括制定企業范圍的政策和高層管理的責任。
3.實施能力 實施能力是企業實施KPA的前提條件。企業必須採取措施，在滿足了這些條件後，才有可能執行KPA的執行活動。實施能力一般包括資源保證、人員培訓等內容。
4.執行活動 執行過程描述了執行KPA所需求的必要角色和步驟。在五個公共屬性中，執行活動是唯一項目執行相關的屬性，其餘四個屬性則涉及企業CMM能力基礎設施的建立。執行活動一般包括計劃、執行的任務、任務執行的跟蹤等。
5.度量分析 度量分析描述了過程的度量和度量分析要求。典型的度量和度量分析的要求是確定執行活動的狀態和執行活動的有效性。
6.實施驗證 實施驗證是驗證執行活動是否與建立的過程一致。實施驗證涉及到管理的評審和審計以及質量保證活動。
在實施CMM時，可以根據企業軟體過程存在問題的不同程度確定實現KPA的次序，然後按所確定次序逐步建立、實施相應過程。在執行某一個KPA時，對其目標組也可採用逐步滿足的方式。過程進化和逐步走向成熟是CMM體系的宗旨。
F. cmm三坐標測量最大實體原則和最小實體原則怎麼理解
A --主基準 限定了3個自由度， 這是最大的面，需要首先保證。一般檢具上就是做個很平的面，如果A面有限定3個定面點的位置的話，就取其三點用pin 做出，鑲好。
B---次基準 限定了2個自由度，這里是指中心孔，不但指圓，還有柱面上的所有要素（說白了，就是也要考慮其垂直度等），檢具上就是用一個等高或少高些的圓柱，圓柱的直徑，如果是基準的最大實體原則的話，就作到中間孔的最小值左右，考慮到垂直度這里可以取：
C--第三基準，限定最後一個自由度，即其轉動。此基準為輔助，圖上用了一個孔，如果也是最大實體的話，也用一個小的post限位。
A, B,C 定下來後，被測要素（羅紋孔）就應該在理想位置限定的兩圓柱面之間。這時候檢具就有幾種做法：
1。有3次元的話，用一專用羅紋規（外部是光面圓的）旋入，打點找到中心，與理論中心對比。（理論中心由檢具或直接打被測零件得到）。
2。直接用規，用一柱子，直徑取羅紋內徑的最大實體狀態值-位置度規格值。
3。用中心儀或高度尺轉換測
G. CMMI和CMM的關系
CMM和CMMI的聯系及區別:
聯系:
CMMI即CMM集成，是系統工程和軟體工程的集成成熟度模型，CMMI更適合於信息系統集成企業。CMMI是在CMM基礎上發展起來的，它繼承並發揚了CMM的優良特性，借鑒了其他模型的優點，融入了新的理論和實際研究成果。它不僅能夠應用在軟體工程領域，而且可以用於系統工程及其他工程領域。
區別:
從等級劃分上看,1,3,5級的名稱沒有變化,均是初始級,已定義和優化;但是2級和4級分別定義為已管理級和定量管理級,這個變化更突出了CMMI定性管理和定量管理的特點.
CMMI共有分屬於4個類別的25個過程哉,覆蓋了4個不同的領域;相對應的CMM共有18個過程域.
CMM基本活動的度量方法和瀑布過程的有次序的,基本活動的管理規范有非常密切的聯系,更適合瀑布型的開發過程;而CMMI相對CMM更一步支持迭代開發過程和經濟動機推動組織採用基於結果的方法:開發業務安全,構想和原型方案,細化後納入基線結構,可用發布,最後確定為現場版本的發布.
CMMI比CMM進一步強化了對需求的重視.在CMM中,關於需求只有需求管理這一個KPA,也就是說強調對有質量的需求進行管理,而如何獲取需求則沒有提出明確的要求;在CMMI中,3級有一個獨立的KPA叫做需求開發,提出了對如何獲取優秀的需求的要求和方法.
CMMI對工程活動進行了一定的強化.在CMM中只有3級中的軟體產品工程和同行評審兩個KPA是與工程過程密切相關的;而在CMMI中,則將需求開發,驗證,確認,技術解決方案產品集成這些工程過程活動都作為單獨的KPA進行了要.
CMMI3級中單獨強調了風險管理,而在CMM中把風險的管理分散在項目計劃,項目跟蹤與監控中進行要求.
從評估方法上看,隨著CMM過渡到CMMI,其CAF(CMM,Assessment Frame-work)框架變成評估需求(ARC:appraisal requirements for CMMI);IPI-CBA 的評估方法 被 SCAMPI方法替代.
H. 軟體測試行業的CMM是指什麼
軟體測試行業的CMM指的是「能力成熟度模型」。
其英文全稱為Capability Maturity Model for Software，英文縮寫為SW-CMM，簡稱CMM。
它是對於軟體組織在定義、實施、度量、控制和改善其軟體過程的實踐中各個發展階段的描述。CMM的核心是把軟體開發視為一個過程，並根據這一原則對軟體開發和維護進行過程監控和研究，以使其更加科學化、標准化、使企業能夠更好地實現商業目標。
(8)CMM怎樣均勻自動取點擴展閱讀
MM/CMMI將軟體過程的成熟度分為5個等級,以下是5個等級的基本特徵：
(1)初始級(initial)。工作無序，項目進行過程中常放棄當初的計劃。管理無章法，缺乏健全的管理制度。開發項目成效不穩定，項目成功主要依靠項目負責人的經驗和能力，他一但離去，工作秩序面目全非。
(2)可重復級(Repeatable)。管理制度化，建立了基本的管理制度和規程，管理工作有章可循。 初步實現標准化，開發工作比較好地按標准實施。 變更依法進行，做到基線化，穩定可跟蹤，新項目的計劃和管理基於過去的實踐經驗，具有重復以前成功項目的環境和條件。
(3)已定義級(Defined)。開發過程，包括技術工作和管理工作，均已實現標准化、文檔化。建立了完善的培訓制度和專家評審制度，全部技術活動和管理活動均可控制，對項目進行中的過程、崗位和職責均有共同的理解 。
(4)已管理級(Managed)。產品和過程已建立了定量的質量目標。開發活動中的生產率和質量是可量度的。已建立過程資料庫。已實現項目產品和過程的控制。可預測過程和產品質量趨勢，如預測偏差，實現及時糾正。
(5)優化級(Optimizing)。可集中精力改進過程，採用新技術、新方法。擁有防止出現缺陷、識別薄弱環節以及加以改進的手段。可取得過程有效性的統計數據，並可據進行分析，從而得出最佳方法。
I. 在測量面與面的平行度公差的時候，如果被測面平面度很差，這樣會導致CMM測量數據不穩定，應該怎麼解決。
這個很好解決，首先建基準一定要准確，只要基準建准確了，後面就都好辦了，平面度不好的情況下盡可能的多採取測量點，就像統計學一樣，采樣的數據越多，就越接近真實值，將所有的量測點進行擬合，當然，測頭的直徑也要選好，不然點到坑坑窪窪就會直接影響測量結果，其次，有一些投影錯誤的量測點要首先排除在擬合元素之外。
J. 測量平面度、平行度有什麼儀器可以測量
測量平面度和平行度的儀器有：偏擺儀、百分表、數據採集儀。
測量原理
平面度：數據採集儀從百分表中實時讀取數據，並進行平面度誤差的計算與分析，無須人工計算，提高測量的准確率。
平行度：數據採集儀從百分表中自動讀取測量數據的最大值跟最小值，數據採集儀軟體自動計算出平行度誤差，並判斷所測零件的平行度誤差是否在平行度公差范圍內。如果所測平行度誤差大於平行度公差值，採集儀會自動發出報警功能，提醒相關操作人員該產品不合格。
(10)CMM怎樣均勻自動取點擴展閱讀
平面度誤差的測量方法和評定方法不同，數據處理的方法也不相同。選定某一測量方法和評定方法，可能直接得到實際表面的平面度誤差值，如採用打表法進行測量，再用對角線法評定其平面度誤差，則可不必進行數據處理，可直接得到測量結果。
採用水平儀進行測量，則不論採用何種評定方法，均需進行數據處理；而對於任何一種測量方法，如果按最小區域法來評定其平面度誤差，都必須進行數據處理才能得到平面度誤差值。
另外，測量基準面和評定基準面一般是不重合的，尤其是符合最小條件的評定基準面的位置是按實際表面的形狀確定的，不可能在測量之前預先確定。且測量所得到的原始數據中的最大值與最小值並不一定是實際表面上的最高點和最低點、
故在數據處理之前，一般應根據所測數據對實際表面的形狀特徵進行大致分析，初步判斷實際表面是凸形、凹形、鞍形或其它復雜形態，以免過多重復計算花費時間，必要時還可畫出其數據空間分布示意圖，進而確定其評定基準面。