1、用于软件过程的改进。(SPI Software Process Improvement)

帮助软件企业对其软件过程的改变进行计划、制定以及实施。

2、用于软件过程评估。(SPA Software Process Assessment)

在评估中，一组经过培训的软件专业人员确定出一个企业软件过程的状况，找出该企业所面对的与软件过程有关的，最迫切的所有问题;以及取得企业领导层对软件过程改进的支持。(用途2是用途1的前一步)

3、 软件能力评鉴。(SCE Software Capability Evaluation)

在能力评鉴中，一组经过培训的专业人员鉴别出软件承包者的能力资格;或者是检查监察正用于软件制作的软件过程的状况。

基于CMMI成熟度模型，包括中小企业在内的软件企业如何进行软件过程改造，如何在具体项目中引入并实施CMMI的标准成为人们关注的重点。CMMI的实施核心焦点不在于软件的开发技术层面，而在于工程过程层面和工程管理层面。所谓工程过程层面是指将工程开发的整个过程所涉及的相关议题作为过程学的体系来研究和执行。过程学本身既不同于通常所说的软件工程技术，(如编码，操作系统等等)，也不同于一般所言的工程管理学，软件过程既是对软件工程这一领域中所涉及的流程按其独特特性进行专门描述。事实上，任何企业在开发工程产品的实践中，都有开发过程产生，虽然很多企业并未对其进行记录或关注。按照工程过程学派的观点，没有正确的过程就不可能有正确的产品产生，因此对开发组织的过程需要规范和改进。

由于软件过程必然与工程管理相关，因而它不象具体的开发技术问题那样容易规划并着手实施，特别是国内广大的中小软件企业和部门，在采纳某一过程体系进行开发流程的改造时，应特别注意如下几方面的问题，将其作为过程实施开端的要领加以掌握：

1.不可急于求成和盲目乐观。任何新体系的采纳和改进都必然涉及对旧有体系的重组和调整，需要投入相当的决心和时间。如果企业在充分评估后决定了以CMMI工程标准来规范建构自身的软件开发行为，则应该在次序改进的前提下尽早实施企业开发过程调整以便有充裕时间理解和评估前期改造的成效。

2.必须懂得CMMI作为一套标准，它指明的是该作什么(What)而非怎样去做(How)，同时CMMI也代表了一种对软件生产过程进行理解和分析的独到观点(Philosophy)。CMMI着重于过程中的关键要素，而非面面俱到，它主要不是为了解决某个具体项目的问题，也不能保证在此框架下产品开发100%成功，CMMI所述的软件过程集合了工程过程和管理过程等方面，对它的过程改进要靠许多细小的阶段性的步骤而非一蹴而就的革新。

3.CMMI1.1版主要针对大型软件企业，这些企业的开发工作通常关涉软件生产过程的方方面面。对于20人以下的小型企业，1.1版中的一些环节可能并不适用。

4.企业在采纳CMMI过程改进的同时，可以引入新技术与自动化工具帮助软件开发的实现，不过，对过程的改进要求企业全面投入并需较长周期，而技术引进则相对周期较短。但如果企业只是依靠技术改进而不注重过程改进，长远看来，企业可能收获甚少。

5.“知己知彼，百战不殆”。实施改进之前，企业应对自身当前所有的软件能力水平及过程状态有尽可能的客观、详尽的了解。可以参考本文后附企业开发能力自测表进行初步诊断，在明了自身实际过程等级之后，企业应确定需要达到的等级目标并找到主要差距所在。企业要想达到的等级目标包括它所特定的过程目标及核心过程域(KPA)。这一等级应符合企业自身开发水平与项目特征。在企业明了了自身实际等级与目标等级之间的差距之后，应制定规划，决定改进次序及程度，可参考的决策因素包括：目标与能力的平衡，投入工期与质量的保证，企业总体发展与当前项目开发的平衡，员工素质条件，最薄弱环节与最急需改进环节，还有最易见效的环节，等等。

6.如有可能，在企业内部成立专门的过程改进规划组，并配合企业外聘的咨询机构或顾问，拟订出详细的过程实施方案，同时注意在实施过程中对计划进行修正和调节。在此，应将改进方案指定得尽量具体详细，这包括：

<1>目标明确并可检验,有助于切实的检验标准;

<2>有详细的实施步骤,有专人负责每一环节的落实,有协调方解决各环节之间的冲突;

<3>如需采纳新技术和工具，应详细分析他们的作用及获取方式并准备对新技术和工具进行改造，对员工进行培训以适应项目所需。

<4>制定项目开发时间表，将每个过程环节的实施与此时间表挂钩。

<5>对项目开发的投入工期进行预测并据此规划开发工作。

<6>预先规划开发过程中相关数据的采集，分析和提供方式与时段;

<7>所有过程，包括：需求分析、项目计划、项目验收和交付，都必须编档并保留，应有具体的监控和考核计划来监督过程的实施。这一计划应考虑到偏差的可能性及应对方案。

<8>企业的高层和相关管理人员应参与过程的制定与实施并形成制度。领导层应负责对每一阶段改进的总结并制定出相应的后继方案，另外，凡涉及对已定计划和过程的调整必须事先申请备案并经领导层同意。

<9>需强调的最重要的一条原则是，过程改进不可流于书面形式，所有员工都应理解并参与其中。

CMMI模式即可用于描述软件机构实际具备的能力成熟度水平，也可用于指明软件企业改进软件工程所需着力之处，它说明了努力的方向，又允许企业自己选择恰当的方式去达到这一目的。实施CMMI的经验告诉软件工程人员，在软件项目开发中，更多的问题和错误来源于工程安排的次序，工程规划和工程管理而不是技术上的how to do。软件工程的过程学不断分析和改善已有工程经验，拟定出尽可能完善的开发过程，并按开发生命周期确定重点环节加以管理，最终达到以量化数据来建立能力成熟度等级的目标。良好的工程过程保证了有序的开发实施，避免了以往开发人员被动救火的方式，并将个人主观因素减低至最少。开发人员的个人创造性从独立任意的发挥消解并转移到如何创建性地运用和完善工程过程上来。

作为一种模型，CMMI实际上是对软件机构工程过程的理论和数据模拟，在对它的应用中，主要包括软件产品供应方和应用方两大类。

目前，世界范围内已采纳CMMI标准的企业纷纷以此标准决定软件项目合同的承接与分包。实践中，许多中小企业在接纳CMMI体系时，采纳了保留企业部分原有工程过程指标并加以修改的办法。

CMMI模式即可用于描述软件机构实际具备的能力成熟度水平，也可用于指明软件企业改进软件工程所需着力之处，它说明了努力的方向，又允许企业自己选择恰当的方式去达到这一目的。实施CMMI的经验告诉软件工程人员，在软件项目开发中，更多的问题和错误来源于工程安排的次序，工程规划和工程管理而不是技术上的how to do。软件工程的过程学不断分析和改善已有工程经验，拟定出尽可能完善的开发过程，并按开发生命周期确定重点环节加以管理，最终达到以量化数据来建立能力成熟度等级的目标。良好的工程过程保证了有序的开发实施，避免了以往开发人员被动救火的方式，并将个人主观因素减低至最少。开发人员的个人创造性从独立任意的发挥消解并转移到如何创建性地运用和完善工程过程上来。

作为一种模型，CMMI实际上是对软件机构工程过程的理论和数据模拟，在对它的应用中，主要包括软件产品供应方和应用方两大类。

目前，世界范围内已采纳CMMI标准的企业纷纷以此标准决定软件项目合同的承接与分包。实践中，许多中小企业在接纳CMMI体系时，采纳了保留企业部分原有工程过程指标并加以修改的办法。

卡莱基·梅隆大学软件研究所提出了一套实施CMMI标准的方法，按照他们的建议，IDEAL是企业开始引入CMMI体系的良好参照模式，它包括：

I--启动(Initiating),表示开发机构应为CMMI的引入准备好前期基础设施和程序。

D--诊断(Diagnosing),明确机构目前所处的能力水平及目标等级所在。

E--建构(Establishing),制定如何实现目标等级的计划。

A--行动(Acting),具体实施该计划。

L--学习(Learning),积累以往经验并将其用于持续的改进过程之中，同时注意新技术和工具的引入以协助过程实施。

如有可能，企业在咨询机构或咨询师的协助下可以加快CMMI体系引入的过程，但企业必须同时着力于培训自身理解工程过程的人才。较好的方法包括在开发组织内部分项目形成CMMI研讨小组以促进开发组及开发人员之间的经验交流。显而易见，实施CMMI的成效应根据机构自身特有的实际情况作判断，正确的实施应该从质和量两方面对过程的各环节发生作用。CMMI体系在中小企业的应用中并未要求逐字照章对应每一项核心过程域和核心实践来进行，机构可以用裁减的办法对其应用程度作修正，也可选用阐述的办法将某项具体的实施工作等同为特定的核心实施。

根据SEI的研究数据，绝大多数软件项目的成功都遵循了下述的工程原则：

1、将软件生命周期划分为若干阶段并进行严格的计划，包括项目计划，里程碑计划，质量检测计划，维护计划等。

2、在开发过程中，分阶段进行复审和评估，以便尽早发现错误所在。

3、项目组成员应注重包括技术和流程在内的培训，提高人员素质。

4、软件过程的改进应是持续性的，不断调整的进程。

5、尽可能采用度量数据来描述过程中的每一环节，从而提高可预测性和可控制性。

6、对以往所有开发工作必须进行文档工作，积累经验以用于未来的开发之中。

7、如果项目允许，尽可能采纳较为先进的技术与工具，例如，面向对象的编程方式(OOP)。