中山大学软件研究所 李磊
二00三年十一月十日

一 前言
　　提升软件质量从来就是软件工程中的重要研究课题，但是也是至今没有满足结果的课题，因此东软件质量无法保证目前依然是软件企业的难题。CMM试图从管理学的角度来解决这一问题，特别是希望控制软件的开发过程来保证软件质量。无疑这是个重大的进展。但是事实上，如果没有在理论上和技术条件的支持，软件开发过程也是难以控制的。此项研究的目标是研制适合进行软件开发过程控制的软件结构，技术，平台和管理系统，为软件企业自然地达到某一高级CMM等级提供技术，方法和管理手段。此项研究也可以看作为软件企业CMM等级进化提供的可操作的必要条件----技术条件。同时此项研究对CMM能做什么和不能做什么进行了讨论。

二 CMM简介
2.1 什么是CMM
　　CMM是英文Capability Maturity Model 的缩写，也就是能力成熟度模型，和是由美国长内梅隆大学软件工程研究所（SEI）提出的。
　　CMM的研究在美国政府的要求下开始于1186年，并于1991年推出CMM1.0版。
　　自CMM1.0提出之后引起软件专家的注意，并且引起了激烈的争论。SEI在研究了这些争论后于1999年完成了CMM2.0版。今天我们讨论的主要是CMM2.0版。
　　由于CMM的视点（对一个问题的着眼点）很好，使得能力成熟度短语被广泛地应用，例如：人力资源能力成熟度和系统能力工程成熟度等。
　　CMM是根据软件企业的管理模式对软件企业的一个评估标准，例如：某企业具有某CMM等级资质。
　　SEI认为CMM是企业的进化模型，但是由于CMM没有提出企业从某某CMM等级进化为更高级CMM等级进化为更高级CMM等级的方法，因此我们不认为是进化模型。

2.2 为什么提出CMM
　　众所周知，在各种各样的工程中，软件工程是最难以控制的工程之一。因为"软件是一种逻辑系统，设计软件比设计硬件所使用的逻辑量要多10至100倍。"我们认为不仅如此，这主要是没有有效的理论和方法来建立这个逻辑系统。由于没有适合的逻辑系统，这意味着这么复杂的逻辑要由人脑来控制，而人脑对于复杂逻辑的控制能力是有限的。明显，由于要由人脑来控制复杂逻辑的一困难问题，因此对于软件工程的控制事实变为对人脑的控制，但是这是不可能。
　　由于上述原因，软件工程存在着如下问题：
　　"软件成本过高，软件开发进度难以控制，估计软件工作量困难，软件质量难以保证和修正维护软件困难"，从而"造成软件开发失败"。
　　为了解决这一问题，CMM认为"人们面临的不仅是技术问题，更重要的是管理问题"。

三 CMM主要内容
　　在叙述CMM内容时，引用最多的是下图：
　　 1　　　　　　 2　　　　　　　3　　　　　　　　4　　　　　　　5

　　（4）已管理级－软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认证和控制。
　　（5）优化级－通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续性地对过程进行改进。

而看作为边集合，则图1构成以图论中的图G=（P，V）。
　　通常情况下边是有含意的，它表示节点间的关系。但是在图G中的边没有任何含意，例如：它没有给出从低级向高级进化的方法。从严格学术的观点看，这种表达是有缺点的。

1） 初始级：没有章法可循。
2） 可重复级：对软件开发过程进行定性管理。
3） 已定义级：制定了标准，因而有章可循。
4） 已管理级：制定了质量标准，可进行定量管理。
5） 优化级：有进化能力。
并且对应的效果为：

　　但是，我们认为目前世界上并不存着对软件工程有效的定量分析理论和方法，但是能有企业通过了CMM4认证。这不能不令人感到奇怪。
而CMM5不知道如何被认定，因为即使在CMM1情况下的软件企业也在通过"新概念和新技术"来不断地"对过程进行改进"。
结论：
第一， 从管理的角度对开发过程进行控制是有意义的；
第二， 各级的评价标准均为主观评价标准；
第三， CMM只提到了What，而不知道How；
第四， 分类没有理论根据。

四 CMM分析
　　保证和提升软件开发质量的重要前提是软件工程化。众所周知软件工程是计算机科学领域中的一个非常重要但又古老的课题。今天我们还在讨论这一问题，则说明至今还没有令人满意的解决方法。为了解决这一问题，最近人们试图从管理学的角度进行研究并且取得结果，例如CMM和ISO9000等。事实上每个软件公司的领导者都知道软件工程的基本道理，并且积极进行努力，但是效果并不理想。目前人们应当回答一个问题，软件开发是否可以全部工程化？显然，答案是否定的。我们认为软件工程化是有条件的，例如：以算法为中心的软件是难以工程化的。
　　为了解决提升软件质量问题，人们试图通过以下方法解决：
　　程序设计方法，例如结构化，Oop，说明程序设计等；
　　设计方法，例如，E_R，UML等；
　　管理方法，例如，ISO9000，CMM等。
　　通过程序设计，设计方法和管理方法来解决软件工程的方向都是对的，但是都仅强调了一个侧面，因此都不能完全地解决问题。
　　特别地，CMM方法试图从管理学的角度来解决问题，这是一个大的进步。因为人们认识到仅仅通过技术手段是解决不了软件质量问题的。它提出了为了保证软件的质量不仅仅应当通过技术手段，而且要对软件的开发过程进行控制，亦"不但重视结果，而且重视过程"。只有通过过程的可控性，才能得到结果的可控性，这就是CMM核心"软件开发过程可视化"。
　　CMM被看作为软件企业进化模型，还不如被看作为软件企业的分类标准，例如对于只控制结果而不控制过程的软件企业被看作为属于CMM 1类，对于只控制阶段成果而不控制阶段过程的企业被看作为属于CMM 2类，等等。
　　对于CMM的内容的理解是容易的，虽然大部分的软件企业并不了解CMM内容，但是也都在自然地进行着从低级向高级的努力，因此大部分软件企业都已部分地满足或在正在努力争取满足CMM 2条件。
　　虽然大部分的软件企业都在进行着管理升级的努力，但从统计数据上看，效果并不理想，如以下数据统计：
　　"到2000年6月底，全世界有1269家软件公司和机构通过了不同级别的CMM认证。其中通过5级认证的只有38家，4级50家，3级210家，2级近400家。在4级和5级企业中，除澳大利亚和以色列各拥有一家4级企业、中国1家5级企业外，其余都是美国和印度的企业。摩托罗拉中国软件中心成为第39家5级认证的企业。"
　　CMM内容是容易理解的，但是在众多软件企业中，只有少数通过了CMM 2条件，为什么？
　　CMM 2是软件最基本条件，为什么众多的软件企业难以达到。
　　为了回答上述问题，则必须回答前面所述"软件是否可以全部工程化"的问题，或者回答是否存在有效的方法，使得软件企业达到某一CMM等级的问题。
　　我们认为CMM没有很好地回答这一问题，例如，当一个企业要达到CMM 2标准时，则必须对需求进行管理，因为"结果表明：在软件开发和维护过程中，所有被检测出来的错误，54%是在编码和单元测试阶段以后才被发现的，其中45%是在需求和设计阶段发生的，而编码阶段的错误只占9%。另外，对GTE、TRW和IBM 三家公司的研究结果表明：在需求阶段查和修改一个错误的代价比值可高达1：200。"
　　CMM非常明确地指明了在软件开发过程对需求管理的重要性。CMM指出"在分配需求被纳入到软件项目计划书之前，由软件工程组对分配需求进行审查。审查工作要详细、具体、要找出不完全的和遗漏的分配需求；要审查分配需求是否可行：是否由软件实现、表达是否清楚和恰当、是否相互一致、是否可测试。若在审查过程中，软件工程组发现某些分配需求有潜在问题，应将这些需求及发现的问题提交给负责分析和分配系统需求的小组，由他们来进一步审查这些可能存在问题的分配需求并对这些需求做出必要的修改。这样，需求就基本上确定下来?quot;。事实上在这段文字中，CMM并没有给出如何保证需求质量的有效方法，而且由人既"软件工程组"进行审查，并且指出审查工作要详细，具体要找出不完全和遗漏的分配需求等。我们认为仅仅"人"完成上述任务是困难的，因为软件是一个非常复杂的"逻辑系统"。研究结果表明：目前还不存在有效的方法检查需求是否是完全的和一致的。
　　当然对CMM 2中所述的其它管理也存在同样问题。这样也就回答了为什么通过软件企业最基本的要求CMM 2也是困难的问题，同时也回答了有的企业虽然并没有采用CMM标准但也开发出了有影响的软件，例如，微软，和有的公司虽然通过了CMM 2但并没有开发出有影响的软件这一问题。
　　综上所述我们可以得出如下结论：
　　1. CMM提出以软件企业对软件开发过程的控制能力进行分类是有意义的。
　　2. CMM 2以上级别的企业对于软件开发过程就已经具备了一定的控制能力，已经具备了成功开发软件的必要条件。
　　CMM虽然提出了有意义的软件企业的分类方法和一些管理（过程）方法，但是并没有提出软件企业达到某级别的有效方法，并且CMM认为"软件开发的主要问题是管理问题，而不是技术问题"的看法是不全面的。因为如果仅仅是管理问题，而不是技术问题，则软件企业家早就认识到这一点，并且积极实施，进而达到高级CMM等级了，因为他们并不"蠢"。
　　3. 提升软件质量的关键不仅仅是要对软件开发过程进行控制的问题，而是如何进行控制的问题。
　　4. 以上述1，2，3为基础软件过程控制方法和软件（项目管理）。