范文一:能力成熟度模型
能力成熟度模型
能力成熟度模型(Capability Maturity Model,英文缩写为CMM)[1]是一种开发模型。Carnegie Mellon大学的研究人员从美国国防部合同承包方那里收集数据并加以研究,提出了CMM。美国国防部资助了这项研究。Carnegie Mellon以该模型为基础,创办了软件工程研究所(SEI)。CMM的目标是改善现有软件开发过程,也可用于其它过程。
它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程,并根据这一原则对软件开发和维护过程进行监控和研究。
CMM是一种用于评价软件承包能力以改善软件质量的方法,侧重于软件开发过程的管理及工程能力的提高与评估。分为五个等级:一级为初始级,二级为可重复级,三级为已定义级,四级为已管理级,五级为优化级。
其假设是:只要集中精力持续努力去建立有效的软件工程过程的基础结构,不断进行管理的实践和过程的改进,就可以克服软件生产中的困难。
历史
1984年,美国国防部资助建立了卡内基·梅隆大学软件研究所(SEI)[2];1987年,SEI发布第一份技术报告介绍软件能力成熟度模型(CMM)及作为评价国防合同承包方过程成熟度的方法论;1991年,SEI发表1.0版软件CMM(SW-CMM)。 CMM自1987年开始实施认证,现已成为软件业权威的评估认证体系。CMM包括5个等级,共计18个过程域,52个目标,300多个关键实践。
CMM等级
能力等级 特点 关键过程
软件工程管理制度缺乏,过程缺乏定
义、混乱无序。成功依靠的是个人的才
第一级 初始能和经验,经常由于缺乏管理和计划导
级(最低级) 致时间、费用超支。管理方式属于反应
式,主要用来应付危机。过程不可预测,
难以重复。
基于类似项目中的经验,建立了基本的
项目管理制度,采取了一定的措施控制需求管理,项目计划,项目跟踪和监控,软第二级 可重费用和时间。管理人员可及时发现问件子合同管理,软件配置管理,软件质量保复级 题,采取措施。一定程度上可重复类似障
项目的软件开发。
已将软件过程文档化、标准化,可按需组织过程定义,组织过程焦点,培训大纲,第三级 已定要改进开发过程,采用评审方法保证软软机集成管理,软件产品工程,组织协调,义级 件质量。可借助CASE工具提高质量和专家审评 效率。
第四级 已管针对制定质量、效率目标,并收集、测定量的软件过程管理和产品质量管理 理级 量相应指标。利用统计工具分析并采取
改进措施。对软件过程和产品质量有定
量的理解和控制。
第五级 优化
基于统计质量和过程控制工具,持续改缺陷预防,过程变更管理和技术变更管理 级(最高级) 进软件过程。质量和效率稳步改进。
CMM能力成熟度各级特点和关键过程。[3]
基本思想
CMM的基本思想是,因为问题是由我们管理软件过程的方法引起的,所以新软件技术的运用不会自动提高生产率和利润率。CMM有助于组织建立一个有规律的、成熟的软件过程。改进的过程将会生产出质量更好的软件,使更多的软件项目免受时间和费用的超支之苦。
CMM实施步骤
软件过程包括各种活动、技术和用来生产软件的工具。因此,它实际上包括了软件生产的技术方面和管理方面。CMM策略力图改进软件过程的管理,而在技术上的改进是其必然的结果。
必须牢记,软件过程的改善不可能在一夜之间完成,CMM是以增量方式逐步引入变化的。CMM明确地定义了5个不同的“成熟度”等级,一个组织可按一系列小的改良性步骤向更高的成熟度等级前进。
整个企业将会把重点放在对过程进行不断的优化,采取主动的措施去找出过程的弱点与长处,以达到预防缺陷的目标。同时,分析各有关过程的有效性资料,作出对新技术的成本与效益的分析,并提出对过程进行修改的建议。达到该级的公司可自发的不断改进,防止同类缺陷二次出现。
在表中可以看出,CMM为软件的过程能力提供了一个阶梯式的改进框架,它基于以往软件工程的经验教训,提供了一个基于过程改进的框架图,它指出一个软件组织在软件开发方面需要哪些主要工作,这些工作之间的关系,以及开展工作的先后顺序,一步一步的做好这些工作而使软件组织走向成熟。CMM的思想来源于已有多年历史的项目管理和质量管理,自产生以来几经修订,成为软件业具有广泛影响的模型,并对以后项目管理成熟度模型的建立产生了重要的影响。尽管已有个人或团体提出了各种各样的成熟度模型,但还没有一个像CMM那样在业界确立了权威标准的地位。但PMI于2003年发布的OPM3以其立体的模型及涵盖范围的广泛有望成为项目管理界的新标准。
意义
软件开发的风险之所以大,是由于软件过程能力低,其中最关键的问题在于软件开发组织不能很好地管理其软件过程,从而使一些好的开发方法和技术起不到预期的作用。而且项目的成功也是通过工作组的杰出努力,所以仅仅建立在可得到
特定人员上的成功不能为全组织的生产和质量的长期提高打下基础,必须在建立有效的软件如管理工程实践和管理实践的基础设施方面,坚持不懈地努力,才能不断改进,才能持续地成功。
软件质量是模糊的、捉摸不定的概念。我们常常听说:某某软件好用, 某某软件不好用;某某某软件功能全、结构合理, 某某某软件功能单一、操作困难??这些模模糊糊的语言不能算作是软件质量评价,更不能算作是软件质量科学的定量的评价。软件质量,乃至于任何产品质量,都是一个很复杂的事物性质和行为。产品质量,包括软件质量,是人们实践产物的属性和行为,是可以认识,可以科学地描述的。可以通过一些方法和人类活动,来改进质量。
实施CMM是改进软件质量的有效方法:控制软件生产过程、提高软件生产者组织性和软件生产者个人能力的有效合理的方法。
软件工程和很多研究领域及实际问题有关,主要相关领域和因素有:
需求工程(REQUIREMENTS ENGINEERING)。理论上,需求工程是应用已被证明的原理、技术和工具,帮助系统分析人员理解问题或描述产品的外在行为。
软件复用(SOFTWARE REUSE),定义为利用工程知识或方法,由一已存在的系统,来建造一新系统。这种技术,可改进软件产品质量和生产率。
还有软件检查、软件计量、软件可靠性、软件可维修性、软件工具评估和选择等。 现状
中国生产力促进协会、北航SEI、中科院研究SEI等科研机构已于近几年在北京、上海、广州和深圳等地先后举办过多次报告会和研讨会,组织过课程学习和应用实验,开展了软件过程方面的研究与开发工作,并发表了多篇的研究成果和学术论文,在软件质量保障平台支撑环境也取得了一定的成果。
近两年来,CMM在我国获得了各界越来越多关注,业界有过多次关于CMM的讨论,2000年6月国务院颁发的《鼓励软件产业和集成电路产业发展的若干政策》对中国软件企业申请CMM认证给予了积极的支持和推动作用,第17条规定"对软件出口型企业CMM认证费用予以适当支持。"2000年中关村电脑节上还有CMM专题论坛,吸引了众多业内人士。鼎新、东大阿尔派、联想、方正、金蝶、用友、浪潮、创智、华为等大型集团或企业等都从1997---2000年起批企业都在进行研究、实验或实施预评估。其中鼎新公司从1997年着手进行CMM认证工作。1999年7月通过第三方认证机构的CMM2认证。东大阿尔派公司于2000年10月通过第三方认证机构的CMM2认证。2001年1月,联想软件经过英国路透集团的严格评估,顺利通过CMM2认证。2001年6月26日,沈阳东软软件股份有限公司(原沈阳东大阿尔派软件股份有限公司)正式通过了CMM3级认证,成为中国首家通过CMM3级的软件企业。
总体上讲,国内对软件过程理论的讨论与实践正在展开,目标是使软件的质量管理和控制达到国际先进水平,中国的软件产业获得可持续发展的能力。专家分析,在未来两三年内,国内软件业势必将出现实施CMM的高潮。从这一趋势看,中国的软件企业已经开始走上标准化、规范化、国际化的发展道路,中国软件业已经面临一个整体突破的时代。
但是我们应该看到目前国内对软件管理工程存在的最大问题是认识不足。管理实际上是一把手工程,需要高层管理人员的足够重视。而且软件过程的重大修改也
必须由高层管理部门启动,这是软件过程改善能否进行到底的关键。此外,软件过程的改善还有待于全体有关人员的积极参与。
除了要认识到过程改善工作是一把手工程这个关键因素外,还应认识到软件过程成熟度的升级本身就是一个过程,且有一个生命周期。过程改善工作需要循序渐进,不能一蹴而就,需要持续改善,不能停滞不前;需要联系实际,不能照本宣科;需要适应变革,不能凝固不变。一个有效的途径是自顶向下的课程培训,即从高层主管依次普及到下面的工程师。
基本概念
CMMI(Capability Maturity Model Integration,能力成熟度模型集成) 将各种能力成熟度模型(即:Software CMM、Systems Eng-CMM、People CMM和Acquisition CMM)整合到同一架构中去,由此建立起包括软件工程、系统工程和软件采购等在内的诸模型的集成,以解决除软件开发以外的软件系统工程和软件采购工作中的迫切需求。
CMMI框架包括软件能力成熟度模型CMM 2.0草案,系统工程能力成熟度模型,软件采购能力成熟度模型,继承产品和过程开发等。
CMMI的:“关键过程域”25个,“目标”105个, “关键实践”485条。 CMMI的评估方式:
自我评估:用于本企业领导层评价公司自身的软件能力。
主任评估:使本企业领导层评价公司自身的软件能力,向外宣布自己企业的软件能力。
CMMI的评估类型:
软件组织的关于具体的软件过程能力的评估。
软件组织整体软件能力的评估(软件能力成熟度等级评估)。
CMMI的基本思想
1、解决软件项目过程改进难度增大问题
2、实现软件工程的并行与多学科组合
3、实现过程改进的最佳效益
背景介绍: CMM是“软件能力成熟度模型”的英文简写,该模型由美国卡内基-梅隆大学的软件工程研究所(简称SEI)受美国国防部委托,于1991年研究制定,初始的主要目的是为了评价美国国防部的软件合同承包组织的能力,后因为在软件企业应用CMM模型实施过程改进取得较大的成功,所以在全世界范围内被广泛使用,SEI同时建立了主任评估师评估制度,CMM的评估方法为CBA-IPI。 CMMI是SEI于2000年发布的CMM的新版本。CMMI不但包括了软件开发过程改进,还包含系统集成、软硬件采购等方面的过程改进内容。CMMI纠正了CMM存在的一些缺点,使其更加适用企业的过程改进实施。CMMI适用SCAMPI评估方法。需要注意的是,SEI没有废除CMM模型,只是停止了CMM评估方法:CBA-IPI。现在如要进行CMM评估,需使用SCAMPI方法。但CMMI模型最终代替CMM模型的趋势不可避免。
标准特点: CMM/CMMI/SPCA的思想来源于已有多年历史的产品质量管理和全面质量管理。Watts Humphrey和Ron Radice在IBM公司将全面质量管理的思想应用于软件工程过程,收到了很大的成效。SEI的软件能力成熟度框架就是在以Humphrey为主的软件专家实践经验的基础上发展而来的。软件能力成熟度模型
中融合了全面质量管理的思想,以5个不断进化的层次反映了软件过程定量控制中项目管理和项目工程的基本原则。CMM/CMMI/SPCA所依据的想法是只要不断地对企业的工程过程的基础结构和实践进行管理和改进,就可以克服软硬件生产中的困难,增强开发制造能力,从而能按时地、不超预算地制造出高质量的软件产品。
CMM简介
CMM(Capability Maturity Model)是能力成熟度模型的缩写,CMM是国际公认的对软件公司进行成熟度等级认证的重要标准。CMM的工作最早开始于86年11月,当时为满足美国政府评估软件供应商能力并帮助其改善软件质量的要求,由美国国防部资助的卡内基—梅隆大学的软件工作研究所(SEI)牵头,在Mitre公司协助下,于87年9月发布了一份能力成熟度框架(Capability Maturity Framework)以及一套成熟度问卷(Maturity Questionnaire)。四年后,SEI在总结自87年以来对成熟度框架和初版成熟度问卷的经验基础上,推出了CMM1.0版。CMM1.0版在成熟度框架的基础上建立了一个可用的模型,该模型可以更加有效地帮助软件公司建立和实施过程改进计划。两年后,SEI于93年推出了CMM1.1版。近几年,SEI又推出了CMM2.0版,同时进入了ISO体系,称为ISO/IEC15504(软件过程评估)。
CMM共分五级。在每一级中,定义了达到该级过程管理水平所应解决的关键问题和关键过程。每一较低级别是达到较高级别的基础。其中五级是最高级,即优化级,达到该级的软件公司过程可自发地不断改进,防止同类问题二次出现;四级称为已管理级,达到该级的软件公司已实现过程的定量化;三级为已定义级,即过程实现标准化;二级为可重复级,达到该级的软件公司过程已制度化,有纪律,可重复;一级为初始级,过程无序,进度、预算、功能和质量等方面不可预测。 CMM致力于软件开发过程的管理和工程能力的提高与评估。该模型在美国和北美地区已得到广泛应用,同时越来越多的欧洲和亚洲等国家的软件公司正积极采纳CMM,CMM实际上已成为软件开发过程改进与评估事实上的工业标准。如今,全球通过CMM五级评估的软件公司大约有十几家,三级以上的大约有100余家,通过二级评估的有300家左右。软件大国印度在这方面工作开展的比较广泛,受益匪浅。目前,我国只有清华同方和IBM的合资公司——鼎新信息开发有限公司于99年7月通过CMM二级评估,该公司表示将争取早日通过CMM三级评估。 CMM与ISO9000的主要区别:
1.CMM是专门针对软件产品开发和服务的,而ISO9000涉及的范围则相当宽。
2.CMM强调软件开发过程的成熟度,即过程的不断改进和提高。而ISO9000则强调可接收的质量体系的最低标准。
引进CMM的主要意义
一.对软件公司
1.提高软件公司软件开发的管理能力,因为CMM可提供软件公司自我评估的方法和自我提高的手段。
2.提高软件生产率。
3.提高软件质量。
4.提高软件公司的国内和国际竞争力。
二.对软件项目发包单位和软件用户
提供了对软件开发商开发管理水平的评估手段,有助于软件开发项目的风险识别。
我国CMM工作的开展相对滞后,全面正式开展CMM评估工作还需一定时间,但只是迟早的问题。业内有识之士呼吁我国应结合国情,及早开展CMM有关工作。 工程
CMM标准并不意味着高品质工程,并不意味着最高水平的组织,并不意味着生产效率最高,其标准本身与项目的品质没有直接关系,CMM只是一种形式测试,表示你是否有一定的程序来遵循,它是大型项目开发的必要条件,不是品质高的充分条件,过度拘泥于CMM形式,失去了灵活性,也可能失去市场,并且CMM并不能保证品质,因为CMM不检测程序的内容,只是检测程序的形式,是否有各种会议,步骤等,至于会议开了什么内容,没有任何关系。CMM水平5 是最高水平,取得CMM5的最多的国家是印度,但是印度的软件质量很差,这折射了这种形式测试的局限性。我国在引用CMM时,一定要吸取其精华,不要拘泥于形式,好的形式要发扬,坏的形式要废弃,保持产品的优质无瑕,和充分的竞争力才是关键。 补充
CMM与RUP的关系:RUP是过程框架,RUP能达到CMM2-3级的要求,RUP描述了软件开发中的过程,即软件开发中需要遵循的规则、模板、方法等;CMM不是过程,而是检验过程成熟度的标准。
体系结构
一个企业软件能力类似于一个人在一个特定领域的能力,是逐步获得和增长的。如果一个人在其领域的发展过程中能得到一个很好的指南,那么他或她就会不断达到一个个设定的目标,并变得成熟起来,否则可能会盲目发展,离自己的目标越来越远,甚至南辕北辙。一个企业的软件能力发展也同样需要一个良好的指南,SW-CMM正是这样一个指南,它以几十年产品质量概念和软件工业的经验及教训为基础,为企业软件能力不断走向成熟提供了有效的步骤和框架。
框架
SW-CMM为软件企业的过程能力提供了一个阶梯式的进化框架,阶梯共有五级。第一级实际上是一个起点,任何准备按CMM体系进化的企业都自然处于这个起点上,并通过这个起点向第二级迈进。除第一级外,每一级都设定了一组目标,如果达到了这组目标,则表明达到了这个成熟级别,可以向下一个级别迈进。CMM体系不主张跨越级别的进化,因为从第二级起,每一个低的级别实现均是高的级别实现的基础。
1.初始级初始级的软件过程是未加定义的随意过程,项目的执行是随意甚至是混乱的。也许,有些企业制定了一些软件工程规范,但若这些规范未能覆盖基本的关键过程要求,且执行没有政策、资源等方面的保证时,那么它仍然被视为初始级。
2.可重复级根据多年的经验和教训,人们总结出软件开发的首要问题不是技术问题而是管理问题。因此,第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程,一个可重复的过程则能逐渐进化和成熟。第二级的管
理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面。其中项目管理分为计划过程和跟踪与监控过程两个过程。通过实施这些过程,从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。
3.定义级在第二级仅定义了管理的基本过程,而没有定义执行的步骤标准,而且无论是管理还是工程开发都需要一套文档化的标准,并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程,剪裁出与项目适宜的过程,并执行这些过程。过程的剪裁不是随意的,在使用前需经过企业有关人员的批准。
4.管理级第四级的管理是量化的管理。所有过程需建立相应的度量方式,所有产品的质量(包括工作产品和提交给用户的产品)需有明确的度量指标。这些度量应是详尽的,且可用于理解和控制软件过程和产品。量化控制将使软件开发真正变成为一种工业生产活动。
5.优化级第五级的目标是达到一个持续改善的境界。所谓持续改善是指可根据过程执行的反馈信息来改善下一步的执行过程,即优化执行步骤。如果一个企业达到了这一级,那么表明该企业能够根据实际的项目性质、技术等因素,不断调整软件生产过程以求达到最佳。
结构
除第一级外,SW-CMM的每一级是按完全相同的结构构成的。每一级包含了实现这一级目标的若干关键过程域(KPA),每个KPA进一步包含若干关键实施活动(KP),无论哪个KPA,它们的实施活动都统一按五个公共属性进行组织,即每一个KPA都包含五类KP。
1. 目标每一个KPA都确定了一组目标。若这组目标在每一个项目都能实现,则说明企业满足了该KPA的要求。若满足了一个级别的所有KPA要求,则表明达到了这个级别所要求的能力。
2. 实施保证实施保证是企业为了建立和实施相应KPA所必须采取的活动,这些活动主要包括制定企业范围的政策和高层管理的责任。
3. 实施能力实施能力是企业实施KPA的前提条件。企业必须采取措施,在满足了这些条件后,才有可能执行KPA的执行活动。实施能力一般包括资源保证、人员培训等内容。
4. 执行活动执行过程描述了执行KPA所需求的必要角色和步骤。在五个公共属性中,执行活动是唯一与项目执行相关的属性,其余四个属性则涉及企业CMM能力基础设施的建立。执行活动一般包括计划、执行的任务、任务执行的跟踪等。
5. 度量分析度量分析描述了过程的度量和度量分析要求。典型的度量和度量分析的要求是确定执行活动的状态和执行活动的有效性。
6. 实施验证实施验证是验证执行活动是否与所建立的过程一致。实施验证涉及到管理方面的评审和审计以及质量保证活动。在实施CMM时,可以根据企业软件过程存在问题的不同程度确定实现KPA的次序,然后按所确定次序逐步建立、实施相应过程。在执行某一个KPA时,对其目标组也可采用逐步满足的方式。过程进化和逐步走向成熟是CMM体系的宗旨。
实施思考
应注意的是,并非实施了CMM软件项目的质量就能有所保障。CMM是一种资质认证,它可以证明一个软件企业对整个软件开发过程的控制能力。按照CMM的思想进行管理与通过CMM认证并不能划等号。CMM认证并不仅仅是在评估软件企业的生产能力,整个评估过程同时还在帮助企业完善已经按照CMM建立的科学工作流程,发现企业在软件质量、生产进度
CMM
以及成本控制等方面可能存在的问题,并且及时予以纠正。
实施CMM对软件企业的发展起着至关重要的作用,CMM过程本身就是对软件企业发展历程的一个完整而准确的描述,企业通过实施CMM,可以更好地规范软件生产和管理流程,使企业组织规范化。
CMM的成功与否,与一个组织内部有关人员的积极参与和创造性活动是密不可分的,而且CMM并未提供实现有关子过程域所需要的具体知识和技能。在国内要想取得过程改进成功,必须做好以下的几点:软件过程改进必须有高级主管的支持与委托,并积极地管理过程改进的进展;中层管理的积极支持;责任分明,过程改进小组的威望高;基层的支持与参与极端重要;利用定量的可观察数据,尽快使过程改进成果可见,从而激励参与者的兴趣;将实施CMM与实施PSP和TSP有机地结合起来;为企业的商业利益服务,并要求同时相符的企业文化变革。
过程改善工作具有一切过程所具有的固有特征,即需要循序渐进,不能一蹴而就;需要持续改善,不能停滞不前;需要联系实际,不能照本宣读;需要适应变革,不能凝固不变。将CMM/PSP/TSP引人软件企业首先要对单位主管和主要开发人员进行系统的培训。另外一个有效的途径是自顶向下的课程培训,即从高层主管依次普及到下面的工程师。培训包括最基本的软件工程和CMM培训知识;专业领域知识等方面的培训;软件过程方面的培训。
CMM模型划分为5个级别,共计18个关键过程域,52个目标,300多个关键实践。每一个CMM等级的评估周期(从准备到完成)约需12-30个月。此期间应抽调企业中有管理能力、组织能力和软件开发能力的骨干人员,成立专门的CMM实施领导小组或专门的机构。同时设立软件工程过程组、软件工程组、系统工程组、系统测试组、需求管理组、软件项目计划组、软件项目跟踪与监督、软件配置管理组、软件质量保证组、培训组。各个小组完成自己的任务同时协调其他小组的工作。然后制定和完善软件过程, 按照CMM规范评估这个过程。CMM正式评估由CMU/SEI授权的主任评估师领导一个评审小组进行,评估过程包括员工培训、问卷调查和统计、文档审查、数据分析、与企业的高层领导讨论和撰写评估报告等,评估结束时由主任评估师签字生效。此后最关键的就是根据评估结果改进软件过程,使CMM评估对于软件过程改进所应具有的作用得到最好的发挥。
范文二:能力成熟度模型
郭繁华-2009005483
能力成熟度模型
本文主要介绍了软件能力成熟度模型产生、发展的过程;概念、总体框架、基本内容;及软件能力成熟度模型在中国的软件企业开发生产软件过程中的重要作用。
一(SW-CMM的发展背景
Capability Maturity Model For Software(SW-CMM),软件能力成熟度模型是八十年代由美国卡内基梅隆大学(Carnegie Mellon University-CMU)的软件工程研究所(Software Engineering Institute–SEI)基于60多年历史的产品质量原理建立的,也可被称为能力成熟度成长的模型。
二(SW—CMM的模型结构
1.成熟度等级
一种方式。当企业着力于一组要求持续改善的量化的过程域时,并采用公共属性、从属目标和从属实践活动时成熟度等级是一个软件企业为其将在一组预定的规程或是一系列规程实施软件工程的,就可以使他们的软件过程得到改善。成熟度等级就是一种已定义的、关于过程改善的进阶。每一个成熟度等级都是企业过程的重要部分。达到每一个成熟度等级,就改进并增长了企业的过程生产能力。
达到要求:
--5 ó?????关注持续的过程改进
--4 ??á??üàí??
过程已测量和控制
--3 ??ò???
为企业刻画过程
--2 ?üàí??
为项目刻画过程
--1 ??ê???
过程不可预测和控制
图1.2 成熟度等级
成熟度等级共有5个等级,每一个都是持续过程改善的基础:
, 初始级(等级1)----初始级是不成熟的软件开发企业的软件过程所处的等级。企
业的开发过程是无序的,需求和进度失控,过程无计划、不确定,过程能力不可预
测,并且不能提供开发和维护软件的稳定的环境。在这种情况下,软件项目的成功
完全依赖于企业里杰出的软件开发团队的经验和努力。除非把下一个项目分派给有
同样经验和能力的团队,否则是不可能再次得到成功的。当企业能生产出可用的产
品时,他们往往要超出项目计划的进度和预算,而且不能保证产品质量的稳定性。
, 管理级(等级2)----达到这一等级,企业已经达到了该等级里的过程域所要求的
所有目标。换句话说,就是企业确保它的过程是计划的、文挡化的、可实施的、可
监测的,并且在项目级别上是可控制的。生产过程的需求、标准、目标、工作产品
以及服务都是被严格定义和文挡化的。管理部门应在定义化的级别上对工作产品的
状态,服务的分布有深入的了解。企业为软件生产过程所建立的目标,例如,预算,
进度和质量,都应被满足。管理级所制订的规划确保软件生产的实践活动即使在承
受压力期间,也会被完整执行。在类似于当前的工作项目中,实施这些实践活动,
会得到所期待的类似的结果。在相关的客户群中建立注释项,并在必要时修订和满
足。工作产品要满足客户的需求,标准和目的,客户也要对它有清晰的了解和明确
的控制。
, 定义级(等级3)----当达到成熟度等级3时,企业已经完成了等级2和3的过程域。有关软件工程与管理工程的一个特定的、面对整个企业的软件开发与维护的过程的文件将被制订出来。同时,这些过程是集成为一个协调的整体,并且使当前软件生产工作过程能够长期地在等级3上建立和改进,这就称为企业的标准软件过程集。这些标准过程集定义了在整个企业建立当前工作过程时所要应用到的基本过程。基本过程说明了在等级3所期待的基础过程元素,及其关系。企业将会从自己的标准软件过程库和适合当前情况的过程集中找出合适的过程,并在作相应的剪裁处理后应用。这些过程应该为以下几项:制订的标准、完成工作的规程和步骤,审核的方法,适合采纳的工具和实施的方式来描述。企业级的基础结构要在企业建立改善标准过程集的过程中支持它在目前和将来的应用。而企业的管理是在企业过程集的基础上建立的,这些过程集的目标是在成熟度等级3上系统地筹备的。
, 定量管理级(等级4)----在等级4,企业已达到等级2、3和4过程域的所有要求。在这一级,企业对于产品、服务的质量和过程性能的说明、管理和控制,是采取在过程的生命周期里建立定量化的质量目标的方式。质量目标是建立在客户、最终用户、企业和过程实施者的需求上的,所以管理的过程是直接定量化的过程。来自各项目的产品质量、服务质量和过程性能的测试数据均被详细地收集、统计和分析,并要归纳在企业范围的测试数据库里,以建立一个用于评价项目的过程、产品的定量化的依据。项目开发小组可以通过缩短各项指数的效能表现偏差来让项目的过程和产品、服务质量处于可接受的定量界限之内。适当情况下,企业应详细说明过程产生变化的原因,并迅速做出反映,采取必要的纠正措施来杜绝问题的再次发生。
, 优化级(等级5)----在优化级,企业成功地完成了等级2、3、4、和5的所有过程域目标。处于等级5的企业是将重点放在对软件生产过程能力的不断优化和改进。并以两种形式进行,一种是逐渐地提升现存过程,另一种是对技术和方法的创新。在优化级,这两方面不断进行的改进活动,是作为企业制订的常规工作,有计划地在管理之下实施的,关于这方面的生产过程和企业的标准过程集都是改进活动的目标,以用来管理过程改进所遵循的准则。企业制订了生产过程,对其进行评估和实施,这种生产过程的定量化地改进就提高了企业原有的生产能力水平,给过程改善变化提出了共性原因。在优化过程中,要分析相关过程的有效资料,做出对新技术的成本和效益分析,并提出建议。优化过程是一种灵活的,创新的行为,是在一个同样灵活处理企业商务价值和目标的,在有能力的开发团体的参与下进行实施的。通过寻求促进自身和持续学习的有效方式,企业对变化和机会的快速反映得到加强。优化过程改进是由于内部每个人的作用都得到发挥,并导致持续改善的循环进行。对选择性的扩展、创新技术过程的改进是在企业内部系统展开的。从量化过程改进目标的角度看,开展企业过程改进的影响应该是可测定和可评估的。
随成熟度等级过程域的从属和特定目标的实现,就提高过程的成熟度。从整体来说软件能力成熟度级别从低到高的变化代表了企业的生产活动由高风险低效率到高质量、高生产率的进展。
2.过程域
过程域是为了实现若干给定的目标而要共同地加以实施的一组相关实践活动。过程域是建立企业的软件生产过程能力所需的主要部件,按5个成熟度等级分组。每个过程域的独特活动用其特定实践活动描述,这些特定实践活动由特定目标来概括。它不是一个过程说明;只是提出企业的一个有效过程的细节,包括做什么(特定实践)、完成了什么(特定目标)。一些过程域在所有的CMMI模型中是可以公用的。
三(作用
软件开发的风险之所以大,是由于软件过程能力低,其中最关键的问题在于软件开发组织不能很好地管理其软件过程,从而使一些好的开发方法和技术起不到预期的作用。而且项目的成功也是通过工作组的杰出努力,所以仅仅建立在可得到特定人员上的成功不能为全组织的生产和质量的长期提高打下基础,必须在建立有效的软件如管理工程实践和管理实践的基础设施方面,坚持不懈地努力,才能不断改进,才能持续地成功。
软件质量是模糊的、捉摸不定的概念。我们常常听说:某某软件好用, 某某软件不好用;某某某软件功能全、结构合理, 某某某软件功能单一、操作困难……这些模模糊糊的语言不能算作是软件质量评价,更不能算作是软件质量科学的定量的评价。软件质量,乃至于任何产品质量,都是一个很复杂的事物性质和行为。产品质量,包括软件质量,是人们实践产物的属性和行为,是可以认识,可以科学地描述的。可以通过一些方法和人类活动,来改进质量。
实施CMM是改进软件质量的有效方法:控制软件生产过程、提高软件生产者组织性和软件生产者个人能力的有效合理的方法软件工程和很多研究领域及实际问题有关,主要相关领域和因素有:需求工程(REQUIREMENTS ENGINEERING)。理论上,需求工程是应用已被证明的原理、技术和工具,帮助系统分析人员理解问题或描述产品的外在行为。软件复用 (SOFTWARE REUSE),定义为利用工程知识或方法,由一已存在的系统,来建造一新系统。这种技术,可改进软件产品质量和生产率。还有软件检查、软件计量、软件可靠性、软件可维修性、软件工具评估和选择等。
参考文献:联想软件事业部 SW-CMM模型应用介绍 2000
海龟( 硅谷 美国 ):软件能力成熟度模型(SW—CMM)、用途与发展史 www.Chinabyte.com 软件仓库系列专题文章 1999-09-15
何新贵 王纬 王方德 崔宗学 余林生 范如鹰 周伯生 蔡愉祖 软件能力成熟度模型 清华大学出版社 2000-11
范文三:CMM-能力成熟度模型
CMM -能力成熟度模型
能力成熟度模型(Capability Maturity Model for Software,英文缩写为SW-CMM ,简称CMM ) 什么是能力成熟度模型
CMM 是指“能力成熟度模型”,是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM 的核心是把软件开发视为一个过程,并根据这一原则对软件开发和维护进行过程监控和研究,以使其更加科学化、标准化、使企业能够更好地实现商业目标。
CMM 是一种用于评价软件承包能力并帮助其改善软件质量的方法,侧重于软件开发过程的管理及工程能力的提高与评估。CMM 分为五个等级:一级为初始级,二级为可重复级,三级为已定义级,四级为已管理级,五级为优化级。
其所依据的想法是:只要集中精力持续努力去建立有效的软件工程过程的基础结构,不断进行管理的实践和过程的改进,就可以克服软件生产中的困难。CMM 它是目前国际上最流行、最实用的一种软件生产过程标准,已经得到了众多国家以及国际软件产业界的认可,成为当今企业从事规模软件生产不可缺少的一项内容。
CMM 为软件企业的过程能力提供了一个阶梯式的改进框架,它基于过去所有软件工程过程改进的成果,吸取了以往软件工程的经验教训,提供了一个基于过程改进的框架;它指明了一个软件组织在软件开发方面需要管理哪些主要工作、这些工作之间的关系、以及以怎样的先后次序,一步一步的做好这些工作而使软件组织走向成熟。
能力成熟度模型的历史和发展
信息时代,软件质量的重要性越来越为人们所认识。软件是产品、是装备、是工具,其质量使得顾客满意,是产品市场开拓、事业得以发展的关键。而软件工程领域在1992年至1997年取得了前所未有的进展, 其成果超过软件工程领域过去15年来的成就总和。
软件管理工程引起广泛注意源于20世纪70年代中期。当时美国国防部曾立题专门研究软件项目做不好的原因,发现70%的项目是因为管理不善而引起,而并不是因为技术实力不够,进而得出一个结论,即管理是影响软件研发项目全局的因素,而技术只影响局部。到了20世纪90年代中期,软件管理工程不善的问题仍然存在,大约只有10%的项目能够在预定的费用和进度下交付。软件项目失败的主要原因有:需求定义不明确;缺乏一个好的软件开发过程;没有一个统一领导的产品研发小组;子合同管理不严格;没有经常注意改善软件过程;对软件构架很不重视;软件界面定义不善且缺乏合适的控制;软件升级暴露了硬件的缺点;关心创新而不关心费用和风险;军用标准太少且不够完善等等。在关系到软件项目成功与否的众多因素中,软件度量、工作量估计、项目规划、进展控制、需求变化和风险管理等都是与工程管理直接相关的因素。由此可见,软件管理工程的意义至关重要。
1987年,美国卡内基. 梅隆大学软件研究所(SEI )受美国国防部的委托,率先在软件行业从软件过程能力的角度提出了软件过程成熟度模型(CMM ),随后在全世界推广实施的一种软件评估标准,用于评价软件承包能力并帮助其改善软件质量的方法。它主要用于软件开发过程和软件开发能力的评价和改进。它侧重于软件开发过程的管理及工程能力的提高与评估。CM 自1987年开始实施认证,现已成为软件业最权威的评估认证体系。CMM 包括5个等级,共计18个过程域,52个目标,300多个关键实践
CMM 的基本思想
CMM 的基本思想是,因为问题是由我们管理软件过程的方法引起的,所以新软件技术的运用不会自动提高生产率和利润率。CMM 有助于组织建立一个有规律的、成熟的软件过程。改进的过程将会生产出质量更好
的软件,使更多的软件项目免受时间和费用的超支之苦。
软件过程包括各种活动、技术和用来生产软件的工具。因此,它实际上包括了软件生产的技术方面和管理方面。CMM 策略力图改进软件过程的管理,而在技术上的改进是其必然的结果。
必须牢记,软件过程的改善不可能在一夜之间完成,CMM 是以增量方式逐步引入变化的。CMM 明确地定义了5个不同的“成熟度”等级,一个组织可按一系列小的改良性步骤向更高的成熟度等级前进。
成熟度等级1:初始级(Initial)。处于这个最低级的组织,基本上没有健全的软件工程管理制度。每件事情都以特殊的方法来做。如果一个特定的工程碰巧由一个有能力的管理员和一个优秀的软件开发组来做,则这个工程可能是成功的。然而通常的情况是,由于缺乏健全的总体管理和详细计划,时间和费用经常超支。结果,大多数的行动只是应付危机,而非事先计划好的任务。处于成熟度等级1的组织,由于软件过程完全取决于当前的人员配备,所以具有不可预测性,人员变化了,过程也跟着变化。结果,要精确地预测产品的开发时间和费用之类重要的项目,是不可能的。
成熟度等级2:可重复级(Repeatable)。在这一级,有些基本的软件项目的管理行为、设计和管理技术是基于相似产品中的经验,故称为“可重复”。在这一级采取了一定措施,这些措施是实现一个完备过程所必不可缺少的第一步。典型的措施包括仔细地跟踪费用和进度。不像在第一级那样,在危机状态下方行动,管理人员在问题出现时便可发现,并立即采取修正行动,以防它们变成危机。关键的一点是,如没有这些措施,要在问题变得无法收拾前发现它们是不可能的。在一个项目中采取的措施也可用来为未来的项目拟定实现的期限和费用计划。
成熟度等级3:已定义级(Defined)。在第3级,已为软件生产的过程编制了完整的文档。软件过程的管理方面和技术方面都明确地做了定义,并按需要不断地改进过程,而且采用评审的办法来保证软件的质量。在这一级,可引用CASE 环境来进一步提高质量和产生率。而在第—级过程中,“高技术”只会使这一危机驱动的过程更混乱。
成熟度等级4:已管理级(Managed)。一个处于第4级的公司对每个项目都设定质量和生产目标。这两个量将被不断地测量,当偏离目标太多时,就采取行动来修正。利用统计质量控制,管理部门能区分出随机偏离和有深刻含义的质量或生产目标的偏离(统计质量控制措施的一个简单例子是每千行代码的错误率。相应的目标就是随时间推移减少这个量) 。
成熟度等级5:优化级(Optimizing)。—个第5级组织的目标是连续地改进软件过程。这样的组织使用统计质量和过程控制技术作为指导。从各个方面中获得的知识将被运用在以后的项目中,从而使软件过程融入了正反馈循环,使生产率和质量得到稳步的改进。
整个企业将会把重点放在对过程进行不断的优化,采取主动的措施去找出过程的弱点与长处,以达到预防缺陷的目标。同时,分析各有关过程的有效性资料,作出对新技术的成本与效益的分析,并提出对过程进行修改的建议。达到该级的公司可自发的不断改进,防止同类缺陷二次出现。
在表中可以看出,CMM 为软件的过程能力提供了一个阶梯式的改进框架,它基于以往软件工程的经验教训,提供了一个基于过程改进的框架图,它指出一个软件组织在软件开发方面需要那些主要工作,这些工作之间的关系,以及开展工作的先后顺序,一步一步的做好这些工作而使软件组织走向成熟。CMM 的思想来源于已有多年历史的项目管理和质量管理,自产生以来几经修订,成为软件业具有广泛影响的模型, 并对以后项目管理成熟度模型的建立产生了重要的影响。尽管已有个人或团体提出了各种各样的成熟度模型,但还没有一个象CMM 那样在业界确立了权威标准的地位。但PMI 于2003年发布的OPM3以其立体的模型及涵盖范围的广泛有望成为项目管理界的标准。
实施CMM 的必要性
软件开发的风险之所以大,是由于软件过程能力低,其中最关键的问题在于软件开发组织不能很好地管理其软件过程,从而使一些好的开发方法和技术起不到预期的作用。而且项目的成功也是通过工作组的杰出
努力,所以仅仅建立在可得到特定人员上的成功不能为全组织的生产和质量的长期提高打下基础,必须在建立有效的软件如管理工程实践和管理实践的基础设施方面,坚持不懈地努力,才能不断改进,才能持续地成功。
软件质量是一模糊的、捉摸不定的概念。我们常常听说:某某软件好用, 某某软件不好用;某某某软件功能全、结构合理, 某某某软件功能单一、操作困难??这些模模糊糊的语言不能算作是软件质量评价,更不能算作是软件质量科学的定量的评价。软件质量,乃至于任何产品质量,都是一个很复杂的事物性质和行为。产品质量,包括软件质量,是人们实践产物的属性和行为,是可以认识,可以科学地描述的。可以通过一些方法和人类活动,来改进质量。
实施CMM 是改进软件质量的有效方法:控制软件生产过程、提高软件生产者组织性和软件生产者个人能力的有效合理的方法软件工程和很多研究领域及实际问题有关,主要相关领域和因素有:需求工程(REQUIREMENTS ENGINEERING)。理论上,需求工程是应用已被证明的原理、技术和工具,帮助系统分析人员理解问题或描述产品的外在行为。软件复用(SOFTWARE REUSE),定义为利用工程知识或方法,由一已存在的系统,来建造一新系统。这种技术,可改进软件产品质量和生产率。还有软件检查、软件计量、软件可靠性、软件可维修性、软件工具评估和选择等。
CMM基本概念
CMM 由低至高共分为5个级别:初始级、可重复级、定义级、管理级和优化级
CMMI (Capability Maturity Model Integration,能力成熟度模型集成)
将各种能力成熟度模型,即:Software CMM、Systems Eng-CMM、People CMM和Acquisition CMM, 整合到同一架构中去,由此建立起包括软件工程、系统工程和软件采购等在内的诸模型的集成, 以解决除软件开发以外的软件系统工程和软件采购工作中的迫切需求。
CMMI 框架包括软件能力成熟度模型CMM 2.0草案,系统工程能力成熟度模型,软件采购能力成熟度模型,继承产品和过程开发等。
CMMI 的:“关键过程域”25个,“目标”105个, “关键实践”485条。
CMMI 的评估方式:
自我评估:用于本企业领导层评价公司自身的软件能力。
主任评估:使本企业领导层评价公司自身的软件能力,向外宣布自己企业的软件能力
CMMI 的评估类型:
软件组织的关于具体的软件过程能力的评估。
软件组织整体软件能力的评估(软件能力成熟度等级评估)。
CMMI 的基本思想
1、解决软件项目过程改进难度增大问题
2、实现软件工程的并行与多学科组合
3、实现过程改进的最佳效益
背景介绍: CMM是“软件能力成熟度模型”的英文简写,该模型由美国卡内基-梅隆大学的软件工程研究所(简称SEI )受美国国防部委托,于1991年研究制定,初始的主要目的是为了评价美国国防部的软件合同承包组织的能力,后因为在软件企业应用CMM 模型实施过程改进取得较大的成功,所以在全世界范围内被广泛使用,SEI 同时建立了主任评估师评估制度,CMM 的评估方法为CBA -IPI 。
CMMI 是SEI 于2000年发布的CMM 的新版本。CMMI 不但包括了软件开发过程改进,还包含系统集成、软硬件采购等方面的过程改进内容。CMMI 纠正了CMM 存在的一些缺点,使其更加适用企业的过程改进实施。CMMI 适用SCAMPI 评估方法。需要注意的是,SEI 没有废除CMM 模型,只是停止了CMM 评估方法:CBA -IPI 。现在如要进行CMM 评估,需使用SCAMPI 方法。但CMMI 模型最终代替CMM 模型的趋势不可避免。
标准特点: CMM/CMMI/SPCA的思想来源于已有多年历史的产品质量管理和全面质量管理。Watts Humphrey 和Ron Radice 在IBM 公司将全面质量管理的思想应用于软件工程过程,收到了很大的成效。SEI 的软件能力成熟度框架就是在以Humphrey 为主的软件专家实践经验的基础上发展而来的。软件能力成熟度模型中融合了全面质量管理的思想,以不断进化的层次定量控制中项目管理和项目工程的基本原则。CMM/CMMI/SPCA所依据的想法是只要不断地对企业的工程过程的基础结构和实践进行管理和改进,就可以克服软硬件生产中的困难,增强开发制造能力,从而能按时地、不超预算地制造出高质量的软件产品。
CMM简介
CMM(Capability Maturity Model) 是能力成熟度模型的缩写,CMM 是国际公认的对软件公司进行成熟度等级认证的重要标准。CMM 的工作最早开始于86年11月, 当时为满足美国政府评估软件供应商能力并帮助其改善软件质量的要求, 由美国国防部资助的卡内基—梅隆大学的软件工作研究所(SEI)牵头, 在Mitre 公司协助下, 于87年9月发布了一份能力成熟度框架(Capability Maturity Framework)以及一套成熟度问卷(Maturity Questionnaire) 。四年后,SEI 在总结自87年以来对成熟度框架和初版成熟度问卷的经验基础上,推出了CMM1.0版。CMM1 0版在成熟度框架的基础上建立了一个可用的模型,该模型可以更加有效地帮助软件公司建立和实施过程改进计划。两年后,SEI 于93年推出了CMM1.1版。近几年,SEI 又推出了CMM2.0版,同时进入了ISO 体系,称为ISO/IEC15504(软件过程评估) 。
CMM 共分五级。在每一级中,定义了达到该级过程管理水平所应解决的关键问题和关键过程。每一较低级别是达到较高级别的基础。其中五级是最高级,即优化级,达到该级的软件公司过程可自发地不断改进,防止同类问题二次出现;四级称为已管理级,达到该级的软件公司已实现过程的定量化;三级为已定义级,即过程实现标准化;二级为可重复级,达到该级的软件公司过程已制度化,有纪律,可重复;一级为初始级,过程无序,进度、预算、功能和质量等方面不可预测。
CMM 致力于软件开发过程的管理和工程能力的提高与评估。该模型在美国和北美地区已得到广泛应用,同时越来越多的欧洲和亚洲等国家的软件公司正积极采纳CMM ,CMM 实际上已成为软件开发过程改进与评估事实上的工业标准。如今,全球通过CMM 五级评估的软件公司大约有十几家,三级以上的大约有100余家,通过二级评估的有300家左右。软件大国印度在这方面工作开展的比较广泛,受益匪浅。目前,我国只有清华同方和IBM 的合资公司——鼎新信息开发有限公司于99年7月通过CMM 二级评估,该公司表示将争取早日通过CMM 三级评估。
CMM 与ISO9000的主要区别:
1.CMM 是专门针对软件产品开发和服务的,而ISO9000涉及的范围则相当宽。
2.CMM 强调软件开发过程的成熟度,即过程的不断改进和提高。而ISO9000则强调可接收的质量体系的最低标准。
引进CMM 的主要意义
一. 对软件公司
1. 提高软件公司软件开发的管理能力,因为CMM 可提供软件公司自我评估的方法和自我提高的手段。
2. 提高软件生产率。
3. 提高软件质量。
4. 提高软件公司的国内和国际竞争力。
二. 对软件项目发包单位和软件用户
提供了对软件开发商开发管理水平的评估手段,有助于软件开发项目的风险识别。
我国CMM 工作的开展相对滞后,全面正式开展CMM 评估工作还需一定时间,但只是迟早的问题。业内有识之士呼吁我国应结合国情,及早开展CMM 有关工作。我公司作为西安地区软件业龙头企业,应学习、消化和借鉴CMM 有关管理思想和方法等先进知识,结合公司ISO9000质量管理等具体工作,不断改进和完善我公司的管理体系,推动我公司各项工作全面发展,并为我公司早日正式开展CMM 评估工作打下良好的基础。反
映了软件过程
补充:
CMM 在空气流量中还可以表示每分钟送出或吸入的空气总体积,如果按立方英尺来计算,单位就是CFM ;如果按立方米来算,就是CMM 。相当于m3/min。
CMM 与RUP 的关系:
RUP 是过程框架,RUP 能达到CMM2-3级的要求,RUP 描述了软件开发中的过程, 即软件开发中需要遵循的规则, 模板, 方法等;CMM 不是过程,而是检验过程成熟度的标准.
风量的常用单位为:CMM(立方米每分) CMH(立方米每时) CFM(立方英尺每分) LM(升每分钟) 换算:1CMM=60CMH=35.245CFM=1000LM
关键过程域:
CMM2:可重复阶段
需求管理:requrement management
软件项目计划:software project planning
软件项目跟踪和监督:software project tracking oversight
软件子合同管理:software subcontract management
软件质量保证:software quanlity assurance
软件配置管理:software configuratione management
CMM3:已定义阶段
组织过程焦点:organization process focus
组织过程定义:organization process definition
培训大纲:training program
集成软件管理:intergrated software management
软件产品工程:software product engineering
组间协调:intergroup coordination
同行评审:peer review
CMM4:已管理阶段
定量管理过程:quantitative process management
软件质量管理:software quality management
CMM5:优化阶段
缺陷预防:defect prevention
技术改革管理:technology change management
过程更改管理:process change management
范文四:能力成熟度模型集成
CMMI 能力成熟度模型集成
什么是 CMMI
CMMI 是 CMM 模型的最新版本。早期的 CMMI(CMMI-SE/SW/IPPD)1.02版本是应用于软件业项目的管理方 法,SEI 在部分国家和地区开始推广和试用。随着应用的推广与模型本身的发展,演绎成为一种被广泛应用 的综合性模型。
自从 1994年 SEI 正式发布软件 CMM 以来,相继又开发出了系统工程、软件采购、人力资源管理以及集成 产品和过程开发方面的多个能力成熟度模型。虽然这些模型在许多组织都得到了良好的应用,但对于一些大 型软件企业来说,可能会出现需要同时采用多种模型来改进自己多方面过程能力的情况。这时他们就会发现 存在一些问题,其中主要问题体现在:
1、不能集中其不同过程改进的能力以取得更大成绩;
2、要进行一些重复的培训、评估和改进活动,因而增加了许多成本;
3、遇到不同模型中有一些对相同事物说法不一致,或活动不协调,甚至相抵触。
于是,希望整合不同 CMM 模型的需求产生了。1997年,美国联邦航空管理局(FAA)开发了 FAA-iCMMSM (联邦航空管理局的集成 CMM) , 该模型集成了适用于系统工程的 SE-CMM、 软件获取的 SA-CMM 和软件的 SW-CMM 三个模型中的所有原则、概念和实践。该模型被认为是第一个集成化的模型。
CMMI 与 CMM 最大的不同点在于:CMMISM-SE/SW/IPPD/SS1.1版本有四个集成成分,即:系统工程(SE)和软件工程(SW)是基本的科目,对于有些组织还可以应用集成产品和过程开发方面(IPPD)的内容,如果涉及 到供应商外包管理可以相应的应用 SS(SupplierSourcing)部分。
CMMI 有两种表示方法,一种是大家很熟悉的,和软件 CMM 一样的阶段式表现方法,另一种是连续式的 表现方法。这两种表现方法的区别是:阶段式表现方法仍然把 CMMI 中的若干个过程区域分成了 5个成熟度 级别,帮助实施 CMMI 的组织建议一条比较容易实现的过程改进发展道路。而连续式表现方法则通过将 CMMI 中过程区域分为四大类:过程管理、项目管理、工程以及支持。对于每个大类中的过程区域,又进一步分为 基本的和高级的。这样,在按照连续式表示方法实施 CMMI 的时候,一个组织可以把项目管理或者其他某类的 实践一直做到最好,而其他方面的过程区域可以完全不必考虑。
CMMI 各个进程的关键元素
CMMI 自出道以来,它所达到的目标就没有变过,第一个是质量,第二个是时间表,第三就是要用最低的 成本。不过特别强调的是,CMMI 不是传统的、仅局限于软件开发的生命周期,它应该被运用于更广泛的一个 范畴——工程设计的生命周期。 TSP 的建立, 也是为了支持 CMMI 的这样一个系统。 那么 CMMI 究竟是什么呢? 它并不是一个过程,也不是告诉你怎么去做一件事情。如果用一句话来概括什么是 CMMI,它就是各个进程的 一个关键的元素,在很多领域里面一个集成的点。它是这样的一个基本架构,能够用来度量你的有效性和实 用性;能够找出这样的一些机会,继续改进的机会,包括在商业目标、策略还有降低项目的风险等方面。
CMMI 的组织结构
CMMI 的组织结构一般在最高领导之下设立 EPG(Engineering Process Group, 工程过程组) 、QA(Quality Assurance, 质量保证组)、EG(EngineeringGroup, 工程组),这三个组的构成就好像是立法、监督和执 法的制衡体系,体现了西方的法治观念。EPG 源于 SEPG(SoftwareEngineering Process Group, 软件工程
过程组),本是组织中专职推进 CMM 的职能单位,随着 CMM 发展到 CMMI,内容更加广泛,EPG 的职能就是组 织的过程改进。
CMMI 的起源
随着人们对 CMM 研究的不断深入,其他学科也结合本系统的特点,陆续推出了自己的 CMM 模型。例如, 人力资源能力成熟度模型、系统工程能力成熟度模型等等:
(1)SW-CMM (SoftwareCMM) 软件 CMM
(2)SE-CMM (SystemEngineering CMM) 系统工程 CMM
(3)SA-CMM (SoftwareAcquisition CMM) 软件采购 CMM
(4)IPT-CMM (IntegratedProduct Team CMM) 集成产品群组 CMM
(5)P-CMM (PeopleCMM) 人力资源能力成熟度模型
为了以示区别,国内外很多资料把 CMM 叫做 SW-CMM。按照 SEI 原来的计划,CMM 的改进版本 2.0应该在 1997年 11月完成,然后在取得版本 2.0得实践反馈意见之后,在 1999年完成准 CMM2.0版本。但是,美国 国防部办公室要求 SEI 推迟发布 CMM2.0版本,而要先完成一个更为紧迫的项目 CMMI。
CMMI(CapabilityMaturity Model Integration)即能力成熟度集成模型,这也是美国国防部的一个设 想,他们想把现在所有的以及将被发展出来的各种能力成熟度模型,集成到一个框架中去。这个框架有两个 功能,第一,软件采购方法的改革;第二,建立一种从集成产品与过程发展的角度出发、包含健全的系统开 发原则的过程改进。就软件而言, CMMI 是 SW-CMM 的修订本。它兼收了 SW-CMM 2.0版 C 稿草案和 SPA 中更 合理、更科学和更周密的优点。SEI 在发表 CMMI-SE/SW1.0版时,宣布大约用两年的时间完成从 CMM 到 CMMI 的过渡。
CMMI 项目更为工业界和政府部门提供了一个集成的产品集,其主要目的是消除不同模型之间的不一致和 重复,降低基于模型改善的成本。CMMI 将以更加系统和一致的框架来指导组织改善软件过程,提高产品和服 务的开发、获取和维护能力。
范文五:CMMI(能力成熟度模型集成)
CMMI
CMMI
早期的 CMMI (CMMI-SE/SW/IPPD) 1.02版本是应用于软件业项目的管理方法, SEI 在部分国家和地区开始推广和试用。 随着应用的推广与模型本身的发展, 演绎成 为一种被广泛应用的综合性模型。
目录
简介
评估
1. 预备工作
2. 评估方法
3. CMM 是项目管理
等级
●初始级
●已管理级
●已定义级
●量化管理级
●优化管理级
评估方式
CMMI 的基本思想
研发背景
源模型
原则
目标
方法
内容
与 CMM 差别
标准名词术语
实施
人员素质
实施流程
简介
评估
1. 预备工作
2. 评估方法
3. CMM 是项目管理 等级
●初始级 ●已管理级 ●已定义级 ●量化管理级 ●优化管理级
评估方式
CMMI的基本思想 研发背景
源模型
原则
?目标
?方法
?内容
?与 CMM 差别 ?标准名词术语 ?实施
?人员素质
?实施流程
简介
CMMI 的全称为:Capability Maturity Model Integration,即能力 成熟度模型集成。
CMMI 家族包括 CMMI for Development, CMMI for Service和 CMMI for Acquisition 三个套装产品。
自从 1994 年 SEI 正式发布软件 CMM 以来, 相继又开发出了系统工程、 软件采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度 模型。虽然这些模型在许多组织都得到了良好的应用,但对于一些大型软 件企业来说,可能会出现需要同时采用多种模型来改进自己多方面过程能 力的情况。这时他们就会发现存在一些问题,其中主要问题体现在: n 不能集中其不同过程改进的能力以取得更大成绩;
n 要进行一些重复的培训、评估和改进活动,因而增加了许多成本; n 遇到不同模型中有一些对相同事物说法不一致,或活动不协调,甚 至相抵触。
于是,希望整合不同 CMM 模型的需求产生了。1997 年,美国联邦航空 管理局(FAA)开发了 FAA-iCMMSM(联邦航空管理局的集成 CMM),该模型 集成了适用于系统工程的 SE-CMM、 软件获取的 SA-CMM 和软件的 SW-CMM 三 个模型中的所有原则、概念和实践。该模型被认为是第一个集成化的模型。
评估
预备工作
评估实践证明:在进行 CMMI 评估之前,制定一个正确的评估计划并将 其文档化,确保有一个富有经验的、受过培训且具有适当资格的小组能被 用来评估,为执行评估过程做准备,是十分必要的。
我们所说的文档化 CMMI 评估计划的结果,包括:要求,协定,估价, 风险,剪裁方法,以及与评估相关的实际考虑(例如:日程安排,后勤, 组织的背景信息)。此外,还应当获取并记录发起方对于 CMMI 评估计划的 正式批准。在制定评估计划之前,应对 CMMI 评估输入中反映出来的协议文 档化,该协议将有助于 CMMI 评估目标和关键评估计划参数的共同理解。在 对驱动计划过程的关键参数达成共同理解的基础上,CMMI 评估发起方和 SCAMPI 主任评估师应就评估计划达成一致;发起者和评估小组领导应就已 计划的评估中技术和非技术细节达成一致。这个计划在执行其他的计划和 准备阶段活动中需要进一步细化。
而通过 CMMI 评估小组的准备工作,将产生一支富有经验的、受过培训 的且定位准确的小组准备执行 CMMI 评估任务。该小组的成员都应当获得了 完成他们各自的任务所必备的知识,或者他们之前所拥有的知识被证实足
以完成相关任务。评估小组领导者已经给每一个人提供了为完成他们各自 的任务所需的对技能进行实践的机会,或者证实这些技能在过去已经得到 了示范。小组成员相互了解,同时开始计划他们如何协调一致的工作。还 应该做到:准备好的小组是为评估目标而服务的,小组的成员已提供培训 且培训结果被记录,在必要的时候,对他们所做的因知识或技能不足的补 救工作已经完成。我们认为,无论 CMMI 评估小组领导者是从头培训一支全 新的评估小组,还是通过从富有经验的小组成员中选择来组建一个小组, 确保他们与 CMMI 评估小组领导者能组成一个成功的集体是其责任。此外, 在对 CMMI 评估进行的预备工作的过程中,我们还应当对模型剪裁的原则有 所了解:
1.在某些应用中,计划模板和例行的程序能够根据评估的需要进行调 整,这和当地的过程所有权一样,有助于交流;
2.一个结构化的计划工艺组有利于只有有限的评估经验的组织,这样 一个工艺就像缓和策略样,对于发现风险是一个很有价值的机会;
3.案例研究材料提供了各种各样的选择来扩充小组培训内容以增强那 些更需要培训的重点;
4.富有经验的评估小组领导者在没有案例分析的情况下,同样可以管 理和模拟评估行为;
5.在小组所有已获得培训成员的集合中,对小组的建立工作进行管理 以确保其团队凝聚力是十分重要的,因此,很多的小组建立练习是可以利 用的,小组的规模、技能、组成部分都是本方法的裁剪内容;
6.所采用工具可以包括评估计划模板,样例,和计划模板中嵌入式的 程序上的帮助,此外,为了估计评估约束的影响,估算工作表和方法也是 很有用处的。
总之,CMMI 评估是一个十分复杂的过程,更由于其具有的不确定性, 在评估的实践中,一定要做到有备无患。真理来自于实践,我们相信,随 着越来越多的软件组织着手 CMMI 评估,越来越多的成功经验将为我们所利 用和借鉴。
评估方法
自 1991年起,CMM 出现了很多模型,覆盖了各种各样的专业领域。其 中著名的模型有系统工程·软件工程·软件采购·集成产品和流程开发等。 然而当企业想要在组织内不同专业领域的流程改进,这些针对不同专业领 域的模型在架构·内容和方法上的不同限制了组织成功实施改进的能力。 此外,将这样模型在组织内部集成也提高了培训·认证和改进的费用。一 套包括多个专业领域的模型加上整合的培训和认证支持将解决这些问题。 CMMI(Capability maturity model integration)是为了合并三个模型 到一个框架中
Capability Maturity Model for Software (SW-CMM) v2.0 draft C,
Electronic Industries Alliance Interim Standard (EIA/IS) 731 Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98
正如其他 CMM 模型,CMMI 提供了流程改进的指导,而不是流程或流程 的描述。组织使用的实际流程取决于很多因素,包括应用领域·组织框架 和规模。CMMI 将许多经过验证的方法加入架构中,来帮组组织评价成熟 度·某个软件流程的能力度,并且建立改进的优先顺序和实施改进。 从 CMMI 框架可以产生不同的 CMMI 模型,因此必须首先确定那种模型 最适合企业流程改进的需要。
阶段式描述 or 连续式描述
系统工程 or 软件工程 or 两者皆有
使用连续式描述可以根据企业需要选择流程改进顺序,降低企业风险, 这给通过 ISO 做流程改进提供了一个方便的比较。 使用能力度(Capability)来衡量。
阶段式描述提供了已经过验证的流程改进顺序,方便从 CMM 移植过来。 使用成熟度(Maturity)来衡量流程改进。
系统工程包括整个系统的开发,可能包括软件也可能不包括。
软件工程用于软件系统的开发, 主要集中在使用系统的·科学的·量化 的方法来开发·运行·维护软件。
CMM 是项目管理
由美国卡内基梅隆大学的软件工程研究所(SEI)创立的
CMM(Capability Maturity Model 软件能力成熟度模型)认证评估,在过去 的十几年中, 对全球的软件产业产生了非常深远的影响。 CMM 共有五个等级, 分别标志着软件企业能力成熟度的五个层次。从低到高,软件开发生产计 划精度逐级升高,单位工程生产周期逐级缩短,单位工程成本逐级降低。 据 SEI 统计,通过评估的软件公司对项目的估计与控制能力约提升 40%到 50%;生产率提高 10%到 20%,软件产品出错率下降超过 1/3。
对一个软件企业来说,达到 CMM2就基本上进入了规模开发,基本具备 了一个现代化软件企业的基本架构和方法,具备了承接外包项目的能力。 CMM3评估则需要对大软件集成的把握,包括整体架构的整合。一般来说, 通过 CMM 认证的级别越高,其越容易获得用户的信任,在国内、国际市场 上的竞争力也就越强。因此,是否能够通过 CMM 认证也成为国际上衡量软 件企业工程开发能力的一个重要标志。
CMM 是目前世界公认的软件产品进入国际市场的通行证, 它不仅仅是对 产品质量的认证,更是一种软件过程改善的途径。参与 CMM 评估的博科负 责人表示,通过 CMM 的评估认证不是目标,它只是推动软件企业在产品的 研发、生产、服务和管理上不断成熟和进步的手段,是一种持续提升和完
善企业自身能力的过程。如果一家公司最终通过 CMMI 的评估认证,标志着 该公司在质量管理的能力已经上升到一个新的高度。
等级
1. 初始级
软件过程是无序的,有时甚至是混乱的,对过程几乎没有定义,成功 取决于个人努力。管理是反应式的。
2. 已管理级
建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必 要的过程纪律,能重复早先类似应用项目取得的成功经验。
3. 已定义级
已将软件管理和工程两方面的过程文档化、标准化,并综合成该组织 的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和 维护软件,软件产品的生产在整个软件过程是可见的。
4. 量化管理级
分析对软件过程和产品质量的详细度量数据,对软件过程和产品都有 定量的理解与控制。管理有一个作出结论的客观依据,管理能够在定量的 范围内预测性能。
5. 优化管理级
过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。 每个等级都被分解为过程域,特殊目标和特殊实践,通用目标、通用 实践和共同特性:
每个等级都有几个过程区域组成,这几个过程域共同形成一种软件过 程能力。每个过程域,都有一些特殊目标和通用目标,通过相应的特殊实 践和通用实践来实现这些目标。当一个过程域的所有特殊实践和通用实践 都按要求得到实施,就能实现该过程域的目标。
能力度等级:属于连续式表述,共有六个能力度等级(0~5),每个能力 度等级对应到一个一般目标,以及一组一般执行方法和特定方法。 0 不完整级
1 执行级
2 管理级
3 定义级
4 量化管理级
5 最佳化级
评估方式
自我评估:用于本企业领导层评价公司自身的软件能力。
主任评估:使本企业领导层评价公司自身的软件能力,向外宣布自己 企业的软件能力
CMMI 的评估类型:
软件组织的关于具体的软件过程能力的评估。
软件组织整体软件能力的评估(软件能力成熟度等级评估)。
CMMI 的基本思想
1、解决软件项目过程改进难度增大问题
2、实现软件工程的并行与多学科组合
3、实现过程改进的最佳效益
研发背景
CMM 的成功促使其他学科也相继开发类似的过程改进模型, 例如系统工 程、需求工程、
人力资源、集成产品开发、软件采购等等,从 CMM 衍生出了一些改善 模型,比如:
(1) SW-CMM (Software CMM) 软件 CMM
(2) SE-CMM (System Engineering CMM) 系统工程 CMM
(3) SA-CMM (Software Acquisition CMM) 软件采购 CMM
(4) IPT-CMM (Integrated Product Team CMM) 集成产品群组 CMM
(5) P-CMM (People CMM) 人力资源能力成熟度模型
为了以示区别,国内外很多资料把 CMM 叫做 SW-CMM。按照 SEI 原来的 计划,CMM 的改进版本 2.0应该在 1997年 11月完成,然后在取得版本 2.0得实践反馈意见之后,在 1999年完成准 CMM2.0版本。
但是,美国国防部办公室要求 SEI 推迟发布 CMM2.0版本,而要先完成 一个更为紧迫的项目 CMMI,原因是在同一个组织中多个过程改进模型的存 在可能会引起冲突和混淆, CMMI就是为了解决怎么保持这些模式之间的协 调。
CMMI(Capability Maturity Model Integration)即能力成熟度集成 模型,这是美国国防部的一个设想,他们想把现在所有的以及将被发展出 来的各种能力成熟度模型,集成到一个框架中去。这个框架有两个功能, 第一,软件采购方法的改革;第二,建立一种从集成产品与过程发展的角 度出发、 包含健全的系统开发原则的过程改进。 就软件而言, CMMI 是 SW-CMM 的修订本。
它兼收了 SW-CMM 2.0版 C 稿草案和 SPA 中更合理、更科学和更周密的 优点。SEI 在发表 CMMI-SE/SW 1.0版时,宣布大约用两年的时间完成从 CMM 到 CMMI 的过渡。
CMMI 项目更为工业界和政府部门提供了一个集成的产品集,其主要目 的是消除不同模型之间的不一致和重复,降低基于模型改善的成本。CMMI 将以更加系统和一致的框架来指导组织改善软件过程,提高产品和服务的 开发、获取和维护能力。
由业界、美国政府和卡内基?梅隆大学软件工程研究所率先倡导的能力 成熟度模型集成(CMMI)项目致力于帮助企业缓解这种困境。CMMI 为改进 一个组织的各种过程提供了一个单一的集成化框架,新的集成模型框架消 除了各个模型的不一致性,减少了模型间的重复,增加透明度和理解,建 立了一个自动的、可扩展的框架。因而能够重总体上改进组织的质量和效 率。CMMI 主要关注点就是成本效益、明确重点、过程集中和灵活性四个方 面。
与原有的能力成熟度模型类似,CMMI 也包括了在不同领域建立有效过 程的必要元素,反映了业界普遍认可的
源模型
软件能力成熟度模型 2.0版,C 稿;电子行业协会临时标准(EIA/IS) 731;集成产品开发能力成熟度模型(IPD-CMM)v0.98。
原则
(1)、强调高层管理者的支持。过程改进往往也是由高层管理者认识 和提出的,大力度的、一致的支持是过程改进的关键。
(2)、 仔细确定改进目标,首先应该对给定时间内的所能完成的改 进目标进行正确的估计和定义并制定计划。选择能够达到的目标和能够看 到对组织的效益。
(3)、 选择最佳实践,应该基于组织现有的软件活动和过程财富, 参考其他标准模型,取其精华去其糟粕,得到新的实践活动模型。
(4)、 过程改进要与组织的商务目标一致,与发展战略紧密结合。 目标
(1)、 为提高组织过程和管理产品开发、发布和维护能力提供保障。
(2)、 帮助组织客观评价自身能力成熟度和过程域能力,为过程改 进建立优先级以及执行过程改进。
方法
(1)、决定哪个 CMMI 模型等级最适合组织过程改进需要。
(2)、 选择模型的表示法是连续式还是阶段式。
(3)、 决定组织需要用到的模型中的知识领域。
(4)、 类似 CMM 提出的过程改进 6步,集成化过程改进分成:开始 集成过程改进,建造集成改善平台,集成传统过程,启动新过程,进行改进 评估。
内容
CMMI 内容分为“Required”(必需的)、“Expected”(期望的)、 “Informative”(提供信息的)三个级别,来衡量模型包括的质量重要性 和作用。最重要的是
成功的组织模型中。
CMMI 包括了 10种
CMMI 提供了阶段式和连续式两种表示方法,但是这两种表示法在逻辑 上是等价的。我们熟悉的 SW-CMM 软件能力成熟模型就是是阶段式的模型, SE-CMM 系统工程模型是连续式模型,而 IPD-CMM 集成产品开发模型结合了 阶段式和连续式两者的特点。
阶段式方法将模型表示威一系列
连续式模型没有像阶段式那样的分散阶段,模型的 KPA 中的方法是当 KPA 的外部形式, 并可应用于所有的 KAP 中, 通过实现公用方法来改进过程。 它不专门指出目标,而是强调方法。组织可以根据自身情况适当裁剪连续 模型并以确定的 KPA 为改进目标。
两种表示法的差异反应了为每个能力和成熟度等级描述过程而使用的 方法,他们虽然描述的机制可能不同,但是两种表示方法通过采用公用的 目标和方法作为需要的和期望的模型元素,而达到了相同的改善目的。 现在 CMMI 面临的一个挑战就是创建一个单一的模型,可以从连续和阶 段两个角度进行观察,包含相同的过程改进基本信息;处理相同范围的一
个 CMMI 过程能够产生相同的结论。统一的 CMMI(U-CMMI)是指产生一个只 有公用方法和支持他们的 KPA 组成的模型。当按一种概念性的可伸展的方 式编写,并产生了用于定义组织的特定目标过程模版,定义的模版构件将 定义一个模型以适用于任何工程或其他方面。
与 CMM 差别
CMMI 模型的前身是 SW-CMM 和 SE-CMM, 前者就是我们指的 CMM。 CMMI 与 SW-CMM 的主要区别就是覆盖了许多领域; 到目前为止包括四个下面领域: (1)、软件工程(SW-CMM)
软件工程的对象是软件系统的开发活动,要求实现软件开发、运行、 维护活动系统化、制度化、量化。
(2)、系统工程(SE-CMM)
系统工程的对象是全套系统的开发活动,可能包括也可能不包括软件。 系统工程的核心是将客户的需求、期望和约束条件转化为产品解决方案, 并对解决方案的实现提供全程的支持。
(3)、集成的产品和过程开发(IPPD-CMM)
集成的产品和过程开发是指在产品生命周期中,通过所有相关人员的 通力合作,采用系统化的进程来更好地满足客户的需求、期望和要求。如 果项目或企业选择 IPPD 进程,则需要选用模型中所有与 IPPD 相关的实践。 (4)、采购(SS-CMM)
采购的内容适用于那些供应商的行为对项目的成功与否起到关键作用 的项目。主要内容包括:识别并评价产品的潜在来源、确定需要采购的产 品的目标供应商、监控并分析供应商的实施过程、评价供应商提供的工作 产品以及对供应协议很供应关系进行适当的调整。
在以上模块中,企业可以选择软件工程,或系统工程,也可以都选择。 集成的产品和过程开发和采购主要是配合软件工程和系统工程的内容使 用。例如,纯软件企业可以选择 CMMI 中的软件工程的内容;设备制造企业 可以选择系统工程和采购;集成的企业可以选择软件工程、系统工程和集 成的产品和过程开发。CMMI 中的大部分内容是适用各不同领域的,但是实 施中会有显著的差别,因此模型中提供了
CMM 的基于活动的度量方法和瀑布过程的有次序的、 基于活动的管理规 范有非常密切的联系,更适合瀑布型的开发过程。而 CMMI 相对 CMM 更一步 支持迭代开发过程和经济动机推动组织采用基于结果的方法:开发业务案 例、构想和原型方案;细化后纳入基线结构、可用发布,最后定为现场版 本的发布。虽然 CMMI 保留了基于活动的方法,它的确集成了软件产业内很 多现代的最好的实践,因此它很大程度上淡化了和瀑布思想的联系。
在 CMMI 模型中在保留了 CMM 阶段式模式的基础上,出现了连续式模 型,这样可以帮助一个组织以及这个组织的客户更加客观和全面的了解它 的过程成熟度。同时,连续模型的采用可以给一个组织在进行过程改进的 时候带来更大的自主性,不用再象 CMM 中 一样,受到等级的严格限制。这 种改进的好处是灵活性和客观性强,弱点在于由于缺乏指导,一个组织可 能缺乏对关键过程域之间依赖关系的正确理解而片面的实施过程,造成一 些过程成为空中楼阁,缺少其他过程的支撑。两种表现方式(连续的和阶 段的)从他们所涵盖的过程区域上来说并没有不同,不同的是过程区域的 组织方式以及对成熟度(能力)级别的判断方式。
CMMI 模型中比 CMM 进一步强化了对需求的重视。在 CMM 中,关于需 求只有需求管理这一个关键过程域,也就是说,强调对有质量的需求进行 管理, 而如何获取需求则没有提出明确的要求。 在 CMMI 的阶段模型中, 3 级 有一个独立的关键过程域叫做需求开发,提出了对如何获取优秀的需求的 要求和方法。CMMI 模型对工程活动进行了一定的强化。在 CMM 中,只有 3级中的软件产品工程和同行评审两个关键过程域是与工程过程密切相关 的,而在 CMMI 中,则将需求开发,验证,确认,技术解决方案,产品集成 这些工程过程活动都作为单独的关键过程域进行了要求,从而在实践上提 出了对工程的更高要求和更具体的指导。CMMI 中还强调了风险管理。不像 在 CMM 中把风险的管理分散在项目计划和项目跟踪与监控中进行要求, CMMI3级里单独提出了一个独立的关键过程域叫做风险管理。
标准名词术语
1 AT Assessment Team 评审小组
2 ATM Assessment Team Member 评审小组成员
3 BA Baseline Assessment 基线评审
4 CAR Causal Analysis and Resolution 原因分析与决策
5 CBA CMM-Based Appraisal 基于 CMM 的评价
6 CBA-IPI
CMM-Based Appraisal for Internal Process
Improvement
为内部过程改进而进行的基于 CMM 的评价(通常
称为 CMM 评审)
7 CC Configuration Controller 配置管理员
8 CF Common Feature 公共特性
9 CFPS Certified Function Point Specialist 注册功能点专家 10 CI Configuration Item 配置项
11 CM Configuration Management 配置管理
12 CMM Capability Maturity Model 能力成熟度模型
13 CMMI Capability Maturity Model Integration 能力成熟度集成 模型
14 COTS Commerce off the shelf 商业现货供应
15 DAR Decision Analysis and Resolution 决策分析与制定 16 DBD Database Design 数据库设计
17 DD Detailed Design 详细设计
18 DP Data Provider 数据提供者
19 DR Derived Requirement 派生需求
20 EPG Engineering Process Group 工程过程小组
21 FP Function Point 功能点
22 FPA Function Point Analysis 功能点分析
23 FR Functional Requirement 功能性需求
24 GA Gap Analysis 差距分析
25 ID Interface Design 接口设计
26 IFPUG International Function Point Users Group 国际功能点 用户组织
27 IPM Integrated Project Management 集成项目管理
28 IR Interface Requirement 接口需求
29 KPA Key Process Area 关键过程域
30 KR Key Requirements 关键需求
31 LA Lead Assessor 主任评审员
32 MA Measurement and Analysis 测量与分析
33 MAT Metrics Advisory Team 度量咨询组
34 MCA Metrics Coordinator and Analyst 度量专员
35 ML matreraty library 度量数据库
36 NFR Non-functional Requirement 非功能性需求
37 OC Operational Concept 操作概念
38 OID Organizational Innovation and Deployment 组织革新与部 署
39 OPD Organizational Process definition 组织过程定义 40 OPF Organizational Process focus 组织过程焦点
41 OPL Organizational Process Assets 组织过程财富
42 OPP Organaizational Process Perormance 组织过程性能 43 OSSP Organization’s Set of Standard Process
组织标准过程集合
44 OT Organizational Training 组织级培训
45 PA Process Areas 过程域
46 PAT Process Action Team 过程行动小组
47 PB Process Assets Library 过程财富库
48 PD Preliminary Design 概要设计
49 PDSP Project Defined Standard Processes 项目定义标准过程 50 PI Produce Integration 产品集成
51 PLC Product Life Cycle 产品生命周期
52 PMC Project Monitoring and Control 项目监控
53 PP Project Planning 项目策划
54 PPQA Process and Product Quality Assurance 过程与产品质量 保证
55 PPR Price Performance Ratio 性能价格比
56 QA Software Quality Assurance 软件质量保证
57 QA Quality Assurance 质量保证
58 QAP Software Quality Assurance Plan 质量保证计划
59 QPM Quantitative Project Management 量化项目管理
60 RD Requirements Development 需求开发
61 RM/ReqM Requirements Management 需求管理
62 RSKM Risk Management 风险管理
63 RTM Requirement Traceability Matrix 需求跟踪矩阵
64 SAM Supplier Agreement Management. 供应协议管理
65 SC Steering Committee 指导委员会
66 SCAMPI
Standard CMMI Assessment Method for
Process Improvement 过程改进 CMMI 标准评审方法
67 SCCB Software Configuration Control Board 软件配置管理控制 委员会
68 SCM Software Configuration Management 软件配置管理
69 SDP Software Development Plan 软件开发计划
70 SEI Software Engineering Institute (美国)软件工程学院 71 SEPG Software Engineering Process Group 软件工程过程组 72 SPI Software Process Improvement 软件过程改进
73 SPP Software Project Planning 软件项目策划
74 SPTO Software Project Tracking and Oversight 软件项目跟踪 与监控
75 SR System Requirements 系统需求
76 SRS Software Requirement Specification 软件需求规格 77 SSM Software Subcontract Management 软件分包管理
78 SSR Software System Requirement 软件系统需求
79 TS Technical Solution 技术解决方案
80 UC Use Case 用例
81 UID User Interface Design 用户界面设计
82 VAL Validation 确认
83 VER Verification 验证
84 WBS Work Breakdown Structure 工作分解结构
85 WP Work Products 工作产品
86 Pre-assessment 预评审
87 Baseline 基线
88 Quality Attribute 质量属性
89 Scenario 场景
实施
现在很多企业因某种原因想做 CMMI 了,大体做法
1、决定实施 CMMI
2、EPG 接受培训,理解 CMMI
3、 EPG 根据自己理解的 CMMI 和实际情况开发一大堆漂漂亮亮的过程文 档、流程图、表格、模板、检查单、作业指南。
4、大家边听着 EPG 的解释(包括培训、答疑),边执行这些过程标准, 然后审计(内、外)
将目前的最佳实践记录下来、写下来、文档化下来。
很多新的 EPG 在做了一段时间后无奈的发现自己居然沦落成了一个过 程标准解说员、甚至文档管理员。自己工作大部分时间是面对文档,或者 督促别人写文档
EPG 最主要的工作应该深入到研发第一线, 帮助研发人员解决研发过程 中面临的最严重的实际问题(当然是解决方案要上升到过程高度,而不应是 单个问题或个人),甚至哪怕是一些不严重但以你的项目经验知道该如何解 决的问题上。总体说来就是掌握项目进展中的任何细微的技术难点要点, 并主动记录下来。
为什么这么说呢?CMMI 实施的主要宗旨就是以每个项目为采集数据的 源头,达到企业整体效益提升和资源重用。真正有价值的东西,是需要一 线人员在实际工作中遇到问题,解决问题,并总结问题,不是一个一线工 作的流水帐。就象一份研发人员的日报。写了上午做什么,下午做什么。 这对企业的积累有什么用处呢?他工作过程中,遇到什么问题,他是怎么解 决的,走过什么弯路,实验过几种方法,失败了,失败的原因是什么,最
后选择了什么方法,可能不是最好的,但完成了任务,达到了效率和资源 分配的平衡。这些东西才可能是未来类似项目中,遇到类似问题时,可能 有参考价值的。通常也是 EPG 个人职业生涯的技术积累。只有公司里每个 员工,把自己认为最有价值的积累贡献出来。才可能达到公司有价值的积 累。而决不是形式上写的上午下午每个小时的流水帐。
人员素质
1、明白什么是有价值的积累,先是对你个人,然后才是顺便帮公司做 了积累。
2、深入一线,发现她们并忠实地记录她们。CMMI 里的 SP、GP,只是 帮助你,提醒你在哪个环节,哪些东西可能是有价值了。你去收集一下, 别视而不见了。因为还有一个企业和你个人的角度不同,立场不同的问题。 例如,REQM 里收集需求,对个人技术方面的积累虽然不多,但对企业是至 关重要的,一次需求变更,没详细写清楚,忘记了到客户那里去签字落实, 可能就会给企业造成很大的损失。做为一个合格的 EPG,是需要有这份责任 和义务把每个环节都做到最好,这是职业道德所在。同时也是对自我延伸 的一个好机会,学会一些和人的沟通,倾听,把专业的东西以平易的方式 表达。这些也都算是 EPG 额外的收获。
通常情况下,为了按时按量完成项目,一线的骨干,对写日报、周报、 文档都很不屑。EPG 也很迁就,事后再补,这也不失为一个提高效率的好办 法。但过去一个月半年了,我们正常人的记忆都能想象,很难记住细节。 无非就是敷衍。这也在情理之中。你总不能让一个明天就要交东西的小组, 今天晚上在通宵努力解决 BUG 的同时,还写什么报告,这也不尽人情。但 作为 EPG 不能只把眼光集中在这妇人之心上。要想的更远。为什么会把项 目推到这么晚, BUG 还没解决完?难道要永远这样下去吗?项目中是有很多不 可预测的因素,甚至是开发人员常说的
那怎么解决这种两难的问题呢?逼着技术骨干写心水,人家没时间也的 确压力很大。不写,公司又得不到有效积累,积累的都是垃圾流水。有个 公司的办法和经验到可以借鉴一下:
公司内部搞了个 BBS,把不同类型的工作分成不同的组,有纯技术的, JAVA 组,C++组等,也有 PPT 组,甚至动画组,界面组。大家把自己平时的 工作积累 FTP 上去,甚至制作方法,遇到问题和解决方法的文档都丢上去, 开始怎么想,用了多少套方案,最后选择了什么。自我感觉如何。把这些 心路历程都写成文档。丢到阳光下,大家评论。用点击率和
说明谁写的是心水,谁在写垃圾。大家都是一个公司的,很容易实名。直 接纳入考核机制中。做为一线人员,大家也有动力来写,自己的聪明才智 有了展现的平台,虚荣心和荷包都得到了相应的满足。何乐而不为呢? EPG 适时的评估大家的成果,并把他们分到项目里。帮助项目总结,甚 至在平时遇到问题时,直接帮助技术人员做必要记录。项目进度松时,再 督促项目人员完善内容。以达到对个人和公司积累的最大化。
EPG 应该明白学习和积累是个终身的过程,对公司如此,对个人也是如 此。CMMI 是个辅助,辅助我们对公司做积累,也帮助我们个人做必要的积 累。公司需要逐步走向更高的管理水平,发展平台。
实施流程
阶段 1:CMMI项目启动会
明确企业实施 CMMI 的商业目标,建立 CMMI 项目实施的沟通机制。 阶段 2:CMMI基础培训和过程改进小组(EPG)组建
进行 CMMI 基础概念讲解,指导企业建立核心的过程改进小组。 阶段 3:诊断
充分了解企业研发过程现状,识别企业现有软件过程与企业现阶段理 应达到的的 CMMI 成熟度级别的差距, 提交诊断报告, 进行过程改进的策划。 阶段 4:过程域培训和文件定义
结合企业过程现状进行 CMMI 过程域培训, 通过举例、 案例分析等方式, 让企业的 EPG 掌握过程文件定义技巧,结合企业实际情况有针对性的定义 组织的研发过程,并确定过程产出物(如:需求报告)
阶段 5:项目试点
选择代表公司核心业务的项目或者典型项目进行试点,通过试点来完 善过程文件,从而为企业全面推广过程文件打下基础。
阶段 6:组织推广
全员参与全面导入与执行 CMMI。
阶段 7:预评估
验证组织推广的结果,识别企业尚存缺陷并制定再次改善方案,准备 充分,以便企业能够更好进行正式 SCAMPI 评估。
阶段 8:SCAMPI正式评估
由 SEI 授权的主任评估师领导, 采用 SCAMPI ( Standard CMMI Appraisal Method for Process Improvement)评估方法,对企业的能力成熟度进行正 式的评估,颁发证书,通过 SEI 网站向全球发布企业信息。