CMM改善不了软件的质量

发表于:2007-8-01 11:35

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:邹大斌    来源:网络转载

#
CMM
分享:

        这是几年前采访著名软件专家Ivar Jacobson博士后写的文章,最近在我的电脑中偶然看到.联想到最近,有好几次与一些软件企业交流,又听到他们在谈CMM/CMMI,所以,贴出来和大家分享。尽管写这篇文章的时候是2005年8月左右,不过,我觉着仍任有必要重提:不要把CMM当成灵丹妙药。

  Ivar Jacobson博士认为,如果采用不良的软件过程,通过CMM/CMMI的成熟度级别越高,只会使软件企业生产不合格软件的过程更加有效率,而不是使企业开发出更好的软件。

  CMM改善不了软件的质量

  软件外包是时下的一个热门话题,被我国不少软件企业视为一座金矿,而CMM被人们认为是进入这个市场的敲门砖,为了拿到那张代表资格的CMM认证证书,不少企业甚至不惜投入数百万之巨。事实上,拿到CMM认证在国外并不代表企业就能提供一个合格的软件,著名的软件专家、拥有组件技术、用例技术等多项发明、与Grady Booch、James Rumbaugh一起被称为UML之父的Ivar Jacobson博士在近期访华期间一再提醒中国的软件企业,谨防掉入CMM陷阱。

  CMM/CMMI的缺点

  CMM/CMMI最早起源于美国国防部。为了改变在采购过程中频繁地采购到大量不合格软件的局面,美国国防部需要一种评估软件质量的方法,这就是要求软件企业进行CMM/CMMI认证。然而,CMM/CMMI真正解决这个问题了吗?

  CMM/CMMI被认为是一种最成熟、最有效地提高软件工程化水平的方法和标准,用来评估和改进过程,它是一个描述在软件开发过程中有待改进的关键因素的框架,描述了一个能用渐进方式进行改进的途径。它为软件过程改进提供一个基础,将软件开发从一个相对来说随意、不成熟的过程变成非常成熟的、有规律的、可管理的过程。

  然而,CMM/CMMI也有一些与身俱来的缺点不容忽视。比如,CMM/CMMI的评估耗资不菲,一个CMM2级评估就可能达到数百万之巨,而且耗时很长,过程十分复杂,常常导致效果不太理想。不少企业的认证流于形式,评估完成后就只留下一大堆文档,而真正的软件开发过程却依然故我。而且,CMM/CMMI只告诉我们应该怎么做,而没有具体地告诉如何做。比如说,它要求必须改进需求管理,那么到底该如何做需求管理?CMM/CMMI没有提供答案。

  还有最重要的一点是,不少软件企业陷入了一个误区,以为单单通过CMM/CMMI评估就可以解决软件质量不高的问题,而忽略了软件过程这一真正改善软件质量的环节。事实上,完全有可能出现这样的情况: 软件成熟度为CMM 1级或2级的企业开发出的软件是真正好用的,而有的企业即使通过了CMM 5级认证,也无法保证它交付好的软件。最糟糕的情形是,如果采用不好的软件过程,通过CMM/CMMI的成熟度级别越高,只会使软件企业生产差劲软件的过程变得更加有效率,而不是使企业开发出更好的软件。

  Ivar Jacobson认为,好的软件过程首先一定是基于组件的,在此基础之上,还要符合迭代开发、用例驱动开发和以架构为中心的这三个最佳实践。

  合理的软件过程是软件质量的基础

  为什么会是这样呢,Ivar Jacobson举了一个非常形象的例子。这是一个农夫和他的奶牛的故事。在奶牛喝水的途中(称为“牛路”)有一片庄稼地,牛会吃掉很多庄稼。农夫看到这种情况后,意识到必须对奶牛喝水的过程进行改进,所以他就在这条道路上铺上了沥青。结果,农夫得到了一个好的“牛路”,牛走得更快了,但是并没有真正解决牛吃庄稼的问题。它应该有更好的方式,就是为牛喝水寻找一条全新的道路。

  软件企业利用CMM框架进行软件质量控制的过程,就像是这个农夫为牛路铺沥青。对于软件企业来说,如果从一个错误的软件过程开始,即使你在这个上面再改进,得到的永远只是“牛路”。这里更应该考虑的是要选择一条更好的路,也就是从一开始时,就采用能够开发出好的软件的过程。然后在这个软件过程的基础上,对这个软件进行度量,改进这个软件的过程,也就是进行CMM/CMMI要求的改进。 B8up

  Ivar Jacobson博士认为,从一个不良的软件过程出发,在此基础上进行改进,实际上会把软件开发变得更糟糕,因为你把软件开发过程固化了,使日后再想对它进行改造,变得更加困难。正确的方法是,先要有一个好的软件过程,这是不容易的,但是值得做的事情。Ivar Jacobson 说,“把一个好的软件过程变得可度量非常容易,但是把一个可度量的软件过程变成一个好的软件过程却很难”。也就是说,只有把一个好的软件过程,即能够开发出好的软件的过程变得可度量才是有益的。而把一个已经经过CMMI改进的、可度量的过程变成一个真正的能够开发出好软件的过程,这是几乎不可能的事情。

  那么什么是一个好的软件过程?Ivar Jacobson建议从以下几个方面进行辨别: 第一,坏的过程关注文档上,而好的过程关注在可执行的程序或者系统上; 第二,坏的过程延误了揭露风险的时间,而好的过程一开始就把自己暴露在风险之下,并及时解决它; 第三,坏的过程在项目的最后才能够验证这个项目的质量,而好的过程其质量是每时每刻都能够得到验证的;第四,坏的过程有一个非常复杂的跟踪关系矩阵,从需求到代码需要一个非常复杂的矩阵,而好的过程,却是一个无缝链接; 第五,在面对变更时,坏的软件很脆弱,好的软件会很健壮。

  Ivar Jacobson提醒软件开发人员要做聪明的农夫,首先得到一个正确的软件过程; 然后,再考虑去度量它、定义它。因为软件项目管理的本质不是能否描述并度量软件过程以及过程到底怎么样,而是首先关注软件,你是否能很好地开发出合格软件。重点是得到结果,通过软件过程得到这个结果,也就是交付的软件产品。

《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • svr678
    2007-8-18 15:50:47

    本文作者下一篇文章主题:
    a.衣服不保暖
    列举若干冻死并穿衣服者实例,同时引用某联合国卫生组织主管的屁话
    b.吃饭不顶用
    同上,作者例外,因为他已经不吃粮食了,haha
    c.。。。。。

  • svr678
    2007-8-18 15:47:33

    1.问题之一,Ivar Jacobson不代表软件行业的主流方向,顶多是一面之词,国内的某些“专家”照样有乱放的驴屁的!
    2.问题之二,标题哗众取宠,与内容严重脱节,唯恐人不咬狗而是狗咬人,建议作者调娱乐新闻板块,或者做个欠揍的狗仔比较和谐一些
    3.问题之三,过程本身属于方法论层面的精华,不是价值观,所谓“合理”+“正确”,如同钳子可以作为凶器一样,使用方法论的人使用不当不能一概而论说工具不好,文章本身缺乏基本的科学分析思路。
    4.问题之四,国内的“CMMI”走向ISO的怪圈,原因在于人祸不是iso和cmmi有问题,Ivar Jacobson这个好坏过程的主观判断在自己并没有好的解决方案并被实践验证前,已经是人祸的引子了,如果可以这样随便主观判断,还剩下什么不可以推翻,由此可见,Ivar Jacobson纯属放驴屁!居然后面还跟个崇洋媚外的闻屁虫!无耻!!!

  • allen_lu
    2007-8-16 10:48:25

    作者震得太偏激了,没法理解。
    “坏的过程关注文档上,而好的过程关注在可执行的程序或者系统上”真是搞笑呀,CMM/CMMI不是一个只关注文档的过程呀。懂不懂CMM/CMMI. 如果没有文档,你人员的变更会使你的软件崩溃,考虑问题太片面了。
    还有作者所谓的那个Ivar Jacobson 比喻也太不恰当了。CMM/CMMI应算一些regular,limits.  你要是给牛安个鼻拴,给他点限制。还有点那么回事。连牛都没放过,不相干的东西来大比喻,吓搞吗!哎。。。。。

  • ∮随风而去~
    2007-8-01 17:15:30

    CMM应该也是一个可以裁减做适当修改的过程嘛~
    是活的又不是死的~
    作者的观点太偏激了~
    应该说有指导意义,但不能当万能法宝~!

  • jiepeach
    2007-8-01 16:44:35

    重要的是态度和动机

  • 252090366
    2007-8-01 14:14:16

    CMMI也不象你说的那么无用!!!

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号