科技: 人物 企业 技术 IT业 TMT
科普: 自然 科学 科幻 宇宙 科学家
通信: 历史 技术 手机 词典 3G馆
索引: 分类 推荐 专题 热点 排行榜
互联网: 广告 营销 政务 游戏 google
新媒体: 社交 博客 学者 人物 传播学
新思想: 网站 新书 新知 新词 思想家
图书馆: 文化 商业 管理 经济 期刊
网络文化: 社会 红人 黑客 治理 亚文化
创业百科: VC 词典 指南 案例 创业史
前沿科技: 清洁 绿色 纳米 生物 环保
知识产权: 盗版 共享 学人 法规 著作
用户名: 密码: 注册 忘记密码?
    创建新词条
科技中国——欢迎光临全球最大的互联网博物馆
  • 人气指数: 31878 次
  • 编辑次数: 1 次 历史版本
  • 更新时间: 2009-12-22
高兴
高兴
发短消息
相关词条
世界品牌实验室
世界品牌实验室
泛在信息社会
泛在信息社会
计算机存储单位
计算机存储单位
TeraGrid
TeraGrid
CMMI
CMMI
世界品牌实验室
世界品牌实验室
并行总线
并行总线
IT失业指南
IT失业指南
GoblinX
GoblinX
GNOME Do
GNOME Do
推荐词条
希拉里二度竞选
希拉里二度竞选
《互联网百科系列》
《互联网百科系列》
《黑客百科》
《黑客百科》
《网络舆情百科》
《网络舆情百科》
《网络治理百科》
《网络治理百科》
《硅谷百科》
《硅谷百科》
桑达尔·皮查伊
桑达尔·皮查伊
阿里双十一成交额
阿里双十一成交额
王健林电商梦
王健林电商梦
陌陌IPO
陌陌IPO
最新词条

热门标签

微博侠 数字营销2011年度总结 政务微博元年 2011微博十大事件 美国十大创业孵化器 盘点美国导师型创业孵化器 盘点导师型创业孵化器 TechStars 智能电视大战前夜 竞争型国企 公益型国企 2011央视经济年度人物 Rhianna Pratchett 莱恩娜·普莱契 Zynga与Facebook关系 Zynga盈利危机 2010年手机社交游戏行业分析报告 游戏奖励 主流手机游戏公司运营表现 主流手机游戏公司运营对比数据 创建游戏原型 正反馈现象 易用性设计增强游戏体验 易用性设计 《The Sims Social》社交亮 心理生理学与游戏 Kixeye Storm8 Storm8公司 女性玩家营销策略 休闲游戏的创新性 游戏运营的数据分析 社交游戏分析学常见术语 游戏运营数据解析 iPad风行美国校园 iPad终结传统教科书 游戏平衡性 成长类型及情感元素 鸿蒙国际 云骗钱 2011年政务微博报告 《2011年政务微博报告》 方正产业图谱 方正改制考 通信企业属公益型国企 善用玩家作弊行为 手机游戏传播 每用户平均收入 ARPU值 ARPU 游戏授权三面观 游戏设计所运用的化学原理 iOS应用人性化界面设计原则 硬核游戏 硬核社交游戏 生物测量法研究玩家 全球移动用户 用户研究三部曲 Tagged转型故事 Tagged Instagram火爆的3大原因 全球第四大社交网络Badoo Badoo 2011年最迅猛的20大创业公司 病毒式传播功能支持的游戏设计 病毒式传播功能 美国社交游戏虚拟商品收益 Flipboard改变阅读 盘点10大最难iPhone游戏 移动应用设计7大主流趋势 成功的设计文件十个要点 游戏设计文件 应用内置付费功能 内置付费功能 IAP功能 IAP IAP模式 游戏易用性测试 生理心理游戏评估 游戏化游戏 全美社交游戏规模 美国社交游戏市场 全球平板电脑出货量 Facebook虚拟商品收益 Facebook全球广告营收 Facebook广告营收 失败游戏设计的数宗罪名 休闲游戏设计要点 玩游戏可提高认知能力 玩游戏与认知能力 全球游戏广告 独立开发者提高工作效率的100个要点 Facebook亚洲用户 免费游戏的10种创收模式 人类大脑可下载 2012年最值得期待的20位硅谷企业家 做空中概股的幕后黑手 做空中概股幕后黑手 苹果2013营收 Playfish社交游戏架构

 CMMI 的全称为:Capability Maturity Model Integration,即能力成熟度模型集成。
  CMMI家族包括CMMI for Development, CMMI for Service和CMMI for Acquisition三个套装产品。
  早期的CMMI(CMMI-SE/SW/IPPD)1.02版本是应用于软件业项目的管理方法,SEI在部分国家和地区开始推广和试用。随着应用的推广与模型本身的发展,演绎成为一种被广泛应用的综合性模型。
  自从1994 年SEI 正式发布软件CMM 以来,相继又开发出了系统工程、软件采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度模型。虽然这些模型在许多组织都得到了良好的应用,但对于一些大型软件企业来说,可能会出现需要同时采用多种模型来改进自己多方面过程能力的情况。这时他们就会发现存在一些问题,其中主要问题体现在:
  n 不能集中其不同过程改进的能力以取得更大成绩;
  n 要进行一些重复的培训、评估和改进活动,因而增加了许多成本;
  n 遇到不同模型中有一些对相同事物说法不一致,或活动不协调,甚至相抵触。
  于是,希望整合不同CMM 模型的需求产生了。1997 年,美国联邦航空管理局(FAA)开发了FAA-iCMMSM(联邦航空管理局的集成CMM),该模型集成了适用于系统工程的SE-CMM、软件获取的SA-CMM 和软件的SW-CMM 三个模型中的所有原则、概念和实践。该模型被认为是第一个集成化的模型。  
目录

[显示全部]

CMMI评估的预备工作编辑本段回目录

  评估实践证明:在进行CMMI评估之前,制定一个正确的评估计划并将其文档化,确保有一个富有经验的、受过培训且具有适当资格的小组能被用来评估,为执行评估过程做准备,是十分必要的。
  我们所说的文档化CMMI评估计划的结果,包括:要求,协定,估价,风险,剪裁方法,以及与评估相关的实际考虑(例如:日程安排,后勤,组织的背景信息)。此外,还应当获取并记录发起方对于CMMI评估计划的正式批准。在制定评估计划之前,应对CMMI评估输入中反映出来的协议文档化,该协议将有助于CMMI评估目标和关键评估计划参数的共同理解。在对驱动计划过程的关键参数达成共同理解的基础上,CMMI评估发起方和SCAMPI主任评估师应就评估计划达成一致;发起者和评估小组领导应就已计划的评估中技术和非技术细节达成一致。这个计划在执行其他的计划和准备阶段活动中需要进一步细化。
  而通过CMMI评估小组的准备工作,将产生一支富有经验的、受过培训的且定位准确的小组准备执行CMMI评估任务。该小组的成员都应当获得了完成他们各自的任务所必备的知识,或者他们之前所拥有的知识被证实足以完成相关任务。评估小组领导者已经给每一个人提供了为完成他们各自的任务所需的对技能进行实践的机会,或者证实这些技能在过去已经得到了示范。小组成员相互了解,同时开始计划他们如何协调一致的工作。还应该做到:准备好的小组是为评估目标而服务的,小组的成员已提供培训且培训结果被记录,在必要的时候,对他们所做的因知识或技能不足的补救工作已经完成。我们认为,无论CMMI评估小组领导者是从头培训一支全新的评估小组,还是通过从富有经验的小组成员中选择来组建一个小组,确保他们与CMMI评估小组领导者能组成一个成功的集体是其责任。此外,在对CMMI评估进行的预备工作的过程中,我们还应当对模型剪裁的原则有所了解:
  1.在某些应用中,计划模板和例行的程序能够根据评估的需要进行调整,这和当地的过程所有权一样,有助于交流;
  2.一个结构化的计划工艺组有利于只有有限的评估经验的组织,这样一个工艺就像缓和策略样,对于发现风险是一个很有价值的机会;
  3.案例研究材料提供了各种各样的选择来扩充小组培训内容以增强那些更需要培训的重点;
  4.富有经验的评估小组领导者在没有案例分析的情况下,同样可以管理和模拟评估行为;
  5.在小组所有已获得培训成员的集合中,对小组的建立工作进行管理以确保其团队凝聚力是十分重要的,因此,很多的小组建立练习是可以利用的,小组的规模、技能、组成部分都是本方法的裁剪内容;
  6.所采用工具可以包括评估计划模板,样例,和计划模板中嵌入式的程序上的帮助,此外,为了估计评估约束的影响,估算工作表和方法也是很有用处的。
  总之,CMMI评估是一个十分复杂的过程,更由于其具有的不确定性,在评估的实践中,一定要做到有备无患。真理来自于实践,我们相信,随着越来越多的软件组织着手CMMI评估,越来越多的成功经验将为我们所利用和借鉴。  

Cmmi评估方法编辑本段回目录

  自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 连续式描述
  系统工程 or 软件工程 or 两者皆有
  使用连续式描述可以根据企业需要选择流程改进顺序,降低企业风险,这给通过ISO做流程改进提供了一个方便的比较。使用能力度(Capability)来衡量。
  阶段式描述提供了已经过验证的流程改进顺序,方便从CMM移植过来。使用成熟度(Maturity)来衡量流程改进。
  系统工程包括整个系统的开发,可能包括软件也可能不包括。
  软件工程用于软件系统的开发,主要集中在使用系统的·科学的·量化的方法来开发·运行·维护软件。
  cmm是项目管理
  由美国卡内基梅隆大学的软件工程研究所(SEI)创立的CMM(Capability Maturity Model 软件能力成熟度模型)认证评估,在过去的十几年中,对全球的软件产业产生了非常深远的影响。CMM共有五个等级,分别标志着软件企业能力成熟度的五个层次。从低到高,软件开发生产计划精度逐级升高,单位工程生产周期逐级缩短,单位工程成本逐级降低。据SEI统计,通过评估的软件公司对项目的估计与控制能力约提升40%到50%;生产率提高10%到20%,软件产品出错率下降超过1/3。
  对一个软件企业来说,达到CMM2就基本上进入了规模开发,基本具备了一个现代化软件企业的基本架构和方法,具备了承接外包项目的能力。CMM3评估则需要对大软件集成的把握,包括整体架构的整合。一般来说,通过CMM认证的级别越高,其越容易获得用户的信任,在国内、国际市场上的竞争力也就越强。因此,是否能够通过CMM认证也成为国际上衡量软件企业工程开发能力的一个重要标志。
  CMM是目前世界公认的软件产品进入国际市场的通行证,它不仅仅是对产品质量的认证,更是一种软件过程改善的途径。参与CMM评估的博科负责人表示,通过CMM的评估认证不是目标,它只是推动软件企业在产品的研发、生产、服务和管理上不断成熟和进步的手段,是一种持续提升和完善企业自身能力的过程。此次由美国PIA咨询公司负责评估并最终通过CMM3认证,标志着博科在质量管理的能力已经上升到一个新的高度。
  CMMI分为五个等级,二十五个过程区域(PA)(如图所示)。
  1. 初始级 软件过程是无序的,有时甚至是混乱的,对过程几乎没有定义,成功取决于个人努力。管理是反应式的。
  2. 已管理级 建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律,能重复早先类似应用项目取得的成功经验。
  3. 已定义级 已将软件管理和工程两方面的过程文档化、标准化,并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件,软件产品的生产在整个软件过程是可见的。
  4. 量化管理级 分析对软件过程和产品质量的详细度量数据,对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据,管理能够在定量的范围内预测性能。
  5. 优化管理级 过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。
  每个等级都被分解为过程域,特殊目标和特殊实践,通用目标、通用实践和共同特性:
  每个等级都有几个过程区域组成,这几个过程域共同形成一种软件过程能力。每个过程域,都有一些特殊目标和通用目标,通过相应的特殊实践和通用实践来实现这些目标。当一个过程域的所有特殊实践和通用实践都按要求得到实施,就能实现该过程域的目标。
  能力度等级:属于连续式表述,共有六个能力度等级(0~5),每个能力度等级对应到一个一般目标,以及一组一般执行方法和特定方法。
  0 不完整级
  1 执行级
  2 管理级
  3 定义级
  4 量化管理级
  5 最佳化级
  CMMI的评估方式:
  自我评估:用于本企业领导层评价公司自身的软件能力。
  主任评估:使本企业领导层评价公司自身的软件能力,向外宣布自己企业的软件能力
  CMMI的评估类型:
  软件组织的关于具体的软件过程能力的评估。
  软件组织整体软件能力的评估(软件能力成熟度等级评估)。
  

CMMI的基本思想编辑本段回目录

  1、解决软件项目过程改进难度增大问题
  2、实现软件工程的并行与多学科组合
  3、实现过程改进的最佳效益
  1、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版本。
  但是,美国国防部办公室要求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为企业的过程构建和改进提供了指导和框架作用;同时为企业评审自己的过程提供了可参照的行业基准。
  2、CMMI的源模型
  软件能力成熟度模型2.0版,C稿;电子行业协会临时标准(EIA/IS)731;集成产品开发能力成熟度模型(IPD-CMM)v0.98。
  3、CMMI的原则
  (1)、 强调高层管理者的支持。过程改进往往也是由高层管理者认识和提出的,大力度的、一致的支持是过程改进的关键。
  (2)、 仔细确定改进目标,首先应该对给定时间内的所能完成的改进目标进行正确的估计和定义并制定计划。选择能够达到的目标和能够看到对组织的效益。
  (3)、 选择最佳实践,应该基于组织现有的软件活动和过程财富,参考其他标准模型,取其精华去其糟粕,得到新的实践活动模型。
  (4)、 过程改进要与组织的商务目标一致,与发展战略紧密结合。
  4、CMMI目标
  (1)、 为提高组织过程和管理产品开发、发布和维护能力提供保障。
  (2)、 帮助组织客观评价自身能力成熟度和过程域能力,为过程改进建立优先级以及执行过程改进。
  5、CMMI的方法
  (1)、决定哪个CMMI模型等级最适合组织过程改进需要。
  (2)、 选择模型的表示法是连续式还是阶段式。
  (3)、 决定组织需要用到的模型中的知识领域。
  (4)、 类似CMM提出的过程改进6步,集成化过程改进分成:开始集成过程改进,建造集成改善平台,集成传统过程,启动新过程,进行改进评估。
  6、CMMI内容
  CMMI内容分为“Required”(必需的)、“Expected”(期望的)、“Informative”(提供信息的)三个级别,来衡量模型包括的质量重要性和作用。最重要的是"要求"级别,是模型和过程改进的基础。第二级别"期望"在过程改进中起到主要作用,但是某些情况不是必须的可能不会出现在成功的组织模型中。 "提供的信息"构成了模型的主要部分,为过程改进提供了有用的指导,在许多情况下他们对需要和期望的构件做了进一步说明。
  "要求"的模型构件是目标,代表了过程改进想要达到的最终状态,它的实现表示了项目和过程控制已经达到了某种水平。当一个目标对应一个关键过程域,就称为"特定目标";对应整个关键过程域就称为"公用目标"。整个CMMI模型包括了54个特定目标,每个关键过程域都对应了一到四个特定目标。每个目标的描述都是非常简捷的,为了充分理解要求的目标就是扩展"期望"的构件。
  "期望"的构件是方法,代表了达到目标的实践手段和补充认识。每个方法都能映射到一个目标上,当一个方法对一个目标是唯一就是"特定方法";而能适用于所有目标时就是"公用方法"。CMMI模型包括了186个特定方法,每个目标有两到七个方法对应。
  CMMI包括了10种"提供的信息":目的,概括和总结了关键过程域的特定目标;介绍说明,介绍关键过程域的范围、性质和实际方法和影响等特征;引用,关键过程域之间的指向是通过引用;名字,表示了关键过程域的构件;方法和目标关系,关键过程域中方法映射到目标的关系表;注释,注释关键过程域的其他模型构件的信息来源;典型工作产品集,定义关键过程域中执行方法时候产生的工作产品;子方法,通过方法活动的分解和详细描述;学科扩充,CMMI对应学科是独立的,这里提供了对应特定学科的扩展;公用方法的详细描述,关键过程域中公用方法应用实践的详细描述。
  CMMI提供了阶段式和连续式两种表示方法,但是这两种表示法在逻辑上是等价的。我们熟悉的SW-CMM软件能力成熟模型就是是阶段式的模型,SE-CMM系统工程模型是连续式模型,而IPD-CMM集成产品开发模型结合了阶段式和连续式两者的特点。
  阶段式方法将模型表示威一系列"成熟度等级"阶段,每个阶段都有一组KPA指出一个组织应集中于何处以改善其组织过程,每个KPA用满足其目标的方法来描述,过程改进通过在一个特定的成熟度等级中满足所有KPA的目标而实现的。
  连续式模型没有像阶段式那样的分散阶段,模型的KPA中的方法是当KPA的外部形式,并可应用于所有的KAP中,通过实现公用方法来改进过程。它不专门指出目标,而是强调方法。组织可以根据自身情况适当裁剪连续模型并以确定的KPA为改进目标。
  两种表示法的差异反应了为每个能力和成熟度等级描述过程而使用的方法,他们虽然描述的机制可能不同,但是两种表示方法通过采用公用的目标和方法作为需要的和期望的模型元素,而达到了相同的改善目的。
  现在CMMI面临的一个挑战就是创建一个单一的模型,可以从连续和阶段两个角度进行观察,包含相同的过程改进基本信息;处理相同范围的一个CMMI过程能够产生相同的结论。统一的CMMI(U-CMMI)是指产生一个只有公用方法和支持他们的KPA组成的模型。当按一种概念性的可伸展的方式编写,并产生了用于定义组织的特定目标过程模版,定义的模版构件将定义一个模型以适用于任何工程或其他方面。
  CMMI与CMM差别:
  CMMI 模型的前身是 SW-CMM 和 SE-CMM,前者就是我们指的CMM。CMMI与SW-CMM的主要区别就是覆盖了许多领域;到目前为止包括四个下面领域:
  (1)、软件工程(SW-CMM)
  软件工程的对象是软件系统的开发活动,要求实现软件开发、运行、维护活动系统化、制度化、量化。
  (2)、系统工程(SE-CMM)
  系统工程的对象是全套系统的开发活动,可能包括也可能不包括软件。系统工程的核心是将客户的需求、期望和约束条件转化为产品解决方案,并对解决方案的实现提供全程的支持。
  (3)、集成的产品和过程开发(IPPD-CMM)
  集成的产品和过程开发是指在产品生命周期中,通过所有相关人员的通力合作,采用系统化的进程来更好地满足客户的需求、期望和要求。如果项目或企业选择IPPD进程,则需要选用模型中所有与IPPD相关的实践。
  (4)、采购(SS-CMM)
  采购的内容适用于那些供应商的行为对项目的成功与否起到关键作用的项目。主要内容包括:识别并评价产品的潜在来源、确定需要采购的产品的目标供应商、监控并分析供应商的实施过程、评价供应商提供的工作产品以及对供应协议很供应关系进行适当的调整。
  在以上模块中,企业可以选择软件工程,或系统工程,也可以都选择。集成的产品和过程开发和采购主要是配合软件工程和系统工程的内容使用。例如,纯软件企业可以选择CMMI中的软件工程的内容;设备制造企业可以选择系统工程和采购;集成的企业可以选择软件工程、系统工程和集成的产品和过程开发。CMMI中的大部分内容是适用各不同领域的,但是实施中会有显著的差别,因此模型中提供了"不同领域应用详解"。
  CMM的基于活动的度量方法和瀑布过程的有次序的、基于活动的管理规范有非常密切的联系,更适合瀑布型的开发过程。而CMMI相对CMM更一步支持迭代开发过程和经济动机推动组织采用基于结果的方法:开发业务案例、构想和原型方案;细化后纳入基线结构、可用发布,最后定为现场版本的发布。虽然CMMI保留了基于活动的方法,它的确集成了软件产业内很多现代的最好的实践,因此它很大程度上淡化了和瀑布思想的联系。
  在 CMMI 模型中在保留了CMM阶段式模式的基础上,出现了连续式模型,这样可以帮助一个组织以及这个组织的客户更加客观和全面的了解它的过程成熟度。同时,连续模型的采用可以给一个组织在进行过程改进的时候带来更大的自主性,不用再象CMM 中 一样,受到等级的严格限制。这种改进的好处是灵活性和客观性强,弱点在于由于缺乏指导,一个组织可能缺乏对关键过程域之间依赖关系的正确理解而片面的实施过程,造成一些过程成为空中楼阁,缺少其他过程的支撑。两种表现方式(连续的和阶段的)从他们所涵盖的过程区域上来说并没有不同,不同的是过程区域的组织方式以及对成熟度(能力)级别的判断方式。
  CMMI 模型中比CMM 进一步强化了对需求的重视。在CMM 中,关于需求只有需求管理这一个关键过程域,也就是说,强调对有质量的需求进行管理,而如何获取需求则没有提出明确的要求。在CMMI的阶段模型中,3 级有一个独立的关键过程域叫做需求开发,提出了对如何获取优秀的需求的要求和方法。CMMI 模型对工程活动进行了一定的强化。在CMM中,只有3级中的软件产品工程和同行评审两个关键过程域是与工程过程密切相关的,而在CMMI中,则将需求开发,验证,确认,技术解决方案,产品集成这些工程过程活动都作为单独的关键过程域进行了要求,从而在实践上提出了对工程的更高要求和更具体的指导。CMMI中还强调了风险管理。不像在CMM 中把风险的管理分散在项目计划和项目跟踪与监控中进行要求,CMMI3级里单独提出了一个独立的关键过程域叫做风险管理。
  CMMI标准名词术语
  1 AT Assessment Team 评审小组
  2 ATM Assessment Team Member 评审小组成员
  3 BA Baseline Assessment 基线评审
  4 CAR Causal Analysis and Resolution 原因分析与决策
  5 CBA CMM-Based Appraisal 基于CMM的评价
  6 CBA-IPI
  CMM-Based Appraisal for Internal Process
  Improvement
  为内部过程改进而进行的基于CMM的评价(通常
  称为CMM评审)
  7 CC Configuration Controller 配置管理员
  8 CF Common Feature 公共特性
  9 CFPS Certified Function Point Specialist 注册功能点专家
  10 CI Configuration Item 配置项
  11 CM Configuration Management 配置管理
  12 CMM Capability Maturity Model 能力成熟度模型
  13 CMMI Capability Maturity Model Integration 能力成熟度集成模型
  14 COTS Commerce off the shelf 商业现货供应
  15 DAR Decision Analysis and Resolution 决策分析与制定
  16 DBD Database Design 数据库设计
  17 DD Detailed Design 详细设计
  18 DP Data Provider 数据提供者
  19 DR Derived Requirement 派生需求
  20 EPG Engineering Process Group 工程过程小组
  21 FP Function Point 功能点
  22 FPA Function Point Analysis 功能点分析
  23 FR Functional Requirement 功能性需求
  24 GA Gap Analysis 差距分析
  25 ID Interface Design 接口设计
  26 IFPUG International Function Point Users Group 国际功能点用户组织
  27 IPM Integrated Project Management 集成项目管理
  28 IR Interface Requirement 接口需求
  29 KPA Key Process Area 关键过程域
  30 KR Key Requirements 关键需求
  31 LA Lead Assessor 主任评审员
  32 MA Measurement and Analysis 测量与分析
  33 MAT Metrics Advisory Team 度量咨询组
  34 MCA Metrics Coordinator and Analyst 度量专员
  35 ML matreraty library 度量数据库
  36 NFR Non-functional Requirement 非功能性需求
  37 OC Operational Concept 操作概念
  38 OID Organizational Innovation and Deployment 组织革新与部署
  39 OPD Organizational Process definition 组织过程定义
  40 OPF Organizational Process focus 组织过程焦点
  41 OPL Organizational Process Assets 组织过程财富
  42 OPP Organaizational Process Perormance 组织过程性能
  43 OSSP Organization’s Set of Standard Process
  组织标准过程集合
  44 OT Organizational Training 组织级培训
  45 PA Process Areas 过程域
  46 PAT Process Action Team 过程行动小组
  47 PB Process Assets Library 过程财富库
  48 PD Preliminary Design 概要设计
  49 PDSP Project Defined Standard Processes 项目定义标准过程
  50 PI Produce Integration 产品集成
  51 PLC Product Life Cycle 产品生命周期
  52 PMC Project Monitoring and Control 项目监控
  53 PP Project Planning 项目策划
  54 PPQA Process and Product Quality Assurance 过程与产品质量保证
  55 PPR Price Performance Ratio 性能价格比
  56 QA Software Quality Assurance 软件质量保证
  57 QA Quality Assurance 质量保证
  58 QAP Software Quality Assurance Plan 质量保证计划
  59 QPM Quantitative Project Management 量化项目管理
  60 RD Requirements Development 需求开发
  61 RM/ReqM Requirements Management 需求管理
  62 RSKM Risk Management 风险管理
  63 RTM Requirement Traceability Matrix 需求跟踪矩阵
  64 SAM Supplier Agreement Management. 供应协议管理
  65 SC Steering Committee 指导委员会
  66 SCAMPI
  Standard CMMI Assessment Method for
  Process Improvement 过程改进CMMI标准评审方法
  67 SCCB Software Configuration Control Board 软件配置管理控制委员会
  68 SCM Software Configuration Management 软件配置管理
  69 SDP Software Development Plan 软件开发计划
  70 SEI Software Engineering Institute (美国)软件工程学院
  71 SEPG Software Engineering Process Group 软件工程过程组
  72 SPI Software Process Improvement 软件过程改进
  73 SPP Software Project Planning 软件项目策划
  74 SPTO Software Project Tracking and Oversight 软件项目跟踪与监控
  75 SR System Requirements 系统需求
  76 SRS Software Requirement Specification 软件需求规格
  77 SSM Software Subcontract Management 软件分包管理
  78 SSR Software System Requirement 软件系统需求
  79 TS Technical Solution 技术解决方案
  80 UC Use Case 用例
  81 UID User Interface Design 用户界面设计
  82 VAL Validation 确认
  83 VER Verification 验证
  84 WBS Work Breakdown Structure 工作分解结构
  85 WP Work Products 工作产品
  86 Pre-assessment 预评审
  87 Baseline 基线
  88 Quality Attribute 质量属性
  89 Scenario 场景
  关键字:CMMI,SCAMPI,过程改进,能力成熟度,EPG
  软件能力成熟度模型(CMM/CMMI)已成为IT业界通用的过程体系,是一条提高软件企业产品质量、增强企业核心竞争力的有效途径,它给软件企业带来的成功已经为许多国内、外著名软件厂商所证明,根据SEI的统计,软件企业在引入CMM后劳动生产率平均增长了35%;错误比率平均减少39%;平均成本回报率为5:1。 纵观国内自1993年开始Motorola(中国)实施起,至后来的东软、金蝶、用友等公司纷纷实施CMM或CMMI,国内企业实施CMMI一时间方兴未艾。但是大部分的企业(近60%的企业)实施CMMI收效不甚理想,最终走向失败,究其原因有多种,例如EPG人员素质不够,EPG团队松散,仅为了得到一纸证书,而忽略了过程改进项目对企业本身的重要程度,种种这些原因其根本核心就是EPG组建。作为全国CMMI咨询能力第一的企业,在EPG组建上有着深刻的理解以及丰富的经验。在EPG组建具体有以下四个步骤:
  1、 EPG人员要求
  过程改进实施人员如果没有足够的软件工程背景,在组织中亦无足够的能力完成其所担当的任务,则可能导致实施项目失败。因此必须选择那些有经验、有能力的员工参与的实施过程中来,充分发挥他们在企业里的正面影响力。
  基本操作方法是:咨询公司与客户交流,并提出EPG人员所需要具备的相关条件,客户根据咨询公司提供的人员条件,结合本公司具体人员情况,提供EPG小组成员名单,
  2、EPG人员确定
  在客户方提供的EPG小组成员名单的基础上,咨询顾问与客户进行交流并筛选其中不符合要求的人员,并最终确定EPG各成员。EPG成员一旦确定,就要保持其稳定性,忌人员流动频繁,从而导致过程改进项目成本上升。
  3、 组织
  人员确定完毕后,将人员组织起来形成EPG项目团队,建立EPG项目团队的共同愿景或目标,确保成员均同意并接受目标,同时需要建立共同的价值观及信念,使成员相信过程改进项目是可行的、必要的,更是重要的,并且能为企业带来高效率、提高企业产品质量的。同时,在本阶段需要明确以下几点:
  (1)明确各EPG项目成员所担当的任务及职责,并以文档的形式予以保存;
  (2)确保时间表获得众人的支持;
  (3)保证EPG团队拥有所需的资源;
  (4) 建立完善的记录和信息沟通系统;
  (5) 制定团队规范;
  4、 培训
  在明确了相应的任务之后,为了使得过程改进项目能够顺利并有效的实施,咨询顾问需
  要对项目组成员进行相关内容的培训,对CMMI模型进行深入了解和学习,培养EPG的工作技能,包括其会议管理能力,项目管理能力等,使其更深刻理解自己所担当的任务以及如何去制定计划直至完成。
  5、 EPG计划
  在给项目成员进行相关知识的培训之后,项目成员对CMMI的基本知识有所了解,在这
  样的基础上,咨询顾问与EPG成员一起,结合企业的实际情况,从实际出发,完成过程改进项目的具体计划,使得过程改进小组成员更进一步明确任务,对任务的细化以及各项任务的时间截点。
  6、 跟踪与监控
  对于CMMI过程改进项目来说,做好计划是前提,但后期的跟踪与监控更是关键,通过对过程改进项目计划的跟踪,对于在实施计划中出现的问题进行解决,并及时修改计划。如果没有很好的对计划的实施情况进行有效及合理的跟踪,很可能会导致我们的过程改进项目延缓或者脱离轨道,最终导致CMMI项目的失败。
  以上针对EPG组建的方法及需要注意的问题进行了一定的诠释,公司从事多年的过程改进项目,根据多年来的经验,CMMI项目要成功,每一阶段都需要付诸很多的努力, “一子错,满盘皆落索”,因此,在EPG组建环节更要引起重视!
  声明:本文版权归科技所有,转载请注明作者及出处。
  五个成熟度级别之间的比较如下:
  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)定义了软件项目的标准,并相信它,遵循它。
  (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)有计划地按人员的角色进行培训c
  技术
  在定性基础上建立新的评估技术。
  度量
  (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级别中有着同样的想法。就像我曾经提到的,敏捷开发是使用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最主要的工作应该深入到研发第一线,帮助研发人员解决研发过程中面临的最严重的实际问题(当然是解决方案要上升到过程高度,而不应是单个问题或个人),甚至哪怕是一些不严重但以你的项目经验知道该如何解决的问题上。总体说来就是掌握项目进展中的任何细微的技术难点要点,并主动记录下来。
  为什么这么说呢?CMMI实施的主要宗旨就是以每个项目为采集数据的源头,达到企业整体效益提升和资源重用。真正有价值的东西,是需要一线人员在实际工作中遇到问题,解决问题,并总结问题,不是一个一线工作的流水帐。就象一份研发人员的日报。写了上午做什么,下午做什么。这对企业的积累有什么用处呢?他工作过程中,遇到什么问题,他是怎么解决的,走过什么弯路,实验过几种方法,失败了,失败的原因是什么,最后选择了什么方法,可能不是最好的,但完成了任务,达到了效率和资源分配的平衡。这些东西才可能是未来类似项目中,遇到类似问题时,可能有参考价值的。通常也是EPG个人职业生涯的技术积累。只有公司里每个员工,把自己认为最有价值的积累贡献出来。才可能达到公司有价值的积累。而决不是形式上写的上午下午每个小时的流水帐。
  明白了上面的说的CMMI的目的,做为一个合格的EPG,就应该具备以下的素质:
  1、明白什么是有价值的积累,先是对你个人,然后才是顺便帮公司做了积累。
  2、深入一线,发现她们并忠实地记录她们。CMMI里的SP、GP,只是帮助你,提醒你在哪个环节,哪些东西可能是有价值了。你去收集一下,别视而不见了。因为还有一个企业和你个人的角度不同,立场不同的问题。例如,REQM里收集需求,对个人技术方面的积累虽然不多,但对企业是至关重要的,一次需求变更,没详细写清楚,忘记了到客户那里去签字落实,可能就会给企业造成很大的损失。做为一个合格的EPG,是需要有这份责任和义务把每个环节都做到最好,这是职业道德所在。同时也是对自我延伸的一个好机会,学会一些和人的沟通,倾听,把专业的东西以平易的方式表达。这些也都算是EPG额外的收获。
  通常情况下,为了按时按量完成项目,一线的骨干,对写日报、周报、文档都很不屑。EPG也很迁就,事后再补,这也不失为一个提高效率的好办法。但过去一个月半年了,我们正常人的记忆都能想象,很难记住细节。无非就是敷衍。这也在情理之中。你总不能让一个明天就要交东西的小组,今天晚上在通宵努力解决BUG的同时,还写什么报告,这也不尽人情。但作为EPG不能只把眼光集中在这妇人之心上。要想的更远。为什么会把项目推到这么晚,BUG还没解决完?难道要永远这样下去吗?项目中是有很多不可预测的因素,甚至是开发人员常说的"手气问题","人品问题"。但这些是需要控制的,也是通过经验可以控制的,所谓艺高人胆大。艺的高低,就是经验的积累决定的。
  那怎么解决这种两难的问题呢?逼着技术骨干写心水,人家没时间也的确压力很大。不写,公司又得不到有效积累,积累的都是垃圾流水。有个公司的办法和经验到可以借鉴一下:
  公司内部搞了个BBS,把不同类型的工作分成不同的组,有纯技术的,JAVA组,C++组等,也有PPT组,甚至动画组,界面组。大家把自己平时的工作积累FTP上去,甚至制作方法,遇到问题和解决方法的文档都丢上去,开始怎么想,用了多少套方案,最后选择了什么。自我感觉如何。把这些心路历程都写成文档。丢到阳光下,大家评论。用点击率和"顶"的人数来说明谁写的是心水,谁在写垃圾。大家都是一个公司的,很容易实名。直接纳入考核机制中。做为一线人员,大家也有动力来写,自己的聪明才智有了展现的平台,虚荣心和荷包都得到了相应的满足。何乐而不为呢?
  EPG适时的评估大家的成果,并把他们分到项目里。帮助项目总结,甚至在平时遇到问题时,直接帮助技术人员做必要记录。项目进度松时,再督促项目人员完善内容。以达到对个人和公司积累的最大化。
  EPG应该明白学习和积累是个终身的过程,对公司如此,对个人也是如此。CMMI是个辅助,辅助我们对公司做积累,也帮助我们个人做必要的积累。公司需要逐步走向更高的管理水平,发展平台。
 

 实施流程编辑本段回目录

  阶段1:CMMI项目启动会
  明确企业实施CMMI的商业目标,建立CMMI项目实施的沟通机制。
  阶段2:CMMI基础培训和过程改进小组(EPG)组建
  进行CMMI基础概念讲解,指导企业建立核心的过程改进小组。
  阶段3:诊断
  充分了解企业研发过程现状,识别企业现有软件过程与企业现阶段理应达到的的CMMI成熟度级别的差距,提交诊断报告,进行过程改进的策划。
  阶段4:过程域培训和文件定义
  结合企业过程现状进行CMMI过程域培训,通过举例、案例分析等方式,让企业的EPG掌握过程文件定义技巧,结合企业实际情况有针对性的定义组织的研发过程,并确定过程产出物(如:需求报告)
  阶段5:项目试点
  选择代表公司核心业务的项目或者典型项目进行试点,通过试点来完善过程文件,从而为企业全面推广过程文件打下基础。
  阶段6:组织推广
  全员参与全面导入与执行CMMI。
  阶段7:预评估
  验证组织推广的结果,识别企业尚存缺陷并制定再次改善方案,准备充分,以便企业能够更好进行正式SCAMPI评估。
  阶段8:SCAMPI正式评估
  由SEI授权的主任评估师领导,采用SCAMPI ( Standard CMMI Appraisal Method for Process Improvement)评估方法,对企业的能力成熟度进行正式的评估,颁发证书,通过SEI网站向全球发布企业信息。

CMMI向何处去?编辑本段回目录

    金秋十月,第七届CMMI研讨会(Seventh Annual CMMI Workshop)在美国佛罗里达州奥兰多市举行。作为全球SCAMPI主任评估师、CMMI讲师和合作伙伴的年度聚会,CMMI研讨会是主任评估师、讲师等过程改进专家面对面交流的重要机会,也是一年以来全球软件过程领域发展状况和后续发展趋势的重要场所。

    笔者作为候补主任评估师,有幸参与了本次CMMI研讨会。会上同近十位主任评估师就中国大陆CMMI的现状与问题——评估数量与质量的矛盾——进行了深入的交流,并结合本次研讨会上发布的CMMI评估的官方数据,以及CMMI V1.3版本的升级计划,就如何缓解“做大”与“做强”的矛盾给出了初步的分析。

    CMMI实施现状

    根据研讨会提供的资料显示,每年实施CMMI评估的组织和从业者的注册数量都有较大增长。2008年较2007年实施的CMMI正式评估组织数增长了32.8%,参与评估的项目数增长了44.6%,其中根据CMMI V1.2版本增补的三年有效期的要求,重新实施的评估增长了56.2%。截至2009年8月,已经有超过10.6万人注册并通过了CMMI概述课程,近3000人完成了CMMI中阶课程;目前通过授权/认证的CMMI讲师达432人,SCAMPI主任评估师达521人(近300人已经完成认证转换),高成熟度主任评估师达150人,构成了初中高各个层次的CMMI从业者的金字塔型架构。全球目前已经有超过60个国家实施了正式评估,其中25个国家的评估通过组织数超过10个——美国以实施1272个评估高居榜首,中国大陆以745个位居第二,接下来是印度、日本、法国、韩国和中国台湾。具体参见表1:
 

CMMI向何处去?

    简单的分析一下上述数据就可以清楚的看到,中国大陆的评估个数正在以每年200家以上的速度迅速完成“量”的突破,不仅迅速超过了韩日等东亚近邻,而且将以软件外包闻名并将CMMI作为欧美外包敲门砖的印度落在身后。迅速做“大“,一方面说明国内软件企业更加重视国际市场的开拓并取得了长足的进步,另一方面也不得不看到数量上的增长是具有中国特色的——政府对CMMI认证的资助起到了重大的推波助澜的作用。
 
    但是稍微挖掘一下数字背后的故事,几个看似微小的差距需要我们清醒的看到长足进步现象下的风险。首先是连续式的评估在全部评估占比,欧美日等软件强国的比率均在10%以上,欧洲更是在15%以上——相对于阶段式评估,连续式应该是结合组织实际持续改进更有针对性的选择。第二,从不同等级的占比分析,中国大陆的3级评估的比率高达72%,5级的比率仅占6%;而全球的平均水平是3级的比率不到50%,5级的比率约占12%,说明我们仅仅是个评估“大”国,远非“强”国。第三,从1级评估个数与比率分析,以自律严格和质量立国著称于世的德日两国分别高达14%和6%,侧面说明了其评估过程的严格与评估质量的过硬。只有正视我们在发展中与传统质量强国的差距,才能进行有效且具针对性的改进和赶超。

内容导航

    CMMI实施与SCAMPI评估的问题

    作为2009年度的重大事件,在3月发布了用于服务领域的CMMI–SVC模型系列,并为推广该模型系列紧锣密鼓地实施了相关的评估师培训与认证,并于6月开始接受该系列正式评估的申请。目前CMMI模型已经升级为包括开发、采购、服务三个系列,涵盖16个核心过程域,以及过程管理、项目管理、支持、工程、采购和建立并交付服务六个领域的综合体系。CMMI模型的应用范围也从IT行业扩展到服务相关的众多领域。如何进一步降低模型的复杂度,同时提高评估的效率,从而减少实施组织的负担,是CMMI面临的重大挑战。

    在研讨会上发布的2006年以来每年评估师实施正式评估数量Top10的数据(具体参见表2)和演讲中披露的评估结果报告系统(SAS)中发现的众多问题——与会同行对评估数量的激增和评估质量的担心都可见一斑。尤其是2008年某位主任评估师完成正式评估数创下了高达34次的“记录“,被与会同行反复提及。
 

CMMI向何处去? 

    考虑每年仅有52周工作时间,而且各国还都有十多天的法定假日,以及每次正式评估之前按照SCAMPI MDD的要求必须实施的评估小组培训与就绪性检查的工作量,难道这位”辛勤”的主任评估师是掌握时空穿梭大法且身体超健康的“超人“一族?

    为缓解上述评估质量相关的问题,尤其是澄清对高成熟度过程域的理解与实施中的重大偏差。SEI在2008年11月发布了对所有高成熟度评估实施审计的要求以及审计的标准,并在2009年5月更新了3个评估质量相关的政策:0020-R 、0021-R 、0022-R,扩展了对评估结果实施审计的范围,明确了评估审计未通过以及暂停评估师资质的标准,定义了对CMMI评估审计未通过结果的申诉过程。上述政策的更新,形象地说就是给主任评估师带上了“紧箍咒“,希望通过主任评估师的授权方式转为认证方式,评估政策的升级以及后续的模型升级等措施,有力地遏制评估质量无法保证的问题;将高成熟度评估作为突破口,警示某些违反SCAMPI MDD和评估职业操守的评估师。
 

内容导航

    CMMI模型的升级

    研讨会上明确的发布了如下日程表——模型的升级采用变更请求驱动的方式,已经自2009年1月正式启动,并计划于2010年11月发布升级的CMMI V1.3版本。
 

CMMI向何处去?

    为了确保版本升级的质量,模型升级的CCB批准了对CMMI产品系列(即,模型、培训材料和评估方法等)的所有变更必须符合以下主要标准:

    1) 更正已识别出的模型、培训材料和评估方法的缺陷,或者进行增强;
    2) 根据需要,合并扩展和注释的内容;
    3) 增加潜在的由CMMI指导小组确定的特定方向 (即,安全、保密、生命周期等) 的模型扩展;
    4) 尽可能减少V1.3版本的整体模型规模; 仅对绝对必要的内容才进行增加;
    5) 模型和方法的变更,应避免对适用公司和组织的已有投资的不利冲击;
    6) 对模型架构的变更,将只能在特定CMMI指导小组授权下实施;
    7) 只有源自变更请求或CMMI指导小组的变更,才被接纳;
    8) 对培训资料的变化,将在V1.3版本正式发布前完成;
    9) 变更将不会导致几乎10万名(截至2008年12月) 已经完成CMMI概述培训的人员的再培训。升级培训也许是需要的,特别是对讲师、主任评估师和评估组成员。

    V1.3版本关注于高成熟度过程域的澄清、共性实践的简化、评估过程效率的提高和模型系列之间的一致性。在模型整体架构方面,需求管理(REQM)过程域从工程领域调整到项目管理领域,共性目标、共性实践和其扩展说明将统一在模型的第二章中进行集中描述。

    对高成熟度过程域的澄清包括了对组织过程性能(OPP),量化项目管理(QPM),原因分析和解决(CAR)和组织创新和部署(OID)四个过程域中实践活动的改进、对五级的两个过程域作用的澄清、对原因分析和解决过程域在二级和三级的应用说明。通过澄清基于统计管理的子过程和项目管理的联系,升级和解释高成熟度的一些术语,平衡必要的、期望的和提示的模型组件的要求,并适当增加高成熟度实践活动的说明和案例,使主任评估师以及实施组织能充分理解模型。

    共性目标、共性实践相关的改进包括精简共性目标2的相关实践,对共性实践GP2.8和GP3.2的澄清,删除能力度4级/5级的共性实践等,以达成对共性目标和实践的简化。模型升级后,可能将GG2下的10个共性实践简化、合并到仅保留GP2.1建立组织级方针、GP2.2策划过程、GP2.8跟踪和监控过程三个共性实践,目前的GP2.3至GP2.10的绝大部分内容将合并到GP2.2,同时部分GP2.10的内容在对高层管理进行澄清后并入GP2.8。合并的同时,将现有GP2.2和GP2.8进行一致性匹配,以便发挥PDCA模型的循环改进的作用。将现有的GP3.2的描述从“搜集由策划和执行过程所衍生的工作产品、度量、度量结果及改进信息,以支持组织过程与过程资产的未来使用与改进“调整为”搜集由策划和执行过程所衍生的信息,以支持组织过程在未来的使用与改进“。

    在从SW-CMM升级到CMMI时,将配套的评估方法从关注证据发现的CBA-IPI方法升级到关注证据验证的SCAMPI方法,目的就是节省评估时间。数据证明,PIIDs的使用有效地减少了现场评估的时间。然而,如果组织花费过多的时间用于准备PIIDs,就需要SCAMPI升级团队研究不增加准备工作费用前提下,仍可保持现场评估效率的途径。作为CMMI升级团队的一部分,他们正在寻找达到这个目标的创新方式。除了通过CMMI模型的精简和澄清,从而明确SCAMPI评估范围和准确性,提高SCAMPI评估的效率外,还希望通过改进就绪性检查阶段的证据收集、对证据抽样方式以及使用的“逆向“PIIDs,进一步优化评估方法、提高效率。

    除此之外,研讨会还特别强调了CMMI和敏捷方法的协调,使过程改进组织能够利用两者协同使用。例如在技术解决方案过程域的特定目标1:评价不同的技术解决方案中,增加采用敏捷方法的注释。
虽然CMMI模型的系列、应用范围有了大幅扩展,但是通过V1.3的升级对CMMI模型本身进行“瘦身“,对评估方法进行”提速“,对模型配套的培训课程进行完善。

    三天的会议紧张而充实,虽然饱受时差的煎熬,依然抵不住与各国主任评估师同行面对面交流的兴奋。尤其是在和与会的中国大陆各位主任评估师的交流中,既感受到大家对评估市场“重数量、轻质量“现状的担忧,同时也感受到大家对CMMI-SVC覆盖的更大市场的关注,以及期望国内过程改进从业者(尤其是咨询顾问)提高自身知识、技能和经验的迫切心情。虽然评估师的能力不尽相同,评估对象的成熟度也确有差距,但是正如中国大学扩招后到处都是本科的情况类似——客观地讲,从不同大学毕业的应届生的水平还是有一定的差距。主观的希望一刀切,一定要求所有应届生具备同样的知识、技能,是不现实也是不可行的。

    当前在中国大陆CMMI评估市场上存在的问题,并非中国独有。作为过程改进的“从业者”,国家部委和各地政府是否结合逐步回归理性的“科技园”热的降温,避免扶持政策的简单化——扶持资金的政府主管机构和咨询公司携手“垄断”本地认证——可以考虑将政府资助从单一只认证书转向更多关注评估过程和评估质量?各位主任评估师也都在获得认证时签署过相关承诺,是否更应该严格遵守职业操守?对于CMMI评估市场的既得利益者——咨询公司是否要适当考虑行业的可持续发展,获得利益的同时避免“杀鸡取卵”的破坏性竞争?企业内的EPG是否切实从商业目标入手,提高对组织内部改进实效的关注,少谈“主义”,为项目组提供有效地支持和服务?诸多问题,总体还是前进中的问题,适逢经济危机爆发的“盘整”阶段,希望各方抓住调整的机遇,共同为充分发挥基于CMMI认证的过程改进献计献策。

    回国后,得知由中国软件行业协会主办、中国软件行业协会系统与软件过程改进分会(CSPIN)承办的“CSSPI 2009第八届中国系统与软件过程改进年会”即将于11月19-21日在京召开,我非常的高兴。过程改进年会是我国过程改进领域最具有影响力的盛会,会议规模庞大,参与的人员大部分都是过程改进领域的专家、企业家、政府领导,会议的内容注重软件企业最佳实践交流分享,是对过程改进领域本年度动态的盘点,也是对未来发展方向的预测,今年的大会主题更是贴进企业生存问题--“危•机—聚焦中国软件服务化时代的生产力”。作为CSPIN专家组的成员,我将全力支持大会的组织工作,也希望届时能与国内外同行展开面对面的深入、广泛的探讨。



→如果您认为本词条还有待完善,请 编辑词条

词条内容仅供参考,如果您需要解决具体问题
(尤其在法律、医学等领域),建议您咨询相关领域专业人士。
1

标签: CMMI

收藏到: Favorites  

同义词: 能力成熟度模型集成

关于本词条的评论 (共0条)发表评论>>

对词条发表评论

评论长度最大为200个字符。