威海经济技术开发区服务外包公共服务平台
当前位置:主页>CMMI

CMMI

CMMI 
 
CMMI全称是Capability Maturity Model Integration,即软件能力成熟度模型集成(也有称为:软件能力成熟度集成模型),是美国国防部的一个设想,1994年由美国国防部(United States Department of Defense)与卡内基-梅隆大学(Carnegie-Mellon University)下的软件工程研究中心(Software Engineering Institute,SEISM)以及美国国防工业协会(National Defense Industrial Association)共同开发和研制的,他们计划把现在所有现存实施的与即将被发展出来的各种能力成熟度模型,集成到一个框架中去,申请此认证的前提条件是该企业具有有效的软件企业认定证书。
 
其目的是帮助软件企业对软件工程过程进行管理和改进,增强开发与改进能力,从而能按时地、不超预算地开发出高质量的软件。其所依据的想法是:只要集中精力持续努力去建立有效的软件工程过程的基础结构,不断进行管理的实践和过程的改进,就可以克服软件开发中的困难。CMMI为改进一个组织的各种过程提供了一个单一的集成化框架,新的集成模型框架消除了各个模型的不一致性,减少了模型间的重复,增加透明度和理解,建立了一个自动的、可扩展的框架。因而能够从总体上改进组织的质量和效率。CMMI主要关注点就是成本效益、明确重点、过程集中和灵活性四个方面。
 
版本介绍
 
CMMI是一套融合多学科的、可扩充的产品集合, 其研制的初步动机是为了利用两个或多个单一学科的模型实现一个组织的集成化过程改进。CMMI的本质是软件管理工程的一个部分。软件过程改善是当前软件管理工程的核心问题, 50多年来计算机的发展使人们认识到要高效率、高质量和低成本地开发软件,必须改善软件生产过程。基于模型的过程改进是指采用能力模型来指导组织的过程改进,使之过程能力稳定的进行改善,该组织也能变得更加成熟。
 
CMMI的成功促使其他学科也相继开发类似的过程改进模型,例如系统工程、需求工程、人力资源、集成产品开发、软件采购等等,从CMM衍生出了一些改善模型,比如:SW-CMM,SE-CMM,IPD-CMM等。不过,在同一个组织中多个过程改进模型的存在可能会引起冲突和混淆。CMMI就是为了解决怎么保持这些模式之间的协调。
 
CMMI 1.3是2010年11月SEI 发布的CMMI模型的最新版本。CMMI 1.3包括CMMI采购模型1.3版、CMMI开发模型1.3版、CMMI服务模型1.3版。
 
CMMI开发模型1.3版(CMMI-DEV 1.3)与CMMI开发模型1.2版相比,做了如下改进:
 
1)将过程域"组织级创新与部署"(Organizational Innovation and Deployment,OID)更名为"组织绩效管理"(Organizational Performance Management, OPM),并增加了一个新的特定目标与几个新的特定实践。
 
2)对模型架构进行了改进,简化对多个模型的使用。
 
过程域
 
Process Area:过程域。简单的说就是做好一个事情的某一个方面,对应软件开发来说,就是做好软件开发的某一个方面。
 
2、3级共有18个过程域(PA),主要内容如下,分四大类:
 
过程管理
 
1. OPD:(Organizational Process Definition)组织级过程定义。建立和维护有用的组织过程资产。
 
2. OPF:(Organizational Process Focus)组织级过程焦点。在理解现有过程强项和弱项的基础上计划和实施组织过程改善。
 
3. OT:(Organizational Training)组织培训管理。增加组织各级人员的技能和知识,使他们能有效地执行他们的任务。
 
项目管理
 
4. PP:(Project Plan)项目计划。保证在正确的时间有正确的资源可用。为每个人员分配任务。协调人员。根据实际情况,调整项目。
 
5. PMC:(Project Monitoring and Control)项目监督与控制。通过项目的跟踪与监控活动,及时反映项目的进度、费用、风险、规模、关键计算机资源及工作量等情况,通过对跟踪结果的分析,依据跟踪与监控策略采取有效的行动,使项目组能在既定的时间、费用、质量要求等情况下完成项目。
 
6.SAM:(Supplier Agreement Management)供应商协议管理。旨在对以正式协定的形式从项目之外的供方采办的产品和服务实施管理。
 
7.IPM:(Integrated Project Management)集成项目管理。根据从组织标准过程剪裁而来的集成的、定义的过程对项目和利益相关者的介入进行管理。
 
8. RSKM:(Risk Management)风险管理。识别潜在的问题,以便策划应对风险的活动和必要时在整个项目生存周期中实施这些活动,缓解不利的影响,实现目标。
 
工程管理
 
9.RD:(Requirement Development)需求开发。需求开发的目的在于定义系统的边界和功能、非功能需求,以便涉众(客户、最终用户)和项目组对所开发的内容达成一致。
 
10.REQM(Requirement Management)需求管理。需求管理的目的是在客户和软件项目之间就需要满足的需求建立和 维护一致的约定。
 
11.TS:(Technical Solution)技术解决方案。在开发。设计和实现满足需求的解决方案。解决方案的设计和实现等都围绕产品、产品组件和与过程有关的产品。
 
12.PI:(Product Integration)产品集成。从产品部件组装产品,确保集成产品功能正确并交付产品。
 
13.VAL:(Validation)确认。确认证明产品或产品部件在实际应用下满足应用要求。
 
14.VER:(Verification)验证。验证确保选定的工作产品满足需求规格。
 
支持管理
 
15. CM:(Configuration Management)配置管理。建立和维护在项目的整个软件生存周期中软件项目产品的完整性 。
 
16.PPQA:(Process and Product Quality Assurance)过程和产品质量保证。为项目组和管理层提供项目过程和相关工作产品的客观信息。
 
17.MA:(Measurement and Analysis)测量与分析。开发和维持度量的能力,以便支持对管理信息的需要。作为改进、了解、控制决策。
 
18. DAR:(Decision Analysis and Resolution)决策分析与解决。应用正式的评估过程依据指标评估候选方案,在此基础上进行决策。
 
第4级除第2、3级所涵盖的18个流程领域外,增加
 
19. OPP :(Organizational Process Performance)组织过程性能。建立与维护组织过程性能的量化标准,以便使用量化方式的管理项目。
 
20. QPM(Quantitative Project Management) 量化的项目管理,量化管理项目已定义的项目过程,以达成项目既定的质量和过程性能目标。。
 
第5级包含第2级到第4级的20个流程领域外,增加,
 
21. OID:(Organizational Innovation and Deployment)组织的创新与推展,选择并推展渐进创新的组织过程和技术改善,改善应是可度量的,所选择及推展的改善需支持基于组织业务目的的质量及过程执行目标。
 
22. CAR:(Causal Analysis and Resolution),识别缺失的原因并进行矫正进一步的防止未来再次发生。
 
其他术语:
 
Life Cycle:(Software Life Cycle Model)项目管理的生命周期。关注的是项目的过程管理。
 
MA:(Measurement & Analysis)。开发并持续发展度量能力以满足项目管理的信息需求。
 
Milestone Review:(Milestone Review)阶段评审。在阶段结束时评审项目的状态并确定项目是否应该进入下一阶段。
 
Process Tailoring:(Process Tailoring)过程裁剪。为了使组织定义的标准过程能够适合于组织项目管理,不论该项目是提供产品还是服务。
 
Review:(Review)评审。可以有效提高系统,软件及产品的质量。
 
Testing:软件测试。
 
发展历史
 
CMMI的起源
 
随着人们对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版本。
 
发展简介
 
自从1994 年SEI正式发布软件CMM以来,相继又开发出了系统工程、软件采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度模型。虽然这些模型在许多组织都得到了良好的应用,但对于一些大型软件企业来说,可能会出现需要同时采用多种模型来改进自己多方面过程能力的情况。这时他们就会发现存在一些问题,其中主要问题体现在:
 
n 不能集中其不同过程改进的能力以取得更大成绩;
 
n 要进行一些重复的培训、评估和改进活动,因而增加了许多成本;
 
n 遇到不同模型中有一些对相同事物说法不一致,或活动不协调,甚至相抵触。 于是,希望整合不同CMM 模型的需求产生了。1997 年,美国联邦航空管理局(FAA)开发了FAA-iCMMSM(联邦航空管理局的集成CMM),该模型集成了适用于系统工程的SE-CMM、软件获取的SA-CMM 和软件的SW-CMM 三个模型中的所有原则、概念和实践。该模型被认为是第一个集成化的模型。CMM与CMMI最大的不同点和区别: CMMISM-SE/SW/IPPD/SS 1.1 版本有四个集成成分,即:系统工程(SE)和软件工程(SW)是基本的科目,对于有些组织还可以应用集成产品和过程开发方面(IPPD)的内容,如果涉及到供应商外包管理可以相应的应用SS(Supplier Sourcing)部分。
 
CMMI有两种表示方法,一种是大家很熟悉的,和软件CMM 一样的阶段式表现方法,另一种是连续式的表现方法。这两种表现方法的区别是:阶段式表现方法仍然把CMMI中的若干个过程区域分成了5 个成熟度级别,帮助实施CMMI的组织建议一条比较容易实现的过程改进发展道路。而连续式表现方法则通过将CMMI中过程区域分为四大类:过程管理、项目管理、工程以及支持。对于每个大类中的过程区域,又进一步分为基本的和高级的。这样,在按照连续式表示方法实施CMMI的时候,一个组织可以把项目管理或者其他某类的实践一直做到最好,而其他方面的过程区域可以完全不必考虑。
 
研发背景
 
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)人力资源能力成熟度模型
 
美国国防部办公室要求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自出道以来,它所达到的目标就没有变过,第一个是质量,第二个是时间表,第三就是要用最低的成本。不过特别强调的是,CMMI不是传统的、仅局限于软件开发的生命周期,它应该被运用于更广泛的一个范畴--工程设计的生命周期。TSP的建立,也是为了支持CMMI的这样一个系统。那么CMMI究竟是什么呢?它并不是一个过程,也不是告诉你怎么去做一件事情。如果用一句话来概括什么是CMMI,它就是各个进程的一个关键的元素,在很多领域里面一个集成的点。它是这样的一个基本架构,能够用来度量你的有效性和实用性;能够找出这样的一些机会,继续改进的机会,包括在商业目标、策略还有降低项目的风险等方面。
 
评估
 
预备工作
 
评估实践证明:在进行CMMI评估之前,制定一个正确的评估计划并将其文档化,确保有一个富有经验的、受过培训且具有适当资格的小组能被用来评估,为执行评估过程做准备,是十分必要的。
 
我们所说的文档化CMMI评估计划的结果,包括:要求,协定,估价,风险,剪裁方法,以及与评估相关的实际考虑(例如:日程安排,后勤,组织的背景信息)。此外,还应当获取并记录发起方对于CMMI评估计划的正式批准。在制定评估计划之前,应对CMMI评估输入中反映出来的协议文档化,该协议将有助于CMMI评估目标和关键评估计划参数的共同理解。在对驱动计划过程的关键参数达成共同理解的基础上,CMMI评估发起方和SCAMPI主任评估师应就评估计划达成一致;发起者和评估小组领导应就已计划的评估中技术和非技术细节达成一致。这个计划在执行其他的计划和准备阶段活动中需要进一步细化。
 
而通过CMMI评估小组的准备工作,将产生一支富有经验的、受过培训的且定位准确的小组准备执行CMMI评估任务。该小组的成员都应当获得了完成他们各自的任务所必备的知识,或者他们之前所拥有的知识被证实足以完成相关任务。评估小组领导者已经给每一个人提供了为完成他们各自的任务所需的对技能进行实践的机会,或者证实这些技能在过去已经得到了示范。小组成员相互了解,同时开始计划他们如何协调一致的工作。还应该做到:准备好的小组是为评估目标而服务的,小组的成员已提供培训且培训结果被记录,在必要的时候,对他们所做的因知识或技能不足的补救工作已经完成。我们认为,无论CMMI评估小组领导者是从头培训一支全新的评估小组,还是通过从富有经验的小组成员中选择来组建一个小组,确保他们与CMMI评估小组领导者能组成一个成功的集体是其责任。此外,在对CMMI评估进行的预备工作的过程中,我们还应当对模型剪裁的原则有所了解:
 
1.在某些应用中,计划模板和例行的程序能够根据评估的需要进行调整,这和当地的过程所有权一样,有助于交流;
 
2.一个结构化的计划工艺组有利于只有有限的评估经验的组织,这样一个工艺就像缓和策略样,对于发现风险是一个很有价值的机会;
 
3.案例研究材料提供了各种各样的选择来扩充小组培训内容以增强那些更需要培训的重点;
 
4.富有经验的评估小组领导者在没有案例分析的情况下,同样可以管理和模拟评估行为;
 
5.在小组所有已获得培训成员的集合中,对小组的建立工作进行管理以确保其团队凝聚力是十分重要的,因此,很多的小组建立练习是可以利用的,小组的规模、技能、组成部分都是本方法的裁剪内容;
 
6.所采用工具可以包括评估计划模板,样例,和计划模板中嵌入式的程序上的帮助,此外,为了估计评估约束的影响,估算工作表和方法也是很有用处的。
 
总之,CMMI评估是一个十分复杂的过程,更由于其具有的不确定性,在评估的实践中,一定要做到有备无患。真理来自于实践,我们相信,随着越来越多的软件组织着手CMMI评估,越来越多的成功经验将为我们所利用和借鉴。
 
评估方法
 
SEI将CMMI的评估过程分为Class A、B 、C三种类型:
 
Class A类评估:是正式的标准过程,目的是获得评估等级,评估过程需执行所有的评估步骤 ,在CMMI标准中需要满足ARC要求 ( Appraisal Requirement for CMMI ) ,需要组建正式评估小组,并需要SEI授权的主任评估师领导评估组进行评估。根据被评估的CMMI的不同级别,评估组人数通常为4-9人,评估天数为5-10天,被评估企业派人参加ATM。评估方式为文件审查和人员访谈,评估输出物为最终评估报告,并由主任评估师向SEI注册评估结果。具体评估过程详细描述参见SCAMPI ( Standard CMMI Appraisal Method for Process Improvement) "标准的CMMI评估方法"。企业做CMMI评估并向SEI注册,都是采用本类评估。
 
Class B类评估:只需要满足部分的ARC要求,并可以只收集更少的信息,但必须包括从访谈方式获得的信息,不需要最终产生组织的成熟度级别,评估组的负责人既可以是SEI授权主任评估师,也可以由组织内部有经验的成员担当,可以认为是组织内部的评估过程,可以在过程改进过程中的诊断过程中使用,也可以在组织发展过程中进行阶段性评估审计时使用。
 
Class C类评估:是一种非正式评估过程,满足更少的ARC要求,组织快速浏览过程,只确定相对较少过程域,不需要SEI授权评估师给出组织成熟度级别。一般是针对特定少数或一个项目,或针对少数过程、或一个过程在组织中执行的情况进行评估,通常是在组织发展过程中进行。
 
自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 连续式描述
 
阶段式描述:阶段式表述提供系统化与结构化的方式,一次一个阶段达到以模型为基础的过程改进。达成每一个阶段可确保有足够的过程基础建设,可作为下一个阶段过程改进的基础。过程域是以成熟度等级组织,并且对过程改进做一些推测工作。阶段式表述根据成熟度等级规定执行过程改进的顺序,它定义一个组织由初始级到已优化级的改进路径。达到每一个成熟度等级可确保有足够的过程基础建设,可作为下一个成熟度等级的基础,并且允许持续与渐进的改进。假如你不知道要选择哪一个过程开始进行改进,阶段式表述对你而言是一个好的选择。它给你一组特定的过程,针对每一个阶段进行改进。这组过程的决定,是来自于十多年过程改进的研究和经验。
 
连续式描述:当使用CMMI 模型进行过程改进时,连续式表述可提供最大的弹性。一个组织可以选择改进单一过程相关的问题点的绩效,或是可以使用多个领域以密切配合组织的经营目标。连续式表述也允许一个组织将不同的过程改进至不同的等级。但组织在选择上仍有一些限制,因为有一些过程域是彼此相依的。假如你知道在你的组织中需要改进的过程,以及了解CMMI 中过程域间的相依性。对你的组织而言,连续式表述是一个好的选择。
 
系统工程 or 软件工程 or 两者皆有
 
使用连续式描述可以根据企业需要选择流程改进顺序,降低企业风险,这给通过ISO做流程改进提供了一个方便的比较。使用能力度(Capability)来衡量。
 
阶段式描述提供了已经过验证的流程改进顺序,方便从CMM移植过来。使用成熟度(Maturity)来衡量流程改进。
 
系统工程包括整个系统的开发,可能包括软件也可能不包括。
 
软件工程用于软件系统的开发,主要集中在使用系统的·科学的·量化的方法来开发·运行·维护软件。
 
项目管理
 
由美国卡内基梅隆大学的软件工程研究所(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 最优化级
 
实施要点
 
基本思想
 
1、解决软件项目过程改进难度增大问题
 
2、实现软件工程的并行与多学科组合
 
3、实现过程改进的最佳效益
 
源模型
 
软件能力成熟度模型2.0版,C稿;电子行业协会临时标准(EIA/IS)731;集成产品开发能力成熟度模型(IPD-CMM)v0.98。
 
原则
 
(1)、强调高层管理者的支持。过程改进往往也是由高层管理者认识和提出的,大力度的、一致的支持是过程改进的关键。
 
(2)、 仔细确定改进目标,首先应该对给定时间内的所能完成的改进目标进行正确的估计和定义并制定计划。选择能够达到的目标和能够看到对组织的效益。
 
(3)、 选择最佳实践,应该基于组织现有的软件活动和过程财富,参考其他标准模型,取其精华去其糟粕,得到新的实践活动模型。
 
(4)、 过程改进要与组织的商务目标一致,与发展战略紧密结合。
 
目标
 
综述
 
(1)为提高组织过程和管理产品开发、发布和维护的能力提供保障。
 
(2)帮助组织客观评价自身能力成熟度和过程域能力,为过程改进建立优先级以及执行过程改进。
 
初步目标
 
CMMI项目初步的目标(在2000年已达到,其发布的版本是CMMI-SE/SW和CMMI-SE/SW/IPPD模型)是集成三个特殊的过程改进模型:软件CMM、系统工程能力评估标准以及集成化产品和过程开发模型。
 
这项集成的目的是通过一种手段减少实现基于多学科模型的过程改进成本。
 
长期目标
 
CMMI项目长期的目标是为今后把其他学科(如获取过程和安全性)添加到CMMI中奠定基础。为了促进模型集成,CMMI产品开发组建立了一个自动的、可扩展的框架,其中可放入构件、培训资料构件以及评估资料。在已定义的规则控制下,更多的新学科能被加入到该框架中。
 
方法
 
(1)、决定哪个CMMI模型等级最适合组织过程改进需要。
 
(2)、 选择模型的表示法是连续式还是阶段式。
 
(3)、 决定组织需要用到的模型中的知识领域。
 
(4)、 类似CMM提出的过程改进6步,集成化过程改进分成:开始集成过程改进,建造集成改善平台,集成传统过程,启动新过程,进行改进评估。
 
内容
 
CMMI内容分为"Required"(必需的)、"Expected"(期望的)、"Informative"(提供信息的)三个级别,来衡量模型包括的质量重要性和作用。最重要的是"要求"级别,是模型和过程改进的基础。第二级别"期望"在过程改进中起到主要作用,但是某些情况不是必须的可能不会出现在成功的组织模型中。 "提供的信息"构成了模型的主要部分,为过程改进提供了有用的指导,在许多情况下他们对"必需"和"期望"的构件做了进一步说明。
 
"必需"的模型构件是目标,代表了过程改进想要达到的最终状态,它的实现表示了项目和过程控制已经达到了某种水平。当一个目标对应一个关键过程域,就称为"特定目标";对应整个关键过程域就称为"公用目标"。整个CMMI模型包括了54个特定目标,每个关键过程域都对应了一到四个特定目标。每个目标的描述都是非常简捷的,为了充分理解要求的目标就是扩展"期望"的构件。
 
"期望"的构件是方法,代表了达到目标的实践手段和补充认识。每个方法都能映射到一个目标上,当一个方法对一个目标是唯一就是"特定方法";而能适用于所有目标时就是"公用方法"。CMMI模型包括了186个特定方法,每个目标有两到七个方法对应。
 
CMMI包括了10种"提供的信息":目的,概括和总结了关键过程域的特定目标;介绍说明,介绍关键过程域的范围、性质和实际方法和影响等特征;引用,关键过程域之间的指向是通过引用;名字,表示了关键过程域的构件;方法和目标关系,关键过程域中方法映射到目标的关系表;注释,注释关键过程域的其他模型构件的信息来源;典型工作产品集,定义关键过程域中执行方法时候产生的工作产品;子方法,通过方法活动的分解和详细描述;学科扩充,CMMI对应学科是独立的,这里提供了对应特定学科的扩展;公用方法的详细描述,关键过程域中公用方法应用实践的详细描述。
 
CMMI提供了阶段式和连续式两种表示方法,但是这两种表示法在逻辑上是等价的。我们熟悉的SW-CMM软件能力成熟模型就是是阶段式的模型,SE-CMM系统工程模型是连续式模型,而IPD-CMM集成产品开发模型结合了阶段式和连续式两者的特点。
 
阶段式方法将模型表示为一系列"成熟度等级"阶段,每个阶段都有一组KPA指出一个组织应集中于何处以改善其组织过程,每个KPA用满足其目标的方法来描述,过程改进通过在一个特定的成熟度等级中满足所有KPA的目标而实现的。
 
连续式模型没有像阶段式那样的分散阶段,模型的KPA中的方法是当KPA的外部形式,并可应用于所有的KPA中,通过实现公用方法来改进过程。它不专门指出目标,而是强调方法。组织可以根据自身情况适当裁剪连续模型并以确定的KPA为改进目标。
 
两种表示法的差异反应了为每个能力和成熟度等级描述过程而使用的方法,他们虽然描述的机制可能不同,但是两种表示方法通过采用公用的目标和方法作为"必需"的和"期望"的模型元素,而达到了相同的改善目的。
 
CMMI面临的一个挑战就是创建一个单一的模型,可以从连续和阶段两个角度进行观察,包含相同的过程改进基本信息;处理相同范围的一个CMMI过程能够产生相同的结论。统一的CMMI(U-CMMI)是指产生一个只有公用方法和支持他们的KPA组成的模型。当按一种概念性的可伸展的方式编写,并产生了用于定义组织的特定目标过程模版,定义的模版构件将定义一个模型以适用于任何工程或其他方面。
 
工具
 
组织在实践CMMI过程中,提升和改进研发管理能力的同时,也面临着辅助过程改进工具的挑战,缺少工具支撑,CMMI的规程、流程,尤其量化数据分析的推行成本非常高,往往使很多组织望而生畏;实践证明能够很好支撑CMMI落地的工具有:微软Project Server、IBM Rational系列工具、青铜器RDM研发管理系统、Techexcel DevSuite。CMMI工具至少要满足如下特点:
 
1. 以项目运作为主线条,至少包含计划进度管理、工时管理、文档管理、变更管理、风险问题管理、量化管理。
 
2. 强大的流程自定义能力,能够支撑不同组织根据自己的要求自定义相应的流程。
 
3. 量化数据收集与分析能力,能够自定义项目质量目标,根据项目质量数据自动汇总组织的能力基线;同时要有智能报表能力。
 
4. 知识管理能力,尤其要实现情境化知识管理,能够将项目历史实际数据直接作为知识进行分享、重用,知识管理要与操作人的行为关联。
 
5. 工程技术要全覆盖,至少要涵盖需求分析与需求管理、测试管理(测试计划、测试用例、测试执行)、需求跟踪管理、文档管理、评审与验证管理。
 
人员素质
 
1、明白什么是有价值的积累,先是对你个人,然后才是顺便帮公司做了积累。
 
2、深入一线,发现她们并忠实地记录它们。CMMI里的SP、GP,只是帮助你,提醒你在哪个环节,哪些东西可能是有价值了。你去收集一下,别视而不见了。因为还有一个企业和你个人的角度不同,立场不同的问题。例如,REQM里收集需求,对个人技术方面的积累虽然不多,但对企业是至关重要的,一次需求变更,没详细写清楚,忘记了到客户那里去签字落实,可能就会给企业造成很大的损失。做为一个合格的EPG,是需要有这份责任和义务把每个环节都做到最好,这是职业道德所在。同时也是对自我延伸的一个好机会,学会一些和人的沟通,倾听,把专业的东西以平易的方式表达。这些也都算是EPG额外的收获。
 
通常情况下,为了按时按量完成项目,一线的骨干,对写日报、周报、文档都很不屑。EPG也很迁就,事后再补,这也不失为一个提高效率的好办法。但过去一个月半年了,我们正常人的记忆都能想象,很难记住细节。无非就是敷衍。这也在情理之中。你总不能让一个明天就要交东西的小组,今天晚上在通宵努力解决BUG的同时,还写什么报告,这也不尽人情。但作为EPG不能只把眼光集中在这妇人之心上。要想的更远。为什么会把项目推到这么晚,BUG还没解决完?难道要永远这样下去吗?项目中是有很多不可预测的因素,甚至是开发人员常说的"手气问题","人品问题"。但这些是需要控制的,也是通过经验可以控制的,所谓艺高人胆大。艺的高低,就是经验的积累决定的。
 
那怎么解决这种两难的问题呢?逼着技术骨干写心得,人家没时间也的确压力很大。不写,公司又得不到有效积累,积累的都是垃圾流水。有个公司的办法和经验到可以借鉴一下:
 
公司内部搞了个BBS,把不同类型的工作分成不同的组,有纯技术的,JAVA组,C++组等,也有PPT组,甚至动画组,界面组。大家把自己平时的工作积累FTP上去,甚至制作方法,遇到问题和解决方法的文档都丢上去,开始怎么想,用了多少套方案,最后选择了什么。自我感觉如何。把这些心路历程都写成文档。丢到阳光下,大家评论。用点击率和"顶"的人数来说明谁写的是心得,谁在写垃圾。大家都是一个公司的,很容易实名。直接纳入考核机制中。做为一线人员,大家也有动力来写,自己的聪明才智有了展现的平台,虚荣心和荷包都得到了相应的满足。何乐而不为呢?
 
EPG适时的评估大家的成果,并把他们分到项目里。帮助项目总结,甚至在平时遇到问题时,直接帮助技术人员做必要记录。项目进度松时,再督促项目人员完善内容。以达到对个人和公司积累的最大化。
 
EPG应该明白学习和积累是个终身的过程,对公司如此,对个人也是如此。CMMI是个辅助,辅助我们对公司做积累,也帮助我们个人做必要的积累。公司需要逐步走向更高的管理水平,发展平台。
 
友情链接
首页 | 综合服务平台 | 创客平台 | 交易平台 | 培训平台 | 认证平台
  • 版权所有:山东省国际服务外包示范基地(威海经济技术开发区) 技术支持:山东曼威软件有限公司
    技术支持电话:0631-5776111 鲁ICP备13022990号-1