两种表示法的差异反应了为每个能力和成熟度等级描述过程而使用的方法，他们虽然描述的机制可能不同，但是两种表示方法通过采用公用的目标和方法作为需要的和期望的模型元素，而达到了相同的改善目的。
　　现在CMMI面临的一个挑战就是创建一个单一的模型，可以从连续和阶段两个角度进行观察，包含相同的过程改进基本信息；处理相同范围的一个CMMI过程能够产生相同的结论。统一的CMMI（U-CMMI）是指产生一个只有公用方法和支持他们的KPA组成的模型。当按一种概念性的可伸展的方式编写，并产生了用于定义组织的特定目标过程模版，定义的模版构件将定义一个模型以适用于任何工程或其他方面。
　　CMMI与CMM差别：
　　CMMI 模型的前身是 SW-CMM 和 SE-CMM，前者就是我们指的CMM。CMMI与SW-CMM的主要区别就是覆盖了许多领域；到目前为止包括四个下面领域：
　　（1）、软件工程（SW-CMM）
　　软件工程的对象是软件系统的开发活动，要求实现软件开发、运行、维护活动系统化、制度化、量化。
　　（2）、系统工程（SE-CMM）
　　系统工程的对象是全套系统的开发活动，可能包括也可能不包括软件。系统工程的核心是将客户的需求、期望和约束条件转化为产品解决方案，并对解决方案的实现提供全程的支持。
　　（3）、集成的产品和过程开发（IPPD-CMM）
　　集成的产品和过程开发是指在产品生命周期中，通过所有相关人员的通力合作，采用系统化的进程来更好地满足客户的需求、期望和要求。如果项目或企业选择IPPD进程，则需要选用模型中所有与IPPD相关的实践。
　　（4）、采购（SS-CMM）
　　采购的内容适用于那些供应商的行为对项目的成功与否起到关键作用的项目。主要内容包括：识别并评价产品的潜在来源、确定需要采购的产品的目标供应商、监控并分析供应商的实施过程、评价供应商提供的工作产品以及对供应协议很供应关系进行适当的调整。
　　在以上模块中，企业可以选择软件工程，或系统工程，也可以都选择。集成的产品和过程开发和采购主要是配合软件工程和系统工程的内容使用。例如，纯软件企业可以选择CMMI中的软件工程的内容；设备制造企业可以选择系统工程和采购；集成的企业可以选择软件工程、系统工程和集成的产品和过程开发。CMMI中的大部分内容是适用各不同领域的，但是实施中会有显著的差别，因此模型中提供了"不同领域应用详解"。
　　CMM的基于活动的度量方法和瀑布过程的有次序的、基于活动的管理规范有非常密切的联系，更适合瀑布型的开发过程。而CMMI相对CMM更一步支持迭代开发过程和经济动机推动组织采用基于结果的方法：开发业务案例、构想和原型方案；细化后纳入基线结构、可用发布，最后定为现场版本的发布。虽然CMMI保留了基于活动的方法，它的确集成了软件产业内很多现代的最好的实践，因此它很大程度上淡化了和瀑布思想的联系。
　　在 CMMI 模型中在保留了CMM阶段式模式的基础上，出现了连续式模型，这样可以帮助一个组织以及这个组织的客户更加客观和全面的了解它的过程成熟度。同时，连续模型的采用可以给一个组织在进行过程改进的时候带来更大的自主性，不用再象CMM 中 一样，受到等级的严格限制。这种改进的好处是灵活性和客观性强，弱点在于由于缺乏指导，一个组织可能缺乏对关键过程域之间依赖关系的正确理解而片面的实施过程，造成一些过程成为空中楼阁，缺少其他过程的支撑。两种表现方式（连续的和阶段的）从他们所涵盖的过程区域上来说并没有不同，不同的是过程区域的组织方式以及对成熟度（能力）级别的判断方式。
　　CMMI 模型中比CMM 进一步强化了对需求的重视。在CMM 中，关于需求只有需求管理这一个关键过程域，也就是说，强调对有质量的需求进行管理，而如何获取需求则没有提出明确的要求。在CMMI的阶段模型中，3 级有一个独立的关键过程域叫做需求开发，提出了对如何获取优秀的需求的要求和方法。CMMI 模型对工程活动进行了一定的强化。在CMM中，只有3级中的软件产品工程和同行评审两个关键过程域是与工程过程密切相关的，而在CMMI中，则将需求开发，验证，确认，技术解决方案，产品集成这些工程过程活动都作为单独的关键过程域进行了要求，从而在实践上提出了对工程的更高要求和更具体的指导。CMMI中还强调了风险管理。不像在CMM 中把风险的管理分散在项目计划和项目跟踪与监控中进行要求，CMMI3级里单独提出了一个独立的关键过程域叫做风险管理。
　　CMMI标准名词术语
　　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的评价
　　6 CBA-IPI
　　CMM-Based Appraisal for Internal Process
　　Improvement
　　为内部过程改进而进行的基于CMM的评价（通常
　　称为CMM评审）
　　7 CC Configuration Controller 配置管理员
　　8 CF Common Feature 公共特性
　　9 CFPS Certified Function Point Specialist 注册功能点专家
　　10 CI Configuration Item 配置项
　　11 CM Configuration Management 配置管理
　　12 CMM Capability Maturity Model 能力成熟度模型
　　13 CMMI Capability Maturity Model Integration 能力成熟度集成模型
　　14 COTS Commerce off the shelf 商业现货供应
　　15 DAR Decision Analysis and Resolution 决策分析与制定
　　16 DBD Database Design 数据库设计
　　17 DD Detailed Design 详细设计
　　18 DP Data Provider 数据提供者
　　19 DR Derived Requirement 派生需求
　　20 EPG Engineering Process Group 工程过程小组
　　21 FP Function Point 功能点
　　22 FPA Function Point Analysis 功能点分析
　　23 FR Functional Requirement 功能性需求
　　24 GA Gap Analysis 差距分析
　　25 ID Interface Design 接口设计
　　26 IFPUG International Function Point Users Group 国际功能点用户组织
　　27 IPM Integrated Project Management 集成项目管理
　　28 IR Interface Requirement 接口需求
　　29 KPA Key Process Area 关键过程域
　　30 KR Key Requirements 关键需求
　　31 LA Lead Assessor 主任评审员
　　32 MA Measurement and Analysis 测量与分析
　　33 MAT Metrics Advisory Team 度量咨询组
　　34 MCA Metrics Coordinator and Analyst 度量专员
　　35 ML matreraty library 度量数据库
　　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 组织过程焦点
　　41 OPL Organizational Process Assets 组织过程财富
　　42 OPP Organaizational Process Perormance 组织过程性能
　　43 OSSP Organization’s Set of Standard Process
　　组织标准过程集合
　　44 OT Organizational Training 组织级培训
　　45 PA Process Areas 过程域
　　46 PAT Process Action Team 过程行动小组
　　47 PB Process Assets Library 过程财富库
　　48 PD Preliminary Design 概要设计
　　49 PDSP Project Defined Standard Processes 项目定义标准过程
　　50 PI Produce Integration 产品集成
　　51 PLC Product Life Cycle 产品生命周期
　　52 PMC Project Monitoring and Control 项目监控
　　53 PP Project Planning 项目策划
　　54 PPQA Process and Product Quality Assurance 过程与产品质量保证
　　55 PPR Price Performance Ratio 性能价格比
　　56 QA Software Quality Assurance 软件质量保证
　　57 QA Quality Assurance 质量保证
　　58 QAP Software Quality Assurance Plan 质量保证计划
　　59 QPM Quantitative Project Management 量化项目管理
　　60 RD Requirements Development 需求开发
　　61 RM/ReqM Requirements Management 需求管理
　　62 RSKM Risk Management 风险管理
　　63 RTM Requirement Traceability Matrix 需求跟踪矩阵
　　64 SAM Supplier Agreement Management. 供应协议管理
　　65 SC Steering Committee 指导委员会
　　66 SCAMPI
　　Standard CMMI Assessment Method for
　　Process Improvement 过程改进CMMI标准评审方法
　　67 SCCB Software Configuration Control Board 软件配置管理控制委员会
　　68 SCM Software Configuration Management 软件配置管理
　　69 SDP Software Development Plan 软件开发计划
　　70 SEI Software Engineering Institute (美国)软件工程学院
　　71 SEPG Software Engineering Process Group 软件工程过程组
　　72 SPI Software Process Improvement 软件过程改进
　　73 SPP Software Project Planning 软件项目策划
　　74 SPTO Software Project Tracking and Oversight 软件项目跟踪与监控
　　75 SR System Requirements 系统需求
　　76 SRS Software Requirement Specification 软件需求规格
　　77 SSM Software Subcontract Management 软件分包管理
　　78 SSR Software System Requirement 软件系统需求
　　79 TS Technical Solution 技术解决方案
　　80 UC Use Case 用例
　　81 UID User Interface Design 用户界面设计
　　82 VAL Validation 确认
　　83 VER Verification 验证
　　84 WBS Work Breakdown Structure 工作分解结构
　　85 WP Work Products 工作产品
　　86 Pre-assessment 预评审
　　87 Baseline 基线
　　88 Quality Attribute 质量属性
　　89 Scenario 场景
　　关键字：CMMI，SCAMPI，过程改进，能力成熟度，EPG
　　软件能力成熟度模型（CMM／CMMI）已成为IT业界通用的过程体系，是一条提高软件企业产品质量、增强企业核心竞争力的有效途径，它给软件企业带来的成功已经为许多国内、外著名软件厂商所证明，根据SEI的统计，软件企业在引入CMM后劳动生产率平均增长了35%；错误比率平均减少39%；平均成本回报率为5：1。 纵观国内自1993年开始Motorola（中国）实施起，至后来的东软、金蝶、用友等公司纷纷实施CMM或CMMI，国内企业实施CMMI一时间方兴未艾。但是大部分的企业（近60％的企业）实施CMMI收效不甚理想，最终走向失败，究其原因有多种，例如EPG人员素质不够，EPG团队松散，仅为了得到一纸证书，而忽略了过程改进项目对企业本身的重要程度，种种这些原因其根本核心就是EPG组建。作为全国CMMI咨询能力第一的企业，在EPG组建上有着深刻的理解以及丰富的经验。在EPG组建具体有以下四个步骤：
　　1、 EPG人员要求
　　过程改进实施人员如果没有足够的软件工程背景，在组织中亦无足够的能力完成其所担当的任务，则可能导致实施项目失败。因此必须选择那些有经验、有能力的员工参与的实施过程中来，充分发挥他们在企业里的正面影响力。
　　基本操作方法是：咨询公司与客户交流，并提出EPG人员所需要具备的相关条件，客户根据咨询公司提供的人员条件，结合本公司具体人员情况，提供EPG小组成员名单，
　　2、EPG人员确定
　　在客户方提供的EPG小组成员名单的基础上，咨询顾问与客户进行交流并筛选其中不符合要求的人员，并最终确定EPG各成员。EPG成员一旦确定，就要保持其稳定性，忌人员流动频繁，从而导致过程改进项目成本上升。
　　3、 组织
　　人员确定完毕后，将人员组织起来形成EPG项目团队，建立EPG项目团队的共同愿景或目标，确保成员均同意并接受目标，同时需要建立共同的价值观及信念，使成员相信过程改进项目是可行的、必要的，更是重要的，并且能为企业带来高效率、提高企业产品质量的。同时，在本阶段需要明确以下几点：
　　（1）明确各EPG项目成员所担当的任务及职责，并以文档的形式予以保存；
　　（2）确保时间表获得众人的支持；
　　（3）保证EPG团队拥有所需的资源；
　　(4) 建立完善的记录和信息沟通系统；
　　(5) 制定团队规范；