1．CMMl概述
    CMMI(Capability Maturity ModelIntegration)，英文的意思是”能力成熟度模型集成”。由卡内基．梅隆大学的软件工程协会(Software Engineering Institute，简称SEI)在c姗的基础上完善而成，目的是通过一个合理的体系模型来对软件组织开发能力进行合理有效的评估，帮助软件组织在模型实施的过程中提高软件过程管理能力，降低软件系统开发风险，在预定的项目周期和预算内开发出高质量的软件产品。并且充分考虑了软件工程与系统工程的集成，使得CMMI不再局限于纯粹软件的范畴。
    2．CMMI模型概要
    CMMI将软件过程改进的进化步骤组织成5个成熟等级，为过程不断改进奠定了循序渐进的基础。表1给出了CMMI?SE／SW1．1 Staged Representat i on模型概要，5个等级各有其不同的行为特征。不同等级组织的行为特征：即一个组织为建立或改进软件过程所进行的活动，对每个项目所进行的活动和所产生的横跨各项目的过程能力。
    3．经验体会
    3．1过程改进形成了良好的工作氛围   

    从符合公司商业目标来说，软件工程过程组(SEPG)一直致力于组织文化的培育。这个文化培育可能是比较虚的词，这么说吧，当有新人加入公司的时候，大家可以不断感受到这种气氛，是这个组织是一个什么样的工作氛围。
    从过程改进方面来说，也是在这个氛围中进行的，对于工作流程的整合，对于工作流程的每一个细小的改进，组织中的每一个人都可以进言献策，而不是由领导说了算，或由质量管理人员说了算。也正因为如此，过程改进以及执行都能比较得到大家的认可，项目组人员在项目开发过程中也比较乐于接受这些流程。
    3．2流程化管理让工作更有序化

    流程文档是从实际工作过程中抽取并定义的。在整合过程中，对于过程角色以及角色的职责做了进一步的清晰定义，同时，对于工作过程也做了制定了工作步骤要求。这样，从客户方发出项目开始，一直到项目验收，项目总结，定出了一整套的流程。是从第一步开始，下一步怎么做，定义了一个做事方式。另外，在流程里面定义了在一个阶段到下个阶段的职责，比如说这个阶段谁负责，负责人干什么事，其他人员干什么事，基本上都定义清楚了。这样很大程度上避免了有些事情大家都觉得应该干，而有些事情却没有人干的局面。所以，流程定义到了每个角色的头上，这样的话，不『一的角色，比如在这个项目组是一个负责人，可能到另外一个项目组是一个普通的工程师，因为角色不同，在不同项目里面的工作也不同。而这些定义，当项目启动的时候，都转化为项目开发计划。
    每个项目都要求做项目开发计划，这个计划包括这个项目在自己开发部是怎么做的，I?J时还包括如果在这个项目外包给软件公司，对软件公司怎么管理的计划，还有我们这边人员怎么配置的计划，这个计划里面包括了很多内容。其他还有配置管理的计划，SQA计划等等，这些计划都包含在软件开发的计划里面。从这个计划建立以后，在后面的过程中基本上要求按照计划执行。但是同时因为项目是变化的，有可能项目定义的内容会有一些偏差，这个时候要求对计划进行监控，如果出现大的偏差的话，开发计划要调整，如果出现小的偏差，需要对Schedule进行调整。同时，如果外包给软件公司的项目，也要求软件公司提供项目计划，而且要求他们每周对进度进行汇报。同时，在计划里面还定义了milestone review，不同阶段的review谁参加，大概是什么时候，这个都要求在计划里面进行定义。项目组人员在项目计划的指导下，因为职责明确，步骤清晰，都能更有效和高效地工作，避免了许多不必要的重复工作(rework)，大家感觉项目做的比以前更顺畅，同事间合作也更融洽，少了很多互相推诿。
    3．3通过流程化管理，全员的风险意识会大大提高
    定义一个比较详细的风险分析流程，流程中要求制作风险标注表。风险标注表是基于FMEA的方式，罩面有风险的发乍概率，发现的严重程度等等。所以要求在项目开始时候，进行风险分析，风险分析的结果作为项目开发计划的一部分。风险吩析时主要从资源和项目进度等各方面进行分析，同时提供了一套典型的分析表给大家作为参考。所谓的典硝风险表是从各个项目里面制定的风险中抽取，以及从各个项目反馈回来的可能风险，不断更新和充实典型风险表。在执行这个流程的时候，在项目一开始要标识风险，如果超过一定数值的风险，要做对应的策略。这样的话，项目开始有风
   险的计划，风险的标识，和风险对应计划。在项目开发过程中每周对风险进行识别，有没有新的风险出现，有没有原来的风险数值的降低，等于是在全项目的过程中，对风险有一个控制。在项目过程中有一整套的风险管理，可能大家在不知不觉中接受了这种风险管理的意识，有的时候在日常生活，甚全是整个公司的其他事情都不自觉的有了风险意识。所有的东西归根到底是给每个员上成功感，觉得在这个公司有发展的前途。
    3．4流程化管理给普通开发人员带来了工作成感
    关于工作的成感，涉及到每个人的感受。从流程角度来说，或者说从过程改进的角度来说，在计划方面，Review方面能促使组织中的每个人的工作更有成感。Review分技术Review和管理Review。技术Review是提前介入，提前减少风险，使项目的质量朝预想方向进行。实际上Review也是减少了项目组人员的工作时间。还有计划、Review，风险分析等等，都减少了救火事件。当然每个项月都会存在救火的时间，但是流程是帮助项目组尽量减少救火的出现。在很多公司里面存在这种状况，如果某个项目一直很顺利，什么事都没有出，平平淡淡过去了，领导会觉得这个项目没有出现英雄人物，如果出现救火了，出现一个大问题，出现～个或几个英雄把这个困难克服了，事情终做完了，可能觉得体现了公司的能力。但是如果软件开发想产业化，比如说想做大规模的开发的话，应该还是尽量避免救火的出现，而且尽量避免靠某些英雄人物的存在。
    4．小结
    软件过程管理的度需要根据具体公司的实际情况，人力、物力投入，人员素质，项目情况来选择，抽象的软件过程管理理论固然完美，但只有对提高本公司、本部门软件开发水平和质量有帮助的才是晟合适的。