cmmi五个成熟度级别

《cmmi五个成熟度级别》由会员分享，可在线阅读，更多相关《cmmi五个成熟度级别（6页珍藏版）》请在金锄头文库上搜索。

1、CMMI 等级的含义 五个成熟度级别之间的比较如下:1,初始级 特征:(1) 软件过程的特点是杂乱无章,有时甚至混乱.几乎没有定义过程的规则或步 骤.(2) 过分的尽诺.常做出良好的承诺:如按照软件工程方式,有序的工程过程来 工作;或达到高 目标的许诺.但实际上却出现一系列危机.(3) 遇到危机就放弃原计划过程,反复编码和测试.(4) 成功完全依赖个人努力和杰出的专业人才 ,取决于超常的管理人员和杰出有效 的软件开 发人员.具体的表现和成果都源于或者说是决定于个人的能力和他们先前的 经验,知识以及 他们的进取心和积极程度.(5) 能力只是个人的特性,而不是开发组织的持性 .依靠着个人的品质或承

2、受着巨 大压力,或 找窍门取得成果.但此类人一旦离去,对组织的稳定作用也消失.(6) 软件过程是不可确定的和不可预见的 .软件成熟性程度处于第一级的软件组织 的软件过 程在实际的工作过程中被经常的改变 (过程是随意的).这类组织也在开发产 品,但其成果是 不稳定的,不可预见的,不可重复的.也就是说,软件的计划,预 算,功能 和产品的质量都是不可 确定和不可预见的.过程:(1) 极少存在或使用稳定的过程.(2) 所谓过程,往往是就这么干而言. (3)各种条例,规章制度互不协调,甚至互相矛盾 人员:(1) 依赖个人努力和杰出人物.一旦优秀人物离去,项目就无法继续(2) 人们的工作方式如同救火.就是

3、在开发过程中不断地出现危机,以及不断 的救火. 技术: 引进新技术是极大风险度量: 不收集数据或分析数据 改进方向:(1) 建立项日管理过程.实施规范化管理.保障项目的承诺.(2) 首要任务是进行需求管理,建立客户与软件项目之间的共同理解,使项目真正 反映客户的 要求.(3) 建立各种软件项目计划 .如软件开发计划,软件质量保证计划,软件配置管 理计划,软件测 试计划,风险管理计划及过程改进计划.(4) 开展软件质量保证活动(SQA).2,可重复级 特征(1) 进行较为现实的求诺,可按以前在同类项目上的成功经验建立的必要过程准则 来确保再 一次的成功.(2) 主要是逐个项目地建立基本过程管理条

4、例来加强过程能力.(3) 建立了基本的项目管理过程来跟踪成本,进度和功能.(4) 管理工作主要跟踪软件经费支出,进度及功能.识别在承诺方面出现的问题.采用基线(BASELINE)来标志进展,控制完整性.(6)定义了软件项目的标准,并相信它,遵循它.(7) 通过于合同建立有效的供求关系. 过程(1) 软件开发和维护的过程是相对稳定的,但过程建立在项目一级.(2) 有规则的软件过程是在一个有效的工程管理系统的控制之下,先前的成功经验 可以被重 复.(3) 问题出现时.有能力识别及纠正.其承诺是可实现的.人员(1) 项目的成功依赖于个人的能力以及管理层的支持.(2) 理解管理的必要性及对管理的承诺.

5、(3) 注意人员的培训问题, 技术 建立技术支持活动,并有稳定的计划. 度量 每个项目建立资 源计划.主要是关心成本,产品和进度.有相应的管理数据.改进方向(1) 不再按项目制定软件过程,而是总结各种项目的成功经验,使之规则化,把具 体经验归纳为 全组织的标准软件过程.把改进组织的整体软件过程能力的软件过程活 动,作为软件开发组 织的责任.(2) 确定全组织的标准软件过程,把软件工程及管理活动集成到一个稳固确定的软 件过程中. 从而可以跨项目改进软件过程效果,也可作为软件过程剪裁的基础.建立软件工程过程小组(SEPG)长期承担评估与调控软件过程的任务，以适应未来软件项 目的要求.(4) 积累数

6、据:建立组织的软件过程库及软件过程相关的文档库(5)加强培训.3,确定级 特征 ：(1) 无论管理方面或工程方面的软件过程都已文件化,标准化,并综合成软件开发 组织的标准 软件过程.(2) 软件过程标准被应用到所有的工程中 ,用于编制和维护软件 .有的项目也可根 据实际情 况,对软件开发组织的标准软件过程进行剪裁.(3) 在从事一项工程时,产品的生产过程,花费,计划以及功能都是可以完全控制 的,从而软件 质量也可以控制.(4)软件工程过程组(SEPG)负责软件过程活动.(5) 在全组织范围内安排培训计划.过程：(1) 整个组织全面采用综合性的管理及工程过程来管理.软件工程和管理活动是稳 定的和

7、可 重复的,具有连续性的.(2) 软件过程起了预见及防范问题的作用,能使风险的影响最小化 人员：(1) 以项目组的方式进行工作.如同综合产品团队.(2) 在整个组织内部的所有人对于所定义的软件过程的活动 ,任务有深入理解.大 大加强了 过程能力.(3) 有计划地按人员的角色进行培训技术 在定性基础上建立新的评估技术.度量：(1) 在全过程中收集使用数据.(2) 在全项目中系统性地共享数据改进方向 (1)开始着手软件过程的定量分析,以达到定量地控制软件项目过程的效果.(2)通过软件的质量管理达到软件的质量目标.4,管理级特征 ：(1)制定了软件过程和产品质量的详细而具体的度量标准 .软件过程和产

8、品的质量 都可以被 理解和控制.(2)软件组织的能力是可预见的.原因是软件过程是被明确的度量标准所度量和操 作.不言而 喻.软件产品的质量就可以预见和得以控制.(3) 组织的度量工程保证所有项目对生产率和质量进行度量 ,并作为重要的软件过 程活功.(4) 具有良好定义及一致的度量标服来指导软件过程 ,并作为评价软件过程及产品 的定量基 础.(5) 在开发组织内已建立软件过程数据库 ,保存收集到的数据,可用于各项目的软 件过程. 过 程：(1)开始定量地认识软件过程.(2)软件过程的变化小.一般在可接受的范围内.(3) 可以预见软件过程中和产品质量方面的一些趋势 .一旦质量经度量后超出这些 标准

9、或 是有所违反.可以采用一些方法去改正,以达到良好的日标.人员 ：每个项目中存在强烈的群体工作意识,因为每人都了解个人的作用与组织的关 系, 因此能够产生这种群体意识. 技术 不断的在定量基础上评估新技术.度量： (1)在全组织内进行数据收集与确定.(2)度量标准化.(3) 数据用于定量地理解软件过程及稳定软件过程. 改进方向 ：(1)缺陷防范.不仅仅在发现了问题时能及时改进,而且应采取特定行动防止将来 出现这类 缺陷.(2)主动进行技术变动管理,标识,选择和评价新技术.使有效的新技术能在开发 组织中施行,(3) 进行过程变动管理.定义过程改进的目的,经常不断地进行过程改进.5,优化级 特征

10、： (1)整个组织特别关注软件过程改进的持续性,顶见及增强自身.防止缺陷及问题 的发生.不 断地提高他们的过程能力.(2)加强定量分析,通过来自过程的质量反馈和吸收新观念,新科技,使软件过程 能不断地得 到改进,(3) 根据软件过程的效果 ,进行成本/利润分析,从成功的软件过程实践中吸取经 验,加以总 结.把最好的创新成绩迅速向全组织转移.对失败的案例,由软件过程小 组近行分析以找出原 因.(4) 组织能找出过程的不足并预先改进 .把失败的教训告知全体组织以防止重复以 前的错 误.(5) 对软件过程的评价相对标准软件过程的改进,都在全组织内推广.过程 ：(1)不断地系统地改进软件过程(2)理解

11、并消除产生问题的公共根源 .在任何一个系统中都可找到:由于随机变化 造成重 复工作,进而导致时间浪费.为了防止浪费人力可能导致的系统变化 .要消除 公共的无效根 源,防止浪费发生.尽管所有级别都存在这些问题,但这是第五级 的焦点.人员 ：（1）整个组织都存在自觉的强烈的团队意识.（2）每个人都致力于过程改进.人们不再以达到里程碑的成就而满足,而要力求减 少错误率. 技术 基于定量的控制和管理,事先主动考虑新技术,追求新技术,利用新技术.可以 实现软件 开发中的方法和新技术的革新,以防止出现错误,不断提高产品的质量和生 产率.度量：利用数据来评估,选择过程改进. 改进方向 保持持续不断的软件过程

12、改进. 二,敏捷开发和高级别 CMMI 关键字:高级别 CMMI 敏捷开发 我经常和别人一起讨论敏捷开发过程的知识,并且我们也会经常 争论结合使用敏 捷开发过程和 CMMI 高级别的话题.他们两个是否能够结合使用 ?或者他 们两个只是 向相反的方向发展?带着这个疑问,下面我们一起来探讨. 这个问题可以说是老 生常谈,但是我对第 5 级别中的那个基本差异有一个疑 问,这个疑问会使人产生不安的情 绪.CMMI1.2强调了想在组织中控制结果的变更，进而将其重心转移到了个人的身上.敏捷开 发在意义上说不单单是为了让每个项目能 在应对各种各样的环境中都拥有灵活的能力 ,并 且可以让他们在这个环境中尽其所

13、能 表现的最好.我们并没有特别关注在所有项目中要规 范行为以便可以预知结果是可 靠的. 但是,我并不清楚我现在尽力想说明的这种区别 ,是 否确实是敏捷开发和 CMMI 的基本概念中的一个基础的区别,还是只是组织如何解释和执 行 CMMI 第 5 级别的一 个结果.当然,敏捷开发团队在过程模型和过程实践资产中拥有的 信任似乎要比 CMMI 团队中的要少虽然在敏捷中没有方法可以规范这些事情即便他们 是低成本的,但 是没有假设说明这就是组织要走的路.事实上,敏捷开发支持者偏向于这样的 想法, 在任何形式的可遇见的过程模型中快速地建立起逐渐减少的成果.是否这就是等同说 敏捷开发支持者相信特殊原因会影响

14、执行效果是如此的普遍 ,以至在组织中试图建立 预见 性的模型是无用的? CMMI第4级别：QPM（量化项目管理）:主要关注懂得过程行为变更的 个别项目,他们认为这些 变更影响着他们的成功和如何处理事情 或者至少影响着完成 产品发展或者达成目标组织单位（EPG）必须要监控成果.OPP（组织过程实践）:主要关注集成 模型,项目可以使用模型来规范他们想要 达到成功的方面,比如说质量,进度表,预算,维护以 及其他任何事情.诀窍就是项 目在过程执行中以这些模型为基础,控制 QPM 中的行为.比较 典型的是,这些模型可 能是基于相似的项目中的重复的结果不断建立起来的,虽然可能并没 有这样的需求. 在个别项

15、目级别中模型应该先被改进以便使用,所以在 CMMI 模型中使用基 于一个项 目的历史数据（比如说,增量）或者 20 个项目的历史数据是没有区别的 ,虽然这可 能对使用者来说是有区别的.CMMI第5级别:CAR（原因分析与解决方法）:主要关注引起问 题的主要原因，过失，管理问题或者其他一切需要解决的问题项目,EPG或者其他任何人是 否可以应用，是作为解决问题的方法.EPG在OPP中监控结果，或者得到别的经验.（敏捷开 发是否在增量 开始点或者结束点不建议进行类似的行为?我不清楚我所知道的术语是否正 确）OID（组织创新与推展）:完全非项目特点关注基于个体,CAR，模型使用，夕卜界因素等的组织 改进.你是否会收集并且使用所有这些学到的经验?你进入企业后是 否会寻求新的或者更好 的做生意的方法（其中敏捷开发可能只是一个例子）?在组织 中又该如何处理证明,分析（职业）, 和使用（结构请参照第 4 级别中的模型和过程 控制）这些改进. 我个人认为 CMMI 高级别 和敏捷开发应该结合起来工作.敏捷可以帮助 CMMI 高级 别更容易实现短期的转变,并且它 在处理事情的发展上起了很重要的作用.我的经验 基本是从第 5 级别得来的,有部分来自第 4 级别.许多组织怀着每个人都必须如此 做的想法而通过了第 3 级别,但是他们却反对在 第 4,5 级别中有着同样的想法.就 像我曾经提到的,敏捷开发是