cmmi2.docx
- 文档编号:11529192
- 上传时间:2023-03-18
- 格式:DOCX
- 页数:14
- 大小:30.20KB
cmmi2.docx
《cmmi2.docx》由会员分享,可在线阅读,更多相关《cmmi2.docx(14页珍藏版)》请在冰豆网上搜索。
cmmi2
CMMI是什么东西?
CMMI英文全称是CapabilityMaturityModelIntegration,直接翻译就是能力成熟度模型,直接看这几个中文字,你还是没有办法搞清楚CMMI是什么东西的。
大家可能在网上见过很多《成功人士的七个习惯》(可能还有很多类似的名字)的文章吧?
有人总结了成功人士的成功的原因,总结出他们的习惯,如果我们也能具备这些习惯,那么我们也很可能成为成功人士。
类似的,CMMI可以看作是成功企业如何做好软件的一些习惯、做法、准则等的集合,是如何做好软件的最佳实践的集合。
如果企业也能按照CMMI的要求做好,那么企业就很可能成为成功的企业。
CMMI里面所有的要求,都是来自于成功企业的最佳实践的,她的先进性我们不必怀疑,如果我们没有做好,那不是CMMI本身的问题,而是我们自己没有理解好或者是没有执行好的原因。
说到CMMI,就不可避免会提到另外3个字母SEI,SEI全称是SoftwareEngineeringInstitute的全称,直译就是软件工程学院,是美国的一所大学,CMMI标准就是他们搞出来的。
CMMI目前最新版本是V1.2,如果你是现在才开始了解CMMI的,那么你完全没有必要去搞清楚V1.1与V1.2的差别,更加没有必要去比较CMM与CMMI的差别,直接了解CMMIV1.2就可以了,你只需要知道CMM是CMMI的前身,而CMMIV1.1虽然比CMM要新很多,但现在已经不用了。
现在在互联网上还有很多比较CMM与CMMI的文章的,除非你很想了解或者你有很多时间,建议不必去看这些内容。
连续式vs阶段式
CMMI有两种表述方式:
连续式与阶段式,两种方式只是从不同的角度来阐述CMMI,其实质上表达的内容是一致的。
就好像我们做数据库设计的时候,可能会设计不同的视图来查看相同数据表的数据,只是角度不一样。
大家可能会问,好好的CMMI,为什么要搞两种表达方式呢?
不怕把大家搞糊涂吗?
确实这两种方式把不少人给搞糊涂了,这是SEI的一个败笔。
以前的CMM是只有阶段式的表达方式的,连续式是后来提出来的,SEI内部分成两派,一派支持连续式,一派支持阶段式,互不相让,最后达不成一致,就出来了现在这个样子,连续式与阶段式两者共存。
连续式其实更加能反应过程改进的本质,并且能更好地引导企业把过程改进做到实处,但连续式比较难以理解。
阶段式是直接继承CMM的,大家都比较容易理解,而且阶段式有一个级别,在商业上更好宣传,但很容易导致企业为了过级而过级。
连续式和阶段式同时也是评估的两个不同角度,用连续式评估,企业会得到很多个PA的Level,用阶段式评估,企业会得到一个整体的Level。
对CMMI还不是很熟的人士,先了解这么多就可以了,以后再慢慢了解。
CMMI包含了三部分的内容:
CMM的内容,系统工程的内容,集成产品开发IPD的内容。
充分体现了集成,体现了软件工程和系统工程的集合。
因此CMMI既可以用于软件工程,也可以用于系统工程。
CMMI分为阶段型和连续型。
阶段型是从1到5级。
连续型是从0到5级。
组织级的过程能力是靠一组过程能力结合起来体现的,而不仅仅是实现单独一个过程。
而提高组织级能力成熟度一般采用阶段型模型,即Level1到Level5,每个级别都又相关的KPA.
过程域PA可以按照过程管理,项目管理,支持,工程四个大类进行划分,具体可以参考Blog中的下图:
有两种类型的目标和实践:
一种是特别目标SG和特定实践;一种是共性目标GG和共性实践GP。
GG和GP主要分为是个步骤来实现:
执行委托-》执行能力-》指导实施-》验证实施。
其中执行委托是GP2.1;实现能力是GP2.2GP2.3GP2.4GP2.5GP3.1;指导实施是GP2.6GP2.7GP2.8GP3.2;验证实施是GP2.9GP3.0
CMMI实施一般遵循IDEAL方法论,即启动(I)->诊断(D)->建立(E)->行动(A)->学习(L)
阶段表示能力成熟度的五个等级:
初始级
(1)->受管理级
(2)->已定义级(3)->定量管理级(4)->持续优化级(5).
相关的名称和术语定义如下:
干系人(Stakeholder)
项目经理(Projectmanager)
高级经理(Seniormanager)
组织(Organization)
企业(enterprise)
开发(Develop)
项目(Project)
项目开发计划(projectdevelopmentplan)
目标(goal)
实践(practice)
过程域PA(processarea)
子实践(Subpractice)
典型工作产品(typicalworkproduct)
组织资产(organizationalassets)
过程体系结构(processarchitectures)
过程要素(processelement)
产品生命周期(productlifecycle)
组织度量库(organizationalmeasurementrepository)
组织过程资产库(organizationallibraryofprocess-relateddocumentation)
CMMI一共25个KPA,二级7个,三级14个,四级2个,五级2个。
黄色为2级,绿色为3级
ConfigurationManagement(CM)
MeasurementandAnalysis(MA)
ProjectMonitoringandControl(PMC)
ProjectPlanning(PP)
ProcessandProductQualityAssurance(PPQA)
RequirementsManagement(REQM)
SupplierAgreementManagement(SAM)
DecisionAnalysisandResolution(DAR)
IntegratedProjectManagement(IPM)
IntegratedSupplierManagement(ISM)
IntegratedTeaming(IT)
OrganizationalProcessDefinition(OPD)
OrganizationalProcessFocus(OPF)
OrganizationalProcessPerformance(OPP)
OrganizationalTraining(OT)
ProductIntegration(PI)
RequirementsDevelopment(RD)
RiskManagement(RSKM)
TechnicalSolution(TS)
Validation(VAL)
Verification(VER)
QuantitativeProjectManagement(QPM)
OrganizationalEnvironmentforIntegration(OEI)
OrganizationalInnovationandDeployment(OID)
CausalAnalysisandResolution(CAR)
1CMM及CMMI的全称分别是什么?
CMM是英文CapabilityMaturityModel的缩写,中文意思是:
软件能力成熟度模型。
CMMI是英文CapabilityMaturityModelIntegration的缩写,中文意思是:
软件能力成熟度模型集成。
2CMM及CMMI的产生背景如何?
为了保证软件产品的质量,80年代中期,美国联邦政府提出对软件承包商的软件开发能力进行评估的要求。
因此,美国卡内基-梅隆大学软件工程研究所(CMU/SEI)于1987年研究发布了软件过程成熟度框架,并提供了软件过程评估和软件能力评价两种评估方法和软件成熟度提问单。
4年之后,SEI将软件过程成熟度框架进化为软件能力成熟度模型(CapabilityMaturityModelForSoftware,简称SW-CMM),并发布了最早的SW-CMM1.0版。
经过两年的试用,1993年SEI正式发布了SW-CMM1.1版,这是目前使用最为广泛的版本。
按照SEI最初的计划,应该在1998年发表SW-CMM的2.0版。
由于软件过程评估(SPA)国际标准项目的进展,美国国防部下令暂时停止推进到SW-CMM的2.0版,以便吸收SPA的长处,于是便产生了CMMI。
CMMI-SE/SW1.0版作为系统工程和软件工程改进的一个集成模型,已于2000年8月11日公布。
CMMI-SE/SW1.0版是为希望改善工程和项目管理过程的产品开发组织而设计的。
这一模型由能力成熟度模型集成项目组完成,该项目组是由美国国防部秘书处下属的采办、技术和后勤办公室(OUSD/AT&L)以及国家防御工业协会联合负责的,并由政府、行业和软件工程学会共同参与。
该项目的目标是开发一个集成的产品套装,以支持行业和政府的过程和产品改进,该产品套装包括模型、评价方法和培训材料。
2000~2001年SEI陆续发表了《系统工程和软件工程综合能力成熟度模型》(CMMI-SE/SW)1.0版和CMMI-SE/SW1.1版以及《系统工程、软件工程和集成产品与过程开发的综合能力成熟度模型》(CMMI-SE/SW/IPPD)1.1版。
在发表CMMI-SE/SW1.0时,SEI宣布大约用两年的时间完成从CMM到CMMI的过渡。
3CMM及CMMI的主要区别是什么?
SEI认为合并后的模型(CMMI-SE/SW)与以前系统工程(CMM-SE)和软件工程(CMM-SW)分开的模型的主要区别在于:
在某些过程域中的推广将有特定的规范关注点。
因此,SEI认为发布合并的模型是更好的选择,可以采用一个模型从而使对规范的关注集中在推广上。
CMMI在2级新增加了度量和分析过程域;在3级新增加了风险管理、决策分析和决议过程域;CMMI还扩充了软件产品工程的部分;配置管理作为一个公共的实践适用于所有的过程域。
借助CMMI-SE/SW,现在使用不同模型对系统工程和软件工程单独进行改进的组织将能够用这样一个集成的模型对过程进行不断改进、培训和评价。
由于该模型能够将系统工程和软件工程集成在一起,这一CMMI模型的采用将支持企业级改进。
集成后的模型兼具了其源模型(软件能力成熟度模型SW-CMMSM2.0版草案C和EIA/IS-731系统工程能力模型SECM)的最优特性。
同时,该模型还让使用它的组织可以在以前基于SW-CMM或SE-CMM的投资基础上加以改进,并从集成模型的标准化和通用性中受益。
使用SE-CMMv1.1的组织应该有能力平稳地过渡到CMMI。
4基于CMMI的集成化过程改进策略
一、引言
在工程领域,组织的质量和生产率依赖于三个主要的因素:
过程、人员和技术。
在一些大型系统的开发领域,随着技术的不断进步和人们素质的提高,过程因素逐渐成为制约产品质量和生产效率的瓶颈。
因此,在开发组织中进行过程改进,进而增强其过程能力成为了开发组织必须要做的一项工作。
由美国卡迈基-梅隆大学的软件工程研究所(SEI)所推出的能力成熟度模型(CMM)的成功,导致了各种模型的衍生,并且每一种模型都探讨了某一特定领域中的过程改进问题。
但是,随着系统复杂性的不断增长,工程实践的执行越来越多地依赖于交叉学科群组、并行工程以及其他一些高度自动化的过程。
面向不同学科领域的过程改进模型已经不能很好地支持并行工程这种混合式的开发环境。
在这种情况下,产生了基于CMMI的集成化过程改进。
二、CMMI简介
CMMI的全称是CapabilityMaturityModelIntegration,即软件能力成熟度模型集成模型,是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的。
现在业界使用的CMMI最新模型是2002年发布的1.1版本系列,如CMMI-SE/SW/IPPD/SS,CMMI-SE/SW/IPPD,CMMI-SE/SW,CMMI-SW等。
CMMI是一套融合多学科的、可扩充的产品集合,其研制的初步动机是为了利用两个或者多个单一学科的模型实现一个组织的集成化过程改进。
在CMMI的初步研制中集成了三个特殊的过程改进模型:
软件(SW-CMM)、系统工程(EIA/IS731)以及集成化产品和过程开发(IPDCMM);从长期考虑,CMMI产品开发群组建立了一个自动的、可扩充的框架,以便于以后将其他一些学科的过程改进模型也逐步添加到CMMI产品集中。
CMMI模型中,最基本的概念是“过程域”。
与以前的一些过程改进模型一样,CMMI模型也只是选择对过程改进最重要的一些题目,并将其编组到“域”中。
在CMMI以前所推出的每一种单一学科过程改进模型中,都包含了一定数量的过程域(或者其他类似名称,如焦点域)。
随着各种学科之间的交叉,过程改进人员发现这些不同模型的过程域之间存在很多重复,在涉及多学科的过程改进中带来一些额外工作量,因此产生了将各种过程改进模型进行集成以减少过程域数量的想法。
这种想法的最早实现就是CMMI项目首先在软件和系统工程之间实现了较高的集成性,产生了一个公共的过程域集合。
随着研究的深入,过程域在不同学科之间的这种公共性越来越明显,因而在CMMI也就渐渐形成了这样一些非常具有通用性的工程过程域。
事实上,过程管理和项目管理可以应用于任何学科,因此,CMMI中的这些工程过程域在对不同学科应用时具有不同的实现。
总的来说,集成达到了两个目的:
一是提炼出了多学科之间的一些公共过程域,另一方面就是减少了过程域的总数量。
下面的表1列出了CMMI及其源模型的过程域数目。
表1:
CMMI模型及其源模型中的过程域数量
==========================
模型过程域数量
==========================
SW-CMM版本2(c)19
EIA/IS73119
IPD-CMM版本0.9823
CMMI-SE/SW/IPPD版本1.125
==========================
每一种CMMI模型是一个多达数百页的文档,文档中包含了不同类型的资料,也就是模型构件。
CMMI的模型构件主要有三类:
需要的(required),期望的(expected),以及提供信息的构件。
需要的构件只有一种,那就是“目标”。
目标表示某个过程域想要达到的最终状态,其实现则表示项目和过程控制已经达到了某种规定程度。
针对单一过程域的目标,称之为特定目标;可适用于所有过程域的目标则称为共性目标。
期望的构件也只有一种,就是“实践”。
实践代表了达到目标所“期望的”手段。
CMMI模型中每个实践都恰好映射到一个目标。
当然,只要能够实现模型中规定的目标,组织可以采用其他一些经过认证的手段作为“替代的”实践,而不一定非要采用模型中规定的实践。
因此,实践只是模型中期望的构件,而不是需要的构件。
同样,针对单一过程域的实践,称之为特定实践;可是用于所有过程域的实践则称为共性实践。
提供信息的构件有10种,分别是目的、介绍性说明、引用、名字、实践与目标关系表、注释、典型工作产品、子实践、学科扩充以及共性实践的详尽描述。
这些构件为需要构件和期望构件提供了有益的补充。
三、规范的选择
如同上面所说,CMMI是一套产品集合。
针对不同的学科有不同的规范和标准。
并且,每增加一种CMMI学科规范,组织在改进和评估中就要考虑更多的过程需求。
比如,原来的SW-CMM模型中描述了300多个实践或活动,而现在的CMMI-SW/SE版本1.1中却描述了400多个实践或活动,用这两种模型进行过程改进或评估所需要的工作量显然是不同的。
因此,一个组织要想利用CMMI进行过程改进,首先必须根据自身的主要业务类型,以及改进的目标等因素,在CMMI产品集合中选择适合于自身组织的规范。
组织在选择适合自身需要的CMMI产品规范时,主要应该考虑一下几方面因素的影响:
组织的核心业务类型
这一点对于规范的选择尤其重要。
虽然在一些大型项目中总会涉及到多学科、多领域的问题,但是对于组织中的核心业务来说,总是有一门或几门学科是特别重要的。
为了减少过程改进中的工作量,避免在改进中引入一些不必要的过程域,组织应该选择对业务成功至关重要的学科规范。
对于开发产品或服务的组织来说,其业务类型大致包括如下三种:
1、组织独立承担对某项新产品的全程开发和维护,开发过程不受外部因素影响。
以软件开发为例。
如果软件开发组织需要开发的是一个面向某一领域的软件系统,并且是独立开发,则首先考虑的规范就应该是CMMI-SW。
该规范中对于软件开发过程中需求的建立、项目计划的制定和实施,以及对软件的测试等过程都有详尽的描述。
不过,考虑到软件工程与系统工程两个学科之间的大量重复性,以及两者在全程质量管理上的统一性,一般推荐使用CMMI-SW/SE规范,因为CMMI项目在软件与系统工程之间已经进行了比较完美的集成,对于进行独立开发的软件组织来说,采用CMMI-SW/SE规范进行集成化过程改进,是在集成性和工作量二者之间进行折衷的最佳平衡点。
2、组织在开发产品或服务中需要集成他人创建的产品,或对产品的开发过程受到某些工程的影响。
实际上,随着系统复杂性的增长,组织所承接的大部分项目都是属于这种业务类型,这就涉及到开发过程中多学科的交叉以及并行工程等问题。
CMMI产品集中的CMMI-SE/SW/IPPD对这种类型的项目开发过程进行了详细描述。
一般来说,如果组织在项目开发中需要使用交叉学科群组,需要解决对项目群组的使用、计划和组织,需要解决学科或组之间的沟通以及与集成化产品和过程开发相关的一些问题,则可以考虑选择CMMI-SE/SW/IPPD版本1.1规范。
3、组织在开发过程中需要获取或转包某些关键构件。
这种业务类型主要涉及到对产品的获取和转包,也就是与产品供应商相关的一些问题。
CMMI-SE/SW/IPPD/SS版本1.1中对于供应商的选择和监督、集成化供应商管理以及供应商定量管理等方面给出了详尽描述,可以比较成功地解决这些问题。
组织开展项目的业务环境
组织开展项目的业务环境也是影响规范选择的一个重要因素。
在为过程改进选择规范时,主要应该考虑以下两种业务环境。
1、项目开发周期的时间长短及项目的稳定性。
如果组织所承接的是一个长期项目,具有稳定的工作环境和压力,那么可以考虑选择集成了多学科的过程改进规范。
因为,当组织面对一个长期、稳定的项目环境时,一般能够支持在一系列业务活动之上的集成化过程改进工作。
并且,由于项目的长期性为过程改进提供了充裕的时间,因而组织可以严格贯彻规范中所描述的过程域中的各项实践和活动,同时还可以从数据和经验积累中感觉到过程改进所带来的益处。
如果组织所面对的是一个快速发展的环境,所承接的项目是短期的、按进度驱动的工程,那么可以考虑只集中于一个特定的学科进行过程改进,甚至可以只选择某一学科规范中的少数过程域进行改进,这样可以在不影响项目进度的前提下,尽快得到过程改进投资的效益回报。
当然,从组织的长远发展来说,这种做法并不可取。
但是当一个组织在面对项目进度的压力时,也只能采取这种折衷的做法。
2、项目面对的客户基础。
在选择过程改进规范时,组织所面对的客户也是一个不容忽视的因素。
如果组织承接的是对复杂系统有一些关键需求的大型项目,例如国防、航天等项目,则客户往往就会要求组织采用有把握的学科规范来匹配系统开发过程。
集成化过程改进的范围和目的
在选择合适的规范之前,首先应该了解所需改善的过程种类和过程改进的目的。
如果组织的目的完全是为了进行内部过程改进,那么在选择规范方面可以有很大的余地。
针对组织中涉及的项目种类和业务类型,只要有助于组织开发过程的定义、改进的学科规范都可以选择。
但是,如果组织进行过程改进是为了认证或定级,以扩大组织的商业影响力,那么就应该有针对性地选择某一特定学科的规范,在过程改进过程中也就要注意对规范实施的严格性和全面性。
四、选择合适的表示法
每一种CMMI模型都有两种表示法:
阶段式和连续式。
这是因为在CMMI的三个源模型中,CMM是“阶段式”模型,系统工程能力模型是“连续式”模型,而集成产品开发(IPD)CMM是一个混合模型,组合了阶段式和连续式两者的特点。
两种表示法在以前的使用中各有优势,都有很多支持者,因此,CMMI产品开发群组在集成这三种模型时,为了避免由于淘汰其中任何一种表示法而失去对CMMI支持的风险,并没有选择单一的结构表示法,而是为每一个CMMI都推出了两种不同表示法的版本。
不同表示法的模型具有不同的结构。
连续式表示法强调的是单个过程域的能力,从过程域的角度考察基线和度量结果的改善,其关键术语是“能力”;而阶段式表示法强调的是组织的成熟度,从过程域集合的角度考察整个组织的过程成熟度阶段,其关键术语是“成熟度”。
尽管两种表示法的模型在结构上有所不同,但CMMI产品开发群组仍然尽最大努力确保了两者在逻辑上的一致性,二者的需要构件和期望部件基本上都是一样的。
过程域、目标在两种表法中都一样,特定实践和共性实践在两种表示法中也不存在根本区别。
因此,模型的两种表示法并不存在本质上的不同。
组织在进行集成化过程改进时,可以从实用角度出发选择某一种偏爱的表示法,而不必从哲学角度考虑两种表法之间的差异。
从实用角度讲,两种表示法各有优点。
阶段式表示法
软件CMM是一种阶段式模型,该模型经过多年的成功使用已经被证明是有效的,这为选择阶段式表示法模型提供了最强有力的证据。
考虑从不成熟组织向成熟组织的发展过程,阶段式表示法具有如下两方面优势:
1、阶段式模型为支持组织的过程改进提供了一个过程平台。
对于着眼于改善过程成熟度的组织来说,阶段式模型提供了一种明确的、行之有效的跨越式发展途径。
阶段式模型中所描述的组织的5个成熟度等级中,每实现一次等级间的跨越,组织就致力于解决某一方面的问题。
例如,组织从成熟度等级1到成熟度等级2,主要致力于有助于改善项目管理的过程域;从成熟度等级2到成熟度等级3,提供了广泛的组织过程定义;从成熟度等级3到成熟度等级4,致力于对过程定量管理的过程域;从等级4到等级5,致力于过程的改进和优化。
通过这种方式,阶段式模型确定了组织进行过程改进的最佳次序,如图1。
图1:
模型的阶段式表示法
2、阶段式模型可以为组织定义一个过程成熟度等级,便于进行跨组织的比较。
在阶段式模型中,每一个过程域都被指定归属到一个成熟度等级中,因此,基于阶段式模型为组织所定义的成熟度等级中,过程域的预期范围和应用将变得非常清晰。
这样,在对不同的组织进行比较时,只要对比组织所达到的不同的成熟度等级,即可知道不同组织在执行过程域方面所存在的差别。
连续式表示法
相比之下,连续式模型不如阶段式模型常用,但也不乏支持者,特别是在系统工程师中。
采用连续式模型主要有如下两方面的优势:
首先,连续式模型为用户进行过程改进提供了比较大的自由度。
如同上面所说,阶段式模型确定了组织进行过程改进的最佳次序,但同时也限定了用户在进行过程改进时必须遵循单一的改善路径。
而连续式模型则允许用户根据组织的业务目的来选择过程改进活动的次序。
在连
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- cmmi2