cmmi简介及cmmi2级的实施方案设计

1、cmmi简介及cmmi2级的实施方案设计第一部分 cmmi简介：cmmi 全称是 capability maturity model integration,，即软件能力成熟度模型集成模型，是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的。cmmi（cmmi-se/sw/ippd）1.02 版本在部分国家和地区被 sei 开始推广和试用，主要应用于软件业项目，帮助提升对软件项目的管理能力。随着模型本身的发展与应用的推广，cmmi 逐渐演变成为了一种被广泛采用的综合性模型。在业界广泛使用的传统软件研发流程会带来一个严重的问题：存在于设计阶段的一个微小缺陷可能会直到后期的测试阶段

2、才能被发现，而整个公司可能会花费数十倍甚至百倍的代价来改正这个缺陷。为此，人力资源管理、软件采购、集成产品和过程开发、以及系统工程等等，多元化覆盖范围越来越广的能力成熟度模型应运而生。1.1 cmmi 的作用软件能力成熟度集成模型（cmmi）经过长期积累和不断地优化，已经成功地发展并被认可为软件研发领域的标准过程体系，通过 cmmi 可以增强企业核心竞争力、有效地提高软件企业产品质量，国内乃至国际上的广大软件厂商都已经见证了 cmmi 为企业带来的成功。目前众多业界的软件企业纷纷试图使用 cmmi 来达到过程改进的趋势，怎样才能将过程改进有效地实施，使其能实质地对软件研发过程起到优化效果，并带

3、来行之有效地经济价值，已经逐渐成为了软件企业的决策者们最为关心的问题。由最新 sei 评估报告中的数据显示，在进行了 cmmi 的评估的企业中，大部分都是商业组织，并且其中近一半的企业人员规模都是在 100 人以下。种种迹象均表明，cmmi 评估已经不仅仅吸引了大型 it 企业的注意力，同样存在大量的中小型企业也对此抱有浓厚的兴趣。对软件企业来讲，cmmi 可以主要应用在两个地方：企业软件过程的改进和企业软件过程能力的评估。1）过程改进对软件来说，要对其进行过程改进需要企业中的所有成员都参加的，这个过程不是一次性的，而是长久持续的不断循环过程。cmmi 制定了一整套的目标和框架来对软件企业的成

4、熟度进行定义和诠释。这些目标和框架那个对软件过程中的关键活动做出了很详细地定义，还对软件工程和过程管理的提出了一系列具有参考价值的成功实践。软件企业可以在实施过程中根据自身情况采用成功实践中的经验来对软件开发的整个过程进行指导，从而有效地对自身软件过程不断改进。2）能力评估目前 cmmi 可以通过两种不同的方式来对软件过程的成熟度进行评估：软件能力评价以及软件过程评估。软件过程评估：该评估方式主要用来评价和估量组织内部当前的软件过程管理状态和当前的软件过程优化问题。软件过程评估会将评估结果向企业领导层进行汇报，从而使领导层成为过程改进的坚强后盾。软件能力评价：主要用来辨识或者监督软件承包方的软

5、件研发和管控能力。软件能力评价的注意力主要基于在保证预算的前提下，能够按照预期的进度提交高质量的软件产品，并能够应对可能存在的诸多风险。1.2 cmmi 的成熟度模型1.2.1成熟度模型的等级 一件产品的开发过程越规范，说明该组织的能力成熟度越高。软件开发项目的管理能力越高，最终的软件产品质量也就越好。cmmi 能力成熟度模型分为五个等级，按照级别依次为（高低），见图 1：图1. cmmi 成熟度模型的五个等级1、初始级(initial)：所有没有经过 cmmi 能力成熟度模型的指导，并根据模型执行过开发过程改进活动的软件企业，其软件产品开发过程都被看做是初始级。2、受管理级(managed)

6、具备了为每个软件开发项目定义明确目标、清晰过程的软件企业，可以被认定为处于受管理级的级别。通过了受管理级评估的软件企业，我们可以认为其在软件开发的过程中执行了适当的监控措施。3、已定义级(defined)如果企业已从其运作过的历史项目之中，提取出一套行之有效的项目开发规范，该企业可以被认定为处于已定义级的级别。“已定义级”可以在企业的所有项目的标准开发过程中推广使用，但是“受管理级”却只能在指定的项目中实施。4、定量管理级(quantitatively managed)已经能通过采取一系列量化的指标作为衡量标准的软件产品管理方式，则该企业可以被认定为处于定量管理级的级别。只要是具备定量管理级能

7、力的软件企业，都能做到为实现软件产品的最终质量和项目过程的效率，创立一系列量化的目标，且运用了统计的方法来管理项目过程。“定量管理级”和“已定义级”之间的区别体现在对项目过程效率的预测与控制，处于“定量管理级”企业的软件产品开发过程管理是定量的。5、持续优化级(optimizing)已经具备通过执行一定的过程规范，对软件过程不断地进行改进，并且该过程是可持续的，可以被认为是处于持续优化级的级别。达到持续优化级的软件企业，可以根据自身的商业目标对的开发过程制定改善目标，并在开发过程中持续不断地进行改善。1.2.2成熟度模型的过程域：不同的诸多过程域组合在一起，形成了 cmmi 的每个成熟度等级不

8、包含初始级，所以cmmi开发模型共有项目管理、支持类、过程管理类、工程类四个类别包括22个相关过程域。cmmi过程域结构：每个过程中设定了通用目标和特定目标，每个目标下由若干惯例组成。这些惯例是根据各个软件组织长期开发实践活动的成功经验逐渐总结、提炼形成的，被认为是具有共性的最佳惯例。由于成熟度的各个等级之间是循序渐进的关系，所以如果想要达到某个成熟度等级，例如已定义级(defined)，除了满足该级本身的过程域之外，还要满足受管理级(managed)的所有过程域。cmmi的模型层次结构如下图2所示。图2. cmmi的模型层次结构cmmi过程域过程域(process area)，简单的说就是做

9、好一个事情的某一个方面。对应软件开发来说，就是做好软件开发的某一个方面。cmmi2、3级共有18个过程域(pa) ，主要内容如下，分四大类：(1)过程管理：1)opd：(organizational process definition)组织级过程定义。建立和维护有用的组织过程资产。2)opf： (organizational process focus)组织级过程焦点。在理解现有过程强项和弱项的基础上计划和实施组织过程改善。3)ot：(organizational training)组织培训管理。增加组织各级人员的技能和知识，使他们能有效地执行他们的任务。4)opp：(organizatio

10、nal process performance)组织过程性能。建立与维护组织过程性能的量化标准，以便使用量化方式的管理项目。5)oid： (organizational innovation and deployment)组织的创新与推展，选择并推展渐进创新的组织过程和技术改善，改善应是可度量的，所选择及推展的改善需支持基于组织业务目的的质量及过程执行目标。(2)项目管理：6)pp：(project planning)项目计划。保证在正确的时间有正确的资源可用。为每个人员分配任务。协调人员。根据实际情况，调整项目。7)pmc： (project monitoring and control)项

11、目监督与控制。通过项目的跟踪与监控活动，及时反映项目的进度、费用、风险、规模、关键计算机资源及工作量等情况，通过对跟踪结果的分析，依据跟踪与监控策略采取有效的行动，使项目组能在既定的时间、费用、质量要求等情况下完成项目。8)sam：(supplier agreement management)供应商协议管理。旨在对以正式协定的形式从项目之外的供方采办的产品和服务实施管理。9)ipm：(integrated project management)集成项目管理。根据从组织标准过程剪裁而来的集成的、定义的过程对项目和利益相关者的介入进行管理。10)rskm: (risk management)风险管

12、理。识别潜在的问题，以便策划应对风险的活动和必要时在整个项目生存周期中实施这些活动，缓解不利的影响，实现目标。11)qpm：(quantitative project management)量化的项目管理，量化管理项目已定义的项目过程，以达成项目既定的质量和过程性能目标。(3)工程管理：12)rd：(requirement development)需求开发。需求开发的目的在于定义系统的边界和功能、非功能需求，以便使用户(客户、最终用户)和项目组对所开发的内容达成一致。13)reqm： (requirement management )需求管理。需求管理的目的是在客户和软件项目之间就需要满足的需

13、求建立和维护一致的约定。14)ts： (technical solution)技术解决方案。在开发、设计和实现满足需求的解决方案。解决方案的设计和实现等都围绕产品、产品组件和与过程有关的产品。15)pi：(product integration)产品集成。从产品部件组装产品，确保集成产品功能正确并交付产品。16)ver：(verification)验证。验证确保选定的工作产品满足需求规格。17)val：(validation)确认。确认证明产品或产品部件在实际应用下满足应用要求。(4)支持管理：18)cm：(configuration management)配置管理。建立和维护在项目的整个软件

14、生存周期中软件项目产品的完整性。19)ppqa：(process and product quality assurance)过程和产品质量保证。为项目组和管理层提供项目过程和相关工作产品的客观信息。20)ma：(measurement and analysis)度量与分析。开发和维持度量的能力，以便支持对管理信息的需要。作为改进、了解、控制决策。21)dar：(decision analysis and resolution )决策分析。应用正式的评估过程依据指标评估候选方案，在此基础上进行决策。22）car：(causal analysis and resolution)原因分析与解决，识

15、别缺失的原因并进行矫正进一步的防止未来再次发生。表1.成熟度级别与过程域映射关系成熟度级别过程域过程域类别 cmmi2级：受管理级(managed)reqm： (requirement management )需求管理工程管理pp：(project planning)项目计划项目管理pmc： (project monitoring and control)项目监督与控制项目管理sam：(supplier agreement management)供应商协议管理项目管理ma：(measurement and analysis)度量与分析支持管理ppqa：(process and product

16、quality assurance)过程和产品质量保证支持管理cm：(configuration management)配置管理支持管理cmmi3级：已定义级(defined)rd：(requirement development)需求开发工程管理ts： (technical solution)技术解决方案工程管理pi：(product integration)产品集成工程管理ver：(verification)验证工程管理val：(validation)确认工程管理opd：(organizational process definition)组织级过程定义过程管理opf： (organiza

17、tional process focus)组织级过程焦点过程管理ot：(organizational training)组织培训管理过程管理ipm：(integrated project management)集成化项目管理项目管理rskm: (risk management)风险管理项目管理dar：(decision analysis and resolution )决策分析支持类cmmi4级：定量管理级(quantitatively managed)opp：(organizational process performance)组织过程性能过程管理qpm：(quantitative pro

18、ject management)量化的项目管理项目管理cmmi5级：持续优化级(optimizing)oid： (organizational innovation and deployment)组织的创新与推展过程管理car：(causal analysis and resolution)原因分析与解决支持管理2.3 cmmi 改进的六项基本原则（1）重要的软件过程改进必须是从高层到下层的依次进行。过程改进的启动、改进活动的优先安排、持续的资源支持等等，都离不开高级管理层的领导；（2）必须人人都参与。树立团队意识，软件工程的改进是整个团队共同的活动；（3）改进需要认清现状，了解当前的过程，树

19、立明确的目标；（4）持续的进行改进。软件过程不能一蹴而就，需要不断持续的学习和提高；（5）过程改进不会自发进行，持久的软件过程改进需要有意识的推动和周期性的增强。（6）软件过程改进需要大量的投资。无论是在时间上、个人技能上还是资金上，都需要不菲的投资。第二部分 cmmi2的实施方案设计2.1 建立实施框架2.1.1 确定改进模型等级考虑到本次实施过程改进的机构为研发部门，而研发部门各项目组成员均在10 人以下，固选用 cmmi-2 级作为本次过程改进的模型。2.1.2确定过程机构及人员1、sponsors（发起者）发起者包括总经理及所有 sepg 组成员，主要职责包括：从最上层开始推动 spi

20、；支持过程改进，提供足够的资源、允许项目计划作适当调整对过、改进执行较好的给予奖励；帮助解决冲突，每月开一次会议检讨工作进展2、sepg leader（软件工程过程改进组组长）sepg leader 主要职责为：制定 spi 计划，并实施 spi 计划；组织 sepg 组的工作，制定 ossp；新过程试用、评估，推动 ossp 的实施；为工作组提供培训和支持；维护过程数据库；阶段性评估软件过程，每月进行工作总结，并向发起者汇报工作进展。3、sepg（软件工程过程改进组）sepg 组成员及其分工如下，见表2。表2.sepg组成员及分工姓名过程改进职责说明项目角色甲epg组长，负责推进和督导过程改

21、进研发部门经历乙epg组员，负责项目监控pmc项目经理丙epg组员，负责项目规划pp、需求管理rm项目经理丁epg组员，负责配制管理cm美工戊epg组员，负责度量与分析ma开发经理己epg组员，负责过程与产品品质保证ppqa测试经理庚epg组员，负责供应商合约管理sam公司执行经理4、working group（工作组）工作组是具体实施 cmmi 体系的项目组成员，应积极参与过程改进。sepg 要对工作组的工作给予支持。5、spi consultant （软件过程改进顾问）中国软件评测中心2.1.3 制定过程改进规程2.1.3.1方针与目标1) epg 作为软件过程制定和优化的专业小组在公司长

22、期存在；2) 其组长由公司任命并直接向公司高层管理负责；3) 公司的目标是在项目启动一年内通过 cmmi 二级评估；4) 系统集成和软件过程改进要结合市场特点和实践，有可操纵性；5) 注意工作阶段重点和工作的逐步完善；6) 确定公司的过程改进计划。7) 公司要执行的过程标准和产品标准2.1.3.2 定期评估和改进策划按照 cmmi 的评估模型开展公司的升级评估和内部小评估，评估时间可在每年的管理发展计划中规定。改进策划：1) 将 iso/cmmi 过程评估结果作为改进策划的主要输入；2) 定义待改进的活动和这些活动的时间表；3) 规定负责这些活动的组及个人；4) 确定所要求的资源，包括资金和工

23、具；5) 当计划首次发行及每当修改时，需经评审；6) 受到组织的软件经理和高级经理的评审和批准。2.1.3.3评审规程体系建立后，在应用到试点、推广项目时各过程域的计划文档需要经过评审并得到 epg 组长的认可后方可执行。具体项目中的需求文档则必须经过同行评审通过后方可纳入配置管理。评审流程：1) 各过程域计划文档提交 qa；2) qa 跟据产品审计检查单对计划内容、格式等进行审计；3) qa 审计通过后召开评审会，进行会签，生成评审记录；4) 需求产生和变更需要提交项目组成员进行同行评审，获取每个成员的认可后由项目经理召开评审会，生成评审记录。2.1.3.4过程推广epg 小组负责将公司的标

24、准过程在全公司范围内推广。推广流程：1) 定义过程体系文件和模版；2) 选择试点项目运行已建立的体系；3) 总结试点中的成果，优化已有的体系；4) 将优化后的体系运用到推广项目中；5) 再次总结和优化体系并更广泛的推广。过程改进流程：一、流程：1) 总结出过程体系存在的问题；2) epg 小组开会对总结出的问题进行分析，并创建出更适合的过程体系；3) 将新的体系试用于一个项目，由 qa 观察实施效果；4) 若新体系实施效果良好，则将其在整个研发部范围内实施；若效果不好，则重复 2）；5) 记录过程改进的成果。二、触发条件：1) 在执行完一个项目后；2) 在项目开发中发现体系不适用；3) 咨询师

25、检查后给出更加好的建议；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) out

26、look ：作为组织财富库存放最新的过程体系相关文件；2) microsoft visual sourcesafe：作为配置库建立地址；3) mtc-05 服务器：存放 cmmi 所有过程改进相关文件；4) wss 站点、rdsd-06 服务器：均可作为具体项目的数据管理库存放地址，由项目经理在项目计划中指定。2.1.3.8风险识别目前识别的主要风险如下：1) 员工的知识和技能不足：安排专业培训 epg 小组权威不够，总经办思想不完全统一，对工作的支持和理解不够，流程制定后无法有效的实施2) 因为 epg 成员大多是兼职，在与具体的项目进度产生资源冲突的情况下，比较难确定优先级，epg 小组的

27、工作优先级可能会降低3) 一年内达到 cmmi2 级的目标是否能够达到，在这么短的时间内是否能够找到一个有效的过程；4) 在强大的市场压力和时间进度压力下，是否能够保证有效的实施cmmi。2.1.4定过程改进计划过程改进计划，见表 3：表3.过程改进计划表里程碑活动日期参与者成功标准1建立符合cmmi2即标准的可操作的过程文件2014-10epg小组成员建立符合2级标准的可操作过程文件，并通过评审2选择试点项目推行过程体系，指定过程域的负责人，启动试点项目2014-12epg小组成员，试点项目成员，公司高层各过程域有指定的负责人，试点3试点项目总结2015-4epg小组总结cmmi体系在试点中

28、的推广效果，提取出好的经验和不足之处4评审修正后的过程体系2015-5epg小组建立起更优化的体系5启动推广项目，正式应用过程体系2015-6epg小组成员、试点项目成员、公司高层推广项目建立优化后的过程体系，制定各过程域责任人6预评估2015-9评估师、epg小组成员、公司高层识别到项目前体系和cmmi2级标准的偏差，并进一步优化过程体系7正式评估2016-1评估师、epg小组成员、公司高层通过正式评估的结果进一步优化过程体系2.2建立过程改进体系2.2.1需求管理 reqm在本次过程改进中，需求管理过程域需要实现以下要求：1. 所有软件需求必须文档化。2. 所有需求文档应经过项目经理和相关

29、人员(如研发部门负责人、测试、质量保证、配置管理、开发)的评审。3. 软件计划、工作产品、活动应与变化了的需求保持一致。根据 cmmi 对过程域的目标定义，需求管理过程域目标及输出，见表 4表4. 需求管理过程域目标及输出表sg（特定目标）说明工作产品对需求的理解区别适合的需求提供者的准则需求管理方针确定是否理解了需求的准则对照准则分析后所得的结果项目需求说明书达成一致的需求集合对需求的承诺需求冲突评估用户需求确认书需求以及需求改变的书目承诺管理需求变更需求状态需求溯源性矩阵需求数据库需求决策数据库需求重要度评估表维护对需求的双向溯源性需求溯源性度量值需求溯源性矩阵需求跟踪系统识别项目工作与需

30、求之间的不一致关于不一致之处的文档，包括来源、条件和理由需求变更申请书对纠正措施的需求需求审核报告纠正措施2.2.2项目计划 pp在本次过程改进中，项目计划过程域需要实现以下要求：1. 项目经理应得到书面的正式任命，并在项目启动会议上明确通知相关人员(如研发部门负责人、测试、质量保证、配置管理、开发)。项目经理负责协商承诺和制定项目软件开发计划。2. 软件项目计划须以软件需求为基础。3. 项目经理须对软件项目的承诺进行定义。4. 项目组成员（负责测试、硬件、集成等工程小组或工程人员）必须定义自己如何参与到软件项目中，并文档化。5. 软件项目计划中，软件规模、开发成本、时间表、承诺须由相关人员(

31、公司高层管理者、研发部门负责人、项目管理部负责人、测试、质量保证、配置管理、开发)评审。6. 所有对公司外部和组织的软件项目承诺必须被公司高层人员评审。7. 软件项目计划需要被管理及控制。根据 cmmi 对过程域的目标定义，项目计划过程域目标及输出，见表 5.表5.项目计划过程域目标及输出表sg工作产品说明完成参数估计项目评估书包括：项目性质（确定是软件产品还是软件项目）；说明项目采用的开发模型、软件技术、体系结构；以往模型和历史数据规模估计；工作量估计；成本估计；风险估计项目周期分析说明书包括：项目开发模型；模型决定的软件工程周期说明；周期中每个阶段的起始时间、大概目标和完成标准以及应该提交

32、的工作成果；每个周期的工作量、人员组成和大概的工作成本拟定项目计划项目计划书包括：技术预研计划、技术预研结果评审计划、产品生产周期规划、技术管理目标、开发目标、预算和进度计划、里程碑、数据管理、项目涉及的软件技术和人员技能、项目组人员组成，角色分配和岗位职责项目计划变更书包括：变更原因说明、详细变更说明、变更的影响分析说明项目计划变更记录表记录项目计划每次变更时间、内容和简要说明获得对计划的承诺项目计划评审表包括：项目计划评审内容、评审标准，评委评审意见项目计划评审报告记录说明项目评审委员会根据每个评委填写的项目计划评审表对项目计划书的最终评审意见和评审结果2.2.3项目监督和控制 pmc在本

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

34、，直到结束项目监督和控制计划根据项目计划制定项目监督和控制计划，以确定项目监督和控制的实施方法项目进展情况审查记录表记录定期和不定期对项目进展情况的审查情况项目风险跟踪表记录项目风险的发生情况以及相应的处理措施项目问题及相应措施记录表记录项目进展过程中出现的问题、采取的措施以及最后取得的成果承诺执行情况记录表定期或不定期的对项目承诺的执行情况进行审查和记录项目干系人介入情况记录表记录项目相干人员介入项目情况项目数据管理记录记录项目相关数据如代码、文档等数据的管理情况2.2.4度量和分析 ma在本次过程改进中，度量和分析过程域需要实现以下要求：1. 度量的定义要满足组织和项目管理的需要和目标。度

35、量为作出正式的决策和实施适当的正确活动提供客观的依据。2. 组织过程改进活动中的度量指的是：度量定义、数据收集和存储机制、分析技术、报告和反馈方法。3. 组织和项目根据度量计划管理度量活动（收集、存储、分析和报告）。4. 组织应建立和管理度量库。根据 cmmi 对过程域的目标定义，度量和分析过程域目标及输出，见表 7：表7.度量和分析过程域目标及输出表sg工作产品说明协调测量和分析活动度量分析计划制定度量分析的方法、操作方式度量分析规程数据采集表建立测量的目标。规定度量值提供度量结果度量分析报告收集度量数据、分析度量数据2.2.5配置管理 cm在本次过程改进中，配置管理过程域需要实现以下要求：1. 每个项目须明确落实 cm 的责任到具体负责人。2. 在项目的整个生命周期中贯彻 cm。3. 对向外交付的工作产品、内部指定的工作产品、支持工具(如编译器等)实行 cm。4. 公司内的所有项目应建立项目的基线库，用于存储最终产品、必要的中间工作产品，以及用到的各种软件工具。5. 定期对基线库和配置管理活动进行审计。根据 cmmi 对过程域的目标定义，配置管理过程域目标及输出，见表 8：表8.配置管理过程域目标及输出配