在国内有着成千上万的中小型软件企业，虽然每一个软件企业所涉及的行业不同、软件的开发能力不同。但是它们都有着共同的特点，也是国内众多中小型软件企业所面临的困惑。我们先来看看下面两个软件企业所面临的不同困惑：

有这样的一个软件企业，每次当市场人员费劲周折的从客户方获得软件订单之后，公司领导也比较重视马上就组织软件人员与客户接触去获取需求。于是软件人员便热情高涨的跑到客户那里做需求调查，在“获取了客户需求”之后。项目经理会马上将整个软件项目切分为若干模块，随之将这些切分好的软件模块分配给项目组内的开发人员。并且根据合同所规定的交付日期，大体上划分了每一个模块完成的时间；告诉开发人员在某一个时间点必须将分到手中的模块完成。可是在项目执行到后期的时候，所产生的问题越来越多。客户要不就是对所开发出的程序不满意，要不就是不停的要求开发方修改软件功能。眼看马上就要到项目的交付日期了，可是看看自己所开发出的软件还有许许多多的让客户不确定。于是项目经理和公司老板都急了，老板则拼命的去做客户关系而项目经理则与项目组成员每天都加班改程序。在经过全公司全体员工齐心合力的努力下总算是在项目延期不久的时候把软件交付给了客户，这时全公司的人也松了一口气。但是好景不常用户在使用软件不长的时间里，发现了许多的软件Bug开发方的人员被用户隔三差五的叫到客户那里去修改程序。面对了许久“救火式”开发和维护的开发人员被弄得筋疲力尽，而公司领导则怕见到客户方的领导怕被客户说自己开发出的软件错误百出；不时的也在感叹软件的利润越来越少。

这是一个很典型的例子，多数小型的软件企业都或多或少的存在着以上的问题，这些问题的原因究竟是这些软件企业的开发人员技不如人还是他们所遇到的客户群很挑剔？其实每一家软件企业的开发人员的技术都不是导致发生以上问题的原因，同样也不能说他们偏偏遇到了挑剔。或许还有人会说以上所表现出来的问题，有很大一部分原因是因为我们所遇到客户群太不成熟所带来的。其实我觉得这些说法都是在找借口推脱软件企业自己的责任，如果一个软件企业有很强的“内功”他就不会怕客户群的不成熟，因为他能做到去引导客户完成客户想要而又说不清楚的东西。同样也可以避免项目开发进度的延误、软件质量底下的问题。为了达到强“内功”的目标，许多软件企业开始寻找修炼自己“内功”的“武林秘笈”。就在这时远渡重洋的软件管理圣经――CMM登陆中国大陆了，许多软件企业开始手捧“武林秘笈”开始进行自己“内功”的修炼。但最终修炼之后给企业带来的是什么呢？我们来看下一个典型的例子。

有这样的一个企业在经过了一段时间混沌、无序开发之后，下定决心不断的练“内功”摆脱混沌、无序开发给自身带来的痛苦。于是全公司从上到下开始学习CMM知识，并且按照CMM Level2的框架为企业建立了相应的过程规范。就在一开始的时候从程序员、项目经理到公司高层都干的热火朝天，觉得自己总算是摆脱了以往无序的开发状况。可是在按照所制定的过程执行了一段时间之后，在企业内部已经完全没有了当初才建立过程规范时的那份激情。所表现出来的是开发人员每天都在想我还差什么文档没有完成，项目经理则更加困惑心里在想我们不是完全按照CMM所要求的规范去执行了吗？为什么我们原来所遇到的问题到现在还是依然存在，项目进度仍然被延误。而公司的质量保证人员更是郁闷，感到每次做过程检查基本上都没有发现多少问题，为什么客户的需求变更还是那么多所编写的软件质量还是不高。难到是自己的失职还是我们所建立的过程有问题？

这就是一个完完全全按照CMM过程规范去修炼自己“内功”的软件企业所面临的困惑，这究竟是软件企业自身在制定和执行CMM规范过程当中出了问题还是CMM本身只是一个美丽的神话。

其实是我们的软件企业在没有完全认清自身的问题的情况下，就完完全全的依赖于CMM标准；希望它能是一副“灵丹妙药”在服用之后马上就能让企业的能力提高到CMM标准所描述的那样。我们应该清楚的认识到CMM理论只不过是一个直到软件企业进行持续软件过程能力改进的框架，而不是软件企业的“救世主”它并不能教会我们该怎样去做好软件需求和编写高质量的代码。我们只有根据企业自身的特点，分析自身所存在的问题。以CMM理论框架为指导去进行符合自己实际情况的过程改进，这才是大多数中小型软件企业的唯一出路。

根据自身情况进行过程改进

在经过上述两个阶段之后公司领导认识到，如果我们完全按照远渡重洋而来的CMM规范去执行迟早将自己陷入泥塘。在现在的能力状况之下我们没办法完全去按照CMM标准去执行，于是2004年3月公司邀请了国内知名的软件工程专家――林锐博士到公司。根据公司所涉及业务的特征和实际执行能力进行软件过程改进工作，为此由公司人力资源部经理陈治伦牵头林博士为主组建了编写小组。负责对公司现有软件过程能力的调查、分析整理，并且根据公司自身的特征和CMM 3的框架理论制定了公司现执行的CMM 2.5软件过程规范。

在这次的过程改进当中，得到了上至申总下至每一为工程师的大力支持。在历时近两个月的工作当中，针对每一个软件部的业务特征和客户群体的不同；分别对每一个软件部的业务特征、客户特征及现行过程的执行情况进行了详细的访谈和分析。针对在以往软件开发过程中所发现的所开发出的软件产品与客户的原始需求的部分脱节问题，经过分析总结之后建立了“客户互动”过程域。通过“客户互动”过程域拉近了客户与开发人员的距离，使得从项目合同签订到项目的完成整个过程当中；客户都能充分的参与到项目的开发、实施过程中从此可以做到了尽可能的减少客户需求和软件产品的差异。

通过对原有过程规范的分析和整理，并且根据公司的实际情况建立了CMM2.5过程模型和相应的过程文档。并经过多次的评审修改后得到了以下的过程模型。

优耐达过程模型：

在整个过程改进当中林博士根据自己多年来对软件工程的认识和相关的理论，并结合公司CMM 2.5过程规范为公司员工进行了多达15场近60小时的培训。使得公司员工在软件工程与过程方面得到了许多有益的收获和提高。

通过这次的软件过程改进活动，使得我清醒的认识到了要想把一个企业的软件过程改进工作做好。不是完全去套用所谓的“软件工程圣经的CMM理论”就能让一个软件企业能够走上规范化的道路的，只有根据本企业的自身条件和能力结合诸如：CMM、TSP、RUP等的理论框架；进行行之有效的过程改进和推广才是软件企业走规范化道路的唯一出路。