CMMI培训讲义1.pdf

《CMMI培训讲义1.pdf》由会员分享，可在线阅读，更多相关《CMMI培训讲义1.pdf（83页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、 CMMI 培训讲义（1）编写：胡希明 王红女 2005 年年 6 月月 目 录 第一章第一章 预备知识预备知识 1 1.1 软件工程基本原理.1 1.2 质量管理体系 ISO9001.4 1.3 项目管理知识体系 PMBOK.9 1.4 软件能力成熟度模型 CMM.12 1.5 软件过程改进案例介绍.21 1.7 著名质量专家论点摘要.29 1.8 软件过程管理标准化国内动态.35 第二章第二章 CMMI 模型框架模型框架 36 2.1CMMI 模型系列.36 2.2 CMMI 模型的过程域.38 2.3CMMI 的两种表示法.41 2.4 CMMI 的阶梯式表示.44 2.5 CMMI 的

2、连续式表示.52 第三章第三章 CMMI 模型部件模型部件 58 3.1 必需部件.58 3.2 期望部件.61 3.3 解释性部件.63 3.4 模型部件实例.64 3.5 名词术语.70 3.6 共性实践的详细说明.73 第 1 页 共 81 页 第一章第一章 预备知识预备知识 1.1 软件工程基本原理软件工程基本原理 就全国情况而言，经过十几年特别是近几年的发展，我国已形成了具有一定自主开发能力、初步的规模和巨大的潜在市场的软件产业。但与发达国家相比，无论在开发能力还是管理水平上都还存在较大差距，尤其是粗放的甚至是落后的软件工程管理制约了我们软件产业的发展。某些国家的整体国力并不比我国强

3、，但在国际软件市场上的份额却远大于我国，原因之一就是我国在软件开发过程管理方面急待改善。应该看到，机械工业以至一般的加工业，都已经有了上百年的历史，产品的生产流程以及工厂、车间、工种等等的机构设置和角色分工都有了成熟的模式。但是，软件企业及其软件产品的生产，历史不长，加之软件本身的智力劳动的特性，软件作为产品的生产流程及其相应的管理活动，还远远没有一个成熟的模式。近 10 年来，在国家各级主管部门的政策倡导和支持下，中国软件企业的决策者也从各自的成长历程中认识到了加强和改进内部管理特别是技术管理的重要性，纷纷投入大量的人力、物力和财力，学习、采用和实施一系列的学科、标准和模型，例如，软件工程、

4、ISO9001、PMBOK 以及 CMM、CMMI 等等。为了改进软件企业的管理，为了“更快、更好、更便宜”的开发软件产品，既要有技术措施（方法和工具），又要有必要的组织管理措施。从学科发展角度出发，人们很自然的想到了软件工程。因为软件工程正是从管理和技术两方面研究如何采用工程的概念、原理、技术和技术方法并加以综合，指导开发人员更好地开发和维护计算机软件的一门新的学科。自从 1968 年正式提出并采用“软件工程”这个术语以来，研究软件工程的专家学者们陆续提出了 100 多条关于软件工程的准则或“信条”。著名的软件工程专家波汉姆（Boehm）综合这些学者们的意见，并总结了多年开发软件的经验，于

5、1983 年在一篇论文中提出了软件工程的 7 条基本原理。他认为这 7 条原理是确保软件产品质量和开发效率的原理的最小集合。人们虽然不能用数学方法严格证明它们是一个完备的集合，但是，事实证明在此之前已经提出的 100 多条软件工程原理都可以由这 7 条原理的适当组合所蕴含或派生所得到。下面给出这 7 条基本原理的简要内容。1.按照软件生命周期的阶段划分制定计划，严格依据计划进行管理。按照软件生命周期的阶段划分制定计划，严格依据计划进行管理。在软件开发与维护的整个生命周期中，需要完成许多性质各异的工作，应该把软件生命周期划分成若干个阶段，并相应地制定出切实可行的计划，然后严格按照计划对软件的开发

6、与维护工作进行管理。共有 6 类计划，包括项目概要计划，里程碑计划，项目控制计划，产品控制计划，验证计划，运第 2 页 共 81 页 行维护计划。不同层次的管理人员都必须严格按照计划各尽其职地管理软件开发与维护工作，绝不能受客户或上级人员的影响而擅自背离或随意修改预定计划。2.坚持进行阶段评审坚持进行阶段评审 软件质量保证工作不能等到编码阶段结束之后再进行，因为大部分缺陷是在编码之前造成的（例如，据统计，设计阶段注入的缺陷占缺陷总数的 63），并且缺陷发现与改正越晚，所需付出的代价就越高。因此，在每个阶段都应进行严格的评审，以便尽早发现在软件开发过程中所犯的错误。3.实行严格的产品控制实行严格

7、的产品控制 在软件开发过程中不应随意改变需求，因为改变一项需求往往需要付出较高的代价。但是，在软件开发过程中改变需求又是难免的，由于外部环境的变化，相应地改变用户需求是一项客观需要，显然不能硬性禁止客户提出需求变更请求，而只能依靠科学的控制技术来顺应这种要求。也就是说，当改变需求时，为了保持软件各个配置项的一致性，必须实行严格的产品控制，其中主要是实行基准配置管理，定义基线，管理和控制基线。基准配置管理也称为变更控制：一切有关修改软件的建议，特别是涉及到对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准以后才能实施修改。绝对不能谁想修改软件（包括尚在开发过程中的软件），就随意进行修改

8、。4.采用现代程序设计技术采用现代程序设计技术 从提出软件工程的概念开始，人们一直把主要精力用于研究各种新的程序设计技术。例如 20 世纪 60 年代末提出的结构程序设计技术以及后来发展的面向对象的分析技术和编程技术，等等。实践表明，采用先进的技术既可提高软件开发的效率，又可提高软件维护的效率。5.结果应能清楚地审查结果应能清楚地审查 软件产品不同于一般的物理产品，它是看不见摸不着的逻辑产品。软件开发人员的工作可视性差，难以准确度量，从而使得软件产品的开发过程比一般产品的开发过程更难于评价和管理。为了提高软件开发过程的可视性，更好地进行管理，应该根据软件开发项目的目标及完成期限，规定开发组织的

9、责任和产品标准，从而使得所得到的结果能够清楚地加以审查。6.开发小组的人员应该少而精开发小组的人员应该少而精 这条基本原理的含义是，软件开发小组的组成人员的素质应该好，而人数则不宜过多。开发小组人员的素质和数量是影响软件产品质量和开发效率的重要因素。素质高的人员的开发效率比素质低的人员的开发效率可能高几倍至几十倍，而且素质高的人员所开发的软件中的缺陷明显少于素质低的人员所开发的软件中的缺陷。此外，随着开发小组人员数目的增加，因为交流情况讨论问题而造成的开销也急剧增加。因此，组成少而精的开发小组是软件工程的一条基本原理。第 3 页 共 81 页 7.承认不断改进软件工程实践的必要性承认不断改进软

10、件工程实践的必要性 遵循上述 6 条基本原理，就能够实现软件的工程化生产，但是，仅有上述 6 条原理并不能保证软件开发与维护的过程能赶上时代前进的步伐，跟上技术的不断进步。因此，应把承认不断改进软件工程实践的必要性作为软件工程的第 7 条基本原理。按照这条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验，例如，收集进度和资源耗费数据，收集缺陷类型和问题报告数据，等等。这些数据不仅可以用来评价新的软件技术的效果，而且可以用来指明必须着重开发的软件工具和应该优先研究的技术。以上 7 条只是基本原理，对每一个软件企业而言，如何根据这几条原理管理和改进软件产品的开发和维护过程，问题还是不

11、少，主要是可操作性差，缺少评价标准，以及缺少相互之间的可比性。于是，人们又只好求助于其他与产品质量管理、项目管理相关的标准体系，或者是新出现的并已证明有效的专门关于软件过程改进和管理的评价模型。从当前及今后一个时期看，一个软件企业在技术、产品管理方面可采用的标准体系或模型，基本上有三个，它们之间的关系如下图示：【注 1.CMMCapability Maturity Model，能力成熟度模型。注 2.CMMICapability Maturity Model Integration，能力成熟度集成模型。注 3.PMProject management,项目管理；PMBOK（A Guide to

12、 the Project Management Body Of Knowledge项目管理知识体系指南)，由 PMI(美国项目管理协会)颁布。】从上图可以看出：?三者不存在互相包含的关系，但有很强的关联性。?三者不存在互相替代的关系，但侧重点各有不同。?PM 和 9001 并不专门针对软件企业，但可用于软件企业特别是包括软件产品、集成工程和服务的软件企业。?CMM、CMMI 专用于软件企业或软件项目，或系统集成企业或系统集成项目。本章后面几节分别介绍 ISO9001、PMBOK 和 CMM。ISO/9001 ISO/9001 CMM注1 PM注3 PMBOK PM注3 PMBOK 软件企业，C

13、MMI注2 第 4 页 共 81 页 1.2 质量管理体系质量管理体系 ISO9001 本节简要介绍质量管理体系 ISO9001:2000。ISO9001 规定了企业质量管理体系的基本要求，它是通用的，适用于所有行业或经济领域，不论其提供何种类别的产品。ISO9001 本身并不规定产品质量的要求。质量管理原则 为促进质量目标的实现，ISO9001 标准明确规定了以下八项质量管理原则：?以顾客为中心。?高层管理者推动。?全员参与。?采用过程方法。?系统的管理。?持续改进。?基于事实的决策。?互利的供方关系。建立和实施质量管理体系的步骤 建立和实施质量管理体系，一般应按下列步骤进行：?确定顾客的需

14、求和期望；?建立企业的质量方针和质量目标；?确定实现质量目标所必需的过程和职责；?对每个过程实现质量目标的有效性确定测量方法；?通过测量，确定每个过程的现行有效性；?确定防止不合格项并消除产生原因的措施；?寻找提高过程有效性和效率的机会；?确定并优先考虑那些能提供最佳结果的改进；?为实施已确定的改进，对战略、过程和资源进行策划；?实施改进计划；?监控改进效果；?对照预期效果，评价实际结果；?评审改进活动，确定必要的纠正、跟踪措施。过程方法 任何得到输入并将其转化为输出的序列活动均可视为过程。为使组织有效运行，必须识别和管理许多内部相互联系的过程。通常，一个过程的输出将直接形成下一个过程的输入。

15、系统识别和管理组织内所使用的过程，特别是这些过程之间的相互作用，称为“过程方法”。ISO9001 标准鼓励采用过程方法建立和实施质量管理体系。实例介绍 此处给出某著名软件企业采用 ISO9001 标准，建立和实施质量管理体系的概况，供参考。?过程识别 整个质量管理体系由四个大过程以及大过程所包含的若干个子过程构成，分别定义如下：第 5 页 共 81 页 体系管理过程：体系管理过程：对应于标准条款 4 和 5，主要活动包括整个质量管理体系所包含的过程及子过程的识别和划分、过程之间关系的确定以及质量管理体系文件的编写、管理和控制；还包括确定管理承诺、质量方针、质量目标、职责划分以及为了质量管理体系

16、的实施、保持和持续改进而进行的质量策划和管理评审。资源管理过程：资源管理过程：对应于标准条款 6（资源管理与提供），为了质量管理体系的实施、保持和持续改进，公司应保证在人员编制、员工培训、基础设施、工作环境等方面提供必要、合理和充分的资源。产品实现过程：产品实现过程：是核心业务过程，对应于标准条款 7（产品实现过程），包括产品策划子过程、与顾客相关的子过程、设计开发子过程、采购子过程以及生产和服务提供子过程。监测、分析和改进过程：监测、分析和改进过程：对应于标准条款 8（测量、分析和改进）。主要活动包括顾客满意、内部审核、过程监视、产品监视等过程的监视与测量活动，以及不合格品控制、数据分析、持

17、续改进和纠正、预防措施。上列 4 个基本过程以及相关子过程的相互关系，如下页图示。第 6 页 共 81 页?过程关系 体系管理过程体系管理过程 资源管理过程资源管理过程产品实现过程产品实现过程 监测、分析与改进过程监测、分析与改进过程 资源提供 人力资源 基础设施 工作环境 监视与测量 不合格品控制数据分析 改进 产品策划子过程产品策划子过程 与顾客相关的子过程与顾客相关的子过程 设计开发子过程设计开发子过程 采购子过程采购子过程 生产与服务提供子过程生产与服务提供子过程 采购流程 采购信息 产品验收 用户需求确定投标书评审 合同评审 顾客沟通 设计开发策划设计开发输入设计开发输出阶段评审 阶

18、段验证 阶段确认 更改控制 客户服务流程控制客户服务流程确认版本控制 顾客财产 产品防护 监视与测量 产品质量计划管理承诺 用户第一 质量方针 质量策划 责权与沟通 管理评审 职责权限 管理者代表 内部沟通 质量目标 体系策划 顾客满意度 内部审核 过程监视 产品监视 持续改进 纠正措施 预防措施 需求分析 软件设计 软件编码 软件测试 软件结项 第 7 页 共 81 页?质量体系文件的分层结构 质量体系文件分为四个层次：?质量手册质量手册：质量体系文件中的纲领性文件。阐明公司质量方针、质量目标和质量策略；描述影响和参与质量活动的部门、岗位职责、权限和相互关系，同时概要描述了质量体系的主体文件

19、即程序文件（规程）。?程序文件程序文件：质量手册的支持性文件，具体描述质量活动各个过程、子过程以及各阶段中所采取的措施和必需遵循的流程。?条例和规范条例和规范：结合公司的具体情况而颁布各类工作条例、技术规范。?表单模板表单模板：包括质量记录模板、文档模板等。?过程与文件的对应关系 上列各个过程和质量体系文件之间的对应关系，见下页对照表。第 8 页 共 81 页 过程与相关文件对照表 过程类别 子过程、活动或内容 相关文件 过程识别 质量手册章节 4.1 体系文件控制、质量记录控制 文件资料控制程序 质量记录控制程序 质量方针、质量目标的确定 质量手册章节 5.3，5.4.1 组织机构和职责权限

20、的明确 质量手册章节 5.5 体系管理 管理评审 管理评审程序 培训管理 人力资源控制 人力资源管理 人力资源管理程序 人力资源管理工作条例 基础设施保障 资源管理 工作环境提供与维护 行政管理工作条例 产品策划 产品实现程序 需求确定 投标书评审 合同评审 与顾客相关 顾客沟通 投标控制程序 合同管理程序 合同管理工作条例 设计开发策划 设计开发输入 设计开发输出 阶段评审 阶段验证 阶段确认 设计和开发 更改控制 产品实现程序 技术管理工作条例 系统集成项目管理工作条例 采购流程 采购信息 采购 产品验收 产品实现程序 设备采购供应管理工作条例 系统集成项目管理工作条例 客户服务流程控制

21、客户服务流程确认 版本控制 产品实现程序 客户服务工作条例 顾客财产 质量手册章节 7.5.4 产品防护 质量手册章节 7.5.5 产品实现 生产与服务提供 监视与测量 数据收集与分析程序 内部质量审核 内部质量审核程序 过程监视和测量 质量手册章节 8.2.3 监视和测量 产品监视和测量 质量手册章节 8.2.4 不合格品控制 质量手册章节 8.3 不合格品控制程序 数据收集与分析应用 数据收集与分析程序 持续改进 纠正措施 持续改进 持续改进过程 预防措施 持续改进程序 第 9 页 共 81 页 1.3 项目管理知识体系项目管理知识体系 PMBOK 项目基本属性。项目，是在限定时间内、利用

22、有限的资源、完成有一定质量要求的目标而进行的一系列有序活动的一次性组合。充分认识项目属性，有利于做好项目管理。项目基本属性 8 条，包括：?整体性，是一系列活动的有序组合。?唯一性，每个项目均是具体的、特殊的，没有二个完全相同的项目。?一次性，目标一旦完成，项目即告结束。?目标性，一个项目有确定的成果性目标。?多约束性，在多种约束条件下完成项目的成果性目标，约束包括时间、资源、质量以及其他非技术性约束。?依赖性，项目活动的进行涉及多个方面的因素，有对内部各级各部门的依赖，有对用户条件的依赖，有对标准的依赖和对各类变更的依赖等等。?冲突性，项目内部会有多种冲突，需要沟通、协调和培训。?周期性，项

23、目不同，但都有其基本的生命周期属性，都会经历大体相同的阶段。项目参数。用于刻划一个项目的主要参数：范围、进度、资源、成本和质量。项目生命周期。项目生命周期划分成四个阶段：?定义。?策划。?实施。?收尾。项目生命周期与软件生命周期阶段划分的对应关系，如下表：项目生命周期 软件生命周期 项目定义 立项管理、需求管理 项目策划 项目策划 项目实施 软件设计、编码、测试 项目收尾 发布、提交、运行维护、技术支持和产品退役 项目管理基本过程 项目管理基本过程共五个：启动过程、策划过程、执行过程、控制过程和结束过程。项目管理基本职能。项目管理基本职能，有九个，如下图所示。第 10 页 共 81 页 项目管

24、理成熟度模型 CMM（见下一节）发布后，有人又根据 PMBOK 和 CMM，进一步提出了一套项目管理成熟度模型（Project Management Maturity Model）,简称 PMMM。PMMM V5.0(2002 年 10 月)标准文本与 CMM 非常相似，也分成 5 级，也有关键过程域的概念，要点如下表：项目管理项目管理 项目整体管理项目整体管理 项目计划制订 项目计划实施 整体变更控制 项目范围管理项目范围管理 启动 范围计划编制 范围定义 范围核定 范围变更控制 项目时间管理项目时间管理 活动定义 活动排序 历时估算 进度计划编制 进度计划控制 项目成本管理项目成本管理 资

25、源计划编制 费用估算 费用预算 费用控制 项目质量管理项目质量管理 质量计划编制 质量保证 质量控制 项目人力资源管理项目人力资源管理 组织的计划编制 人员获取 班子组建 项目沟通管理项目沟通管理 沟通计划编制 信息发布 绩效报告 管理收尾 项目风险管理项目风险管理 风险识别 风险量化 定性风险分析 定量风险分析 风险应对计划编制 风险监控 项目采购管理项目采购管理 采购计划编制 询价计划编制 询价 供方选择 合同管理 合同收尾 第 11 页 共 81 页 成熟度等级 关键过程域 Initial process 初始级 Project Definition 项目定义 Repeatable pr

26、ocess 可重复级 Project Establishment 项目立项 Requirement Management 需求管理 Risk Management 风险管理 Project Planning 项目策划 Project Monitoring and Control 项目监控 Management of Suppliers and External Parties 供方和外部合作方管理 Project Quality Control 项目质量控制 Configuration Definition and Control 配置定义与控制 Defined Process 已定义级 Or

27、ganizational Focus 机构聚焦 Project Management Process Definition 项目管理过程定义 Project Training 项目培训 Integrated Management 综合管理 Lifecycle Control 生命周期控制 Inter-team Coordination 组间协调 Quality Assurance 质量保证 Managed Process 受管理级 Project Metrics 项目度量 Organizational Quality Management 机构质量管理 Optimization 优化级 Pro

28、active Problem Management 意外问题管理 Technology Management 技术管理 Continuous Process Improvement 持续过程改进 第 12 页 共 81 页 1.4 软件能力成熟度模型软件能力成熟度模型 CMM 什么叫 CMM 软件能力成熟度模型的英文全名是 Capability Maturity Model for Software，缩写为 SW_CMM，简称 CMM。最初，为了支持美国国防部对软件承包商的能力进行客观评价，卡内基梅隆大学软件工程研究所（Carnegie Mellon University Software E

29、ngineering InstituteCMU/SEI）在 1987 年提出了关于软件的过程成熟度模型框架和成熟度问卷简要描述，并在美国国防项目承包商范围内开始试行 CMM 等级评估。SW-CMM V1.0 发表之后，美国国防部合同审查委员会提出，发包单位可以在招投标程序中规定“投标方要接受基于 CMM 的评估”的条款，发包单位将把评估结果作为选择承包方的重要因素之一。注意，接受并进行 CMM 评估只是有了参加美国军方项目投标的资格，CMM 评估决非像国内有些媒体上讲的那样：CMM 是进入美国市场以至国际市场的通行证。但是，CMM 评估对软件过程改进确实有明显的促进作用，这使 SEI 看到了

30、CMM评估的巨大商业前景，因此从 1990 年以后，（完整的 SW-CMM V1.1 版本于 1993年发布），SEI 把基于 CMM 的评估作为商业行为推向市场。这些年来，接受 CMM评估的软件机构和企业已从美国国防项目承包领域扩散到普通经济领域和其他国家与地区，并且这种评估同样适合中小企业。CMM 评估已经引起国外和国内软件企业的高度关注。CMM 主要应用在两大方面：能力评估和过程改进。?能力评估 有两种通用的评估方法，用以评估企业或机构软件过程的成熟度：?软件过程评估:用于确定一个企业软件过程的当前状态以及软件过程管理活动中应该优先改进的问题，为企业领导层提供报告以获得企业对软件过程改进

31、的支持。软件过程评估集中关注企业自身的软件过程，在一种合作的、开放的环境中进行。评估的成功取决于管理者和专业人员对企业软件过程改进的支持。CBA_IPI 是一种软件过程评估方法，其全称是：基于 CMM 的软件过程评估标准（CBA_IPICMM Based Appraisal for Internal Process Improvement）。目前国内企业一般的做法是聘请SEI授权的主任评估师根据CBA_IPI方法对企业的软件过程进行正式评估，并签发通过 CMM 哪一级的评估证书。?软件能力评价:用于识别合格的软件承包商或者监控软件承包商开发软件的过程状态。软件能力评价集中关注识别在预算和进度要

32、求范围内完成高质量软件产品的合同执行能力及相关风险。评价在一种审核的环境中进行，重点在于检查企业实际执行软件过程的文档化记录。SCE 是 SEI 开发的一种基于 CMM 的软件能力评价方法，其全称是：软件能力评估 SCE(Software Capability Evaluatoin)。?过程改进 软件过程改进是一个持续的、全员参与的过程。CMM 实施或软件过程改第 13 页 共 81 页 进(Software Process Improvement)采用的方法称 IDEAL 模式，分五步：初始化(Initiating)、诊断(Diagnosing)、建立(Establishing)、行动(Ac

33、ting)、推进(Leveraging),如下图所示。CMM 结构框架 CMM 将一个机构或企业的软件能力成熟度划分为五个等级，分别为：初始级、可重复级、已定义级、受管理级和优化级。?初始级（Initial）：在初始级，企业不具备稳定的软件开发与维护环境。项目成功与否在很大程度上取决于是否有杰出的项目经理和经验丰富的开发团队。项目经常超出预算和不能按期完成，企业软件过程能力不可预测。?可重复级(Repeatable):在可重复级，企业建立了管理软件项目的方针以及为贯彻执行这些方针的措施。企业基于同类项目的经验对新项目进行策划和管理。企业的软件过程能力可描述为有纪律的，并且项目开发过程处于项目管

34、理体系的有效控制之下。?已定义级（Defined）：在已定义级，企业形成了管理软件开发和维护活动的机构标准软件过程，包括软件工程过程和软件管理过程。项目组可以依据机构的标准，定义项目的软件过程并进行管理和控制。企业的软件过程能力可描述为标准的和一致的，过程是稳定的和可重复的，并且高度可视。?受管理级（Managed）：在已管理级，企业对软件产品和过程都设置定量的质量目标。通过把过程性能的变化限制在可接受的范围内，从而实现对产品和过程的控制。企业的软件过程能力可描述为可预测的，软件产启动（initiating）诊断（Diagnosing）建立（Establishing）行动（Acting）推进（

35、Leveraging）激励改进 设定改进范围 提出改进倡议 设立实施改进的组织机构和岗位职责 描述并评价当前的过程实践提出改进建议并将阶段性结果形成文档 设定改进策略和优先排序建立过程改进行动小组策划改进活动 策划与 执行指南 计划、执行和跟踪 定义过程和度量 修订机构一级的相关规定分析经验教训并形成文档软件过程改进的 IDEAL模型 第 14 页 共 81 页 品具有可预期的高质量。?优化级（Optimizing）：在优化级，企业通过预防缺陷、技术创新和改进过程等多种方式，不断提高项目的过程性能以持续改善企业软件过程能力。企业的软件过程能力可描述为持续改进的。每一级包含有数量不等的若干个关键

36、过程域 KPA(Key Process Area),共 18个关键过程域。每个 KPA 都有若干个目标(Goal)，共 52 个目标。每个 KPA 包含实现目标所必需的若干个重要活动，称关键实践(Key Practice),共 316 个关键实践。整个结构框架，如下表所示：成熟度级别成熟度级别 关键过程域（关键过程域（Key Process Area）目标数目标数 实践数实践数 优化级 优化级 Optimizing Level 缺陷预防 Defect Prevention 技术更新管理 Technology Change Management 过程改进管理 Process Change Man

37、agement 3 3 3 18 19 19 已管理级 Managed Level 已管理级 Managed Level 过程定量管理 Quantitative Process Management 软件质量管理 Software Quality Management 3 3 18 13 已定义级 Defined Level 已定义级 Defined Level 机构过程聚焦 Organization Process Focus 机构过程定义 Organization Process Definition 培训规划 Training Program 软件集成管理 Integrated Soft

38、ware Management 软件产品工程 Software Product Engineering 组间协调 Intergroup Coordination 同行评审 Peer Reviews 3 2 3 2 2 3 2 16 11 16 19 20 17 9 可重复级 Repeatable Level 可重复级 Repeatable Level 需求管理 Requirements Management 软件项目策划 Software Project Planning 软 件 项 目 跟 踪 和 监 督Software Project Tracking and Oversight 软件分包

39、合同管理 Software Subcontract Management 软件质量保证 Software Quality Assurance 软件配置管理 Software Configuration Management 2 3 3 4 4 4 12 25 24 22 17 21 级 初始级 Initial Level 级 初始级 Initial Level CMM 内部结构 上面已经提到，CMM 标准将软件能力成熟度分成五个等级，从二级开始每个等级包含若干个关键过程域（KPA），共 18 个关键过程域。每个 KPA 的标准文本，都划分为相同的部分，即概述、目标、关键实践；而关键实践又分成五

40、类：执行约定、执行能力、执行活动、测量分析和实施验证。此处，先对这几个名词略作说明。第 15 页 共 81 页 关键过程域(Key Process Areas)关键过程域(Key Process Areas)每一个成熟度等级由若干个关键过程域构成。关键过程域指明企业改进软件过程能力应关注的重点范围，并指出为了达到某个成熟度等级所应解决的问题。达到一个成熟度等级，必须实现该等级和以下等级的全部关键过程域及其全部目标。每个关键过程域包含了一系列的相关活动（关键实践），当这些活动全部完成时，就能够达到一组评价过程能力成熟度的目标。要实现一个关键过程域，就必须达到该关键过程域的所有目标。下表给出全部

41、KPA 及其分类：过程分类 成熟度等级 管理过程 机构过程 工程过程 过程分类 成熟度等级 管理过程 机构过程 工程过程 5.优化级 技术更新管理 过程改进管理 缺陷预防 4.已管理级 定量过程管理 软件质量管理 3.已定义级 软件集成管理 组间协调 机构过程聚焦 机构过程定义 培训规划 软件产品工程 同行评审 2.可重复级 需求管理 软件项目策划 软件项目跟踪与监督 软件分包合同管理 软件质量保证 软件配置管理 1.初始级 无序过程 目标（Goals）目标（Goals）目标概括一个关键过程域的全部关键实践应达到的目的，用以确定一个机构或一个项目组是否已有效地实现了关键过程域。目标表明了一个关

42、键过程域的范围、边界和意图。目标用于检验关键实践的实施情况，确定实现关键实践的措施、方法是否满足关键过程域的意图等。如果一个级别以及以下级别的所有目标都已实现，则表明这个组织已经达到了这个级别，可以进行下一个级别的软件过程改进。关键实践（Key Practices）关键实践（Key Practices）关键实践是指在基础设施以及其他前提条件均满足的情况下对关键过程域的规范实施起重要作用的活动。每个关键过程域都有若干个关键实践，实施这些关键实践，就实现了关键过程域的目标。关键实践按其共同特点（Common Features）可以分为 5 类:执行约定、执行能力、执行活动、测量和分析、验证实施。?

43、执行约定（Commitment to Perform，简称 C）：企业或机构为了保证过程第 16 页 共 81 页 建立和继续起作用而必须采取的行动。执行约定一般包括机构方针（Organizational policy）和管理职责的指派。?执行能力（Ability to Perform，简称 Ab）：机构和项目组实施软件过程的前提条件。执行能力一般指资源提供、职责划分和人员培训等。?执行活动（Activities Performed，简称 A）：指实施关键过程域达到目标所必需执行的活动以及活动所应遵循的规程、活动中的角色分工等。这是关键实践的主要部分，也是评估时的主要检查点。?测量和分析（Me

44、asurement and Analysis，简称 M）：对过程进行测量和对测量结果进行分析。测量和分析一般包括为确定执行活动的状态和有效性所应进行测量的科目。?验证实施（Verifying Implementation，简称 V）：为确保已建过程得到有效执行所必需的验证活动或步骤。验证一般包括高级管理者、部门经理、项目经理和软件质量保证部门对过程活动和工作产品的评审和审计。实例 为了对CMM内部结构能有具体的了解，此处以第二级第一个KPA需求管理为例，根据原文逐段翻译成中文。需求管理 第二级（可重复级）的一个关键过程域 需求管理的目的是：客户和软件项目组对软件项目应遵循的客户需求建立一种共同

45、的理解。需求管理包括：建立和维护一个关于软件项目的与用户的协议，该协议称为“指定给软件的系统需求”。这里的“客户”可以解释为系统工程组、营销组、其他内部机构、或外部客户。该协议包括了技术和非技术（如交付日期）二个方面的需求。该协议构成了整个软件生命周期中估算、计划、执行和跟踪软件项目活动的基础。系统需求对软件、硬件和其他系统组件（如人员）的划分和分配，可以由软件工程组以外的小组（如系统工程组）负责，软件工程组可能不能直接控制这种分配。软件工程组在该项目的约束范围内，应采取适当的步骤确保使分配给软件并且由项目组负责实现的系统需求形成文档并得到控制。为了达到控制的目的，软件工程组应评审分配给软件的

46、初始的或修订过的系统需求，以便在进入软件项目之前先解决系统需求中的问题。分配给软件的系统需求一旦发生变化，就应调整受到影响的软件计划、工作产品和活动，使其与更改后的需求保持一致。目标 目标目标1 分配给软件的系统需求应是得到控制的，并用以建立供软件工程和管理的基线。分配给软件的系统需求应是得到控制的，并用以建立供软件工程和管理的基线。第 17 页 共 81 页 目标目标2 软件计划、工作产品和活动应与分配给软件的系统需求保持一致。软件计划、工作产品和活动应与分配给软件的系统需求保持一致。执行约定 约定约定1 项目组应遵循书面的机构方针管理分配给软件的系统需求。项目组应遵循书面的机构方针管理分配

47、给软件的系统需求。该方针一般规定：1给定需求应建立文档；2 给定需求应经下列人员评审：软件管理人员，和 其他相关小组 3 更改软件计划、工作产品和活动，以保持与给定需求的变更相一致。执行能力 能力能力1 每个项目系统需求的分解以及分配给硬件、软件和其他系统组的职责应当明确。每个项目系统需求的分解以及分配给硬件、软件和其他系统组的职责应当明确。职责包括：1 在整个项目生命周期中，系统需求的管理、文档化及其分配。2.实施系统需求及其分配的变更。能力能力2 给定需求应形成文档。给定需求应形成文档。给定需求包括：1 影响和决定软件项目活动的非技术需求（例如：协议、条件和/或合同条款）。2 软件的技术需

48、求 在这些实践中，分配给软件的系统需求称为“给定需求”。给定需求是系统需求的一部分，在系统的软件部分实现。给定需求是软件开发计划的初始输入。软件需求分析则是对给定需求进一步细化和优化，最终生成文档化的软件需求。其他相关小组包括：系统测试小组，软件工程小组（包括所有分小组，如软件设计小组），系统工程小组，软件质量保证小组，软件配置管理小组，以及 文档支持小组。分解和分配系统系统需求不是软件工程组的职责，而是他们工作的前提。协议、条件和合同条款的实例包括：要交付的产品，交付日期，以及 里程碑。第 18 页 共 81 页 3用于确认软件产品满足给定需求的验收准则。能力能力3 应提供给定需求管理所必要

49、的资源和费用。应提供给定需求管理所必要的资源和费用。1指派在软件工程和应用领域有经验和专长的人员管理给定需求。2有可供使用的支持管理需求的工具。能力能力4 软件工程组和其他软件相关组的成员接受过实施需求管理活动的培训。软件工程组和其他软件相关组的成员接受过实施需求管理活动的培训。执行活动 活动活动1 将给定需求纳入软件项目之前，软件工程组应对其进行评审。将给定需求纳入软件项目之前，软件工程组应对其进行评审。1 确定不完整和遗漏的给定需求。2 评审给定需求以确定它们是否：可行并适用于软件实现，叙述清楚、适当，彼此一致，并且 可测试。3 由负责分析和分配系统需求的小组负责对评审中确认为存在潜在问题

50、的给定需求项进行评审，并做必要的修改。4 与相关小组协商由给定需求引起的约定。技术需求的实例包括：最终用户、操作员、技术支持人员分别所需的或集成的功能；性能需求；设计约束条件；程序设计语言；以及 界面需求。支持工具包括：制表软件 配置管理工具 跟踪工具 文本编辑工具 培训内容包括：项目采用的方法、标准和规程，以及 应用领域知识。相关小组包括：软件工程组，软件估算组，系统工程组，系统测试组，软件质量保证组，软件配置管理组，合同管理组，以及 文件支持组。第 19 页 共 81 页 活动活动2 软件工程组应将经过评审的给定需求作为软件策划、工作产品和相关活动的基础。软件工程组应将经过评审的给定需求作