CMMI2.0简介与模型研究

CMMI2.0简介与模型研究黄河敏捷CMMI2.0的变化CMMI概述实践域简介CMMI概述01CMM软件能力成熟度模型CapabilityMaturityModel的缩写形式，80年代末，美国国防部委托SEI（卡耐基梅隆大学）开发的一套标准，用以对软件承包商的开发能力进行评估CMMI1.0能力成熟度模型集成CapabilityMaturityModelIntegration90年代末，SEI整合CMM的三个模型，发布CMMI1.0版本，Integration的用意就是解决不同CMM模型的重复性、复杂性问题，并对CMM家族标准进行统一CMMI2.02018年CMMI发布2.0版本，做了较大改动，也引入很多敏捷开发实践强调商业目标对过程改进的驱动作用，这是2.0的一个基本思想；强调通过定量的数据说明组织能力的变化；强调高层参与过程改进的重要性；员工的行为要固化为工作习惯，体系规范的执行深入到每个人的意识中。等级名称定义1级初始级描述满足实践域意图的初步方法的基本实践；没有一套完整实践来满足实践域的全部意图2级已管理级基于第1级实践；简单但完整的一组实践，能够满足实践域的全部意图；不需要使用组织资产3级已定义级基于第2级实践；采用组织标准并根据独特的项目和工作特征进行裁剪；项目使用和贡献组织资产4级量化管理级基于第3级实践；使用统计和其它量化技术来检测、完善或预测焦点领域，以实现质量与过程性能目标5级优化管理级基于第4级实践；使用统计与其他量化技术来优化质量与过程性能目标的实现情况CMMI2.0能力等级类型能力域简称实践域简称实践个数Level1Level2Level3Level4Level5行动确保质量ENQ同行评审PR6141

过程质量保证PQA6141

需求开发和管理RDM14167

验证和确认VV7232

设计和开发产品EDP产品集成PI10163

技术解决方案TS10136

选择和管理供应商SMS供应商协议管理SAM10342

管理策划和管理工作PMW估算EST6132

监视和控制MC10244

策划Plan152841

管理业务弹性MBR风险与机会管理ROM8125

管理员工MWF组织级培训OT9126

实现支持实施SI原因分析和解决CAR1112521配置管理CM716

决策分析和解决DAR825

提高提高性能IMP管理性能与度量MPM2226653过程资产开发PAD11137

过程管理PM123261

维持习惯性和持久性SHP治理GOV81421

实施基础条件II6123

CMMIV2.0模型CMMI2.0的变化02进一步强调商业目标对过程改进的驱动作用CMMIV1.3中只是在5级强调围绕商业目标进行过程改进，但是在2.0无论哪个级别都强调围绕商业目标进行改进，这是2.0的基本思想，也是过程改进的本质。要通过性能变化衡量改进效果是否围绕商业目标进行改进，要体现在组织级的能力变化上，并通过度量数据体现出来，通过定量的数据说明组织级能力的变化高层经理对过程改进参与情况的具体化描述高层需要参与的活动提炼为GOV实践域，强调高层参与过程改进的重要性员工的行为要固化为工作习惯体系规范的执行深入到每个人的意识中，即使面临工期压力也要坚持按照过程要求执行过程灵活映射到模型CMMI模型定义了whattodo，而Howtodo是由企业自己去定义的。Howtodo可以有很多不同做法，企业可以灵活定义随机抽样检查有助于过程固化参与评估的项目都应该是随机抽样的，目的是让企业真正能够将自己的体系推广到每个项目一、思想的变化过程域修改为实践域，简写仍然是PA原先过程中的实践之间是有先后顺序关系的，但其实CMMI模型中的实践是没有顺序关系的，修改为实践域可避免这个误解新增能力域的概念（CA）针对组织要解决的特定问题的一组相关实践域，即针对要解决的问题的一种概述过程域类型修改为能力域类型CMMI1.3连续式将过程域分为：工程类、项目管理、支持类、过程管理。CMMI2.0将过程域改为能力域，分为四种类型：行动、管理、实现、提高。新增视图（view）的概念视图是由最终用户选择的或CMMI研究所预定义的、对模型的最终用户很重要的一组实践域级实践组的集合SAM和CMMI1.3版本一样，是唯一一个可以排除在外的PA二、关键术语的变化行动Doing确保质量设计和开发产品交付与管理服务选择和管理供应商管理Managing策划和管理工作管理业务弹性管理员工实现Enabling支持实施提高Improving提高性能维持习惯性和持久性能力域采用平实的语言描述2.0总体内容更简化，语言更通俗易懂整合了PeopleCMM等多个模型除1.3包含的开发、服务、采购三个系列外，增加人力资源管理模型不再区分特定实践域共性实践所有共性实践整合到2个PA即GOV与II，GOV描述了高层管理者在过程改进、过程实施中需要做的活动。II描述了过程改进、过程实施所需要的基础设施。这2个PA都是为了确保过程规范能够在组织中固化为习惯。三、结构与描述方式的变化不再对实践域划分等级，而是对实践划分等级这个变化更符合实际、也更合理。比如对于MPM（原MA）而言，原先只要求4级的企业才要进行数据度量管理，现在即使是2、3级的企业也要求做数据度量，只是方法手段上有差别在20个实践域中，只有CM仅包含1、2级的实践，而GOV、PLAN、PCM、SAM四个过程域包含1、2、3、4级的实践，CAR与MPM包含5个等级的实践，其它实践域都是包含1、2、3级的实践2级实践累计79条，3级实践累计73条，4级实践累计10条，5级实践累计4条三、结构与描述方式的变化实践域名称实践个数Level1Level2Level3Level4Level5CAR原因分析与解决方案1112521CM配置管理716

DAR决策分析与解决方案8251

EST估算6132

GOV治理81421

II实施设施6123

MPM管理性能与度量元2226653MC监督和控制10244

OT组织级培训9126

PR同行评审6141

PLAN策划152841

PAD过程资产开发11137

PCM过程管理123261

PQA过程质量保证6141

PI产品集成10163

RDM需求开发与管理14167

RSK风险和机会管理8125

SAM供应商合同管理10342

TS技术解决方案10136

VV验证与确认7232

合计

196297973104CMMIDEVV2.0实践统计CMMIDEVV1.3有22个过程域，而CMMIDEVV2.0有20个实践域。其中有些实践域保留了原来的名字，如CAR、CM、DAR、OT、PI、SAM等；有些实践域名字微调，如MC、PLAN|PAD、RSK、PQA等；有些实践域是新增或者剥离出来的，如EST，PR、GOV、II等；有些实践域则是由原来的多个PA合并而来，如MPM、RDM、VV具体可见下表四、过程域的变化CMMIDEV2.0PA与V1.3对比CMMI2.0实践域CMMI1.3过程域备注CARCARCMCMDARDAREST新增PA，从PP中剥离出来GOV定义公司高层经理的活动，来自于V1.3的共性实践II来自V1.3的共性实践MPMMA所有定量管理的时间都合并到MPM中QPMOPPMCOPMIPM中有关跟踪的实践汇总到MC，如管理关键依赖、环境等。里程碑评审不再出现在实践名字中PMCOTOTPR新增PA，从VER中剥离出来PLANPP估算的实践剥离为一个单独的PA，IPM中与策划有关的实践汇总到本PA

数据管理的时间剥离到CM中，风险管理的实践剥离到RSK中PADOPD名称修改，删除了建立团队运作规则指南的实践PCMOPF名称修改，有些实践来自于OPMPQAPPQA名称修改PIPIRDMRD所有的需求工程实践合并到RDMREQMRSKRSKM增加了机会管理，RSK是风险和机会管理SAMSAMTSTSVVVER合并为VV，同行评审独立为一个PAVALIPMIPM拆分到PLAN和MC中类型能力域简称实践域简称

价值解释行动确保质量ENQ同行评审PR通过专家阅读文档、代码发现缺陷，是在实现之前发现缺陷的最有效手段过程质量保证PQA过程是历史经验教训的总结，是对这些历史财富的规范化、标准化，为了避免错误的重现。质量保证是监督这些历史经验的落地实施，让成功得以重复。

质量保证的关键是要客观，独立的团队，依法办事需求开发和管理RDM包含需求获取、需求分析、需求描述、需求验证与确认、需求管理等五个需求管理工程的活动验证和确认VV验证与确认是互补的，缺一不可

验证：强调做法（中间过程）是否正确，与产品需求做对比，需求评审、代码评审、系统测试等都是验证；

确认：强调结果是否正确，与最初的原始需求对比，用户评审、用户验收测试属于确认设计和开发产品EDP产品集成PI把不同部件集成在一起，包含集成策略的制定、集成准备、集成、集成后的验证与确认、以及交付的活动

接口设计、接口实现，代码持续集成、每日构建、手工集成、自动化集成技术解决方案TS包含技术路线选择、概要设计、详细设计、实现、技术文档编写等活动选择和管理供应商SMS供应商协议管理SAM包括外包或者采购产品或服务的行为，若不涉及可裁剪管理策划和管理工作PMW估算EST规模、工作量、工期、成本等都要做估算，估算是承诺的基础，充分沟通是估算的基础。估算是逐步细化的，并非在项目初期就估算一次。策划Plan项目计划，与估算一般是同步进行的，也是要逐步细化，随着项目进展调整计划监视和控制MC对照计划监督与管理计划的执行情况管理业务弹性MBR风险与机会管理ROM风险是意料之外的坏事，机会是意料之外的好事，风险是惊吓，机会是惊喜，我们要趋利避害管理员工MWF组织级培训OT对人的能力的培养，将经验教训传播给更多人了解实现支持实施SI原因分析和解决CAR对关键事件、问题识别原因，并采取纠正或预发措施，好事和坏事都可以做CAR配置管理CM通过配置标识、版本控制、版本管理、基线管理和配置审计来管理工作产品的完整性决策分析和解决DAR就是做选择题，某个需求可以有多个技术方案时，需要对技术方案做决策分析，以便选出最合理的方案提高提高性能IMP管理性能与度量MPM所有的度量都是要围绕商业目标，度量活动要有价值，所以并不是有什么就度量什么，要有度量目标，通过度量能帮助解决管理问题过程资产开发PAD与过程有关的组织级方针、流程描述、裁剪指南、检查单、模版、规程定义、培训材料过程管理PM用PDCA循环对过程进行持续改进，维持习惯性和持久性SHP治理GOV过程改进是一把手工程，高层管理者一定要参与，包括识别开展工作的要点、组织级方针、提供资源、监督过程等实施基础设施II要有充足的基础设施，包括资源、资金、培训、流程定义、经验教训总结等CMMI2.0实践域价值实践域简介03列表实践描述解释1.1记录需求需求文档化2.1引导干系人的需要、期望、约束、接口启发客户提出自己真实需求，引导的手段，比如访谈、原型、问卷调查等。2.2转换干系人的需求、期望、约束为排列了优先级的需求需求要划分优先级2.3和需求提供者关于需求的含义达成一致理解需求理解的一致性，采用面对面沟通、原型展示、需求评审等手段达成一致2.4从工作投入的参与者处获得他们对需求可实现的承诺实现需求的人要对需求理解一致，认为技术上可实现，且工期是有保证的2.5建立、记录、维护需求与活动、工作产品之间的双向可跟踪项确保需求被分配到人、被设计、被实现、被测试，从需求能跟踪到代码，也能从代码跟踪到需求2.6确保计划、活动和工作产品与需求保持一致通过各种评审、测试、验证与确认活动，确保计划、设计、代码、用例等与需求一致，当发生需求变更时也要维持相关配套文档、活动与需求的一致性3.1根据组织级的过程，开发和保持更新解决方案和其构建需求实际上就是需求规格，就是对需求的详细定义，需求变更时要执行需变更影响分析、评审、许可3.2定义操作概念和场景包含产品全生命周期的场景，及用户在各种场景下如何使用产品的描述3.3分配待实现的需求把整体的系统需求分配给不同的模块实现3.4识别、定义、保持更新接口与连接需求接口需求包含外部接口和内部接口3.5确保需求是必要的和充分的要求需求是不多不少的，刚刚好，不要忽视依赖项3.6平衡干系人的需要和约束平衡的前提是需求划分了优先级3.7确认需求以确保最终的解决方案可以在目标环境中运行此确认的是需求而不是最终产品，可以通过评审、模拟或仿真来实现1.需求开发与管理RDM需求在CMMI模型中的分类需要：必须的、不可裁剪的需求期望：最好能实现、越多越好、可以裁减的需求约束：实现需要与期望的限制条件，可能是技术的、管理的、环境的限制接口或连接：与其他产品或系统之间的衔接关系，任何一个系统都不是孤立存在的划分需求优先级的方法卡诺模型：把需求划分为基本需求、期望需求、兴奋性需求ROI方法：让客户或客户代表对每个需求的业务价值给出相对的分值,让开发团队针对每个需求给出开发成本的相对分值，二者相除得到相对的投入产出比，然后排序得出优先级VSDT方法：通过分析需求的价值、风险与不确定性、延期交付成本、技术成本等四个要素，衡量出最终的优先级1.需求开发与管理RDM列表实践描述解释1.1评审工作产品并记录问题做了评审，并记录问题2.1制定并保持更新用以准备和执行同行评审的规程和支持材料定义具体的同行评审的方法、规程，包括检查单、评审记录表等2.2选择待同行评审的工作产品并非所有工作产品都要做评审，要制定评审的计划，识别出要评审的输出件、评审方法、评审参与的角色、评审时机2.3采用已建立的规程，对选中的工作产品准备和实施同行评审包括评审通知、评审资料分发、准备会议室等2.4解决同行评审中发现的问题记录、跟进、解决同行评审时发现的问题3.1分析同行评审的结果可以分析缺陷密度、评审速度、缺陷类型的分布等2.同行评审PR3.过程质量保证PQAPPQA（ProcessandProductQualityAssurance）简化而来，实际包含过程与产品质量保证过程是历史经验教训的总结，是对历史财富的规范化、标准化，是为了避免错误的重现。质量保证是监督这些历史经验的落地执行，能够让成功得以重复。质量保证的关键是要客观，如何确保客观性呢？独立的团队，不能自己检查自己依法办事，对照标准规范，而不是凭经验QA人员本身的职业素养组织级要建立质量保证的文化，各级管理者要尊重公司的标准规范，而不是法外施恩，管理者违反标准规范列表实践描述解释1.1识别和处理过程和工作产品的问题有基本的识别问题的活动2.1基于历史的质量数据，制定、保持更新和遵从质量保证方法和计划充分挖掘历史数据的价值，在开始新项目前制定质量保证方法和计划。质量保证计划包含的内容通常有：质量保证人员、需要检查的过程或活动、需检查的工作产品、抽样检查的比例、检查时间、检查方法、问题报告渠道2.2在整个工作期间，对照文档化的过程，客观评价选中的、已执行的过程和工作产品参照标准化的规范，检查各项活动、输出件是否按照规范执行有几个点：检查时要依据文档化的标准规范；并非所有文档和过程都要检查，可以抽样；要有检查单。检查方法：查文档有无、是否符合模版；旁观活动的执行；事后访谈过程的执行者。2.3交流质量问题和不符合问题，并确保他们得到解决首先和不符合问题的当事人沟通问题，若当事人拒绝问题或不按时解决，可以逐级上报；若双方有异议的问题比较多，应反思是规范本身不合理，还是公司缺少质量保证的文化；不符合问题要进行横展分析，看看其他项目是否有类似问题；不符合项要跟踪记录下来。2.4记录并使用质量保证活动的结果质量保证活动记录包括：质量保证计划、不符合项记录、不符合项的统计分析报告、质量保证活动总结报告、度量数据、经验教训总结等，这些记录要保留下来，补充到组织过程资产库，便于将来项目借鉴3.1在质量保证活动期间，识别和记录改进机会多与项目组打交道，可以听到、看到更多问题，识别改进机会；识别的机会要提交到EPG，确认是否纳入组织级改进。尤其是发生频率比较高的不符合项要进行反思，分析是否标准规范不合理，也可能要加强标准规范的培训推广力度。4.过程质量保证PQA5.风险与机会管理RSK风险是意料之外的坏事，机会是意料之外的好事，风险是惊吓，机会是惊喜。风险与机会都是不一定发生的，要趋利避害。基本概念风险与机会是事先的，不是事后的，事后的是事件管理，问题管理要尽早报告风险，处理风险风险与机会在项目或任务执行过程中是持续的，是贯穿始终的对风险与机会的管理，要平衡成本与收益，不是所有的风险或机会都是先采取措施风险有三个基本属性：影响的严重性、发生的可能性、时间的紧迫性列表实践描述解释1.1识别、记录风险或机会，并保持更新识别可以采用分类法、头脑风暴法、调查问卷、检查单。2.1分析所识别的风险或机会分析：影响的严重性、发生的概率、紧迫性。分析的结果是为了划分优先级2.2监督识别的风险或机会并和受影响的干系人沟通状态包含两层含义：一是监督风险或机会状态的变化，此时也可以识别出新的风险或机会，而是要和相关人员沟通状态的变化3.1识别并使用风险或机会分类分类目的是为了把相近的风险合并应对措施，节约成本，通常按风险或机会的来源进行分类。3.2为风险或机会的分析和解决、定义和使用参数对风险或机会的三个参数进行统一定义：影响的严重性：何谓高中低；发生的可能性：按概率划分几个等级？时间的紧迫性：远中近如何划分3.3制定和保持更新风险或机会管理策略管理策略包括责任分配、时机、方法、三个参数的统一定义、应对措施的启动条件、常见风险或机会的应对措施、跟踪频率、采集哪些度量数据等3.4制定和保持更新风险或机会管理计划缓解措施：用来减低风险发生的概率或延迟风险发生的措施应急措施：当风险发生时用来降低风险危害的措施创造机会的计划：没有机会创造机会，增加其发生概率应对计划：一旦机会来了，如何充分使其利益最大化3.5通过实施已计划的风险或机会来管理风险或机会对照上述计划落实哪些措施5.风险与机会管理RSK6.配置管理CMCMMIDEV2.0的20个PA中，CM是唯一一个没有3级实践的PA配置管理：通过配置标识、版本控制、版本管理、基线管理和配置审计来管理工作产品的完整性配置项：配置管理的对象，包括各种文档资料、代码等工作产品基线：经过正式认可，作为后续开发基础的一组配置项，其变更需要经过正式的批准配置控制委员会：对配置项的变更进行评审认可的一个小组配置审计：检查基线中的配置项版本是否正确一致、位置是否正确、是否与其功能说明一致列表实践描述解释1.1执行版本控制文档、代码等配置项要执行版本管理2.1识别置于配置管理之下的配置项配置项包含交付给客户的、不交付给客户的文档、代码2.2建立、保持更新并使用配置和变更管理系统配置和变更管理系统包含工具、规程、物理的存储介质、实际的配置项等，常用工具有：SVN、Git、Jira、Confluence等。要定义清楚：目录结构、权限分配、备份机制等2.3建立或发布内部使用或交付给客户的基线基线可以采用按配置项命名，比如：需求基线、设计基线、产品基线等2.4管理配置项的变更配置项的变更需要经过审批，要识别变更影响范围，包括对技术、管理、人员的影响。对技术的影响包括需求、设计、代码、用例，管理的影响包括工作量、工期、质量、风险，人员的影响包括变更要通知到哪些人2.5建立、保持更新并使用描述了配置项的记录配置项的变更要做记录，包括变更提出时间、提出人、实施人、变更内容、变更原因、验证人、验证结论等2.6执行配置审计以维持配置基线、变更和配置管理系统的完整性定期执行配置审计，以确保配置库中的配置项不多不少、版本一致、命名规范、位置正确、内容符合要求、记录完备6.配置管理CM7.原因分析与解决方案CAR对选中的现象识别原因，并采取纠正措施或预防措施，可以理解为复盘、质量回溯组织内的好事和坏事都可以做CAR，并非仅仅是对坏事做CAR做原因分析时，要从现象到数据，再到原因，原因有浅层次的原因，也有深层次的根本原因，对直接原因采取纠正措施，对根本原因采取预防措施。列表实践描述解释1.1识别并处理选中现象的原因2.1选择要分析的现象原因分析是有成本的，并非所有事情都要进行正式的原因分析，要挑选值得分析的现象做分析，一般是重大BUG、重大质量事件、客户投诉2.2分析并采取措施采用5why法、鱼骨图、头脑风暴等方法进行原因分析，输出纠正与预防措施3.1遵从组织级的流程确定选中现象的根因组织级要定义根因分析的流程。什么是根因？当这个原因解决后，这个问题是否不会再发生？类似的问题不会再发生？3.2提出行动建议以处理识别的根因针对根本原因提出预防措施3.3实施选中的行动建议实施预防措施3.4记录根因分析和解决方案的数据记录过程中的相关数据3.5为已经证明有效的变更提出改进建议验证预防措施成功后，修改组织级体系流程或推广到其它项目组4.1采用统计和其它量化技术对选中的现象执行根因分析进行根因分析时，要采用统计技术，如：相关性