在 CMMI 模型中在保留了CMM阶段式模式的基础上，出现了连续式模型，这样可以帮助一个组织以及这个组织的客户更加客观和全面的了解它的过程成熟度。同时，连续模型的采用可以给一个组织在进行过程改进的时候带来更大的自主性，不用再象CMM 中 一样，受到等级的严格限制。这种改进的好处是灵活性和客观性强，弱点在于由于缺乏指导，一个组织可能缺乏对关键过程域之间依赖关系的正确理解而片面的实施过程，造成一些过程成为空中楼阁，缺少其他过程的支撑。两种表现方式（连续的和阶段的）从他们所涵盖的过程区域上来说并没有不同，不同的是过程区域的组织方式以及对成熟度（能力）级别的判断方式。
CMMI 模型中比CMM 进一步强化了对需求的重视。在CMM 中，关于需求只有需求管理这一个关键过程域，也就是说，强调对有质量的需求进行管理，而如何获取需求则没有提出明确的要求。在CMMI的阶段模型中，3 级有一个独立的关键过程域叫做需求开发，提出了对如何获取优秀的需求的要求和方法。CMMI 模型对工程活动进行了一定的强化。在CMM中，只有3级中的软件产品工程和同行评审两个关键过程域是与工程过程密切相关的，而在CMMI中，则将需求开发，验证，确认，技术解决方案，产品集成这些工程过程活动都作为单独的关键过程域进行了要求，从而在实践上提出了对工程的更高要求和更具体的指导。CMMI中还强调了风险管理。不像在CMM 中把风险的管理分散在项目计划和项目跟踪与监控中进行要求，CMMI3级里单独提出了一个独立的关键过程域叫做风险管理。
编辑本段标准名词术语
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了，大体做法 1、决定实施CMMI
2、EPG接受培训，理解CMMI
3、EPG根据自己理解的CMMI和实际情况开发一大堆漂漂亮亮的过程文档、流程图、表格、模板、检查单、作业指南。
4、大家边听着EPG的解释(包括培训、答疑)，边执行这些过程标准，然后审计(内、外)
将目前的最佳实践记录下来、写下来、文档化下来。
很多新的EPG在做了一段时间后无奈的发现自己居然沦落成了一个过程标准解说员、甚至文档管理员。自己工作大部分时间是面对文档，或者督促别人写文档
EPG最主要的工作应该深入到研发第一线，帮助研发人员解决研发过程中面临的最严重的实际问题(当然是解决方案要上升到过程高度，而不应是单个问题或个人)，甚至哪怕是一些不严重但以你的项目经验知道该如何解决的问题上。总体说来就是掌握项目进展中的任何细微的技术难点要点，并主动记录下来。
为什么这么说呢?CMMI实施的主要宗旨就是以每个项目为采集数据的源头，达到企业整体效益提升和资源重用。真正有价值的东西，是需要一线人员在实际工作中遇到问题，解决问题，并总结问题，不是一个一线工作的流水帐。就象一份研发人员的日报。写了上午做什么，下午做什么。这对企业的积累有什么用处呢?他工作过程中，遇到什么问题，他是怎么解决的，走过什么弯路，实验过几种方法，失败了，失败的原因是什么，最后选择了什么方法，可能不是最好的，但完成了任务，达到了效率和资源分配的平衡。这些东西才可能是未来类似项目中，遇到类似问题时，可能有参考价值的。通常也是EPG个人职业生涯的技术积累。只有公司里每个
员工，把自己认为最有价值的积累贡献出来。才可能达到公司有价值的积累。而决不是形式上写的上午下午每个小时的流水帐。
编辑本段人员素质
1、明白什么是有价值的积累，先是对你个人，然后才是顺便帮公司做了积累。
2、深入一线，发现她们并忠实地记录她们。CMMI里的SP、GP，只是帮助你，提醒你在哪个环节，哪些东西可能是有价值了。你去收集一下，别视而不见了。因为还有一个企业和你个人的角度不同，立场不同的问题。例如，REQM里收集需求，对个人技术方面的积累虽然不多，但对企业是至关重要的，一次需求变更，没详细写清楚，忘记了到客户那里去签字落实，可能就会给企业造成很大的损失。做为一个合格的EPG，是需要有这份责任和义务把每个环节都做到最好，这是职业道德所在。同时也是对自我延伸的一个好机会，学会一些和人的沟通，倾听，把专业的东西以平易的方式表达。这些也都算是EPG额外的收获。
通常情况下，为了按时按量完成项目，一线的骨干，对写日报、周报、文档都很不屑。EPG也很迁就，事后再补，这也不失为一个提高效率的好办法。但过去一个月半年了，我们正常人的记忆都能想象，很难记住细节。无非就是敷衍。这也在情理之中。你总不能让一个明天就要交东西的小组，今天晚上在通宵努力解决BUG的同时，还写什么报告，这也不尽人情。但作为EPG不能只把眼光集中在这妇人之心上。要想的更远。为什么会把项目推到这么晚，BUG还没解决完?难道要永远这样下去吗?项目中是有很多不可预测的因素，甚至是开发人员常说的\手气问题\，\人品问题\。但这些是需要控制的，也是通过经验可以控制的，所谓艺高人胆大。艺的高低，就是经验的积累决定的。
那怎么解决这种两难的问题呢?逼着技术骨干写心水，人家没时间也的确压力很大。不写，公司又得不到有效积累，积累的都是垃圾流水。有个公司的办法和经验到可以借鉴一下：
公司内部搞了个BBS，把不同类型的工作分成不同的组，有纯技术的，JAVA组，C++组等，也有PPT组，甚至动画组，界面组。大家把自己平时的工作积累FTP上去，甚至制作方法，遇到问题和解决方法的文档都丢上去，开始怎么想，用了多少套方案，最后选择了什么。自我感觉如何。把这些心路历程都写成文档。丢到阳光下，大家评论。用点击率和\顶\的人数来说明谁写的是心水，谁在写垃圾。大家都是一个公司的，很容易实名。直接纳入考核机制中。做为一线人员，大家也有动力来写，自己的聪明才智有了展现的平台，虚荣心和荷包都得到了相应的满足。何乐而不为呢?
EPG适时的评估大家的成果，并把他们分到项目里。帮助项目总结，甚至在平时遇到问题时，直接帮助技术人员做必要记录。项目进度松时，再督促项目人员完善内容。以达到对个人和公司积累的最大化。
EPG应该明白学习和积累是个终身的过程，对公司如此，对个人也是如此。CMMI是个辅助，辅助我们对公司做积累，也帮助我们个人做必要的积累。公司需要逐步走向更高的管理水平，发展平台。
编辑本段实施流程
阶段1：CMMI项目启动会
明确企业实施CMMI的商业目标，建立CMMI项目实施的沟通机制。 阶段2：CMMI基础培训和过程改进小组（EPG）组建
进行CMMI基础概念讲解，指导企业建立核心的过程改进小组。 阶段3：诊断
充分了解企业研发过程现状，识别企业现有软件过程与企业现阶段理应达到的的CMMI成熟度级别的差距，提交诊断报告，进行过程改进的策划。 阶段4：过程域培训和文件定义
结合企业过程现状进行CMMI过程域培训，通过举例、案例分析等方式，让企业的EPG掌握过程文件定义技巧，结合企业实际情况有针对性的定义组织的研发过程，并确定过程产出物（如：需求报告） 阶段5：项目试点
选择代表公司核心业务的项目或者典型项目进行试点，通过试点来完善过程文件，从而为企业全面推广过程文件打下基础。 阶段6：组织推广
全员参与全面导入与执行CMMI。
阶段7：预评估
验证组织推广的结果，识别企业尚存缺陷并制定再次改善方案，准备充分，以便企业能够更好进行正式SCAMPI评估。 阶段8：SCAMPI正式评估
由SEI授权的主任评估师领导，采用SCAMPI ( Standard CMMI Appraisal Method for Process Improvement)评估方法，对企业的能力成熟度进行正式的评估，颁发证书，通过SEI网站向全球发布企业信息。
