软件测试：过程改进方法重于CMMI模型

发布: 2009-2-09 11:18 | 作者: 不详 | 来源: 测试时代采编 | 查看: 72次 | 进入软件测试论坛讨论

在实施CMMI的过程，理解CMMI模型的难点之一是理解模型，模型理解不深不透，就无法正确地判断是否达到了模型的要求，可能做了很多投入产出不成比例的活动，造成资源的浪费。在理解了模型之后，更大的困难在于如何在企业里推广CMMI模型。举个很简单的例子,按CMMI模型的要求，项目组应该进行估算：估算任务和工作产品的属性以及工作量等，对于软件开发，任务和工作产品的属性就是规模、复杂度、复用率等。CMMI模型只讲了要“做什么”，没有讲“为什么”、也没有讲“怎么做”。企业可以定义本组织认可的估算模型以解决怎么做的问题，但是，对于项目组的成员来讲，他们已经习惯了原来的作业方式，比如：只估计工作量，不估算规模。他们不清楚为什么这么做，如果让他们改变原来的策划过程，没有策略、没有方法，只靠培训与行政的约束几乎是不可能的，需要推广者利用各种办法以促使执行者能够从被动实施转化为主动实施，从而形成习惯，自觉自愿的实施。再比如，很多企业有决策的活动，但是大的决策都不是在项目立项之后做的，而是在立项之前由高层经理组织各方面的人员讨论、确定产品的技术路线，如何确保这样的决策采用结构化的决策方法呢?体系的推广者可以定义过程，但是对高层经理的约束如何落实呢?这就不是CMMI模型本身可以解决的。

　　SEI推荐了IDEAL作为过程改进的过程模型，该模型和PDCA的思想是类似的，是一种循环上升的、持续改进的过程模型，是一种宏观的过程模型，并没有给出具体的措施。在推行过程改进的时候，需要推广人员创造地寻找一些策略与方法去推广体系。典型的一些策略与方法举例如下：

　　例一：“测试先行”。在管理基础薄弱的软件企业里面，通过加强软件测试，可以直观地发现很多问题，从而使大家认识到质量的重要性，认识到进行过程改进的重要性，事实胜于雄辩;另一方面也减少了用户发现错误的概率。

　　例二：“缺陷分析”。对于客户反馈的缺陷、自己测试出的缺陷可以进行深入的原因分析，通过连续询问多个“为什么”发现问题的根源，从而能够从根本上采取措施、解决问题。