下载文档原格式
一：CMMI简介1.1 CMMI发展简史CMMI（Capability Maturity Model Integration，能力成熟度模型集成）是用于产品开发（或服务）的过程改进成熟度模型。
CMMI的最佳实践覆盖了产品构思、交付和维护的整个生命周期。
1981年，美国卡内基梅隆大学软件工程研究所（SEI），应美国联邦政府的要求开发的一种用于评价软件承包商能力并帮助其改善质量的方法。
Watts Humphrey将成熟框架带到了SEI并增加了成熟度等级的概念，将这些原理应用于软件开发，发展成为软件过程成熟度框架，它提供了一个评估软件开发过程的管理以及工程能力的标准。
1987年，基于Watts Humphery 等人的工作，SEI的Mark Pauk 等人建立了第一个CMM模型，即软件CMM。
1993年，SEI推出了CMM 1.1，这是目前世界上应用最广泛的CMM 版本。
十几年来CMM的改进工作一直不断地进行，相继有多个学科领域的CMM模型问世：SE-CMM, SW-CMM, IPD-CMM等。
美国国防采购与技术办公室领导了一个由政府、企业和SEI的代表组成的团队开始开发一个CMM模型的集成框架，即CMMI。
CMMI的基础源模型包括：软件CMM 2.0版本，EIA-731系统工程，以及IPD CMM (IPD) 0.98a版本。
2002年1月CMMI 1.1版本正式发布，并立即被广泛采用。
CMMI 1.2的三种模型·2·2006年8月，面向开发的CMMI（CMMI-DEV 1.2）版本正式发布。
为了适应更加广泛的应用，SEI 计划今后发布另外二种模型，分别是面向服务的CMMI（CMMI-SVC 1.2）版本和面向采购的CMMI（CMMI-ACQ 1.2）。
1.2 CMMI的过程域过程域（Process Area）是同属于某个领域而彼此相关的实践集合，当这些实践共同执行时，可以达到该领域过程改进的目标。
CMMI评估流程CMMI（Capability Maturity Model Integration，能力成熟度模型集成）是一种用于评估和改进组织软件和系统工程能力的方法。
CMMI评估流程是指按照CMMI 模型的要求进行评估的具体步骤和方法。
本文将详细介绍CMMI评估流程的标准格式。
一、背景介绍在开始介绍CMMI评估流程之前，我们先来了解一下CMMI的背景和基本概念。
CMMI是由美国软件工程协会（SEI）于1991年提出的，旨在帮助组织提高软件和系统工程能力，从而提高产品质量和工程效率。
CMMI模型分为5个成熟度级别，分别是初始级、可管理级、已定义级、已量化级和优化级。
每个级别都有一系列的过程区域，用于描述组织在该级别下应该具备的能力。
二、CMMI评估流程概述CMMI评估流程是指按照CMMI模型要求进行评估的具体步骤和方法。
评估的目的是确定组织在CMMI模型中的成熟度级别，以及在各个过程区域中的能力水平。
评估结果可以帮助组织了解当前的能力状况，找出改进的方向，并制定改进计划。
三、CMMI评估流程步骤1. 确定评估目标和范围在进行CMMI评估之前，需要明确评估的目标和范围。
评估目标可以是确定组织的成熟度级别，也可以是评估某个特定的过程区域的能力水平。
评估范围可以是整个组织，也可以是某个部门或项目。
2. 收集评估所需的信息和数据评估需要收集组织的相关信息和数据，包括组织的文档、流程描述、工作产品、员工培训记录等。
这些信息和数据将用于评估组织在CMMI模型中的能力水平。
3. 进行现场访谈和观察评估团队将与组织的员工进行面对面的访谈，了解组织的工作流程、实践和经验。
同时，评估团队还会观察组织的工作环境和工作产品，以获取更全面的评估数据。
4. 分析和评估数据评估团队将对收集到的信息和数据进行分析和评估。
他们将根据CMMI模型的要求，对组织在各个过程区域中的能力进行评估，并综合得出组织的成熟度级别。
5. 编写评估报告评估团队将根据评估结果，编写评估报告。
cmmi解析全称是即软件能力成熟度模型集成，是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的，其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件其所依据的想法是:只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件开发中的困难为改进一个组织的各种过程提供了一个单一的集成化框架，新的集成模型框架消除了各个模型的不一致性，减少了模型间的重复，增加透明度和理解，建立了一个自动的、可扩展的框架因而能够从总体上改进组织的质量和效率主要关注点就是成本效益、明确重点、过程集中和灵活性四个方面分5个级别1，完成级在完成级水平上，企业对项目的目标与要做的努力很清晰，项目的目标得以实现但是由于任务的完成带有很大的偶然性，企业无法保证在实施同类项目的时候仍然能够完成任务企业在一级上的项目实施对实施人员有很大的依赖性 2，管理级在管理级水平上，企业在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制，并与上级单位对项目与流程进行审查企业在二级水平上体现了对项目的一系列的管理程序这一系列的管理手段排除了企业在一级时完成任务的随机性，保证了企业的所有项目实施都会得到成功3，定义级在定义级水平上，企业不仅能够对项目的实施有一整套的管理措施，并保障项目的完成;而且，企业能够根据自身的特殊情况以及自己的标准流程，将这套管理体系与流程予以制度化这样，企业不仅能够在同类的项目上升到成功的实施，在不同类的项目上一样能够得到成功的实施科学的管理成为企业的一种文化，企业的组织财富4，量化管理级在量化管理级水平上，企业的项目管理不仅形成了一种制度，而且要实现数字化的管理对管理流程要做到量化与数字化通过量化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上的波动5，优化级在优化级水平上，企业的项目管理达到了最高的境界企业不仅能够通过信息手段与数字化手段来实现对项目的管理，而且能够充分利用信息资料，对企业在项目实施的过程中可能出现的次品予以预防能够主动地改善流程，运用新技术，实现流程的优化企业在实施的时候，路要一步一步地走一般地讲，应该先从二级入手在管理上下功夫争取最终实现的第五级历史背景的在XX年发布了过程成熟度模型( ) XX年发布了软件的能力成熟度模型SW-()可以视为的领域的起点自此以后，人们开发了各种模型，譬如美国联邦航空管理局()开发了-，集成了其三个模型的所有特征和实践XX年正式发布 XX年12月发布XX年全面替换目前普遍在使用的是的标准，正在审批阶段的是的标准，它们改进的主要方向是完善定义以及可实施性 (能力成熟度模型综合) 涵盖以下几个方面：该模型提供了一套可供公众使用的准则；这些准则描述那些成功地实施了过程改进的组织的特性该模型用“软件能力成熟度”来衡量这种综合能力；阶段式表示的五个成熟度级别初始级–已管理级–已定义级–量化管理级 - 持续优化级 -每个级别都有不同的 (PA，某一个方面)，过程域，下面是各个级别所的过程域： 1级- 初始级2级- 已管理级，涵盖了7个PA配置管理、过程与产品质量保证、度量与分析、供应商协议管理、项目监督与控制、项目计划需求管理3级-已定义级涵盖了11个PA决策分析与解决方案、确认、验证、产品集成、技术解决方案、需求开发、风险管理、集成项目管理、组织级培训、组织过程定义、组织过程焦点 4级-量化管理级，涵盖了2个PA 组织过程性能、定量项目管理 5级-持续优化级，涵盖了2个PA组织革新与部署、原因分析与解决方案对于常见的疑问是：不通过2级能过3级吗？3级的企业研发总体成本比2级的要高？怎样才算通过了某个级别的评估呢？评估与审核有何不同？很多公司说自己整体过了多少级，什么叫“整体过”呢？我们自己的公司处于第几级？对于1级，未设定任何标准在各个级别有详细的标准要通过高级别的评估，必须要满足其低级别的所有标准如果该级别的全部PA达到要求了，就认为该级别达到了如果判断PA达到要求呢？每个PA包含几个目标()如果这几个目标都达到要求了，就认为该PA达到要求了如果判断达到要求呢？每个包含几个实践()每个实践达到要求了，就认为该达到要求了评估一个企业是否达到某级别的标准，评估的关键就是每个的实际情况根据评估办法的严谨程度，有以下办法：C、 B、 A(正式评估用的办法）某企业通过了某某级别的评估，意味着什么？评估是对企业准备的几个评估项目按照的标准进行检查企业可以准备任意数量的项目，评估的项目是企业自己指定的通过评估，只代表评估小组认为参加评估的几个项目达到了某个级别的标准通过评估，不代表这个企业其他项目也达到了要求，也不代表该企业后续项目也会达到这个标准企业的商业目标加快进度-- 相同的项目规模，需要更少的时间完成减少成本-- 相同的项目规模，需要更少的成本完成提高质量-- 相同投入情况下，质量更高终极目标：更高的利润！企业商业目标与的关系是为了支持企业的商业目标的不是用来增加管理成本而不提高收益的更高级别的企业，它的效能应该更高效能=收益/投入吃饭“例子“项目”需求如下： -->某个时间，公司进行聚餐活动-->请你组织这次活动，目的是用合理的经费让大家高高兴兴地吃一顿用1-5级如何管理？第1级：初始级第2级：已管理级第3级：已定义级第4级：量化管理级第5级：持续优化级1:初始级-->不用做什么计划，提前一点订好座位-->当天下班大家一哄而去-->现场点菜，然后大吃一顿结果变为：-->定不到位？-->菜不合大家口味-->经费超出预算-->大家心情变得很沮丧问题：有没有可能取得比较好的效果呢？这样做会有什么结果？-->大家吃的满意？-->预算控制得好-->老板高兴真的能够这样吗？ 2级做法的一些遗留问题？不需要进行风险管理吗?用什么方法调查大家喜欢吃什么菜式呢？有指南就好了？如何组织聚餐活动是不是有个指导？或者有成功经验可供参考？ 3:已定义级经过一段时间积累，以下活动都有明确的指导文档：-->如何写计划-->如何组织吃饭现场活动-->如何确定餐单对于确定餐单、选定酒水供应商方面采用决策分析的办法进行风险管理建立了相应的培训制度另外，为了让组织聚餐活动越做越好，成立了专门的来维护文档这样做的结果？？这次活动的几率大大提高了但谁能拍胸口说：一定能够成功？ 3级遗留的问题感觉成功机会提高了很多，但没有一个底？最好能有个数字能说明问题 4: 定量管理级积累了大量聚餐活动的、数据积累了大量的聚餐满意度数据当前活动反应聚餐活动能力的数据、满意度等在一定范围内波动根据当前、，可预测聚餐活动的最终成本通过这些数据对活动进行监控4的特点：组织过程性能根据历史数据，算出了性能基线、性能模型定量项目管理聚餐活动进行时，利用性能基线、性能模型进行定量管理这样做会有什么结果？聚餐活动进展情况了如指掌比较准确的估计到最后的结果成功的几率大大提高 4带来的想象哇！4已经非常厉害了更厉害的5会是怎样呢？猜猜？ 5: 持续优化级如何持续改进？-->原因分析-->采用新技术-->公司定下新的目标 5 之原因分析通过数据，我们发现由A君组织的聚餐活动，满意度总能在基线范围内但由B君组织时，满意度异常的高，超出了基线上限于是我们进行了原因分析，发现了B君进行抽奖活动之前，做了个调查，知道哦啊每个人最想要什么故抽奖活动进行得很出色，满意度就高了 5之原因分析抽奖活动之前先进行调查这个工作，在过程文档里面并没有规定的，是B君的特殊做法异常高兴，把B君的做法写入过程中于是全部人都按照这个做法去做了，结果满意度性能基线上升了对于一些特殊问题、特殊情况进行分析，可以得到改进过程的机会对过程进行改进后，我们的性能会提高5之采用新技术出现了这样的一些问题：发现难以统计到场的人员，经常去问很多人不知道如何去就餐地点为了解决这个问题，采用如下新技术：每个人配一台和，里面有地图，活动组织者用笔记本电脑能见到各位位置采用新技术后，大家准时出席率提高，并且满意率也提高 5之公司定下新的目标预算的偏差率当前值是-20%到20%，老板觉得很不满意，期望改进为-10%到10% 就非常紧张，投入大量人力物力分析如何改进发现导致预算偏差大的地方主要在于酒水采购方面，供应商的价钱浮动太厉害定下改进计划，修改了采购方面的过程，对供应商的选择加强了标准在某次聚餐中施行新的采购过程，结果发现成本偏差果然控制在-10%到10%范围内分析试运行结果后，把过程正式推行，最终满足了老板的要求 5的两个PA 原因分析组织革新与部署技术改进：公司定下新目标通过这个吃饭的分析，能否感受到管理模型的魅力么？重温一下可爱的5个阶段：第1级：初始级第2级：已管理级第3级：已定义级第4级：量化管理级第5级：持续优化级QA职责 QA工程师岗位职责是：一、质量管理体系：1、QA工程师编制项目部质量管理体系策划书，经领导审批后下发执行2、QA工程师根据施工计划提出年度、月度监督检查计划计划内容要依据质量管理体系文件，并每年监督检查要覆盖项目部所有部门和体系涉及的所有要素3、现场监督检查是随机的、不定时的，QA工程师对监督发现的不符合或缺陷做出记录，并将不符合或缺陷按重要性的不同以书面或口头形式通知责任方目的在于向责任方提出改进工作的建议，提醒责任方引起重视，纠正不符合和缺陷4、巡检主要针对单位工程开工、施工过程中、三级验收及监理公司参与的四级验收之前，QA工程师提前按照程序文件要求对文件包资料进行检查，避免在监理公司验收时提出不符合，同时保证施工与资料同步，避免后补资料5、QA工程师汇总各类管理体系月度、年度监督检查情况，出具报告，报公司企业策划部，并对有关问题提出纠正预防措施，监督实施；6、QA工程师汇总各部门年度体系培训计划，经人力资源管理批准后，各部门组织实施7、QA工程师配合质监专工参与质监中心站活动，并依据有关要求整理迎检资料，对各部门的资料提前组织检查8、QA工程师与各部门保持密切联系，及时解决体系运行中接口不协调的问题，如无法解决可提交管理评审输入9、QA工程师配合好与业主及监理公司进行的各种质保监督检查活动，及时组织对检查出的质量问题进行整改，并采取纠正或预防措施10、QA工程师与各专业工程师、单项工程师密切配合，抓好不合格品的控制出现不合格品，要及时进行原因分析并做好统计记录工作，采取有效的纠正预防措施，杜绝类似质量问题再发生11、QA工程师根据每年公司质量体系审核、日常监督检查、质量评定情况、管理评审以及顾客反映的有关问题，进行全面的汇总统计分析，找出质量体系运行的薄弱环节以书面报告的形式反馈相应的部门，并由其制订预防措施和质量改进目标，实现质量改进 12、QA工程师配合好公司组织的质量管理体系内审，并对出现的不符合组织整改13、QA工程师配合好由认证单位组织的外审，并对出现的不符合组织整改 14、QA 工程师对有关招标文件从体系考虑角度进行审查 15、QA工程师每周不少于一次到现场检查16、QA工程师每月不定期对重要进货物资、监视设备、文件包等资料进行抽检二、计量管理体系：1、QA工程师组织项目部有关人员学习贯彻执行国家计量法律、法规、法令及公司程序文件2、QA工程师组织建立项目部量值溯源图3、QA工程师建立项目部管理人员网络图4、QA工程师负责项目部管理部门使用检测设备的日常计量管理工作5、QA工程师负责项目部计量检测体系的运行及日常的监督6、QA工程师负责项目部计量管理信息的上传下达7、QA工程师负责建立项目部计量检测设备台帐，并上报企业策划部 8、QA工程师负责项目部计量检测设备的送检工作 9、QA工程师负责批准各部门检测设备需用计划的提出10、QA工程师负责检测设备的封存、报废、回收等管理工作11、QA工程师配合人力资源做好项目部员工的计量教育、培训工作，不断更新职工的计量知识，提高员工的计量意识12、QA工程师配合好公司组织的计量管理体系内审，并对出现的不符合组织整改13、QA工程师配合好由*机构组织的外审，并对出现的不符合组织整改 14、QA工程师负责监督检测设备的贮存和使用情况 15、QA工程师每周不定期对检测设备进行抽查16、QA工程师每月对外包队使用计量器具的情况进行抽查三、环境管理体系：1、QA工程师每年组织环境因素的识别与评价，汇总报批重要环境因素2、QA工程师汇总报批环境目标、指标、环境管理方案，并监督验证实施3、QA 工程师组织各部门编制项目部环境管理体系文件4、QA工程师负责与电厂、监理公司等的外部联络，接收外部相关方的投诉5、QA工程师组织制定项目部环境管理体系年度培训计划人力资源负责培训的组织、落实和记录管理6、QA工程师参与项目部能源、资源的节约控制；参与自然灾害的防范，现场事故的预防、应急准备和响应；参与消防设计评审；参与确定生活和生产活动中的环保监测项目和关键特性；参与生产施工过程噪声、振动、烟尘、污水排放控制7、QA工程师为各责任部门的培训提供技术支持；各责任部门负责实施 8、QA工程师每月对废弃物处理的情况进行监督检查9、QA工程师负责组织项目部的应急准备和响应，建立应急方案，并监督实施 10、QA工程师对监测设备和仪器进行统一管理、每月进行抽检11、QA工程师协助处理环境事故，协助责任部门分析不符合项产生原因，制定并实施纠正和预防措施，QA工程师监督实施12、QA工程师配合文明施工员每周至少二次到现场检查，形成环境记录13、QA工程师协助、配合公司组织的内审工作；为管理评审提供需要的信息14、QA工程师负责接收公司的信息并及时传达；负责汇总项目部的信息并按要求上报15、QA工程师每月对主管部门环境特殊、重要岗位人员相关知识、技能的培训情况进行监督检查 16、QA工程师每半年对法律、法规及其它要求的遵守执行情况进行监督检查四、职业安全健康管理体系：1、QA工程师配合安监专工编制职业安全健康体系策划书，配合安监人员对职业安全健康体系运行的整体情况进行策划2、QA工程师组织编制、修订、发放项目部职业安全健康体系文件；3、QA工程师参与安全质量会议；4、QA工程师参与公司、项目部组织的月度、季度安全大检查5、QA工程师监督验证检查中提出的体系性不符合的纠正和预防6、QA工程师参与对工程分承包方资料的评价，并对其施加影响提出建设性意见和建议7、QA工程师每月对的收集和发放进行检查、每月对化学危害品的使用检查8、QA工程师配合安监专工对项目部的应急预案和响应方案的建立、实施情况进行检查； 9、QA工程师检查各部门目标的分解和管理方案的落实情况软件qa工程师职责对比分析无论是9还是，都是以过程为中心也就是说，通过过程的持续改进来提高产品质量而过程质量与产品质量如何正向关联呢？就需要质量保证这也是9和都很推崇的方法但从国内软件企业的现状来看，很多企业的过程体系都相差无几，而开发出来的产品质量却千差万别导致这种差别的原因有很多，过程及其执行方式的生搬硬套就是其中很重要的原因之一在建立QA组织的时候，多数企业也这样实行“拿来主义”就像看着别人穿着一双非常漂亮的鞋，就想拿过来自己穿，一般都不会适合自己其结果要么是打肿脚穿大鞋，要么是削足适履，效果可想而知我们应该做的是“量脚买鞋”、“量体裁衣”QA组织的建立也一样，应先了解企业的文化、可获得的资源以及过程成熟度水平等，再据此选择适宜的QA组织下面我们就从一个动态的视角来探讨QA组织的建立建立组织结构建立一个组织，首先需要考虑的是它的组织结构组织结构不仅在很大程度上决定了岗位的职责，而且还决定了资源如何配置按照国内多数企业的做法，QA组织结构可划分为三类：职能结构、矩阵结构以及两者结合而成的柔性结构职能结构在职能结构中，各个职能部门设立自己的QA岗位，位于高级经理之下，独立于项目组QA直接对高级经理负责，但业务上需要向项目经理汇报，属于项目成员如图1所示这种组织结构的优点是QA容易融入项目组，易于发现实质性的问题，解决问题也很快捷缺点是各职能部门相对独立，部门之间的经验缺乏交流和共享，还可能出现对过程、方法和工具研究的重复性投资在这种组织结构下，由于高级经理专注于业务的发展，QA的职业发展容易受到忽视，难于接受到应有的培训和提升矩阵结构在矩阵结构中，设立了专门的QA部门，与各业务职能部门平级QA隶属于QA部，行政上向QA经理负责，业务上向业务部门的高级经理和项目经理汇报如图2所示在这种组织结构中，由QA部经理对QA考评和授权，有利于保证QA的独立性和评价的客观性，也有利于确保组织的长期利益与项目的短期利益之间的平衡QA资源为所有项目所共享，可按照项目优先级动态调配，资源利用更充分，但也可能出现资源竞争冲突此外，QA 部门对QA流程的改进、QA知识的管理、QA人员的发展负责，并可集中资源进行QA平台的建设，以防止重复性的投资但另一方面，在矩阵结构中，QA难于融入项目组，发现的问题也很少能得到及时有效的解决柔性结构柔性结构是职能结构和矩阵结构的混合形态，在职能结构的基础上建立了QA组专业组QA组是一个专业组，不是一个行政机构可由质量管理部委派人员担任或由某业务部门的QA兼任与职能机构一样，QA直接对高层经理负责，但在业务上向项目经理和汇报柔性结构吸收了职能结构和矩阵结构的许多优点，既便于QA融入项目组，又便于部门之间经验的分享，还利于QA能力的提高可以从各部门QA汇报中提取出各项目的共性问题，用于组织级过程的改进企业还可以通过授予不同的权利，比如按照2/8原则与高级经理分配QA的管理，来促进QA专业研究与应用的结合QA可以协助评审和组织会议；在存在外包的情况下，可能需要QA在监控外包方方面发挥作用重要责任过程成熟度是影响QA职责分配很重要的因素，不同的成熟度等级所要求的QA工作分布是不同的在低成熟度等级下，需要抽取各项目最佳实践来定义过程，并指导过程的实施，QA在这方面的工作最多随着过程的完善、制度化和实施，QA的工作重点逐渐转向了过程评审和产品审计当企业的过程成熟度达到4级或5级以后，对过程的遵守已经成为员工的一种习惯，过程和产品的审查需求减少，而度量和过程能力的优化又成为QA的工作重点企业文化对QA来说就像空气一样，看不见它，但却深深地被它影响比如说，在一个氛围活跃、高技术、创新能力强的企业，QA应该倾向于服务职责；而在一个强纪律、低技术、规章制度成熟的企业，QA就应该倾向于监督职责QA工程师国内企业越来越注重产品质量，随之，对品质监管的力度与要求也越来越高QA工程师水涨船高，备受重视QA的薪金是跟工作年限成正比的那么，经验丰富的QA工程师都需要掌握些什么呢？ 1) 相关体系的认证及完善 2）主管技术措施和技术、质量、安全的交底工作 3）一般性品质工作 4）质量培训工作5）做品质就像在给病人看病，高手总是能在不良发生之前就解决它所以，QA ，最重要的是一个预防性作用 1根据工程资料内部要求及时对产品的有关项目组织实验室测试 2制订品质计划3对各种材料及成品之检验标准书进行审核 4即时处理客户抱怨及退货以确保客户满意5主持每周品质会议并推动全公司相关部门人员共同提升品质 6统计、分析各品质会议并推动全公司相关部门人员共同提升品质 7统计、分析各阶段品质不良并推动各部门改善以达到目标 8针对材料不良辅导供应商分析、改善 9做好品质记录以便追溯1稽核评估供应商并做好相应记录 11考核下属业绩配置岗位人员在建立组织结构过程中设立了QA工作岗位，就需要为岗位配备足够的资源，特别是分派岗位人员从大体上说，QA人员的配备可根据企业特点分为两类：全职和兼职全职就是设置专门的QA人员，QA的主要职责就是质量保证工作在设置这类人员时，最重要的是考虑他的知识、技能和素质是否符合组织和岗位的规定和要求这些要求是依据企业文化和成熟度的不同而有所侧重比如说，对于一个协作意识较弱、官僚主义较浓的企业，沟通对QA来说可能是一个重要的素质要求；对于成熟度较低，还没有制度化标准过程的企业，对业务的了解和QA专业知识的精通可能是选择QA最重要的标准兼职就是将工程师分派到其它职能部门或项目中去兼任QA工作，每一位工程师都作为一名潜在的QA这也是QA人员配置的一个可选方案，一般适宜于开放的、以质量为向导的文化，反过来也能对质量文化的建设起到很大的促进作用但这种方案应小心地与组织制度结合，比如奖惩制度、成本制度等，否则容易引起利益冲突由于QA的概念引入国内不久，QA人才相当缺乏为了获得足够的资源来完成QA工作，也可以采取岗位轮换的方式比如，允许项目经理在项目管理岗位和QA岗位上轮换，把一定的QA工作经历作为项目经理上岗的必备条件采取岗位轮换的方式，一方面解决了QA资源的不足，另一方面还促进了轮岗人员把QA的思想和方法融会到开发和项目管理工作中，更大程度上提高产品质量从以上的分析我们可以知道，建立QA组织需要动态地考虑企业的文化、可获得的资源以及过程成熟度水平等因素，做到“因地制宜”，而不是生搬硬套首先要建立一个适宜的组织结构，组织结构中确立了QA岗位和汇报渠道接下来就是确定岗位职责，并根据岗位职责的要求配置合适的QA人员只有在组织结构、岗位职责、岗位人员都设置和整合好以后，才能充分发挥QA的价值，确保通过过程的持续改进来带动产品质量的不断提高工作内容在需求定义流程中，审查是更适合质量保证测试人员的角色，而不是定义；但QA测试人员需要学习如何高效执行审查对于QA测试人员来主产，在于需求定义审查中成功获得支持关键在于，找到对于其它参与人员重要的问题，这就意味着找出需求内容相关的问题，避免投入过多的精力在形式和可测试性上在我的书中，或相关的讨论坛中，我描述了许多方法来识别需求问题——包括清晰度和可测试性——以及如何使用强大的方法来检测出错误和疏忽的内容有些组织让业务分析师负责定义需求和开发测试，从而证明需求已经达到要求这类双重角色常常会因为测试方法和知识的不足，而导致测试被忽略掉另外，分析师的测试。
CMMI2.0介绍1 CMMI介绍2018 年 3 月，美国 CMMI （ Capability Matu-rity Model Integration，能力成熟度模型集成）研究院发布了最新研究成果，即 CMMI2.0 ，在此之前的版本是 CMMI1.3 。
1.1 CMMI2.0 模型架构CMMI2.0 模型引入“能力域”和“实域”的概念，将 CMMI1.3 的开发（DEV）、服（SVC）、采购（ACQ）和人力管理（PPL）等种模型中的所有实践整合在一个模型中。
CMMI2.0 中共有 12 个能力域，这 12 个能力域被分为 4 类： Doing （执行）、Managing （管理）、 Enabling （使能）和 Improving （提高）。
每个能力域中包含一组相关的实践域。
项目可以构建自己的自定义视图。
CMMI2.0 模型的核心是一组集成的、预定义的和可定制的不同模型的视图，由5 个部分组成，见表1。
图1 CMMI 发展历程表1 CMM2.0模型组成部分结构1.2 CMMI2.0模型的主要内容CMM12.0模型中的实践域等同于CMMI3模型中的过程域。
实践域是一组实践，它们共同描述已定义的意图和价值所需的关键活动表2 实践域组成及其包括的内容1.3 能力等级定义CMMI2.0模型的实践组中的实践是按照1级至5级能力等级进行安排的（见表3），每个等级都是在前一个等级基础上增加新的功能或能力要求，为组织改进提供一条清晰的路径。
表3 CMMI2.0实践能力等级1.4 CMM2.0-DEV视图当前，CMMI20模型中总共有4种能力域类型，12个能力域，39个实践域。
这39个实践共组成了4个预定义视图，但目前仅发布了CMM2.0-DEV视图，其余视图（CMMI2.0-SVC、CMMI2.0-SPM和CMM2.0-PPL视图）待陆续发布。
表4 CMMI2.0-DEV视图2 CMMI2.0-DEV视图与CMMI1.3-DEV的对比CMMI2.0-DEV视图实践域与CMMI.3-DEV过程域之间对比见表所述。
cmmi能力成熟度模型结构
CMMI（Capability Maturity Model Integration）能力成熟度模型结构由一系列的PA（过程域）组成，这些PA构成了集成能力模型的核心，为企
业提供了软件工程、系统工程、集成产品及过程开发方面的过程改进框架和指南。
CMMI模型由四个类别组成，分别是：
1. Doing（对应的工程类）：包括行动能力域，确保质量、设计和开发产品、交付与管理服务等。
2. Managing（对应的项目管理类）：包括管理能力域，规划和管理工作、管理业务弹性、管理员工等。
3. Enabling（对应的支持类）：包括赋能能力域，支持实施、管理安全和
安保等。
4. Improving（对应的过程管理类）：包括提高能力域，维持习惯性和持久性、改善性能等。
CMMI 模型还具有四个类别，12个能力域和25个实践域。
每个类别又包
含专门定义的能力域，这些域是组织在开发和交付产品和/或服务时通常会
遇到的相关和通用的实践按照逻辑分的组。
以上内容仅供参考，如需更全面准确的信息，建议查阅CMMI官方网站发布的资料或咨询专业的CMMI评估师。
产品经理应该了解的CMMI模型编辑导读：产品经理学习CMMI，一方面是学习CMMI解决软件问题的方法论，另一方面是了解主流的软件开发流程，方便协调产品和项目开发。
本文作者从CMMI 的基本概念出发，对CMMI的级别和发展现状展开了详细的介绍，与大家分享，希望通过此文能够加深你对CMMI的了解。
01 基本概念1.1 过程改进在软件开发中，约束软件项目的三个要素是质量、进度和成本，被称为软件开发铁三角，软件开发总是在这三个要素中妥协平衡，不时要抉择保哪个牺牲哪个，不断在刀尖上跳舞。
而决定质量的要素又有三个：人、过程和技术，其中CMMI 主要关注过程的改进。
因为CMMI有一个基本的假设前提：产品的质量很大程度上受影响于所使用的开放与维护过程的质量。
所以为了改进产品质量，需要改进过程质量，称为过程改进。
1.2 CMMI的定义CMMI, Capability Maturity Model Integration，能力成熟度模型集成。
CMMI是美国国防部发起并资助的一个项目，由卡内基梅隆大学软件工程研究所（SEI）开发。
CMMI是一种过程改进模型。
CMMI是业界过程改进的最佳实践集合。
CMMI关注于改进组织内部的过程，描述了从随意、不成熟的过程到提高了质量与有效性的、有秩序、成熟的过程的演进道路。
1.3 CMMI模型CMMI 1.3分为三种模型：CMMI-DEV开发模型（应用最广）、CMMI-SVC服务模型和CMMI-ACQ采购模型。
它们有公用的一些过程域，也有特有的一些过程域。
CMMI的最新版本为2.0，但相关资料非常少，官网购买CMMI-DEV 2.0指南需要150美元。
1.4 过程域PACMMI-DEV-v1.3为例，包含22个PA，分为过程管理类、项目管理类、工程类和支持类4类：过程管理5个PA：OPD组织级过程定义、OPF组织级过程关注、OPM组织级绩效管理、OPP组织级过程性能、OT组织级培训。
软件项目管理CMMI入门与精通1．初识cmmi2．CMMI一级—初始级3．CMMI二级4．CMMI三级5．CMMI四级6．CMMI五级7．CMMI与ISO的区别与联系8．CMMI在项目中软件研发实际应用一、初始CMMICMMI是由卡内基梅隆大学软件工程学院（Software Engineering Institute，简称SEI）1984年受美国国防部要求开始研究在软件产业建立一套工程制度，用来评估与改善软件开发公司的过程与能力，并协助软件开发人员持续改善流程的成熟度与软件质量，从而提升软件开发项目及公司的管理能力，最终达到软件开发功能正确、缩短开发进度、降低开发成本、确保软件质量的目标。
1986年正式开始研究CMM能力成熟度模型（Capability Maturity Model，简称CMM），于1991年正式推出了软件能力成熟度模型（Capability Maturity Model For Software，简称SW-CMM）,两年后1993年正式推出SW_CMM1.0 。
后来又根据CMM1.0在各个行业领域进展成了CMMs，其中包含系统工程能力成熟度模型（Systems Engineering Capability Maturity Model, SE-CMM）、整合产品进展能力成熟度模型（Integrated Product Development Capability Maturity Model, IPD-CMM）、人力资源管理能力成熟度模式（People Capability Maturity Model, P-CMM）等应用模型。
由于各行业架构的不一致，SEI于2000年12月公布了能力成熟度整合模型（Capability Maturity Model - Integrated, CMMI）对此进行整合。
后来通过不断改进，就形成了今天的CMMI1.2,1.3版本。
CMMI有关基本概念：CMMI-Capability Maturity Module Integration（软件过程能力成熟度集成模型），是将原先的CMM-SW/SE等等整合为一个模型，目前使用的版本叫CMMI-DEV（Development）v1.2。
CMMI3级18个过程域CMMI（Capability Maturity Model Integration）是一种用于评价和改进组织的软件工程能力的模型。
CMMI模型将软件工程能力分为不同的级别，目前最高级别是CMMI级别5、在CMMI模型中，共有18个过程域，每个过程域都包含一组过程目标和过程实践。
下面将介绍CMMI级别3中的18个过程域，并对每个过程域进行详细解析。
1. 要求开发（Requirements Development）：该过程域涉及确定、分析和记录系统和软件需求的活动。
它包括需求的获取、管理、分析和验证。
2. 要求管理（Requirements Management）：该过程域涉及组织和控制项目的需求。
它包括需求的识别、跟踪、控制和变更管理。
3. 项目计划和监控（Project Planning and Monitoring）：该过程域涉及制定和维护项目计划，并监控项目活动的执行。
它包括识别和规划项目活动、建立项目计划、监控项目进展和基于此进行调整。
4. 项目监控和控制（Project Monitoring and Control）：该过程域涉及监控和控制项目执行过程中的工作和活动。
它包括收集和分析项目绩效数据、对比实际和计划绩效，对项目进展进行控制。
5. 供应商协议管理（Supplier Agreement Management）：该过程域涉及与供应商达成协议，并管理和监控供应商的活动。
它包括选择供应商、与供应商协商、管理和控制供应商的交付和绩效。
6. 产品集成（Product Integration）：该过程域涉及对各个组成部分进行整合，形成最终产品。
它包括定义和实施产品集成策略、执行产品集成和验证集成后的产品。
7. 风险管理（Risk Management）：该过程域涉及识别、评估和控制项目和产品的风险。
它包括制定风险管理计划、识别和评估风险、并采取相应的风险缓解措施。
8. 决策分析和解决方案评估（Decision Analysis and Resolution）：该过程域涉及通过分析和评估不同的解决方案，制定决策。
CMMI术语定义术语定义更改控制页目录1目的 (1)2范围 (1)3术语定义 (1)3.1CMMI过程域 (1)3.1.1REQM (1)3.1.2PP (1)3.1.3PMC (1)3.1.4SAM (1)3.1.5MA (2)3.1.6PPQA (2)3.1.7CM (2)3.1.8OPF (2)3.1.9OPD (2)3.1.10RD (2)3.1.11TS (2)3.1.12PI (3)3.1.13VER (3)3.1.14VAL (3)3.1.15IPM (3)3.1.16RSKM (3)3.1.17DAR (3)3.1.18OT (3)3.1.19OPP (4)3.1.20QPM (4)3.2相关的组织 (4)3.2.1变更控制委员会（CCB） (4)3.2.2管理指导组（MSG） (4)3.2.3技术管理委员会（TMB） (5)3.2.4MS推进组 (5)3.2.5质量保证组（QAG） (5)3.2.6工程过程组（EPG） (5)3.3DELPHI法 (6)3.4FPA法 (6)3.5工期 (6)3.6工作量 (6)3.7生产率 (6)3.8B UG (6)3.9覆盖率 (7)3.10缺陷 (7)3.11WBS (7)3.12度量 (7)3.12.1基本度量 (7)3.12.2派生度量 (7)3.13产品构件 (8)3.14干系人 (8)3.15工作产品 (9)3.16供货周期 (9)3.17估算 (9)3.18过程和工作产品数据 (9)3.19候选方案 (9)3.20基础构件 (10)3.21基线 (10)3.22测试 (10)3.22.1回归测试 (10)3.22.2单元测试 (10)3.22.3集成测试 (10)3.22.4系统测试 (11)3.22.5验收测试 (11)3.23计划 (11)3.24决策人 (11)3.25客户化项目 (11)3.26培训 (12)3.26.1内部培训 (12)3.26.2外部培训 (12)3.27同行评审 (12)3.28项目计划 (12)3.29项目数据 (12)3.30项目组 (12)3.31需求不一致 (13)3.32需求跟踪矩阵 (13)3.33需求开发 (13)3.34选择准则 (13)3.35组织标准过程集合(OSSP) (14)3.36组织过程相关文档库 (14)3.37组织度量数据库 (14)3.38组织过程财富库（OPAL） (15)3.39工作环境标准 (15)1目的统一组织标准过程文件中的术语解释。
