CMMI V1.3版是什么？
一、什么是 CMMI
1.1 概述
CMMI即软件能力成熟度模型集成,是由美国卡耐基梅隆大学软件工程研究所（Software Engineering Institute,SEI）组织全世界的软件过程改进和软件开发管理方面的专家历时四年而开发出来的,并在全世界推广实施的一种软件能力成熟度评估标准,主要用于指导软件开发过程的改进和进行软件开发能力的评估，CMMI缩写：
1. C：能力 -Capability
2. M：成熟度 -Maturity
3. M：模型 -Model
4. I：集成 -Integration
1.2 三种应用领域
三种应用领域共享16个核心过程域，同时每个领域自己特有的一些过程域，不同CMMI模型之间的差别，在于特定过程域（Specific PAs）所关注的不同的业务目标和管理诉求。
1. 开发（CMMI for Development CMMI-DEV）：为专注于开发产品和服务的企业而设计的。该模型探讨了将客户需求转化为开发人员所需的细节，有效地将产品组件集成到最终产品或服务中，进行技术分析和开发工作来设计产品或服务，并确保开发产品、开发工作满足了最终用户的需求和设计过程中的规范要求。
2. 服务（CMMI for Service CMMI-SVC）：ISO/IEC20000等组织模型最佳实践。
3. 采购(CMMI for Acquisition CMMI-ACQ)：政府及产业采购最佳实践。
1.3 CMMI 发展简史
1. 60年代中期爆发了软件危机。
2. 70年代中期美国国防部调查发现：项目70%国为管理不善。
3. 90年代中期10%项目控制在预定的费用和进度。
4. 95年美国取消810亿美元项目（其中31%取消,53%进度延迟50%）。
5. 80年代中期美国政府提出开发能力评估的要求。
6. 1987年,SEI的Mark Pauk等人建立了第一个CMM（Capability Maturity Model,能力成熟度模型）,即CMM软件。
7. 1993年,SEI推出了CMM 1.1,美国国防采购与技术办公室领导了一个由政府、企业和SEI的代表组成的团队开始开发一个CMM模型的集成框架,即CMMI（Capability Maturity Model Integration,能力成熟度模型集成）。
8. 2002年1月,CMMI 1.1发布。
9. 2006年8月,面向开发的CMMI（CMMI-DEV 1.2）版本发布。
10. 2010年11月,CMMI-DEV 1.3版本发布。
1.4 CMMI 基本思想
开发和应用CMMI的主要原因有三点：一是软件项目的复杂性的快速增长使过程改进的难度增大,二是软件工程的并行与多学科组合,三是实现过程改进的最佳效益。
1. 解决软件项目的过程改进难度增大问题。CMM成功实施以后,极大地提高了软件企业的开发效率和软件产品的质量,从而也提高了软件产品的可靠性和软件产业的信誉,这样人们就对软件寄予了更大的希望。人们希望软件能够完成更多、更大、更复杂的任务。
2. 实现软件工程的并行与多学科组合。这种倾向意味着设计人员和客户要与制造人员、测试人员和用户共同工作,以支持开发需求的制造组织,这种工作方式蕴涵着所有关键的相关人员要支持产品或服务开发的所有阶段。
3. 实现过程改进的最佳效益。尽管过程改进存在复杂化的因素,但软件管理专家们相信,其中的许多障碍可以通过一个集成过程改进的公共模型来克服。这种信念反映了在集成方面所进行的工作和CMMl项目的作者和评审人员的经验。人们相信,正如通过CMM的过程改进能够产生显著的效益一样,集成过程改进也能产生更大的效益。
二、 实施CMMI的收益
自2003年SEI(Software Engineering Institute/SEI, Carnegie Mellon University/CMU)发表CMMI开始，全球每年导入家数几乎以倍数成长，显示CMMI确为国际证实有助于流程改善的模式，甚至认为CMMI已经为软体的品质保证及国际合作的基本要求。导入CMMI-DEV开发模型有助于提升流程改善与品质管控的能力，从环境建立、技术辅导、人才培训、推广宣导等分项计划实施，健全国内环境以达到强化者体质。同时，透过已达一定数量的CMMI认证厂商数目发挥群聚效应，建立品质品牌，将使国际买主对我国资讯服务业的技术与服务更具信心，打开产业的国际知名度。配合国内业者于特定领域的专业技术，结合产业上中下游的供应链，达到产业垂直分工与水平整合的综效，提供全方位产品服务。国际化有赖于群策群力，整合国内业者行销资源以拓展国际专案，有效的将我国资讯服务业推向世界的舞台。
除此之外，国内资讯软体业者普遍为中小型机构，与国外动辄数千人的规模相比，无论在研发经费、人力资源、内部管理等，皆无法达到相对的水准，特别是内部流程与专案的管理技术，需花费人力与成本才能累积，因此小型机构普遍较无定义良好的制度与做法，因此导入经国际业者广泛采用的CMMI流程改善机制，将有助于短时间内提升厂商自身的技术与管理能力，透过透明的专案监控作法度量分析，使得管理阶层更具信心地掌握专案品质、时程与成本；奠定良好的营运管理机制，便于了解相关营运活动的状况，并透过不断的改善流程，除了使流程务实有效外，也将促进生产力之提升与营运成本之下降。透过不断的改善流程，除了使流程务实有效外，也将促进生产力之提升与营运成本之下降。获得全球性软件与系统工程行业的唯一权威认证，是对企业软件研发与服务能力的权威认可，主要概括为以下几点：
1. 提升公司品牌形象与市场竞争力，帮助企业在竞争中脱颖而出。
2. 获得政府对软件与系统集成企业自主创新与发展的支持。
3. 让公司持续、可控的向客户交付符合要求的产品与服务。
4. CMMI通过降低研发、生产和交付的成本，帮助公司提升经营业绩。
5. 灵活运用CMMI DEV（研发）、CMMI SVC（服务）还是CMMI ACQ（采购）三种不同模型，可以帮助提升不同的商业需求。
三、 CMMI 体系
3.1 CMMI 过程域概述
CMMI还有一个重要的概念是过程域（Process Area）,过程域指出了达到某个成熟度等级必须要解决的一族问题,就某一领域内的一组相关实践,当它们共同得到实施时,能满足一组对于在本领域作出改进较为重要的目标。
过程域的内容包括模型和过程改进的基础和目标,其中目村代表了过程改进想要达到的最终状态,它的实现表示了项目和过程控制水平,其包含特定目标与共性目标。
1. 特定目标
1) 只适用于一个过程,它描述过程特性具有唯一性,即只有该过程必须实现的那些特性。
2) 特定目标是必需的部件,在评估时用来衡量该过程域是否满足要求,例如需求管理过程域的一个特定目标是“SG1管理需求”。
2. 共性目标
1) 共性目标称为“共性”是因为同一目标的陈述对应了多个过程域。
2) 共性目标描述组织制度化实施的特征,例如需求管理过程域的一个共性目标是“GG2 制度化管理过程”。
3.2 CMMI 的22个过程域
3.2.1 2级支持类过程域
1. CM：Configuration Management配置管理,目的是使用配置识别、配置控制、配置状态记录与报告以及配置审计,来建立并维护工作产品的完整性。
2. MA：Measurement and Analysis 度量与分析,目的是开发并保持用于支持管理信息所需的度量能力。
3. PP：Project Planning 项目计划,目的是建立并维护定义项目活动的计划。
4. PMC：Project Monitoring and Control 项目监督与控制,目的是提供对项目进展的了解,以便在项目绩效显著偏离计划的时候采取适当的纠正措施。
5. PPQA：Process and Product Quality Assurance 过程与产品质量保证,目的是向员工与管理层提供对过程及其相关工作产品的客观洞察。
6. REQM：Requirements Management 需求管理 ,目的是管理项目的产品与产品组件需求,并确保那些需求与项目计划和工作产品间的协调一致。
7. SAM：Supplier Agreement Management 供方协议管理,目的是管理从供方采购产品与服务的活动。
3.2.2 3级支持类过程域
1. RD ：Requirements Development 需求开发,目的是挖掘、分析并建立客户需求、产品需求与产品组件需求。
2. DAR：Decision Analysis and resolution决策分析与解决,目的是使用正式的评价过程,遵循已建立的准则,对已识别的多个备选方案进行评价,以分析可能的决策。
3. IPM ：Integrated Project Management集成项目管理,目的是从组织的标准过程集中裁剪得到集成的已定义过程,并以此为依据建立并管理项目以及相关干系人的参与。
4. OPD ：Organization Process Definition 组织级过程定义,目的是建立并维护一套可用的组织级过程资产、工作环境标准以及团队规则与指南。
5. OPF ：Organization Process Focus 组织级过程关注,目的是基于对组织过程资产当前的强项与弱项的透彻理解,计划、实施并部署组织级过程改进。
6. OT ：Organization Training 组织级培训,目的是发展人员的技能与知识,使其能够有效且高效地执行他们的角色。
7. PI ：Product Integration 产品集成 ,目的是将产品组件装配成产品,确保产品作为一个整体正确地运行（即具有所要求的功能与质量属性）,并交付产品。
8. RSKM：Risk Management 风险管理,目的是在项目潜在问题发生前对其进行识别,以便在整个产品或项目生命期中,计划并在需要时启动风险的处理行动,从而降低这些潜在问题对达成目标产生的不利影响。
9. TS：Technical Solution 技术解决方案,目的是选择、设计并实现对需求的解决方案。
10. VAL：Validation 确认,目的是证明产品或产品组件被置于预期环境中时满足其预期用途。
11. VER：Vertification 验证,目的是确保选定的工作产品满足其规定的需求。
3.2.3 4级支持类过程域
1. OPP：Organization Process Performance 组织级过程性能,目的是建立并维护对组织标准过程集中所选定过程性能的量化理解,以及支持达成质量与过程性能目标,并提供过程性能数据、基线与模型,以量化管理组织项目。
2. QPM：Quantitative Project Management 量化项目管理,目的是量化地管理项目,以达成项目已建立的质量与过程性能的目标。
3.2.4 5级支持类过程域
1. CAR：Causal Analysis and resolution原因分析与解决,目的是识别所选结果的原因并采取行动,以改进过程性能。
2. OPM：Organization Performance Management 组织级绩效管理,目的是主动地管理组织的绩效以及满足其业务目标
3.3 阶段式模型与过程域
阶段式模型与过程域
3.3.1 5个成熟等级
阶段式则是反应其成熟度水平,阶段式模型将过程域划分为5个成熟等级：
1. 初始级（第1级）：过程通常是混乱的,而且组织通常没有提供稳定的开发环境。这些组织的成功往往依赖组织中个人的能力与拼搏精神,而不是使用一套经过验证的过程。虽然在这种混乱的环境中也能开发出可以工作的产品和服务,但是往往伴随着项目费用的超支和进度的拖延。
相关过程域：无
2. 已管理级（第2级）：组织的项目已确保需求是被管理的,而且其过程是经过计划、执行、度量及控制的。在预定的时间节点（例如重要的里程碑和重要任务的完成时刻）,管理层都可以了解工作成果的情况。
相关过程域 ：REQM、PP、PMC、SAM、MA、CM、PPQA
3. 已定义级（第3级）：项目可对组织的标准过程进行裁剪,以建立项目过程,适用于某些特殊项目或单位。成熟度3级是基于对过程活动的了解,以及对过程、产品与服务的详细度量,可更主动地管理过程。
相关过程域 ：RD、TS、PI、VER、VAL、OPF、OPD、OT、IPM、RSKM、DAR
4. 已量化管理级（第4级）：选定对整体过程绩效有重大影响的子过程,并使用统计和其他的量化技术来控制这些子过程。建立质量与过程绩效的量化目标,并以该目标为管理过程的准则。量化目标是根据客户、最终用户、组织及过程执行者的需求而设定的。以统计的术语表示质量和过程绩效,并使它们在整个过程中受到管理。针对这些过程,收集过程绩效的详细度量资料,并进行统计分析。界定过程变化的特殊原因,并适当地修正特殊原因的来源,以避免未来再度发生。将度量结果纳入度量库,以支持未来以事实为基础的决策。
相关过程域 ：QPM、OPP
5. 持续优化级（第5级）：成熟度第5级专注于持续改进过程绩效,已经建立组织的量化过程目标,并持续修订以反映持续变化的经营目标。其专注于克服过程变化的共性原因,并改变过程（也就是改变过程绩效的平均值）以改善过程绩效（同时维持统计上的可测性）,以便达到预期过程改进的量化目标。
相关过程域 ：OPM、CAR
阶段式模型成熟等级与过程域对应关系
3.3.2 达到2级管理水平项目的特点
1. 客户要签署《需求规格说明书》,并且变更受到控制。
2. 要编写《开发计划》来指导工作。
3. 根据《开发计划》跟踪实际工作。
4. 如果涉及到软硬件采购,则需要采取一套方法来管理。
5. 采取一些试题的办法,获取项目的一些信息。
6. 有SQA监督项目工作。
7. 有SCM保证工作产品的一致性。
2级项目特别小结：
1. 软件开发的一些细节没有定义：如需求开发、设计、编码、测试等。
2. 全部的PA都是针对项目这一级的,没有组织级的PA。
3.3.3 达到3级管理水平项目的特点
1. 项目管理水平升级：3级的IPM集成项目管理,指导利用组织财富库,裁剪出项目计划；RSKM详细指导到如何做风险管理。
2. 细化了软件工程的各个环节：需求调研、系统设计、程序开发、测试、维护。
3. 增加了决策的流程：哪些情况需要进行决策分析、决策要有选择的标准、要有候选方案、要有选择的办法。
4. 加入了组织级方面的要求：组织过程聚焦、组织过程定义、组织培训。
3级项目特别小结：
1. 项目管理水平升级：风险管理升级、开发计划升级。
2. 细化了软件工程的各个环节：需求开发、系统设计、程序开发、测试、维护。
3. 增加了决策流程。
4. 加入了组织级方面的要求。
3.4 连续式模型与过程域
连续式是反应一个软件公司的能力水平,将过程域划分为项目管理、过程管理、工程和支持等4个类别。单个过程域属于唯一的一个类型,比如不会出现一个过程域既是项目管理的又是过程管理的。
连续式模型与过程域
3.4.1 连续式模型类别
1. 项目管理类过程域：项目管理类过程域涵盖了与项目的计划、监督和控制相关的项目管理活动, CMMI-DEV中的七个项目管理类过程域如下:
1) 集成项目管理( Integrated Project Management,IPM)
2) 项目监督与控制( Project Monitoring and Control,PMC)
3) 项目计划( Project Planning,PP)
4) 量化项目管理（Quantitative Project Management,QPM）
5) 需求管理(Requirements Management, REQM)
6) 风险管理（Risk Management, RSKM）
7) 供方协议营理（Supplier Agreement Management,SAM）
2. 过程管理类过程域：包含跨项目的活动,这些活动与过程的定义、计划、部署、实施、监督、控制、评估、度量及改进相关,CMMI-DEV中的五个过程管理类过程域如下:
1) 组织级过程定义（Organizational Process Definition,OPD）
2) 组织级过程关注（Organizational Process Focus,OPF）
3) 组织级绩效管理（Organizational Performance Management,OPM）
4) 组织级过程性能（Organizational Process Performance,OPP）
5) 组织培训(Organizational Training,OT)
3. 工程类过程域：涵盖了工程学科所有的开发与维护活动,工程类过程域书写使用了通用的工程术语,这样,涉及产品开发过程（如软件工程、机械工程等）的任何技术学科都能够将其用于过程改进。工程类过程域不同工程学科的关联过程整合到单一的产品开发过程之中,来支持以产品为导向的过程改进策略,这种过程方法有效避免了组织级“烟囱”型隔阂思想的倾向。工程类过程域适用于开发领域中任何产品或服务的开发（如软件产品、硬件产品、服务、过程等）CMMI-DEV中的五个工程类过程域如下：
1) 产品集成( Product Integration,PI)
2) 需求开发( Requirements Development,RD)
3) 技术解决方案( Technical Solution．TS)
4) 确认(Validation,VAL)
5) 验证( Verification,VER)
4. 支持类过程域：涵盖了支持产品开发与维护的活动,支持类过程域应对面向项目的过程,并能够应对通用于组织的过程。例如“过程与产品质量保证”过程域能够与所有的过程域一起使用,来对全部过程域中所描述的过程与工作产品提供客观评价,CMMI-DEV中的五个支持类过程域如下：
1) 原因分析与解决( Causal Analysis and Resolution,CAR)
2) 配置管理（Configuration Management,CM）
3) 决策分析与解决(Decision Analysis and Resolution,DAR)
4) 度量与分析（Measurement and Analysis,MA）
5) 过程与产品质量保证（Process and Product Quality Assurance,PPQA）
3.4.2 连续式模型能力等级
能力等级表示一个组织在实施和控制其过程以及改善其过程绩效等方面所具备的能力。一个过程能力等级由这个过程的若干相关的特定实践和共性实践所构成。这些特定实践和共性实践如果得以执行,则将使该组织的这个过程的执行能力得到提高,进而增强该组织的总体过程能力。
1. 能力等级0-不完整级的特征：不完整级也称为未执行级,它的程程是一个未执行或仅仅部分执行的过程,该过程的一个或多个特定目标未被满足。
2. 能力等级1-已执行的特征：已执行的过程是一个满足过程域各个特定目标的过程,不完整级与已执行级之间的关键差别在于“已执行级过程满足相应的过程的所有特定目标”。
3. 能力等级2-已管理级的特征：已管理级过程是一个具有以下特征的已执行级过程：
1) 按照预定方针给以策划和执行的
2) 为了生成受控的输出,过程的执行都是配备有适当的资源、有熟练的技能的人
3) 各方利益相关者介入了该过程
4) 并且依据各项要求进行了审查和评价
4. 能力等级3-已定义级的特征：已定义级过程是这样一种受管理的过程：
1) 它是根据组织的剪裁指南从本组织的标准过程集合剪裁而得来
2) 它具有受到维护的过程描述
3) 它能为本组织的过程资源贡献工作成果、度量项目以及其它过程改进信息
四、 CMMI3 级认证
4.1 基于CMMI的过程改进步骤
过程该进生命周期模型
4.2 评估证据类型
1. 评估证据类型
1) 直接成果：成果本身是此执行方法的目的。
2) 间接成果：成果本身并非此执行方法的目的,但为达成目的而使用手段的成果。
3) 确证：证实执行方法的实施之口头或书面的证明。
2. 评估方法
1) SCAMPI C:内部评估方法。
2) SCAMPI B:内部评估方法。
3) SCAMPI A:最正式的评估方法,需要有SEI授权的主任评估师。
4.3 CMMI规划战略
CMMI改进规划-三步走战略
4.4 CMMI DEV评估要求
1. 采用 SCAMPI A V1.3评估方法，根据客户业务情况适当裁剪后，包含CMMI 各等级的所有过程域。
2. 在填写“评估输入”之前，由客户公司项目负责人与Fancier咨询师共同确定参评的组织结构范围。
3. 一般选择3-5个典型项目参加评估，能代表公司核心的业务，具有完整生命周期，数量要达到年项目量的60%以上 。
4. 评估小组（ATM）由主任评估师、Fancier咨询师以及其他ATM成员组成，在评估前需参加过 CMMI Institute*授权的Introduction to CMMI培训课程，主任评估师提供的ATM SCAMPI方法的培训。
5. 评估时间视具体评估进展情况确定CMMI 2级和3级一般会持续5～7天，CMMI高等级为15 - 22天。
6. 评估结果将由主任评估师按SCAMPI的要求上报至CMMI Institute归档。
7. 证书有效期三年
4.5 CMMI实施流程
1. 阶段1-CMMI项目启动会：明确企业实施CMMI的商业目标,建立CMMI项目实施的沟通机制。
2. 阶段2-CMMI基础培训和过程改进小组（EPG）：进行CMMI基础概念讲解,指导企业建立核心的过程改进小组。
3. 阶段3-诊断：充分了解企业研发过程现状,识别企业现有软件过程与企业现阶段理应达到的CMMI成熟度级别的差距,提交诊断报告,进行过程改进的策划。
4. 阶段4-过程域培训和文件定义：结合企业过程现状进行CMMI过程域培训,通过举例、案例分析等方式,让企业的EPG掌握过程文件定义技巧,结合企业实际情况有针对性的定义组织的研发过程,并确定过程产出物（如：需求报告）
5. 阶段5-项目试点：选择代表公司核心业务的项目或者典型项目进行试点,通过试点来完善过程文件,从而为企业全面推广过程文件打下基础。
6. 阶段6-组织推广：全员参与全面导入与执行CMMI。
7. 阶段7-预评估：验证组织推广的结果,识别企业尚存缺陷并制定再次改善方案,准备充分,以便企业能够更好进行正式SCAMPI评估。
8. 阶段8-SCAMPI正式评估：由SEI授权的主任评估师领导,采用SCAMPI ( Standard CMMI Appraisal Method for Process Improvement)评估方法,对企业的能力成熟度进行正式的评估,颁发证书,通过SEI网站向全球发布企业信息。
4.6 评估步骤
1. 步骤一：差距分析
2. 步骤二：整改指导
3. 步骤三：体系实施
4. 步骤四：就绪检查
5. 步骤五：预评估
6. 步骤六：正式评估
