周伯生教授CMM认证工作会上作学术报告
2000年10月20日，北京软件产业促进中心召开北京软件产业基地企业质量认证实施工程第二次工作会议，特邀北京航空航天大学软件工程研究所周伯生教授做CMM评估基本要点及最新动态学术报告，准备开展CMM评估的约20家软件企业的代表参加了会议。
周教授在报告中介绍了美国软件工程实践的现状、CMM/PSP/TSP软件过程的框架和企业进行CMM评估有关的若干问题、CMM的最新进展，以及在卡耐基-梅隆大学参加世界软件工程研讨会的情况。周教授认为，软件过程改善是当前软件开发技术的核心问题，而软件产业的发展，在经历了从70年代开始的结构化生产时代，到90年代中期，以CMM模型的成熟模型和日益为市场接受为标志，已经进入以过程为中心的时代，而软件发展第三个时代，及软件工业化生产时代，从90年代中期软件过程技术的成熟和面向对象技术、构件技术的发展为基础，已经渐露端倪，估计到2005年，可以实现真正的软件工业化生产，这个趋势应该引起软件企业界和有关部门的高度重视，及早采取措施，跟上世界软件发展的脚步。
北京软件产业促进中心
软件因其复杂性和难以度量，使软件项目管理较之其他项目管理而言有其特殊性。那么，如何确保软件项目的质量？软件研发项目管理又应该遵循什么标准呢？
打造软件管理新观念
----周伯生教授谈软件研发项目管理
问：近年来，您在大力倡导软件研发项目管理方面做了很多工作。首先，请您 介绍一下软件项目管理的由来，您认为实施软件研发项目管理的意义何在呢？
答：软件研发项目管理最早源自于70年代中期。当时美国国防部曾立题专门研究软件项目做不好的原因，发现70％的项目是因为管理不善引起的，而并不是因为技术实力不够，进而得出一个结论，即管理是影响软件研发项目全局的因素，而技术只影响局部。这个结论非常重要。到了90年代中期，软件研发项目管理不善的问题仍然存在。据美国软件工程实施现状的调查，软件研发的情况仍然很难预测，大约只有10％的项目能够在预定的费用和进度下交付。
在商用软件产业中，这一现象尤为严重。1995年，美国共取消了810亿美元的软件项目，其中31％的项目未做完就取消了，53％的软件项目进度通常要延长一半的时间，通常只有9％的软件项目能够及时交付并且费用也不超支。软件项目失败的主要原因有：需求定义不明确；缺乏一个好的软件研发过程；没有一个统一领导的产品研发小组；子合同管理不严格；没有经常往意改善软件过程；对软件构架很不重视；软件界面定义不善且缺乏合适的控制；软件升级暴露了硬件的缺点；关心创新而不关心费用和风险；军用标准太少且不够完善等等。在关系到软件项目成功与否的众多因素中，软件度量、工作量估计、项目规划、进展控制。需求变化和风险管理等都是与项目管理直接相关的因素。由此可见，软件研发项目管理的意义至关重要。
软件项目管理和其他项目管理相比有其特殊性。首先，软件是知识产品，进度和质量都难以度量，生产效率也难以保证。其次，软件系统的复杂程度也是超乎人想象的。例如，宇宙飞船的软件系统源程序代码多达2000万行，如果按过去的生产效率一个人一年只能写1万行代码的话，那么需要2000万人年的工作量，这是非常惊人的。正因为软件如此复杂和难以度量，软件研发项目管理的发展还很不成熟。
问：如您所说，软件是十分复杂且难以度量，因此对软件研发项目进行管理必须依据一定的标准。国内软件行业以前倡导的标准是1SO9000系列，而您却在很多场合大力倡导CMM，即能力成熟度模型（Capability Maturity Model）。请问这两种标准的区别何在？为什么您主张软件研发项目管理一定要依循CMM标准呢？
答:ISO9000是国际标准化组织提出的系列标准，其中1So9003是专门为软件行业定制的。而CMM则是美国卡纳基梅隆大学软件工程研究所（CMU／SEI）提出的软件研发项目管理的一系列方法。1SO9000和CMM的共同点是二者都强调了软件产品的质量。所不同的是，ISO9000强调的是衡量的准则，例如应该做什么、什么算好、什么算不好，却没有告诉软件开发人员如何达到好的目标，如何避免差错。CMM则提供了一整套较为完善的软件研发项目管理的方法。美国先后在这上面投资了5亿多美元，做了很多实践工作来改进软件研发项目管理，而且其内容还在不断地改进，CMM1.1版本推出后，现在又开始推出了CMM 2.0。ISO9000系列标准涵盖面广，即包括其他行业也一直没有什么改进。在软件行业方面，它实际上是由英国学院派一批没有做过复杂巨系统的人制定出来的标准，如果认为，只要通过ISO9000认证，就可改善软件生产，并用它来引导国内软件行业的发展，这无疑是种误导，我认为应该倡导美国的CMM系列。我在1999年宣扬这个观点时，当时有些人还觉得这个观点有些偏颇，但现在，越来越多的人已经同意这种观点。最近，北京市软件行业协会在中关村电脑节期间也开始倡导依循CMM来进行软件研发项目的管理。相信国内对这方面的重视程度还会进一步加强。
问：CMM的具体内涵是什么？是否实施了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％，特征是软件过程预测准确、值得信赖；为优化级的所占比例小于l％：其特征是软件过程能持续改善。美国的情况尚且如此，国内在这方面的起步则更加缓慢一些。目前，据我所知，国内只有清华大学鼎新公司的CMM成熟度等级能够达到可重复级。尽管CMM已经是一套发展相当成熟的方法，但国内要想完全地掌握并大范围地付诸实践，对绝大多数软件企业来说，可能还需要3-5年的时间。
需要注意的是，并不是实施了CMM后，软件研发项目的质量就能够有所保障了。 CMM不是万能的，它的成功与否，与组织内部有关人员的积极参与和创造性活动密不可分，而且CMM并未提供有关子过程实现域所需要的具体知识和技能。因此，PSP（Persona1 Software Process，个体软件过程）应运而生。 PSP也是由美国卡纳基梅隆大学软件工程研究所开发出来的，它的推出在软件工程界引起了极大的轰动，可以说是由定向软件工程走向定量软件工程的一个标志。 PSP为基于个体和小型群组软件过程的优化提供了具体而有效的途径，例如如何制订计划，如何控制质量，如何与其他人相互协作等等。在软件设计阶段， PSP的着眼点在于软件缺陷的预防，其具体办法是强化设计结束准则，而不是设计方法的选择。根据对参加培训的104位软件人员的统计数据表明，在应用了PSP后，软件中总的差错减少了58.0％，在测试阶段发现的差错减少了71.0％，生产效率提高了20.0％。PSP的研究结果还表明，绝大多数软件缺陷是由于对问题的错误理解或简单的失误所造成的，只有很少一部分是由于技术问题而产生的。而且根据多年来的软件工程统计数据表明，如果在设计阶段注入一个差错，则这个差错在编码阶段引发了3一5个新的缺陷，要修复这些缺陷所花的费用要比修复这个设计缺陷所花的费用多一个数量级。因此，PSP保障软件产品质量的一个重要途径是提高设计质量。
然而，实践证明，仅有PSP还是不够的，因此， CMM/SEI又在此基础上又发展出了TSP（Team Software Process。群组软件过程）的方法。TSP指导项目组中的成员如何有效地规划和管理所面临的项目开发任务，并且告诉管理人员如何指导软件开发队伍。始终以最佳状态来完成工作。TSP实施集体管理与自己管理自己相结合的原则，最终目的在于指导开发人员如何在最少的时间内，以预定的费用生产出高质量的软件产品，所采用的方法是对群组开发过程的定义、度量和改进。实施TSP的先决条件有3条：首先，需要有高层主管和各级经理的支持，以取得必要的资源其次，项目组开发人员需要经过PSP的培训并有按TSP工作的愿望和热情；第三，整个开发单位在总体上应处于CMM二级以上，开发小组的规模以3-20人为宜。在实施TSP的过程中，首先要有明确的目标，开发人员要努力完成已经接受的委托任务。在每一阶段开始，要做好工作计划。如果发现未能按期按质完成计划，应立即分析原因，以判定问题是由于工作内容不合适或工作计划不实际所引起，还是由于资源不足或主观努力不够所引起。开发小组一方面应随时追踪项目进展状态并进行定期汇报，另一方面应经常评审自己是否按PSP的原理工作。开发小组成员应按自己管理自己的原则管理软件过程，如发现过程不合适，应及时改进，以保证用高质量的过程来产生高质量的软件。项目开发小组则按集体管理的原则进行管理，全体成员都要参加和关心小组的规划、进展的追踪和决策的制定等项工作。
总而言之，单纯实施CMM，永远不能真正做到能力成熟度的升级，只有将实施CMM与实施PSP和TSP有机地结合起来，才能发挥最大的效力。
问：在软件研发项目管理方面，您觉得国内还存在哪些不足？在实施软件过程改善方面，需要注意哪些问题呢？
答：目前国内对软件研发项目管理存在的最大问题是认识不足。管理实际上是一把手工程，需要高层管理人员的足够重视。据国外有些大公司的介绍，他们在软件研发项目管理方面的投资一般占软件研发费用的10％左右。做软件项目管理是要花钱的，需要投入一定的人力物力，这些都需要得到高层管理人员的支持。软件过程的重大修改必须由高层管理部门启动，这是软件过程改善能够进行到底的关键。此外，软件过程的改善还有待于全体有关人员的积极参与，否则不仅他本人将失去从软件过程改善中获得提高的机会，甚至还会成为过程改善的阻力。在进行软件项目管理的过程中，需要注意以下几点：首先，软件过程改善不仅需要有明确的目标，而且需要对当前过程有很好的了解，就好比当查阅地图确定行进方向时，不仅行进的目标要明确，还需要知道现在自己所处的位置。其次，需要认识到软件过程改善是一个持续改善的过程，需要不断地学习，需要知识的积累，特别是当主客观环境（例如客户需求和主要开发人员）发生变化时，需要对过程进行修改，以适应变化了的情况。最后，软件过程改善不仅需要参与人员的自觉努力，还需要定期补充各项必要的资源。过程改善需要有关领导的规划、参与人员的忘我工作和管理人员的精心安排。但是如果没有必要的资金投入，整个软件过程改善工作就会缺乏物质基础。
除了要认识到过程改善工作是一把手工程这个关键因素外，还应认识到软件过程成熟度的升级本身就是一个过程，且有一个生命周期。因此，过程改善工作必然具有一切过程所具有的固有1特征，即需要循序渐进，不能一蹴而就需要持续改善，不能停滞不前；需要联系实际，不能照本宣读需要适应变革，不能凝固不变。我认为，将CMM／PSP／TSP引人软件企业最有效的途径首先要对单位主管和主要开发人员进行系统的培训。卡纳基梅隆大学软件工程研究所曾尝试让软件工程师通过自学的方式来进行，但实际上，只有不到20％的人能够坚持到底。另外一个有效的途径是自顶向下的课程培训，即从高层主管依次普及到下面的工程师。
现在国内软件产业的发展可以说已经具有一定规模了，但除了北大方正、东大阿尔派、用友等大企业外，做软件工程项目更多的是一些规模在数十人左右的中小企业。也许有人会问，像他们这样一些人力物力资源匮乏的企业。又如何来进行软件研发项目的管理呢？其实，我建议这些中小企业可以以CMM为框架，先从PSP做起，然后在此基础上逐渐过渡到TSP，以保证CMM／PSP／TSP确实在企业中生根开花。我相信只要坚持改善软件工程的管理，并在实践中总结适合自身的经验，一定能取得很好的效果。
