提高软件质量的有效利器－度量

            曾记得1999年，国内对软件质量的认识还非常落后，当时的“英雄模式”非常盛行，很多企业认为“软件质量就是研发人员自身的事情，只要找几个编程英雄，软件质量就迎刃而解”，“如果某企业设置专职的测试工程师，会被大家认为是奢侈的事情”。
 
            曾记得1999年，国内对软件质量的认识还非常落后，当时的“英雄模式”非常盛行，很多企业认为“软件质量就是研发人员自身的事情，只要找几个编程英雄，软件质量就迎刃而解”，“如果某企业设置专职的测试工程师，会被大家认为是奢侈的事情”。然而事与愿违，我早期所在的公司(当时在国内外都非常有名)就是这样：招聘了很多的高级编程人员，启动了很多软件研发项目，并且花了很多的钱，但产品质量却仍然很差，很多新产品因质量问题根本无法投入市场，并且延误了市场先机;勉强投入市场的几个新产品却将公司的维护部门打入万劫不复的地步，因为维护部人员经常在凌晨2-3点被紧急电话叫醒“我是×郊县×局的，我们机房瘫痪了，立即来一趟”，甚至他们经常要在天寒地冻、刮风下雨的恶劣条件下熬夜。
            就在那一年，可能是公司认识到了质量的重要性和它的真实含义，把我从研发工程师转变成了一位质量工程师兼测试工程师，也许是我学过项目管理专业的缘故。从那时起，我知道了什么是ISO9000，什么是CMM,
            什么是TL9000。公司也花了几百万买了大量的软件工具，如Rational，CCC/Harvest，Telelogic，Numega等等。从此公司的质量开始演变为“测试模式”，最后变成“过程模式”。在过程模式下，我们把公司的软件产品开发的整个过程(从诞生到消亡)逐渐分解成许多可控制的标准小过程，按照ISO9000/TL9000/CMMI进行过程管理，别看这个变化不起眼，但它的效果却是惊人的。就象计算机软件技术从进程演变到线程一样，其实就是把进程拆成许多线程，却带来了软件执行效率的质的飞跃。关于如何更好地分解过程，软件产品开发应该包括哪些标准过程，ISO9000/TL9000/CMMI提供了很多非常好的实践和模型，我不在这里做详细的介绍了。
            但是我们发现，即使你把软件产品开发的过程分解到位、定义到位，甚至通过了CMMI5级评估，但实际执行地效果却不明显，软件质量可能丝毫没有提高。据官方2007年最新统计，中国通过ISO9000认证的公司数量在全球第一，通过CMM/CMMI评估的公司数量在全球第二，但中国软件产品的质量是不是也达到全球第一或第二了呢?答案是很明显的，我们的软件产品质量仍然很差，与国际水平还差一大截，这可以通过CSBSG/ISBSG的数据比对就能看出来。那么到底是为什么呢?我想最大的原因是忽视了过程本身的有效性，而太关注于“过级”。
            那么过程的有效性如何来评价和控制，答案就是度量。度量是唯一一个能永久驱动企业内部过程改进的动力。认证、评估、客户的要求、政府的资助，这些驱动力都是暂时的。通过度量，可以把企业每一个过程的有效性进行客观的评价，并与企业历史的度量数据进行纵向比对，也可以与行业的基准数据进行横向比对，从而找出自己的弱点和差距，进行针对性的改进。所谓“知己知彼，百战不殆”，应用到软件开发领域，也就是这个道理。度量将是真正提高软件质量的有效利器。
            那么如何来应用度量呢，我们可以举个例子。
            多公司在进行技术评审、测试等这些经典质量控制的活动中，往往流于形式，感觉效果不好。在评审活动中，往往因发现不了缺陷或只发现少量的轻微缺陷就判定这个评审顺利地通过，结果在后续的活动中或产品上市后却发现这些评审遗留了很多缺陷而没有被发现。如果我们能有效的利用度量来作为评审通过的判定准则，就可以避免或最大限度的降低这些错误。假设我们从CSBSG/ISBSG数据库中了解到，P50的企业在评审需求或设计的时候应该发现每页0.5个缺陷，在代码走查/单元测试时应该发现10个缺陷/千代码行，在系统测试时应该发现6个缺陷/千代码行。那么我们把这些基准数据作为我们评审、测试的通过准则，如果没有达到这些指标就表明评审活动或测试活动不有效，需要分析一下这些活动是否存在以下问题：如评委没有预读资料，评审会上大家在讨论解决方案或争论而不是在发现缺陷和确认缺陷，没有按照同行评审的规范进行等等。(注：P50是指在CSBSG数据库中查询到的排名在第50%的度量数据，不是指平均值。)
            关于度量应用的范围和例子还有很多，这里不再一一列举，主要向大家强调的是建立和实施我们自己的过程后，一定要对过程进行度量，来看看过程执行的效果，这样才能真正提高软件质量。

本页关键词：提高软件质量的有效利器－度量