在实施CMM过程中，可根据各个企业面临的不同问题决定实现核心过程域的先后秩序并按此秩序逐步进行。而在实施每一个具体的核心过程域时，对其目标组及核心实践也可确定执行的先后顺序，逐步实现总体目标。最后，我们将第二、三、四、五等等级始终的核心过程域简介如下：
第二级（可重复级）
- 需求管理（Requirement Management）- 软件项目的开发必须以客户的需求为指向，需求管理目的在于使开发商和客户对客户本身的真实需求有统一认识。
- 软件项目计划（Software Project Planning）- 软件项目管理必须事先拟订合乎规范的开发计划及其他相关计划，例如，检测与追踪计划。
- 软件项目追踪和监控（Software Project Tracking and Oversight）- 防范项目实施过程中所产生的计划偏离问题，使项目组对软件项目的进展充分了解并控制。
- 软件与合同管理(Software Subcontract Management) －建立规范化的软件分包管理制度以保证软件质量的一致性。
- 软件质量保证（Software Quality Assurance）－通过对软件开发过程的监控和评测保证软件质量。
- 软件配置管理（Software Configuration Management）－保证在软件项目开发生命周期的完整性。
第三级（定义级）
- 企业过程焦点（Organization Process Focus）－在整个企业范围内树立标准的过程并将其列为企业工作重点。
- 企业过程制定（Organization Process Definition）－对企业过程进行确立。
- 培训计划（Training Program）－对项目组员工进行必要的过程培训。
- 集成软件管理（Integrated Software Management）－调整企业的标准软件过程并将软件工程和管理集成为一个确定的项目过程。
- 软件产品工程（Software Product Engineering）－关于软件项目的技术层面的目标在此确立，如设计、编码、测试和校正。
- 组际协调（Intergroup Coordination）－促进各项目组之间的借鉴与支持在全企业范围内实现。
- 同业复查（Peer Reviews）－促进各项目组成员之间运用排查、审阅和检测等手段找到并排除产品中的缺陷。
第四级（管理级）
- 定量过程管理（Quantitative Process Management）－对软件过程的各个元素进行定量化描述和分析并收集量化数据协调管理。
- 软件质量管理（Software Quality Management）－通过定量手段追踪并掌握软件产品质量使其达到预定标准。
第五级（优化级）
- 缺陷预防（Defect Prevention）－通过有效机制识别软件缺陷并分析缺陷来源从而防止错误再现，减少软件错误发生率。
- 技术变动管理（Technology Change Management）－引入新工具和技术并将其融入企业软件过程之中，以促进生产工效和质量。
- 过程变动管理（Process Change Management）－在定量管理基础上坚持全企业范围的，持续性的软件过程改进，提高生产率，减少投入和开发时间，保证企业的过程长期处于不断更新和主动调节之中。
基于CMM成熟度模型，包括中小企业在内的软件企业如何进行软件过程改造，如何在具体项目中引入并实施CMM的标准成为人们关注的重点。CMM的实施核心焦点不在于软件的开发技术层面，而在于工程过程层面和工程管理层面。所谓工程过程层面是指将工程开发的整个过程所涉及的相关议题作为过程学的体系来研究和执行。过程学本身既不同于通常所说的软件工程技术，（如编码，操作系统等等），也不同于一般所言的工程管理学，软件过程既是对软件工程这一领域中所涉及的流程按其独特特性进行专门描述。事实上，任何企业在开发工程产品的实践中，都有开发过程产生，虽然很多企业并未对其进行记录或关注。按照工程过程学派的观点，没有正确的过程就不可能有正确的产品产生，因此对开发组织的过程需要规范和改进。
由于软件过程必然与工程管理相关，因而它不象具体的开发技术问题那样容易规划并着手实施，特别是国内广大的中小软件企业和部门，在采纳某一过程体系进行开发流程的改造时，应特别注意如下几方面的问题，将其作为过程实施开端的要领加以掌握：
1．不可急于求成和盲目乐观。任何新体系的采纳和改进都必然涉及对旧有体系的重组和调整，需要投入相当的决心和时间。如果企业在充分评估后决定了以 CMM工程标准来规范建构自身的软件开发行为，则应该在次序改进的前提下尽早实施企业开发过程调整以便有充裕时间理解和评估前期改造的成效。
2．必须懂得CMM作为一套标准，它指明的是该作什么（What）而非怎样去做（How），同时CMM也代表了一种对软件生产过程进行理解和分析的独到观点（Philosophy）。CMM着重于过程中的关键要素，而非面面俱到，它主要不是为了解决某个具体项目的问题，也不能保证在此框架下产品开发 100%成功，CMM所述的软件过程集合了工程过程和管理过程等方面，对它的过程改进要靠许多细小的阶段性的步骤而非一蹴而就的革新。
3．CMM1.1版主要针对大型软件企业，这些企业的开发工作通常关涉软件生产过程的方方面面。对于20人以下的小型企业，1.1版中的一些环节可能并不适用。
4．企业在采纳CMM过程改进的同时，可以引入新技术与自动化工具帮助软件开发的实现，不过，对过程的改进要求企业全面投入并需较长周期，而技术引进则相对周期较短。但如果企业只是依靠技术改进而不注重过程改进，长远看来，企业可能收获甚少。
5．"知己知彼，百战不殆"。实施改进之前，企业应对自身当前所有的软件能力水平及过程状态有尽可能的客观、详尽的了解。可以参考本文后附企业开发能力自测表进行初步诊断，在明了自身实际过程等级之后，企业应确定需要达到的等级目标并找到主要差距所在。企业要想达到的等级目标包括它所特定的过程目标及核心过程域（KPA）。这一等级应符合企业自身开发水平与项目特征。在企业明了了自身实际等级与目标等级之间的差距之后，应制定规划，决定改进次序及程度，可参考的决策因素包括：目标与能力的平衡，投入工期与质量的保证，企业总体发展与当前项目开发的平衡，员工素质条件，最薄弱环节与最急需改进环节，还有最易见效的环节，等等。
6．如有可能，在企业内部成立专门的过程改进规划组，并配合企业外聘的咨询机构或顾问，拟订出详细的过程实施方案，同时注意在实施过程中对计划进行修正和调节。在此，应将改进方案指定得尽量具体详细，这包括：
<1>目标明确并可检验,有助于切实的检验标准；
<2>有详细的实施步骤,有专人负责每一环节的落实,有协调方解决各环节之间的冲突；
<3>如需采纳新技术和工具，应详细分析他们的作用及获取方式并准备对新技术和工具进 行改造，对员工进行培训以适应项目所需。
<4>制定项目开发时间表，将每个过程环节的实施与此时间表挂钩。
<5>对项目开发的投入工期进行预测并据此规划开发工作。
<6>预先规划开发过程中相关数据的采集，分析和提供方式与时段；
<7>所有过程，包括：需求分析、项目计划、项目验收和交付，都必须编档并保留，应有具体的监控和考核计划来监督过程的实施。这一计划应考虑到偏差的可能性及应对方案。
<8>企业的高层和相关管理人员应参与过程的制定与实施并形成制度。领导层应负责对每一阶段改进的总结并制定出相应的后继方案，另外，凡涉及对已定计划和过程的调整必须事先申请备案并经领导层同意。
<9>需强调的最重要的一条原则是，过程改进不可流于书面形式，所有员工都应理解并参与其中。
CMM模式即可用于描述软件机构实际具备的能力成熟度水平，也可用于指明软件企业改进软件工程所需着力之处，它说明了努力的方向，又允许企业自己选择恰当的方式去达到这一目的。实施CMM的经验告诉软件工程人员，在软件项目开发中，更多的问题和错误来源于工程安排的次序，工程规划和工程管理而不是技术上的how to do。软件工程的过程学不断分析和改善已有工程经验，拟定出尽可能完善的开发过程，并按开发生命周期确定重点环节加以管理，最终达到以量化数据来建立能力成熟度等级的目标。良好的工程过程保证了有序的开发实施，避免了以往开发人员被动救火的方式，并将个人主观因素减低至最少。开发人员的个人创造性从独立任意的发挥消解并转移到如何创建性地运用和完善工程过程上来。
作为一种模型，CMM实际上是对软件机构工程过程的理论和数据模拟，在对它的应用中，主要包括软件产品供应方和应用方两大类。
目前，世界范围内已采纳CMM标准的企业纷纷以此标准决定软件项目合同的承接与分包。实践中，许多中小企业在接纳CMM体系时，采纳了保留企业部分原有工程过程指标并加以修改的办法。
卡莱基·梅隆大学软件研究所提出了一套实施CMM标准的方法，按照他们的建议，IDEAL是企业开始引入CMM体系的良好参照模式，它包括：
I--启动（Initiating）,表示开发机构应为CMM的引入准备好前期基础设施和程序。
D--诊断（Diagnosing）,明确机构目前所处的能力水平及目标等级所在。
E--建构（Establishing）,制定如何实现目标等级的计划。
A--行动（Acting）,具体实施该计划。
L--学习（Learning）,积累以往经验并将其用于持续的改进过程之中，同时注意新技术和工具的引入以协助过程实施。
如有可能，企业在咨询机构或咨询师的协助下可以加快CMM体系引入的过程，但企业必须同时着力于培训自身理解工程过程的人才。较好的方法包括在开发组织内部分项目形成CMM研讨小组以促进开发组及开发人员之间的经验交流。显而易见，实施CMM的成效应根据机构自身特有的实际情况作判断，正确的实施应该从质和量两方面对过程的各环节发生作用。CMM体系在中小企业的应用中并未要求逐字照章对应每一项核心过程域和核心实践来进行，机构可以用裁减的办法对其应用程度作修正，也可选用阐述的办法将某项具体的实施工作等同为特定的核心实施。
根据SEI的研究数据，绝大多数软件项目的成功都遵循了下述的工程原则：
a,将软件生命周期划分为若干阶段并进行严格的计划，包括项目计划，里程碑计划，质量检测计划，维护计划等。
b,在开发过程中，分阶段进行复审和评估，以便尽早发现错误所在。
c,项目组成员应注重包括技术和流程在内的培训，提高人员素质。
d,软件过程的改进应是持续性的，不断调整的进程。
e,尽可能采用度量数据来描述过程中的每一环节，从而提高可预测性和可控制性。
f,对以往所有开发工作必须进行文档工作，积累经验以用于未来的开发之中。
g,如果项目允许，尽可能采纳较为先进的技术与工具，例如，面向对象的编程方式(OOP)
达到可重复级软件能力成熟度能力的企业有能力重复在以前项目上所作开发的成功经验，虽然项目的具体实施各不相同，但通过企业的制度化的有效管理过程，各项目组能够在当前和未来的项目中保证已建立的软件项目管理和实施规则能够得到正确和有效地执行，从而可在新项目上用积累的制度化有序化和文档化的经验进行有成功保障的开发实践，这种成功保障也可在开发前期的项目成本，工程进度和质量预算上得到体现。在此阶段的软件开发组织已拥有了一套有效过程，它们是实用的、文档化的、实施验证过的、可测量的和能改进的。
单个项目组通常会面对各类项目约定问题，项目组对项目的正确约定来源于以往开发项目的经验及当前项目的各级需求。项目经理应成为一个有序体系中的重要环节，他们负责追踪软件成本、进度和功能，能迅速发现项目级约定中出现的问题并设法解决。
各项目组对软件需求和实现需求的软件产品已建立了基于验证的基准或基限，项目标准也得到确立，软件组织能保证正确地执行标准。第二级软件组织的过程能力是有纪律的，项目的规划和追踪是稳定的，项目过程也在项目管理体系的有效控制之下重复着被验证的成功经验。在此，组织体系和管理的问题比技术问题更加重要。
