【IT168 技术文章】
CMM是一件严肃的事，国内企业不要一哄而上为了CMM而CMM，把CMM弄得流于庸俗化。
2000年夏天中关村电脑节上举办了CMM国际论坛，这次论坛把CMM这个软件项目管理的新概念推到了大家面前，而且迅即便有了"时髦"的光环。一些软件厂家开始从ISO转向CMM，一些评论文章把CMM当作国内软件产业振兴的又一次"指望"，一些基于CMM的科研成果也逐渐为外人所知，关于CMM的研讨会也渐次增多。
CMM最初的提出，与阿帕网(Arpanet)一样，有着美国官方的背景。美国政府定制大型软件的投入历来占相当的比重，但是软件项目并不是单纯的计算机工程，可以简单地"外包"了事。软件系统的开发是原始系统的一次变革历程，是一个过程；而担当软件开发的企业，并不只是担当娴熟的工匠的角色，他们要从内部了解用户的需求，与用户一起走过这个变革的里程，伴随用户把手工作业的平台，迁移到以数字化和网络化为特征的新平台的完整过程。
有软件开发经验的人们都知道，许多在开发进程中存在的问题不是没有解决之道，不是没有恰当的工具，而是没有恰当的组织和恰当的协调。需求分析是否能够做得扎实，并不在于业务人员和技术人员能否提出整个问题的轮廓，并把它组织成描述性的文档，而在于这个需求的认定是否有足够的组织保障，使得技术开发人员可以说，"按照这个思路往下做，应该没有问题"。
然而问题往往就出在这里。试图解决这一问题其实就是卡内基梅隆大学的软件工程研究所SEI(Software Engineering Institute)提出的软件能力成熟度模型(Software Capability Maturity Model)追求的目标：软件开发组织如何提高自己的成熟度水平。这个成熟度水平的衡量标准的难点并不在体系内部，而是在体系的外部和边界处。
CMM的五个等级标志着企业的逐渐提高的软件开发能力的成熟度；更有价值的是，它列出了为达到每一个成熟度等级所必须要做的事。CMM的提出者希望企业通过使用这个模型，一个等级一个等级地去提高它们的软件开发及生产能力。
CMM提出的背景实际是为了解决政府大型软件项目的承包管理问题，因此其核心内容--关键实践(Key Practice)是针对承包开发这一特定的过程而建构的。值得注意的是，CMM对软件开发项目最大的贡献在于，它把组织和管理的精神明确地纳入到软件开发的过程中来，它不是基于目标和方法的管理，而是基于过程的管理。
1987年，软件研究所(SEI)展示了他们的软件能力成熟度模型，把软件过程的成熟度分为五级，目的是给软件开发从被动地解决碰到的难题的方式，转化到成熟的、规范化的方式提供一条途径。这五个等级分别是：
第一级：初始级在初始级，企业一般不具备稳定的软件开发与维护的环境。常常在遇到问题的时候，就放弃原定的计划而只专注于编程与测试。
第二级：可重复级在这一级，建立了管理软件项目的政策以及为贯彻执行这些政策而定的措施。基于过往的项目的经验来计划与管理新的项目。
第三级：定义级在这一级，有关软件工程与管理工程的一个特定的、面对整个企业的软件开发与维护的过程的文件将被制订出来。同时，这些过程被集成为一个协调的整体。这就称为企业的标准软件过程。
第四级：定量管理级在这一级，企业对产品与过程建立起定量的质量目标，同时在过程中加入规定得很清楚的连续的度量。作为企业的度量方案，要对所有项目的重要的过程活动进行生产率和质量的度量。软件产品因此具有可预期的高质量。
第五级：(不断)优化级在这个等级，整个企业将会把重点放在对过程进行不断的优化。企业会采取主动去找出过程的弱点与长处，以达到预防缺陷的目标。同时，分析有关过程的有效性的资料，作出对新技术的成本与收益的分析，以及提出对过程进行修改的建议。
从这样一个阶梯式演化的模型来看，最重要的一个标准就是软件开发的过程必须是开放的，以便不断地进行优化。
CMM的主要作用有如下3个方面：
1、用于软件过程的改进。(SPI Software Process Improvement)帮助软件企业对其软件过程的改变进行计划、制定以及实施。
2、用于软件过程评估。(SPA Software Process Assessment)在评估中，一组经过培训的软件专业人员确定出一个企业软件过程的状况，找出该企业所面对的与软件过程有关的、最迫切的所有问题，以及取得企业领导层对软件过程改进的支持。(用途2是用途1的前一步)
3、软件能力评鉴。(SCE Software Capability-Evaluation)在能力评鉴中，一组经过培训的专业人员鉴别出软件承包者的能力资格；或者是检查监察正用于软件制作的软件过程的状况。
拿CMM标准与国内大型软件工程的实践相对照，就可以发现，目前国内大型软件工程的缺陷主要在于：
缺乏制度保证，使得软件开发的过程是一个相对独立的工程建造过程；
缺乏严格的经济技术评价程序，更重要的是，缺乏对评估结果的正确认识；
缺乏规范的项目开发管理。
现实的过程往往令人扫兴，因为大型企业的项目开发，往往是一个低级组织机构(即先天缺乏决策资格的组织)一厢情愿的过程，这个过程由于面临的是一个不可讨论的运作机构和僵化的组织原则，所以从一开始就只能采取"照猫画虎"的姿态，把企业的信息化系统建设定位在"翻版工程"的基础之上。项目组既不可能对现存的业务程序提出任何"重构(Re-engineering)"的建议，更不能实施这些旨在优化和改善业务程序，使之更适合数字化、网络化的基本要求，甚至都不能协调不同业务口径、业务程序之间的数据混乱和边界交叉。
大型企业的软件项目开发，由于总是处于被动描画目标系统的地位，所以很容易成为各个不同业务部门误导的受害者。这些业务部门都异口同声地表白自己部门的优势地位，强调自己部门的本位需求，夸大本部门的重要程度。
需求调查对项目组来说，其实只是从一大堆原始问题出发，到一大堆高级问题结束。原始问题是：部门的基本业务有哪些，数据如何，流程如何等等；高级问题就是：A部门只能如此，A部门必须要求B部门如何如何等等。项目组的工作基础从此发生了变化，他们为了争取自己"创造"的空间不至于缩减为零，就只能退后一步，为这些部门的考虑留下更多的口子，让事实去对接。
以上这些问题在国内软件企业的工作过程中都普遍地存在着，值得庆幸的是，国内软件产业界已加强了对自身存在的问题和CMM标准的认识，大家都希望能获得CMM等级认证来提高自己公司的软件开发水平，从而最终增强我国软件产业的实力。这当然是一件令人欣慰的事。但我们想要提醒的是，CMM是一件严肃的事，国内企业不要一哄而上为了CMM而CMM，把CMM弄得流于庸俗化。正如业内人士所说的那样：通过CMM并不是目的，关键是学习先进科学的软件开发流程，改进软件过程，不断提高自身研发管理水平，保证产品质量，让我们的软件企业走上规范化发展的道路。
