兩種表示法的差異反應(yīng)了為每個能力和成熟度等級描述過程而使用的方法，他們雖然描述的機(jī)制可能不同，但是兩種表示方法通過采用公用的目標(biāo)和方法作為需要的和期望的模型元素，而達(dá)到了相同的改善目的。
　　現(xiàn)在CMMI面臨的一個挑戰(zhàn)就是創(chuàng)建一個單一的模型，可以從連續(xù)和階段兩個角度進(jìn)行觀察，包含相同的過程改進(jìn)基本信息；處理相同范圍的一個CMMI過程能夠產(chǎn)生相同的結(jié)論。統(tǒng)一的CMMI（U-CMMI）是指產(chǎn)生一個只有公用方法和支持他們的KPA組成的模型。當(dāng)按一種概念性的可伸展的方式編寫，并產(chǎn)生了用于定義組織的特定目標(biāo)過程模版，定義的模版構(gòu)件將定義一個模型以適用于任何工程或其他方面。
　　CMMI與CMM差別：
　　CMMI 模型的前身是 SW-CMM 和 SE-CMM，前者就是我們指的CMM。CMMI與SW-CMM的主要區(qū)別就是覆蓋了許多領(lǐng)域；到目前為止包括四個下面領(lǐng)域：
　?。?）、軟件工程（SW-CMM）
　　軟件工程的對象是軟件系統(tǒng)的開發(fā)活動，要求實(shí)現(xiàn)軟件開發(fā)、運(yùn)行、維護(hù)活動系統(tǒng)化、制度化、量化。
　?。?）、系統(tǒng)工程（SE-CMM）
　　系統(tǒng)工程的對象是全套系統(tǒng)的開發(fā)活動，可能包括也可能不包括軟件。系統(tǒng)工程的核心是將客戶的需求、期望和約束條件轉(zhuǎn)化為產(chǎn)品解決方案，并對解決方案的實(shí)現(xiàn)提供全程的支持。
　?。?）、集成的產(chǎn)品和過程開發(fā)（IPPD-CMM）
　　集成的產(chǎn)品和過程開發(fā)是指在產(chǎn)品生命周期中，通過所有相關(guān)人員的通力合作，采用系統(tǒng)化的進(jìn)程來更好地滿足客戶的需求、期望和要求。如果項(xiàng)目或企業(yè)選擇IPPD進(jìn)程，則需要選用模型中所有與IPPD相關(guān)的實(shí)踐。
　?。?）、采購（SS-CMM）
　　采購的內(nèi)容適用于那些供應(yīng)商的行為對項(xiàng)目的成功與否起到關(guān)鍵作用的項(xiàng)目。主要內(nèi)容包括：識別并評價(jià)產(chǎn)品的潛在來源、確定需要采購的產(chǎn)品的目標(biāo)供應(yīng)商、監(jiān)控并分析供應(yīng)商的實(shí)施過程、評價(jià)供應(yīng)商提供的工作產(chǎn)品以及對供應(yīng)協(xié)議很供應(yīng)關(guān)系進(jìn)行適當(dāng)?shù)恼{(diào)整。
　　在以上模塊中，企業(yè)可以選擇軟件工程，或系統(tǒng)工程，也可以都選擇。集成的產(chǎn)品和過程開發(fā)和采購主要是配合軟件工程和系統(tǒng)工程的內(nèi)容使用。例如，純軟件企業(yè)可以選擇CMMI中的軟件工程的內(nèi)容；設(shè)備制造企業(yè)可以選擇系統(tǒng)工程和采購；集成的企業(yè)可以選擇軟件工程、系統(tǒng)工程和集成的產(chǎn)品和過程開發(fā)。CMMI中的大部分內(nèi)容是適用各不同領(lǐng)域的，但是實(shí)施中會有顯著的差別，因此模型中提供了"不同領(lǐng)域應(yīng)用詳解"。
　　CMM的基于活動的度量方法和瀑布過程的有次序的、基于活動的管理規(guī)范有非常密切的聯(lián)系，更適合瀑布型的開發(fā)過程。而CMMI相對CMM更一步支持迭代開發(fā)過程和經(jīng)濟(jì)動機(jī)推動組織采用基于結(jié)果的方法：開發(fā)業(yè)務(wù)案例、構(gòu)想和原型方案；細(xì)化后納入基線結(jié)構(gòu)、可用發(fā)布，最后定為現(xiàn)場版本的發(fā)布。雖然CMMI保留了基于活動的方法，它的確集成了軟件產(chǎn)業(yè)內(nèi)很多現(xiàn)代的最好的實(shí)踐，因此它很大程度上淡化了和瀑布思想的聯(lián)系。
　　在 CMMI 模型中在保留了CMM階段式模式的基礎(chǔ)上，出現(xiàn)了連續(xù)式模型，這樣可以幫助一個組織以及這個組織的客戶更加客觀和全面的了解它的過程成熟度。同時(shí)，連續(xù)模型的采用可以給一個組織在進(jìn)行過程改進(jìn)的時(shí)候帶來更大的自主性，不用再象CMM 中 一樣，受到等級的嚴(yán)格限制。這種改進(jìn)的好處是靈活性和客觀性強(qiáng)，弱點(diǎn)在于由于缺乏指導(dǎo)，一個組織可能缺乏對關(guān)鍵過程域之間依賴關(guān)系的正確理解而片面的實(shí)施過程，造成一些過程成為空中樓閣，缺少其他過程的支撐。兩種表現(xiàn)方式（連續(xù)的和階段的）從他們所涵蓋的過程區(qū)域上來說并沒有不同，不同的是過程區(qū)域的組織方式以及對成熟度（能力）級別的判斷方式。
　　CMMI 模型中比CMM 進(jìn)一步強(qiáng)化了對需求的重視。在CMM 中，關(guān)于需求只有需求管理這一個關(guān)鍵過程域，也就是說，強(qiáng)調(diào)對有質(zhì)量的需求進(jìn)行管理，而如何獲取需求則沒有提出明確的要求。在CMMI的階段模型中，3 級有一個獨(dú)立的關(guān)鍵過程域叫做需求開發(fā)，提出了對如何獲取優(yōu)秀的需求的要求和方法。CMMI 模型對工程活動進(jìn)行了一定的強(qiáng)化。在CMM中，只有3級中的軟件產(chǎn)品工程和同行評審兩個關(guān)鍵過程域是與工程過程密切相關(guān)的，而在CMMI中，則將需求開發(fā)，驗(yàn)證，確認(rèn)，技術(shù)解決方案，產(chǎn)品集成這些工程過程活動都作為單獨(dú)的關(guān)鍵過程域進(jìn)行了要求，從而在實(shí)踐上提出了對工程的更高要求和更具體的指導(dǎo)。CMMI中還強(qiáng)調(diào)了風(fēng)險(xiǎn)管理。不像在CMM 中把風(fēng)險(xiǎn)的管理分散在項(xiàng)目計(jì)劃和項(xiàng)目跟蹤與監(jiān)控中進(jìn)行要求，CMMI3級里單獨(dú)提出了一個獨(dú)立的關(guān)鍵過程域叫做風(fēng)險(xiǎn)管理。
　　CMMI標(biāo)準(zhǔn)名詞術(shù)語
　　1 AT Assessment Team 評審小組
　　2 ATM Assessment Team Member 評審小組成員
　　3 BA Baseline Assessment 基線評審
　　4 CAR Causal Analysis and Resolution 原因分析與決策
　　5 CBA CMM-Based Appraisal 基于CMM的評價(jià)
　　6 CBA-IPI
　　CMM-Based Appraisal for Internal Process
　　Improvement
　　為內(nèi)部過程改進(jìn)而進(jìn)行的基于CMM的評價(jià)（通常
　　稱為CMM評審）
　　7 CC Configuration Controller 配置管理員
　　8 CF Common Feature 公共特性
　　9 CFPS Certified Function Point Specialist 注冊功能點(diǎn)專家
　　10 CI Configuration Item 配置項(xiàng)
　　11 CM Configuration Management 配置管理
　　12 CMM Capability Maturity Model 能力成熟度模型
　　13 CMMI Capability Maturity Model Integration 能力成熟度集成模型
　　14 COTS Commerce off the shelf 商業(yè)現(xiàn)貨供應(yīng)
　　15 DAR Decision Analysis and Resolution 決策分析與制定
　　16 DBD Database Design 數(shù)據(jù)庫設(shè)計(jì)
　　17 DD Detailed Design 詳細(xì)設(shè)計(jì)
　　18 DP Data Provider 數(shù)據(jù)提供者
　　19 DR Derived Requirement 派生需求
　　20 EPG Engineering Process Group 工程過程小組
　　21 FP Function Point 功能點(diǎn)
　　22 FPA Function Point Analysis 功能點(diǎn)分析
　　23 FR Functional Requirement 功能性需求
　　24 GA Gap Analysis 差距分析
　　25 ID Interface Design 接口設(shè)計(jì)
　　26 IFPUG International Function Point Users Group 國際功能點(diǎn)用戶組織
　　27 IPM Integrated Project Management 集成項(xiàng)目管理
　　28 IR Interface Requirement 接口需求
　　29 KPA Key Process Area 關(guān)鍵過程域
　　30 KR Key Requirements 關(guān)鍵需求
　　31 LA Lead Assessor 主任評審員
　　32 MA Measurement and Analysis 測量與分析
　　33 MAT Metrics Advisory Team 度量咨詢組
　　34 MCA Metrics Coordinator and Analyst 度量專員
　　35 ML matreraty library 度量數(shù)據(jù)庫
　　36 NFR Non-functional Requirement 非功能性需求
　　37 OC Operational Concept 操作概念
　　38 OID Organizational Innovation and Deployment 組織革新與部署
　　39 OPD Organizational Process definition 組織過程定義
　　40 OPF Organizational Process focus 組織過程焦點(diǎn)
　　41 OPL Organizational Process Assets 組織過程財(cái)富
　　42 OPP Organaizational Process Perormance 組織過程性能
　　43 OSSP Organization’s Set of Standard Process
　　組織標(biāo)準(zhǔn)過程集合
　　44 OT Organizational Training 組織級培訓(xùn)
　　45 PA Process Areas 過程域
　　46 PAT Process Action Team 過程行動小組
　　47 PB Process Assets Library 過程財(cái)富庫
　　48 PD Preliminary Design 概要設(shè)計(jì)
　　49 PDSP Project Defined Standard Processes 項(xiàng)目定義標(biāo)準(zhǔn)過程
　　50 PI Produce Integration 產(chǎn)品集成
　　51 PLC Product Life Cycle 產(chǎn)品生命周期
　　52 PMC Project Monitoring and Control 項(xiàng)目監(jiān)控
　　53 PP Project Planning 項(xiàng)目策劃
　　54 PPQA Process and Product Quality Assurance 過程與產(chǎn)品質(zhì)量保證
　　55 PPR Price Performance Ratio 性能價(jià)格比
　　56 QA Software Quality Assurance 軟件質(zhì)量保證
　　57 QA Quality Assurance 質(zhì)量保證
　　58 QAP Software Quality Assurance Plan 質(zhì)量保證計(jì)劃
　　59 QPM Quantitative Project Management 量化項(xiàng)目管理
　　60 RD Requirements Development 需求開發(fā)
　　61 RM/ReqM Requirements Management 需求管理
　　62 RSKM Risk Management 風(fēng)險(xiǎn)管理
　　63 RTM Requirement Traceability Matrix 需求跟蹤矩陣
　　64 SAM Supplier Agreement Management. 供應(yīng)協(xié)議管理
　　65 SC Steering Committee 指導(dǎo)委員會
　　66 SCAMPI
　　Standard CMMI Assessment Method for
　　Process Improvement 過程改進(jìn)CMMI標(biāo)準(zhǔn)評審方法
　　67 SCCB Software Configuration Control Board 軟件配置管理控制委員會
　　68 SCM Software Configuration Management 軟件配置管理
　　69 SDP Software Development Plan 軟件開發(fā)計(jì)劃
　　70 SEI Software Engineering Institute (美國)軟件工程學(xué)院
　　71 SEPG Software Engineering Process Group 軟件工程過程組
　　72 SPI Software Process Improvement 軟件過程改進(jìn)
　　73 SPP Software Project Planning 軟件項(xiàng)目策劃
　　74 SPTO Software Project Tracking and Oversight 軟件項(xiàng)目跟蹤與監(jiān)控
　　75 SR System Requirements 系統(tǒng)需求
　　76 SRS Software Requirement Specification 軟件需求規(guī)格
　　77 SSM Software Subcontract Management 軟件分包管理
　　78 SSR Software System Requirement 軟件系統(tǒng)需求
　　79 TS Technical Solution 技術(shù)解決方案
　　80 UC Use Case 用例
　　81 UID User Interface Design 用戶界面設(shè)計(jì)
　　82 VAL Validation 確認(rèn)
　　83 VER Verification 驗(yàn)證
　　84 WBS Work Breakdown Structure 工作分解結(jié)構(gòu)
　　85 WP Work Products 工作產(chǎn)品
　　86 Pre-assessment 預(yù)評審
　　87 Baseline 基線
　　88 Quality Attribute 質(zhì)量屬性
　　89 Scenario 場景
　　關(guān)鍵字：CMMI，SCAMPI，過程改進(jìn)，能力成熟度，EPG
　　軟件能力成熟度模型（CMM／CMMI）已成為IT業(yè)界通用的過程體系，是一條提高軟件企業(yè)產(chǎn)品質(zhì)量、增強(qiáng)企業(yè)核心競爭力的有效途徑，它給軟件企業(yè)帶來的成功已經(jīng)為許多國內(nèi)、外著名軟件廠商所證明，根據(jù)SEI的統(tǒng)計(jì)，軟件企業(yè)在引入CMM后勞動生產(chǎn)率平均增長了35%；錯誤比率平均減少39%；平均成本回報(bào)率為5：1。 縱觀國內(nèi)自1993年開始Motorola（中國）實(shí)施起，至后來的東軟、金蝶、用友等公司紛紛實(shí)施CMM或CMMI，國內(nèi)企業(yè)實(shí)施CMMI一時(shí)間方興未艾。但是大部分的企業(yè)（近60％的企業(yè)）實(shí)施CMMI收效不甚理想，最終走向失敗，究其原因有多種，例如EPG人員素質(zhì)不夠，EPG團(tuán)隊(duì)松散，僅為了得到一紙證書，而忽略了過程改進(jìn)項(xiàng)目對企業(yè)本身的重要程度，種種這些原因其根本核心就是EPG組建。作為全國CMMI咨詢能力第一的企業(yè)，在EPG組建上有著深刻的理解以及豐富的經(jīng)驗(yàn)。在EPG組建具體有以下四個步驟：
　　1、 EPG人員要求
　　過程改進(jìn)實(shí)施人員如果沒有足夠的軟件工程背景，在組織中亦無足夠的能力完成其所擔(dān)當(dāng)?shù)娜蝿?wù)，則可能導(dǎo)致實(shí)施項(xiàng)目失敗。因此必須選擇那些有經(jīng)驗(yàn)、有能力的員工參與的實(shí)施過程中來，充分發(fā)揮他們在企業(yè)里的正面影響力。
　　基本操作方法是：咨詢公司與客戶交流，并提出EPG人員所需要具備的相關(guān)條件，客戶根據(jù)咨詢公司提供的人員條件，結(jié)合本公司具體人員情況，提供EPG小組成員名單，
　　2、EPG人員確定
　　在客戶方提供的EPG小組成員名單的基礎(chǔ)上，咨詢顧問與客戶進(jìn)行交流并篩選其中不符合要求的人員，并最終確定EPG各成員。EPG成員一旦確定，就要保持其穩(wěn)定性，忌人員流動頻繁，從而導(dǎo)致過程改進(jìn)項(xiàng)目成本上升。
　　3、 組織
　　人員確定完畢后，將人員組織起來形成EPG項(xiàng)目團(tuán)隊(duì)，建立EPG項(xiàng)目團(tuán)隊(duì)的共同愿景或目標(biāo)，確保成員均同意并接受目標(biāo)，同時(shí)需要建立共同的價(jià)值觀及信念，使成員相信過程改進(jìn)項(xiàng)目是可行的、必要的，更是重要的，并且能為企業(yè)帶來高效率、提高企業(yè)產(chǎn)品質(zhì)量的。同時(shí)，在本階段需要明確以下幾點(diǎn)：
　?。?）明確各EPG項(xiàng)目成員所擔(dān)當(dāng)?shù)娜蝿?wù)及職責(zé)，并以文檔的形式予以保存；
　　（2）確保時(shí)間表獲得眾人的支持；
　　（3）保證EPG團(tuán)隊(duì)擁有所需的資源；
　　(4) 建立完善的記錄和信息溝通系統(tǒng)；
　　(5) 制定團(tuán)隊(duì)規(guī)范；