资源预览内容
第1页 / 共6页
第2页 / 共6页
第3页 / 共6页
第4页 / 共6页
第5页 / 共6页
第6页 / 共6页
亲,该文档总共6页全部预览完了,如果喜欢就下载吧!
资源描述
CMMI 等级的含义 五个成熟度级别之间的比较如下:1,初始级 特征:(1) 软件过程的特点是杂乱无章,有时甚至混乱.几乎没有定义过程的规则或步 骤.(2) 过分的尽诺.常做出良好的承诺:如按照软件工程方式,有序的工程过程来 工作;或达到高 目标的许诺.但实际上却出现一系列危机.(3) 遇到危机就放弃原计划过程,反复编码和测试.(4) 成功完全依赖个人努力和杰出的专业人才 ,取决于超常的管理人员和杰出有效 的软件开 发人员.具体的表现和成果都源于或者说是决定于个人的能力和他们先前的 经验,知识以及 他们的进取心和积极程度.(5) 能力只是个人的特性,而不是开发组织的持性 .依靠着个人的品质或承受着巨 大压力,或 找窍门取得成果.但此类人一旦离去,对组织的稳定作用也消失.(6) 软件过程是不可确定的和不可预见的 .软件成熟性程度处于第一级的软件组织 的软件过 程在实际的工作过程中被经常的改变 (过程是随意的).这类组织也在开发产 品,但其成果是 不稳定的,不可预见的,不可重复的.也就是说,软件的计划,预 算,功能 和产品的质量都是不可 确定和不可预见的.过程:(1) 极少存在或使用稳定的过程.(2) 所谓过程,往往是就这么干而言. (3)各种条例,规章制度互不协调,甚至互相矛盾 人员:(1) 依赖个人努力和杰出人物.一旦优秀人物离去,项目就无法继续(2) 人们的工作方式如同救火.就是在开发过程中不断地出现危机,以及不断 的救火. 技术: 引进新技术是极大风险度量: 不收集数据或分析数据 改进方向:(1) 建立项日管理过程.实施规范化管理.保障项目的承诺.(2) 首要任务是进行需求管理,建立客户与软件项目之间的共同理解,使项目真正 反映客户的 要求.(3) 建立各种软件项目计划 .如软件开发计划,软件质量保证计划,软件配置管 理计划,软件测 试计划,风险管理计划及过程改进计划.(4) 开展软件质量保证活动(SQA).2,可重复级 特征(1) 进行较为现实的求诺,可按以前在同类项目上的成功经验建立的必要过程准则 来确保再 一次的成功.(2) 主要是逐个项目地建立基本过程管理条例来加强过程能力.(3) 建立了基本的项目管理过程来跟踪成本,进度和功能.(4) 管理工作主要跟踪软件经费支出,进度及功能.识别在承诺方面出现的问题.采用基线(BASELINE)来标志进展,控制完整性.(6)定义了软件项目的标准,并相信它,遵循它.(7) 通过于合同建立有效的供求关系. 过程(1) 软件开发和维护的过程是相对稳定的,但过程建立在项目一级.(2) 有规则的软件过程是在一个有效的工程管理系统的控制之下,先前的成功经验 可以被重 复.(3) 问题出现时.有能力识别及纠正.其承诺是可实现的.人员(1) 项目的成功依赖于个人的能力以及管理层的支持.(2) 理解管理的必要性及对管理的承诺.(3) 注意人员的培训问题, 技术 建立技术支持活动,并有稳定的计划. 度量 每个项目建立资 源计划.主要是关心成本,产品和进度.有相应的管理数据.改进方向(1) 不再按项目制定软件过程,而是总结各种项目的成功经验,使之规则化,把具 体经验归纳为 全组织的标准软件过程.把改进组织的整体软件过程能力的软件过程活 动,作为软件开发组 织的责任.(2) 确定全组织的标准软件过程,把软件工程及管理活动集成到一个稳固确定的软 件过程中. 从而可以跨项目改进软件过程效果,也可作为软件过程剪裁的基础.建立软件工程过程小组(SEPG)长期承担评估与调控软件过程的任务,以适应未来软件项 目的要求.(4) 积累数据:建立组织的软件过程库及软件过程相关的文档库(5)加强培训.3,确定级 特征 :(1) 无论管理方面或工程方面的软件过程都已文件化,标准化,并综合成软件开发 组织的标准 软件过程.(2) 软件过程标准被应用到所有的工程中 ,用于编制和维护软件 .有的项目也可根 据实际情 况,对软件开发组织的标准软件过程进行剪裁.(3) 在从事一项工程时,产品的生产过程,花费,计划以及功能都是可以完全控制 的,从而软件 质量也可以控制.(4)软件工程过程组(SEPG)负责软件过程活动.(5) 在全组织范围内安排培训计划.过程:(1) 整个组织全面采用综合性的管理及工程过程来管理.软件工程和管理活动是稳 定的和可 重复的,具有连续性的.(2) 软件过程起了预见及防范问题的作用,能使风险的影响最小化 人员:(1) 以项目组的方式进行工作.如同综合产品团队.(2) 在整个组织内部的所有人对于所定义的软件过程的活动 ,任务有深入理解.大 大加强了 过程能力.(3) 有计划地按人员的角色进行培训技术 在定性基础上建立新的评估技术.度量:(1) 在全过程中收集使用数据.(2) 在全项目中系统性地共享数据改进方向 (1)开始着手软件过程的定量分析,以达到定量地控制软件项目过程的效果.(2)通过软件的质量管理达到软件的质量目标.4,管理级特征 :(1)制定了软件过程和产品质量的详细而具体的度量标准 .软件过程和产品的质量 都可以被 理解和控制.(2)软件组织的能力是可预见的.原因是软件过程是被明确的度量标准所度量和操 作.不言而 喻.软件产品的质量就可以预见和得以控制.(3) 组织的度量工程保证所有项目对生产率和质量进行度量 ,并作为重要的软件过 程活功.(4) 具有良好定义及一致的度量标服来指导软件过程 ,并作为评价软件过程及产品 的定量基 础.(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 级别中有着同样的想法.就 像我曾经提到的,敏捷开发是
网站客服QQ:2055934822
金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号