cmmi五个成熟度级别

CMMI 等级的含义 五个成熟度级别之间的比较如下: 1,初始级 特征: (1)软件过程的特点是杂乱无章,有时甚至混乱.几乎没有定义过程的规则或步 骤. (2)过分的尽诺.常做出良好的承诺:如"按照软件工程方式,有序的工程过程来 工作";或达到高目标的许诺.但实际上却出现一系列危机. (3)遇到危机就放弃原 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 过程,反复编码和测试. (4)成功完全依赖个人努力和杰出的专业人才,取决于超常的管理人员和杰出有效 的软件开发人员.具体的表现和成果都源于或者说是决定于个人的能力和他们先前的 经验,知识以及他们的进取心和积极程度. (5)能力只是个人的特性,而不是开发组织的持性.依靠着个人的品质或承受着巨 大压力,或找窍门取得成果.但此类人一旦离去,对组织的稳定作用也消失. (6)软件过程是不可确定的和不可预见的.软件成熟性程度处于第一级的软件组织 的软件过程在实际的工作过程中被经常的改变(过程是随意的).这类组织也在开发产 品,但其成果是不稳定的,不可预见的,不可重复的.也就是说,软件的计划,预 算,功能 和产品的质量都是不可确定和不可预见的. 过程: (1)极少存在或使用稳定的过程. (2)所谓"过程",往往是"就这么干"而言. (3)各种条例,规章制度互不协调,甚至互相矛盾 人员: (1)依赖个人努力和杰出人物.一旦优秀人物离去,项目就无法继续 (2)人们的工作方式如同"救火".就是在开发过程中不断地出现危机,以及不断 的"救火". 技术: 引进新技术是极大风险 度量: 不收集数据或分析数据 改进方向: (1)建立项日管理过程.实施规范化管理.保障项目的承诺. (2)首要任务是进行需求管理,建立客户与软件项目之间的共同理解,使项目真正 反映客户的要求. (3)建立各种软件项目计划.如软件开发计划,软件质量保证计划,软件配置管 理计划,软件测试计划,风险管理计划及过程改进计划. (4)开展软件质量保证活动(SQA). 2,可重复级 特征 (1)进行较为现实的求诺,可按以前在同类项目上的成功经验建立的必要过程准则 来确保再一次的成功. (2)主要是逐个项目地建立基本过程管理条例来加强过程能力. (3)建立了基本的项目管理过程来跟踪成本,进度和功能. (4)管理工作主要跟踪软件经费支出,进度及功能.识别在承诺方面出现的问题. (5)采用基线(BASELINE)来标志进展,控制完整性. (6)定义了软件项目的 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 ,并相信它,遵循它. (7)通过于 合同 劳动合同范本免费下载装修合同范本免费下载租赁合同免费下载房屋买卖合同下载劳务合同范本下载 建立有效的供求关系. 过程 (1)软件开发和维护的过程是相对稳定的,但过程建立在项目一级. (2)有规则的软件过程是在一个有效的工程管理系统的控制之下,先前的成功经验 可以被重复. (3)问题出现时.有能力识别及纠正.其承诺是可实现的. 人员 (1)项目的成功依赖于个人的能力以及管理层的支持. (2)理解管理的必要性及对管理的承诺. (3)注意人员的培训问题, 技术 建立技术支持活动,并有稳定的计划. 度量 每个项目建立资源计划.主要是关心成本,产品和进度.有相应的管理数据. 改进方向 (1)不再按项目制定软件过程,而是总结各种项目的成功经验,使之规则化,把具 体经验归纳为全组织的标准软件过程.把改进组织的整体软件过程能力的软件过程活 动,作为软件开发组织的责任. (2)确定全组织的标准软件过程,把软件工程及管理活动集成到一个稳固确定的软 件过程中.从而可以跨项目改进软件过程效果,也可作为软件过程剪裁的基础. (3)建立软件工程过程小组(SEPG)长期承担评估与调控软件过程的任务,以适应未 来软件项目的要求. (4)积累数据:建立组织的软件过程库及软件过程相关的文档库 (5)加强培训. 3,确定级 特征 ： (1)无论管理方面或工程方面的软件过程都已文件化,标准化,并综合成软件开发 组织的标准软件过程. (2)软件过程标准被应用到所有的工程中,用于编制和维护软件.有的项目也可根 据实际情况,对软件开发组织的标准软件过程进行剪裁. (3)在从事一项工程时,产品的生产过程,花费,计划以及功能都是可以完全控制 的,从而软件质量也可以控制. (4)软件工程过程组(SEPG)负责软件过程活动. (5)在全组织范围内安排培训计划. 过程： (1)整个组织全面采用综合性的管理及工程过程来管理.软件工程和管理活动是稳 定的和可重复的,具有连续性的. (2)软件过程起了预见及防范问题的作用,能使风险的影响最小化 人员： (1)以项目组的方式进行工作.如同综合产品团队. (2)在整个组织内部的所有人对于所定义的软件过程的活动,任务有深入理解.大 大加强了过程能力. (3)有计划地按人员的角色进行培训 技术 在定性基础上建立新的评估技术. 度量： (1)在全过程中收集使用数据. (2)在全项目中系统性地共享数据 改进方向 (1)开始着手软件过程的定量分析,以达到定量地控制软件项目过程的效果. (2)通过软件的质量管理达到软件的质量目标. 4,管理级 特征 ： (1)制定了软件过程和产品质量的详细而具体的度量标准.软件过程和产品的质量 都可以被理解和控制. (2)软件组织的能力是可预见的.原因是软件过程是被明确的度量标准所度量和操 作.不言而喻.软件产品的质量就可以预见和得以控制. (3)组织的度量工程保证所有项目对生产率和质量进行度量,并作为重要的软件过 程活功. (4)具有良好定义及一致的度量标服来指导软件过程,并作为 评价 LEC评价法下载LEC评价法下载评价量规免费下载学院评价表文档下载学院评价表文档下载 软件过程及产品 的定量基础. (5)在开发组织内已建立软件过程数据库,保存收集到的数据,可用于各项目的软 件过程. 过程： (1)开始定量地认识软件过程. (2)软件过程的变化小.一般在可接受的范围内. (3)可以预见软件过程中和产品质量方面的一些趋势.一旦质量经度量后超出这些 标准或是有所违反.可以采用一些方法去改正,以达到良好的日标. 人员 ：每个项目中存在强烈的群体工作意识,因为每人都了解个人的作用与组织的关 系,因此能够产生这种群体意识. 技术 不断的在定量基础上评估新技术. 度量： (1)在全组织内进行数据收集与确定. (2)度量标准化. (3)数据用于定量地理解软件过程及稳定软件过程. 改进方向 ： (1)缺陷防范.不仅仅在发现了问题时能及时改进,而且应采取特定行动防止将来 出现这类缺陷. (2)主动进行技术变动管理,标识,选择和评价新技术.使有效的新技术能在开发 组织中施行, (3)进行过程变动管理.定义过程改进的目的,经常不断地进行过程改进. 5,优化级 特征 ： (1)整个组织特别关注软件过程改进的持续性,顶见及增强自身.防止缺陷及问题 的发生.不断地提高他们的过程能力. (2)加强定量分析,通过来自过程的质量反馈和吸收新观念,新科技,使软件过程 能不断地得到改进, (3)根据软件过程的效果,进行成本/利润分析,从成功的软件过程实践中吸取经 验,加以总结.把最好的创新成绩迅速向全组织转移.对失败的案例,由软件过程小 组近行分析以找出原因. (4)组织能找出过程的不足并预先改进.把失败的教训告知全体组织以防止重复以 前的错误. (5)对软件过程的评价相对标准软件过程的改进,都在全组织内推广. 过程 ： (1)不断地系统地改进软件过程 (2)理解并消除产生问题的公共根源.在任何一个系统中都可找到:由于随机变化 造成重复工作,进而导致时间浪费.为了防止浪费人力可能导致的系统变化.要消除 "公共"的无效根源,防止浪费发生.尽管所有级别都存在这些问题,但这是第五级 的焦点. 人员 ： (1)整个组织都存在自觉的强烈的团队意识. (2)每个人都致力于过程改进.人们不再以达到里程碑的成就而满足,而要力求减 少错误率. 技术 基于定量的控制和管理,事先主动考虑新技术,追求新技术,利用新技术.可以 实现软件开发中的方法和新技术的革新,以防止出现错误,不断提高产品的质量和生 产率. 度量： 利用数据来评估,选择过程改进. 改进方向 保持持续不断的软件过程改进. 二,敏捷开发和高级别 CMMI 关键字: 高级别 CMMI 敏捷开发 我经常和别人一起讨论敏捷开发过程的知识,并且我们也会经常争论结合使用敏 捷开发过程和 CMMI 高级别的话题.他们两个是否能够结合使用?或者他们两个只是 向相反的方向发展?带着这个疑问,下面我们一起来探讨. "这个问题可以说是老生常谈,但是我对第 5 级别中的那个基本差异有一个疑 问,这个疑问会使人产生不安的情绪.CMMI1.2 强调了想在组织中控制结果的变更, 进而将其重心转移到了个人的身上.敏捷开发在意义上说不单单是为了让每个项目能 在应对各种各样的环境中都拥有灵活的能力,并且可以让他们在这个环境中尽其所能 表现的最好.我们并没有特别关注在所有项目中要规范行为以便可以预知结果是"可 靠的". 但是,我并不清楚我现在尽力想说明的这种区别,是否确实是敏捷开发和 CMMI 的基本概念中的一个基础的区别,还是只是组织如何解释和执行 CMMI 第 5 级别的一 个结果.当然,敏捷开发团队在过程模型和过程实践资产中拥有的信任似乎要比 CMMI 团队中的要少――虽然在敏捷中没有方法可以规范这些事情即便他们是低成本的,但 是没有假设说明这就是组织要走的路.事实上,敏捷开发支持者偏向于这样的想法, 在任何形式的可遇见的过程模型中快速地建立起逐渐减少的成果.是否这就是等同说 敏捷开发支持者相信特殊原因会影响执行效果是如此的普遍,以至在组织中试图建立 预见性的模型是无用的?" CMMI 第 4 级别: QPM(量化项目管理):主要关注懂得过程行为变更的个别项目,他们认为这些 变更影响着他们的成功和如何处理事情――或者至少影响着完成产品发展或者达成目 标.组织单位(EPG)必须要监控成果. OPP(组织过程实践):主要关注集成模型,项目可以使用模型来规范他们想要 达到成功的方面,比如说质量,进度表,预算,维护以及其他任何事情.诀窍就是项 目在过程执行中以这些模型为基础,控制 QPM 中的行为.比较典型的是,这些模型可 能是基于相似的项目中的重复的结果不断建立起来的,虽然可能并没有这样的需求. 在个别项目级别中模型应该先被改进以便使用,所以在 CMMI 模型中使用基于一个项 目的历史数据(比如说,增量)或者 20 个项目的历史数据是没有区别的,虽然这可能 对使用者来说是有区别的. CMMI 第 5 级别: CAR(原因分析与解决方法):主要关注引起问题的主要原因,过失,管理问题 或者其他一切需要解决的问题.项目,EPG 或者其他任何人是否可以应用,是作为解 决问题的方法.EPG 在 OPP 中监控结果,或者得到别的经验.(敏捷开发是否在增量 开始点或者结束点不建议进行类似的行为?我不清楚我所知道的术语是否正确) OID(组织创新与推展):完全非项目特点.关注基于个体,CAR,模型使用,外 界因素等的组织改进.你是否会收集并且使用所有这些学到的经验?你进入企业后是 否会寻求新的或者更好的做生意的方法(其中敏捷开发可能只是一个例子)?在组织 中又该如何处理证明,分析(职业),和使用(结构请参照第 4 级别中的模型和过程 控制)这些改进. 我个人认为 CMMI 高级别和敏捷开发应该结合起来工作.敏捷可以帮助 CMMI 高级 别更容易实现短期的转变,并且它在处理事情的发展上起了很重要的作用.我的经验 基本是从第 5 级别得来的,有部分来自第 4 级别.许多组织怀着"每个人都必须如此 做"的想法而通过了第 3 级别,但是他们却反对在第 4,5 级别中有着同样的想法.就 像我曾经提到的,敏捷开发是使用 CMMI 第 4,5 级别来改进如何发展产品的完美例 子. CMMI 是 Capability Maturity Model Integration(能力成熟度模型集成)的缩写, 是在 CMM(Capability Maturity Model 能力成熟度模型)的基础上发展而来 三,CMMI 实施 现在很多企业因某种原因想做 CMMI 了,大体做法 1,决定实施 CMMI 2,EPG 接受培训,理解 CMMI 3,EPG 根据自己理解的 CMMI 和实际情况开发一大堆漂漂亮亮的过程文档,流程 图,表格,模板,检查单,作业指南. 4,大家边听着 EPG 的解释(包括培训,答疑),边执行这些过程标准,然后审计 (内,外) 将目前的最佳实践记录下来,写下来,文档化下来. 很多新的 EPG 在做了一段时间后无奈的发现自己居然沦落成了一个过程标准解说 员,甚至文档管理员.自己工作大部分时间是面对文档,或者督促别人写文档 我到觉得 EPG 最主要的工作应该深入到研发第一线,帮助研发人员解决研发过程 中面临的最严重的实际问题(当然是解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 要上升到过程高度,而不应是单个问题或 个人),甚至哪怕是一些不严重但以你的项目经验知道该如何解决的问题上.总体说来 就是掌握项目进展中的任何细微的技术难点要点,并主动记录下来. 为什么这么说呢?CMMI 实施的主要宗旨就是以每个项目为采集数据的源头,达到 企业整体效益提升和资源重用.真正有价值的东西,是需要一线人员在实际工作中遇 到问题,解决问题,并总结问题,不是一个一线工作的流水帐.就象一份研发人员的 日报.写了上午做什么,下午做什么.这对企业的积累有什么用处呢?他工作过程中, 遇到什么问题,他是怎么解决的,走过什么弯路,实验过几种方法,失败了,失败的 原因是什么,最后选择了什么方法,可能不是最好的,但完成了任务,达到了效率和 资源分配的平衡.这些东西才可能是未来类似项目中,遇到类似问题时,可能有参考 价值的.通常也是 EPG 个人职业生涯的技术积累.只有公司里每个员工,把自己认为 最有价值的积累贡献出来.才可能达到公司有价值的积累.而决不是形式上写的上午 下午每个小时的流水帐. 明白了上面的说的 CMMI 的目的,做为一个合格的 EPG,就应该具备以下的素 质: 1,明白什么是有价值的积累,先是对你个人,然后才是顺便帮公司做了积累. 2,深入一线,发现她们并忠实地记录她们.CMMI 里的 SP,GP,只是帮助你,提 醒你在哪个环节,哪些东西可能是有价值了.你去收集一下,别视而不见了.因为还 有一个企业和你个人的角度不同,立场不同的问题.例如,REQM 里收集需求,对个人 技术方面的积累虽然不多,但对企业是至关重要的,一次需求变更,没详细写清楚, 忘记了到客户那里去签字落实,可能就会给企业造成很大的损失.做为一个合格的 EPG,是需要有这份责任和义务把每个环节都做到最好,这是职业道德所在.同时也 是对自我延伸的一个好机会,学会一些和人的沟通,倾听,把专业的东西以平易的方 式表达.这些也都算是 EPG 额外的收获. 通常情况下,为了按时按量完成项目,一线的骨干,对写日报,周报,文档都很 不屑.EPG 也很迁就,事后再补,这也不失为一个提高效率的好办法.但过去一个月 半年了,我们正常人的记忆都能想象,很难记住细节.无非就是敷衍.这也在情理之 中.你总不能让一个明天就要交东西的小组,今天晚上在通宵努力解决 BUG 的同时, 还写什么报告,这也不尽人情.但作为 EPG 不能只把眼光集中在这妇人之心上.要想 的更远.为什么会把项目推到这么晚,BUG 还没解决完?难道要永远这样下去吗?项目 中是有很多不可预测的因素,甚至是开发人员常说的"手气问题","人品问题".但这些 是需要控制的,也是通过经验可以控制的,所谓艺高人胆大.艺的高低,就是经验的 积累决定的. 那怎么解决这种两难的问题呢?逼着技术骨干写心水,人家没时间也的确压力很 大.不写,公司又得不到有效积累,积累的都是垃圾流水.有个公司的办法和经验到 可以借鉴一下: 公司内部搞了个 BBS,把不同类型的工作分成不同的组,有纯技术的,JAVA 组, C++组等,也有 PPT 组,甚至动画组,界面组.大家把自己平时的工作积累 FTP 上 去,甚至制作方法,遇到问题和解决方法的文档都丢上去,开始怎么想,用了多少套 方案,最后选择了什么.自我感觉如何.把这些心路历程都写成文档.丢到阳光下, 大家评论.用点击率和"顶"的人数来说明谁写的是心水,谁在写垃圾.大家都是一个公 司的,很容易实名.直接纳入考核机制中.做为一线人员,大家也有动力来写,自己 的聪明才智有了展现的平台,虚荣心和荷包都得到了相应的满足.何乐而不为呢? EPG 适时的评估大家的成果,并把他们分到项目里.帮助项目总结,甚至在平时 遇到问题时,直接帮助技术人员做必要记录.项目进度松时,再督促项目人员完善内 容.以达到对个人和公司积累的最大化. EPG 应该明白学习和积累是个终身的过程,对公司如此,对个人也是如此.CMMI 是个辅助,辅助我们对公司做积累,也帮助我们个人做必要的积累.公司需要逐步走 向更高的管理水平,发展平台. 四,CMMI 实施之核心 关键字:CMMI,SCAMPI,过程改进,能力成熟度,EPG,PA,过程域 在上一章节中,我们谈到了关于过程改进团队的组建方法及在组建过程中需要注 意的问题,在本节中我们将继续探讨 EPG 过程改进的另一个更为重要的一环——定义 过程文档. 曾经有一位评估师开玩笑说,三级是写文档,四级是写文档的文档,五级是写文 档的文档的文档.由此可见,文档贯穿于整个 CMMI,在过程改进中起着举足轻重的作 用.那么如何才能写出既符合 CMMI 又立足于企业本身实际情况的文档呢?这就是本 文将要探讨的问题——定义过程文档. 在定义过程文档时,首先,应该进行企业的习惯表述与 CMMI 术语和语言间的映 射.特别是组织结构中的一些术语,角色,组织内部之间关系以及过程活动的表述方 式都需要映射到其组织的相应部分,以防止别人无法理解. 定义过程文档的一般步骤是: (1)先确定并描述产品的生命周期. 一般来说,产品生命周期可以划分为 6 个阶段,即产品概念阶段,产品定义阶 段, 产品开发阶段, 产品测试阶段,用户验收阶段,产品维护阶段. (2)根据产品生命周期的各个阶段确定需要改进的过程域(PA)活动. "过程域"用于描述 CMMI 标准定义的软件过程能力评估模型中的一种部件.在 该模型中,"过程域"是最大的的构造块,每个"过程域"由一组目标构成,每个目 标得到一组实践支持.模型中描述的过程是参考模板,用"过程域"来表示.不能与 实际过程混淆."过程域"不是实际的过程,它是模型中的模板. (3)针对某一个 PA 过程活动,完成 PA 的数据流程图. (4)准备相应的模板,检查表或者方法附件定义过程文档.再在 EPG 内部讨论 修改,然后拿给评审人员阅读,最后是进行正式评审.进一步修订,再评审直到大家 认可为止,再进入下一个 PA 过程.(或者也可以评审通过后进行试点,试点成功再进 入下有个 PA 过程.) 根据自己多年的咨询经验,总结了在定义过程文档时一般容易出现的问题. 1,"本地化做得不够" 咨询顾问常常在项目进行中发现这样的问题:在定义某个 PA 过程时,客户会过于 依赖咨询公司提供的其他一些企业的过程文档,并将这些文档梢作调整成为其自己的 过程文件.由于每个软件企业的情况是不一样,流程,规范,记录应该根据公司实际 情况来制定,参照 CMMI 框架,制定适合公司本身情况的"本地化"过程体系,这样 的效果会更好. (2)总体把握,逐步细化 在定义第一个 PA 过程时,如果没有考虑它跟其它 PA 之间的关系就直接参照 CMMI 的此 PA 的目标和实践完成了过程文件,可能发生的结果要么是无法通过评审, 要么就是通过了之后再返回进行修改.由于各 PA 间关系密切,息息相关,因此在实际 的定义过程中,先要从总体上把握住各 PA 间关系,完成整个过程的数据流程图的基础 上再进行逐步细分,否则即是"只见树木不见森林". (3)多交流,多总结 由于在项目初期,EPG 小组对于 CMMI 的理解不够透彻,大家也没什么经验,这 就需要 EPG 成员,QA,管理人员,开发人员之间多多交流,在定义过程文档时多讨 论,集众人之智慧,随着过程定义的进展,EPG 小组对 CMMI 的理解加深,就需要总 结经验,避免将来在遇到类似问题的时候多走弯路.