★ CMMI软件过程能力认证评估★
7.1企业如何选用CMM/CMMI
企业选择CMM还是CMMI，主要基于以下几个方面进行考虑：
• 1. 实施企业的业务特点：如果企业的规模不是很大，业务又集中在软件开发为主，那么还是软件CMM比较适用。如果企业的规模比较大（开发人员100人以上），并且业务不仅仅集中在软件开发，还包括硬件开发哪怕是硬件代理（采购）都可以考虑实施CMMI。
• 2. 实施企业对过程改进的熟悉程度：如果企业已经实施过ISO9000，并且取得了较好的效果，那么可以考虑实施CMMI。如果企业虽然没有实施过CMM，但是对于过程改进一直比较关注，接受过不少相关培训，甚至能够自发的进行一些过程改进，那么也可以考虑实施CMMI。如果过去没有接触过类似的工作，那么最好先从软件CMM 2级开始，首先建立持续过程改进的思路。另外，软件CMM的要求也比CMMI要稍低一些。可以适当降低实施的难度。
• 3. 实施企业对过程改进项目的预算：不论怎样，几乎可以肯定地说，实施CMMI的费用肯定要比实施CMM高出一些。而就模型本身来看，CMMI的2级7个过程区域在内容上并不比软件CMM的2级6个关键过程区域多多少。所以，我们完全可以“少花钱、多办事”，也就是说可以采用CMM的实施和评估方法，但可以在过程改进的时候参考CMMI的要求，这样就会经济很多。
7.2你的CMM认证是“真”的吗
不用看一个企业通过了CMM的几级认证，只先问它都用了哪些自动化开发工具，用到了什么程度，就知道它的CMM认证是“真”是“假”。
听软件企业说CMM(Capability Maturity Model，能力成熟度模型)认证听了很久，到现在都已经开始谈CMMI(Capability Maturity Model Integration，能力成熟度模型集成)了。也不断听到国内软件企业通过了CMM2、CMM3认证的消息，甚至有少数企业通过了CMM4、CMM5级认证。但是却没看到国内软件企业拿到外包项目的数量急剧上升，甚至在某些领域，国内一些获得CMM3资质的企业的外包订单反而远远少于印度一些获得CMM2认证的企业，不少台湾地区的软件企业也比祖国大陆的软件企业做得更好。
为什么会这样？曾有业界人士自暴内幕：在具体的软件外包项目谈判时，外包方问，“你们都采用什么自动化开发平台啊？”承包方一听这话就傻眼了。不少通过了CMM认证的企业把最多的精力花在了CMM资质评估上，例如在评估前邀请印度培训师进行内部培训，协助准备一大堆评估需要的资料，然后大张旗鼓地迎接评审，但获得资质之后又继续照旧原来的手动开发流程，根本不会用到任何自动化开发工具。这样的谈判最终往往会以失败告终。精明的外包方知道，如果没有任何自动化开发工具，CMM认证中的很多事情是难以手动完成的，就像一个汽车流水线中不可能所有工序都是手工操作一样。
为CMM而CMM是不少企业在CMM实施中很容易走进的误区，认为拿到一定的CMM资质之后就能够争取到无数的外包业务，以至最终为了达到这一目的而不择手段，甚至一些媒体在谈到CMM的时候也将讨论重点放在了CMM过高的评估费用上，而忘了实施CMM最原始的目的是为了提高对软件开发的管理，最终实现ROI的提升。
这种本末倒置的做法一直以来就受到业内专家的指责，但解决的办法也只是停留在呼吁软件企业要端正对CMM的态度。呼吁意味着什么？意味着最终寄希望于软件企业自身的观点转变。其实绝大多数企业也都明白要用长远眼光去看问题，但眼看一些虚假繁荣的软件开发企业因为顶着CMM认证的光环而受益，不少心里明白的企业决策者还是抱着侥幸心理试图闯关。
事实上，很多时候对一件事的态度真的只是一念之差。能否有态度的端正一方面取决于自身的主观因素，另一方面客观环境和客观条件的限制更是帮助软件企业端正CMM态度的良药。笔者希望告诉这些侥幸的企业，当CMM/CMMI认证体系越来越严谨，当软件外包方的要求越来越严格，当软件消费者的消费心理越来越成熟，这种侥幸心理遭遇的将是一败涂地。而且更重要的是，很多能够大大提高软件开发效率、降低软件开发成本的做法，如果没有自动化工具的帮助是完全做不到的。
例如外包订单中的团队协作开发，异地同步软件开发是不少外包订单常用的手法，美国、欧洲和亚洲相互之间的时差都在8小时左右，如果三地能够利用时差一天实现24小时的不间断开发无疑将大大提高开发效率，但这样的协作开发如果没有自动化的软件配置管理工具、变更管理工具、统一的质量系统流程等的帮助，根本无法完成。
再例如，版本控制管理工具一般都能帮助软件开发回到任何一个时间点的生产基线，当发现开发思路有所偏差时，可以自动将所有程序恢复到从前一个时间点的状态，这对手工开发来说完全不可想象。
IBM软件部Rational软件大中华区销售总经理陈致平先生接受记者采访时还提到，在很多外包订单中，上游开发商希望承包方的开发环境能够与自己的自动化开发环境接轨，就像制造产业链的上游厂商可能希望下游供应商能够与自己使用相同的ERP、CRM、SCM系统一样，从而能够进行无缝的连接。
除了外包项目，一般的软件开发项目如果使用自动化开发工具，在减少重复开发、管理每个开发者的访问权限、避免软件资产流失等方面也都有很大的帮助。自动化开发工具不是实现CMM的充分条件，但一定是必要条件。
自动化工具不是装点门面
自动化开发环境曾经经过多个阶段的演变，从最早的简单CASE工具，到后来的应用开发生命周期(Application Development Life Cycle)、软件开发生命周期(Software Development Life Cycle)，再到今天的自动化软件开发平台(Software Development Platform)，软件开发的状态也从纯手工进化到片断式的自动化开发，最终进化到完全的自动化开发。
当软件产品价格越来越便宜，软件产品的功能越来越多样化，软件开发企业就将面临着像制造企业必须上马ERP一样的情形，自己的软件生产线自动化程度越高，自己的核心竞争能力也就越强。
CMM认证不是用来装点门面的，自动化开发工具和平台更不是用来装点门面的。有限的资金要用在刀刃上，如果资金有限，或许把评估费用放在自动化开发工具的投资上，反而更加务实。当然如果资金状况允许，自然可以鱼与熊掌兼得。
7.3CMM实施经验谈
在基于CMM实施软件过程改善时，有些根本的思想认识问题解决不了，往往会使实施的周期比较长，效果不好，甚至导致过程改善的失败或中止。软件企业的高层领导、企业的过程改善主管、销售人员、项目经理及一般的开发人员都需要对这些问题统一认识，在此基础上才能消除各方面的阻力，把握好过程改善的方向，控制好过程改善的进度。笔者在总结了3年的实施CMM的经验教训后，归纳了如下几个思想认识问题，供拟准备进行过程改善或正在进行过程改善的软件企业同行参考：
CMM不是万能的，只有CMM是不行的，还要技术(开发方法、工具)人员二个要素一起改善
在软件工程发展的历史进程中，人们为了解决软件危机，尝试了采用诸如形式化描述语言、结构化开发方法、CASE工具、构件化开发方法等等各种解决方案，但是效果并不那么显著，CMU SEI提出了软件过程能力成熟度模型（CMM）基于过程的角度来解决软件危机。那么是否实施了CMM，软件企业的开发能力就一定能提高，一定能带来经济效益呢？答案是否定的。如果企业里要带来经济效益必须要结合软件过程、工具、开发方法、人员等多种因素一起提高，才能保证带来经济效益，因为人员、技术和过程是支撑软件开发平台的三条腿，少了那一条都不行。大家也都知道木桶原理，一个木桶可存槠水的最大容量是由最短的那根木头决定的。在企业的开发能力中过程、技术(含工具、方法)、人员都是主要的因子，都需要全面提高，只关注一个方面，而忽略了其他方面，都是有害的。
在开始实施CMM时，最容易犯的一个错误就是"唯管理论"或孤立地只抓过程改善，忽略了开发技术与人员的提高，过分强调管理的作用，实施了半年或一年后，发现企业的生产能力并没有得到明显的改善，这时反对的声音就会成为主流，过程改善就难以继续进行了。有的企业采用面向对象的开发方法进行软件开发，但是企业内并没有对面向对象技术真正了解的专家，虽然也采用RUP过程、也采用ROSE等开发工具，但是仅仅是形似，没有做到真正的OO方法，没有得到OO方法的精髓，这种问题仅仅依靠过程改善是无法解决的。还有的企业开发人员的积极性很差，工作热情很低，企业的激励机制没有起到很好的作用，这种问题也是依靠CMM无法解决的。
管理就是预防，管理的作用是隐性的，不都是立竿见影的，大家要有耐心
在实施CMM时，企业的管理层在开始时往往会对过程改善期望值太高，希望短时间内效果显著，上面我们谈到了，效果显著与否不是由一个方面的要素决定的，需要多个因素共同改善。而管理的最大作用是预防，防患于未然。任何的管理的改善都是符合J曲线的，即在改善的初期企业的运行效率可能会下降，甚至可能会出现一些混乱的局面，不过渡过了这段时间就会看到效果。所以在改善的初期大家要有这个思想准备，要有耐心。
坚持活学活用，以我为主
机械照搬CMM的条文是在实施CMM时常犯的错误。在国内的软件企业中，都是从作坊式的软件组织逐步发展过来的，也没有经过软件工程化阶段，甚至也没有什么标准、规范。真正超过10年软件工程经验的人员更是比较少的，加上大家不愿从事管理，因而有的企业所组建SEPG的人员中可能在工程经验方面是有欠缺的，又没有真正的有实践经验的专家进行指导，所以对CMM的理解就不可能一下就很深刻，不敢裁剪CMM，容易机械照搬CMM条文，其实这恰恰违背了CMM的精神，CMM是软件工程经验的集大成，是从实践中总结出来，用以指导实践的，CMM本身也在更新版本，不断完善。每个企业都有自己的特点，就象微软的MSF，那是微软自己内部的管理过程标准，是微软的产品开发经验总结，有些内容是CMM中没有的，完全可以借鉴过来使用，所以只要可以提高企业自己的软件管理水平，就应该大胆地来尝试。
在推行CMM时，所以遇到的阻力，很大程度上是由于照搬CMM的条文，不切合项目组的实际，没有具体情况具体分析。实际上，一线的管理人员、开发人员最了解实际。谁了解实际，谁有发言权。所以在制定CMM规程标准时，尤其是在制定大家要执行的操作规程、模板和记录表样时，一定要得到执行者的认同，否则就容易造成执行和沟通的障碍，你硬要推，表面上看来似乎大伙也照规程做了，其实是表面文章，对改善没有实际帮助，以导致SPI工作受阻。
要改良式不要革命式
以革命的方式来实施CMM，期望通过一场运动来解决过程能力的问题，一种可能是不懂CMM，不晓得管理的改进是循序渐进的，一种可能是明知故犯，期望在短期内通过CMM评估，单纯追求市场上的轰动效应。有的企业在短时间内虽通过了CMM几级评估，我想恐怕由于没有实效而得不到大家的认同而难以将这种"水平"持续下去。一个企业引入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的推广人员要尽快提出实施的具体措施，尽快落实。任何变革都要涉及到企业内的权利的再分配，不要忽视企业政治，这是客观存在的，所以一定要预防那些光说不练者。
7.4ISO9000与CMM的比较
ISO9000与CMMI的比较
本文试图从大家所熟悉的ISO 9001标准入手，对ISO 9001、ISO 900-3和CMM之间的区别和联系做个简单的分析，探讨一些大家感到困惑的问题，包括：
1)取得ISO 9000认证的组织大约相当于CMM的哪个等级？
2)取得CMM第2级(或第3级)的组织是否可以认为满足ISO 9001要求？
3)取得ISO 9001证书与取得CMM相应等级证书的企业，谁的质量管理/质量保证水平/能力更高？
一、背景
ISO 9000族国际标准是在总结了英国的国家标准基础之上产生的，因此，欧洲通过ISO 9000认证的企业数量最多，约占全世界的一半以上。受此影响，相当多的欧洲软件企业选择了ISO 9001或TickIT****（ISO 9001）认证。CMM是由美国卡内基-梅隆大学的软件工程研究所（SEI）开发的软件成熟度模型，美国的软件企业更多的选择取得CMM等级证书。在形式上，CMM分为5个等级（第1级级别最低，第5级级别最高），与ISO 9000审核后只有“通过”和“不通过”两个结论相比，CMM是一个动态的过程，企业在取得低级别证书后，可根据高级别的要求确定下一步改进的方向。在基本原理方面，ISO 9001和CMM都十分关注软件产品质量和过程改进。尤其是ISO 9000:2000版标准增加持续改进、质量目标的量化等方面的要求后，在基本思路上和CMM更加接近。
① 本文参考了Mark C. Paulk先生的 HOW ISO 9001 COMPARES WITH THE CMM，但观点不尽相同。
② ISO 9001是软件企业开展质量体系认证依据的标准；
③ ISO 9000-3是国际标准化组织（ISO）制定的软件开发企业实施ISO 9001指南；
④ TickIT认证是一个基于ISO 9001的、专门针对软件开发企业的认证制度，与取得非TiclIT（ISO 9001）认证相比，TickIT对审核员的专业要求更高， TickIT（ISO 9001）证书在业界更有权威性
二、二者对比
1.ISO 9001和CMM既有区别又相互联系，两者不可简单的互相替代。
尽管ISO 9001标准的一些要求在CMM中不存在，而CMM的一些要求在ISO 9001标准中也不存在，但不可否认的是，两者之间的关系非常密切。当然，两者之间的差别也很明显，例如， ISO 9001标准的要素4.7和4.15在CMM中没有细述，而4.19则是分散在CMM的各部分中。ISO 9001的一些要素可以在CMM中找到完全对应的部分，另外一些要素则是比较分散的对应。两者的最大相似之处在于两者都强调“该说的要说到，说到的要做到”。对每一个重要的过程应形成文件，包括指导书和说明，并检查交货质量水平。CMM强调持续改进，ISO 9001的1994版标准主要说明的是“合格质量体系的最低可接受水平”（ISO 9001的2000版标准也增加了持续改进的内容）。另外，1999年底，由美国质量协会（ASQ）和MOTOROLA、NOKIA、BELL SOUTH等100多家企业、机构共同制定的电信行业（包括电信软件开发企业）质量体系标准TL 9000正式发布，在处理已经取得CMM和ISO 9001认证的软件开发企业如何升级到TL 9000时，补充审核的要求有很大差异，这从一个侧面也可以说明它们之间的差别。但很明显，取得ISO 9001认证对于取得CMM的等级证书是有益的，反之，取得CMM等级证书，对于寻求ISO 9001认证也是有帮助的。
2.取得ISO 9001认证并不意味着完全满足CMM某个等级的要求
表面上看，获得ISO 9001标准的企业应有CMM第3至第4级的水平，但事实上，有些获得CMM第1级的企业也获得了ISO 9001证书，原因是ISO 9001强调以顾客的要求为出发点，不同的顾客要求的质量水平也不同，而且各个审核员的水平/解释也有些差异；如果审核员接受过TickIT审核员课程的培训，那么经他审核获得ISO 9001证书的企业大约相当于CMM第 3级的水平。由此可以看出，取得ISO 9001认证所代表的质量管理和质量保证能力的高低与审核员对标准的理解及自身水平的高低有很大的关系，而这不是ISO 9001标准本身所决定的，ISO 9001标准只是质量管理体系的最低可接受准则，不能说已满足CMM的大部分要求。有一点可以肯定，ISO 9001认证合格的企业至少能满足CMM第2级的大部分要求以及第3级的一部分要求。
3.取得CMM第2级(或第3级)不能笼统的谈可以满足ISO 9001的要求
CMM 第2级的所有关键过程都涉及ISO 9001的要求，但都低于ISO 9001的要求。另外，一些CMM第1级的组织在满足了第2级和第3级的一些关键过程的要求后，也可以获得ISO 9001认证证书。一些CMM第2级或第3级的企业可能被认为符合ISO 9001的要求，但是，甚至一些第3级企业也需另外满足ISO 9001的要素4.15的搬运和交付要求以及补充对市售软件和可复用软件的控制。当然，尽管CMM没有完全满足ISO 9001标准的一些特定要求，但包含了大部分的要求。不可否认，CMM是专门针对软件开发企业设计的，因此在针对性上比ISO 9001要好。ISO已经意识到这个问题，针对软件开发企业应用ISO 9001提供了指南标准（ISO 9000-3），预计在2000年底发布的ISO 9000:2000也考虑了软件企业的特点。需要特别说明的是，CMM强调的是软件开发过程的管理，对于国内软件企业涉及较多的“系统集成”并没有考虑，如果单纯按照CMM的要求建立质量体系应该注意补充“系统集成”方面的内容。
三、结束语
本文并没有回答CMM和ISO 9001谁更好，也不想回答这个问题，一个体系的好坏是由很多方面决定的。上面仅仅反应了作者对这两个体系的一些看法，不免带有一些主观和片面。但是，对于一个软件开发企业来说，获得什么样的认证证书只是表面的，重要的是如何着眼于持续改进以更好的保证软件开发的质量、满足顾客的要求，从而获得竞争优势，这是每一个软件开发企业应该认真考虑的问题。
7.5SPCA 简介
软件过程及能力成熟度评估（SPCA）
1 软件过程及能力成熟度评估
“软件过程及能力成熟度评估”（简称SPCA）是软件过程能力评估和软件能力成熟度评估的统称，是信息产业部会同国家认证认可监督委员会在研究了国际软件评估体制，尤其是美国卡内基-梅隆大学SEI所建立的能力成熟度模型能力成熟度模型CMMI，并考虑国内软件产业实际情况所建立的软件评估体系。
SPCA依据的评估标准是SJ/T 11234和SJ/T 11235，这两个标准是在深入研究了CMM、CMMI、ISO/IEC TR15504、ISO9000、TL 9000以及其他有关的资料和文件以及国外企业实施CMM的实际情况后，结合国内企业的实际情况，以CMMI作为主要参考文件最终形成的，这两个行业标准由信息产业部于2001年5月1日发布实施。
SJ/T 11234《软件过程能力评估模型》针对软件企业对自身软件过程能力进行内部改进的需要，与CMMI连续表示形式基本相同。该模型有22个过程，分为4大类，即：过程管理类、项目管理类、工程化类和支持类，每个过程能力从0到5划分为6个评估等级，每个等级包含了通用目标、通用惯例、特定目标和特定惯例，它们组成一套衡量准则。按此准则对实际运行的过程进行评估，可以确定当前软件过程的能力状态。对每个过程评估后，可以得到企业软件过程能力的一条“谱线”。企业还可以针对软件开发项目，根据项目的目标和要求，有针对性地“弄清楚”有关过程的能力状态，实施必要的过程改进，以支持项目的完成。
SJ/T 111235《软件能力成熟度模型》针对软件企业综合能力第二方或第三方评估的需求，与CMMI分阶段表示形式基本相同。该模型用成熟度1～5个等级来描述综合软件能力。与SJ/T 11234相同，也有22个过程方面。除了成熟度等级1外，每个等级包含若干个过程方面，每个过程方面的实施情况由相应目标和惯例的实施情况体现。采用这种衡量准则可以评估软件企业的综合能力——软件能力成熟程度。
SPCA评估遵循《软件过程及能力成熟度评估指南》，该指南是国家认监委和信息产业部2002年8月共同发布的利用SJ/T11234或SJ/T11235实施评估的操作指南。评估过程由经过培训的专业队伍以评估参考模型作为确定过程的强项和弱项的基础而对一个或多个过程进行检查。从不同用途考虑，评估分为内部过程改进评估和顾客选择评价两种。
目前，国家认证认可监督管理委员会（CNCA）和信息产业部已经联合发布《软件过程及能力成熟度评估监督管理办法》，CNCA授权的中国认证机构国家认可委员会(CNAB)和中国国家认证人员培训认可委员会（CNAT），已制定和试点实施“软件过程及能力成熟度评估”认可规则，并成立SPCA工作组，以推动中国软件过程及能力成熟度评估的实施。
2 实施SPCA的作用和意义
软件过程及能力成熟度评估可以规范软件开发过程及其管理、规范市场竞争、帮助企业进行内部软件过程改进、降低软件开发风险、增加软件企业的市场竞争力。
我国政府一直重视软件产业的规范和发展，强调提高我国软件开发和软件产品质量的重要性。国务院于2000年6月颁发的“18号文件” 《鼓励软件产业和集成电路产业发展的若干政策》第五章第十七条明确提出鼓励软件出口型企业通过ISO 9000系列质量保证体系认证和CMM认证，其认证费用通过中央外贸发展基金适当予以支持。目前各省市、高新区、软件园都有对通过软件能力成熟度评估的企业给予资金奖励的制度。随着SPCA中国国家认可制度的建立和实施，对于通过SJ/T 11234和SJ/T 11235评估的企业将可得到更多得政策支持。
随着我国经济市场的日益成熟，与信息产业部建立的计算机信息系统集成资质认证体制一样，SPCA评估及其评估结果在市场化运作中将会起到越来越重要的作用。广大用户和企业也越来越接受和认可SJ/T11234和SJ/T11235标准，并将作为企业招投标，选择合作伙伴的一项指标，也是进行第二方评估或评价的依据。这对我国软件企业和产业的提高、发展和壮大也将产生积极的影响。
3 SPCA的实施与评估
企业实施SJ/T11234或SJ/T11235并进行评估，一般需进行如下7个阶段：标准培训、组织职能建立和文件体系完善、文件评审、差距分析、持续支持、中期评估、最终评估。其中各阶段的目的如下：
标准培训：旨在建立公司人员的软件过程改进意识，了解过程改进原理，以利SJ/T11234或SJ/T11235实施。
组织职能建立和文件体系完善：建立实施SJ/T11234或SJ/T11235的职能机构，明确职责；识别公司现存软件过程和文件，完善软件过程定义并建立完整的文件体系。
文件评审：评审文件体系的适用性，识别文件的改进之处。
差距分析：进行现状分析，识别与SJ/T11234或SJ/T11235的每个过程方面的差距，并制定一个行动计划来覆盖识别出的差距。
持续支持：实施持续支持以实施过程改进，并覆盖差距分析阶段识别出的差距。
准备性检查：对软件过程改进实施情况进行评估，为最终评估做准备。
最终评估：使用《软件过程及能力成熟度评估指南》的方法进行最终评估并定级。评估包括三个阶段：准备阶段、现场阶段和报告阶段。
4 SPCA与CMM/CMMI的区别
★CMMI认证★CCRC认证★ITSS认证★CS认证★DCMM认证★DSMM认证★两化融合认证★重庆CMMI认证★重庆CCRC认证★重庆ISO27001认证★重庆ITSS认证★重庆CS认证★重庆GJB5000A认证★重庆两化融合认证★ |
