CMM规范文档.docx
《CMM规范文档.docx》由会员分享，可在线阅读，更多相关《CMM规范文档.docx（70页珍藏版）》请在冰豆网上搜索。
CMM规范文档
文件编号20100001
CMM规范描述
（CapabilityMaturityModelforSoftware软件能力成熟度模型）
目录
CMM产生背景1
主要问题1
主要作用1
CMM的基本概念2
软件过程2
软件过程能力2
软件过程性能2
软件过程成熟度2
成熟与不成熟3
CMM的五级成熟度4
基本前提4
基本原理5
基本内容5
五个成熟度级别5
初始级5
第一级：
初始级6
第二级：
可重复级6
第三级：
定义级7
第四级：
管理级8
第五级：
优化级8
发展9
技术内容10
CMM的结构和基本内容10
第一级：
初始级（TheInitialLevel）12
第二级：
可重复级（TheRepeatableLevel）12
概述12
构成13
需求管理（RequirementsManagement）13
目标14
承诺14
前提条件14
执行动作15
度量分析16
验证16
软件项目计划（SoftwareProjectPlanning）16
内容17
目标17
承诺17
前提条件：
18
执行动作19
度量分析23
验证23
软件项目的跟踪和监督（SoftwareProjectTackingandOversight）24
目标25
行为的责任25
行为的能力26
活动32
度量和分析33
验证实施33
软件子合同管理（SoftwareSubcontractManagement）35
目的35
内容35
目标35
承诺36
前提条件36
执行动作36
度量分析37
验证37
软件质量保证（SoftwareQualityAssurance）38
目标38
承诺38
前提条件39
活动39
软件配置管理（SoftwareConfigurationManagement）40
目的40
内容40
目标41
承诺41
能力41
活动42
度量分析44
验证44
第三级：
已定义级（TheDefinedLevel）44
概述44
构成45
目标46
承诺46
前提条件46
执行动作46
度量分析47
验证47
机构过程定义（OrganizationProcessDefinition）47
内容48
目标48
承诺48
前提条件48
执行动作49
度量分析49
验证49
培训计划（TrainingProgram）49
目的50
内容50
目标50
承诺50
前提条件50
执行动作51
度量分析51
验证51
集成软件管理（IntegratedSoftwareManagement）52
目的52
内容52
目标52
承诺52
前提条件52
执行动作53
度量分析54
验证54
软件产品工程（SoftwareProductEngineering）54
目的54
目标54
承诺55
前提条件55
执行动作55
度量分析56
验证56
组间协调（IntergroupCoordination）57
目的57
内容57
目标57
承诺57
前提条件57
执行动作58
度量分析58
验证59
同行评审（PeerReviews）59
目的59
内容59
目标59
承诺60
前提条件60
执行动作60
度量分析60
验证60
第四级：
已管理级（TheManagedLevel）61
概述61
构成61
定量过程管理（QuantitativeProcessManagement）61
目的62
内容62
目标62
承诺62
能力63
活动63
度量分析64
软件质量管理（SoftwareQualityManagement）64
目的64
内容64
目标64
承诺65
能力65
活动65
度量分析65
验证65
第五级：
TheOptimizingLevel66
概述66
构成66
缺陷预防（DefectPrevention）66
目标67
承诺67
能力67
活动68
度量和分析68
验证实施68
技术变更管理（TechnologyChangeManagement）69
目标69
承诺70
能力70
活动70
度量和分析71
验证71
过程变更管理（ProcessChangeManagement）71
目标72
执行约定72
高级管理者73
执行能力73
执行的活动75
测量和分析86
验证实施87
CMM产生背景
主要问题
在过去的二十年里，新的软件开发方法和技术的使用并未使软件生产率和生产质量得到有效的提高。
软件生产商开始意识到他们的基本问题在于对软件的生产过程管理不力，主要体现在：
软件产品不能按时完成、超出预算的成本、以及采用新的技术和工具后其好处难以体现。
主要作用
CMM可以指导软件机构如何控制软件产品的开发和维护过程，以及如何向成熟的软件工程体系演化，并形成一套良性循环的管理文化。
具体说来，一个企业要想改进其生产过程，应该采取如下策略和步骤：
确定软件企业当前所处的过程成熟级别；
了解对改进软件生产质量和加强生产过程控制起关键作用的因素；
将工作重点集中在有限几个关键目标上，有效达到改进机构软件生产过程的效果，进而可持续地改进其软件生产能力。
CMM的基本概念
软件过程
人们在开发和维护软件及其相关产品时所涉及的各种活动、方法、实践和改革等。
其中软件相关产品包括软件项目计划、设计文档、程序代码、测试用例和用户手册等。
软件过程能力
当遵循某个软件过程时所能达到的期望效果，它可以有效预测企业接收新的软件项目时可能得到的结果。
软件过程性能
当遵循某个软件过程时所达到的实际效果。
它可以用于验证软件过程能力。
软件过程成熟度
指一个特定的软件过程被显式定义、管理、度量、控制和能行的程度。
成熟度可以用于指示企业加强其软件过程能力的潜力。
当一个企业达到了一定的软件过程成熟级别后，它将通过制定策略、建立标准和确立机构结构使它的软件过程制度化。
而制度化又促使企业通过建立基础设施和公司文化来支持相关的方法、实践和过程。
从而使之可以持续并维持一个良性循环。
成熟与不成熟
企业要通过选择最关键的目标来进行过程改进，应该搞清成熟的软件过程和不成熟的过程之间的差异。
不成熟的企业有如下标志：
缺乏确定的软件过程和相应的管理和控制；
即使给出了软件过程，也不严格的遵循和强制执行；
管理是完全被动的，管理者采用的策略是救火式的，即出了事才去解决，解决的时候也难以纵观全局，往往只顾眼前；
由于缺乏有依据的估算，制订软件预算和生产计划时往往跟着感觉走，实际生产时则常常超标；
如果强制在预定期限内完成，那么软件的功能和质量肯定是得不到保证；
缺乏评价软件产品质量和解决产品缺陷和过程问题的客观基础。
成熟的企业则有如下标志：
具有在企业范围内管理、控制软件开发和维护过程的能力；
现有人员和新进人员均了解所遵循的软件过程，且工作活动均按照事先的计划完成；
在定义好的软件过程中，所有项目和机构中的角色和责任分明；
制定的计划是有效的且与实际的工作进展一致；
软件过程在必要时可按照一定规则和程序加以修改；
软件产品和过程的具有一定的可控性。
这主要体现在：
管理者能够监督软件产品的质量和生产过程；
具有客观的和定量化的措施来判断产品质量并分析产品与生产过程中的问题；
计划和预算有章可循，它是基于历史数据的，从而是实际可行的；
预算的结果，包括成本、时间表、产品功能和质量等，通常能够达到；
有关的参与者完全理解遵循软件过程的价值并认真地遵循之；
具有支撑软件过程的基础设施，如标准过程库、历史数据库等。
CMM的五级成熟度
基本前提
软件质量在很大程度上取决于产生软件的软件过程的质量和能力；
软件过程是一个可管理、可度量并不断改进的过程；
软件过程的质量受到用以支撑它的技术和设施的影响；
企业在软件过程中所采用的技术层次应适应于软件过程的成熟度。
基本原理
CMM强调连续的软件过程改进。
该连续的改进基于多个演化步骤。
CMM将这些演化步骤划分成五个级别。
这种分级结构的理论依据是软件质量原理。
每一级别都包括若干目标。
当满足某一目标后，软件过程的相应部分便确定下来。
五级成熟度定义了一个标准，用以度量机构的软件过程成熟度和评价其软件过程能力。
基本内容
CMM的成熟度理论目前主要涉及如下内容：
机构和资源的管理:
涉及机构本身的责任，人员和其它资源设施。
软件工程过程及其管理:
涉及软件工程过程，即软件过程的深度、范围和完整性以及如何度量、管理和改进这样的过程。
工具和技术:
软件工程过程中使用的开发工具和技术。
五个成熟度级别
初始级
可重复级：
有规章的过程
定义级：
标准化、一致的过程
管理级：
可预测过程
优化级：
可持续改进的过程
成熟度的行为刻划
第一级：
初始级
成功来源于个人英雄主义而非机构行为，因此它不可重复，更换人员后成功便难以维持。
第二级：
可重复级
针对特定软件项目建立管理该项目的策略和实现这些策略的过程。
新项目的计划和管理基于类似项目的经验。
软件过程能力主要通过管理单个项目的软件生产过程来得到提高和增强。
不同的项目可有不同的软件过程，机构应当建立一定的方针和策略以针对具体的项目选择合适的软件生产过程并进行管理。
可重复级的主要特点在于确定了基本的软件生产管理和控制，具体来讲，有：
结合已有项目的经验和新项目的特点来确定本项目的责任和承诺；
软件生产成本、时间表和实现的功能被有效跟踪；
识别实现承诺所需解决的关键问题；
定义软件项目过程标准，机构要确保其被遵守。
概括来说，第二级的主要特点是项目计划和跟踪是确定且有效的，项目的软件过程是可控的，以及已有的成功经验是可重复的。
第三级：
定义级
有一个机构范围内标准的软件过程，软件工程活动和管理活动被集成为一个有机的整体。
标准化的目的是使高层管理者和软件技术人员能够有效合作。
有一个组例如软件工程组（SEPG）专门负责订立机构的标准软件过程，并且在机构中制定培训计划来确保相关人员和管理者有足够的知识和技能完成标准过程所赋予的角色。
标准的软件过程结合具体项目的特点经过裁剪即形成项目定义软件过程，它是一组集成的完善定义的软件工程和管理过程。
一个完善定义的软件过程应包括就绪准则、输入、工作过程、验证机制、输出和完成准则。
对于已建立的产品生产线，其成本、时间表和实现功能均可跟踪和控制，软件产品的质量可以得到保证。
软件过程能力的实现主要基于在机构范围内对一个定义软件过程的活动、角色和责任的共同理解。
概括来说，第三级的主要特征在于软件过程已被提升成标准化过程，从而更加具有稳定性、重复性和可控性。
第四级：
管理级
软件的过程和产品有定量的质量指标。
重要的软件过程活动均配有生产率和质量方面的度量指标；
应用数据库来收集和分析定义软件过程中涉及的各种数据；
对项目软件过程和软件质量的评价有定量的基准。
软件项目的产品和生产过程的控制具有可预测性。
将软件过程性能可能出现的偏差控制在可接受的量化界限内；
具体区分影响过程性能发生偏差的有效因素和偶然因素；
向新领域拓展的风险是可预知的并被仔细管理和权衡。
概括来说，第四级的主要特征是定量化、可预测、异常控制和高质量。
第五级：
优化级
机构集中于持续的过程改进
具有标识过程缺陷和增强过程能力的有效手段。
利用试验数据分析使用新技术所需的代价和带来的效益，然后再有选择地采用。
当出现偏差时，软件项目人员能够分析出错原因并采取有效手段防止其再次出现。
防止不必要的浪费是第五级的重点。
改进的途径有两个，一个是对已有过程的渐进式改进；另一个则是有选择地使用新技术和新方法所带来的革新。
概括来说，第五级的主要特征是新技术的采用和软件过程的改进被作为日常的业务活动来加以计划和管理
发展
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发布了CMM1.1版本,其中增加了一个关于培训的KPA.
技术内容
CMM的结构和基本内容
CMM描述了五个级别的软件过程成熟度（初始级可重复级已定义级已管理级优化级，成熟度反映了软件过程能力（SoftwareProcessCapability）的大小，任何一个软件机构的软件过程必定属于其中某个级别。
除了第一级以外，每级成熟度又由若干关键过程域（KeyProcessArea）构成。
五个成熟度及其关键过程领域如图所示：
图中的每个关键过程域分别针对软件过程的某一方面，具体描述了某级成熟度下软件过程在该方面所应达到的的一组目标和实现这些目标的一组关键活动（KeyPractice）。
所有关键活动被划分为五类，分别为完成该组目标所需的承诺（CommitmenttoPerform）、前提条件（AbilitytoPerform）、实际动作（Activitiesperformed）、度量分析（MeasurementandAnalysis）以及验证（VerifyingImplementation）。
上述五方面被称为五个CommonFeatures。
CMM的结构如图所示：
需要提出的是，任何一个成熟度级别的关键过程域集都是本级描述的关键过程域集和所有下级的关键过程域集的并集。
如3级的关键过程域就应有13个不同的域，其中7个是3级自己包含的，6个属于2级成熟度，而4级应有15个域。
第一级：
初始级（TheInitialLevel）
初始级的软件机构缺乏对软件过程的有效管理，其软件项目的成功来源于个人英雄主义而非机构行为，因此它不是可重复的。
第二级：
可重复级（TheRepeatableLevel）
概述
第二级软件机构的主要特点是：
项目计划和跟踪的稳定性，项目过程的可控性和以往成功的可重复性。
更具体的说：
机构建立了管理软件项目的策略和实现这些策略的过程。
新项目的计划和管理基于类似项目的经验。
过程能力的增强基于以各个项目为基础的有纪律的基本过程管理。
不同的项目可有不同的过程，而对机构的要求是具有指导项目建立适当管理过程的策略。
每个项目都确定了基本的软件管理控制，包括：
基于前面项目的经验和新项目特点，做出现实的项目承诺（如预算、交付期、软件质量等）；
软件项目管理者要跟踪开支、日程、软件功能；
满足承诺的过程中的出现的问题要及时发现，妥善解决；
定义了软件项目标准，且机构确保其被遵守。
构成
本级的关键过程领域（KPA）包括：
需求管理（RequirementsManagement）
客户的需求是软件项目的基础。
软件需求管理的目的是在客户和软件项目之间达成对客户需求的一致理解。
目的：
需求管理的目的是要建立客户与客户需求的软件项目之间的普遍的理解。
内容：
建立维护一种与客户在软件项目上技术和非技术方面的认同。
这种认同是在
整个软件生命周期中预算、计划、执行以及跟踪软件项目活动的基础。
目标
控制软件的分配给软件的系统需求来为软件工程和管理应用建立统一的基准；
软件的计划、产品及活动要与软件的系统需求保持一致。
承诺
C1项目要遵循一书面化的机构政策来管理软件的系统需求。
分配的软件系统需求要文档化
软件需求要经过软件经理和受到影响的组的检查
软件的计划、产品和活动的改变要与软件需求保持一致
前提条件
A1针对每一个项目，有责任要分析系统需求，并把它们具体分配到软件、
硬件和其它的系统组件。
其中责任包含两方面：
在整个项目周期中，系统需求以及它们的分配要有管理且文档化
有效的修改系统需求及它们的分配
A2软件的系统需求要文档化。
软件的系统需求包括：
影响、决定软件项目活动的非技术需求
软件的技术需求
用来验证软件产品是否满足需求的接受度标准
A3提供充足的资源和资金来管理软件需求。
需要有在应用领域和软件工程有经验的人员和专家来管理需求
需要有可用的工具
A4软件工程组和相关组的人员要经过培训来进行需求管理活动。
执行动作
AC1软件工程组在软件需求加入软件项目前，要对其进行检查。
不完整和遗漏的地方要指出
软件需求要被检查来判定它们是否可行、可清晰描述、可被测试和互相一致
任何需求若被判定为有潜在问题。
软件工程组需和负责需求分析的组在检查进行必要的修改
需求分析的结果要通知所有受到影响的组
AC2软件工程组以软件需求分析作为软件计划、产品和活动的基础。
软件需求分析要加以管理和控制
软件需求分析是软件开发计划的基础
软件需求分析是开发软件需求的基础
AC3软件需求分析的改变要检查并加入软件项目。
承诺的改变要经过磋商
软件需求分析的改变引起在计划、产品和活动中相应的改变
度量分析
M1.度量所处活动的状态，从而来管理软件需求分析。
验证
V1.高层的管理人员要定期的审查管理软件需求的活动。
V2.项目经理要周期的用事件驱动的方式来审查管理软件需求的活动。
V3.软件质量保证组审查活动和产品来管理软件需求并报告结果。
软件项目计划（SoftwareProjectPlanning）
为软件工程和项目管理建立一个合理的计划。
目的：
为遵循软件工程概念并管理软件开发项目而建立合理的计划。
内容
估测软件开发各阶段工作产品的大小，以及所需要的资源
制订时间表，评估相关风险，并协商各方面的责任。
按照客户的最终需求制订软件项目计划。
目标
为便于计划和跟踪完成情况将有关软件各方面的估算写入文档。
计划完成软件项目的各种活动和相关责任，并将它写入文档。
有关的工作组和相关人员需同意承担他们的责任。
承诺
任命一项目软件监督员（projectsoftwaremanager）负责协调各方面的责任并制订开发计划。
C1.为软件项目制订计划需要遵循一个标准的组织方针。
该方针规定：
1.以软件的最终需求为基础。
2.各项责任需要在项目负责人（projectmanager）、项目软件监督员、和其他软件负责人（softwaremanager）间协调。
3.需要同其他工程组参与时，要同他们协商并将过程写入文档。
4.相关组对软件项目提出意见。
5.当项目相关责任涉及到机构外人员或小组时需要更高层领导的审核。
6.项目软件开发计划需要管理并控制（managedandcontrolled）。
前提条件：
A1.有关项目软件订立一个文档化并得到一致认可的工作说明（statementofwork）。
1.说明要包括从责任到目标到资源乃至时间表等所有相关内容。
2.该说明要经由项目负责人、项目软件监督员、其他软件负责人、以及相关组一起审核。
3.该工作说明需要管理并控制。
A2.制订软件开发计划的各项责任要落实到个人。
1.项目软件监督员需亲自或指定相关人员协调计划的制订工作。
2.软件工作产品及各项活动的职责需按可跟踪和可记录的方式划分并分配给各软件负责人。
A3.为订立计划提供足够的资源和资金。
1.各领域专家应尽可能参与。
2.要有订立计划活动的支持工具。
A4.相关人员（包括软件负责人和软件工程师）需要做软件评估和计划方面的培训。
执行动作
AC1.软件过程组要参与项目提案小组。
1.涉及的内容包括提案的准备和提交、各项说明的讨论和提交、以及项目相关职责发生变动时的协商。
2.过程组审核项目提案的各项承诺。
AC2.软件项目计划需在整个项目计划的早期阶段订立并同时进行。
AC3.软件工程组同其他相关组一起贯穿项目始终参与计划的制订（和修改），并负责审核项目级的计划。
AC4.对机构外个人或组所做的承诺需按照标准化的过程同高层管理者一起审核。
AC5.软件生命周期中可管理的预定义阶段需标识并确定。
AC6.项目软件开发计划需要按照标准化过程制订。
1.软件开发计划需基于：
客户标准、项目标准、产品说明、以及客户需求。
2.其他工程组和软件相关组参与软件工程组活动的计划需相互协商、有关支出需预算、达成一致时需文档化。
3.软件工程组参与其他工程组和软件相关组活动的计划需相互协商、有关支出需预算、达成一致时需文档化。
4.制订的软件开发计划需要由项目负责人、项目软件监督员、各软件负责人及相关组审核。
5.软件开发计划需要管理和控制。
AC7.软件项目计划要文档化。
计划内容包括：
1.项目的目的、范围、目标以及成果。
2.所遵循的软件生命周期模型。
3.为开发和管理软件所选择的规程、方法和标准的标识。
4.各软件工作产品的标识。
5.各软件工作产品的大小以及变动情况。
6.项目各项支出和成本的估算。
7.关键计算机资源使用的估算。
8.软件项目的时间表，包括重要阶段的识别和检查。
9.各种项目软件风险的识别和评估。
10.有关软件工程各种设施和支持工具的计划。
AC8.建立和维护对软件项目的控制所需要的软件工作产品需要标识。
AC9.按照文档化过程推导出对软件工作产品大小（或变动）的估算。
1.所有主要的软件工作产品和活动的大小要估算。
2.为达到估算的目标需要将工作产品分解到合适的粒度。
3.尽量使用历史上已有的数据。
4.有关大小估算的假设要文档化。
5.大小估算要文档化、得到审核、并取得一致。
AC10.按标准化过程导出对项目支出和成本的估算。
1.应基于工作产品大小估算（及变动大小）作支出和成本的估算。
2.应尽量使用目前或历史的生产率数据用于估算，相应的数据源及原由要文档化。
数据可以来自机构内的其他项目，并且要考虑到生产工作产品的关键支出和成本。
3.对成本、人员、和支出的估算应基于历史数据。
如使用来自相同项目的数据，并确定时间段和预算所估算值在生命周期各阶段间的分布。
4.估算值及所依据的假设要文档化、得到审核、并取得一致。
AC11.按照标准化过程导出对关键计算机资源使用的估算。
1.识别所需的关键资源。
2.所作估算要相应于工作产品的大
升级会员 