CMM规范文档.docx

1、CMM规范文档文件编号20100001 CMM规范描述 （Capability Maturity Model for Software 软件能力成熟度模型） 目录CMM产生背景 1主要问题 1主要作用 1CMM的基本概念 2软件过程 2软件过程能力 2软件过程性能 2软件过程成熟度 2成熟与不成熟 3CMM的五级成熟度 4基本前提 4基本原理 5基本内容 5五个成熟度级别 5初始级 5第一级：初始级 6第二级：可重复级 6第三级：定义级 7第四级：管理级 8第五级：优化级 8发展 9技术内容 10CMM的结构和基本内容 10第一级：初始级（The Initial Level） 12第二级：可重

2、复级（The Repeatable Level） 12概述 12构成 13需求管理（Requirements Management） 13目标 14承诺 14前提条件 14执行动作 15度量分析 16验证 16软件项目计划（Software Project Planning） 16内容 17目标 17承诺 17前提条件： 18执行动作 19度量分析 23验证 23软件项目的跟踪和监督（Software Project Tacking and Oversight） 24目标 25行为的责任 25行为的能力 26活动 32度量和分析 33验证实施 33软件子合同管理（Software Subcon

3、tract Management） 35目的 35内容 35目标 35承诺 36前提条件 36执行动作 36度量分析 37验证 37软件质量保证（Software Quality Assurance） 38目标 38承诺 38前提条件 39活动 39软件配置管理（Software Configuration Management） 40目的 40内容 40目标 41承诺 41能力 41活动 42度量分析 44验证 44第三级：已定义级（The Defined Level） 44概述 44构成 45目标 46承诺 46前提条件 46执行动作 46度量分析 47验证 47机构过程定义（Organi

4、zation Process Definition） 47内容 48目标 48承诺 48前提条件 48执行动作 49度量分析 49验证 49培训计划（Training Program） 49目的 50内容 50目标 50承诺 50前提条件 50执行动作 51度量分析 51验证 51集成软件管理（Integrated Software Management） 52目的 52内容 52目标 52承诺 52前提条件 52执行动作 53度量分析 54验证 54软件产品工程（Software Product Engineering） 54目的 54目标 54承诺 55前提条件 55执行动作 55度量分析

5、 56验证 56组间协调（Intergroup Coordination） 57目的 57内容 57目标 57承诺 57前提条件 57执行动作 58度量分析 58验证 59同行评审（Peer Reviews） 59目的 59内容 59目标 59承诺 60前提条件 60执行动作 60度量分析 60验证 60第四级：已管理级（The Managed Level） 61概述 61构成 61定量过程管理（Quantitative Process Management） 61目的 62内容 62目标 62承诺 62能力 63活动 63度量分析 64软件质量管理（Software Quality Mana

6、gement） 64目的 64内容 64目标 64承诺 65能力 65活动 65度量分析 65验证 65第五级：The Optimizing Level 66概述 66构成 66缺陷预防（Defect Prevention） 66目标 67承诺 67能力 67活动 68度量和分析 68验证实施 68技术变更管理（Technology Change Management） 69目标 69承诺 70能力 70活动 70度量和分析 71验证 71过程变更管理（Process Change Management） 71目标 72执行约定 72高级管理者 73执行能力 73执行的活动 75测量和分析 8

7、6验证实施 87CMM产生背景主要问题 在过去的二十年里，新的软件开发方法和技术的使用并未使软件生产率和生产质量得到有效的提高。软件生产商开始意识到他们的基本问题在于对软件的生产过程管理不力，主要体现在：软件产品不能按时完成、超出预算的成本、以及采用新的技术和工具后其好处难以体现。 主要作用CMM可以指导软件机构如何控制软件产品的开发和维护过程，以及如何向成熟的软件工程体系演化，并形成一套良性循环的管理文化。具体说来，一个企业要想改进其生产过程，应该采取如下策略和步骤：确定软件企业当前所处的过程成熟级别；了解对改进软件生产质量和加强生产过程控制起关键作用的因素； 将工作重点集中在有限几个关键目

8、标上，有效达到改进机构软件生产过程的效果，进而可持续地改进其软件生产能力。CMM的基本概念 软件过程 人们在开发和维护软件及其相关产品时所涉及的各种活动、方法、实践和改革等。其中软件相关产品包括软件项目计划、设计文档、程序代码、测试用例和用户手册等。 软件过程能力 当遵循某个软件过程时所能达到的期望效果，它可以有效预测企业接收新的软件项目时可能得到的结果。 软件过程性能 当遵循某个软件过程时所达到的实际效果。它可以用于验证软件过程能力。 软件过程成熟度 指一个特定的软件过程被显式定义、管理、度量、控制和能行的程度。成熟度可以用于指示企业加强其软件过程能力的潜力。当一个企业达到了一定的软件过程成

9、熟级别后，它将通过制定策略、建立标准和确立机构结构使它的软件过程制度化。而制度化又促使企业通过建立基础设施和公司文化来支持相关的方法、实践和过程。从而使之可以持续并维持一个良性循环。 成熟与不成熟 企业要通过选择最关键的目标来进行过程改进，应该搞清成熟的软件过程和不成熟的过程之间的差异。 不成熟的企业有如下标志：缺乏确定的软件过程和相应的管理和控制； 即使给出了软件过程，也不严格的遵循和强制执行； 管理是完全被动的，管理者采用的策略是救火式的，即出了事才去解决，解决的时候也难以纵观全局，往往只顾眼前；由于缺乏有依据的估算，制订软件预算和生产计划时往往跟着感觉走，实际生产时则常常超标； 如果强制

10、在预定期限内完成，那么软件的功能和质量肯定是得不到保证；缺乏评价软件产品质量和解决产品缺陷和过程问题的客观基础。 成熟的企业则有如下标志：具有在企业范围内管理、控制软件开发和维护过程的能力；现有人员和新进人员均了解所遵循的软件过程，且工作活动均按照事先的计划完成；在定义好的软件过程中，所有项目和机构中的角色和责任分明；制定的计划是有效的且与实际的工作进展一致； 软件过程在必要时可按照一定规则和程序加以修改；软件产品和过程的具有一定的可控性。这主要体现在： 管理者能够监督软件产品的质量和生产过程； 具有客观的和定量化的措施来判断产品质量并分析产品与生产过程中的问题； 计划和预算有章可循，它是基于

11、历史数据的，从而是实际可行的； 预算的结果，包括成本、时间表、产品功能和质量等，通常能够达到；有关的参与者完全理解遵循软件过程的价值并认真地遵循之； 具有支撑软件过程的基础设施，如标准过程库、历史数据库等。 CMM的五级成熟度 基本前提 软件质量在很大程度上取决于产生软件的软件过程的质量和能力；软件过程是一个可管理、可度量并不断改进的过程； 软件过程的质量受到用以支撑它的技术和设施的影响；企业在软件过程中所采用的技术层次应适应于软件过程的成熟度。 基本原理 CMM强调连续的软件过程改进。该连续的改进基于多个演化步骤。CMM将这些演化步骤划分成五个级别。这种分级结构的理论依据是软件质量原理。 每

12、一级别都包括若干目标。当满足某一目标后，软件过程的相应部分便确定下来。五级成熟度定义了一个标准，用以度量机构的软件过程成熟度和评价其软件过程能力。 基本内容 CMM的成熟度理论目前主要涉及如下内容：机构和资源的管理: 涉及机构本身的责任，人员和其它资源设施。 软件工程过程及其管理: 涉及软件工程过程，即软件过程的深度、范围和完整性以及如何度量、管理和改进这样的过程。工具和技术: 软件工程过程中使用的开发工具和技术。 五个成熟度级别初始级 可重复级：有规章的过程定义级：标准化、一致的过程管理级：可预测过程优化级：可持续改进的过程 成熟度的行为刻划 第一级：初始级 成功来源于个人英雄主义而非机构行

13、为，因此它不可重复，更换人员后成功便难以维持。 第二级：可重复级 针对特定软件项目建立管理该项目的策略和实现这些策略的过程。新项目的计划和管理基于类似项目的经验。 软件过程能力主要通过管理单个项目的软件生产过程来得到提高和增强。不同的项目可有不同的软件过程，机构应当建立一定的方针和策略以针对具体的项目选择合适的软件生产过程并进行管理。可重复级的主要特点在于确定了基本的软件生产管理和控制，具体来讲，有：结合已有项目的经验和新项目的特点来确定本项目的责任和承诺；软件生产成本、时间表和实现的功能被有效跟踪； 识别实现承诺所需解决的关键问题；定义软件项目过程标准，机构要确保其被遵守。 概括来说，第二级

14、的主要特点是项目计划和跟踪是确定且有效的，项目的软件过程是可控的，以及已有的成功经验是可重复的。 第三级：定义级 有一个机构范围内标准的软件过程，软件工程活动和管理活动被集成为一个有机的整体。标准化的目的是使高层管理者和软件技术人员能够有效合作。有一个组例如软件工程组（SEPG）专门负责订立机构的标准软件过程，并且在机构中制定培训计划来确保相关人员和管理者有足够的知识和技能完成标准过程所赋予的角色。标准的软件过程结合具体项目的特点经过裁剪即形成项目定义软件过程，它是一组集成的完善定义的软件工程和管理过程。一个完善定义的软件过程应包括就绪准则、输入、工作过程、验证机制、输出和完成准则。 对于已建

15、立的产品生产线，其成本、时间表和实现功能均可跟踪和控制，软件产品的质量可以得到保证。软件过程能力的实现主要基于在机构范围内对一个定义软件过程的活动、角色和责任的共同理解。 概括来说，第三级的主要特征在于软件过程已被提升成标准化过程，从而更加具有稳定性、重复性和可控性。 第四级：管理级 软件的过程和产品有定量的质量指标。 重要的软件过程活动均配有生产率和质量方面的度量指标； 应用数据库来收集和分析定义软件过程中涉及的各种数据； 对项目软件过程和软件质量的评价有定量的基准。 软件项目的产品和生产过程的控制具有可预测性。 将软件过程性能可能出现的偏差控制在可接受的量化界限内；具体区分影响过程性能发生

16、偏差的有效因素和偶然因素；向新领域拓展的风险是可预知的并被仔细管理和权衡。 概括来说，第四级的主要特征是定量化、可预测、异常控制和高质量。 第五级：优化级 机构集中于持续的过程改进 具有标识过程缺陷和增强过程能力的有效手段。 利用试验数据分析使用新技术所需的代价和带来的效益，然后再有选择地采用。 当出现偏差时，软件项目人员能够分析出错原因并采取有效手段防止其再次出现。 防止不必要的浪费是第五级的重点。改进的途径有两个，一个是对已有过程的渐进式改进；另一个则是有选择地使用新技术和新方法所带来的革新。 概括来说，第五级的主要特征是新技术的采用和软件过程的改进被作为日常的业务活动来加以计划和管理发展

17、1990年3月1日,SEI发布了CMM的0.0版本(仅包含关键活动的草表)给CMM用户工作组. 1991年3月18日,根据工作组的反馈,SEI发布了包含第二级KPA草案的CMM0.4版本.一个月后,SEI发布了第三级KPA草案(版本号为0.5). 1991年6月,经过修订和SEI内部的同级评审,0.6版本发布,其中包含了一些重大变化,如修改了KPA集合,和对KAP重新定义使之只适合于某一级. 随后,SEI有发布了包含CMM第四级和第五级KPA草案的0.7版本.直到1991年8月15日,经过多次修改,评审,问卷调查和集合用户反馈意见的CMM1.0版本终于正式发布. 1993年2月10日,SEI发

18、布了CMM1.1版本,其中增加了一个关于培训的KPA.技术内容CMM的结构和基本内容CMM描述了五个级别的软件过程成熟度（初始级 可重复级 已定义级 已管理级 优化级，成熟度反映了软件过程能力(Software Process Capability)的大小，任何一个软件机构的软件过程必定属于其中某个级别。除了第一级以外，每级成熟度又由若干关键过程域(Key Process Area)构成。五个成熟度及其关键过程领域如图所示： 图中的每个关键过程域分别针对软件过程的某一方面，具体描述了某级成熟度下软件过程在该方面所应达到的的一组目标和实现这些目标的一组关键活动（Key Practice）。所有关

19、键活动被划分为五类，分别为完成该组目标所需的承诺（Commitment to Perform）、前提条件（Ability to Perform）、实际动作（Activities performed）、度量分析（Measurement and Analysis）以及验证（Verifying Implementation）。上述五方面被称为五个Common Features。CMM的结构如图所示：需要提出的是，任何一个成熟度级别的关键过程域集都是本级描述的关键过程域集和所有下级的关键过程域集的并集。如3级的关键过程域就应有13个不同的域，其中7个是3级自己包含的，6个属于2级成熟度，而4级应有15

20、个域。第一级：初始级（The Initial Level）初始级的软件机构缺乏对软件过程的有效管理，其软件项目的成功来源于个人英雄主义而非机构行为，因此它不是可重复的。第二级：可重复级（The Repeatable Level）概述第二级软件机构的主要特点是：项目计划和跟踪的稳定性，项目过程的可控性和以往成功的可重复性。更具体的说：机构建立了管理软件项目的策略和实现这些策略的过程。新项目的计划和管理基于类似项目的经验。过程能力的增强基于以各个项目为基础的有纪律的基本过程管理。不同的项目可有不同的过程，而对机构的要求是具有指导项目建立适当管理过程的策略。每个项目都确定了基本的软件管理控制，包括：

21、基于前面项目的经验和新项目特点，做出现实的项目承诺（如预算、交付期、软件质量等）；软件项目管理者要跟踪开支、日程、软件功能；满足承诺的过程中的出现的问题要及时发现，妥善解决；定义了软件项目标准，且机构确保其被遵守。构成本级的关键过程领域（KPA）包括：需求管理（Requirements Management） 客户的需求是软件项目的基础。软件需求管理的目的是在客户和软件项目之间达成对客户需求的一致理解。目的：需求管理的目的是要建立客户与客户需求的软件项目之间的普遍的理解。 内容：建立维护一种与客户在软件项目上技术和非技术方面的认同。这种认同是在 整个软件生命周期中预算、计划、执行以及跟踪软件项

22、目活动的基础。 目标控制软件的分配给软件的系统需求来为软件工程和管理应用建立统一的基准；软件的计划、产品及活动要与软件的系统需求保持一致。承诺C1 项目要遵循一书面化的机构政策来管理软件的系统需求。 分配的软件系统需求要文档化软件需求要经过软件经理和受到影响的组的检查软件的计划、产品和活动的改变要与软件需求保持一致前提条件A1 针对每一个项目，有责任要分析系统需求，并把它们具体分配到软件、 硬件和其它的系统组件。其中责任包含两方面： 在整个项目周期中，系统需求以及它们的分配要有管理且文档化有效的修改系统需求及它们的分配A2 软件的系统需求要文档化。软件的系统需求包括： 影响、决定软件项目活动的

23、非技术需求软件的技术需求用来验证软件产品是否满足需求的接受度标准A3 提供充足的资源和资金来管理软件需求。 需要有在应用领域和软件工程有经验的人员和专家来管理需求需要有可用的工具A4 软件工程组和相关组的人员要经过培训来进行需求管理活动。 执行动作AC1 软件工程组在软件需求加入软件项目前，要对其进行检查。不完整和遗漏的地方要指出软件需求要被检查来判定它们是否可行、可清晰描述、可被测试和互相一致任何需求若被判定为有潜在问题。软件工程组需和负责需求分析的组在检查进行必要的修改需求分析的结果要通知所有受到影响的组AC2 软件工程组以软件需求分析作为软件计划、产品和活动的基础。 软件需求分析要加以管

24、理和控制软件需求分析是软件开发计划的基础软件需求分析是开发软件需求的基础AC3 软件需求分析的改变要检查并加入软件项目。 承诺的改变要经过磋商软件需求分析的改变引起在计划、产品和活动中相应的改变度量分析M1.度量所处活动的状态，从而来管理软件需求分析。 验证V1.高层的管理人员要定期的审查管理软件需求的活动。V2.项目经理要周期的用事件驱动的方式来审查管理软件需求的活动。 V3.软件质量保证组审查活动和产品来管理软件需求并报告结果。软件项目计划（Software Project Planning） 为软件工程和项目管理建立一个合理的计划。目的：为遵循软件工程概念并管理软件开发项目而建立合理的计

25、划。 内容 估测软件开发各阶段工作产品的大小，以及所需要的资源制订时间表，评估相关风险，并协商各方面的责任。按照客户的最终需求制订软件项目计划。目标为便于计划和跟踪完成情况将有关软件各方面的估算写入文档。计划完成软件项目的各种活动和相关责任，并将它写入文档。有关的工作组和相关人员需同意承担他们的责任。承诺任命一项目软件监督员（project software manager）负责协调各方面的责任并制订开发计划。C1. 为软件项目制订计划需要遵循一个标准的组织方针。该方针规定：1. 以软件的最终需求为基础。 2. 各项责任需要在项目负责人（project manager）、项目软件监督员、和其他

26、软件负责人（software manager）间协调。 3. 需要同其他工程组参与时，要同他们协商并将过程写入文档。 4. 相关组对软件项目提出意见。5. 当项目相关责任涉及到机构外人员或小组时需要更高层领导的审核。 6. 项目软件开发计划需要管理并控制（managed and controlled）。 前提条件： A1. 有关项目软件订立一个文档化并得到一致认可的工作说明（statement of work）。 1. 说明要包括从责任到目标到资源乃至时间表等所有相关内容。 2. 该说明要经由项目负责人、项目软件监督员、其他软件负责人、以及相关组一起审核。 3. 该工作说明需要管理并控制。 A

27、2. 制订软件开发计划的各项责任要落实到个人。 1. 项目软件监督员需亲自或指定相关人员协调计划的制订工作。 2. 软件工作产品及各项活动的职责需按可跟踪和可记录的方式划分并分配给各软件负责人。 A3. 为订立计划提供足够的资源和资金。 1. 各领域专家应尽可能参与。 2. 要有订立计划活动的支持工具。 A4. 相关人员（包括软件负责人和软件工程师）需要做软件评估和计划方面的培训。 执行动作AC1. 软件过程组要参与项目提案小组。 1. 涉及的内容包括提案的准备和提交、各项说明的讨论和提交、以及项目相关职责发生变动时的协商。 2. 过程组审核项目提案的各项承诺。 AC2. 软件项目计划需在整个

28、项目计划的早期阶段订立并同时进行。AC3. 软件工程组同其他相关组一起贯穿项目始终参与计划的制订（和修改），并负责审核项目级的计划。AC4. 对机构外个人或组所做的承诺需按照标准化的过程同高层管理者一起审核。AC5. 软件生命周期中可管理的预定义阶段需标识并确定。AC6. 项目软件开发计划需要按照标准化过程制订。1. 软件开发计划需基于：客户标准、项目标准、产品说明、以及客户需求。2. 其他工程组和软件相关组参与软件工程组活动的计划需相互协商、有关支出需预算、达成一致时需文档化。3. 软件工程组参与其他工程组和软件相关组活动的计划需相互协商、有关支出需预算、达成一致时需文档化。4. 制订的软件

29、开发计划需要由项目负责人、项目软件监督员、各软件负责人及相关组审核。 5. 软件开发计划需要管理和控制。AC7. 软件项目计划要文档化。计划内容包括： 1. 项目的目的、范围、目标以及成果。 2. 所遵循的软件生命周期模型。 3. 为开发和管理软件所选择的规程、方法和标准的标识。 4. 各软件工作产品的标识。 5. 各软件工作产品的大小以及变动情况。 6. 项目各项支出和成本的估算。 7. 关键计算机资源使用的估算。 8. 软件项目的时间表，包括重要阶段的识别和检查。9. 各种项目软件风险的识别和评估。10. 有关软件工程各种设施和支持工具的计划。AC8. 建立和维护对软件项目的控制所需要的软

30、件工作产品需要标识。 AC9. 按照文档化过程推导出对软件工作产品大小（或变动）的估算。1. 所有主要的软件工作产品和活动的大小要估算。2. 为达到估算的目标需要将工作产品分解到合适的粒度。3. 尽量使用历史上已有的数据。4. 有关大小估算的假设要文档化。5. 大小估算要文档化、得到审核、并取得一致。AC10. 按标准化过程导出对项目支出和成本的估算。1. 应基于工作产品大小估算（及变动大小）作支出和成本的估算。2. 应尽量使用目前或历史的生产率数据用于估算，相应的数据源及原由要文档化。数据可以来自机构内的其他项目，并且要考虑到生产工作产品的关键支出和成本。3. 对成本、人员、和支出的估算应基于历史数据。如使用来自相同项目的数据，并确定时间段和预算所估算值在生命周期各阶段间的分布。4. 估算值及所依据的假设要文档化、得到审核、并取得一致。AC11. 按照标准化过程导出对关键计算机资源使用的估算。 1. 识别所需的关键资源。2. 所作估算要相应于工作产品的大