软件工程与能力成熟度模型CMM是怎样的？
20世纪70年代中期，软件工程管理引起广泛注意。当时美国国防部曾立题专门研究软件项目做不好的原因，发现70%的失败项目是因为管理不善而引起的，而不是因为技术实力不够。他们进而得出一个结论，即管理是影响软件研发项目全局的因素，而技术只影响局部。 这个结论非常重要。软件项目失败的主要原因有：需求定义不明确；缺乏一个好的软件开发过程；没有一个统一领导的产品研发小组；子合同管理不严格；没有经常注意改善软件过程；对软件构架很不重视；软件界面定义不善且缺乏合适的控制等等。 在关系到软件项目成功与否的众多因素中，软件度量、工作量估计、项目规划、进展控制、需求变化和风险管理等都是与工程管理直接相关的因...全部
20世纪70年代中期，软件工程管理引起广泛注意。当时美国国防部曾立题专门研究软件项目做不好的原因，发现70%的失败项目是因为管理不善而引起的，而不是因为技术实力不够。他们进而得出一个结论，即管理是影响软件研发项目全局的因素，而技术只影响局部。
这个结论非常重要。软件项目失败的主要原因有：需求定义不明确；缺乏一个好的软件开发过程；没有一个统一领导的产品研发小组；子合同管理不严格；没有经常注意改善软件过程；对软件构架很不重视；软件界面定义不善且缺乏合适的控制等等。
在关系到软件项目成功与否的众多因素中，软件度量、工作量估计、项目规划、进展控制、需求变化和风险管理等都是与工程管理直接相关的因素。由此可见，软件工程管理的意义至关重要。
软件项目的特殊性
软件工程管理和其它工程管理相比有其特殊性。
首先，软件是知识产品，进度和质量都较难度量，生产效率也较难保证。其次，软件系统复杂程度也是超乎想象的。例如，宇宙飞船的软件系统源程序代码多达2000万行，如果按过去的生产效率一个人一年只能写1万行代码的话，将需要2000人年的工作量，这是非常惊人的。
正因为软件如此复杂和难以度量，软件工程管理的发展还很不成熟。
CMM，逐步的成熟
美国Carnegie Mellon大学软件工程研究所（CMU/SEI）主持研究与开发的CMM/PSP/TSP技术，为软件工程管理开辟了一条新的途经。
CMM是英文“Capability Maturity Model”的简称，意为能力成熟度模型。CMM的本质是软件管理工程的一个部分。根据软件生产的历史与现状，CMM框架可用5个不断进化的层次来表达：其中初始层是混沌的过程，可重复层是经过训练的软件过程，定义层是标准一致的软件过程，管理层是可预测的软件过程，优化层是能持续改善的软件过程。
任何单位所实施的软件过程，都可能在某一方面比较成熟，在另一方面不够成熟，但总体上必然属于这5个层次中的某一个层次。在某个层次内部，也有成熟程度的区别。在一个较低层次的上沿，很可能与一个较高层次的下沿非常接近，此时由这个较低层次向该较高层次进化也就比较容易。
反之，在一个较低层次的下沿向较高层次进化，就比较困难。在CMM框架的不同层次中，需要解决带有不同层次特征的软件过程问题。因此，一个软件开发单位首先需要了解自己处于哪一个层次，然后才能够对症下药地针对该层次的特殊要求解决相关问题，这样才能收到事半功倍的软件过程改善效果。
任何软件开发单位在致力于软件过程改善时，只能由所处的层次向紧邻的上一层次进化，即软件过程的进化是渐进的，而不能是跳跃的。而且在由某一成熟层次向上一更成熟层次进化时，在原有层次中的那些已经具备的能力还应该得到保持与发扬。
CMM家族包括CMM集成产品集、SACMM（软件获取能力成熟度模型）、SECMM（系统工程能力成熟度模型）和IDEAL模型。其中CMM集成产品集为工业界和政府部门提供了一系列集成产品，以支持软件过程和产品的改善；SACMM用于单位获取和采购基于软件的应用系统的软件过程，美国国防部、陆军、海军和一些商用单位都已采用SACMM对他们的获取能力进行评估；SECMM是描述一个单位为保证实现一个好的系统工程的主要元素；而IDEAL模型则是一个单位用于启动、规划和实现过程改善措施蓝图的模型，概括了建立一个成功的过程改善项目的必要步骤，其中I代表Initiating（启动）、D代表Diagnosing（诊断）、E代表Establishing（建造）、A代表Acting（措施）、L代表Learning（学习）。
美国曾在1995年做过软件产业成熟程度的调查，发现在美国的软件产业中，CMM成熟度等级为初始级的竟占70%，其特征是软件开发过程不能预测，风险度高；为可重复级的占15%，其特征是软件开发过程需小心谨慎方能避免失败；为定义级的所占比例小于10%，其特征是软件开发过程相当稳定，进展顺利且可以预测；为管理级的所占比例小于5%，其特征是软件过程预测准确、值得信赖；为优化级的所占比例小于1%，其特征是软件过程能持续改善。
CMM还需绿叶配
需要注意的是，并不是实施了CMM，软件项目的质量就能有所保障。CMM不是万能的，它的成功与否，与一个组织内部有关人员的积极参与和创造性活动是密不可分的，而且CMM并未提供实现有关子过程域所需要的具体知识和技能。
因此，个体软件过程PSP（Personal Software Process）也就应运而生。PSP为基于个体和小型群组软件过程的优化提供了具体而有效的途径，例如如何制订计划，如何控制质量，如何与其他人相互协作等等。
在软件设计阶段，PSP的着眼点在于软件缺陷的预防，其具体办法是强化设计结束准则，而不是设计方法的选择。根据对参加培训的104位软件人员的统计数据表明，在应用了PSP后，软件中总的缺陷减少了58。
0%，在测试阶段发现的缺陷减少了71。9%，生产效率提高了20。8%。PSP的研究结果还表明，绝大多数软件缺陷是由于对问题的错误理解或简单的失误所造成的，只有很少一部分是由于技术问题而产生的。
而且根据多年来的软件工程统计数据表明，如果在设计阶段注入一个差错，则这个差错在编码阶段要引发35个新的缺陷，要修复这些缺陷所花的费用要比修复这个设计缺陷所花的费用多一个数量级。因此，PSP保障软件产品质量的一个重要途径是提高设计质量。
PSP的推出，在软件工程界引起了极大的轰动，可以说是由定向软件工程走向定量软件工程的一个标志。
仅有CMM和PSP还是不够的，因此，CMU/SEI又在此基础上提出了群组软件过程TSP（Team Software Process）的方法。
TSP指导项目组中的成员如何有效地规划和管理所面临的项目开发任务，并且告诉管理人员如何指导软件开发队伍始终以最佳状态来完成工作。TSP实施集体管理与自我管理相结合的原则，最终目的在于指导一切人员如何在最少的时间内，以预定的费用生产出高质量的软件产品；所采用的方法是对群组软件开发过程的定义、度量和改进。
实施TSP的先决条件有3条：首先，需要有高层主管和各级经理的支持，以取得必要的资源；其次，项目组开发人员需要经过PSP的培训并有按TSP工作的愿望和热情；第三，整个单位在总体上应处于CMM二级以上。
在实施TSP的过程中，首先要有明确的目标，开发人员要努力完成已经接受的委托任务。在每一阶段开始，要做好工作计划。如果发现未能按期按质完成计划，应分析原因，以判定问题是由于工作内容不合适或工作计划不实际所引起，还是由于资源不足或主观努力不够所引起。
开发小组一方面应随时追踪项目进展状态并进行定期汇报，另一方面应经常评审自己是否按PSP的原理工作。开发人员应按自己管理自己的原则管理软件过程，如发现过程不合适，应及时改进，以保证用高质量的过程来生产高质量的软件。
项目开发小组则按集体管理的原则进行管理，全体成员都要参加和关心小组的规划、进展的追踪和决策的制订等项工作。
总之，单纯实施CMM，永远不能真正做到能力成熟度的升级，只有将实施CMM与实施PSP和TSP有机地结合起来，才能发挥最大的效力。
目前国内对软件工程管理存在的最大问题是认识不足。管理实际上是一把手工程，需要高层管理人员的足够重视。据国外有些大公司的介绍，他们在软件工程管理方面的投资一般占软件开发费用的10%左右，这些都需要得到高层管理人员的支持。
而且软件过程的重大修改也必须由高层管理部门启动，这是软件过程改善能否进行到底的关键。此外，软件过程的改善还有待于全体有关人员的积极参与，否则不仅他本人将失去从软件过程改善中获得提高的机会，甚至还会成为过程改善的阻力。
除了要认识到过程改善工作是一把手工程这个关键因素外，还应认识到软件过程成熟度的升级本身就是一个过程，且有一个生命周期。因此，过程改善工作必然具有一切过程所具有的固有特征，即需要循序渐进，不能一蹴而就，需要持续改善，不能停滞不前；需要联系实际，不能照本宣科；需要适应变革，不能凝固不变。
而且我认为，要将CMM/PSP/TSP引入软件企业，最有效的途径是要对单位主管和主要开发人员进行系统的培训。美国 Carnegie Mellon 大学软件工程研究所曾经尝试让软件工程师通过自学的方式来进行，但实际上只有不到20%的人能够坚持到底。
另外一个有效的途径是自顶向下的课程培训，即从高层主管依次普及到下面的工程师。
现在国内软件产业的发展可以说已经具有一定规模了，但除了北大方正、东大阿尔派、用友等大企业外，做软件工程项目更多的是一些规模在数十人左右的中小企业。
收起
