内容简介:CMMI(Capability Maturity Model Integration )——软件能力成熟度模型集成,一直以来都是各组织提高软件工程能力的行业标杆,我们的军用软件研制能力成熟度模型GJB5000标准也是来自于此。2018年CMMI 2.0正式发布,新的CMMI的理念、组织结构等必将对GJB5000带来不容忽视的影响。这些影响表现在以下几个方面:
CMMI(Capability Maturity Model Integration )——软件能力成熟度模型集成,一直以来都是各组织提高软件工程能力的行业标杆,我们的军用软件研制能力成熟度模型GJB5000标准也是来自于此。
2018年CMMI 2.0正式发布,新的CMMI的理念、组织结构等必将对GJB5000带来不容忽视的影响。
这些影响表现在以下几个方面:
-
全过程管理
之前的CMMI有22个过程域,但是过程域是分等级的,CMMI二级只有7个过程域,三级增加11个过程域,四级再增加2个过程域,五级组织才会涉及到全部22个过程域。
虽然CMMI评价有阶段式也有连续式,但对过程域的等级分割,已经在事实上让那些低等级的组织失去应用高等级过程域的兴趣。
GJB5000也是同理。
CMMI 2.0打破这种等级模式,它对这些过程域(2.0中称为实践域)不分等级,而是对每个实践分等级。 这也就意味着即使是CMMI初级组织(2.0中的实践等级从1级开始)也需要实施全部20个实践域(2.0中对过程域进行拆分整合后,共有20个实践域)。 这就是全过程管理的思想。
这种思想较之前的高级组织才适用全过程的思想要更为合理。 因为CMMI把软件开发活动分解为20个实践域的活动,那么,不管你组织的能力强弱、水平高低,这20实践域的活动都是不可缺少的,区别只是你做得是否到位而已。 而这个是否到位,就在于你实施了哪些优秀实践。
在实施GJB5000的时候,我们也都会意识到这个问题——实施GJB5000二级的组织就没有工程活动吗? 答案当然是否定的。 没有工程活动,软件项目就不会存在,这个道理显而易见。
CMMI 2.0也是看到了这样问题的存在,所以,它推行了全过程管理的理念,这也是实施GJB5000应当考虑的问题。
-
能力导向
正如SEI一直以来宣传的那样,CMMI集成这么多的优秀实践是为了帮助组织提高性能的。 这在CMMI 2.0中尤其重点强调。
而我们在推进GJB5000时,更多地强调标准化和规范化,对建立GJB5000体系提升组织的软件开发能力方面少有问津。 这是我们GJB5000应当改进的地方。
只强调标准化和规范化,会让组织对GJB5000抱有只付出没回报的错误印象,既不利于GJB5000推进,也让我们推进GJB5000的意义减半。
-
系统管理
CMMI本身就是多个模型的集成,系统和服务模型早已有之。 但在2.0中,这几种模型不再是分开的,而是融合在一起。 CMMI 2.0是开发模型、系统模型、服务模型通用的集成模型。 在一些实践的表述中,开发模型也是这些实践域的一个特殊应用场景。
GJB5000原来对应的是CMMI的开发模型,但在具体实施过程中,已经发现系统和软件管理的脱节、不匹配带来的诸多问题。 现在,我们军用软件开发组织应该考虑像CMMI 2.0集成模型那样,把系统管理也纳入到GJB5000的体系中来。
-
重视高层
我们都知道,体系的推进和变革是一把手工程。 但是,怎么才能让高层重视GJB5000体系的建设和实施,一直以来效果都不是很好。 原来的CMMI/GJB5000对于高层治理并没有什么具体的规定,只是以高层验证稍有提及; 再在GJB5000评价的时候辅以高层访谈以促进高层的重视而已。
CMMI 2.0中对此有了重大改变,它把治理(GOV)作为一个实践域提出来,给出了具体实施的优秀实践,对组织的高层管理软件过程管理体系提出了具体要求。
GJB5000应当从中借鉴经验,让高层管理者真正地重视、管理GJB5000体系。
-
夯实基础
之前的CMMI把实施各过程域所需的基础条件作为共用目标和共用实践,实际上效果并不是很好。
在GJB5000评价的时候,也都清楚发现的问题打在共用实践上,不痛不痒,根本不会引起被评单位的重视。
在CMMI 2.0中,将这些共性的基础要求也作为一个实践域提出来,并且实践要求也较之前更为具体。 比如,关于提供资源的实践要求中就明确: 除了提供人力、 工具 等资源之外,也包括资金和培训。
万丈高楼平地起,没有这些基础,GJB5000的实施效果必然会受到影响,所以,CMMI 2.0告诉我们GJB5000实施要重视基础。
-
合并整理
CMMI 2.0的实践域由之前的22个变为20个,这其中对多个过程域进行了整合: 比如需求开发和管理整合为一个实践域,验证和确认整合为一个实践域; 测量分析和定量项目管理整合为一个实践域等; 同时也把一些目标和实践从原来的过程域中拆分出来提升为一个实践域: 比如估计、评审、治理、基础等。
通过这样的拆分和整合,CMMI 2.0对软件开发过程的管理脉络更加清晰,更便于用户对CMMI的理解和使用,可操作性也有很大的提升。
对于过程域间的实践要求的重叠,评价员们在GJB5000评价的时候就深有体会——常常会有同一个问题与不同过程域的实践有关; 同一个工作产品和多个实践相关,按照过程域逐条实践评价的时候要不断地切换工作产品。
通过对实践域和实践的合并拆分,这些问题有望得到解决。
总之,CMMI 2.0的发布,给我们GJB5000的实施指出了多个改进的途径,我们应当借鉴其理念和思想,帮助我们进一步优化GJB5000体系。
这正是:
模型发布似花开,吸引蜂蝶采蜜来
深挖思想和理念,帮助五千上高台
作者简介: 王小双,长期从事GJB5000推广、实施、评价、改进的工作,创建《软件工程之思》微信公众号,一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。 现致力于GJB5000咨询以及软件过程改进、软件工程能力提升的研究工作。
以上所述就是小编给大家介绍的《花开有声——CMMI2.0对GJB5000的影响分析》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 人工智能对业务分析专业的影响?
- “一般数据保护条例”对数据分析及挖掘的影响
- Equifax公布数据泄漏分析报告:全美大半居民受事件影响
- 影响数千网站的第三方JavaScript库文件漏洞分析
- CVE-2019-0708漏洞影响面分析及采用多种规则的检测方法
- 通过可视化分析地理因素对多变量聚类的影响(Visualizing the Impact of Geographical Variations...
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。