完善企业内部控制

CMM/CMMI不是软件企业唯一的选项一边按照CMM/CMMI做各种需要的文档,一边还在按照老传统做什么调研,方案设计,调试,跟CMM/CMMI并不合拍.这是问题之一.CMM/CMMI是一个评估的依据,也是一个过程改进的框架,并不是一个标准.这是问题之二.CMM/CMMI体现了西方的"三权分力"的思想.SEPG相当于立法机构,而软件项目组相当于行政机构,SQA人员相当于司法机构.三者相互制约.这种软件项目经理和技术主管职位不分,职责不明的做法怎么能够做好CMMI这是问题之三.CMM/CMMI不是为软件研究性项目设计的,而是为产品项目设计的.需要搞清楚你的项目是研究性的,还是产品性的,不要盲从CMM/CMMI.这是问题之四.CMM/CMMI不可以以强权方式实施.不能越级做CMM/CMMI需要收集不同项目的过程实践经验,经总结分析才能形成组织的过程.这是问题之五.实施CMM时必须解决的认识问题在企业的开发能力中过程,技术(含工具,方法),人员都是主要的因子,都需要全面提高,只关注一个方面,而忽略了其他方面,都是有害的.在开始实施CMM时,最容易犯的一个错误就是"唯管理论"或孤立地只抓过程改善,忽略了开发技术与人员的提高,过分强调管理的作用,实施了半年或一年后,发现企业的生产能力并没有得到明显的改善,这时反对的声音就会成为主流,过程改善就难以继续进行了.管理就是预防,管理的作用是隐性的,不都是立竿见影的,大家要有耐心在实施CMM时,企业的管理层在开始时往往会对过程改善期望值太高,希望短时间内效果显着,上面我们谈到了,效果显着与否不是由一个方面的要素决定的,需要多个因素共同改善.而管理的最大作用是预防,防患于未然.任何的管理的改善都是符合J曲线的,即在改善的初期企业的运行效率可能会下降,甚至可能会出现一些混乱的局面,不过渡过了这段时间就会看到效果.所以在改善的初期大家要有这个思想准备,要有耐心.坚持活学活用,以我为主机械照搬CMM的条文是在实施CMM时常犯的错误.CMM是软件工程经验的集大成,是从实践中总结出来,用以指导实践的,CMM本身也在更新版本,不断完善.每个企业都有自己的特点,就象微软的M,那是微软自己内部的管理过程标准,是微软的产品开发经验总结,有些内容是CMM中没有的,完全可以借鉴过来使用,所以只要可以提高企业自己的软件管理水平,就应该大胆地来尝试.要改良式不要革命式让大家在"小步快跑"中接受变革,这样风险最小,效果最好.期望在短期内通过CMM评估,单纯追求市场上的轰动效应.恐怕由于没有实效而得不到大家的认同而难以将这种"水平"持续下去.一个企业引入CMM之后会从本质上影响企业的文化,改变大家的思想与做事方法.CMM与企业的创新文化是不矛盾的企业在推行CMM时,过分机械,没有从实际出发,不能与实践紧密结合,挫伤了开发人员的积极性.软件企业必须形成创新的文化,事实CMM本身也一种软件工程管理的创新,而技术创新是必须进行管理才能使其有效地转化为生产力,转化为企业的实际效益,达到效益最大化,这是最根本的.要勇于实践,也要允许犯错误CMM就是软件工程经验与教训的总结.在实施CMM的过程中,肯定会走些弯路,甚至于要犯错误,由此许多人会议论纷纷,一直会反映到高层经理处,这时不要犹豫,要敢于尝试,更不能因为有困难就打退堂鼓,现在大家都是"摸着石头过河"要少说不,少说难,勇于实践,有错就改.对于软件企业的领导尤其要注意这一点,不要因为在过程中的一些实践失败,就对项目经理,SEPG等人员有偏见,要提倡这种文化.管理过程改进是组织内所有人的事情,而并非仅仅是SEPG的事情按照CMM专家的建议,在一个组织内专职从事软件过程改善的人数应为组织总人数的2-3%,根据这一建议,我们企业内一开始就配备专职的软件工程过程组(SEPG),这些员工专职负责企业的软件过程改善工作,另外我们根据需要组织一些技术任务组(TWG),他们会的参与特定过程规程,标准的制定,试点和修改完善工作.在这种情况,可能会出现如下的问题:SEPG成了最忙的人,TWG的任务往往会由于那些的人员以工作忙为理由一拖再拖,最后还是由SEPG的成员替代TWG做工作,企业的非开发人员对管理过程改进的效果一下没有明确地感受到,甚至看到由于加了些新的活动可能使项目拖期可能会更严重,于是他们可能就会将这些抱怨反馈到企业的高层经理,在推行过程中经常会听到:我这个项目时间太紧,当前不适合使用CMM,高层经理迫于市场的压力,甚至可能会提出不合实际的项目工期等等.推行CMM不仅仅是管理人员的事情,每个人都要积极参与.要改变原来的一些做法:即SEPG是在使劲的推进CMM的工作,而不是大家自觉自愿的来实施CMM.从SEPG的角度来看,要做好培训的工作,首先要解决的大家的思想认识问题,这还是比较难的,有些人的思想还是比较顽固的.当然管理首先要解决的是思想认识上的问题,不但在主观上要解决,在客观上也要有措施,光说不练是不行的,光练不说也是要否定的.我曾经遇到过类似的问题,有的开发人员或者项目经理在口头上是可以接受变革的,会配合工作的,但是在具体操作,很可能又会遇到事实上的否定,这时作为CMM的推广人员要尽快提出实施的具体措施,尽快落实.任何变革都要涉及到企业内的权利的再分配,不要忽视企业政治,这是客观存在的,所以一定要预防那些光说不练者.理解CMM直到198x年,人们还错误地认为,"只要有好的SE方法/工具,就可以开发出高质量的软件,就可以提高软件生产率".现在,人们认识到,"如果软件开发组织不能良好地定义/管理其软件过程,它就往往不能从SE中充分获益,从而也得不到预期的结果".即只重SE方法/工具,不重SE管理,不行.有句名言叫"拥有工具的傻子还是傻子"(呵呵,还有句名言叫"格言总是情绪的",因此认为自己SE意识不强的朋友,不要认为这句话是骂你的哟),用来说明重视SE管理的重要性.软件过程等于工程过程+管理过程软件工程学等于方法/技术+工具/环境+标准/规范+管理/控制前二者关注工程过程,后二者关注管理过程.过程:"为实现给定目标所执行的一系列步骤".软件过程:"人们用以开发/维护软件及其相关产品的一系列活动,包括〖软件工程活动〗和〖软件管理活动〗,自然,其中一定会涉及有关的方法/技术".其中"相关产品"指项目计划,设计文档,代码,测试用例等,它们在CMM中常被称为"软件工作产品".这里提〖软件过程〗"一定会涉及有关的方法/技术".于是,应该这样理解,即"CMM本身不是特定软件过程的定义",CMM只是建议如何"一步一个台阶"地改进〖软件过程〗.软件过程能力:〖软件开发组织/项目组〗通过执行其〖软件过程〗能够实现〖预期结果〗的〖程度〗.软件过程性能:〖软件开发组织/项目组〗通过执行其〖软件过程〗所得到的〖实际结果〗.软件过程能力是〖最可能的预期结果〗,可对〖软件开发组织/项目组〗而言.软件过程性能是〖已得到的实际结果〗,可对〖软件开发组织/项目组/某个软件项目〗而言.软件过程成熟度:一个特定软件过程被明确/有效地定义/管理/测量/控制的程度.CMM侧重于软件开发组织中的有关软件过程的宏观管理,for软件开发组织.PSP侧重于软件开发组织中的个体软件过程的微观优化,for软件开发个人(和小型群组).为什么把个人和小型群组并列呢因为它们的共同实质是"合作的规模小".个人开发也需要"合作"哟,你把需求分析做完向自己交接,自己和自己"合作"嘛.CMM和PSP二者相互补充/相互支持,因为如果众多个体没有好的过程意识和高的过程能力,整个开发组织的软件能力成熟度也不可能高.从事纯粹的软件开发的组织,其实是比较少的,这些组织,往往还进行软件采办业务/系统工程产品开发业务等,于是出现了一种将系统工程,软件工程,软件采办等集成在一起的CMM——它就是CMMI我国的SE专家基于CMM1.1,参照CMM2.0和有关资料,提出了符合我国国情的CSCMM.CSCMM与CMM的主要区别:在等级1和等级2之间插入了一个"基本级",使成熟度等级更加均匀.意义:以免软件开发组织长时间达不到2级,会是之失去信心.0.初始级.没有定义软件过程.1.基本级.定义了软件过程但执行可能不一致.2.可重复级.定义了软件过程且执行基本一致.3.已定义级.工程过程/管理过程都明确/妥善定义,并且文档化/标准化,成为软件开发组织的〖标准软件过程〗.组织内所有软件开发项目均采用该〖标准软件过程〗的〖经批准的剪裁版本〗.4.定量管理级.在开发过程中,能详细采集软件过程/软件产品的度量数据,从而对〖成本/进度/质量〗定量预测/定量控制.(可见,"定量管理级"这个名字比"已管理级"更传神.)5.优化级.能根据〖实践总结/新的技术〗,对〖标准软件过程〗不断改进.温昱注:上面体现的"定量"比"定性"更难更高级的思想,和数学/化学倒是一样的.另外,〖标准软件过程〗由开发组织来定,CMM并不对"用什么方法/技术"做建议.其实,既然优化级就是"能根据〖实践总结/新的技术〗对〖标准软件过程〗不断改进",更能看出CMM是独立于任何老技术/新技术的.呵呵,永不失效.在软件开发组织中,软件过程要规范化/具体化.在软件开发组织中,要通过正式文档/文件和培训,将其软件过程准确无误地告知所有员工,新员工要进行特别培训.CMM的组织结构:它推荐在最高领导之下设立SEPG(软工过程组),SQA(质量保证组),SEG(软工组).提示:三个组构成了软件开发中的"立法","监督","执法"体系,体现了西方文化的法治观念.CMM(CapabilityMaturityModel软件能力成熟度模型)为软件企业的过程能力提供了一个阶梯式的进化框架,它基于过去所有软件工程成果的过程改善的框架,吸取了以往软件工程的经验教训.它指明了一个成熟的软件组织在软件开发方面需要管理的那些主要工作,这些工作之间的关系,以及以怎样的先后次序一步一步的做好这些工作,使软件组织走向成熟.是目前国际上最流行也是最实用的软件生产过程标准,理解CMM需要注意以下几点:1.他仅指明该做什么,而没有指明如何做,他不是方法论(温昱注1:见后),但我们在学习CMM时,可以从中学到分析问题的方法.2.他仅指明该做的关键内容,他仅描述软件过程的本质属性,而并非面面俱到.抓问题主要方面的思想贯穿在整个CMM模型中.3.软件过程是指软件工程过程,软件管理过程和软件组织的过程三者的有机结合(温昱注2:见后).软件工程过程是我们理解的常规的软件的需求分析,设计,编码,测试等过程,软件管理过程是指为使软件过程顺利进行而进行和管理活动的集合.上述两个过程是以软件工程组为主的活动.软件组织的过程是企业级的对软件的组织活动,是以企业为主的活动.4.他是从软件过程的角度考虑问题,而并非关注软件开发工具.这与框架软件生存周期无关,也与所采用的开发技术(温昱注1:见后)无关.5.CMM为改善整个企业的软件过程提供了指南,而并非针对某个具体项目.SW-CMM并不能保证在这个过程框架下,产品开发百分之百的成功.产品的成功是多种因素的组合,例如市场等因素.6.CMM1.1是针对大型软件企业(500人以上)的,对小型的软件企业(50人以下)需要裁减.7.SW-CMM的过程的不断改进基于许多小的,进化的步骤而不是革命性的创新.8.基于CMM的过程改善投资力度大,周期长,而技术投资则可能在短期内有较快回报.单独依靠技术改进可能在短期内有较快回报,但最终可能一无所获.温昱注1:方法论是通过一组选定的〖方法〗和〖技术〗,来解决问题的策略.方法论等于方法(们)+技术(们).因此,这里提CMM"不是方法论","与所采用的开发技术无关",是正确的.我见过有人提"CMM是方法论",不对.当然,软件过程和方法/技术有关哟.

温昱注2:软件工程等于工程过程+管理过程.软件工程学等于方法/技术+工具/环境+标准/规范+管理/控制.前二者关注工程过程,后二者关注管理过程.但是,这里却提"软件过程是指软件工程过程,软件管理过程和软件组织的过程三者的有机结合".我认为它和前一观点并不矛盾,后一观点只是把〖管理过程〗分成了〖软件工程组的管理过程〗和〖整个企业的管理过程〗,又换了个名字叫"组织过程"而已.软件企业如何有效地推行CMM软件项目管理是针对软件开发进行的项目管理,它既有项目管理的共性,也有其特殊性.它的特殊性主要表现在软件项目的开发过程及其项目的最终产品--软件产品上.国内开展软件项目规范管理的时间并不长,软件企业各级管理者对软件项目管理的认识也很不够.目前很多软件项目的成功主要归功于技术高手的个人努力,或者碰巧由一位有能力的项目经理来管理项目,偶然性的因素很大.随着市场竞争的日趋激烈,市场环境的日益成熟,特别是在中国进入WTO后,国内软件企业与国外软件企业的竞争,以及开拓国外市场的需要,软件项目管理不完善的问题便越来越突出,软件项目管理显得越来越重要.为此,许多企业引进了目前世界上较完善的公认软件业标准CMM(软件能力成熟度模型SoftwareCapabilityMaturityModel),希望通过CMM的实施来提高公司的软件项目管理水平.但是,由于对软件项目管理的认识不足,人们对CMM的期望值也很大,对CMM的实施普遍存在以下误区:1.CMM能很快提高企业的软件产品质量,2.CMM能解决软件开发过程中的所有问题,3.迫于市场压力去拿一张CMM评估证书,而不去考虑CMM的真正作用,4.技术水平比管理水平更重要,当技术水平提高时,再考虑实施CMM5.等当抱着以上想法去实施CMM时,其效果便可想而知.而当有些企业认识到软件项目管理不能立竿见影地解决他们面临的问题时,他们当初对CMM实施的信心便开始动摇,就有可能走上形式化的死循环.那么,CMM是什么呢从内容上看,CMM标准分5个级别,每一级别由一些关键过程域(KPA)组成,也就是说,CMM的管理方式是基于过程的管理方式.每一个KPA都有目标(GOAL)要求,要通过CMM某级别的评估,必须达到本级别所有KPA的所有目标要求,以及本级别以下级别的所有KPA的所有目标要求.如过CMM,要达到CMML3的要求,也要达到CMML2的要求.对于如何达到目标要求,CMM标准又规定了以下五方面内容:1.执行约定:实施本KPA的方针要求与高级管理者的承诺与支持,2.执行能力:实施的先决条件,包括组织结构,资源,培训等方面的要求,3.执行的活动:为实现一个KPA要求所必须的角色和规程.包括制定计划,进行工作,跟踪,并在必要时采取纠正措施,4.测量和分析:采集数据表明过程的状态,预防问题的发生.5.实施验证:确保已建立流程的实施.包括验证,即高级管理者,主管和项目经理,SQA对过程相关活动的实施进行验证.总之,CMM规定了要达到的目标,实施需要的条件(约定,能力),需要做的工作(过程活动,测量和验证).而具体如何去实现,则须根据公司实际,可以八仙过海,各显神通.正如,规范化管理不会制约开发人员的创造力,而是使开发人员的创造力在正确且明确的轨道上,得到更充分,更有效的发挥,实施CMM的真正目的,是使公司的软件项目管理潜能,在借鉴成功企业的经验,结合本公司实际后,得到完全的展现,从而保证软件开发过程和软件产品的质量.推行CMM,相当于在企业内引入一种新的软件项目管理的方式,是软件项目管理的一场变革.它的成功,有赖于大多数组织成员,特别是各级管理者的赞同,支持和配合.所以,在实施CMM之前,公司应对面对的变革阻力有充分的认识和准备.首当其冲的,便是对CMM的正确认识.正如前面所介绍的,由于CMM推广在国内才起步不久,其真正作用目前还没有得到充分的证实.所以,过高,过分的期望,或者是怀疑,抵制的情绪,普遍存在.由于CMM实施的是一项长期的管理工作,不能一蹴而就,所以前者也会对CMM的真正落实实施起阻碍作用.因为,当他们意识到CMM不是万能的,不能满足他们过高,过分的期望时,他们反过来会否定CMM的意义和作用,从起初热情的拥护者转向坚决的反对者.所以,CMM的正确认识是推行CMM前必须达到的共识.解决对CMM正确认识的方法可以通过理智而循序渐进的宣传和培训活动来实现.为什么要强调理智呢正确的认识是为了有一个正确的态度.当一个人的情绪过于激动时,就不能冷静地,理智地思考问题.情绪的影响能较快地产生反响,但持续的时间不长.反之,理智,冷静的接受的观点,能较长时间的保持.CMM实施是一项长期的工作,不能凭一时的冲动,需要持久,稳定的推动力.所以培训和宣传要考虑采用条理清楚,说理充分的方式.培训和宣传工作也不是能一步就到位的,有一个对CMM标准逐步深入了解的过程.而且循序渐进的宣传和培训就像不断加深的记忆,起到了强化的作用,有助于对人们对CMM的认识深入而持久,不会轻易改变.其次,是管理与技术的对立与统一.CMM是软件项目管理的一个标准,软件项目能否成功,技术因素也是关键.技术水平直接影响着软件项目管理的方式方法,对管理起着制约作用.反过来,成功的软件项目管理则对技术的进步起到保障的作用,巩固技术改进的成果,使技术的积累与提升沿着正常的轨道有效地发展.没有管理的技术进步,也是不能持久的.目前,绝大多数企业的项目经理都是技术出身,所谓"技而优则仕".重技术,轻管理的现象普遍存在.而且技术对项目质量立竿见影的效果,也使项目经理对软件项目管理的缓慢而持久的对项目质量的保障作用持怀疑态度,或者说有只关注眼前利益,而不顾长远的利益的心态.这里,我想补充说一下,为什么CMM标准2级只有管理方面的内容,而到3级才引入软件工程,技术管理方面的概念.CMM标准的5级,就像是台阶,每上升一级,代表者软件过程能力的成熟,软件项目管理水平的提高.下面的台阶是向上走的基础.CMM2主要关注的是需求的管理(注意:是管理,而不是需求分析等技术),项目策划,项目跟踪与监督,软件配置管理和软件质量保证.这里,没有技术的内容在里面.为什么呢因为只有建立了管理的机制,技术的进步才能有保障,只有有了管理的基础,才能实现技术的积累与提升.项目经理是实施CMM的中坚力量,项目经理管理意识的提高是实施CMM成功的关键.为此,企业应建立有效的引导,激励机制,加强项目经理的管理知识及其应用的培训,并逐步建立有效的项目经理选拔培养制度.既然是变革,必然就有新观念,新概念的引进.前面已谈到CMM的正确认识对消除变革阻力,有效推行CMM的重要性.这是在较高层次上对CMM进行抽象后的认识,它起到的是统一思想的作用.在具体的实施过程中,会遇到CMM标准中的各种新的名词(实际上就是新的概念,新的管理思想的引入),包括CMM的组成结构.概念的理解是CMM标准理解的重要组成部分,概念不理解,就不能很好地理解标准要求.如何在操作中体现和落实这些思想,是我们实施过程中要去克服的.如果不能很好地处理这个问题,容易使人沮丧,从而有可能逐步丧失对CMM实施的信心.有人认为,只要SEPG成员(SEPG:软件工程过程组SoftwareEngineeringProcessGroup,负责CMM实施的小组,主要工作有组织过程的制定,维护和改进的组织工作)理解CMM标准要求(包括理解CMM标准中的各种概念)就可以了.其他人员,包括各级管理者,项目经理,开发人员不需要理解这些要求和概念,只要告诉他们如何去做就可以了.本人对这种说法持否定态度.如果不理解CMM标准要求,不理解各种概念的真正含义,只知其然,而不知其所以然,实施者如何能把CMM标准在具体工作中真正落实.就像只告诉你怎么走,而不告诉你往那里去,你将如何处理遇到的意外情况如果所说的行不通,怎么办你又如何根据实际情况有效地到达目的地也许在某些行业,这种"只告诉你如何做,不告诉你为什么要这么做"的方式是有效的,但这种方式绝对不适用于软件企业.为什么因为人的差异.我们要根据不同的人采取不同的激励方式.因为CMM推行本身就是引导和激励企业全体开发人员的持久的支持和参与,所以要根据开发人员本身的价值和他们的追求采取相应的CMM推行措施.开发人员的整体素质相对较高,从事的又是创造性很强的软件开发工作,自主性相对较强.让他们理解标准要求,理解各种概念,对于调动他们的积极性,从而有效的实施CMM是非常有帮助的.另一方面,CMM标准的核心管理思想,过程改进,也只有在全体实施者理解标准要求的基础上,积极参与的过程中才能实现.SEPG制定的初始过程文件可能是最好的,理想的,但绝对不可能是最适用的,最可行的,最可操作的.这需要各级实施者在使用文件定义过程的基础上,结合标准要求进行过程改进,从而找到符合标准要求的,适用于本企业的软件管理方式.所以,对各级人员进行CMM标准理解的培训非常重要.培训可以分为不同层次进行,一层一层逐步从抽象到具体.培训的方式也可以有演讲,座谈,案例讲解,讨论小组,实际操作中的指导等不同的方式.总而言之,有效推行CMM的关键,在于充分理解CMM标准的要求后,结合企业软件项目开发的实际,找出适合于本企业的软件项目管理方法.CMM标准的实施,重在解决企业软件项目开发过程中存在的问题,实现软件开发过程的持续改进.企业应当充分认识到推行前及推行过程中可能遇到的困难和阻力,并根据企业实际,采取有效的措施.只有这样,才能使推行CMM真正成为企业提高软件项目管理水平,保证软件产品质量,从而提高企业市场竞争力的有效手段

总之,单纯实施CMM,永远不能真正做到能力成熟度的升级,只有将实施CMM与实施PSP和TSP有机地结合起来,才能发挥最大的效力.因此,软件过程框架应该是CMM/PSP/TSP的有机集成,其相互关系可用图1来表示.

目前国内对软件工程管理存在的最大问题是认识不足.管理实际上是一把手工程,需要高层管理人员的足够重视.据国外有些大公司的介绍,他们在软件工程管理方面的投资一般占软件开发费用的10%左右,这些都需要得到高层管理人员的支持.而且软件过程的重大修改也必须由高层管理部门启动,这是软件过程改善能否进行到底的关键.此外,软件过程的改善还有待于全体有关人员的积极参与,否则不仅他本人将失去从软件过程改善中获得提高的机会,甚至还会成为过程改善的阻力.

除了要认识到过程改善工作是一把手工程这个关键因素外,还应认识到软件过程成熟度的升级本身就是一个过程,且有一个生命周期.因此,过程改善工作必然具有一切过程所具有的固有特征,即需要循序渐进,不能一蹴而就,需要持续改善,不能停滞不前,需要联系实际,不能照本宣科,需要适应变革,不能凝固不变.而且我认为,要将CMM/PSP/TSP引入软件企业,最有效的途径是要对单位主管和主要开发人员进行系统的培训.建议这些中小企业可以以CMM为框架,先从PSP做起,然后在些基础上逐渐过渡到TSP,以保证CMM/PSP/TSP确实在企业中生根开花.总之,我们必须从软件过程,过程工程的角度来看待CMM的发展,从经济学的观点来分析这个过程的价值.

七、CMM五级标准

第一级:初始级

在初始级,企业一般不具备稳定的软件开发与维护的环境.常常在遇到问题的时候,就放弃原定的计划而只专注于编程与测试.

第二级:可重复级

在这一级,建立了管理软件项目的政策以及为贯彻执行这些政策而定的措施.基于过往的项目的经验来计划与管理新的项目.

第:定义级

在这一级,有关软件工程与管理工程的一个特定的,面对整个企业的软件开发与维护的过程的文件将被制订出来.同时,这些过程是集成到一个协调的整体.这就称为企业的标准软件过程.

第四级:定量管理级

在这一级,企业对产品与过程建立起定量的质量目标,同时在过程中加入规定得很清楚的连续的度量.作为企业的度量方案,要对所有项目的重要的过程活动进行生产率和质量的度量.软件产品因此具有可预期的高质量.

第五级:(不断)优化级

在这个等级,整个企业将会把重点放在对过程进行不断的优化.企业会采取主动去找出过程的弱点与长处,以达到预防缺陷的目标.同时,分析有关过程的有效性的资料,作出对新技术的成本与收益的分析,以及提出对过程进行修改的建议.

CMM第一级:初始级

◆特征(1)软件过程的特点是杂乱无章,有时甚至混乱,几乎没有定义过程的规则或步骤.

(2)过分的承诺,常作出良好的承诺:如"按照软件工程方式,有序的工程来工作",或达到高目标的许诺.但实际上却出现一系列问题.

(3)遇到危机就放弃原计划过程,反复编码和测试.

(4)成功完全依赖个人努力和杰出的专业人才,取决于超常的管理人员和杰出有效的软件开发开发人员.具体的表现和成果都源于或者说是决定于个人的能力和他们先前的经验,知识以及他们的进取心和积极程度.

(5)能力只是个人的特性,而不是开发组织的特性.依靠着个人的品质或承受着巨大的压力,或找窍门取得成果.但此类人一旦离去,对组织的稳定作用也消失.

(6)软件过程是不可确定的和不可预见的.软件成熟性程度处于第一级软件组织的软件过程在实际的工作过程中被经常的改变(过程是随意的).这类组织也在开发产品,但其成果是不稳定的,不可预见的,不可重复的.也就是说,软件的计划,预算,功能和产品的质量都是不可确定和不可预见的.

◆过程(1)极少存在或使用稳定的过程

(2)所谓"过程",往往是"就这么干"而言.

(3)各种条例,规章制度互不协调,甚至互相矛盾.

◆人员(1)依赖个人努力和杰出人物.一旦优秀人物离去,项目就无法继续.(2)人们的工作方式如同"救火",就是在开发过程中不断地出现危机,以及不断的"救火".

◆技术引进新技术是极大风险.

◆度量不收集数据或分析数据.

◆改进方向(1)建立项目管理过程,实施规范化管理,保障项目的承诺.

(2)首要任务是进行需求管理,建立客户与软件项目之间的共同理解,使项目真正反映客户的要求.

(3)建立各种软件项目计划,如软件开发计划,软件质量保证计划,软件配置管理计划,软件测试计划,风险管理计划及过程改进计划.

(4)开展软件质量保证活动(SQA).

CMM第二级:可重复级

◆特征(1)进行较为现实的承诺,可按以前在同类项目上的成功经验建立的必要过程准则来确保再一次的成功.

(2)主要是逐个项目地建立基本过程管理条例来加强过程能力.

(3)建立了基本的项目管理过程来跟踪成本,进度和功能.

(4)管理工作主要跟踪软件经费支出,进度及功能.识别在承诺方面出现的问题.

(5)采用基线(BASELINE)来标志进展,控制完整性.

(6)定义了软件项目的标准,并相信它,遵循它.

(7)通过子合同建立有效的供求关系.

◆过程(1)软件开发和维护的过程是相对稳定的,但过程建立在项目一级.

(2)有规则的软件过程是在一个有效的工程管理系统的控制之下,先前的成功经验可以被重复.

(3)问题出现时,有能力识别及纠正.承诺是可实现的.

◆人员(1)项目的成功依赖于个人的能力以及管理层的支持.

(2)理解管理的必要性及对管理的承诺.

(3)注意人员的培训问题.

◆技术建立技术支持活动,并有稳定的计划.

◆度量每个项目建立资源计划.主要是关心成本,产品和进度.有相应的管理数据.

◆改进方向(1)不再按项目制定软件过程,而是总结各种项目的成功经验,使之规则化,把具体经验归纳为全组织的标准软件过程.把改进组织的整体软件过程能力的软件过程活动,作为软件开发组织的责任.

(2)确定全组织的标准软件过程,把软件工程及管理活动集成到一个稳固确定的软件过程中.从而可以跨项目改进软件过程效果,也可作为软件过程剪裁的基础.

(3)建立软件工程过程小组(SEPG)长期承担评估与调整软件过程的任务,以适应未来软件项目的要求.

(4)积累数据,建立组织的软件过程库及软件过程相关的文档库.

(5)加强培训.

CMM第:确定级

◆特征(1)无论管理方面或工程方面的软件过程都已文件化,标准化,并综合成软件开发组织的标准软件过程.

(2)软件过程标准被应用到所有的工程中,用于编制和维护软件.有的项目也可根据实际情况,对软件开发组织的标准软件过程进行剪裁.

(3)在从事一项工程时,产品的生产过程,花费,计划以及功能都是可以控制的,从而软件质量也可以控制.

(4)软件工程过程组(SEPG)负责软件活动.

(5)在全组织范围内安排培训计划.

◆过程(1)整个组织全面采用综合性的管理及工程过程来管理.软件工程和管理活动是稳定的和可重复的,具有连续性的.

(2)软件过程起了预见及防范问题的作用,能使风险的影响最小化.

◆人员(1)以项目组的方式进行工作.如同综合产品团队.

(2)在整个组织内部的所有人对于所定义的软件过程的活动,任务有深入了解,大大加强了过程能力.

(3)有计划地按人员的角色进行培训.

◆技术在定性基础上建立新的评估技术.

◆度量(1)在全过程中收集使用数据.

(2)在全项目中系统性地共享数据.

◆改进方向(1)开始着手软件过程的定量分析,以达到定量地控制软件项目过程的效果.

(2)通过软件的质量管理达到软件的质量目标.

CMM第四级:管理级

◆特征(1)制定了软件过程和产品质量的详细而具体的度量标准,软件过程和产品质量都可以被理解和控制.

(2)软件组织的能力是可预见的,原因是软件过程是被明确的度量标准所度量和操作.不言而喻,软件产品的质量就可以预见和得以控制.

(3)组织的度量工程保证所有项目对生产率和质量进行度量,并作为重要的软件过程活动.

(4)具有良好定义及一致的度量标准来指导软件过程,并作为评价软件过程及产品的定量基础.

(5)在开发组织内已建立软件过程数据库,保存收集到的数据,可用于各项目的软件过程.

◆过程(1)开始定量地认识软件过程.

(2)软件过程的变化小,一般在可接受的范围内.(3)可以预见软件过程中和产品质量方面的一些趋势.一旦质量经度量后超出这些标准或是有所违反,可以采用一些方法去改正,以达到良好的目标.

◆人员每个项目中存在强烈的群体工作意识.因为每人都了解个人的作用与组织的关系,因此能够产生这种群体意识.

◆技术不断的在定量基础上评估新技术.

◆度量(1)在全组织内进行数据收集与确定.

(2)度量标准化.

(3)数据用于定量地理解软件过程及稳定软件过程.

◆改进方向(1)缺陷防范,不仅仅在发现了问题时能及时改进,而且应采取特定行动防止将来出现这类缺陷.

(2)主动进行技术变动管理,标识,选择和评价新技术,使有效的新技术能在开发组织中施行.

(3)进行过程变动管理,定义过程改进的目的,经常不断地进行过程改进.

CMM第五级:优化级

◆特征(1)整个组织特别关注软件过程改进的持续性,预见及增强自身,防止缺陷及问题的发生,不断地提高他们的过程处理能力.

(2)加强定量分析,通过来自过程的质量反馈和吸收新观念,新科技,使软件过程能不断地得到改进.

(3)根据软件过程的效果,进行成本/利润分析,从成功的软件过程中吸取经验,加以总结.把最好的创新成绩迅速向全组织转移,对失败的案例,由软件过程小组进行分析以找出原因.

(4)组织能找出过程的不足并预先改进,把失败的教训告知全体组织以防止重复以前的错误.

(5)对软件过程的评价和对标准软件过程的改进,都在全组织内推广.

◆过程(1)不断地系统地改进软件过程.

(2)理解并消除产生问题的公共根源,在任何一个系统中都可找到:由于随机变化造成重复工作,进而导致时间浪费.为了防止浪费人力可能导致的系统变化.要消除"公共"的无效率根源,防止浪费发生.尽管所有级别都存在这些问题,但这是第五级的焦点.

◆人员(1)整个组织都存在自觉的强烈的团队意识.

(2)每个人都致力过程改进,人们不再以达到里程碑的成就而满足,而要力求减少错误率.

◆技术基于定量的控制和管理,事先主动考虑新技术,追求新技术.可以实现软件开发中的方法和新技术的革新,以防止出现错误,不断提高产品的质量和生产率.

◆度量利用数据来评估,选择过程改进.

◆改进方向保持持续不断的软件过程改进.

CMM总结:五层结构图

我们看到,在第五级上技术和过程的改进像普通商业活动一样有计划,有管理地进行.由于组织不断致力于改进过程的能力,所以软件开发组织的能力可持续改进.这种改进不仅表现在对存在的软件过程逐步改进,不表现在采用新技术和新方法方面的革新.

初始级等>,有纪律的过程等>,可重复级等>,标准一致的过程等>,确定级等>,能预见的过程等>,可管理级等>,不断改进的过程等>,优化级

八,实施软件质量保障体系CMM/TSP/PSP的建议

软件产业的发展,在经历了从70年始以结构化分析与设计,结构化评审,结构化程序设计以及结构化测试为特征的结构化生产时代,到90年代中期,以CMM模型的成熟模型和日益为市场接受为标志,已经进入以过程成熟模型CMM,个体软件过程PSP和群组软件过程TSP为标志的以过程为中心的时代,而软件发展第三个时代,及软件工业化生产时代,从90年代中期软件过程技术的成熟和面向对象技术,构件技术的发展为基础,已经渐露端倪,估计到2005年,可以实现真正的软件工业化生产,这个趋势应该引起软件企业界和有关部门的高度重视,及早采取措施,跟上世界软件发展的脚步.软件生产转向以改善软件过程为中心,是世界各国软件产业或迟或早都要走的道路.软件过程改善是当前软件开发技术的核心问题.

软件过程的三个流派:CMU-SEI的CMM/PSP/TSPISO9000质量标准体系ISO/IEC15504(SPICE)

CMU-SEI的CMM/PSP/TSP20世纪80年代中期国际软件产业界对软件的研究十分重视,因为在采用软件工程方法克服软件危机的过程中,人们认识到,软件是否完善是软件风险大小的决定因素.这方面的研究取得了重大的突破,其标志是1987年美国CarnegieMellon大学软件工程研究所(CMU/SEI)以W.S.Humphrey为首的研究组发表的研究成果"承制方软件工程能力的评估方法",该成果在1991年发展成为CMM(软件过程能力成熟度模型).软件过程能力成熟度模型被国际软件界公认为软件工程学的一项重大成果.软件目前,软件能力成熟度模型2.0版已经修订问世.CMM在软件工程的实践方面已有很大的影响,在工业界已得到广泛接受.不仅已用于军事控制系统,而且已用于全球经济领域的主要组织.有数千个组织在利用CMM的软件过程改进.在美国,关于CMM模型的教程已经作为参考和研究的对象出现了,这样做是为了让CMM模型极其相关问题引起工业界的更密切地关注.基于CMM模型的工具如成熟度问题集,软件过程评估训练和软件能力评价训练已经在CMM中渐渐得到修订.近期的关于CMM的活动主要是发展关于CMM模型的不同版本.由于CMM并未提供有关实现CMM关键过程域所需的具体知识和技能,因此,美国CarnegieMellon大学软件工程研究所(CMU/SEI)以W.S.Humphrey为首主持研究与开发了个体软件过程PSP(Personalsoftwareprocess)和群组软件过程TSP(TeamSoftwareProcess),形成CMM/PSP/TSP体系.ISO9000质量标准体系

最初的软件质量保证系统是在70年代由欧洲首先采用的,其后在美国和世界其他地区也迅速地发展起来.目前,欧洲联合会积极促进软件质量的制度化,提出了如下ISO9000软件标准系列:ISO9001,ISO9000-3,ISO9004-2,ISO9004-4,ISO9002.这一系列现已成为全球的软件质量标准.除了ISO9000标准系列外,许多工业部门,国家和国际团体也颁布了特定环境中软件运行和维护的质量标准,如:IEEE标准729-1983,730-1984,EuroNormEN45012等.ISO/IEC15504(SPICE)CMM的方法很快就引起了软件界的广泛关注,1991年国际标准化组织采纳了一项动议,开展调查研究,在此后引发了一系列的研究工作,现已取得重要成果,产生了技术报告ISO/IEC15504《信息技术-软件过程评估》,预计于今年产生正式标准.从该技术报告的内容来看,其基本的目的和思路,均与CMU/SEI的CMM相似.目前,学术界和工业界公认美国CarnegieMellon大学软件工程研究所(CMU/SEI)以W.S.Humphrey为首主持研究与开发的软件能力成熟度模型CMM是当前最好的软件过程,已成为业界事实上的软件过程的工业标准.国内学术界:中国生产力促进协会,北航SEI,中科院研究SEI等科研机构已于近几年在北京,上海,广州和深圳等地先后举办过多次报告会和研讨会,组织过课程学习和应用实验,开展了软件过程方面的研究与开发工作,并发表了多篇的研究成果和学术论文,在软件质量保障平台支撑环境也取得了一定的成果.产业界:近两年来,CMM在我国获得了各界越来越多关注,业界有过多次关于CMM的讨论,国务院发布的《鼓励软件产业和集成电路产业发展的若干政策》对中国软件企业申请CMM认证给予了积极的支持,在第17条规定"对软件出口型企业CMM认证费用予以适当支持."2000年中国村电脑节上还有CMM专题论坛,吸引了众多业内人士.鼎新,东大阿尔派,联想,方正,金蝶,用友,浪潮,创智,华为,东大阿尔派等大型集团或企业等都从1997---2000年起批企业都在进行研究,实验或实施预评估.其中鼎新公司从1997年着手进行CMM认证工作.1999年7月通过第三方认证机构的CMM2认证.东大阿尔派公司于2000年10月通过第三方认证机构的CMM2认证.2001年1月,联想软件经过英国路透集团的严格评估,顺利通过CMM2认证.

总体上讲,国内对软件过程理论的讨论与实践正在展开,目标是使软件的质量管理和控制达到国际先进水平,中国的软件产业获得可持续发展的能力.专家分析,在未来两三年内,国内软件业势必将出现实施CMM的.从这一趋势看,中国的软件企业已经开始走上标准化,规范化,国际化的发展道路,中国软件业已经面临一个整体突破的时代.

软件质量保障体系的实施

根据一直以来对国际上软件过程理论与实践的发展,尤其是近几年来着重在CMM,PSP和TSP以及ISO软件过程标准草案等方面的研究工作,国内专家学者建议,软件过程的改善应该从三方面着手进行:o软件能力成熟度模型CMM(CapabilityMaturityModel)o个体软件过程PSP(PersonalSoftwareProcess)o群组软件过程TSP(TeamSoftwareProcess)三者各有侧重,但互为补充.CMMo迄今为止学术界和工业界公认的有关软件工程和管理实践的最好的软件过程.o为评估软件组织的生产能力提供了标准.o为提高软件组织的生产过程指明了方向.CMM软件过程成熟度模型概要*1,比较在介绍CMM内容之前,首先概述一下不成熟软件组织与成熟软件组织的差异.在不成熟的软件单位,软件过程一般由实践者及其管理者在项目进程中临时拼凑而成,因而推迟进度和超出预算已成为惯例,产品质量难以预测,有时为了满足进度要求,常在产品功能和质量上做出让步.然而,一个成熟软件组织具有在全组织范围内管理软件,开发过程和维护过程的能力,规定的软件过程被正确无误地通知到所有员工,工作活动均按照已规划的过程进行.并通过可控的先导性试验和费效分析使这些过程得到改进,对已定义过程中的所有岗位及其职责都有清楚的描述,和通过文档与培训使全组织有关人员对已定义的软件过程都有很好的理解,从而使其软件过程所导致的生产率和质量能随时间的推移得到改进.表1给出了不成熟和成熟软件组织的比较,这种比较分析不仅是形成软件能力成熟模型的基础,也有利于理解该模型.

2,CMM的一些基本概念(1)软件过程:人们用于开发和维护软件及其相关过程的一系列活动,包括软件工程活动和软件管理活动.(2)软件过程能力:描述(开发组织或项目组)遵循其软件过程能够实现预期结果的程度,它既可对整个软件开发组织而言,也可对一个软件项目而言.(3)软件过程性能:表示(开发组织或项目组)遵循其软件过程所得到的实际结果,软件过程性能描述的是已得到的实际结果,而软件过程能力则描述的是最可能的预期结果,它既可对整个软件开发组织而言,也可对一个特定项目而言.(4)软件过程成熟:一个特定软件过程被明确和有效地定义,管理测量和控制的程度.(5)软件能力成熟度等级:软件开发组织在走向成熟的途中几个具有明确定义的表示软件过程能力成熟度的平台.(6)关键过程域:每个软件能力成熟度等级包含若干个对该成熟度等级至关重要的过程域,它们的实施对达到该成熟度等级的目标起到保证作用.这些过程域就称为该成熟度等级的关键过程域,反之有非关键过程域是指对达到相应软件成熟度等级的目标不起关键作用.归纳为:互相关联的若干软件实践活动和有关基础设施的一个集合.(7)关键实践:对关键过程域的实践起关键作用的方针,规程,措施,活动以及相关基础设施的建立.关键实践一般只描述"做什么"而不强制规定"如何做".整个软件过程的改进是基于许多小的,渐进的步骤,而不是通过一次革命性的创新来实现的,这些小的渐进步骤就是通过一些着关键实践来实现.(8)软件能力成熟度模型:随着软件组织定义,实施,测量,控制和改进其软件过程,软件组织的能力也伴随着这些阶段逐步前进,完成对软件组织进化阶段的描述模型.

3,CMM模型概要软件开发的风险之所以大,是由于软件过程能力低,其中最关键的问题在于软件开发组织不能很好地管理其软件过程,从而使一些好的开发方法和技术起不到预期的作用.而且项目的成功也是通过工作组的杰出努力,所以仅仅建立在可得到特定人员上的成功不能为全组织的生产和质量的长期提高打下基础,必须在建立有效的软件工程实践和管理实践的基础设施方面,坚持不懈地努力,才能不断改进,才能持续地成功.CMM提供了一个框架,将软件过程改进的进化步骤组织成5个成熟等级,为过程不断改进奠定了循序渐进的基础.这5个成熟度等级定义了一个有序的尺度,用来测量一个组织的软件过程成熟和评价其软件过程能力,这些等级还能帮助组织自己对其改进工作排出优生次序.成熟度等级是已得到确切定义的,也是在向成熟软件组织前进途中的平台.每一个成熟度等级为连续改进提供一个台基.每一等级包含一组过程目标,通过实施相应的一组关键过程域达到这一组过程目标,当目标满足时,能使软件过程的一个重要成分稳定.每达到成熟框架的一个等级,就建立起软件过程的一个相应成分,导致组织能力一定程度的增大.下面表2给出了CMM模型概要,表中的5个等级各有其不同的行为特征.要通过描述不同等级组织的行为特征:即一个组织为建立或改进软件过程所进行的活动,对每个项目所进行的活动和所产生的横跨各项目的过程能力.表2CMM模型概要4,CMM的结构软件机构的最终质量保证模式可以用下图1说明,图1给出软件质量计划,质量控制,质量改进一个简单循环,其实,它归纳出CMM的真正内核,所以,可以说CMM的模型是一种新兴管理思想:连续改进(ContinuosImprovement)循环的体现.图1

CMM的作用n科学地评价软件开发单位的软件能力成熟等级n帮助软件开发单位进行自检,了解自己的强项和弱项,从而不断完善和改进单位的软件开发过程,确保软件质量,提高软件开发能效率.

CMM实施的思考

根据CMM的基本原理,基本内容和基本方法,对CMM提出4个问题供大家思考:1.过程成熟度需要多长时间多少费用对企业有何好处2.影响基于CMM的软件过程的成败因素是什么3.CMM是否会导致过度官僚主义是否会使组织变得更保守,不愿冒风险4.有无合适的,易理解的框架(不仅仅是告诉"我们做什么",而且告诉"我们怎么做")可指导所有软件组织进行CMM改进这些针对CMM提出的问题与争论,国外进行了一些调查工作,但国内基本上没有这方面的专业调查和研究,以后再根据国内企业对CMM的认识,认证的增强和增多,这些问题会得到更科学的解答.现给出国外针对上述问题的一些调查结果:问题1:成熟度提升一级建议安排1年到2年,费用问题国内外相距太远不好比较.对企业的好处问题给出下表说明:

问题2:影响过程改进失败的因素有:无法实施计划和跟踪,突发事件或危险造成,时间和资源限制造成,知道应该做什么而不知道如何做造成.问题3:大部分(84%-96%)不认为会使组织变成官僚主义机构,难于创新和不敢冒风险.问题4:这需要不断总结经验,提出办法.

在国内要想取得过程改进成功,作者认为:1,软件过程改进必须有高级主管的支持与委托,并积极地管理过程改进的进展.2,中层管理的支持很重要3,责任分明,过程改进小组威望高4,基层的支持与参与极端重要5,如何利用定量的可观察数据,尽快使过程改进成果可见,从而激励参与者的兴趣6,为企业的商业利益怎么写作,并要求有成功的过程改进相符的企业文化变革

如果企业出现如下情况,过程改进肯定就失败:1,高层领导机构态度不明确,见解不一致2,各部门只管自己,互不通气,互不支持3,对以前不成功的过程改进冷嘲热讽4,项目成员认为软件过程改进会影响实际工作,而不支持软件过程改进活动

结论:CMM不是万能的,它的成功与否,与一个组织内部有关人员的积极参与和创造性活动是密不可分的.

CMM是对软件工程的工业实践所需的有关目标,方法和实践的最佳有效描述.问题是如何在一个实验室或者产业环境中做到CMM规则的应用CMM是一个致力于组织过程改进的框架,问题是如何才能确保CMM使工作有效而且便利未提供有关实现关键过程域所需要的具体知识和技能.因此,个体软件过程PSP(PersonalSoftwareProcess)也就应运而生.PSP概述

个体软件过程(PersonalSoftwareProcess,PSP)是由美国CarnegieMellon大学软件工程研究所(CMU/SEI)的Wattss.Humphrey领导开发的,于1995年它的推出,在软件工程界引起了极大的轰动,可以说是由定向软件工程走向定量软件工程的一个标志.PSP是一种可用于控制,管理和改进个人工作方式的自我改善过程,是一个包括软件开发表格,指南和规程的结构化框架.PSP为基于个体和小型群组软件过程的优化提供了具体而有效的途径,例如如何制订计划,如何控制质量,如何与其他人相互协作等等.在软件设计阶段,PSP的着眼点在于软件缺陷的预防,其具体办法是强化设计结束准则,而不是设计方法的选择.根据对参加培训的104位软件人员的统计数据表明,在应用了PSP后,软件中总的差错减少了58.0%,在测试阶段发现的差错减少了71.0%,生产效率提高了20.0%.PSP的研究结果还表明,绝大多数软件缺陷是由于对问题的错误理解或简单的失误所造成的,只有很少一部分是由于技术问题而产生的.而且根据多年来的软件工程统计数据表明,如果在设计阶段注入一个差错,则这个差错在编码阶段引发了3一5个新的缺陷,要修复这些缺陷所花的费用要比修复这个设计缺陷所花的费用多一个数量级.因此,PSP保障软件产品质量的一个重要途径是提高设计质量.

个体软件过程PSP的现状o从1993年开始,美国,欧洲,澳大利亚等地已先后有20多所大学开设了讲授PSP的课程.o在工业界,PSP也先后在Motorola,HP,AIS等公司推广使用.o北航软件工程研究所于1997年开始,在北航计算机科学与工程系率先讲授了PSP课程,并组织了PSP应用实验.

个体软件过程PSP的演化*

个体软件过程PSP的内容

PSP与具体的技术(程序设计语言,工具或者设计方法)相对独立,其原则能够应用到几乎任何的软件工程任务之中.PSP能够:(1)说明个体软件过程的原则,(2)帮助软件工程师作出准确的计划,(3)确定软件工程师为改善产品质量要采取的步骤,(4)建立度量个体软件过程改善的基准,(5)确定过程的改变对软件工程师能力的影响.

个体软件过程PSP支持环境

北航软件工程研究所在研制的基于Inter的"个体软件过程支持环境",支持个体软件过程的定义,运作,度量,分析和优化,支持PSP在实际软件开发项目中的应用,支持PSP概念和方法的推广普及,支持软件工作人员软件工程方面素质的提高.

个体软件过程PSP的作用

l使用自底向上的方法来改进过程,向每个软件工程师表明过程改进的原则,使他们能够明白如何有效地生产出高质量的软件.l为基于个体和小型群组软件过程的优化提供了具体而有效的途径.其研究与实践填补了CMM的空白.l帮助软件工程师在个人的基础上运用过程的原则,借助于PSP提供的一些度量和分析工具,了解自己的技能水平,控制和管理自己的工作方式,使自己日常工作的评估,计划和预测更加准确,更加有效,进而改进个人的工作表现,提高个人的工作质量和产量,积极而有效地参与高级管理人员和过程人员推动的组织范围的软件工程过程改进.

群组软件过程TSP概述

致力于开发高质量的产品,建立,管理和授权项目小组,并且指导他们如何在满足计划费用的前提下,在承诺的期限范围内,不断生产并交付高质量的产品.TSP指导项目组中的成员如何有效地规划和管理所面临的项目开发任务,并且告诉管理人员如何指导软件开发队伍.始终以最佳状态来完成工作.TSP实施集体管理与自己管理自己相结合的原则,最终目的在于指导开发人员如何在最少的时间内,以预定的费用生产出高质量的软件产品,所采用的方法是对群组开发过程的定义,度量和改进.

实现TSP方法需要具备的条件o需要有高层主管和各级经理的支持,以取得必要的资源o整个软件开发小组至少应在CMM的第二级(可重复层).o全体软件开发人员必须经过PSP的培训,并有按TSP工作的愿望和热情.o开发小组成员应在2到20个人之间.在实施TSP的过程中,首先要有明确的目标,开发人员要努力完成已经接受的委托任务.在每一阶段开始,要做好工作计划.如果发现未能按期按质完成计划,应立即分析原因,以判定问题是由于工作内容不合适或工作计划不实际所引起,还是由于资源不足或主观努力不够所引起.开发小组一方面应随时追踪项目进展状态并进行定期汇报,另一方面应经常评审自己是否按PSP的原理工作.开发小组成员应按自己管理自己的原则管理软件过程,如发现过程不合适,应及时改进,以保证用高质量的过程来产生高质量的软件.项目开发小组则按集体管理的原则进行管理,全体成员都要参加和关心小组的规划,进展的追踪和决策的制定等项工作.

按TSP原理对开发小组的基本度量要素o所编文档的页数.o所编代码的行数.o花费在各开发阶段或各开发任务上的时间(以分为单位).o在各个开发阶段中引入和改正的差错数目.o在各个阶段对最终产品增加的价值.

度量TSP实施质量的过程质量元素o软件设计时间应大于软件实现时间.o设计评审时间至少应占一半以上的设计时间.o代码评审