UML软件工程组织

有关ISO与cmm的比较

Q：我们已经拿到了ISO9000的质量体系认证，这对实施cmm有什么影响？

A：国内软件公司采用的ISO 9000系列质量体系认证通常有ISO 9001的1994年版和2000年版。ISO 9001和cmm非常相似的是，两者都共同着眼于质量和过程管理，而且它们都是基于戴明博士的全面质量管理产生的，因此不存在任何矛盾的地方。但是，它们的基础是不同的：ISO9001（ISO9000标准系列中关于软件开发和维护的部分）确定一个质量体系的最少需求，而cmm强调持续过程改进。在1994年版的ISO 9001中，cmm 2级的6个关键过程区域所涉及的部分，基本上都比较明确的做出了要求；而cmm 3级的7个关键过程区域中所涉及的内容大多数都提到了，但做出的要求不是非常详细。很多实施了94版ISO的企业在了解了SW-cmm以后，普遍反映cmm比ISO的要求明确、详细得多。如果94版ISO实施的效果很好的话，实施cmm 2级工作量是可以减少很多的。而2000版的ISO则更多的和cmm有直接对应的关系，甚至是大量cmm 4级和5级的要求。

目前我看到的大多数已经实施了ISO 9000质量体系认证的软件企业，在实施cmm的时候在以下方面会有一定的优势：

★ 都拥有已经形成文档的程序文件。但因为ISO 9001的高度抽象性，有些程序文件定义的不是很具体，cmm中有些关键实践无法体现，但也有些企业花费了不少精力将ISO 9001的条款和软件工程相关的实践进行了很好的结合，相对来说就能够体现绝大多数的cmm要求的实践。这样的话，按照cmm要求建立过程体系的工作量就可以减少很多了。

★ 对于过程改进的概念已经比较熟悉了。如果ISO实施的比较认真到位的话，过程改进方面的理念应该在企业中比较深入人心，无论是高层经理还是开发人员都会对这方面的工作比较认同和支持。

★ 绝大多数拥有ISO 9001质量体系认证的企业都已经配备了和质量保证相关的工作人员，质量目标、方针和意识都比较明确。

有利就有弊，某些企业如果ISO实施的不是很到位的话，在实施cmm的时候也可能遇到这些问题：

★ 通过ISO 9001质量认证的实施过程，企业过分强调认证本身的重要性，证书拿到之后定义的过程就不再全面、认真地实施了，公司的员工发现过程改进工作变成了走形式、走过场。因此在整个企业中弥漫着一种对于过程改进非常抵触和消极的情绪，绝大多数人员普遍对cmm表示怀疑、信心不足。

★ 高层经理对实施cmm难度认识不足，他们通常会觉得：9000的认证不是很简单么？几个人花上几个月的时间不就搞好了，cmm想必也是差不多的，实施以后公司也没有什么特别明显的效果和收益。于是他们觉得cmm这件事情很容易，不需要花很多的心思和人力就可以轻松过关，这样对于SEPG的过程改进工作难度就很大了。

上述情况对于cmm强调的持续过程改进带来的负面影响是非常巨大的。除了企业过分强调证书以外，产生这些问题的原因还有以下几个方面：

★ cmm分成了5个成熟度级别，每个级别都是更高级别的基础。而ISO 9001要求企业把所有的条款一次性做好，其中当然也包括一些cmm高级别中的类似要求。对于任何一家企业，在刚刚开始进行过程改进的时候，想很好地实现这些要求是非常不容易的。

★ ISO 9001中没有明确的制度化方面的要求，尽管定期地对企业进行复审，但很多企业仍然不清楚到底如何去更好地把这些流程制度化。在cmm中，有4类和制度化相关的关键实践。简单说来“制度化”的意思是：把企业中已经定义好的过程在相当长的时间和相对广泛的范围内保持良好、到位的实施。cmm每个KPA都有关于制度化方面的要求，比如：通过组织方针来约束所有人去遵循过程的要求；通过提供充足的资源和资金、培训以及分配明确的职责来保证大家的使用过程；通过收集数据和量化的分析来判断过程是否仍有不足，如何改进、如何提高过程的效率；通过不同级别的管理人员以及质量保证人员的检查和监督确保大家按照要求的流程去做事等。

★ cmm只关注软件，而ISO 9001有更大的范围，对于制造业非常合适，即使是IT领域，也包括了硬件、软件和服务。因为ISO 9001的咨询师和审计员不一定是软件方面的专家，加上ISO 9001的高度抽象性，审计员可以以不同的方式解释实践的合理性，这就使一些拿到认证的企业仍然是cmm 1级的组织。另外，软件企业实施ISO的过程中，遇到了一些以软件企业角度去理解相关条款的问题时，可能无法从咨询师和审计员那里获得满意的答案。我曾经看到这样一家企业，他们实施ISO 9000 2000版已经半年多了，此时决定实施cmm。我看了他们的程序文件，感觉定义的非常好，项目计划、配置管理、质量保证方面几乎已经达到了cmm 2级的要求，但通过和部门经理、项目经理以及开发人员代表座谈，发现大家实际的做法和过程要求的完全不一样。究其根源，就在于当项目经理和开发人员对于公司流程要求的做法和实践表示不理解或不明白的时候，负责定义流程的人员无法给出令人信服的解释，久而久之，流程的执行变成了形式化的东西。