软件测试中CMM实施的案例学习指导

案例1:

　　V公司和竞争对手相比，在技术上并不占有优势，于是V公司采用了“快速响应”的策略。无论是面对瞬息的市场，还是多变的用户需求。V公司总能够抢先于竞争对手推出产品，为此受到了市场的肯定。但是V公司在实施CMM的时候，却错误地选择了“瀑布式”的开发模型，加上相对复杂的实施流程，如果研发体系严格按照要求去做，那么对市场的响应速度必然大大降低，企业的核心竞争力受到威胁。但是如果H公司坚定“快速响应”的策略，现有CMM的实施就无法有效进行。V 企业走入两难的境地。

　　V企业实施CMM并没有错，错的是他们在实施CMM的时候并没有考虑到企业的核心竞争力和总体战略，采用了错误的生命周期模型和相对复杂的实施流程，最后导致了这样的结果。

　　对公司的战略影响是一个方面，另外一个方面是，CMM的实施涉及到机构的重组，如果我们不能在组织架构，薪酬待遇，绩效考核等方面辅助以适当的政策的话，CMM的实施不可能顺利进行。

　　案例2:

　　W公司为了推行CMM，组建了独立的QA部门。尽管在W公司的内部宣传材料上对QA的作用进行了大肆的宣传，认为其对于CMM的推行和项目管理都具有重要作用，但是实际上QA人员的资历都相对较浅，对开发过程，技术和工具都缺乏必要的了解。只能够照搬一些条文来要求开发人员，开发人员对此并不认账，认为 QA人员是没事找事。另外，QA这个岗位在薪酬和升迁方面毫不吸引人。

　　为了避免QA部门成为新手和项目组淘汰人员的集中地，QA部门经理设法推行项目经理锻炼制度，让项目经理到QA部门锻炼一段时间，然后继续担任项目经理或者升迁。但是因为此项制度没有得到有效的支持，项目经理在QA部门工作一段时间以后竟然没有开发部门愿意接收，就更谈不上升迁了。QA部门在W公司的威望江河日下。

　　QA人员对于质量保证和CMM的实施至关重要，如果我们认可QA人员对于公司的价值，那就必须在人才和待遇上向QA部门倾斜。

　　案例3:

　　S公司在推行CMM 2级的时候遇到了极大的阻力，项目经理对估计和计划过程根本不感兴趣。其原因在于S公司有“倒排计划”的习惯做法。

　　项目经理对项目的进度安排没有决定权，当项目经理接受任务的时候，项目的发布日期早已确定，而且项目经理做出的人力资源请求一般也不会得到满足，项目经理被迫在一个资源短缺的环境下开展工作。既然Deadline已经确定，增加人手又不可能，项目经理怎么会对估计和计划有兴趣呢?

　　与此相对应，S公司的内部宣传材料在不断地表彰在资源短缺的困难情形下做出成绩的经理和开发人员，对“无原则服从命令”行为的赞许，已经成为了公司文化根深蒂固的一部分，并且得到管理层的默许和鼓励。

　　S公司的文化和CMM的要求是抵触的。CMM要求项目经理对任务的合理性进行分析，要求在理性的基础上做出判断，而不是盲目地服从。如果S公司不能够改变他们的文化，CMM就不能够得到有效实施。

　　案例4:

　　A公司是一个小型公司，但却采用了一个步骤繁琐的CMM实施方案，而且没有采用任何自动化的过程工具，大部分由纸面文件传递来进行。比如在测试中如果发现了一个问题，必须由测试人员找到文件模版，填写好缺陷的种类和描述，打印出来，交给相关人员签字，开发人员的修改结果就只好填写在纸面上，最后还要找项目经理签字。相关人员浪费在文件传递上的时间可能比进行开发和测试的时间还要长。

　　以CMM为模型制订管理框架，其本质是为了规范管理，减少错误的发生。而执行这些管理规程，就其本身而言，并不是我们的目的，而仅仅是一种手段。对这些规程的执行也不创造任何价值。在条件许可的情况下，我们要尽可能地简化手续，提高效率。并适当地引入自动化工具。像A公司的情况，用一个缺陷追踪工具就可以大幅度地提高效率。

　　案例5:

　　H公司和Z公司都在研发相同类型的C产品。H公司在推广CMM，采用了相对严格的过程规范，并且把相对重要的部分外包给了印度的CMM5级公司。这些手段Z公司都没有采用，但是Z公司却抢在了前面。

　　Z公司的“秘密武器”是一种形式化语言—SDL，Z公司采用SDL作为设计工具，这样C产品的相当一部分代码可以由SDL工具自动生成，而且在设计阶段就可以进行仿真运行，这样就大大地提高了效率并减少了缺陷。H公司虽然采用了相对严格的过程规范，但是因为全部代码为手工编制，所以，无论是效率还是质量， H公司都落后了。

　　H公司显然忽视了先进技术可能为生产率带来的进步，通过了CMM高级别的评估，只能说明被评估的组织机构在过程控制上做得更加细致，但是并不能够保证你的开发过程是高效的。某些沉迷于CMM的组织机构忘记了先进的软件工程技术的重要性。

　　案例6:

　　H公司的B项目是一个庞大的项目组，技术相当复杂。名词术语很多，而且对于同一件事物的表达方式也不尽相同。项目组非常有必要制定一个规范的术语表，既统一了说法，也方便项目组的新人查阅。但是事情的发展是很有戏剧性的。

　　项目组在起初并没有重视术语表的编制，因为人少，产生的文档也不多，所以这件事情无人重视。但是到了项目进展了1/3左右，术语的混乱已经相当严重的时候。B项目组的一个工程师X自发地开发了一个小程序，用于查阅术语的名称和缩写。项目经理对X工程师的做法提出了表扬，并委任X开发和维护这个标准术语表。

　　项目经理和相关部门的始终没有意识到：(1)开发和维护这样的标准术语表是项目经理和配置管理人员的职责，不是某一个软件工程师的任务。(2)类似的问题在别的项目组一定出现过，以后的项目组一定也会遇到，必须在开发规范上堵住这个漏洞，让别的项目不会重蹈覆辙。

　　所谓的“管理无大事”，过程管理的真谛就在于这些看似细节的小事。基本的过程管理原则和规范只是“骨架”，而“血肉”是要靠这些看似细枝末节的小事来丰满的。积沙成塔，集腋成裘，点滴持续地改进，其效果最终是巨大的。

原文转自：http://www.ltesting.net