CMM2软件能力成熟度实践.docx
- 文档编号:11614653
- 上传时间:2023-03-28
- 格式:DOCX
- 页数:79
- 大小:161.96KB
CMM2软件能力成熟度实践.docx
《CMM2软件能力成熟度实践.docx》由会员分享,可在线阅读,更多相关《CMM2软件能力成熟度实践.docx(79页珍藏版)》请在冰豆网上搜索。
CMM2软件能力成熟度实践
CMM-2软件能力成熟度实践
中国软件行业的特点,是规模小和管理能力低,如何能在短的时间里提高管理能力呢,CMM是一个很好的选择.依照CMM模型进行企业软件过程改造有助于让大家….
CMM来源于实践,在软件开发活动中,由于开发工具\软件开发过程\开发语言规则等的地域性特点不强,而地域性强的是人员\项目内容等,而….
CMM代表了实施软件过程改进的典型过程,它是建立在软件工程的基础上,它的目的是提高软件机构对成本、质量和生产效率的控制能力,但并不是解救项目的灵丹妙药,CMM是一个工具,因为它是从各和规模的软件项目过程归纳而来,所以只有灵活地运用CMM才帮助企业提高。
CMM2级也称为可重复级,目标是实现对软件项目制定了基本的软件管理和控制规范,建立稳定的软件计划和跟踪的过程,对软件需求进行控制,对相关工作产品(工作产品所指的并不一定是原代码,有可能是项目技术可行性分析报告,项目计划等工作的结果)进行控制,对变更进行控制。
本书是普及性书籍,是用来指导企业进行实践的CMM2过程改进的,不是CMM的详细教材,有兴趣者可以买有关CMM原理的书籍来看,本书也不讲解软件工程的细节,但是大家可以参考本书所指定和引用的书籍。
本书重点通过CMM模型所涉及为企业改进活动实践讲起,通过一个软件项目的实例来指导企业进行CMM2的过程改进,当然过程涉及到软件工程的细节时,本书将指导大家使用和本书相关的相关软件工程的资源。
本书适合想进行CMM2过程改进的企业或组织的领导、项目经理、开发组人员作为。
。
。
。
本书是从软件开发的实践出发编写而成,本书中不涉及软件项目的外包的内容。
第一章CMM简介
第二章组织级该做些什么
第三章如何管理需求
第四章如何进行软件策划
第五章开始编码了,怎么控制
第六章如何进行配置管理
第七章质量保证
第八章相关培训
第九章CMM2评估
附录A:
CMM1.1内容
第一章CMM的简介3
1.1CMM简述3
1.2CMM的5个级别3
1.3CMM级别的关系4
1.4国内企业实施CMM2过程改造5
第二章详解CMM27
2.1CMM的结构和组成7
2.2等级2的RM关键过程域(需求管理)10
2.3等级2的SPP关键过程域(软件项目计划)14
第三章管理层该做什么41
3.1先讲一些质量基本概念41
3.11什么是软件质量,如何保证软件质量41
3.12什么是项目管理,为什么要采用项目管理来开发软件43
2.2看看我们的日程表44
3.3准备活动47
3.31CMM调研48
3.32决策49
3.4建立基本的组织机构49
3.41组织机构49
3.43项目组的组织结构50
3.44软件工程组和相关组52
第四章制定CMM2实施计划53
第一章CMM的简介
1.1CMM简述
CMM(CapabilityMaturityModelforSoftware)是软件能力成就度模型,它是由软件工程研究所(SEI,SoftwareEngineeringInstitute)提出的,目的是领导软件机构进行在成本和进度的要求下能提交高质量的软件,CMM为软件企业提供了一条从混乱、不成熟的软件过程向成熟的、有纪律的软件过程改进的方法。
1986年11月,SEI在MITRE公司协助下,开始开发过程成熟度框架,以帮助软件机构进行软件过程改造;1987年SEI发布了软件过程成熟度问卷;1991年CMM最初版本通过评审,并开始在软件机构中应用。
什么叫软件过程,软件过程是软件工程的基础,软件过程是指在相应的规范下组织和使用相应的资源(人财物等)生产出满足客户需要的软件产品。
软件过程可以抽象成一系列的工作和工作产品的开发、维护的行为、方法、实践和控制过程,如项目计划、概要设计、详细设计、代码、测试计划等。
软件过程成熟度指对于具体的软件过程进行明确定义、管理、测量和控制的程度,改进软件过程要求企业加强管理机制,并且长期有效地关注软件过程,建立软件过程的制度化,这样才能以越来越好的方式进行软件开发。
CMM是全面质量管理(TQM,TQCtotalqualityManagement)中的过程管理部分在软件行业的应用,CMM比ISO9000更细致,更具有针对性,当然通过了ISO9000认证的软件企业基本上已经满足了CMM2至CMM3的要求。
CMMI
1.2CMM的5个级别
CMM一共有5个级别,分别是一级初始级、二级可重复级、三级已定义级、四级已管理级和五级优化级。
级别1:
初始级
软件机构不能提供开发和维护软件的稳定环境,,经常做出不切合实际的承诺,危机发生时,项目一般都会脱离原有计划,回到仅有编码和调试的状态,项目经常超出预算和超期,软件项目的成功完全依赖于项目组中特别的人,当他们离开后他们对软件项目过程的影响随之消失,所以项目的开发能力的保证来自于个人能力而非组织能力.
比较典型的特征是项目的需求不断变更,软件设计不断变更,经常会发生推倒重来的事情,项目后期加班严重,最终产品的客户满意度不高等等.
在级别一中,软件过程是一个不定的过程(黑盒),由于没有很好地定义活动和实施,管理人员需要花大量时间确定项目的状态和活动的状态,需求在不被确定的情况下进入软件过程,软件产品的质量只有在发布后才能被评估出来.
级别2:
可重复级
建立并实施了软件管理的规程,项目执行经过定义的、文档化的、有以往经验的、可测量的、强制的以及可改进的过程,管理级对软件项目制定了基本的软件管理和控制措施,项目负责人不断跟踪软件成本、进度,一旦出现问题能很快确定,对软件需求和开发过程中的工作产品进行基线(基线:
)管理。
软件项目的计划和跟踪是稳定的,并可以重复以前的成功,项目的过程处于一个项目管理系统的有效的控制之下,遵守并执行基于以前成功项目所制定的项目计划。
在级别二,因为已经建立基本的项目管理,软件项目的开发过程可以看成是一系列黑盒的串连,在项目的里程碑处具有可视性(可以知道当然的状态和进度),客户可以在里程碑处对产品进行评审.
级别3:
已定义级
将组织用于开发和维护的标准过程文档化,指定了一个负责机构过程活动小组(SEPG),在组织内部进行培训,保证全体人员和负责人具有所需的知识和技能。
软件过程被严格定义,包括准备、输入、实施工作的标准和规程、验证机制、输出和完成准则的过程。
无论是软件工程活动还是管理活动,其过程都是稳定的,可重复的,软件开发的成本、进度和功能均可受到良好的控制,软件质量被跟踪。
在三级,软件过程中的任务具有可视性,管理人员和工程人员对自身的活动在一定程序进行相互交流,管理人员对可能发生的风险进行准备,客户可以随时得到关于项目准确的最新情况.
级别4:
已管理级
组织对所有的项目的关键软件过程活动进行生产率和质量的测量,收集并分析这些数据,为评估项目的软件过程和产品建立定量的基础。
该级别的软件机构可以对软件过程因为软件过程是稳定的、可测量的,所限定的数量范围内预测软件的过程趋势和工作产品的质量,当意外发生时,可明确指出变化产生的原因,当超出预计边界时,能采取相应的措施进行纠正。
在该级,管理人员可以测量项目的进度和存在的问题,而且在项目开始之前,客户就能对过程能力和风险有定量的认识.
级别5:
优化级
组织强调渐进的过程改进,以预防缺陷为目的的过程中,能有效地确定软件的优势和弱势,并预先加强防范,使用描述软件过程有效性的数据完成新技术的成本和效益分析,并向该机构的软件过程提供相应的更改建议.
软件小组通过分析缺陷产生的原因对软件过程进行评估以预防已知的缺陷再次发生,并在组织内部进行宣传以防止再次发生.
级别5的特点是,过程可以不断得到改进,并且可以通过对已有软件过程进行不断改进来提高过程效率和能力,可以使用新技术和新方法进行革新,技术和过程改进可作为常规的业务活动来进行计划和管理.
在该级对过程进行更改后造成的影响能够被准确的被评估,管理人员能估计和定量跟踪更改的效果和影响.
1.3CMM级别的关系
CMM的级别其实是将过程管理的改进活动由浅入深,每一个级别都是下一个级别的基础,如果企业要跳跃级别,往往会导致改进活动失败.一般来说较高等级的软件过程的潜力只有建立在相应的基础上才可以发挥出来.成熟度等级只描述一个等级上占主导地位的关键问题,即主要矛盾。
在一级的企业中,在还没建立可重复级过程(二级)之前,试图去实施已定义级的过程,因为没有管理过程的规定,当项目陷入成本和进度的压力后,工程过程会在这些压力下被抛弃.
在还没有对过程进行定义为基础的软件企业,试图进行定量管理过程(四级),因为没有对过程进行定义,就没有了采集和解释数据的共同基础,那么一个项目中采集到的数据,对其它项目来说是无用的,如果使用它,必然导致不良的结果,企业即使具有实施较高成熟度等级的软件过程的能力并不意味着它可以跳越成熟度等级。
在CMM模型中,每个等级都有一个必要的基础,从此基础出发才能达到下一个等级,因此,跳越等级通常被认为是违反规律和不能允许的。
当然,在CMM模型中,针对当前机构或项目的需要,也可以在较低级别实行较高级别的实践,例如:
SEPG小组(软件工程过程组),SEPG小组是三级的属性,但是在企业从一级向二级改进的活动中,经常建立该组来指导企业从一级到二级的过程改进.另外就是部分活动,如分析、测试等,在二级中没有进行描述,但是一级的企业依然有这些活动,在三级,这些活动被定义为连贯和严谨的软件工程过程。
当然本书所讲的一级企业进行二级改造的例子中没有SEPG小组。
1.4国内企业实施CMM2过程改造
中国注册的软件企业有八千余家,实际进行软件开发的约有五千多家,绝大多数的企业的研发人员规模小于50人,就软件开发来说,多是作坊式开发,项目的管理是基于黑箱的人的管理方式,项目的成功和精英的关系极大,如果项目组中有人离开,不要说精英,就是一个普通程序员的离开都有可能导致项目延期甚至失败,而就每个项目来说,经验(成功的和失败的)只能积累在个人的范围内,对于企业,对于其它的项目基本上没有帮助.
中国软件企业的特点是规模小,年纪轻,没有积累的管理经验,很多企业对软件工程还知之甚少,就软件的开发管理很不成熟,而CMM模型为软件企业搭建了一个较好的管理框架,用于管理企业内部具体的软件过程,可以在短的时间内为企业建立一套完整的软件工程过程,从而极大程度地提高企业按计划的时间和成本提交有质量保证的软件产品的能力。
中国和印度的软件产品起步是差不多的,但是如今印度已经成为名副其实的软件大国,这其中的差别不仅仅只是一个ISO9000或者是CMM认证的差异,仔细对比中国和印度的软件产业,中国自身拥有巨大的软件市场,在软件技术上具有优势,印度总体落后于中国,其软件产品依赖出口,但产业结构已经完成与国际接轨,如今,印度的计算机软件产品已远销世界75个国家,其中28个国家完全依靠印度的计算机软件和服务支撑。
特别是中国加入WTO以后,软件产业与国际化接轨迫在眉睫,软件产品的质量\成本和进度将成为软件企业生存和发展的首要因素,说用CMM进行软件过程改进,利用别人已有的经验,取其对自己有用的部分,加以使用,并由此在实践中不断改进和创新。
这应该是我们赶超世界水平的一种办法,另外用CMM进行软件过程评估,有助于提高我国软件产业的国际竞争力,获得规模效益是有很大帮助的。
实施CMM2模型进行软件过程改进,必然会遇到很多阻力,下面就将简述一下主要阻力及其产生原因。
首先是制度化的理念与原有管理模式的冲突,国外的软件企业有几十年的软件管理经验,其软件工程的推广程序远远超过我国,而过程改进将首先同企业文化冲突,原因很多,领导不重视,相关人员抵触,质量保证人员和软件工程组人员得不到应有的重视和权威。
其实CMM2在推行过程中与在中国推行ISO9000所遇到的问题是一样的,推行制度化,制定规范、监督和执行三位一体,这就会与企业的特权行为相抵触,软件开发最常见的就是后期加班加点,不按计划,不管规范,而在这些时间,制度就往往成为压力的牺牲品。
第二是管理层推动的问题,所有制度的推行,必须要有高层领导的推动,过程改造是一个长期的工作,而且并不是立竿见影的,而在真正受到压力的时候,高层领导是否还能够坚定的推动,中国企业在推行ISO9000的时候,很多企业是三把火,是问有多少企业领导是不断对制度和过程进行研究,并成为个中高手,如果自己对此还知之不多,又怎么能了解和体会制度给企业带来的好处呢?
在CMM2过程改进中,我们要求高层领导不只是支持,而且还要亲者参与。
进行CMM过程改造的目的不是为了”评级”,如果企业采用其它的手段通过了”评级”,但自身没有获得提高,这实际上是自欺欺人,在ISO9000的评审中出现过极少的例子,相信在CMM评审中也会出现.
第三是软件企业人员的质量意识亟待提高,中国的软件企业,小规模非公有制企业占绝大多数,而在这些企业中,实施质量体系定向培训的是凤毛麟角,大多数的公司不愿意为此投入资金和人力,造成各级人员不了解质量体系的知识。
另外,项目管理人员对质量体系的实施起着至关重要的作用,但实际上我国软件企业的项目管理人员基本上都是从技术出身,对软件工程的了解,对项目管理的了解都很欠缺,缺乏真正的项目管理意识,而在实际的推广过程中必须首先对他们强化管理意识,这样在真正的软件项目的过程中,项目管理人员就会主动维护质量保证的工作。
第四是CMM咨询和认证的问题,详细的CMM资料都是只告诉你做什么,但是没告诉你怎么做,具体的实施和应用需要企业自己不断去领会并且由专人来进行培训和指导,由于中国的企业培训还没有建立起来,中国的主任评审员还属于稀缺资源,从CMM的评审认证具有垄断性,对中小型企业来说成本较高,在一定程度上也相应影响了CMM的发展,所以在我国,大力推行第三方评审就很有必要了。
而且随着中国进入WTO,CMM评审的价格会相应下调,这对CMM在中国的推广也将是一件好事.
提供高质量的产品和成功的产品是两个不同的概念,高质量的产品是成功产品的重要条件,但不是说高质量的产品就一定会成功,这也就是说CMM并不是企业的万灵丹,它一种有步骤且一致地改进软件产品的管理过程和工程过程的方案,但是它并不能解决软件工程中的全部问题,它的目的是提高企业的当前软件过程的管理能力,而且也不涉及企业的战略能力,如企业的人才战略、新技术战略(在低级的企业中,采用新技术是有风险的)以及产品战略等,一个企业的成功必须是多个条件加在一起。
关于人才的管理软件工程所专门开发了一套人员管理成熟度模型(PM-CMM),有兴趣的读者可以参考与之相关的文档.
由于CMM产生的历史的特殊性,CMM1.1版本很适合与政府签约的大型软件开发组织部的大型项目,这也是很多中小型企业对表示CMM怀疑的地方,事实上对中小型组织或中小型项目来说,合理地对CMM进行剪裁是有效的,另外就CMM2级和3级来说,基本上与组织和项目的规模大小没有直接的关系。
对于企业实施CMM笔有提出以下几个建议:
软件企业应专注于软件工程过程改进,除非必要,不要搞软件能力评审,特别是不能将“认证”作为执行改进活动的目的。
软件过程管理与改进的唯一目的是:
开发制造高质量的软件产品。
(质量的几个重要的要素是:
产品要适应客户的需要,产品要保时,保成本。
)
领会CMM和其他的模型与标准,运用自己的专业判断力去使用它,决不能生搬硬套。
按照企业自身的特点、要求与条件去制订软件过程和选择实行改进的部分。
软件过程的建立与改进要有短、中、长期的目标,有轻重缓急之分。
切忌一下子什么都想达到。
摊子铺得越大,失败的概率也越大,一定要选择先做什么,什么是“最薄弱的环节”和“最易做到而又有显著收效”。
就某一能力的成熟度来说,不必一下子去满足该级级的所有目标,可以试行某部分关键过程领域的中的部分关键实践活动,要逐步取得经验后再展开。
在CMM过程改造中从等级1到等级2可能需用几年的时间,而在其它等级间的升迁通常花费约2年时间。
企业上层领导要首先理解建立软件过程管理和改进的重要,并亲自领导这件工作。
要保证过程管理的人员配备。
企业上层领导的持之以恒的参与是成功的先决条件。
除此之外,专业开发人员的全力支持与参与过程管理和改进也是成功的关键。
企业在内部的“过程评估”中,坦诚地暴露软件过程中存在的各种问题。
从而制定出真正对症下药的过程改进的对策。
是否在企业中全面推行CMM过程改造是一个慎重的决定,它所涉及的范围相当广,而且要求投入人力、物力和财力资源,一个企业如果单凭一点点对CMM的认识就做出是否全面推行CMM的决定,那将是很遗憾的。
企业应该在对CMM及有关的一切知识有彻底的理解之后,才去考虑是否全面引进的问题。
////另外,在二级的企业,对项目时间及成本的估计会超过一级////
第二章详解CMM2
CMM由五个成熟度等级组成。
除了等级1外,每个成熟度等级由几个关键过程域组成。
每个关键过程域又划分为五个称作共同特点的部分。
共同特点规定一些关键实践,当这些关键实践群体得到认真执行,能实现关键过程域的目标。
下显示了CMM的这个结构。
2.1CMM的结构和组成
CMM的组成部分包括:
成熟度等级(Maturitylevels)
一个成熟度等级是在朝着实现成熟软件过程进化选中的一个妥善定义的平台。
五个成熟度等级提供CMM的顶层结构。
过程能力(ProcessCapability)
软件过程能力描述通过遵循软件过程能实现预期结果的程度。
一个组织的软件过程能力提供一种预测组织承担下一个软件项目时预期的最可能结果的方法。
关键过程域(KeyProcessareas)
每个成熟度等级由若干关键过程域组成。
每个关键过程域标识出一串相关的活动,当它们作为群体完成时,就达到一组目标,此组目标对建立该过程成熟度等级是至关重要的。
关键过程域是分别定义在各个成熟度等级并与之相连在一起的。
例如,等级2的一个关键过程域是软件项目策划。
目标(Goals)
目标概括一个关键过程域中的关键实践,并可用于确定一个组织或项目是否已有效地实施该关键过程域。
目标表示每个关键过程域的范围、边界和意图。
例如,软件项目策划关键过程域的一个目标是“软件估计已文档化,供策划和跟踪软件项目使用。
”参
见“软件能力成熟度模型,1.1版”[Paulk93a]和本文的4.5节(即运用专业判断),能得到更多的有关解释目标的信息。
共同特点(CommonFeatures)
将关键实践分别归入下列五个共同特点中:
执行约定、执行能力、执行的活动、测量和分析、及验证实施。
共同特点是一种属性,它能指示一个关键过程域的实施和规范化是否是有效的、可重复的和持久的。
执行的活动这个共同特点描述实施活动。
其余四个共同特点描述规范化因素,它们使得过程成为组织文化的一部分。
关键实践(KeyPractices)
每个关键过程域用若干关键实践加以描述,当实施这些关键实践时,能帮助实现该关键过程域的目标。
关键实践描述对关键过程域的有效实施和规范化贡献最大的基础设施和活动。
例如,软件项目策划这个关键过程域的一个关键实践是“按照已文档化的规程制定项目的软件开发计划”。
这个结构图用个例子来解释,如果一个企业达到了CMM二级的水平,这表明了该企业具有以下的过程能力:
已建立管理软件项目的方针和实施这些方针的规程。
基于在类似项目上的经验对新项目进行策划和管理。
使软件项目的有效管理过程制度化,组织能重复在以前项目上所开发的成功实践,尽管项目所实施的具体过程可能不同。
一个有效过程可特征化为实用的、已文档化的、已实施的、已培训的、已测量的和能改进的。
项目已设置基本的软件管理控制。
实际可行的项目约定是基于对以前项目的观察结果和当前项目的需求。
项目的软件经理跟踪软件成本、进度和功能;识别在满足约定方面出现的问题。
对软件需求和为实现需求所开发的工作产品建立基线,并控制其完整性。
软件项目标准已确定,并且组织能保证准确地执行它们。
如果有子承包商的话,软件项目与他们一起努力建立一种强有力的客户一供应商关系。
过程能力可概括为有纪律的,因为软件项目的规划和跟踪是稳定的,能重复以前的成功。
由于遵循实际可行的基于以前项目性能的计划,项目过程处在项目管理系统的有效控制之下。
对于CMM二级,它包括了6个关键过程域,分别是需求管理、软件项目计划、软件项目跟踪和监控、软件配置管理、软件质量保证、软件子合同管理。
每一个关键过程域是之了实现相应的目标,例如需求管理的目标是:
控制指定给软件的系统需求,为软件工程和管理应用建立基线(目标1),保持软件计划、产品和活动与指定给软件的系统需求一致(目标2)。
每一个关键过程域可以分成执行约定、执行能力、执行的活动、测量和分析、及验证实施五个部分(共同特点),这五个部分从五个不同的方向反映了这个关键过程域的过程情况。
对于整个CMM来说,每一系列关键过程域的完成,就代表着企业达到了某一个级别,CMM二级有6个关键过程域,三级有七个,四级两个,五级三个,整个CMM的级别结构如下图:
优化级(5)
过程变更管理
技术变更管理
缺陷预防
定量管理级(4)
软件质量管理
定量过程管理
已定义级(3)
同行评审
组际协调
软件产品工程
集成软件管理
培训大纲
组织过程定义
组织过程焦点
可重复级
(2)
软件配置管理
软件质量保证
软件子合同管理
软件项目跟踪和监控
软件项目策划
需求管理
初始级
(1)
2.2等级2的RM关键过程域(需求管理)
需求管理的目的是在客户和将处理客户需求的软件项目之间建立对客户需求的共同认识。
需求管理包括和客户一起建立和维护有关软件项目需求的协议,该协议称作“分配给软件的系统需求”。
“客户”可解释为系统工程组、销售部门、另一个内部组织、或者一个外部客户。
协议既包括技术需求、又包括非技术需求(例如交付日期)。
该协议形成估计、计划和跟踪整个软件生存周期内软件项目活动的基础。
将系统需求分配给软件、硬件和其它系统成分的工作可能由软件工程组之外的组(如系统工程组)完成,软件工程组可能不能直接控制需求的分配。
在项目约束范围内,软件工程组采取适当的步骤以保证对分配给软件的需求形成文档、并加以控制。
为了实施控制,软件工程组需对初始的和经修改的分配给软件的系统需求进行评审,以保证有关问题在被纳入软件项目之前得以解决。
每当改变分配给软件的系统需求时,都要调整受到影响的软件计划,工作产品和相关活动,使其与更新后的需求保持一致。
目标
目标1:
分配给软件的系统需求是受控的,为软件工程和管理建立基线。
目标2:
软件项目计划、工作产品和活动与分配给软件的系统需求保持一致。
执行约定
约定1项目遵循一书面的、组织级的方针去管理分配给软件的系统需求。
分配给软件的系统需求称为“分配需求”。
分配需求是系统需求的一部分,它将用系统的软件部分来实现。
分配需求是软件开发计划的主要输入。
软件需求分析对分配需求进行详细的分析和细化,并生成文档化的软件需求。
该方针一般规定;
1.对分配需求建立文档。
2.由下列人员评审分配需求:
软件经理
其它受到影响的组
受到影响的组的实例有:
●系统测试组
●软件工程组(包括所有小组,例如软件设计小组)
●系统工程组
●软件质量保证组
●配置管理组
●文档支持组
3.修订软件计划、更改工作产品和相关活动,以保持和分配需求的变更一致。
执行能力
能力1:
对每个项目,应明确对系统需求的分析,和将其分配到硬件、软件和其它部分的职责。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- CMM2 软件 能力 成熟度 实践