CMMI 的定义
CMMI全称是Capability Maturity Model Integration，即能力成熟度模型集成。
CMMI是世界公认的软件产品进入国际市场的通行证，不仅是对产品质量的认证，更是一种软件过程改善的途径。如果一家公司最终通过CMMI的评估认证，标志着该公司在质量管理的能力已经上升到一个新的高度。
而认证的等级越高，意味着公司质量管理能力成熟度越高，做的越好。
CMMI 的来源
1994年由美国国防部（United States Department of Defense）与卡内基-梅隆大学（Carnegie-Mellon University）下的软件工程研究中心（Software Engineering Institute，SEISM）以及美国国防工业协会（National Defense Industrial Association）共同开发和研制的
CMMI主要关注点就是成本效益、明确重点、过程集中和灵活性四个方面。
这些都可以不用关注。只要知道它是一项国际认可的认证标准即可。
CMMI的价值
CMMI为企业带来价值主要体现在以下几个方面：
1） 对开发流程进行标准化和规范化，保证项目进度和质量。
2） 有利于成本控制，缩减不必要的项目开支。
3） 建立完备的知识库，不畏惧人才流失。
4） 持续改善流程，提高质量和效率。
5） 在一些投标项目竞争中，更具有优势。——这也是一般外包公司特别重视这个证的原因。
6） 来自美国制定的国际标准，更能得到国外的认可。——所以一般软件公司要准备融资上市前都力争拿到此证的原因。
传闻有这么一个故事，在一个项目投标过程中，一家公司说，我们 CMMI 认证是5级，另外几家都是3级，所以直接中标了。
软件外包公司之所以特别重视 CMMI 的认证，也是这个原因。
软件公司也会将拿到CMMI 认证视为争取国际融资的一个重要过程。
CMMI 的结构
连续式表述（Continuous）
连续式表述可以提供最大的弹性，一个组织可以选择改善单一流程相关的问题点的绩效，或是可以使用多个领域以密切配合组织的经营目标。连续式表述允许对不同的流程执行不同等级的改善。但组织在选择上仍有一些限制，因为有一些流程领域是彼此相依赖的。
阶段式表达（Staged）
阶段式表达提供系统化结构化的方式，一次一个阶段达到以模型为基础的流程改善。达到每一个阶段可确保有足够的流程基础建设，可作为下一个阶段流程改善的基础。
连续式表达和阶段式表达图示如下：
常见的 CMMI 等级为阶段式表达。
CMMI 的等级
CMMI 等级共五级， Maturity Levers，通常简写为 ML。
ML1初始级
软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。
ML2已管理级
建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。
ML3已定义级
已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。
ML4量化管理级
分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。
ML5优化级
过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。
默认情况下，任何一家软件公司都可以认为是1级。
2级比较容易做到，3级的要求要多很多，一般来说建议2、3级一起来做。3级到4级间跨度和难度较大。但如果4级做得比较好，要做到5级难度不算很大。
参考示意图如下：
而评估的时候，如果2级的标准达到，但3级的要求达不到，就算4级的要求达到了，也只能算2级。
CMMI的各级标准
先理解过程域的概念。过程域（Process Area），简称 PA，简单的说就是软件开发过程中的某一个方面。
每个ML等级都被分解为若干个过程域。
如上图，PA 共22个，2级有7个PA，3级有11个PA，4级有2个PA，5级有2个PA。各个过程域对应的名称及释义如下:
CMMI等级 |
缩写 |
过程域英文名称 |
过程域中文名称 |
过程域的释义 |
类别 |
ML1 |
|
|
|
|
|
ML2 |
CM |
Configuration Management |
配置管理 |
建立和维护在项目的整个软件生存周期中软件项目产品的完整性 |
支持管理 |
MA |
Measurement and Analysis |
测量与分析 |
开发和维持度量的能力，以便支持对管理信息的需要，作为改进、了解、控制决策 |
支持管理 |
|
PPQA |
Process and Product Quality Assurance |
过程和产品质量保证 |
为项目组和管理层提供项目过程和相关工作产品的客观信息 |
支持管理 |
|
PMC |
Project Monitoring and Control |
项目监督与控制 |
通过项目的跟踪与监控活动，及时反映项目的进度、费用、风险、规模、关键计算机资源及工作量等情况，通过对跟踪结果的分析，依据跟踪与监控策略采取有效的行动，使项目组能在既定的时间、费用、质量要求等情况下完成项目 |
项目管理 |
|
PP |
Project Planning |
项目计划 |
保证在正确的时间有正确的资源可用，为每个人员分配任务、协调人员，根据实际情况，调整项目 |
项目管理 |
|
REQM |
Requirements Management |
需求管理 |
需求管理的目的是在客户和软件项目之间就需要满足的需求建立和维护一致的约定 |
项目管理 |
|
SAM |
Supplier Agreement Management |
供应商协议管理 |
旨在对以正式协定的形式从项目之外的供方采办的产品和服务实施管理 |
项目管理 |
|
ML3 |
DAR |
Decision Analysis and Resolution |
决策分析与解决方案 |
应用正式的评估过程依据指标评估候选方案，在此基础上进行决策 |
支持管理 |
IPM |
Integrated Project Management |
集成项目管理 |
根据从组织标准过程剪裁而来的集成的、定义的过程对项目和利益相关者的介入进行管理 |
项目管理 |
|
OPD |
Organizational Process Definition |
组织级过程定义 |
建立和维护有用的组织过程资产 |
过程管理 |
|
OPF |
Organizational Process Focus |
组织级过程焦点 |
在理解现有过程强项和弱项的基础上计划和实施组织过程改善 |
过程管理 |
|
OT |
Organizational Training |
组织培训管理 |
增加组织各级人员的技能和知识，使他们能有效地执行他们的任务 |
过程管理 |
|
PI |
Product Integration |
产品集成 |
从产品部件组装产品，确保集成产品功能正确并交付产品 |
工程管理 |
|
RD |
Requirements Development |
需求开发 |
需求开发的目的在于定义系统的边界和功能、非功能需求，以便涉众(客户、最终用户)和项目组对所开发的内容达成一致 |
工程管理 |
|
RSKM |
Risk Management |
风险管理 |
识别潜在的问题，以便策划应对风险的活动和必要时在整个项目生存周期中实施这些活动，缓解不利的影响，实现目标 |
项目管理 |
|
TS |
Technical Solution |
技术解决方案 |
在开发、设计和实现满足需求的解决方案，解决方案的设计和实现等都围绕产品、产品组件和与过程有关的产品 |
工程管理 |
|
VAL |
Validation |
确认 |
确认证明产品或产品部件在实际应用下满足应用要求 |
工程管理 |
|
VER |
Verification |
验证 |
验证确保选定的工作产品满足需求规格 |
工程管理 |
|
ML4 |
OPP |
Organizational Process Performance |
组织过程绩效 |
建立与维护组织过程性能的量化标准，以便使用量化方式的管理项目 |
过程管理 |
QPM |
Quantitative Project Management |
量化的项目管理 |
量化管理项目已定义的项目过程，以达成项目既定的质量和过程性能目标 |
项目管理 |
|
ML5 |
CAR |
Causal Analysis and Resolution |
因果分析与解决方案 |
识别缺失的原因并进行矫正，进一步的防止未来再次发生 |
支持管理 |
OPM |
organizational performance management |
组织绩效管理 |
选择并推展渐进创新的组织过程和技术改善，改善应是可度量的，所选择及推展的改善需支持基于组织业务目的的质量及过程执行目标 |
过程管理 |
每个过程域有明确的目标(Goal)和实践(Practice)，必须要达到该等级所有过程域的目标，才可达到该等级。而达成目标的方式，即要完成这个目标对应的所有实践。
目标和实践又包含：
GG(Generic Goals)，中文名为通用目标，对应GP(Generic Practices)，中文名为通用实践，应用于能力维度，所以适用于所有关键过程域。
SG(Specific Goals)，中文名为特定目标，对应SP(Specific Practices)，中文名为特定实践，应用于过程维度，只能适用某一特定关键过程域
CMMI 的等级、过程域、目标和实践的关系如下：
中文图示为：
CMMI级别、PA、Goal与Practice的详细清单如下：
通用目标中文 |
通用实践中文 |
交付物 |
GG1 完成特定目标 |
GP 1.1 执行特定实践 |
|
GG2 制度化已管理的过程 |
GP 2.1 建立组织政策 |
|
GP 2.2 过程计划 |
|
|
GP 2.3 提供资源 |
|
|
GP 2.4 分配职责 |
|
|
GP 2.5 人员培训 |
|
|
GP 2.6 管理配置项 |
|
|
GP 2.7 识别并引入相关的利益相关者 |
|
|
GP 2.8 监督和控制过程 |
|
|
GP 2.9 坚持客观的评价 |
|
|
GP 2.10 更高层领导审核状态 |
|
|
GG3 制度化已定义的过程 |
GP 3.1 建立一个已定义的过程 |
|
GP 3.2 收集（经验）改进信息 |
|
CMMI等级 |
缩写 |
过程域中文名称 |
特定目标中文 |
特定实践中文 |
交付物 |
ML1 |
|
|
|
|
|
ML2 |
CM |
配置管理 |
SG1 建立基线 |
SP 1.1 识别配置项 |
配置计划 |
SP 1.2 建立配置管理系统 |
配置计划 |
||||
SP 1.3 创建或发布基线 |
配置计划 |
||||
SG2 跟踪并控制变更 |
SP 2.1 跟踪变更请求 |
变更控制、变更申请、分析变更记录 |
|||
SP 2.2 控制变更 |
变更控制、变更申请、分析变更记录 |
||||
SG3 建立完整性 |
SP 3.1 建立配置管理记录 |
功能审计、物理审计 |
|||
SP 3.2 执行配置审计 |
功能审计、物理审计 |
||||
MA |
测量与分析 |
SG1 协调度量和分析活动 |
SP 1.1 确定度量目标 |
度量计划 |
|
SP 1.2 细化度量 |
度量计划 |
||||
SP 1.3 确定数据收集和存储规程 |
度量计划、度量数据表 |
||||
SP 1.4 确定分析规程 |
度量计划、度量数据表 |
||||
SG2 提供度量结果 |
SP 2.1 收集度量数据 |
度量计划 |
|||
SP 2.2 分析度量数据 |
|
||||
SP 2.3 存储数据和度量结果 |
|
||||
SP 2.4 通报度量结果 |
里程碑报告 |
||||
PPQA |
过程和产品质量保证 |
SG1 客观评价过程与工作产品 |
SP1.1客观评价过程 |
|
|
SP1.2客观评价工作产品 |
过程检查表、不符合项报告、工作记录 |
||||
SG2 提供客观洞察 |
SP2.1沟通并解决不符合问题 |
产品检查表、工作记录 |
|||
SP2.2建立记录 |
|
||||
PMC |
项目监督与控制 |
SG1 对照计划监督项目 |
SP1.1监督项目计划参数 |
MPP、周报、项目进展报告 |
|
SP1.2监督承诺 |
项目进展报告 |
||||
SP1.3监督项目风险 |
风险识别表 |
||||
SP1.4监督数据管理 |
SVN/配置管理 |
||||
SP1.5监督干系人的参与 |
MPP、项目计划 |
||||
SP1.6进行进展评审 |
里程碑报告、周报、会议纪要 |
||||
SP1.7进行里程碑评审 |
会议纪要 |
||||
SG2 管理纠正措施直至关闭 |
SP2.1分析问题 |
项目进展报告、项目偏差报告 |
|||
SP2.2采取纠正措施 |
项目进展报告 |
||||
SP2.3管理纠正措施 |
项目进展报告 |
||||
PP |
项目计划 |
SG1 建立估算 |
SP 1.1 估算项目的范围 |
项目计划（WBS分解结构） |
|
SP 1.2 估算项目属性 |
项目计划（WBS分解结构） |
||||
SP 1.3 定义项目生存周期阶段 |
项目计划（WBS分解结构） |
||||
SP 1.4 估算工作量和成本 |
项目计划（WBS分解结构） |
||||
SG2 制定项目计划 |
SP2.1建立预算与进度 |
项目计划（WBS分解结构） |
|||
SP2.2识别项目风险 |
风险识别表 |
||||
SP2.3计划数据管理 |
配置管理、项目计划 |
||||
SP2.4计划项目资源 |
项目计划（WBS分解结构-带资源要求） |
||||
SP 2.5 知识和技能的计划 |
培训计划（项目计划一部分） |
||||
SP2.6计划干系人的参与 |
项目计划（WBS分解结构） |
||||
SP 2.7 制定项目计划 |
项目计划（WBS分解结构） |
||||
SG3 获得对计划的承诺 |
SP 3.1 审查从属计划 |
项目计划、项目子计划评审报告 |
|||
SP 3.2 协调工作与资源配置 |
调整后的计划 |
||||
SP 3.3 获得计划承诺 |
计划评审（计划及会议纪要） |
||||
REQM |
需求管理 |
SG1 管理需求 |
SP1.1理解需求 |
用户需求书（客户签字） |
|
SP1.2获得对需求的承诺 |
用户需求书评审报告 |
||||
SP1.3管理需求变更 |
需求变更申请 |
||||
SP1.4维护需求的双向可追溯性 |
需求追踪矩阵 |
||||
SP1.5确保项目工作与需求间的协调一致 |
不一致检查表 |
||||
SAM |
供应商协议管理 |
SG1 建立供应商协议 |
SP 1.1 确定采购方式 |
|
|
SP 1.2 选择供应商 |
|
||||
SP 1.3 签定供应商协议 |
|
||||
SG2 履行供应商协议 |
SP 2.1 执行供应商协议 |
|
|||
SP 2.2 监督选定的供应过程 |
|
||||
SP 2.3 评价供应商产品 |
|
||||
SP 2.4 验收采购的产品 |
|
||||
SP 2.5 移交产品 |
|
||||
ML3 |
DAR |
决策分析与解决方案 |
SG1 运用建立的准测评价候选方案，作为决策的基础 |
SP 1.1 建立决策分析指导原则 |
决策分析报告 |
SP 1.2 建立评价准则 |
决策分析报告 |
||||
SP 1.3 确定候选解决方案 |
决策分析报告 |
||||
SP 1.4 选择评价方法 |
决策分析报告 |
||||
SP 1.5 评价候选方案 |
决策分析报告 |
||||
SP 1.6 选择解决方案 |
决策分析报告 |
||||
IPM |
集成项目管理 |
SG1 应用项目定义过程 |
SP 1.1 建立项目定义过程 |
项目过程定义书 |
|
SP 1.2 利用组织过程财富规划项目活动 |
项目过程定义书 |
||||
SP 1.3 建立项目工作环境 |
项目过程定义书，项目计划 |
||||
SP 1.4 集成计划 |
项目计划、附属子计划 |
||||
SP 1.5 利用集成计划管理项目 |
周报及进展报告 |
||||
SP 1.6 充实组织过程财富 |
过程改进建议 |
||||
SG2 与相关干系人协调和合作 |
SP 2.1 管理干系人的介入 |
项目计划 |
|||
SP 2.2 管理依存关系 |
项目计划 |
||||
SP 2.3 解决协调问题 |
项目计划 |
||||
OPD |
组织级过程定义 |
SG1 建立并维护一套组织过程资产 |
SP 1.1 建立标准过程 |
组织过程定义过程文件 |
|
SP 1.2 建立生存周期模型描述 |
生命周期指南、生命周期模型、组织过程定义文件 |
||||
SP 1.3 建立裁剪准则和指南 |
裁剪指南 |
||||
SP 1.4 建立组织度量库 |
组织级度量库 |
||||
SP 1.5 建立组织过程财富库 |
组织级财富库 |
||||
SP 1.6 建立工作环境标准 |
组织过程标准 |
||||
OPF |
组织级过程焦点 |
SG1 确定过程改进机会 |
SP 1.1 建立组织过程的需要 |
组织过程焦点的规章制度 |
|
SP 1.2 评估组织过程 |
预评估报表幻灯片 |
||||
SP 1.3 识别组织的过程改进机会 |
过程改进计划（评审后） |
||||
SG2 规划和实施过程改进 |
SP 2.1 制定过程行动计划 |
过程改进建议 |
|||
SP 2.2 实施过程行动计划 |
MSG会议记录 |
||||
SG3 部署组织过程财富 |
SP 3.1 部署组织过程财富 |
试点项目导入计划 |
|||
SP 3.2 部署标准过程 |
试点项目导入计划 |
||||
SP 3.3 监督实施 |
配置管理过程文件、基线发布通知 |
||||
SP3.4 过程相关的经验纳入组织过程财富 |
组织过程资产库、项目总结报告、项目评审报告 |
||||
OT |
组织培训管理 |
SG1 建立组织级培训能力 |
SP 1.1 确定战略培训需求 |
培训计划 |
|
SP 1.2 确定由组织负责的培训需求 |
年度培训计划 |
||||
SP 1.3 建立组织培训计划 |
年度培训计划 |
||||
SP 1.4 建立培训能力 |
|
||||
SG2 提供必要的培训 |
SP 2.1 交付培训 |
培训计划、月报 |
|||
SP 2.2 建立培训记录 |
学员反馈表、签到表 |
||||
SP 2.3 评价培训效果 |
部门培训反馈表、培训师评估表 |
||||
PI |
产品集成 |
SG1 准备产品集成 |
SP 1.1 确定集成次序 |
产品集成方案 |
|
SP 1.2 建立产品集成环境 |
产品集成方案 |
||||
SP 1.3 建立产品集成规程和准则 |
产品集成方案、测试用例 |
||||
SG2 确保接口兼容性 |
SP2.1评审接口描述的完整性 |
产品集成方案 |
|||
SP2.2管理接口 |
产品集成方案 |
||||
SG3 装配产品组件并交付产品 |
SP3.1确定需集成的产品组件准备就绪 |
单元测试BUG管理表、代码走查表 |
|||
SP 3.2 组装产品构件 |
产品集成方案 |
||||
SP 3.3 核查组装的产品构件 |
集成测试总结报告、BUG管理表 |
||||
SP3.4打包并交付产品或产品组件 |
产品交付确认单 |
||||
RD |
需求开发 |
SG1 开发客户需求 |
SP 1.1 获取客户的需要 |
用户需求调查表、DemoBS、DemoCS |
|
SP 1.2 生成客户需求 |
用户需求说明书、需求功能列表 |
||||
SG2 开发产品需求 |
SP 2.1 建立产品需求和构件需求 |
需求规格说明书 |
|||
SP 2.2 分配产品构件需求 |
需求规格说明书 |
||||
SP 2.3 确定接口需求 |
需求规格说明书 |
||||
SG3 分析并确认需求 |
SP 3.1 建立操作概念和场景 |
需求规格说明书（用例图） |
|||
SP 3.2 定义功能需求 |
需求规格说明书 |
||||
SP 3.3 分析需求 |
需求规格说明书 |
||||
SP 3.4 平衡需求 |
需求规格说明书 |
||||
SP 3.5 确认需求 |
需求规格说明书评审会议纪要 |
||||
RSKM |
风险管理 |
SG1 准备风险管理 |
SP 1.1 确定风险来源和类别 |
风险库 |
|
SP 1.2 定义风险参数 |
风险库 |
||||
SP 1.3 建立风险管理策略 |
风险库 |
||||
SG2 识别并分析风险 |
SP 2.1 识别风险 |
风险识别跟踪表 |
|||
SP 2.2 风险评估、分类和确定优先级 |
风险识别跟踪表 |
||||
SG3 缓解风险 |
SP 3.1 制定风险缓解计划 |
风险识别跟踪表 |
|||
SP 3.2 实施风险缓解计划 |
风险识别跟踪表 |
||||
TS |
技术解决方案 |
SG1 选择产品构件方案 |
SP 1.1 开发候选方案和选择准则 |
候选技术解决方案、决策分析报告 |
|
SP 1.2 选择产品构件方案 |
产品解决方案、决策分析报告 |
||||
SG2 开发设计 |
SP 2.1 设计产品或构件 |
概要、详细、数据库设计 |
|||
SP 2.2 建立技术数据包 |
概要、详细、数据库设计 |
||||
SP 2.3 设计接口 |
概要、详细、数据库设计 |
||||
SP 2.4 分析制作、购买或重用 |
项目计划 |
||||
SG3 实现产品设计 |
SP 3.1 实现构件的设计 |
代码说明书、代码确认单 |
|||
SP 3.2 编写产品支持文档 |
操作手册、培训文档、安装维护手册 |
||||
VAL |
确认 |
SG1 准备确认 |
SP1.1选择需要确认的产品 |
测试计划 |
|
SP1.2建立确认环境 |
测试计划 |
||||
SP1.3建立确认规程与准则 |
测试计划 |
||||
SG2 确认产品或产品组件 |
SP2.1执行确认 |
测试脚本、BUG管理表 |
|||
SP2.2分析确认结果 |
产品交付确认单 |
||||
VER |
验证 |
SG1 准备验证 |
SP1.1选择待验证的工作产品 |
项目计划、测试计划 |
|
SP1.2建立验证环境 |
项目计划、测试计划 |
||||
SP1.3建立验证规程与准则 |
项目计划、测试计划 |
||||
SG2 执行同行评审 |
SP 2.1 准备同行评审 |
测试报告评审报告 |
|||
SP 2.2 执行同行评审 |
测试报告评审报告 |
||||
SP 2.3 分析同行评审数据 |
测试报告评审报告 |
||||
SG3 验证选定的工作产品 |
SP3.1执行验证 |
测试总结报告、BUG管理表 |
|||
SP3.2分析验证结果 |
测试总结报告、BUG管理表 |
||||
ML4 |
OPP |
组织过程绩效 |
SG1 建立基线和模型 |
SP 1.1 选择过程 |
|
SP 1.2 建立过程性能度量 |
|
||||
SP 1.3 建立质量和过程性能目标 |
|
||||
SP 1.4 建立过程性能基线 |
|
||||
SP 1.5 建立过程性能模型 |
|
||||
QPM |
量化的项目管理 |
SG1 定量项目管理 |
SP 1.1 建立项目目标 |
|
|
SP 1.2 组成项目定义过程 |
|
||||
SP 1.3 选择用于定量管理的子过程 |
|
||||
SP 1.4 管理项目性能 |
|
||||
SG2 统计管理子过程性能 |
SP 2.1 选择度量和分析技术 |
|
|||
SP 2.2 运用统计方法理解过程变动 |
|
||||
SP 2.3 监督选定的子过程性能 |
|
||||
SP 2.4 记录统计管理数据 |
|
||||
ML5 |
CAR |
因果分析与解决方案 |
SG1 确定缺陷原因 |
SP 1.1 选择待分析的缺陷数据 |
|
SP 1.2 分析原因 |
|
||||
SG2 解决产生缺陷的根源 |
SP 2.1 实施行动建议 |
|
|||
SP 2.2 评价变更的效果 |
|
||||
SP 2.3 记录数据 |
|
||||
OPM |
组织绩效管理 |
SG 1 选择改进 |
SP 1.1 收集和分析改进建议 |
|
|
SP 1.2 识别革新 |
|
||||
SP 1.3 试点改进 |
|
||||
SP 1.4 选择用于部署的改进 |
|
||||
SG 2 部署改进 |
SP 2.1 计划部署 |
|
|||
SP 2.2 管理部署 |
|
||||
SP 2.3 度量改进效果 |
|
目标(Goal)一共有 x 个，实践（Practice）一共400+。
CMMI的评估办法
SCAMPI（Standard CMMI Appraisal Method for Process Improvement），是CMMI的评估方法。这种评估方法又划分成了3种严格程度，分别为 Class A，Class B，Class C。
三种方法的大概区别见下表，很多细的区别需要去看评估方法的定义文件。
需求 |
Class A |
Class B |
Class C |
采集证据方法的类型 |
均采用文档审查与访谈的方法 |
||
是否需要进行评分 |
针对目标打分，评估是否满足模型要求 |
不要求进行评分 |
|
组织单元的覆盖率 |
输出评估报告，给出成熟度级别 |
不需给出成熟度级别 |
|
SEI 注册 |
主任评估师向SEI注册评估结果 |
不需向 SEI 注册 |
|
组织单元的覆盖率 |
覆盖被评估的所有的部门 |
不要求覆盖所有的部门 |
|
评估团队的最少人数 |
组建正式评估小组 |
不需组建正式评估小组 |
|
评估团队的最少人数 |
需满足ARC要求 |
满足部分ARC要求 |
更少ARC要求 |
评估团队的最少人数 |
4 |
2 |
1 |
对评估组长的要求 |
SEI授权的主任评估师领导评估组进行评估 |
可以是主任评估师，也可是已参加培训有经验的 |
|
对评估组的要求 |
25年以上工程经验，平均工程经验超过6年 |
|
|
对评估组管理经验的要求 |
10年以上管理经验，至少有1人超过6年 |
|
|
对评估组成员的要求 |
至少有2人是过程改进的参与者 |
|
|
对评估组成员的要求 |
不能是被访谈人员的上级管理者 |
||
对评估组成员的要求 |
均接受过introduction to CMMI 及SCAMPI评估方法的培训 |
||
可见， Class A类评估是正式的标准过程，也是最为严格的，目的是获得评估等级，评估过程需执行所有的评估步骤。按照SEI SCAMPI评估方法1.2版本的要求，CMMI评估的结论是3年有效期，即3年后需要重新评估。