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