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

发布: 2008-4-02 12:30 | 作者: 不详　 | 来源: 51testing.com | 查看: 52次 | 进入软件测试论坛讨论

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

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

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

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

　　例三：“扯虎皮做大旗”。EPG不是项目组的直接领导，不可以直接对项目下命令，因此在推广的过程要善于利用企业的领导，经常和领导沟通，和领导一起加深对研发管理的认识，从领导那里获得反馈，并借助领导的影响力促进体系在项目中的推广。领导未必能够系统的理解CMMI，但是EPG可以利用领导的局部指示进行外推、丰富完善，以比较系统的推广体系。

　　例四：“造势”。造势并非造假，而是大范围的、深入地宣传CMMI的思想、从舆论上能够形成一种氛围，使大家意识到过程改进的重要性、内容等。比如说可以采用各种形式的张贴画、可以举办各种各样的竞赛活动等等。

　　例五：“榜样的力量是无穷的”。榜样证明了一种成功的方法，为其他人树立一种追赶的目标。可以通过在组织内发现这种榜样，宣传这种榜样，表扬先进，让其他人来效仿。

　　例六：“经验价值最大化”。每个人、每个项目组都有自己的经验教训，可以将这些经验教训通过一定的方式收集起来、抽象出来，在整个公司内进行宣传、推广，用大家熟悉的项目、事件、人员作为案例。

　　目标是明确的、清晰的，如何达到目标才是企业执行力的表现。在确定改进的目标时可以参考的基准很多，比如CMMI模型、ISO15504、ISO12207等等，实施这些标准与规范的方法却是要因企业而异，灵活处理。