模板
教程
环境
性能
功能
管理
CMM软件过程改进前常见问题解答
Q：在实施基于CMM的过程改进时，难度最大的KPA是哪些？ A：根据SEI在2002年8月份发布的统计数据来看，如下图： 上图是根据全球496次正式评估得到的统计图表，其中我们重点关注CMM 2级的6个关键过程区域的情况。图中对于每一个关键过程区域都有2个数据，分别
| Q：在实施基于CMM的过程改进时，难度最大的KPA是哪些？ A：根据SEI在2002年8月份发布的统计数据来看，如下图： 上图是根据全球496次正式评估得到的统计图表，其中我们重点关注CMM 2级的6个关键过程区域的情况。图中对于每一个关键过程区域都有2个数据，分别表示在这496次评估中完全达到要求的比例和进行了评估的比例。换句话说，在2级的6个KPA中红色柱最短的应该就是实施难度最大的KPA，这样看来子合同管理似乎是实施难度最大的KPA。但我们发现产生这种情况的原因是：在绝大多数的软件企业中没有需要进行子合同管理的情况，这样，子合同管理这个KPA在60%以上的评估中被定为“不适用”或者“不评级”。除去这个KPA，在90%以上的评估中，二级中的其他5个KPA都进行了评估，而只有10%多一点的评估中SQA（软件质量保证组）能够做到完全达到要求，这足以说明SQA是CMM 2级实施过程中难度最大的KPA，需求管理的实施难度最小。具体分析，原因如下： ★ 和各企业对于不同KPA的重视程度有关系，需求管理几乎是所有软件企业都非常重视的内容，毕竟需求管理不好，需求变更频繁对项目组的工作量、进度和成本等方面影响是巨大的，于是各企业无论是否进行基于CMM的过程改进，都努力在找出使项目组和用户就将来产品的功能、性能等达成一致理解的方法，并尽一切办法减少客户提出需求变更的可能。相对来说，质量保证的工作就不那么引人注意了。 ★ SQA的工作带有一定的预防性质。大家都知道，在软件公司里面，评判一个人是不是“高手”的准则是他能不能解决其他人都解决不了的问题，就像给人治病的医生，能够治疗疑难杂症的是“神医”；不知道大家有没有想过，如果有个医生在病人刚刚出现轻微症状的时候就能把别人的病治好，对于病人来说是莫大的幸事，但这样的医生恐怕一般人不会认为他是个好医生，同样，SQA也是如此。 ★ 很多国内的软件企业一边在抱怨他们的客户成熟度低，对于软件什么也不懂，每天都在提出一大堆的需求变更，另一方面却在充分的利用客户什么都不懂，在软件产品的质量上睁一只眼闭一支眼，毕竟高质量的产品需要更高的成本来换取，既然用户也没有那么高的质量要求，何必费那么大的力气呢。可是他没有想过，这种做法和一些黑作坊里面生产“三无”食品并没有什么本质上的区别。好在越来越多的软件企业已经加强了质量意识，也使SQA的地位得到了不少的提升。 ★ SQA要在组织中得到认同。很多CMM 2级实施不到位的组织经常出现的问题就是无论是高层经理还是项目组有关的人员，大家都认为SQA可有可无，没有必要。如果不是CMM有这样的KPA，才不会安排专人去做这些事情呢。SQA做得好的企业通常有这样的特征，组织中的所有人员能够充分认识到SQA的价值，而项目组中发生的问题都能够在SQA的帮助下友善的解决。 ★ 根据CMM的要求可以看出，对SQA沟通能力的要求是比较高的。现在有不少企业的SQA成了“收账的”，根据公司的规定到什么时候项目组应该出什么文档，SQA就冲到项目组那里，大喊：“该交XX文档了！”。项目经理就像老鼠看见猫一样，求饶着说：“项目组现在太紧张了，能不能过几天再说？”到底能不能再说就看SQA的心情了。久而久之，所有的文档都改成了项目结束的时候再统一提交，而到那个时候文档的质量也没有人关心了。CMM要求的SQA可不是这样的，SQA要成为项目组的好朋友，而不是“猫和老鼠”的关系，一方面SQA要执行必要的质量检查和过程检查，这是保证公司的整体利益而必须要做的；另一方面，SQA在执行检查的同时，要通过发现的问题了解项目现在有什么麻烦，在项目组的级别上能不能解决，是否需要向高层经理汇报。要想做好这些事情，要求SQA对上面的高层经理，对下面的项目组反复的沟通，必要的时候还需要请一些技术经验丰富的专家协助执行技术检查，没有相当的沟通技巧是很难做好这些事情的。 对于SQA能否有效的发现问题也是一个不小的考验。如果SQA没有比较丰富的软件开发和项目管理方面的经验，又不具备足够的威望邀请一些有这些经验的人员来协助进行检查的话，项目组就可以随心所欲的“蒙”SQA了。有的公司舍不得让经验丰富的人员来做SQA，结果可想而知；有的公司在实施CMM以后，充分认识到了SQA的价值，将这个岗位采取轮岗制，要求每个项目经理在正式上岗以前都必须先做半年的SQA，以便充分理解这个岗位的难处和重要性，以后可以更好的配合他们的工作，这真是一个很好的想法，值得推荐。 |
| ■ 实施企业是否可以使用阶段式的演进路线： 如果企业只希望单方面的提高自己在项目管理、工程活动、支持活动或者过程管理四个方面中的某些方面的能力，那么就只能应用CMMI的连续表示方法。如果实施企业可以接受成熟度级别的思路（目前看国内大多数企业还是比较习惯于成熟度级别的），那么就不一定必须选择CMMI了。 ■ 实施CMM与CMMI可以平滑的转换。 一来，CMMI并不要求一家企业必须先做CMMI的2级然后再向更高的成熟级别演进，评估的时候也没有这样的要求。 另外， CMMI的评估都会根据被评估的成熟度级别，检查所有不高于该级别的过程区域。换句话说，一个企业在CMM正式评估中达到了2级的成熟度，将来改为基于CMMI进行过程改进。在CMMI 3级的正式评估时，CMMI 2级的内容同样要进行检查。如果我们能够在做CMM 2级的时候就按照CMMI的要求实施，效果没有任何的折扣，但对于实施企业来说，会节省很多在培训和评估方面的“额外”费用。（此处的“额外”费用是指CMMI收费比CMM高出的部分） Q：听说SEI到2003年底将不再继续支持SW-CMM 1.1版，那我们是不是到时候必须要改为使用CMMI？ A：到目前为止了解到的消息确实如此，不过软件CMM并不像大家想象的那样到今年年底就不复存在了。 SEI为了让CMMI有更多的用户，已经宣布到2003年底，不再继续对软件CMM提供支持。这种现象就像是微软公司在推出新版本的Windows后，一段时间后就不再对过去版本的产品提供技术支持是一样的道理。 但为什么可以说CMM并不会到了2003年底就不复存在了呢？这要从SEI对于CMM的支持都包括哪些内容说起，其中主要包括提供CMM相关知识的培训，公开世界上一些软件组织实施CMM后发表的论文，解答来自全球软件组织关于CMM的问题，为主任评估师提供授权证书，管理CMM正式评估相关的信息数据库等等。除此以外，大家还要知道每位主任评估师的资格证书是有2年的有效期的。这样我们就可以作出下面的结论了：如果主任评估师在2003年拿到了资格证书，他们可以在2004年和2005年继续为软件企业提供培训和CMM正式评估的服务，而此时SEI对这样的结果是认可的，只不过SEI不会在进入2004年以后再颁发新的CMM主任评估师的资格证书了。按照这样的思路，我们可以说CMM可以一直使用到2005年12月。在那之后，恐怕大家只能使用CMMI了。不过，现在在主任评估师当中，仍然存在着大量的争论，很多人仍然坚信CMMI不能完全替代CMM。客观地讲，CMMI确实比CMM要先进，质量也高出不少。但CMM已经被应用了10年多了，有些人对它的感情还是很深的，所以有的主任评估师猜想SEI可能会延长对CMM的支持时间。但目前我们还没有收到任何这方面的消息。 Q：听说软件CMM 要出3.0版了，这是真的么？ A：在2002年12月份，我们听说了这样的消息。这似乎和SEI宣布到2003年底就不再支持软件CMM有些矛盾。其实是这样的：CMM 3.0版本的研发并不是SEI宣布要进行的项目，而是卡内基·梅隆大学宣布要研发的。不过有不少坚持支持CMM的主任评估师对此表示极大的兴趣和欢迎，也有不少主任评估师对此事表示担忧，因为CMMI的研发是得到了美国国防部大力支持的，这样擅自决定开发软件CMM的新版本恐怕很难得到“老东家”的支持。果然不出所料，在我们大家充满好奇期盼新版本的软件CMM的时候，我们在2003年4月上旬接到了这个项目被取消的消息，虽然不是官方宣布的，但消息来源非常可靠。作为实施的企业，大可不必为此担忧。只要认真地实施过程改进，目前的软件CMM 和CMMI都可以帮助我们取得很好的效果。 结束语 以上十八个问题是对实施CMM前，软件企业各级管理人员通常要考虑的几个方面进行的一个简单的概括说明。当然，对实施CMM的探讨决不仅限于此。我希望通过这十八个问题，使将要进行过程改进的企业能对CMM有一个正确的认识，找到一个简单有效的途径来帮助企业实施CMM。本文若有不正之处，希望读者能够通过.net提出意见、建议，进行讨论，以便能有进一步的改进和提高。">yuanqingping@263.net提出意见、建议，进行讨论，以便能有进一步的改进和提高。 |
