CMMI简介及CMMI2级的实施方案设计（DOC）

CMMI简介及CMMI2级的实施⽅案设计第⼀部分 CMMI简介：

CMMI 全称是Capability Maturity Model Integration,，即软件能⼒成熟度模型集成模型，是由美国国防部与卡内基-梅隆⼤学和美国国防⼯业协会共同开发和研制的。CMMI （CMMI-SE/SW/IPPD）1.02 版本在部分国家和地区被SEI 开始推⼴和试⽤，主要应⽤于软件业项⽬，帮助提升对软件项⽬的管理能⼒。随着模型本⾝的发展与应⽤的推⼴，CMMI 逐渐演变成为了⼀种被⼴泛采⽤的综合性模型。在业界⼴泛使⽤的传统软件研发流程会带来⼀个严重的问题：存在于设计阶段的⼀个微⼩缺陷可能会直到后期的测试阶段才能被发现，⽽整个公司可能会花费数⼗倍甚⾄百倍的代价来改正这个缺陷。为此，⼈⼒资源管理、软件采购、集成产品和过程开发、以及系统⼯程等等，多元化覆盖范围越来越⼴的能⼒成熟度模型应运⽽⽣。1.1 CMMI 的作⽤

软件能⼒成熟度集成模型（CMMI）经过长期积累和不断地优化，已经成功地发展并被认可为软件研发领域的标准过程体系，通过CMMI 可以增强企业核⼼竞争⼒、有效地提⾼软件企业产品质量，国内乃⾄国际上的⼴⼤软件⼚商都已经见证了CMMI 为企业带来的成功。⽬前众多业界的软件企业纷纷试图使⽤CMMI 来达到过程改进的趋势，怎样才能将过程改进有效地实施，使其能实质地对软件研发过程起到优化效果，并带来⾏之有效地经济价值，已经逐渐成为了软件企业的决策者们最为关⼼的问题。由最新SEI 评估报告中的数据显⽰，在进⾏了CMMI 的评估的企业中，⼤部分都是商业组织，并且其中近⼀半的企业⼈员规模都是在100 ⼈以下。种种迹象均表明，CMMI 评估已经不仅仅吸引了⼤型IT 企业的注意⼒，同样存在⼤量的中⼩型企业也对此抱有浓厚的兴趣。对软件企业来讲，CMMI 可以主要应⽤在两个地⽅：企业软件过程的改进和企业软件过程能⼒的评估。1）过程改进

对软件来说，要对其进⾏过程改进需要企业中的所有成员都参加的，这个过程不是⼀次性的，⽽是长久持续的不断循环过程。CMMI 制定了⼀整套的⽬标和框架来对软件企业的成熟度进⾏定义和诠释。这些⽬标和框架那个对软件过程中的关键活动做出了很详细地定义，还对软件⼯程和过程管理的提出了⼀系列具有参考价值的成功实践。软件企业可以在实施过程中根据⾃⾝情况采⽤成功实践中的经验来对软件开发的整个过程进⾏指导，从⽽有效地对⾃⾝软件过程不断改进。2）能⼒评估

⽬前CMMI 可以通过两种不同的⽅式来对软件过程的成熟度进⾏评估：软件能⼒评价以及软件过程评估。

软件过程评估：该评估⽅式主要⽤来评价和估量组织内部当前的软件过程管理状态和当前的软件过程优化问题。软件过程评估会将评估结果向企业领导层进⾏汇报，从⽽使领导层成为过程改进的坚强后盾。

软件能⼒评价：主要⽤来辨识或者监督软件承包⽅的软件研发和管控能⼒。软件能⼒评价的注意⼒主要基于在保证预算的前提下，能够按照预期的进度提交⾼质量的软件产品，并能够应对可能存在的诸多风险。1.2 CMMI 的成熟度模型1.2.1成熟度模型的等级

⼀件产品的开发过程越规范，说明该组织的能⼒成熟度越⾼。软件开发项⽬的管理能⼒越⾼，最终的软件产品质量也就越好。CMMI 能⼒成熟度模型分为五个等级，按照级别依次为（⾼——低），见图1：

图1. CMMI 成熟度模型的五个等级

1、初始级(Initial)：

所有没有经过CMMI 能⼒成熟度模型的指导，并根据模型执⾏过开发过程改进活动的软件企业，其软件产品开发过程都被看做是初始级。

2、受管理级(Managed)

具备了为每个软件开发项⽬定义明确⽬标、清晰过程的软件企业，可以被认定为处于受管理级的级别。通过了受管理级评估的软件企业，我们可以认为其在软件开发的过程中执⾏了适当的监控措施。3、已定义级(Defined)

如果企业已从其运作过的历史项⽬之中，提取出⼀套⾏之有效的项⽬开发规范，该企业可以被认定为处于已定义级的级别。“已定义级”可以在企业的所有项⽬的标准开发过程中推⼴使⽤，但是“受管理级”却只能在指定的项⽬中实施。4、定量管理级(Quantitatively managed)

已经能通过采取⼀系列量化的指标作为衡量标准的软件产品管理⽅式，则该企业可以被认定为处于定量管理级的级别。只要是具备定量管理级能⼒的软件企业，都能做到为实现软件产品的最终质量和项⽬过程的效率，创⽴⼀系列量化的⽬标，且运⽤了统计的⽅法来管理项⽬过程。“定量管理级”和“已定义级”之间的区别体现在对项⽬过程效率的预测与控制，处于“定量管理级”企业的软件产品开发过程管理是定量的。5、持续优化级(Optimizing)

已经具备通过执⾏⼀定的过程规范，对软件过程不断地进⾏改进，并且该过程是可持续的，可以被认为是处于持续优化级的级别。达到持续优化级的软件企业，可以根据⾃⾝的商业⽬标对的开发过程制定改善⽬标，并在开发过程中持续不断地进⾏改善。

1.2.2成熟度模型的过程域：

不同的诸多过程域组合在⼀起，形成了CMMI 的每个成熟度等级——不包含初始级，所以CMMI开发模型共有项⽬管理、⽀持类、过程管理类、⼯程类四个类别包括22个相

关过程域。CMMI过程域结构：每个过程中设定了通⽤⽬标和特定⽬标，每个⽬标下由若⼲惯例组成。这些惯例是根据各个软件组织长期开发实践活动的成功经验逐渐总结、提炼形成

的，被认为是具有共性的最佳惯例。由于成熟度的各个等级之间是循序渐进的关系，所以如果想要达到某个成熟度等级，例如已定义级(Defined)，除了满⾜该级本⾝的过程域之外，还要满⾜受管理级(Managed)的所有过程域。CMMI的模型层次结构如下图2所⽰。

图2. CMMI的模型层次结构

CMMI过程域过程域(Process Area)，简单的说就是做好⼀个事情的某⼀个⽅⾯。对应软件开发来说，就是做好软件开发的某⼀个⽅⾯。

CMMI2、3级共有18个过程域(PA) ，主要内容如下，分四⼤类：

(1)过程管理：

1) OPD：(Organizational Process Definition)组织级过程定义。建⽴和维护有⽤的组织过程资产。

2) OPF：(Organizational Process Focus)组织级过程焦点。在理解现有过程强项和弱项的基础上计划和实施组织过程改善。3) OT：(Organizational Training)组织培训管理。增加组织各级⼈员的技能和知识，使他们能有效地执⾏他们的任务。4) OPP：(Organizational Process Performance)组织过程性能。建⽴与维护组织过程性能的量化标准，以便使⽤量化⽅式的管理项⽬。

5) OID：(Organizational Innovation and Deployment)组织的创新与推展，选择并推展渐进创新的组织过程和技术改善，改善应是可度量的，所选择及推展的改善需⽀持基于组织业务⽬的的质量及过程执⾏⽬标。(2)项⽬管理：

6) PP：(Project Planning)项⽬计划。保证在正确的时间有正确的资源可⽤。为每个⼈员分配任务。协调⼈员。根据实际情况，调整项⽬。

7) PMC：(Project Monitoring and Control)项⽬监督与控制。通过项⽬的跟踪与监控活动，及时反映项⽬的进度、费⽤、风险、规模、关键计算机资源及⼯作量等情况，通过对跟踪结果的分析，依据跟踪与监控策略采取有效的⾏动，使项⽬组能在既定的时间、费⽤、质量要求等情况下完成项⽬。

8) SAM：(Supplier Agreement Management)供应商协议管理。旨在对以正式协定的形式从项⽬之外的供⽅采办的产品和服务实施管理。

9) IPM：(Integrated Project Management)集成项⽬管理。根据从组织标准过程剪裁⽽来的集成的、定义的过程对项⽬和利益相关者的介⼊进⾏管理。

10) RSKM: (Risk Management)风险管理。识别潜在的问题，以便策划应对风险的活动和必要时在整个项⽬⽣存周期中实施这些活动，缓解不利的影响，实现⽬标。

11) QPM：(Quantitative Project Management)量化的项⽬管理，量化管理项⽬已定义的项⽬过程，以达成项⽬既定的质量和过程性能⽬标。(3)⼯程管理：

12) RD：(Requirement Development)需求开发。需求开发的⽬的在于定义系统的边界和功能、⾮功能需求，以便使⽤户(客户、最终⽤户)和项⽬组对所开发的内容达成⼀致。

13) REQM：(Requirement Management )需求管理。需求管理的⽬的是在客户和软件项⽬之间就需要满⾜的需求建⽴和维护⼀致的约定。

14) TS：(Technical Solution)技术解决⽅案。在开发、设计和实现满⾜需求的解决⽅案。解决⽅案的设计和实现等都围绕产品、产品组件和与过程有关的产品。

15) PI：(Product Integration)产品集成。从产品部件组装产品，确保集成产品功能正确并交付产品。16) VER：(Verification)验证。验证确保选定的⼯作产品满⾜需求规格。

17) V AL：(Validation)确认。确认证明产品或产品部件在实际应⽤下满⾜应⽤要求。(4)⽀持管理：

18) CM：(Configuration Management)配置管理。建⽴和维护在项⽬的整个软件⽣存周期中软件项⽬产品的完整性。19) PPQA：(Process and Product Quality Assurance)过程和产品质量保证。为项⽬组和管理层提供项⽬过程和相关⼯作产品的客观信息。

20) MA：(Measurement and Analysis)度量与分析。开发和维持度量的能⼒，以便⽀持对管理信息的需要。作为改进、了解、控制决策。

21) DAR：(Decision Analysis and Resolution )决策分析。应⽤正式的评估过程依据指标评估候选⽅案，在此基础上进⾏决策。

22）CAR：(Causal Analysis and Resolution)原因分析与解决，识别缺失的原因并进⾏矫正进⼀步的防⽌未来再次发⽣。

表1.成熟度级别与过程域映射关系

2.3 CMMI 改进的六项基本原则

（1）重要的软件过程改进必须是从⾼层到下层的依次进⾏。过程改进的启动、改进活动的优先安排、持续的资源⽀持等等，都离不开⾼级管理层的领导；

（2）必须⼈⼈都参与。树⽴团队意识，软件⼯程的改进是整个团队共同的活动；（3）改进需要认清现状，了解当前的过程，树⽴明确的⽬标；

（4）持续的进⾏改进。软件过程不能⼀蹴⽽就，需要不断持续的学习和提⾼；

（5）过程改进不会⾃发进⾏，持久的软件过程改进需要有意识的推动和周期性的增强。（6）软件过程改进需要⼤量的投资。⽆论是在时间上、个⼈技能上还是资⾦上，都需要不菲的投资。第⼆部分 CMMI2的实施⽅案设计2.1 建⽴实施框架2.1.1 确定改进模型等级

考虑到本次实施过程改进的机构为研发部门，⽽研发部门各项⽬组成员均在10 ⼈以下，固选⽤CMMI-2 级作为本次过程改进的模型。2.1.2确定过程机构及⼈员1、Sponsors（发起者）

发起者包括总经理及所有SEPG 组成员，主要职责包括：从最上层开始推动SPI；⽀持过程改进，提供⾜够的资源、允许项⽬计划作适当调整对过、改进执⾏较好的给予奖励；帮助解决冲突，每⽉开⼀次会议检讨⼯作进展2、SEPG Leader（软件⼯程过程改进组组长）

SEPG Leader 主要职责为：制定SPI 计划，并实施SPI 计划；组织SEPG 组的⼯作，制定OSSP；新过程试⽤、评估，推动OSSP 的实施；为⼯作组提供培训和⽀持；维护过程数据库；阶段性评估软件过程，每⽉进⾏⼯作总结，并向发起者汇报⼯作进展。

3、SEPG（软件⼯程过程改进组）SEPG 组成员及其分⼯如下，见表2。表2.SEPG组成员及分⼯

4、Working Group（⼯作组）

⼯作组是具体实施CMMI 体系的项⽬组成员，应积极参与过程改进。SEPG 要对⼯作组的⼯作给予⽀持。5、SPI Consultant （软件过程改进顾问）中国软件评测中⼼2.1.3 制定过程改进规程2.1.

3.1⽅针与⽬标

1) EPG 作为软件过程制定和优化的专业⼩组在公司长期存在；2) 其组长由公司任命并直接向公司⾼层管理负责；3) 公司的⽬标是在项⽬启动⼀年内通过CMMI ⼆级评估；

4) 系统集成和软件过程改进要结合市场特点和实践，有可操纵性；5) 注意⼯作阶段重点和⼯作的逐步完善；

6) 确定公司的过程改进计划。7) 公司要执⾏的过程标准和产品标准2.1.

3.2 定期评估和改进策划

按照CMMI 的评估模型开展公司的升级评估和内部⼩评估，评估时间可在每年的管理发展计划中规定。

改进策划：1) 将ISO/CMMI 过程评估结果作为改进策划的主要输⼊；2) 定义待改进的活动和这些活动的时间表；3) 规定负责这些活动的组及个⼈；4) 确定所要求的资源，包括资⾦和⼯具；5) 当计划⾸次发⾏及每当修改时，需经评审；6) 受到组织的软件经理和⾼级经理的评审和批准。2.1.3.3评审规程

体系建⽴后，在应⽤到试点、推⼴项⽬时各过程域的计划⽂档需要经过评审并得到EPG 组长的认可后⽅可执⾏。具体项⽬中的需求⽂档则必须经过同⾏评审通过后⽅可纳⼊配置管理。评审流程：1) 各过程域计划⽂档提交QA；2) QA 跟据产品审计检查单对计划内容、格式等进⾏审计；3) QA 审计通过后召开评审会，进⾏会签，⽣成评审记录；4) 需求产⽣和变更需要提交项⽬组成员进⾏同⾏评审，获取每个成员的认可后由项⽬经理召开评审会，⽣成评审记录。2.1.3.4过程推⼴

EPG ⼩组负责将公司的标准过程在全公司范围内推⼴。推⼴流程：1) 定义过程体系⽂件和模版；2) 选择试点项⽬运⾏已建⽴的体系；3) 总结试点中的成果，优化已有的体系；

4) 将优化后的体系运⽤到推⼴项⽬中；5) 再次总结和优化体系并更⼴泛的推⼴。过程改进流程：⼀、流程：

1) 总结出过程体系存在的问题；

2) EPG ⼩组开会对总结出的问题进⾏分析，并创建出更适合的过程体系；3) 将新的体系试⽤于⼀个项⽬，由QA 观察实施效果；

4) 若新体系实施效果良好，则将其在整个研发部范围内实施；若效果不好，则重复2）；5) 记录过程改进的成果。⼆、触发条件：

1) 在执⾏完⼀个项⽬后；

2) 在项⽬开发中发现体系不适⽤；3) 咨询师检查后给出更加好的建议；2.1.

3.5过程财富库管理

存放已定义的规程、⽂档模板、教程置于组织财富库中，并指定⼈员进⾏维护。1) 存放位置：OUTLOOK\\ 公⽤⽂件夹\\ 所有的公⽤⽂件夹\\ 公共信息\\CMMI ⽂档；2) 维护⼈员：EPG Leader，配置管理员。2.1.

3.6所需培训和技能

组织⼈员进⾏项⽬组的新过程的培训⼯作。培训规程：1) 在建⽴体系前对各过程域负责⼈作专业培；2) 在具体项⽬启动前对项⽬组相关⼈员作CMMI 相关培训；3) 当有新加⼊的项⽬成员时，单独对其进⾏CMMI 相关培训；4) 当有新过程发布时，对新过程的改进点及使⽤作培训。2.1.

3.7⼯具与设备要求

1) OUTLOOK ：作为组织财富库存放最新的过程体系相关⽂件；2) Microsoft Visual SourceSafe：作为配置库建⽴地址；3) mtc-05 服务器：存放CMMI 所有过程改进相关⽂件；

4) WSS 站点、rdsd-06 服务器：均可作为具体项⽬的数据管理库存放地址，由项⽬经理在项⽬计划中指定。2.1.3.8风险识别

⽬前识别的主要风险如下：1) 员⼯的知识和技能不⾜：安排专业培训EPG ⼩组权威不够，总经办思想不完全统⼀，对⼯作的⽀持和理解不够，流程制定后⽆法有效的实施2) 因为EPG 成员⼤多是兼职，在与具体的项⽬进度产⽣资源冲突的情况下，⽐较难确定优先级，EPG ⼩组的⼯作优先级可能会降低3) ⼀年内达到CMMI2 级的⽬标是否能够达到，在这么短的时间内是否能够找到⼀个有效的过程；4) 在强⼤的市场压⼒和时间进度压⼒下，是否能够保证有效的实施CMMI。2.1.4定过程改进计划过程改进计划，见表3：表3.过程改进计划表

2.2建⽴过程改进体系2.2.1需求管理 REQM

在本次过程改进中，需求管理过程域需要实现以下要求：1. 所有软件需求必须⽂档化。

2. 所有需求⽂档应经过项⽬经理和相关⼈员(如研发部门负责⼈、测试、质量保证、配置管理、开发)的评审。

3. 软件计划、⼯作产品、活动应与变化了的需求保持⼀致。根据CMMI 对过程域的⽬标定义，需求管理过程域⽬标及输出，见表4

表4. 需求管理过程域⽬标及输出表

2.2.2项⽬计划 PP

在本次过程改进中，项⽬计划过程域需要实现以下要求：1. 项⽬经理应得到书⾯的正式任命，并在项⽬启动会议上明确通知相关⼈员(如研发部门负责⼈、测试、质量保证、配置管理、开发)。项⽬经理负责协商承诺和制定项⽬软件开发计划。2. 软件项⽬计划须以软件需求为基础。3. 项⽬经理须对软件项⽬的承诺进⾏定义。4. 项⽬组成员（负责测试、硬件、集成等⼯程⼩组或⼯程⼈员）必须定义⾃⼰如何参与到软件项⽬中，并⽂档化。5. 软件项⽬计划中，软件规模、开发成本、时间表、承诺须由相关⼈员(公司⾼层管理者、研发部门负责⼈、项⽬管理部负责⼈、测试、质量保证、配置管理、开发)评审。6. 所有对公司外部和组织的软件项⽬承诺必须被公司⾼层⼈员评审。7. 软件项⽬计划需要被管理及控制。根据CMMI 对过程域的⽬标定义，项⽬计划过程域⽬标及输出，见表5.表5.项⽬计划过程域⽬标及输出表

2.2.3项⽬监督和控制 PMC

在本次过程改进中，项⽬监督和控制过程域需要实现以下要求：1. 项⽬经理负责软件跟踪和监督活动。2. 采⽤并维护项⽬软件开发计划⽂档作为软件跟踪和监督的基础。3. 项⽬经理应知道项⽬的状态和问题。4. 当项⽬没有按照软件项⽬计划执⾏和完成，项⽬经理、项⽬组及项⽬有关⼈员应相应地采取调整⼯作⽅式或调整项⽬计划的纠正措施。5. 对软件承诺的变更，应得到受影响的⼩组和个⼈的参与和同意6. 公司⾼层管理者评审对公司外部个⼈或者组织的承诺变更以及新的承诺。根据CMMI对过程域的⽬标定义，项⽬监督和控制过程域⽬标及输出，见表6：

2.2.4度量和分析 MA

在本次过程改进中，度量和分析过程域需要实现以下要求：1. 度量的定义要满⾜组织和项⽬管理的需要和⽬标。度量为作出正式的决策和实施适当的正确活动提供客观的依据。

2. 组织过程改进活动中的度量指的是：度量定义、数据收集和存储机制、

分析技术、报告和反馈⽅法。3. 组织和项⽬根据度量计划管理度量活动（收集、存储、分析和报告）。4. 组织应建⽴和管理度量库。根据CMMI 对过程域的⽬标定义，度量和分析过程域⽬标及输出，见表7：

2.2.5配置管理 CM

在本次过程改进中，配置管理过程域需要实现以下要求：1. 每个项⽬须明确落实CM 的责任到具体负责⼈。2. 在项⽬的整个⽣命周期中贯彻CM。3. 对向外交付的⼯作产品、内部指定的⼯作产品、⽀持⼯具(如编译器等)实⾏CM。4. 公司内的所有项⽬应建⽴项⽬的基线库，⽤于存储最终产品、必要的中间⼯作产品，以及⽤到的各种软件⼯具。5. 定期对基线库和配置管理活动进⾏审计。根据CMMI 对过程域的⽬标定义，配置管理过程域⽬标及输出，见表8：

2.2.6过程和产品质量保证 PPQA

在本次过程改进中，过程和产品质量保证过程域需要实现以下要求：1. 所有项⽬中应有QA 功能。2. 每个项⽬都应指派⼀个质量保证负责⼈，负责执⾏项⽬的质量保证活动。3. 执⾏质量保证审计的个⼈不能参与审计对象的开发活动。4. 从公司组织架构上保证QA ⼈员有独⽴于项⽬经理、项⽬组、配置管理组、测试组之外的渠道汇报给公司⾼层管理者。QA ⼈员的⼯作不被项⽬组的管理⼈员评审，QA ⼈员确保公司⾼层管理者得到项⽬正在使⽤的过程及正在构造的产品的报告。5. 公司⾼层管理者定期和在事件驱动下评审QA 活动及其成果。根据CMMI 对过程域的⽬标定义，过程和产品质量保证过程域⽬标及输出，见表9：

2.2.7供⽅协定管理 SAM

在本次过程改进中，供⽅协定管理过程域需要实现以下要求：1. 在组织的采购中，选择不同的采购型号。2. 识别出资格合格的供应商。3. 建⽴和维护供应商合同，根据供应商合同进⾏采购。4. 根据合同中的需求条款对交付的采购产品进⾏验证和交付。根据CMMI 对过程域的⽬标定义，供⽅协定管理过程域⽬标及输出，见表10：表10.供⽅协定管理过程域⽬标及输出表