(完整版)CMMI过程域总结v2.0,推荐文档
（完整版）CMMI过程域总结v2.0,推荐文档
（完整版）CMMI过程域总结v2.0,推荐文档CMMI 基本介绍V2.0目录1组织成熟度级别和类别 (2)2通用目标和通用实践 (3)3RD 需求开发REQUIREMENTS DEVELOPMENT (4)4REQM 需求管理REQUIREMENTS MANAGEMENT (5)5PP 项目策划PROJECT PLANNING (6)6PMC 项目监督和控制PROJECT MONITORING AND CONTROL (7)7RSKM 风险管理RISK MANAGEMENT (8)8SAM 供应商协议管理SUPPLIER AGREEMENT MANAGEMENT (9)9CM 配置管理CONFIGURATION MANAGEMENT (10)10PPQA 过程和产品质量保证PROCESS AND PRODUCT QUALITY ASSURANCE (11)11MA 度量和分析MEASUREMENT AND ANALYSIS (12)12DAR 决策分析和解决DECISION ANALYSIS AND RESOLUTION (13)13TS 技术解决方案TECHNICAL SOLUTION (14)14PI 产品集成PRODUCT INTEGRATION (15)15VER 验证VERIFICATION (16)16VAL 确认VALIDATION (17)17OPF 组织过程聚焦ORGANIZATIONAL PROCESS FOCUS (18) 18OPD 组织过程定义ORGANIZATIONAL PROCESS DEFINITION (19)19OT 组织培训ORGANIZATIONAL TRAINING (20)20IPM 集成项目管理INTEGRATED PROJECT MANAGEMENT (21)21OPP 组织过程性能ORGANIZATIONAL PROCESS PERFORMANCE (22)22QPM 量化项目管理QUANTITATIVE PROJECT MANAGEMENT (23)23CAR 因果分析和解决CAUSAL ANALYSIS AND RESOLUTION (24)24OPM 组织性能管理ORGANIZATIONAL PERFORMANCE MANAGEMENT (25)3RD 需求开发Requirements Development目的：引出、分析和建立客户、产品及产品组件的需求。
CMMI级过程域讲解
CMMI级过程域讲解CMMI（Capability Maturity Model Integration）是一种用于评估和改进软件开发过程的框架。
它通过对软件开发组织的过程进行评估，为组织提供了一个逐步改进过程的路径，从而提高组织的能力和成熟度。
CMMI框架包括五个过程域，它们是：项目管理、项目支持、要素工程、项目环境和组织过程。
每个过程域都有一组特定的目标和实践，用于评估和改进相关的软件开发过程。
首先是项目管理过程域，它关注的是项目的计划、执行和监控。
它包括了项目管理的三个关键方面：计划制定、项目监控和项目管理。
项目管理过程域的目标包括项目计划的制定、项目资源的分配和控制、项目风险的管理和项目进展的监控。
其次是项目支持过程域，它提供了支持项目管理过程的各种资源和服务。
项目支持过程域包括配置管理、度量和分析、决策分析和解决方案评价等方面。
其目标包括配置管理的实施、度量和分析的开展、决策分析和解决方案评价的应用。
第三个是要素工程过程域，它关注的是软件开发中所使用的各种工具和技术。
要素工程过程域包括需求开发、技术解决方案、产品集成和验证、产品交付等方面。
其目标包括需求开发的实施、技术解决方案的应用、产品集成和验证的实施、产品交付的管理。
第四个是项目环境过程域，它关注的是项目所处的环境因素对项目成功的影响。
项目环境过程域包括了风险管理、分析过程和产品市场分析等方面。
其目标包括风险管理的实施、分析过程的开展、产品市场分析的应用。
最后是组织过程过程域，它关注的是软件开发组织的过程管理。
组织过程过程域包括组织过程的定义、组织过程管理的实施和过程改进等方面。
其目标包括组织过程的定义和实施、组织过程管理的应用、过程改进的管理。
总而言之，CMMI级过程域是一个用于评估和改进软件开发过程的框架。
它包括了五个过程域，分别是项目管理、项目支持、要素工程、项目环境和组织过程。
每个过程域都包含了一系列的目标和实践，用于评估和改进相关的软件开发过程。
CMMI总结
CMMI总结1.CMMI 的全称为：Capability Maturity Model Integration，即能力成熟度模型集成。
2.目前公司使用的是CMMI-for-DEV V1.2，通过的是CMMI LEVEL 3认证。
3. CMMI将CMM的多个模型合并到一个框架中，包括SE /SW /SS /IPPD几个专业领域的过程模型。
CMMI提供了流程改进的指导，指导制定软件企业研发的的一系列流程，监督流程的执行，并据反馈的结果进行过程改进。
4.CMM共有五个等级，分别标志着软件企业能力成熟度的五个层次。
初始级Initial可重复级Managed(Basic Project Management)已定义级Defined (Process Standardization)量化管理级Quantitatively Managed (Quantitative Management)优化管理级Optimizing (Continuous Process Improvement)5.原则（1）、强调高层管理者的支持。
（2）、确定改进目标.一、I PD基本介绍1. IPD, 集成产品开发（Integrated Product Development）是一套产品开发的模式、理念与方法。
2. IPD作为先进的产品开发理念，其核心思想概括如下：a) 新产品开发是一项投资决策。
b) 基于市场的开发。
c) 跨部门、跨系统的协同。
d) 异步开发模式，也称并行工程。
e) 重用性。
f) 结构化的流程。
3. IPD框架上从以下三个大的方面来具体现IPD的核心思想.市场管理市场管理从客户、投资、市场等产品生存的外在客观环境因素来影响产品的特性和生命。
包括：a) 客户需求分析$-产品价格（Price）；A-可获得性（Availability）；P-包装（Packaging）；P-性能（Performance）；E-易用性（Easy to use）；A-保证程度（Assurances）；L-生命周期成本（Life cycle of cost）；S-社会接受程度（Social acceptance）。
我对CMMI2.0II实践域的理解和分析
我对CMMI2.0II实践域的理解和分析实施基础条件 (Implementation Infrastructure, II)实践域是通过建立必要的基础条件，确保过程得到建立、遵守、维护和持续改进。
这些基础条件包括：组织已定义的过程（过程实施的基础，没有过程定义，谈何过程实施）、过程实施所需的资源（人员、工具等）、过程实施所需的资金（购买工具、培训经费等）、对组织过程的培训（不了解过程，就无从执行过程）。
本实践域共3个等级6个实践。
实践1.1就是要求项目执行组织定义好的过程，即使当前组织的CMMI实践处于较低水平，没有严格的建立起适用的、有效的标准过程。
实施本实践，至少使项目各行其事的乱象有所改观，也会为组织过程改进提供第一手的资料。
实践2.1的核心也是提供资源，它与前版共用实践2.3比较接近。
前面的GOV实践域的2.2也是提供资源，但GOV提供资源偏重于过程改进，本实践域的提供资源偏重于过程实施。
本实践除了要求为过程实施提供人力、工具等资源之外，也包括资金和培训。
本实践也是整个实践域的核心。
实践2.2要求组织建立过程、对过程进行评估/评审，验证项目是否遵循组织的过程，对过程进行改进等活动，涵盖了前版OPD、OPF 过程域的部分实践。
实践3.1是要求在项目中实际应用组织资产来进行项目的策划、管理和过程的执行。
应用组织资产可以提高效率、降低成本，所以组织应当不断丰富自己的组织资产，并在项目中加强推广和应用。
实践3.2要求评估过程的有效性和符合性。
这与实践2.2中的评估不同，实践2.2的评估的目的是验证项目有没有按照过程要求执行，本实践评估的重点是过程的有效性和符合性。
其中符合性指的是通过项目实施的结果判断过程的实施是否与组织预期的过程目标相一致。
有效性是指对组织目标的实现是否有帮助，如效率提高、质量和性能提升等。
实践3.3是为组织资产做贡献，与前版的IPM过程域SP1.6基本一致。
本实践的价值是：通过改进组织过程和过程资产来提高投资回报。
cmmi2.0监督与控制实践域内容
CMMI2.0监督与控制实践域内容随着现代社会的发展和科技的进步，软件行业的发展越来越迅速。
在这样一个竞争激烈的行业中，软件企业需要不断提高自己的研发能力和管理水平，以适应市场的需求和挑战。
CMMI（Capability Maturity Model Integration）是一个被广泛应用的软件过程改进框架，它可以帮助软件企业评估和改进其软件开发和维护的过程，从而提高软件产品的质量和开发效率。
CMMI2.0是CMMI的最新版本，它引入了一些新的概念和实践域，其中就包括监督与控制实践域。
监督与控制实践域是CMMI2.0中非常重要的一个实践域，它涉及到软件项目的监督、控制和管理，对软件企业的发展和项目的成功至关重要。
本文将深入探讨CMMI2.0监督与控制实践域的内容和意义。
I. 实践域介绍CMMI2.0的监督与控制实践域是一个包含一系列实践的域，旨在帮助软件项目从需求分析到产品交付过程中，确保项目中所采用的监督与控制实践能够有效实施。
该实践域包含了以下几个子实践域：1. 计划监督与控制（Plan and Monitor）计划监督与控制是指在软件项目启动阶段，制定项目计划，并在项目执行过程中监督和控制项目的进度和质量。
这个子实践域包括了以下一些具体实践：- 制定项目计划：明确项目范围、目标、资源需求和里程碑，并为项目制定详细的计划。
- 监督项目进度和成本：及时更新项目进度和成本信息，对项目的实际进度和成本与计划进行比较，及时发现和纠正偏差。
- 管理项目风险：识别和评估项目风险，制定适当的风险应对策略，确保风险不会对项目的进度和质量造成影响。
2. 监管与评审（Supervise and Review）监管与评审是指在项目执行过程中，对项目各项工作的进展和质量进行监督和评审。
这个子实践域包括了以下一些具体实践：- 进行工作审查：定期对项目中的工作成果和文档进行审查，及时发现和纠正问题，确保工作符合质量标准。
cmmi实施的个人总结范文
cmmi实施的个人总结范文篇一：CMMI总结CMM的每个等级都被分解为3个层次:关键过程域、公共特性和关键实践。
CMMI的层次：关键过程域表示在遵循一个软件过程后所得到的实际结果。
软件过程性能既可对整个软件开发或项目而言，也可对一个特定软件项目而言。
可见，软件过程性能描述已得到的实际结果，而软件过程能力则描述最可能的预期结果。
在这里，要注意与软件过程能力的区别，前者关注的是实际得到的结果，而后者关注的是期望得到的结果。
由于项目要求和客观环境的差异，软件过程性能不可能充分反映软件过程的整体能力，即软件过程性能受限于它的环境。
软件工作者在运用这两项指标时应有足够的认识。
4.软件过程成熟度：软件过程成熟度是指一个具体的软件过程被明确地定义、管理、评价、控制和产生实效的程度。
所谓成熟度包含着能力的一种增长潜力，同时也表明了组织（企业）实施软件过程的实际水平。
随着软件组织的软件过程成熟度的提高，开发组织通过其方针、标准和组织机构等将其软件过程规范化和具体化，从而使得开发组织明确定义的有关管理和工程的方法、实践和规程等在现有人员离去后仍能继续下去。
5.软件能力成熟度模型：软件能力成熟度模型（Capacity Maturity Model）是软件过程能力成熟度模型的简称。
软件能力成熟度模型是指对软件组织进化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织能力经过这些阶段逐步前进。
这个能力成熟度模型使软件组织能够较容易地确定其当前过程的成熟度并识别出其软件过程执行中的薄弱环节，确定对软件质量和过程改进最为关键的几个问题，从而形成对其过程的改进策略；软件组织只要关注并认真实施一组有限的关键活动，就能稳步地改善其全组织的软件过程，使全组织的软件过程能力持续增长。
6.软件能力成熟度等级：软件能力成熟度等级是指软件开发组织在走向成熟的过程中几个具有明确定义的表征软件过程能力成熟度的平台。
每一个成熟等级为过程继续改进达到下一个等级提供一个基础。
我对CMMI2.0SAM实践域的理解和分析
我对CMMI2.0SAM实践域的理解和分析供应商协议管理 (Supplier Agreement Management, SAM)即前版CMMI中的供方协议管理（SAM）过程域。
与前版相比，SAM 2.0有以下变化：•变化1：SAM不仅用于软件，2.0中它可以用于硬件、服务等所有解决方案和工作产品。
•变化2：SAM2.0实践域有4个等级的实践。
•变化3：SAM2.0中增加了对供方发票的管理。
•变化4：SAM2.0中增加了对供应商的量化管理要求。
•变化5：SAM2.0中去掉了选择供方的专用实践。
本实践域共4个等级10个实践。
第1级实践1.1要求开发并记录供应商协议。
本实践与前版SAM过程域SP1.3“建立供方协议”基本一致。
2.0中强调供应商协议形式的灵活性。
供应商协议指采购方与供应商之间签订的任何协议。
实践1.2要求接收或拒收供应商的交付物。
本实践与前版SAM过程域SP2.4“接收所获取的产品”接近。
2.0中强调接收时要验证交付物满足合同/协议要求的情况，根据情况决定接收还是拒收。
这里强调的是结果。
实践1.3要求管理供应商发票。
采购方按照协议要求及时处理供应商发票，是双方维持良好合作关系的一个前提条件。
第2级实践2.1要求按照供应商协议监督供应商活动并对供应商协议进行维护。
本实践的重点在于对供应商协议的管理，当出现一些意外情况不得不变更供应商协议时，双方要及时沟通，形成新的供应商协议。
实践2.2要求执行供应商协议。
本实践与前版SAM过程域SP2.1“执行供方协议”基本一致。
实践2.3要求接收供应商的交付物之前要先进行验证。
本实践与前版SAM过程域SP2.4“接收所获取的产品”接近。
与实践1.2不同，这里强调的是验收过程。
实践2.4要求依据供应商协议来管理供应商发票。
与实践1.3不同，这里强调的是供应商协议的遵从性。
只有满足协议要求，才会批准发票的支付。
同时，这里也包括协议中约束条款的执行，如因进度延误或验收质量导致的对供应商的惩罚性费用的处理。
CMMI二级过程域
CMMI二级过程域1、需求管理REQMSG1：管理需求SP1.1：理解需求 SP1.2：获取需求SP1.3：管理需求变更 SP1.4：维护需求的双向追溯性SP1.5：确保项目工作与需求的一致性2、项目策划PPSG1：建立估算值SP1.1：估计项目的范围 SP1.2：建立工作产品与任务属性的估算值SP1.3：定义项目点生命周期 SP1.4：估计工作量和成本SG2：开发项目计划SP2.1：建立预算和进度 SP2.2：识别项目风险SP2.3：对数据管理进行计划 SP2.4：策划项目的资源SP2.5：策划项目过程所需的知识和技能 SP2.6：策划干系人的参与SP2.7：建立和完成项目计划SG3：获取对项目计划的承诺SP3.1：评审影响项目的各种计划 SP3.2：调整工作和资源水平SP3.3：获得对计划的承诺3、项目监控PMCSG1：按计划监控项目SP1.1监控项目计划的各项参数 SP1.2监控承诺事项SP1.3监控项目风险 SP1.4监控数据管理SP1.5监控干系人的参与 SP1.6进行进度审计SP1.7进行里程碑审查SG2：管理纠正措施,直至关闭SP2.1分析问题 SP2.2采取纠正措施SP2.3管理纠正措施4、配置管理CMSG1：建立基线SP1.1：识别配置项 SP1.2：建立配置管理系统SP1.3：建立或发布基线SG2：跟踪和控制变更SP2.1：跟踪变更请求 SP2.2：控制配置项SG3：建立完整性SP1.1：建立配置管理记录 SP1.2：执行配置审计5、度量分析MASG1：安排度量与分析活动SP1.1：建立度量目标 SP1.2：确定度量项SP1.3：确定数据收集和存储流程 SP1.4：确定分析流程SG2：提供度量结果SP2.1：收集度量数据 SP2.2：分析度量数据SP2.3：保存数据和结果 SP2.4：结果交流6、过程与产品质量保证PPQASG1：客观评估过程与产品SP1.1：客观评估工作过程 SP1.2：客观评估工作产品SG2：提供客观的洞察力SP2.1：沟通并确保解决不符合项 SP2.2：建立记录7、供应商协议管理SAMSG1：建立供应商协议SP1.1：确定采购类型 SP1.2：选择供应商SP1.3：建立供应商协议SG2：满足供应商协议SP2.1：执行供应商协议 SP2.2：验收采购的产品SP2.3：确保产品移交通用目标和通用实践初始级GG1：实现特定目标GP1.1实施特定实践已管理级GG2：制度化已管理过程GP2.1：建立组织政策GP2.2：策划过程GP2.3：提供资源GP2.4：分配责任GP2.5：培训人员GP2.6：配置管理GP2.7：识别并纳入相关干系人GP2.8：监控过程GP2.9：客观评价符合度GP2.10：与高层管理者一起审查过程状态。
(完整版)CMMI过程域总结v2.0,推荐文档
CMMI基本介绍V2.0目录1组织成熟度级别和类别 (2)2通用目标和通用实践 (3)3RD 需求开发REQUIREMENTS DEVELOPMENT (4)4REQM需求管理REQUIREMENTS MANAGEMENT (5)5PP项目策划PROJECT PLANNING (6)6PMC项目监督和控制PROJECT MONITORING AND CONTROL (7)7RSKM风险管理RISK MANAGEMENT (8)8SAM供应商协议管理SUPPLIER AGREEMENT MANAGEMENT (9)9CM配置管理CONFIGURATION MANAGEMENT (10)10PPQA过程和产品质量保证PROCESS AND PRODUCT QUALITY ASSURANCE (11)11MA度量和分析MEASUREMENT AND ANALYSIS (12)12DAR决策分析和解决DECISION ANALYSIS AND RESOLUTION (13)13TS技术解决方案TECHNICAL SOLUTION (14)14PI产品集成PRODUCT INTEGRATION (15)15VER验证VERIFICATION (16)16VAL确认VALIDATION (17)17OPF组织过程聚焦ORGANIZATIONAL PROCESS FOCUS (18)18OPD组织过程定义ORGANIZATIONAL PROCESS DEFINITION (19)19OT组织培训ORGANIZATIONAL TRAINING (20)20IPM集成项目管理INTEGRATED PROJECT MANAGEMENT (21)21OPP组织过程性能ORGANIZATIONAL PROCESS PERFORMANCE (22)22QPM量化项目管理QUANTITATIVE PROJECT MANAGEMENT (23)23CAR因果分析和解决CAUSAL ANALYSIS AND RESOLUTION (24)24OPM组织性能管理ORGANIZATIONAL PERFORMANCE MANAGEMENT (25)1组织成熟度级别和类别2通用目标和通用实践3RD需求开发Requirements Development目的：引出、分析和建立客户、产品及产品组件的需求。
(完整版)CMMI过程域总结v2.0,推荐文档
3 / 25
3 RD 需求开发 Requirements Development
目的：引出、分析和建立客户、产品及产品组பைடு நூலகம்的需求。
特定目标
特定实践
SG1 开发客户需 求 (收集相关干系人 得需要、期望、约 束及接口，并转换 成客户需求)
SP1.1 引导需求：引导相关干系人提出关于产品生命周期各阶段得需要、期望、 约束及接口 SP1.2 将相关干系人的需要转化为客户需求：将相关干系人的需要，如期望、约 束与限制、接口等转化为客户需求；通常会包括对系统目标、范围、解决问题、 软件特性、接口要求等有详细的描述。
3 RD 需求开发 REQUIREMENTS DEVELOPMENT .........................................................................4 4 REQM 需求管理 REQUIREMENTS MANAGEMENT.....................................................................5 5 PP 项目策划 PROJECT PLANNING .............................................................................................6 6 PMC 项目监督和控制 PROJECT MONITORING AND CONTROL ..................................................7 7 RSKM 风险管理 RISK MANAGEMENT .......................................................................................8 8 SAM 供应商协议管理 SUPPLIER AGREEMENT MANAGEMENT..................................................9 9 CM 配置管理 CONFIGURATION MANAGEMENT......................................................................10 10 PPQA 过程和产品质量保证 PROCESS AND PRODUCT QUALITY ASSURANCE...........................11 11 MA 度量和分析 MEASUREMENT AND ANALYSIS ....................................................................12 12 DAR 决策分析和解决 DECISION ANALYSIS AND RESOLUTION .................................................13 13 TS 技术解决方案 TECHNICAL SOLUTION .................................................................................14 14 PI 产 品集成 PRODUCT INTEGRATION......................................................................................15 15 VER 验 证 VERIFICATION..........................................................................................................16 16 VAL 确 认 VALIDATION ............................................................................................................17 17 OPF 组织过 程聚焦 ORGANIZATIONAL PROCESS FOCUS ..........................................................18 18 OPD 组织过 程定义 ORGANIZATIONAL PROCESS DEFINITION ..................................................19 19 OT 组织培训 ORGANIZATIONAL TRAINING .............................................................................20 20 IPM 集成项目 管理 INTEGRATED PROJECT MANAGEMENT......................................................21 21 OPP 组织过程 性能 ORGANIZATIONAL PROCESS PERFORMANCE ............................................22 22 QPM 量化项目 管理 QUANTITATIVE PROJECT MANAGEMENT ................................................23 23 CAR 因果分析 和解决 CAUSAL ANALYSIS AND RESOLUTION....................................................24 24 OPM 组织性能管理 ORGANIZATIONAL PERFORMANCE MANAGEMENT .................................25
cmmi实施的个人总结范文
cmmi实施的个人总结cmmi实施的个人总结范文篇一：CMMI总结CMM的每个等级都被分解为3个层次:关键过程域、公共特性和关键实践。
CMMI的层次：关键过程域（CMM 18个【2-5级】）：每个关键过程域所包含的关键实践涉及5个方面：执行约定、执行能力、实施活动、度量和分析、验证实施。
具体描述：1）执行约定（Commitment to Perform）：执行约定描述一个组织在保证将过程建立起来并持续起作用方面所必须采取的行动。
执行约定一般包含制定组织的方针和规定高级管理者的支持。
2）执行能力（Ability to Perform）：执行能力描述的是在软件过程中每个项目组或整个组织必须达到的前提条件。
执行能力一般包括资源、组织机构和培训。
3）实施活动（Active Performed）：实施活动描述的是实现一个关键过程域时所必须执行的任务和步骤。
实施活动应该包括建立计划（正式和非正式的计划）和制定步骤开展工作，对该工作进行跟踪，以及必要时进行改进的措施。
4）度量和分析（measurement and analysis）：度量和分析描述对过程进行度量的基本规则，以确定、改进和控制过程的状态。
度量和分析一般包括一些为了确定所执行活动的状态及有效性所能采用的度量和分析的例子，通过这些例子可以知道如何确定操作活动的状态和效果。
5）验证实施（Verifying implementation）：验证实施描述了保证遵照已建立的过程进行活动的措施。
验证一般包括管理者和软件质量保证部门所作的评审和审计。
CMM有两个基本用途：软件过程评估和软件能力评价。
步骤（共6步）：第一步：建立一个评估/评价组。
第二步：填写提问单。
第三步：进行响应分析。
第四步：进行现场访问。
第五步：提出调查发现清单。
第六步：制作关键过程域（KPA）剖面图。
1.4.1 从初始级向可重复级过渡：初始级是CMM的起点，任何一个准备按照CMM框架等级进化的软件企业都自动地处于这一等级。
CMMI文档一览表（大全5篇）
CMMI文档一览表（大全5篇）第一篇：CMMI文档一览表CMMI文档一览表 V0.9 项目名称:《立项申请书》——《评审申请表》《评审准备表》《评审报告》；《立项通知单》《项目章程》《项目启动会议》《项目过程定义》——《评审申请表》《评审准备表》《评审报告》《项目WBS 估计书》——《评审申请表》《评审准备表》《评审报告》《项目开发计划》——《评审申请表》《评审准备表》《评审报告》（风险计划、培训计划、沟通计划、跟踪计划）《测试计划》——《评审申请表》《评审准备表》《评审报告》《风险管理列表》《项目周报》《项目成员周报》《项目阶段报告》《项目总结报告》《产品移交申请表》《产品移交文档清单》《移交组织财富库清单》项目例会、里程碑会议、总结会议《项目会议纪要》《数据项检查表》《项目问题跟踪表》单元《测试用例》《单元测试缺陷报告》《测试报告》/《工序报验单》、《材料报验单》、《产品验收记录单》集成《测试用例》《产品集成就绪检查列表》《集成测试缺陷报告》《测试报告》——《评审准备表》《评审报告》系统《测试用例》《系统测试缺陷报告》《测试报告》——《评审准备表》《评审报告》《验收测试计划》《验收测试缺陷报告》《验收测试用例》《验收测试报告》/《验收报告》《测试计划》（美伦纱业）注：船安一卡通和二层交换机项目在所有测试结束后，汇总缺陷，形成文档《缺陷报告》美伦纱业项目的《阶段缺陷报告》，每个阶段一个，项目结项以后汇总成一个《缺陷报告》《需求开发计划》《需求记录表》《需求模块功能矩阵》《用户需求规格说明书》——《评审申请表》《评审准备表》《评审报告》《软件需求规格说明书》——《评审申请表》《评审准备表》《评审报告》《设计说明书》《模块设计方案》《技术数据包》——《评审申请表》《评审准备表》《评审报告》《用户手册》——《评审申请表》《评审准备表》《评审报告》《集成计划》——《评审申请表》《评审准备表》《评审报告》QA《工作环境及设备检查表》《配置管理计划》——《评审申请表》《评审准备表》《评审报告》《配置审计报告》《配置状态报告》《变更申请表》《CM周报》《质量保证计划》——《评审申请表》《评审准备表》《评审报告》《QA过程评审检查表》《QA报告》《QA问题跟踪表》《QA 周报》《QA年度工作总结》《QA向高层报告》《项目度量计划》——《评审申请表》《评审准备表》《评审报告》《项目度量表》《项目估计记录》《决策分析报告》《培训申请表》《培训考勤表》《培训记录表》《项目异常数据分析表》、《原因分析会议记录》、《原因分析及改进报告》附：已有文档在文档旁注明数量，如果该文档只有一个，则打一个钩代替1。
CMMI的5个级别和25个过程域
CMMI的5个级别和25个过程域CMMI (Capability Maturity Model Integration)是一个结构化的过程改进方法，用于评估和提升组织的软件工程能力。
CMMI分为五个不同的成熟度级别，每个级别都有一组相关的过程域。
本文将详细介绍CMMI的五个级别和25个过程域。
1. 初始级别 (Level 1 - Initial)初始级别指的是一个组织在软件开发方面缺乏组织化和预测性的过程。
在这个级别上，软件开发过程通常是不可控制的，且无法重复使用。
这意味着项目结果无法预测和控制，导致成本和进度的不确定性。
2. 执行级别 (Level 2 - Managed)执行级别指的是一个组织开始建立和管理自己的软件开发过程。
在这个级别上，组织已经建立了一些基本的软件开发过程，并能够在不同的项目中重复使用这些过程。
然而，这些过程还没有得到完全的规范和标准化。
2.1 需求管理 (Requirements Management)需求管理是确保正确、一致和可追踪需求的过程。
它涉及定义、确认和维护需求，以确保项目能够满足用户的期望。
2.2 项目计划与监控 (Project Planning and Monitoring)项目计划与监控是制定和监控项目时间表、成本和资源的过程。
它确保项目能够按计划进行，并能够做出合适的调整以达到预期的目标。
2.3 供应商协商 (Supplier Agreement Management)供应商协商是与供应商建立和维护合作关系的过程。
它确保与供应商的交付和管理能够满足项目的需求。
2.4 产品质量保证 (Product Quality Assurance)产品质量保证是确保项目交付的产品符合质量标准和用户期望的过程。
它涉及质量计划、质量审查和质量度量等活动。
2.5 配置管理 (Configuration Management)配置管理是管理项目的配置项（包括软件、硬件和文档等）的过程。
CMMI2.0整理_00.01
实践总结 第三级 RDM 3.1 开发并持续更新解决方案及 其组件的需求。 RDM 3.2 开发操作概念和场景。 RDM 3.3 分配要落实的需求。 RDM 3.4 识别、开发并持续更新接口 或连接需求。 RDM 3.5 确保需求是必要且充分的。 RDM 3.6 在利益相关方的需求和约束 条件之间取得平衡。 RDM 3.7 确认需求，以确保生成的解 决方案在目标环境中按照预期工作。
SSS 3.1 制定、持续更新并遵循征求 、评估和选择供应商的协商方法。
SAM 3.1 选择技术类的供 择和监督供应商过程和交付物。
第四级
第五级
备考
非核心实 践域
非核心实 践域
不参与成 熟度等级 评估
不参与成 熟度等级 评估
PI 2.1 开发、持续更新并遵循集成 策略。 PI 2.2 开发、持续更新并使用集成 环境。 PI 2.3 开发、持续更新并遵循用于 集成解决方案和组件的规程和准则。 PI 2.4 在集成之前，确认每个组件 已被正确识别并按照其需求和设计正 常工作。 PI 2.5 评价集成的组件以确保其符 合解决方案的需求和设计。 PI 2.6 根据集成策略集成解决方案 和组件。 SDM 2.1 制定、记录、持续更新并遵 循服务协议。 SDM 2.2 根据服务协议接收和处理服 务请求。 SDM 2.3 根据服务协议交付服务。 SDM 2.4 分析现有服务协议和服务数 据，为更新协议或新协议做好准备。 SDM 2.5 制定、记录、持续更新并遵 循操作和变更服务系统的方法。 SDM 2.6 确认服务系统就绪情况以支 持服务的交付。 STSM 2.1 开发、持续更新并使用当 前服务的描述。 STSM 2.2 收集、记录和分析有关服 务交付的战略需要和能力的数据。 STSM 2.3 开发、持续更新并遵循提 供源自战略需要和能力的新服务或变 更服务的方法。 SSS 2.1 创建并持续更新询价包。 SSS 2.2 确定合格的潜在供应商并分 发询价包寻求回应。 SSS 2.3 根据记录的评估标准评估提 议的解决方案并选择供应商。 SAM 2.1 根据供应商协议监督供应商 并保持协议更新。 SAM 2.2 根据供应商协议执行活动。 SAM 2.3 在接收之前先验证采购的供 应商交付物是否符合供应商协议。 SAM 2.4 根据供应商协议管理供应商 提交的发票。
CMMI二级过程域
CMMI二级过程域CMMI（Capability Maturity Model Integration）是由美国软件工程协会（SEI）开发的一种过程改进方法论，用于评估和改进组织的软件开发和组织管理过程。
CMMI定义了一个规范的过程能力模型，用以指导组织在软件工程和管理上的改进。
CMMI模型包括了5个等级，从初始级到优化级，每个等级都对应一定的过程能力。
CMMI二级是初级阶段，其中包含了10个过程域，每个过程域都对应一组具体的实践和目标。
第一个过程域是需求管理，它涉及到如何对项目需求进行管理和跟踪。
其中包括了需求的分析、确认和定义等活动。
实践包括了建立需求管理计划、确保需求的可追溯性和变更控制等。
第二个过程域是项目计划和监控，它关注的是如何制定项目计划、管理项目的进度和资源，并进行监控和调整。
实践包括了建立项目计划、建立项目监控机制和进行问题和风险管理等。
第三个过程域是项目监测和控制，它强调如何对项目进度、成本和质量进行监测和控制。
实践包括了收集项目度量数据、分析和报告项目状态，以及进行过程和产品审核等。
第四个过程域是供应商协议管理，它关注的是与外部供应商的合作和管理。
实践包括了建立和维护与供应商的合同和协议，对供应商进行评估和选择，以及监督供应商的交付和质量。
第五个过程域是配置管理，它涉及到对软件配置项进行管理和控制。
实践包括了建立配置管理计划、进行配置项标识和控制，以及管理配置变更和版本控制。
第六个过程域是过程和产品质量保证，它重点是如何确保项目中的过程和产品质量。
实践包括了建立过程和产品质量保证计划、执行过程和产品审核，以及收集和分析质量度量数据。
第七个过程域是测量和分析，它关注的是如何对过程和产品的质量进行测量和分析。
实践包括了建立度量和指标体系、收集和分析度量数据，并进行趋势分析和预测。
第八个过程域是过程和产品创新，它强调如何持续改进过程和产品。
实践包括了建立持续改进机制、推动创新实践，以及收集和分享改进经验。
CMMI级过程域介绍
01.05.2020
42
目标和实践的映射 2
• 特殊目标
• 设计展开
• 实现产品设计
•特殊实践
•运用有效的设计方法
•建立技术资料包
•设计接口
•进行开发、采购或复用分析 • 实现设计 • 编制产品支持文档
01.05.2020
43
典型工作产品
•SP 1.1 开发详细的候选方案和选择准则 从候选方案中选择产品和产品构件解决方案 （包括与产品有关的过程）
RD
产品体系结构 产品构件设计
PI
01.05.2020
建立技术 资料包
按照标准 设计接口
进行开发、 购买或复用
的分析
技术资料包
I/F 设计文档 I/F 说明书 I/F 控制文件
选择标准 开发、购买分析
39
技术解决 – 关系图
RD
选择产品构件方案
设计展开
实现产品设计
候选方案和评价准则
设计细节和文档
已开发的产品
定义过程 计划过程 提供资源 分配职责 培训 管理配置
GP2.7 利益相关者介入
GP2.8 GP3.2
监督并控制过程 收集改善信息
GG3
GP2.9 GP2.10
01.05.2020
客观评价符合性 高层管理评价
明确公司对需求开发的期望和要求
定义需求开发过程 制订需求开发的计划 准备实施需求开发所需的资源 明确需求开发过程中的角色和职责 对需求开发实施适当培训，比如客户交流等 需求开发过程的产品和活动纳入配置管理，比如需求规格说明书
需求开发 – 关系图
分析和确认需求
建立操作 概念和场景
建立所要求的 功能定义
分析需求
CMMI-DEV 22个过程域详解
CMMI-DEV 22个过程域详解CMMI-DEV中提到的开发，是包括了软件、硬件等类型的开发。
CMMI-DEV这个模型还可以增加适用于复杂多学科的产品开发的IPD附件，在CMMI之外称为IPD，在CMMI内称为IPPD。
IPPD并没有涉及到市场、财务等。
多出来的一个P 代表是过程，IPD中包含了市场与财务，所以IPD与IPPD是有一定差别的。
IPPD 有其适用范围，不能乱用，IPD也是同理。
国内有些企业盲目追随华为实施IPD，成功者少，失败者众。
为什么呢？没有注意IPD的适用范围。
IPD适用于什么类型的组织呢？（1）复杂产品的开发，需要多学科配合协同的产品开发；（2）市场驱动的产品开发，产品需要随时判断是否满足了市场的需求，是否投入产出合适，如果不可以，需要随时终止项目的开发。
（3）项目的团队规模比较大，需要划分为多个小组进行协同工作。
小组之间的沟通是项目成功的一个制约因素。
在CMMI-DEV中包含了22个过程域。
何谓过程域（process area，简写为PA）？过程域是一类最佳实践的集合，这些最佳实践属于同一类的过程。
CMMI 中有几百条最佳实践，需要将他们分类管理，以便于实施，便于记忆。
分类的方法是人们分析、认识问题的一种主要的方法。
在CMMI中将所有的实践划分成了22类，每类中包含的实践个数从4个到14个不等。
这种分类是否就完全合理呢？仁者见仁，智者见智，没有绝对的合理，有的实践放在某个PA中很自然，有的就有点牵强，SEI就那么划分了，你就那么记忆吧。
要注意过程域与过程的概念不同，过程域是实践的集合，何谓集合？集合中的元素是没有严格的先后顺序的，是一个堆，堆是数据结构中的专业术语。
过程是活动的偏序集（偏序关系是离散数学中的专业术语），活动之间是有先后顺序的。
不要搞混了2个概念，否则是很囧的。
22个过程域可以分成4类，项目管理类、过程管理类、工程类、支持类。
总结为下表：。
cmmi实施的个人总结范文
cmmi实施的个人总结范文cmmi实施的个人总结范文篇一：CMMI总结CMM的每个等级都被分解为3个层次：关键过程域、公共特性和关键实践。
CMMI的层次：关键过程域（CMM 18个【2-5级】）：每个关键过程域所包含的关键实践涉及5个方面：执行约定、执行能力、实施活动、度量和分析、验证实施。
具体描述：1）执行约定mitment to Perform）：执行约定描述一个组织在保证将过程建立起来并持续起作用方面所必须采取的行动。
执行约定一般包含制定组织的方针和规定高级管理者的支持。
2）执行能力（Ability to Perform）：执行能力描述的是在软件过程中每个项目组或整个组织必须达到的前提条件。
执行能力一般包括资源、组织机构和培训。
3）实施活动（Active Performed）：实施活动描述的是实现一个关键过程域时所必须执行的任务和步骤。
实施活动应该包括建立计划（正式和非正式的计划）和制定步骤开展工作，对该工作进行跟踪，以及必要时进行改进的措施。
4）度量和分析（measurement and analysis）：度量和分析描述对过程进行度量的基本规则，以确定、改进和控制过程的状态。
度量和分析一般包括一些为了确定所执行活动的状态及有效性所能采用的度量和分析的例子，通过这些例子可以知道如何确定操作活动的状态和效果。
5）验证实施（Verifying implementation）：验证实施描述了保证遵照已建立的过程进行活动的措施。
验证一般包括管理者和软件质量保证部门所作的评审和审计。
CMM有两个基本用途：软件过程评估和软件能力评价。
步骤（共6步）：第一步：建立一个评估评价组。
第二步：填写提问单。
第三步：进行响应分析。
第四步：进行现场访问。
第五步：提出调查发现清单。
第六步：制作关键过程域（KPA）剖面图。
1.4.1 从初始级向可重复级过渡：初始级是CMM的起点，任何一个准备按照CMM框架等级进化的软件企业都自动地处于这一等级。
CMMI简介+过程域介绍
1.可依据组织级的资产库进行 各类评审
3级
项目估算和项目计划
2.依据组织采集指南和项目特 点进行项目的过程裁剪
风险管理 （其他同2级）
无
无
1.EPG负责过程改进工作 2.有效开展组织级培训活动
1.采取统计学计划监控项目的实际性能
根据组织级性能基线，性能模 与项目最终目标进行比较
定义组织级性能基线和模
• 自1991 年SW-CMM首次发布后，SEI 又开发了其他成熟 度模型，包括：系统工程、采购、人力资源管理和集成产 品开发等。虽然各个模型针对的专业领域不同，但彼此之 间也有一定的重叠，后SEI将各个模型整合，建立统一模 I 是一套融合多学科的、可扩充的产品集合，该模型 包含了从软件需求提出、软件设计、开发、编码、测试、 交付运行到软件退役的软件整个生存周期里各个软件过程 的各项基本要素；是软件过程的有机汇集，旨在为软件组 织改进其过程和提高其对软件产品或服务的开发、采购以 及维护的能力中提供指导。
• 通过过程域能力的角度进行选择的就是分别在每 个过程域中建立基线并度量改进结果。这种方法 在连续式表示法中得到了支持，使用的关键术语 是“能力”。
• 通过组织成熟度的角度进行选择则强调过程域集 合，这些过程域集合的目睹是用来定义整个组织 的过程成熟度的已验证阶段。在阶段式表示法中 采用了此方法，使用的关键术语是“成熟度”。
• 其所依据的想法是：只要集中精力持续努力去建立有效的 软件工程过程的基础结构，不断进行管理的实践和过程的 改进，就可以克服软件开发中的困难。
1.2 CMMI 产生的背景
• CMM 是指软件能力成熟度模型，英文缩写为SW-CMM， 简称CMM。CMM 的定义是：对于软件组织在定义、实施 、度量、控制和改善其软件过程的实践中各个发展阶段的 描述。CMM 的核心是把软件开发视为一个过程，并根据 这一原则对软件开发和维护进行过程监控和研究，以使其 更加科学化、标准化、使企业能够更好地实现商业目标。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
CMMI 基本介绍V2.0
目录
1组织成熟度级别和类别 (2)
2通用目标和通用实践 (3)
3RD 需求开发REQUIREMENTS DEVELOPMENT (4)
4REQM 需求管理REQUIREMENTS MANAGEMENT (5)
5PP 项目策划PROJECT PLANNING (6)
6PMC 项目监督和控制PROJECT MONITORING AND CONTROL (7)
7RSKM 风险管理RISK MANAGEMENT (8)
8SAM 供应商协议管理SUPPLIER AGREEMENT MANAGEMENT (9)
9CM 配置管理CONFIGURATION MANAGEMENT (10)
10PPQA 过程和产品质量保证PROCESS AND PRODUCT QUALITY ASSURANCE (11)
11MA 度量和分析MEASUREMENT AND ANALYSIS (12)
12DAR 决策分析和解决DECISION ANALYSIS AND RESOLUTION (13)
13TS 技术解决方案TECHNICAL SOLUTION (14)
14PI 产品集成PRODUCT INTEGRATION (15)
15VER 验证VERIFICATION (16)
16VAL 确认VALIDATION (17)
17OPF 组织过程聚焦ORGANIZATIONAL PROCESS FOCUS (18)
18OPD 组织过程定义ORGANIZATIONAL PROCESS DEFINITION (19)
19OT 组织培训ORGANIZATIONAL TRAINING (20)
20IPM 集成项目管理INTEGRATED PROJECT MANAGEMENT (21)
21OPP 组织过程性能ORGANIZATIONAL PROCESS PERFORMANCE (22)
22QPM 量化项目管理QUANTITATIVE PROJECT MANAGEMENT (23)
23CAR 因果分析和解决CAUSAL ANALYSIS AND RESOLUTION (24)
24OPM 组织性能管理ORGANIZATIONAL PERFORMANCE MANAGEMENT (25)
3RD 需求开发Requirements Development
目的：引出、分析和建立客户、产品及产品组件的需求。
4REQM 需求管理Requirements Management
目的：管理项目的产品及产品组件需求，并标识出这些需求与项目策划及工作产品之间的不一致性。
5PP 项目策划Project Planning 目的：建立并维护用以定义项目活动的计划。
6PMC 项目监督和控制Project Monitoring and Control
目的：目的在于了解项目的进度，以便项目在执行性能严重偏离项目策划时，可采取适当的纠正措施。
7RSKM 风险管理Risk Management
目的：风险管理的目的在于风险发生前识别出潜在问题，以便在产品或项目生命周期中，通过规划风险或请求支援等风险抵御活动，来降低实现目标过程中所带来的不利影响。
8SAM 供应商协议管理Supplier Agreement Management
目的：是管理从供应商采购产品和服务的过程。
9CM 配置管理Configuration Management
目的：是通过使用配置识别、配置控制、配置状态记录及配置审计，来建立和维护工作产品的完整性。
10PPQA 过程和产品质量保证Process and Product Quality Assurance
目的：是使项目成员与管理层客观的了解过程及相关的工作产品。
11MA 度量和分析Measurement and Analysis
目的：是开发与维持度量能力，以用于支持管理信息的需要。
12DAR 决策分析和解决Decision Analysis and Resolution
目的：在于使用正式的评估流程，根据已建立的准则评估各种已界定的备选方案，以分析可能的决策。
13TS 技术解决方案Technical Solution 目的：是为选择、设计及实现需求提供解决方案。
解决方案、设计和实现成品包括产品、
产品组件，以及与产品相关生命周期的
单一过程或适当组合的过程。
14PI 产品集成Product Integration 目的：将产品组件整合成产品，确保整合后的产品可以正确工作，且交付产品。
15VER 验证Verification
目的：目的在于确保选定的工作产品符合其指定的需求。
注重过程。
16VAL 确认Validation
目的：是在预期环境中展示产品或产品组件满足其期望价值的情况。
注重产品。
Process Focus
目的：是基于对当前组织过程和过程资产强项和弱项的充分了解，以策划、实施和开展组织过程改进。
Process Definition
目的：是建立并维护一套可用的组织过程资产和工作环境标准，以及团队规则和指导。
19OT 组织培训Organizational Training 目的：提供组织成员的技能和知识，使其能够高效的执行他们所担任角色的任务。
20IPM 集成项目管理Integrated Project Management
目的：是根据组织的标准流程对已集成和定义的流程进行裁剪，以建立和管理项目以及相关干系人的参与活动。
21OPP 组织过程性能Organizational Process Performance
目的：建立并维护对组织标准过程集中已选定的过程的量化认识，已支持取得质量与过程性能目标，并提供过程性能数据、基线及模式，来量化地管理组织地目的。
22QPM 量化项目管理Quantitative Project Management
目的：是以量化的方式管理项目，以实现项目已建立的质量和过程性能目标。
23CAR 因果分析和解决Causal Analysis and Resolution
目的：是确定已选择结果的产生原因并采取行动，改进过程性能。
24OPM 组织性能管理Organizational Performance Management
目的：是提前对组织的性能进行管理，以满足组织的商业目标。
“”
“”
At the end, Xiao Bian gives you a passage. Minand once said, "people who learn to learn are very happy people.". In every wonderful life, learning is an eternal theme. As a professional clerical and teaching position, I understand the importance of continuous learning, "life is diligent, nothing can be gained", only continuous learning can achieve better self. Only by constantly learning and mastering the latest relevant knowledge, can employees from all walks of life keep up with the pace of enterprise development and innovate to meet the needs of the market. This document is also edited by my studio professionals, there may be errors in the document, if there are errors, please correct, thank you!。