CMMI知识体系框架提交.docx
《CMMI知识体系框架提交.docx》由会员分享，可在线阅读，更多相关《CMMI知识体系框架提交.docx（31页珍藏版）》请在冰豆网上搜索。
CMMI知识体系框架提交
CMMI知识体系框架
一、CMMI的研究动态
20世纪80年代，美国联邦政府提出对软件开发组织的软件开发能力进行评估的要求，以规范其软件项目管理过程，提高软件质量。
1993年，卡内基-梅隆大学软件工程研究所（SEI）正式发布了软件能力成熟度模型SW-CMMVIA.SW-CMM是组织进行软件过程改善和软件过程能力评估的一个有效的指导框架，它通过过程控制提高软件产品质量，以使其更加科学化、标准化。
继CMM之后，SEI提出了成熟度能力集成模型CMMI，以更加系统和一致的框架来指导组织改善软件过程，提高软件产品和服务的开发、获取和维护能力。
1、发展历程
CMM及CMMI从产生到现在，仅仅20余年的时间，但已经历了四个不同的发展阶段：
（1）开发和建立阶段（20世纪80年代-2000年底）
CMM及其他模型的研究，CMMI立项，集成已有的过程改进模型并进行改进，形成第一个集成化CMMI模型及相关的评估和培训资料。
该阶段结束的标志是第一个正式的CMMI产品发布。
（2）试用和完善阶段（2000年底-2002年1月）
将初始CMMI模型运用于工程过程改进实践，验证模型中具体条款的准确性和实用性，形成较稳定的版本。
该阶段结束的标志是第一个成熟版本（CMMI1.1）的发布。
（3）学习和推广阶段（2002年1月-现在）
成功的经验促使更多的组织采用CMMI，同时引发学习、研究CMMI的热潮。
目前的研究主要处于该阶段。
（4）贯标机制形成阶段（即将或正在开始）
对已有研究成果进行科学总结，形成贯彻、执行CMMI的系统理论与方法。
简单地说，贯标是“建立质量体系并有效地运行”。
具体是：
配置足够、合理的资源，设置合理、有效的组织结构，规定岗位职责，相关人员各尽其职协同工作，按程序规定完成生产中的每一过程，最后对贯标效果进行综合评估。
随着对CMMI研究向纵深发展，即将或正在进入该阶段。
2、研究成果
国外研究成果主要分为三类：
（1）组成CMMI的基础模型
适用于软件开发的CMM（SW-CMM）、系统工程能力成熟度模型（SE-CMM）、适用于软件获取的CMM（SA-CMM）、系统工程能力评估模型（SECAM）、PeopleCMM、适用于集成化产品开发的CMM（IntegratedProductDevelopment，IPD）等等。
（2）SEI发布的CMMI产品集
随着对集成化过程改进的需求日益加大，SEI陆续发布了一系列产品，主要包括：
集成了不同学科的CMMI-SE/SW，CMMI-SE/SW/IPPD，CMMI-SE/SW/IPPD/A；CMMI评估需求版本1.0（ARCVl.0）；适用于过程改进的标准CMMI评估方法（SCAMPI）等等。
（3）其他组织对CMMI的开创性成果
CMMI及CMMI的成功和广泛采纳，吸引越来越多的相关领域（软件工程、系统工程、项目管理等）专家对其进行应用研究。
这些研究基本处于学习SEI已有成果的层次，但也进行了一些创新性工作，主要包括：
针对某个组织的具体要求，将CMMI运用于实际，获得了大量宝贵的经验和教训；对CMMI中的某个过程域进行分析，提出了一些有效的方法和理论；将CMMI与其他标准对比，研究其各自的特点等等。
我国的研究现状：
我国从上世纪90年代开展CMM/CMMI研究以来，仅仅10余年，目前的研究主要体现在学习和实施CMM/CMMI，大多沿用国外的理论、方法和技术，重在从国外引入并结合组织自身特点实施CMM/CMMI。
近年来，随着国内不少知名企业率先成功实施CMM/CMMI并通过成熟度等级评估，其影响力日益扩大，有不少人开始探索适合中国软件产业特点的CMM/CMMI理论、方法和技术。
我国信息产业部《信息产业“十五”计划纲要》指出，“十五”期间国家软件业的发展重点是，改进软件的传统开发方法和管理方式，推进以构件为基础的软件工业化生产，加强对软件企业能力成熟度（CMM）的管理，开发系统集成软件，增强承担重大系统工程软件开发与系统集成的能力。
2000年6月国务院颁发了《鼓励软件产业和集成电路产业发展的若干政策》，该文件的第五章第十七条明确提出“鼓励软件出口型企业通过GB/T19000-IS09000系列质量保证体系认证和CMM（能力成熟度模型）认证。
其认证费用通过中央外贸发展基金适当予以支持。
”
然而，截止2003年3月底，我国仅不足100家企业通过CMM/CMMI不同级别的评估，其中通过4级和5级的还不到10家。
究其原因，除了组织自身的认知水平不高，国内获得SEI授权的评估师不足等原因之外，人员匾乏、资金不足、技术落后是大多数软件组织实施CMM/CMMI的最大制约因素。
CMM/CMMI是一项复杂的系统工程，根据组织实际的不同，每一个CMM/CMMI等级的评估周期（从准备到完成）约需12-30个月，实施期间的人力、资金、技术投入是巨大的。
当前国内的软件企业规模现状是以小型软件企业为主的金字塔结构，以它们目前的实力根本无法达到CMM/CMMI的要求。
实践水平的落后严重制约了理论的研究和发展，反过来又对实践产生了影响。
二、CMMI的特点
1、CMMI模型结构基于对过程和过程改进理论的深刻认识。
2、CMMI是管理模型而非技术模型。
CMMI是一条过程改进的途径，是一套指南，帮助组织通过持续的重复、测量和提炼，稳步创造与精化开发环境。
其更偏重于对过程改进的高层次指导，而不拘泥于低层次的技术细节。
3、CMMI是改进模型。
集成化的模型有利于统筹分析和整体规划改进；跨越部门学科的过程带来更多的交流，从而利于形成紧密的、有效的、精简的、继承的过程，对过程改进有全局效益。
4、CMMI模型是层次分明的结构。
成熟度等级-过程域-目标-实践，是一个典型的层次模型。
三、CMMI的结构
CMMI为软件组织建立了一个描述其综合软件能力的模型，并提供一套可供公众使用的准则：
这些准则描述那些成功地实施了过程改进的组织的特征。
该模型用“软件能力成熟度”来衡量这种综合软件能力。
在模型中，把所有软件组织的软件能力成熟度划分为5个等级—第1到第5级。
数字越大，成熟度等级越高。
高成熟度等级代表比较强的综合软件能力，反之亦然。
按照这种概念，一个组织的成熟度等级表明这个组织有效地管理软件产品（或服务）开发的能力。
从过程改进的角度说，这种成熟度等级是过程改进的递进式平台。
除了第1级之外，每个成熟度等级都反映出有一批软件过程稳定下来。
在这批稳定的软件过程的基础上，软件组织可以瞄准更高一个成熟度等级。
通过过程改进活动，使更多的软件过程以制度化的形式达到稳定，于是，该组织的综合软件能力就升到一个更高的成熟度平台上。
应该注意，按照该模型提升软件能力成熟度等级是由低到高逐步递进的，不能放弃比较低的等级直接进入比较高的等级。
5个成熟度等级分别是：
第1级：
初始级
第2级：
受管理级
第3级：
已定义级
第4级：
定量管理级
第5级：
持续优化级
除第1级（初始级）以外，其他各等级用预先规定的一组过程域来定义。
每个过程域的实现，用相应的一组目标（共性目标和特定目标）来衡量。
模型中为每个目标规定了相应的一组实践（共性实践和特定实践），通过实施这些实践来达到相应的目标。
换句话说，如果针对某个成熟度等级，实施了该等级定义的各个过程域的各个实践并且达到了目标要求，也就表明软件能力达到了这个成熟度等级。
围绕成熟度等级的过程域、目标和实践等是构成模型的部件。
除了过程域、目标和实践外，模型中还包含子实践、典型工作产品、详细说明、示例以及引证，它们也是本模型的组成部件。
显然，CMMI模型具有层次分明的结构特点：
成熟度等级-过程域-目标-实践，是一个典型的层次模型，如图：
从管理的角度分析：
这种层次结构也满足管理过程的需要。
成熟度等级是一个总的管理纲要，划分为5个等级—第1到第5级。
它给出了组织过程改进的范围和要实现的成熟度能力的大致目标。
如成熟度等级2意味着主要关注需求管理、项目计划、项目监督和控制、供应商合同管理、度量和分析、过程和产品质量保证、配置管理等7个过程域的满足。
过程域是一个更加具体的子纲要，它是在成熟度等级的基础上针对某个过程改进方面的详细说明，并仅仅选择那些对过程改进关系最重要的题目。
如需求管理过程域，收集了大量有关的需求管理信息，主要包括过程域的目的、描述成功的需求管理过程和实践的结果、相关注解以及入门指导资料。
因为经验证明，无法充分确定需求和管理的变化是项目不能满足其成本、进度或质量目的的主要原因。
目标是管理想要达到的最终状态，它的实现表示项目和过程控制已经达到了某种规定的程度。
特定目标仅仅适用于单一的过程域，而共性目标可以适用于所有的过程域。
实践是达到目标的管理手段，它可以作为强指示器指示它们被映射到的目标是否得到满足。
不过，这种管理手段并不是唯一的，一个特定的组织可能拥有达到一个目标的己认证的手段，而该手段并不依赖于映射到那个目标的所有实践的性能。
也就是说，“替代的”实践可以提供达到目标的同样有用的手段。
当一个实践对一个单一的过程域是唯一的时，就称该实践为“特定实践”，而当一个实践可能适用于所有的过程域时，就称该实践为“共性实践”。
以下对相关概念进行说明：
1、成熟度等级
第1级：
初始级——在第1级成熟度等级的情况下，过程一般是随机性的和无序的。
处于成熟度等级1的组织一般不具备稳定的开发环境。
在这类组织中，项目的成功往往取决于个人的能力和拼搏精神，离开了具备同样能力和经验的人，就无法在下一个项目中获得同样的成功。
处于成熟度等级1的软件组织在这种专门化的无序环境中常常也能生产出可以工作的产品，但是，往往伴随着的是项目超过预算和拖延进度。
第2级：
受管理级——一个软件组织如果达到了成熟度等级2的各个过程方面的全部目标，就表明这个组织的软件能力达到了第2级成熟度等级。
就意味着该软件组织己经确保有关的过程在项目一级得到策划、被形成了文件、得到执行、受到监督和控制。
在这一级上，项目要达到针对过程确定的诸如成本、进度和质量目标之类的具体目标。
由第2级成熟度等级反映出来的过程约束有助于确保现行的实践按照某些成功的经验被执行。
这些实践如果在与当前工作类似的工作上使用，可望得到类似的结果。
在这一级上，要对过程的需求、标准和具体目标，过程的工作产品以及服务做出规定并且形成文件。
管理层应该在某些规定点（例如，在重大里程碑处和重大作业完成时）能够“看得见”工作产品和服务的状态。
要在相关的共利益者之间建立承诺并予以满足。
必要时，可以修改承诺。
工作产品要与共利益者一起审查，要对工作产品加以控制。
工作产品和服务要满足其规定的需求、标准和具体目标。
第3级：
已定义级——处于成熟度等级3的软件组织是已经达到了等级2和等级3的各个过程方面的全部目标的组织。
在等级3上，所要执行的过程是从组织的标准过程集合和组织过程财富剪裁而来，是与将要运行该过程的环境相适应的。
这些要执行的过程是得到理解和恰当赋予特性的，并且用标准、规程、工具和方法予以描述。
在第2级与第3级之间的一个重要差别在于标准、过程描述和规程的适用范围。
在第2级成熟度等级上，标准、过程描述和规程可能只在过程的某个特定事例中使用，例如在某个具体项目上使用。
在第3级上，项目用的标准、过程描述和规程是从组织的成功经验总结得来，整个组织执行的过程是一致的，这些标准、过程描述和规程通过己定义过程在整个组织的各个项目使用。
它们之间的另一个重要差别是，在第3级上对过程的描述更详细、更严格，并且在实施过程管理时更强调了解过程活动之间关系、过程的详细度量值以及过程的工作产品和服务。
组织的标准过程集合是第3级成熟度等级的基础，它是长期建立和不断完善的。
标准过程定义了用于建立供整个组织一致实施的过程的基本过程，它们描述第3级成熟度等级上所期望的基本过程要素以及这些过程要素之间的关系（例如顺序和界面）。
需要长期建立和不断完善组织一级的基础设施，用以支持当前和将来使用组织标准过程集合。
组织的管理层根据组织的标准过程集合确定过程的具体目标。
这些过程具体目标应该适合于在第3级成熟度等级上处理。
第4级：
定量管理级——处于成熟度第4级的组织是达到了第2，3和4级各个过程方面的全部目标的组织。
在这个等级上，对各个过程运用统计技术和其他定量技术对各个过程实施控制，建立了关于产品质量、服务质量以及过程性能的定量目标，并且把这些定量目标作为管理过程的准则。
在过程的整个生存周期中，对产品质量、服务质量和过程性能都进行统计管理。
顾客、最终用户、组织以及过程实施者的需要是目标量化的基础。
实施该过程的人直接介入对该过程的定量管理。
对过程总体性能有重要作用的其他过程也要进行定量管理。
要收集这些过程的过程性能的详细度量值并进行统计学分析。
找出过程变化的特殊原因，适宜时，从这些特殊原因的根源上解决问题，以防止将来再次发生类似问题。
这里所说的特殊原因是造成某些短暂的具体缺陷的原因，而不是过程的内在原因。
把产品质量、服务质量和过程性能的度量值纳入组织度量值库，以支持今后以事实为根据的决策。
第3级与第4级之间的关键区别在于过程性能的可预见性。
在第4级上，对过程的性能是以统计技术或其他定量技术进行控制，并且从统计意义上说是可预见的。
在第3级上，过程性能仅仅具备定性的可预见性。
第5级：
持续优化级——处于成熟度等级第5级的组织是达到了成熟度等级第2，3和4级各个过程方面的全部目标的组织。
成熟度等级5侧重于过程性能的持续改进，无论是渐进式的改进还是变革式的改进。
在这个成熟度等级上，是在了解过程内在变化原因的基础上持续改进过程。
建立起组织的定量过程改进目标，作为管理过程改进的准则，并且，这些目标将适时修改，以反映不断变化的本组织的业务目标。
实际实施的过程和组织的标准过程集合都是改进活动的对象。
对那些用于处理过程变化共性原因和定量改进本组织的过程改进建议要予以识别、评价和部署。
在选择所要实施的改进时，要综合考虑具体的过程改进在达到过程改进目标方面的贡献、相应的成本和对组织的影响。
灵活的变革式的过程持续优化依赖于与组织的业务目标和价值相称的强有力的工作队伍。
通过查找问题，加快共享经验教训，可以增强组织对变化和机会的快速反映能力。
在持续的改进循环中，过程改进成为每个员工的本职工作的一部分。
对于所选择的渐进式和变革式过程改进建议要在组织里系统性地部署。
对照过程改进的定量目标对所部署的过程改进的效果进行测量和评价。
第4级与第5级之间的关键差别在于所处理的过程变化的类型。
在第4级上，过程涉及到处理特殊的变化原因并且提供统计意义上的可预见性：
虽然过程可以产生可以预计的结果，但是这种结果可能不足以达到己确定的目标。
在第5级上，过程涉及到处理变化的共性原因以及通过改变过程（即，移动过程性能的中位值）来改进过程性能（维持统计意义上的可预见性），从而达到所确定的过程改进定量目标。
2、过程域
过程域分为4类：
过程管理、项目管理、工程、支持，共24个过程域。
过程域选择思路如下：
所有企业最关注的内部管理活动是“生产活动”（工程过程），模型应当涉及“生产活动”的各个部分；
项目管理作为基础性的管理内容必须包括在内，模型应当涉及项目管理的基本内容；
作为支持、控制“生产活动”和“项目管理”的组织过程必须提供；
对于关键性的组织过程必须提供。
（1）过程管理
过程管理类包括与定义、计划、资源、实施、实现、监督、控制、验证、度量和改善过程相关的交叉项目实践的五个过程域，它们是：
组织过程定义（OPD）、组织过程焦点（OPF）、组织过程性能（OPP）、组织级改革与实施（OID）、组织培训（OT）。
成熟度等级
过程域
说明
依赖性
ML5
组织级改革和实施（OID）
选择和使用新增的和创新的改进方案，这方案应可度量地改进组织过程和技术
其中OPF和OPD是OPP的基础，OPP是OID的基础
ML4
组织过程性能（OPP）
建立和维护一个组织标准集性能的定量理解，且提供过程性能数据、基线和模型来定量地管理组织项目
ML3
组织过程焦点（OPF）
建立和维护对组织的过程和过程资产的理解，并标识、计划和实施组织的过程改进活动
组织过程定义（OPD）
建立和维护一套可使用的组织级过程资产
组织培训（OT）
培养有技能和有知识的人员，以便其能够高效地执行任务
（2）项目管理
项目管理类过程域包括与计划、监督和控制项目有关的活动的七个过程域。
它们是：
项目计划（PP）、项目监督和控制（PMC）、项目定量管理（QPM）、供应商合同管理（SAM）、风险管理（RSKM）、集成化项目管理（IPM）、集成化群组（IT）。
成熟度等级
过程域
说明
依赖性
ML4
项目定量管理（QPM）
定量地管理项目的已定义过程从而实现项目的已建立的质量和过程性能目标
PP和PMC是IPM的基础，IPM是QPM的基础
ML3
集成化项目管理（IPM）
按照一个集成的和已定义的过程建立和管理项目和项目相关人员，并建立项目的共享构想和执行该项目目标的集成化群组的群组结构
风险管理（RSKM）
在问题发生前识别出潜在的问题，以便于必要时计划并进行风险处理活动，从而降低整个生命周期中的不利影响
集成化群组（IT）
为工作产品的开发形成和维持一个集成化的组
ML2
项目计划（PP）
建立和维护定义项目活动的计划
项目监督和控制（PMC）
提供对项目进展情况的了解，当项目的性能与其计划严重偏离时，采取适当的纠正行动
供应商合同管理（SAM）
建立一个正式的合同，对项目外部供应商的产品和服务的获取进行管理
（3）工程
在项目管理和过程管理两个分组中，有些过程域相互依赖，并以其他过程域为先决条件。
工程过程分组中，缺乏这样的依赖关系。
相反，它假定所有过程域以一种集成化的方式一起运作。
在CMMI中，工程过程域将软件和系统工程过程集成到一个“面向产品”的过程域集。
这个过程域集是基本的业务过程，其它所有的过程均是为这个过程域集提供支持和改善的。
它可以应用于工程开发领域中的所有产品或服务的开发（如软件产品、硬件产品、服务或过程）。
工程类过程域包括：
需求管理（REAM）、需求开发（RD）、技术解决方案（TS）、产品集成（PI）、验证（VER）、确认（VAL）。
成熟度等级
过程域
说明
依赖性
ML3
确认（VAL）
证明工作产品和产品构件处于其计划的环境中时能完成其计划的用途
集成化
验证（VER）
保证所选的工作产品符合特定的需求
产品集成（PI）
用产品构件装配成产品，确保集成产品有正确的功能，并且交付生产
技术解决方案（TS）
针对需求来开发、设计和实施解决方案
需求开发（RD）
生产并分析客户、产品和产品构件的需求
ML2
需求管理（REAM）
管理项目产品和产品构件的需求并且标识出需求和项目计划以及工作产品之间的不一致性
（4）支持
支持过程域提供了其他CMMI过程域使用的基本过程。
另外，它们也可应用于CMMI共性实践。
总的说来，这些过程域都以项目为目标（除了过程和产品质量保证）。
不过必要时，它们可以更广泛地用于组织。
它们是：
配置管理（CM）、过程和产品质量保证（PPQA）、度量和分析（MA）、决策分析和解决方案（DAR）、因果分析和解决方案（CAR）。
成熟度等级
过程域
说明
共性实践
ML5
因果分析和解决方案（CAR）
识别发生缺陷和其他问题的原因，采取行动来预防其将来发生
与“GP5.2纠正问题的公共原因”紧密相关
ML3
决策分析和解决方案（DAR）
依据己建立的标准，使用评价已标识为可选方案的结构化方法来作出决策
ML3
度量和分析（MA）
开发和维护用以支持管理信息需要的度量能力
“GP2.2计划过程”来定义度量目的，“GP2.8监督和控制过程”包括度量性能
过程和产品质量保证（PPQA）
提供客观的监控过程和相关工作产品的人员和管理
“GP2.9客观的评价依赖性”紧密相关
配置管理（CM）
用配置标识、配置控制、配置状态统计表和配置审计等手段来建立和维护工作产品的完整性
“GP2.6管理配置”紧密相关
3、所需知识
完成上述类型工作所需要的各种专业知识和管理知识，包括软件工程、系统工程、集成化产品和过程开发以及其他学科的知识。
（1）软件工程
如在IHE标准610.12中所定义的，软件工程是将系统的、受过训练的、可以计量的方法应用到软件的开发、操作和维护中，即软件的工程应用。
软件开发的特点有时似乎比其他学科更接近于数学和艺术。
软件本质上是一个模糊的、智能的开发媒介，没有物理定理支配其行为；它既可出现奇迹，亦可呈现危险。
正因如此，当用软件操作时，应用成熟学科与过程是重要的。
（2）系统工程
INCOSE定义系统工程为“能实现成功系统的跨学科的方法和手段”。
系统工程集成所有系统相关的学科，以便系统以最有效的方式满足企业和技术需求，同时努力极小化本地优化并且最大化回报投资。
如果不考虑与之相关的各种专业学科，则很难充分理解系统工程的范围。
在“项目和系统工程管理的本质”一文中，HowardEisner列出了30个系统工程的关键元素，这些元素包括各种域，如任务工程、体系结构设计、生命周期成本计算、选择分析、技术数据管理、操作和维护、集成后勤支持以及过程重构。
（3）集成化产品和过程开发
CMMI将集成化产品和过程开发定义为在整个产品生命周期，通过必要学科的及时沟通，增加客户满意的产品开发的系统方法。
IPPD强调在贯穿整个生命周期期间所有技术及业务的相关人员的参与，这些人员包括顾客、供应商以及产品和产品相关过程的开发者，涉及的业务如测试与评价、制造、支持、培训、销售、采购、财务、合同以及处置过程。
很清楚，实现IPPD要比组织的工程过程和实践影响更多的内容。
因为它本质上是经营企业的方法，可能在根本上改变组织结构和调整领导层行为。
（4）其他学科
CMMI的长期目的是为今后把其他学科（如获取和安全性）添加到模型中奠定基础。
为了促进现在的和将来的模型集成，CMMI产品开发群组建立了一个自动的、可扩展的框架，其中可以放入模型构件、培训资料构件以及评估资料。
在已定义的规则控制下，更多的可能学科将加入该框架中。
四、CMMI的内容
1、内容分类
作为一个管理模型，CMMI提供了一种手段，把重要的和有关的管理知识进行分类，即采用术语“Required”（必需的）、“Expected”（期望的）、“Informative”（提供信息的）来衡量所提供资料的相对重要性。
分类
说明
“Required”（必需的）
最重要的部分，确认必要条件，是进行评估的基础
“Expected”（期望的）
在某些情况下，有些组织部一定按照这个执行；但这些资料主要是一些最佳实践，在过程改进中起主要作用
“Informative”（提供信息的）
模型中最多的部分，可用于说明和培训
最重要的资料是“需要的”，这些项是模型的基础，是了解过程改进需要什么及确定认证是否符合模型的基础。
唯一需要的CMMI模型构件是“目标”。
软件组织通过策划和实施软件过程来达到这些目标。
对于实现给定过程域来说，“需要的”构件是最重要的模型构件。
在贯标中，用它们来衡量过程域的要求是否得到满足，是衡量组织的软件能力成熟程度的尺度。
为了叙述方便，模型中给每个目标设定了一个名称、相应的名称标识符以及目标陈述。
第二重要的是“期望的”资料，这些项也许不是十分重要的，在某些情况下可能不会出现在成功使用模型的组织中。
不过，期望的资料在过程改进中却起主要作用。
这样的项是达到需要的构件的强指示器。
CMMI模型唯一期望的构件是“实践”的陈述。
该构件描述的是，一个组织为了达到某一组特定目标和共性目标一般要实施哪些实践
升级会员 