前言
CMMI是英文Capability Maturity Model Integration的缩写。
CMMI认证简称软件能力成熟度集成模型，是鉴定企业在开发流程化和质量管理上的国际通行标准，全球软件生产标准大都以此为基点，并都努力争取成为CMMI认证队伍中的一分子。
它最早是应用于软件业的一个过程改进模型，为软件组织描述了从混乱的、不成熟的软件过程向成熟有序的软件过程进行改进的一条途径。后来随着应用的推广和模型本身的发展，CMMI逐渐演化成为一个被广泛应用的综合性过程改进模型。
- 来自政府与产业界的有关开发的最佳实践集合。
- CMMI主要规定了不同的实践域，不同的过程域有不同的“目标和实践” 。
对一个软件企业来说，达到CMMI2就基本上进入了规模开发，基本具备了一个现代化软件企业的基本架构和方法，具备了承接外包项目的能力。CMMI3评估则需要对大软件集成的把握，包括整体架构的整合。
CMMI 首先是评价流程，流程评价三个特定领域：过程和服务开发，服务建立和管理、产品和服务获取。对于使用了 CMMI 的公司来说，其目的在于使组织达到成熟度等级 5 级。
当企业的软件能力成熟度发展到这个程度时，CMMI将不再被采用，企业将更加注重软件产品的定期改进与维护保养。
在软件企业中，通过 CMMI 的等级越高，则说明该企业的能力成熟度越高，相应的开发的产品质量也越高，用户对于企业产品也就越满意，同时企业所具有的生产开发组织对于软件产品的研发也更成熟。
CMMI 过程及产品质量保证，主要是站在客观的角度对软件产品研发过程及其产品进行监测和审核，并向项目成员及管理人员提供相关结果。
一般来说，通过CMMI认证的级别越高，其越容易获得用户的信任，在国内、国际市场上的竞争力也就越强。
基本思想
1、解决软件项目过程改进难度增大问题。
2、实现软件工程的并行与多学科组合。
3、实现过程改进的最佳效益。
CMMI并不强调所有的软件企业都采用统一的管理模式和规范，而是提供一系列评估的指标，帮助企业在 原有基础上进一步实现规范化管理，比如企业的文档之间是否保持一致性、软件开发人员的管理是否严格、开发的软件是否经过严格测试等等。CMMI对企业的要求和帮助基于CMMI模型的软件成熟度实践要求企业尽量采用更加规范的开发标准和方法，使用更加科学和精确的度量手段，选择更便于管理和使用的开发工具。
因此，造成了整个工程的可重构性、可分解性和最优化，明确了整个项目中必要和不必要的工作，明确了整个项目的风险。
在实践域中，这些实践被分类到一组演进的等级中，分别称为第1级、第2级，以此类推。这样的等级划分为性能改进提供了一条途径。
每个演进的等级都基于以前的等级，然后增加新的功能或熟练性，从而提高了能力。
通常来说，软件的质量很大程度上取决于开发团队的能力和管理水平。特别是对于大型软件项目开发而言，整个团队的管理能力对质量起着关键性的作用。要确定软件的优质程度，主要取决于开发团队成员是否称职，以及他们的管理水平是否过硬。CMMI 应用场景是为了对软件功能进行评价，不断地完善软件。
双软企业
双软企业是集企业的软件开发、技术装备、开发环境、人员配置及学历构成、质量标准、服务体系、经营业绩等为一体的综合性标准。企业的软件著作权登记、软件检测、软件产品登记、软件企业认证四方面内容,是衡量企业软件研发能力与整体技术实力的重要标准,是软件企业证明自身IT实力的重要指标。
项目管理
CMMI L5将度量统计技术用于项目管理
1、EPG需要掌握的度量统计技术
1.正态性检验，求得历史项目的均值，标准差。
2.对历史项目进行相关性分析，建立未来项目的回归方程。
3.通过回归方程对项目的目标可能性进行预测。
4.历史项目与试点项目双样本检验，分析改进的有效性。
5.试点项目样本能力分析，分析达成目标的有效性。
2、项目经理需要掌握的度量统计技术
1.使用回归方程来做项目计划。
3、使用工具
Minitab工具、Crystal Ball-水晶球风险管理软件。
人均生产力，总工作目标（人天），项目延误率，外部缺陷密度，均值，标准差，上限，下限，
决策变量，过程方法，控制因子，缺陷密度（回归），执行结果，单位工作量，缺陷密度（回归），注入/发现缺陷密度，缺陷个数，动态预测工作量（人日），计算工作量（人日），实际工期偏差，剩余工作量（人日），估算产品规模，阶段人数，计划工期，实际产品规模，实际任务完成百分比，实际缺陷率，缺陷密度模型公式。
编码人均生产力=1.22+0.522代码复用率-2.55需求变更率
系统测试发现缺陷密度=-1.45+0.247测试用例深度+16.2单位工作量
文档附录(名称/要求)
需求（需求人员） 需求调研计划
1.需要包含客户的名称
需求调研记录（要求多份）
1.需要有项目中的具体业务的问题
2.一般会有多份调研记录
3.一般包含调研问卷、客户调查记录、需求调研报告等
用户需求
1.包含需求的优先级内容，形式可以为用户需求说明书/需求调研报告/用户需求清单等
2.需要包含：
（1）使用软件的情况描述（场景—拓扑图）
（2）使用软件功能方法（操作部分—业务流程图）
（3）功能描述
（4）性能要求（具体数字）
（5）接口（内外部接口）
需求确认单
1.此份材料为与用户完成确认需求的整句，需要有用户的签字
产品需求（《需求规格说明书》）
1.内容中包含需求的具体规格信息，包括功能、性能、接口等
2.如在用户需求文档中已包含此类信息，可进行合并，但内容须齐全
需求承诺书
1.此份材料为项目团队内部对完成需求的承诺，需要项目组成员签字
需求跟踪矩阵
1.包含完整的业务模块（功能需求）、性能要求、接口要求的跟踪信息
2.须包含以下阶段的内容：用户需求、产品需求、设计（可以是概设详设分开）、源代码、测试用例
3.需求跟踪一定要有代码部分，类名/方法名/代码的具体路径都可以
4.此文档按照项目推进的各个阶段同步交由此阶段负责人进行跟踪信息维护
需求评审记录
1.需要包含：
（1）评审准备表
（2）评审检查单
（3）评审报告
2.评审方式必须与过程组合中的方式、项目已定义过程表内容一致
3.评审发现的问题数量至少3个以上，须和组织的基线（PPB）一致
4.评审检查单，需要核对需求的场景、操作、完整性、一致性、可实现性、与需求的不一致问题等内容
需求变更记录
1.需求基线建立之后的变更记录，通常不少于三次变更
2.包含变更汇总表、变更申请单等材料；
3.变更申请单中，需要包含：
（1）变更的影响分析
（2）变更涉及的文档及具体模块
（3）涉及到设计文档中的内容
4.需求变更记录与配置中的配置项记录有关联，即配置项变更中，涉及需求变更的部分，在需求变更记录中须体现
需求沟通记录
1.就需求内容与客户沟通的记录，以客户接受/客户妥协为标准
2.鉴于与需求变更相结合，最终客户接受/客户妥协记录，可以有多种形式，包括会议纪要、与客户沟通的邮件记录等
设计（设计人员） 技术解决方案
1.需要包含
（1）不同的技术选型
（2）选择的方法及结果
（3）候选方案的选择方式、方案说明、优缺点
技术决策过程记录
1.选择技术方案的记录文档
2.决策分析的报告
设计说明书
1.需要包含：
（1）概要设计文档
（2）详细设计文档
（3）接口设计文档
（4）其他设计文档（数据库设计和界面设计等）
复用分析
1.按模块整理的复用分析，一般要说明具体复用的部分和复用的程度
设计评审记录
1.需要包含：
（1）评审检查单
（2）评审准备表
（3）评审报告……
技术文档清单
1.一般是设计基线中所包含的文档部分，可以是一个单独的文档，里面是具体的文档名称的清单
编码（编码人员）
源代码
1.说明：源代码的编译截图
代码走查记录
1.代码走查检查单
单元测试记录
1.单元测试用例
Bug记录
1.代码走查
2.单元测试的Bug记录
用户手册
集成（编码人员） 集成记录
1.需要包含：
（1）集成计划：包含集成的策略、顺序、集成方法、集成入口和出口的准则
（2）接口检查单
（3）集成环境检查单
（4）集成报告
集成测试记录
1.需要包含：
（1）集成测试计划
（2）集成测试用例
（3）集成测试报告
Bug记录
测试（测试人员） 系统测试记录
1.需要包含：
（1）计划
（2）用例
（3）Bug表
（4）报告
2.需要包含功能和性能两类测试
Bug记录
性能测试记录
1.需要包含：
（1）性能测试计划
（2）性能测试报告/压力测试报告
交付（测试人员） 试运行记录
1.需要包含：
（1）计划
（2）日志
（3）报告
移交记录（项目经理、测试人员）
1.需要包含：
（1）计划
（2）移交清单
（3）移交确认单
（4）移交产品的培训记录
计划（项目经理） 估算表
1.为业务模块的规模估算，需要包含：
（1）估算的方法
（2）模块功能点的计算方法（代码行时，需要说明什么样的代码算有效代码）
（3）估算的方法（专家估算法、三点估算法等）
（4）由规模计算得到工作量、工期、成本
2.估算表中的工作两部分，需要来自项目的量化管理预测之后得到
项目已定义过程表
1.需要包含：
（1）生命周期、过程、产出的选择
（2）剪裁或调整的部分，需要明确具体的理由
（3）所包含文档部分，和实际产出的文档一致
（4）评审的方式，与计划及产出的文档一致
2.与过程结合相关的部分，内容要和组合的结果一致：例如组合在前、剪裁在后，项目已定义过程文档，是先把组合的结果放进来，再剪裁其他的部分
项目计划
进度计划
1.可以是Project文档形式，也可以使Excel文档形式，需要包含：
（1）项目中所有的活动，包括管理和工程
（2）每个活动安排具体的人员
（3）工期和工作量应该与估算表得到的结论一致
计划评审记录
1.需要包含：
（1）评审检查单
（2）评审准备表
（3）评审报告
计划承诺书
1.需要包含：
（1）项目组所有成员的签字，并且需要明确说明，可以按计划中的时间完成相应的内容，同意之后进行签字
监控（项目经理） 例会会议纪要
1.会议纪要评率须与项目计划中的要求一致，一般为周例会会议纪要，内容包含：
（1）对应时间点的问题单和风险表中的内容
（2）对问题的处理
项目周报
1.即每周的周报，需要包含：
（1）进度的跟踪情况、工作量的跟踪情况、工期的跟踪情况，计划的数字要和估算表一致，实际进度不能和计划的完全一样（会有偏差）
（2）问题的跟踪
（3）风险的跟踪
（4）原因分析启动的跟踪
（5）评审活动的跟踪
（6）干系人及关键以来的跟踪
（7）度量数据检查
（8）度量数据异常跟踪
2.周报中的数字，需要和里程碑报告的数字一致
里程碑记录
1.需要包括：
（1）里程碑会议纪要
（2）里程碑报告
2.里程碑报告，需要包含：
（1）周报里面的信息汇总
（2）发现问题及解决问题的数量
（3）本阶段的改进建议、执行的改进、应用的组织资产、可以提交给组织的资产
问题记录
1.需要包含：
（1）管理类的问题
（2）工程方面的问题
（3）度量数据的问题
（4）需要进行原因分析的问题
（5）量化管理中的问题
2.项目问题表中，问题部分要和周报、会议纪要一致；问题的数量要和里程碑报告、项目度量表一致
原因分析记录
1.需要包含：
（1）原因分析过程，例如问题部分、分析原因（例如鱼骨图列出所有可能的原因，并筛选、确定原因）
（2）收集解决措施（即针对确定之后的原因给出解决措施）
（3）选择解决措施
（4）执行记录（包含收集措施执行后的数据、会议纪要和周报里面的跟踪）
（5）效果分析
（6）提出的改进建议（包括标准过程、指南、模板或技术、工具等方面）
2.需要包含：
（1）项目管理类型的内容
（2）类型化缺陷方面的内容
（3）度量数据方面的内容
（4）量化管理方面的内容（目标不达标、关键数据异常、不满足组织基线等）
度量（项目经理） 项目度量计划
1.需要包含：
（1）来自业务目标的度量信息
（2）度量的操作定义和度量的方法
（3）使用的技术及工具
度量数据检查单
1.需要包含判断度量数据异常的标准
项目度量表
1.数据需要和项目周报、里程碑报告中的数据一致
2.分析的部分，要和度量计划中要求的方法一致，需要有对应的折线图、直方图、饼图、控制图（可以在量化管理里面）
3.要有异常的数据（例如偏差大于20%的情况），并有对应的原因分析
4.工作量、工期、规模的部分，要和估算一致，数据要和里程碑报告一致
5.缺陷的部分，要和对应Bug记录一致
风险（项目经理） 风险管理计划与跟踪表
1.需要包含风险和机会两部分内容：
（1）风险的分类
（2）识别方式
（3）处理机制
（4）识别出来的风险清单、系数、应对及结果
（5）周期性跟踪的记录
2.需要包含：
（1）管理类风险
（2）工程类风险
（3）量化风险
3.风险识别和跟踪，与周报中的一致，同时在项目例会中体现识别和跟踪的情况
评审（项目经理、需求人员）
评审计划（包含评审对象及评审方法）
1.需要包含：
（1）评审对象
（2）评审方法
评审检查单
计划评审
1.需要包含：
（1）评审准备表（预审记录）
（2）评审报告
需求评审（需求人员）
1.需要包含：
（1）评审准备表（预审记录）
（2）评审报告
设计评审（设计人员）
1.需要包含：
（1）评审准备表（预审记录）
（2）评审报告
用例评审
1.需要包含：
（1）评审准备表（预审记录）
（2）评审报告
支持文档评审
1.需要包含：
（1）评审准备表（预审记录）
（2）评审报告
（3）用户手册评审
评审数据汇总表
1.评审效率、发现缺陷密度通常和组织的极限数据一致；
2.当出现数据不一致时，需要有相应的原因分析报告，作为原因分析和度量数据异常的处理证据
决策（项目经理、设计人员） 决策分析计划
1.可以包含在项目计划中，需要说明：
（1）启动决策的时间
（2）决策权限的划分方式
管理决策
1.需要包含：
（1）候选方案
（2）决策准则
（3）决策方法
（4）决策打分表
（5）决策结果
技术决策（设计人员）
1.技术决策与设计阶段的决策对应，需要包含：
（1）候选方案
（2）决策准则
（3）决策方法
（4）决策打分表
（5）决策结果
量化管理（项目经理） 项目QPPO
1.需要包含：
（1）组织的性能目标要求
（2）项目根据规模得到的过程和性能目标（工作量、进度、成本目标）
（3）过程组合的结果
（4）目标达成率分析的结果
项目量化管理表
1.需要包含：
（1）立项时的过程组合
（2）可控因子调整
（3）项目的关键子过程选择方法和结果
（4）监控性能度量项的选择方法和结果
（5）统计和量化技术的选择结果（监控的分析方法）
（6）度量数据的采集频率
2.项目的量化监控预测管理表，针对阶段目标达成率分析、关键子过程性能监控的数据分析，这两项中的异常，要有对应的原因分析记录
原因分析记录（量化部分）
1.需要包含：
（1）原因分析过程，例如问题部分、分析原因（例如鱼骨图列出所有可能的原因，并筛选、确定原因）
（2）收集解决措施（即针对确定之后的原因给出解决措施）
（3）选择解决措施
（4）执行记录（包含收集措施执行后的数据、会议纪要和周报里面的跟踪）
（5）效果分析
（6）提出的改进建议（包括标准过程、指南、模板或技术、工具等方面）
2.需要包含：
（1）项目管理类型的内容
（2）类型化缺陷方面的内容
（3）度量数据方面的内容
（4）量化管理方面的内容（目标不达标、关键数据异常、不满足组织基线等）
质量保证（质量保证人员） 质量保证计划
检查单
1.每次检查会产生一个检查单
2.检查单类型分别为：过程检查单和产品检查单
不一致问题跟踪表
1.对检查单中的问题的汇总
2.问题部分与检查单一一对应
质量报告
配置管理（配置管理人员） 配置管理计划
1.需要说明内容如下：
（1）配置项的确定方法
（2）配置项的定义
（3）配置管理系统和变更管理系统的构成
（4）基线建立过程
（5）变更过程
（6）防止不正当变更的方法
2.配置项可以包含基线项，资料项与配置项应该是互斥的
3.源代码基线需按模块建立
4.配置计划制定时，只需要说明需要建立哪些基线即可
基线申请单
配置审计
状态报告
变更记录
1.变更记录包含需求变更、注意测试轮次、对测试Bug的修改、需要进行代码基线的变更
发布通知
1.一般使用基线申请单或变更申请单代替
项目基线（配置管理人员） 需求基线
1.根据基线申请单中的配置项内容建立对应的基线（文档可以是对应文档复制过来，须注意文档的版本修订记录）
2.每次需求变更的时候，都需要有对应的基线的版本
设计基线
1.根据基线申请单中的配置项内容建立对应的基线（文档可以是对应文档复制过来，须注意文档的版本修订记录）
编码基线
1.根据基线申请单中的配置项内容建立对应的基线（文档可以是对应文档复制过来，须注意文档的版本修订记录）
2.需要兼顾测试申请
3.源代码的基线版本要和对应代码部分的测试轮次一致
4.编码基线按模块建立，每个模块有各自的变更版本
交付基线
1.根据基线申请单中的配置项内容建立对应的基线（文档可以是对应文档复制过来，须注意文档的版本修订记录）
CMMI 评估
受评估项目：提交8-10个项目用于评估。
查验网站：CMMI审计人员通过企业的网站，了解企业的业务情况。
实际绩效：导入CMMI模型的企业，需要注重导入后的绩效变化，要对绩效进行测量，强调实用性。
ATM要求：要进行考试。
1、评估方法
将组织过程与CMMI模型进行比对，提供准确的情况，以便了解当前已经实施的过程；确定所评价的CMMI过程域目标的满足程度；如评估发起人要求，定出级别。识别组织单元内的过程弱项和强项。
2、客观证据
客观证据是用于表明模型实践实施或制度化的文件或访谈。客观证据的来源可以包括工具、讲解、文件和访谈。
3、每个过程域如何给出评分等级。
CMMI 规程文件
文档准备-满足三级要求基础
- 提供8-10个软件开发项目文档记录。
- 完成过程管理类所需的记录，完成2个项目的项目管理类，工程管理类，支持类152个记录。
- 完成EGP,组织级QA，组织级CM，组织件OT所需的记录。
参见：
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
