有人认为，如果一个软件机构在五个开发人员以下，以及开发周期短于六个月，进行基于SW-CMM的软件过程改进是不划算的。写这篇文章的一个目的，就是帮助人力财力不那么雄厚的中小型企业进行软件过程改进，让他们能少花钱，少花时间，并且显著得益。无论人数多少，开发周期多短，改进必得益！

笔者在“SW-CMM与中国”一文中己提出了对在中国软件产业中应用CMM的一些建议。

只要一个软件企业在开发产品，它就一定有一个软件过程（可能只是没有写下来）。如果这个过程不能很好地适应开发工作的要求，就需要进行软件过程改进。

软件过程改进并不是一件很困难的事。并没有写一个操作系统，或设计一个微处理器那样的纯技术上的难度。但它面对的是一种含有大量管理成分的工程技术。这也就是为什么不容易把它做好的原因。

什么是“改进”？改进所涉及的几个步骤是：

1.把要想达到的状态与目前的状态作比较，找出所有差距；

2.决定要改变哪一些（注意，不一定是全部）差距，要改变到什么程度（可分阶段改）；

3.制定具体的行动计划；

4.执行计划，同时在执行过程中对行动计划按情况进行调整（以最佳效果为目标）；

5.总结这一轮改进的经验，开始下一轮改进。 下面讨论，在进行软件过程改进时，上述五个步骤中的关键内容。

“要想达到的状态”（目标状态）：具体是指软件过程的状态。如果一个机构决定采用SW-CMM来作参考篮本的话，就可以基于它的各个关键过程域（KPA ），制定出符合自己机构及产品特点的目标状态。（在这里，笔者强调“基于”及“符合自己特点”，意思就是不能照抄。）

“目前的状态”：要找出什么是目前的状态，就要进行对目前软件过程的评估。评估的方法很多，最简单的就是一组熟悉本机构的日常开发运作的人员在一起讨论，把它列出来。在这里，可借助SW-CMM的评估问卷办法。实质上，评估问卷中的问题，就是把各关键过程域的各细则内容，加上“有没有做到”、“有没有建立”、“有没有执行”等语句而构成的，并没有什么神秘之处。

“决定要改变哪一些差距”：要从多个方面进行考虑决定。例如：“最薄弱的环节”、“最需要改进的环节”，“最易做到而又有显著收效的改进”，“有人力，财力和时间，即有条件进行”。各机构要按自己的情况作决定。

“要改变到什么程度”：由于条件的限制，我们不可能做一切希望要做的事，或者不可能百分之百地一步实现目标。许多时候，欲速则不达，反而误了事。目标与能力，要有个平衡。

“具体的行动计划”：“具体的”就是：

a. 要有明确的，可以检验的目标；

b. 要定出检验成功与否的标准；

c. 要有具体的实施行动办法；

d. 要指定具体执行计划的人，每人的具体责任与任务；

e. 要指明计划的主要领导或协调者，以负责解决一切在执行中出现的问题；

f. 要列出所采用的新技术与新工具，怎样获得它们；

g. 要定出对新技术和新工具进行对本机构适用性改造的目标；

h. 要有对新技术和新工具的使用进行培训的计划；

i. 要列出每一改进对过程的其他部分的关系、影响、和协调的办法；

j. 要建立与项目相关联的时间表；

k. 要指出相关的人力、资金与时间的来源；

l. 要定出在整个执行过程中，必须在什么时候提供什么数据；

m. 要有对执行情况进行监察考核的具体办法及计划；

n. 要准备很可能发生的，在执行过程中对行动计划按情况进行调整的行动。

o. 要有对行动计划执行中可能出现的意外情况有所准备，保证项目仍然能够顺利进行。

p. 必须要有高层领导、管理人员作为推动整个行动计划的动力。

“在执行过程中对行动计划按情况进行调整”：一旦发现需要对行动计划进行调整，以期达到最佳的效果，而实际情况也允许在中途进行调整的话，可以进行经过计划的、严加控制的调整。所有的改变必须预先取得所有有关人员的同意。

“总结这一轮改进的经验”：过程改进是一个永不停止的工作。总结经验使我们能越做越好，越做越有信心。光有未经实践的知识，还不能有信心。信心是经过运用知识解决了问题之后建立起来的。

SEI 建议的做法：

运用SW-CMM进行软件过程改进，按照SEI 的建议是使用他们制定的IDEAL 模式的做法。

IDEAL 是个组合字，实际代表：

I Initiating（创始）为成功地进行过程改进而打好基础。

D Diagnosing（诊断）找出相对于你要达到的位置，你现在在何处。

E Establishing（建立）计划你如何达到你的目的地。

A Acting（行动）按计划进行工作。

L Learning （学习）从经验中学习和改进你在将来采用新技术的能力。

读者可详细学习SEI 的出版物：（编号 SEI-96-HB-001，共263 页，可从SEI 网页上找到） “软件过程改进用户指南”（IDEAL：A User`s Guide for Software Process Improvement ）

笔者认为，正规地使用IDEAL 模式，可能比较适合于大型企业。

下面，就一些问题提出笔者的看法：

是否一定需要外来的咨询？

企业进行软件过程改进，是否一定需要外来的咨询呢？笔者认为，好的咨询确实能带来帮助，如果财力上付得起，同时又了解对方是有商业道德和有能力的顾问，则不妨进行一点初步的接触，然后逐步判断他的观点和建议是否符合你们机构的需要，千万不要被对方说服去投入一个你们的机构现在不需要的，或在人力、财力、时间上条件不具备的努力。（咨询服务也是一种商品。不道德的商人会向你推销你并不需要的商品。）你们要进一步判断，究竟在哪一些方面，在多大的程度上需要多少外来的帮助，因为过程改进的一个目的是培养本机构的人才，过份地依赖外来咨询，会削弱这个努力。

俗语说得好“三个臭皮匠，顶个诸葛亮”。在机构内部组织一个小组，多讨论，通过各种渠道多学习别人的经验，破除教条迷信，灵活运用自己的专业判断力，就有能力领导整个过程改进，并且在实践中成长起来。（至于运用专业判断力，实际上更多时候是运用常识。一种讲法，无论来自什么权威，如果你觉得不合常理的话，就要弄清究竟。）

知道了要做什么，如何知道怎样做？

SW-CMM只提出了要做些什么（关键过程域中的关键实践），但并没有介绍要怎样做。解决这个问题的方法很多，比如到软件工程的书中去找、向有经验的人请教、或者就自己讨论出一个可行的办法，从来都不要小看自己经过认真思考而想出来的办法。凡是从书中或别人处学得的办法，都要经过适当的改变，以适应自己的机构的条件及目前项目的特点。世界上没有适合一切人穿的鞋。
怎样知道过程改进带来了什么效果呢？

一般来说，你知道了目前的缺点是什么，就应当知道怎样去判断过程改进的效果。当然，效果可以分别从质和量的角度去量度。对于不同的改进，效果的检验方法就不同，比如对于项目的计划中的软件规模大小的估算，就可以从最终产品的大小中得知估算的准确度；比如进行早期缺陷预防，就可以看看在开发的各个阶段所发现的缺陷数目的分布（记得在行动计划中要有记录统计的一项）；又比如进行软件配置的版本控制改进，就可以看看是否对不同的版本有了完全及方便的控制。因此，可以看出，这些都是按常理进行的事。 找差距时，应对照哪些关键过程域？

SW-CMM的能力成熟度分等级，是人为的。它是基于SEI 对成熟度的由底到高的理解来划分的。有人就觉得划分得不大合理，然而，使用者是活着的人，可以按自己需要作改变。 笔者认为，对于初开始软件过程改进的机构，不妨对照全部或部分的SW-CMM第二级的各个关键过程域，外加第三级的“交换审核”，及第五级的“缺陷预防”。（有点象从菜单上点菜）

为什么要把“交换审核”及“缺陷预防”从高的成熟度等级中“往下拉”呢？原因是，按笔者的实际经验，“交换审核”是一个简单易行而且非常有效的找出缺陷的方法，也是一种促进开发人员注重预防缺陷的好方法。至于“缺陷预防”，这是整个软件过程的核心与灵魂，从一开始就必须全力以赴。

在每个对照的关键过程域中，原原本本地对照每一项关键实践吗？ 绝对不是。这里就牵涉到对SW-CMM进行裁剪及解释的间题。“裁剪”是指对范围及程度的改变；“解释”是指把实际软件项目中的实践工作，解释理解为（等同为）某个关键实践。基本上，不要去裁剪那些属于目标（Goals ）的关键实践。裁剪及解释，是中小企业能否成功地应用SW-CMM的一个关键。在不影响效果的前提下，剪裁到越简单越好。要慢慢地把自己培养成裁剪高手。

（SEI 有专门讨论裁剪（Tailoring ）的技术报告，文件编号是94-TR-024 。）

把机构目前的一切推倒，按SW-CMM重建，是否会更好？

千万不要这样做。基于目前的过程进行改进，证明是最有成效的方法。

是否起码要满足SW-CMM第二级的所有关键过程域呢？

笔者认为不必。任何方面，任何程度的改进都是有益的。要按照你机构的担负能力及要求来决定进行软件过程改进的广度与深度。

软件过程改进中，应注意些什么呢？

应该注意的事情很多，但笔者认为最重要的一点是要注重执行、做实事，千万不要定出了行动计划之后就丢进抽屉中，束之高阁。另外一个要注意的问题是，要有对行动计划执行中可能出现的意外情况有所准备，保证项目仍然能够顺利进行。