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

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

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

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

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

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

　　在每个对照的关键过程域中，原原本本地对照每一项关键实践吗？

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

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

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

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

　　是否起码要满足SW-CMM第二级的所有关键过程域呢？ 　　笔者认为不必。任何方面，任何程度的改进都是有益的。要按照你机构的担负能力及要求来决定进行软件过程改进的广度与深度。

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

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