UML软件工程组织

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，以便充分理解这个岗位的难处和重要性，以后可以更好的配合他们的工作，这真是一个很好的想法，值得推荐。