CMM规范文档可编辑修改word版.docx
《CMM规范文档可编辑修改word版.docx》由会员分享，可在线阅读，更多相关《CMM规范文档可编辑修改word版.docx（61页珍藏版）》请在冰点文库上搜索。
CMM规范文档可编辑修改word版
文件编号20100001
CMM规范描述
（CapabilityMaturityModelforSoftware软件能力成熟度模型）
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.所作估算要相应于工作产品的大小、处理负载、以及通信量。
3.所作估算要文档化、得到审核、并取得一致。
AC12.按照标准化过程确定项目软件的时间表。
1.时间表应基于工作产品的大小（变动大小）、以及软件支出和成本。
2.时间表应基于已有项目的经验。
3.时间表应包括关键阶段（milestone）的日期、关键依赖的日期以及其他有关约束。
4.时间表中的活动应有适当的时间段、关键阶段要有适当间隔以确保进度测定的准确性。
5.有关时间表的假设要文档化。
6.时间表要文档化、得到审核、并取得一致。
AC13.有关成本、资源、时间表、以及技术应用的软件风险要标识、评估、并文档化。
1.按照潜在影响分析风险并确定优先级。
2.识别风险的偶然性。
AC14.制订有关工程设施和支持工具的计划。
1.功能需求的估算应基于工作产品的估算及其他相关特性。
2.为获得或开发这些设施和工具有关的职责要分配，相关承诺要协商。
3.该计划要经由相关组审核。
AC15.软件计划有关的数据要记录在案。
1.记录所有的估算值，以及为重建这些估算值和评测其合理性所需的所有相关信息。
2.计划数据要管理并控制。
度量分析
M1.测量主要被用于确定软件计划活动所处的状态。
验证
V1.同高层管理者一起周期性检查软件项目计划活动。
1.技术、成本、人员和时间表的效能要审核。
2.底层不能解决的问题和矛盾要处理。
3.软件项目风险要解决。
4.各项任务需分配、审核并跟踪直至任务完成。
5.每次会议的总结性报告要准备好并分发给相关组和个人。
V2.项目负责人周期性或当重要事件发生时审核项目软件的计划活动。
1.有关组要派代表。
2.基于工作说明和需求审核计划活动的状态和当前结果。
3.各组间的依赖关系需要处理。
4.底层不能解决的问题和矛盾需要处理。
5.风险要审核。
6.任务项要分配、审核并跟踪。
7.会议的总结性报告要分发。
V3.软件质量保证组要审核并审计计划活动和工作产品，同时汇报结果。
审核内容包括：
1.软件估算和计划活动。
2.项目承诺的制定和审核活动。
3.软件开发计划的准备活动。
4.软件开发计划所采用的标准。
5.软件开发计划的内容。
软件项目的跟踪和监督（SoftwareProjectTackingand
Oversight）
使管理者对实际的软件项目进展过程有足够的了解，以在项目效能偏离计划太多是采取有效措施。
目的是提供实际进程的充分的可视性，以便当软件项目的执行严重偏离软件计划时管理者能够采取有效的措施。
软件项目跟踪和监督包括根据文档化的评估、责任和计划跟踪和审核软件的完成和结果并在实际的完成和结果的基础上调整计划。
文档化的软件项目计划（即在KPA-软件项目计划中描述的软件开发计划）用于跟踪软件活动、交流状况和修改计划的基础。
软件活动由管理者进行监控。
当所选择的软件工作产品完成并处于所选择的里程碑时，首要通过实际软件规模、努力、成本和进度表与计划的对比来确定进程。
如果确认不符合项目计划，采取矫正措施。
该措施可包括更改软件开发计划以反映实际完成情况、重新计划剩余的工作或采取行动改善操作。
目标
目标1根据软件计划跟踪实际结果和完成情况。
目标2如果实际结果和完成情况严重偏离软件计划，采取和管理矫正措施直至结束。
目标3软件责任的改变要经受影响部门和个人的同意。
行为的责任
责任1指定一个项目软件经理负责项目软件的活动和结果。
责任2项目依照书面的管理软件项目的组织性原则进行。
这一原则代表性地说明了：
1.一个文档化的软件开发计划作为跟踪软件项目的基础运用和维护。
2.项目经理始终了解软件项目的状况和问题。
3.软件计划未获完成时采取措施，调整操作或调整计划。
4.经受影响部门的参与和认可修改软件责任。
受影响部门包括：
软件工程（包括所有的子部门，如软件设计）软件评估
系统工程系统测试
软件质量保证软件配置管理合同管理
文档支持
5.高级经理审核所有责任的变动和新的针对个人和机构外部门的软件项目责任。
行为的能力
能力1文档化和批准软件项目的软件开发计划。
参阅KPA-软件项目计划的活动6&7中涉及软件开发计划的实践。
能力2项目软件经理明确地分配软件工作产品和活动的责任。
分配的责任包括：
1.要开发的软件工作产品或要提供的服务。
2.软件活动的努力和成本。
3.软件活动的进度表。
4.软件活动的预算
能力3提供充足的资源和资金用于跟踪软件项目。
1.分配特定的责任给软件经理和软件任务负责人，以跟踪软件项目。
2.开发支持软件跟踪的工具。
支持工具的例子包括：
电子数据表程序
项目计划/进度程序
能力4培训软件经理进行软件项目的技术和人事方面的管理。
培训的例子包括：
管理技术项目
跟踪和勘查软件规模、努力和成本和进度管理人员
能力5一级软件经理接受软件项目技术方面的指导。
指导的例子包括：
项目软件工程标准和程序项目的应用领域
进行的活动
活动
升级会员 