过程改进（Software Process improvement，SPI）帮助软件企业对其软件（制作）过程的改变（进）进行计划、（措施）制定以及实施。 他的实施对象就是软件企业的软件过程，也就是软件产品的生产过程，当然也包括软件维护之类的维护过程，而对于其他的过程并不关注。

对于软件企业来说，软件过程是整个企业最复杂、最重要的业务流程，软件产品就是软件企业的生命，改进整个企业的业务流程，最重要的还是要改进它的软件过程。多年以来，人们认识到要想高效率、高质量和低成本地开发软件，必须以改善软件生产过程为中心，全面开展软件工程和质量管理手段。这是世界各国软件产业都要走的路，我国软件产业之所以落后，不是因为技术落后，而软件过程改进是对软件生产的管理落后。CMM就是结合了质量管理和软件工程的双重经验而制定的一套针对软件生产过程的规范。由此可见，对软件生产过程的管理在整个软件企业的管理中起了决定性作用。因此，从这种意义上讲，软件企业的BPR和CMM软件过程改进在实施对象是一致的。

在世界范围内，软件项目需求正以非常快的速度增长，并且这种增长看起来还远未达到目的。这种增长已经导致软件开发活动急剧性的增长，已使得对用于构筑软件的过程，正确的说法是软件过程，得到更多的关注。软件过程可以定义为人们用来开发和维护软件以及相关产品（如：工程计划、设计文档、规章、检测事例及用户手册）的一组活动、方法、实践及转换。软件过程重要性的提高已经引起了对软件过程改进的要求，这就需要过程分析和评估的方法。

CMM在软件改进措施的策划上，措施计划的实施上和过程定义的都有着特使的价值。在策划改进措施期间，具有有关其软件过程问题和经营环境的知识的软件工程组的成员可将CMM重关键过程域的目目标和当前的实践相比较。应该开查与恭喜目标，管理优先级，实践运行的层次，实施每次实践对组织的价值，以及改组织在其文化背景下一个实践的能力等方面有关的关键实践。接下来，软件工程过程组必须确定那些需要作过程改进，如何实现更改，以及如何获得所需要的买进。CMM通过给有关过程改进的讨论的出发点，并且帮助揭示与通用软件工程实践所采用的那些完全不同的假定，从而对这些活动提供帮助。在实施行动计划计划时，过程组可以用CMM 和关键实践来构造部门可操作的行动计划和定义软件过程。

SPI的五条核心原则分别是：

1·注重问题 2·强调知识创新3 ·鼓励参与 4·领导层的统一 5·计划不断地改进。

“问题的解决是过程改进的核心，实践不仅是SPI组的目标也是它的起点。”这条原则为过程改进人员指明了目标，明确了方法。SPI就是要在实践中发现软件过程中的问题，并在实践中寻找和找到解决问题的办法，可以说过程改进就是在不断发现问题和解决问题的过程中不断向前发展。

“改进是一种知识的创新，SPI是受知识的驱动的”。这条原则强调了知识创新在SPI中的作用，提醒了SPI人员在注重知识创新的同时更要注重知识的传播和扩散。

通常从事SPI工作的做法是，过程改进仅仅是过程改进人员的事情，其他人员只是被动地接受。而“合作促使改进产生”这条原则给予了我们很好的启发和提示。它告诉我们，过程改进不仅仅是一个人或几个人的事情，而是整个组织的事情。只有鼓励大家都积极参与，让这些人基于自身的经验和职业的判断力来实实在在地设计和开发新的过程，才能使设计出来的过程真正为他们所理解，为他们所用，从而实现过程的成功。这也是我们在过程改进工作中容易疏忽的地方。

“SPI的关键点在于改变软件开发的方式。然而，改变人的行为并不是件容易的事。”这条原则分析了我们在这项工作中可能会遇到的困难和阻力，本书中也不忘为我们提供了如何克服这些问题的可行方法、建议和实例。

“改进必须是综合了各个层次的人的力量。”SPI人员一定要保证SPI的目标与组织的整体目标是一致的，因为只有这样才能保证SPI工作得到各个领导层的赞同、支持和投入，才能综合利用各个层次的力量来推动SPI工作的前进。这是预防过程改进项目风险的重要手段。

“改进应该是一个不断持续的过程。”这一原则进一步提示和告诫SPI人员一定要认识到改进的不断持续的特性。到达顶点并不重要，关键的是，你现在处在一个上升??达一个目标你就创造了另一个更高的目标，这个目标对我们的过程和环境都具有重要的意义。

这五条原则是从实践中发展而来、相互关联的SPI哲学，对我们SPI工作具有非常重要的指导作用。

策略一：两个方针

重诊断，轻评估 以诊断和解决企业实际问题为SPI方法论，不追求商业评估。以往实施ISO9000的过程中发现，企业拿证书的愿望常常会冲淡“真正改进”的目的。所以，除非不得已，建议一开始不要把商业评估作为目标，以便将焦点集中在“改进”上。的确，一旦进行商业评估，难保不急功近利，限期取证。SPI如同“治病”，多长时间治好怎么可以人为规定呢？

重诊断，正是前述自底向上方法论的具体贯彻。根据企业的不同状态和症状，实施有针对性的方案，将有望设计出实用性更强、效率更高的应用模型。

重实施，轻宣传 我们不妨来看一组数据，这是北京SPIN去年发起的一次调查，提问是“您认为软件企业中开发不规范，不能突破管理瓶颈的原因是什么？”

可见，以往我们多年来实施ISO9000这样的体系，但效果差得可怜（客户满意度12%）。

据报道，中国通过ISO9000的企业超过了日本和韩国，但是中国并没有因此成为质量强国！

ISO9000在软件企业的现状，并不能仅仅归结于ISO9000不适合软件企业这一点上，更大的问题在于，人们对体系的“可实施性”研究和重视得不太够。

所以我们提出以高的“过程实施率”（定义的文档被很好的遵守）和“过程性能改善”为SPI目标，不追求宣传效应。

策略二：两手抓

实施制度化的同时，并行实施企业文化；既要施压，又要清障。

中小企业往往制度化体系很不健全，存在着随意决策的管理习惯，甚至基本的企业纪律都不具备，企业还处于“人治”和“法制”的争论中，这样的状态和某些大企业实施SPI的状况是不同的，需要特别强调行政施压。由于缺乏统一的企业文化，所以理念的统一也要加以重视。

CMM的实质是制度化体系，实施CMM也是实施全面制度化的有效途径。但是制度和组织文化总是辨证存在的，没有良好的文化保障，制度化将困难重重，而没有制度的支撑，文化也将是无源之水。企业文化的实施从改造企业价值观开始，价值观是企业文化的核心，一个企业中如果好的行为不能得到鼓励，坏的行为不能得到惩罚，那怎么能倡导出有利于制度生存的价值观呢？

两手抓还包括另外一个层次的含义，过程改进要加强推进和减少阻力并重。这针对两种现实中的错误认识：一种认为，员工都是自觉的，只要把道理讲清楚了，制度就能得到实施。这种假定是不现实的，如同法律，如果假设人们都是遵纪守法的，那么法律本身就没必要存在了。实际情况是，人们在组织中总是有区分的，有的人主动顺应变革，有的人推一推也能动，有的人可能推十下也不动，从而成为变革的障碍。所以变革的落实需要一个强的“推力”。另外一个观点刚好相反，认为没必要对员工讲为什么，只要告诉怎样做就行了。这又走到另外一个极端，体系在强力的推动下可能会暂时得到执行，但是由于并没有解决观念转变的问题，一定难以持久。

策略三：推行工具

要推行配置管理工具和项目管理工具这两种工具，工具将有效分解事务性工作，从而缓解人力资源投入不足的矛盾。

配置管理工具根据不同的平台推荐使用VSS和CVS，项目管理工具使用微软公司的MSP。使用工具，可有效分解管理工作量，提升工作效率；有助于管理制度的真正落实，使体系更加固定化。

策略四：补基础课

为了解决基础薄弱的问题，需要在SPI前期为企业补基础管理和基本软件工程两门课。

CMM的设计是以美国的软件企业为研究对象，它假定企业在实施CMM前，已经具备了基本软件工程和基本管理的能力，所以有“先管理、后工程”的观点。就是先把项目管理到位，再实施软件工程（即软件工程到位）。

但是这个假定对于绝大部分的中国软件企业是不成立的。

软件企业需要补的基础管理内容包括：基本时间管理、角色转变、目标管理、沟通管理、基本人力资源管理等。基本软件工程则包括基本的软件工程生命周期、阶段划分、基本文档编制等。

策略五：三方参与

按照ISO9000的说法叫全员参与，分成三个层面就是：

一是高于项目管理的层面，称为高层经理。他们提供资源和战略两方面的支持，所以高层经理应该对体系总体架构、体系实施必要性、可行性、障碍和风险、资源等负有责任。

二是项目管理层面，含项目经理和SPI人员。SPI人员作为制度化体系的执行者和推行者应该加强自身修养，要求别人的事，一定要自己能做到。而项目经理作为主要的一线实施人员，需要对整个体系的细节有深入了解和研究，应该把日常工作时间的30%～50%放在工程化管理相关事宜上，要贯彻公司的SPI整体制度，积极主动在项目组内进行推行。

三是项目组成员，包括开发和测试人员，要求团队以纪律性要求自己，做好局部和整体、短期和长期的矛盾平衡。

特别要关注试点项目的PM（项目经理）选择，选择好的PM意味着SPI一半的成功。

需要说明的是，自底向上并不是绝对不做正式评估，如果需要，等到水到渠成再实施评估，不仅使得过程改进更实在，而且只需投入少量的资金就可获得评估。

介绍

如果我们把软件过程改进看作一个项目，象其他项目一样，它也要有一个好的计划，这个计划不但要满足公司的商业目标，还要包含过程改进战略和具体的实施步骤（子项目）。软件过程改进非一日之功，急于求成必将导致失败；因此，如果不进行系统的战略策划而盲目进行过程改进，只会浪费时间和资金而不会取得好的效果。有了有效的战略计划，我们才能在这项长期的活动中获得管理人员、开发人员和公司的所有者的理解和耐心的支持。

那么如何进行战略策划呢？本文介绍的两位主任评审员开发的过程改进战略策划的方法，已经在很多软件企业成功实施。其中应用的主要技术包括：战略决策、优先级排序、过程改进与过程评审。

通常，战略策划由一个小组负责，小组里要包括参与了过程评审的人员以及其他策划工作的受益人，另外高层经理的参与是非常重要的；策划的方式是在负责人的指导下以讨论方式进行。实践证明，以下步骤非常有效：针对不同的改进点分别制定改进方案

方案评价

将改进方案排序

估计并制定实施的进度表

获得管理层的承诺

具体介绍如下：

1 制定过程改进方案

评审结束后，策划组要对评审结果进行分析，筛选出十个左右的改进点；然后将每个改进点都作为一个改进项目，分别制定两到三页的改进方案。方案主要包括以下内容：

1.现状的简单介绍

2.改进方案介绍

3.预期收益

4.实施负责人

5.对成本、资源和项目周期的估计

方案中还应该说明建议使用的实施方法，例如是否进行试用等。估计成本时要包括：过程定义的时间、试用期间人员培训的成本、处理反馈意见的时间和重新试用的成本。

因为所有的改进工作不可能一次实施，所以接下来我们要确定各个改进项目的优先级，具体步骤如下：

2 评价各个改进方案

我们怎么确定改进活动的优先级呢？主要是通过考察三方面的因素，即：对商业目标的影响、风险和在CMM中的定位。

有些公司还会对各方案进行成本/收益分析（例如，考察投资回报率），但是1级或2级的企业往往没有充分的历史数据，因此无法准确估计过程改进的无形收益；4级和5级的企业通常就能作到这一点，3级的企业也有可能作到。

2.1 对商业目标的影响

对商业目标的影响是指某项改进工作对总体的战略目标的影响。

首先，策划小组要和主管的高层经理进行讨论，明确公司商业目标、并分析确定决定商业目标能否实现的5-7个关键成功因素（CSFs）。如果公司没有明确成文的商业目标，小组的首要工作就是确定商业目标；如果商业目标已经非常清楚、明确，并且形成了文档，策划小组的核心工作就是分析关键成功因素并每个关键成功因素确定权重。

接下来，我们要对每项改进活动进行分析，按其对每个关键成功因素的贡献进行评分，然后将结果进行加权平均，作为最后比较的一个依据。

2.2 风险因素

风险是指实施改进工作的困难程度，我们要考虑实施某项改进是象赌博一样冒险么？结果是不是有一定的可预测性呢？通常，风险的来源主要有三个方面：项目的规模、结构的问题和技术。

项目规模风险，是指实施的人工成本，一般人工成本越低风险越小。

结构方面的风险，主要有以下因素

参与该项目开发的功能组的数量

项目的复杂程度

制定解决方案的人员在该过程域的经验是否丰富

对改进中带来变更，预期存在抵触行为

技术风险，主要包括以下方面：

需要改进的软件工程过程的成熟程度

能否获得充分的新技术方法的培训

工具和其他支持条件的成熟程度

2.3 CMM中的定位：

是指某一改进活动对达到更高能力成熟度等级的贡献。权重是按照KPA所属的能力成熟度等级来确定，比较简单。我们可以初步确定：目前所处等级的下一个能力成熟度等级的KPA权重最大且相等，其后按顺序递减。各改进点的分值按其对个KPA的影响确定，有些改进点可能影响多个KPA；另外需要注意，各个改进点对某一个KPA的影响总值不能超过100%。

接下来，我们还可以根据评审结果将下一个成熟度等级的KPA进行划分，看看哪些更重要。评审中，大家达成共识认为对组织影响最大的问题所对应的KPA应该获得较高的权重。

3 对改进方案进行排序

进行了以上分析之后，我们按照分值对各个改进方案进行排序，总分的计算方法如下：

总分=（权重1）（对商业目标的影响）+（权重2）（风险）

+ （权重3）（在CMM中的定位）

公式中的得分是按上面介绍的步骤进行处理得出的，权重主要是根据策划小组成员的共识确定的，有些公司认为三方面的因素同样重要因此赋予相同权重，也有些公司认为对商业目标的影响的重要性是在CMM中定位的的三倍，而风险因素是在CMM中定位的两倍。

这样，我们就基本建立了各个改进项目的优先级，分数最高的优先级最高。

4 估计实施的进度表

排序完成后，我们就要考虑各个改进点的依赖关系，根据优先级顺序和依赖关系进行总体战略策划，并制定进度表。有趣的是，优先极较低的改进项目往往是优先级较高的项目的先决条件，因此在进度表中就应该靠前。另外，我们还要考虑实施效果的影响和可视性。例如，对于1级的企业，管理层还没有建立起过程改进的威信，过去给人的印象总是言行不一，那么就要选择风险较低，大家都能看到且有不凡收益的改进项目，帮大家建立信心，即使这些项目优先级较低。

5 获得管理层的承诺

下一步，我们要完成正式的计划、提交管理层获得认同和承诺。我们在上面说过，高层管理人员的参与确定关键成功因素是非常必要的，这里，我们要再次强调管理层的重要作用，因为他们要负责批准战略计划、授权启动改进项目并且不断重申对于过程改进的承诺。

过程改进的总体计划通常包括：介绍（说明计划的目标）、制定计划时所使用的方法、对评审结果和推荐措施的总结，主要内容是各个改进项目的方案和策划活动的结果。当然也应该包括：进度表、相关任务、负责人、项目运行指标以及所需的资源，如：人员、资金、软件、硬件工具等。

管理人员评审和签字批准，意味着管理层对改进活动人员和资源上的支持和承诺。

总结

通过以上的介绍，希望大家对过程改进的战略策划有了一定的了解。我们需要强调的是：成功的过程改进策划是建立在以下的基本原则之上的：

过程改进与商业目标相结合

合适人员的参与

有效的策划方法

积极沟通、思路共享

保持整体观念

我们的很多客户通过实施以上的方法，在评审结束后迅速、有效地实施了过程改进，他们对自己的决策满怀信心、不断向着更高的能力成熟度迈进。

1 改进用户需求过程

1.1 改进用户需求的获取方式

1） 研究用户特点

2） 成立需求调查小组

1.2 改进获取用户需求的态度

1） 正式的外部文档方式

2） 正式的提交过程

1.3 改进用户需求内容准备工作

1） 专业的用户需求调查表单，力求取得用户的配合，由用户或需求调?

1） 用户需求的分析、总结，须及时反馈到用户方，以取得及时而有效、满意但不多余的需求

2 改进需求分析方式

1） 改进需求分析的前提条件——正确的获取用户的需求

2） 针对不同类型的系统采用不同的需求方式和模型，更有助于界定需求的范畴

3） 及时总结、改进需求分析方式和模型，形成需求分析模式库

4） 复用和改进需求分析模式库

5） 加载有效的、适用的、先进的需求分析理论于经验分析基础之上

6） 改进项目组内需求分析的沟通和流通

7） 在需求分析初始，尽早分析需求的可行性，并作备案

8） 对不适当需求，与用户沟通，以取得理解和信任

9） 对不合理需求，协调用户，以降低成本

10） 需求一旦获得认定，尽快进行系统分析和设计

11） 及时有效的控制需求的变化，防止对需求随意的更改和增删

3 改进系统分析和设计原则

1） 以最小的代价实现系统

2） 以开发人员最熟悉的方法、技术和工具实现系统

3） 尽量采用先进的方法和理论，以适应发展的需求

4） 在系统的相关处，与具体的实施人员进行及时有效的沟通，寻求实现的最佳途径

5） 以简单、易懂的方式进行分析和设计

6） 以简单、易懂的方式表现系统

7） 系统分析的方式要易于复用，并及时进行调整、改进，系统系统分析库

8） 对系统的分析、设计加以控制、遵守，防止系统结构的随意更改

4 改进系统的实施和验证

1） 确保在取得共同的理解后才进行系统的实施和验证

2） 系统的实施和验证遵循一定的流程，以约定的方式进行沟通

3） 系统的变化能够以多种不同方式进行沟通，以确保变化被告知、并被认可

4） 确保在系统的实施和验证过程中，所采用的方式和方法是易于理解的，且不易发生变化

5） 系统的实施和验证完成标识明显，易于被相关人员识别

5 改进用户验收被动局面

1） 理解和支持用户的行为

2） 取得用户的理解和支持

3） 对系统进行充分的验证

4） 提高系统安装的成功率和速度

5） 改进系统界面，使系统直观、有效

6） 保证进度，提高诚信度

6 改进系统维护过程

1） 对用户进行有效的培训

2） 快捷、有效、合理的处理用户的问题

3） 跟踪问题，形成问题库

SPI的最根本利益其实在于，他能够极大的提高项目成功的几率，这是大家都追求的。当然需要明确定义这里的“项目成功”的含义，不是客户要求三个月完工，最后按时交工，就是成功。而是综合平衡进度、交付后质量、成本等若干要素后所达到的最优状态。 ；在项目管理三要素中，项目干系人通常会把进度当作第一目标，结果相当多赶进度完成的项目，在交付后面临者大量的后续修改，甚至推翻重来。如果把这部分开销算到项目中去，项目早已失败的一塌糊涂了。

对大量失败项目的统计结果表明，最大的原因在于缺乏过程或者没有很好的遵循已定义的过程。我们知道决定项目质量和生产率的要素有人、技术和过程，如果借用木筒的比喻，过程不见得是其中最宽的一条，但是当前它是最短的，所以它决定着木桶的盛水量。我们迫切的需要SPI，就是要把最短的木条尽快补上去。

只有基于良好的过程，人和技术才能发挥出最大的威力。

以项目形式管理软件过程改进，特别有利于提高团队凝聚力、规避风险、明确目标、提高效率，而且由于SPI项目组与其他项目组形成了一种矩阵式组织结构，可以有效促进组间交流。所以对于SPI这样一件比较复杂的工程来说，以项目形式进行管理将是成功的重要保证。　国外的一项有关SPI（Software ProcessImprovement软件过程改进）的调查表明，没有很好地对过程改进进行管理造成了至少70%以上的软件企业改进失败或挫折！当我们问自己如下问题的时候，能否迅速给出满意的答案——

SPI强调管理，自身是如何管理的？

SPI提供方法论，自己的方法论如何？

SPI强调做事要有计划性，自身计划性如何？

SPI倡导风险管理，自身的风险被很好识别了吗？

本文试图给出一种对SPI自身进行管理的方法——“以项目形式管理SPI”。

以项目形式管理SPI通常分为如下五步骤：体系诊断，方案设计，项目策划，过程管理，项目验收总结。

诊断是一切过程改进和管理咨询的前奏，对于不以取证为目的的软件过程改进来说，这一步尤其重要。　“过程诊断”和“过程审计”有着某种程度的相似性，通常的方式为面谈、文档查阅、检查表填写等形式。

典型的SPI诊断花费大约为2～3人/日，这和组织的成熟度、组织的历史长短、管理和业务的复杂度都有关系。

对诊断过程的漠视是自上向下改进策略的最大弊端。

在了解了组织、项目的实际状态以后，就可以有针对性地提出解决方案了，这一步骤称为方案设计。在上图方案中，我们可以看到主要的元素来自于CMM、SEBOK（软件工程）、Good Practice （最佳实践）。这种结果是与该企业的如下现状相适应的：

首先，该企业没有形成基本的软件工程流程。

其次，项目没有生命周期的概念，无明确启动和验收点，正如其项目经理所言，“我们的项目结束点要等到下一个项目已经开始，本期项目不得不结束时才会出现”。

再次，该企业整体管理基础薄弱，资源提供不充分，这种情况下，在大企业顺理成章的事情可能在这里都是问题，所以需要大量的变通和折衷策略，这些都被归纳在Good Practice中。

诸如此类的方案设计，存在两个裁减特征： 一是横向裁减，可以在打破现有知识体系的基础上，创造性的构建新体系；其二是纵向裁减，比如对于CMM具体KPA，也可以分两步或更多步来达到要求。所有这些裁减都会带来更多的灵活性。

SPI方案的编制需要涵盖如下内容：本组织软件过程改进的历史，过程诊断（包括诊断方法、诊断结果和差距分析），改进方案（包括总体目标、总体工程化管理系统设计和详细改进措施），资源需求预测，计划进度概要（包括前提和承诺、资源需求预测），风险，里程碑。

方案得到认可后，可启动项目策划。SPI的项目策划要求与其他项目策划的要求并无多少差异，主要是编制一份项目计划，有如下内容：项目目标（包括整体目标和本阶段目标），假定和约束，项目组织（包括组织结构、接口关系、报告关系和责任矩阵），项目进度跟踪方式，项目里程碑，交付物（包括文档编制和人员培训），风险管理，项目激励，项目验收。

计划制定好以后，还要对 SPI的实施过程进行定期和不定期的过程跟踪，一般可通过“周”和“里程碑”两种周期进行跟踪。周跟踪的内容为进度、完成量、问题和风险，通过周报和周会的形式进行；里程碑跟踪的内容为进度、工作量、人力开销、风险等，还要对项目管理的经验和教训进行总结，里程碑也是识别典型案例和收集最佳实践的良好时机。里程碑跟踪活动通常包括“里程碑总结报告编制”和“里程碑总结会”两种形式。

对于自底向上的软件过程改进，并没有标准的验收准则可利用，这要求组织根据自身裁减的体系编制自己的验收准则。验收准则有定性和定量两种形式，定量适合于有一定管理基础的组织，需要有足够的、可信的、可比的历史数据。但多数中小软件企业可能在起步阶段只能选择定性验收的方式，这种定性验收方式常常是“先僵化、再固化、后优化”理念的一种体现。　项目验收后，组织需要进行SPI项目的最后一项活动——项目总结，需要提交书面报告并召开总结会，项目总结中要统计汇总SPI本身数据、进度、开销、偏差及分析，还要识别和共享经验教训。这一阶段的工作将为今后的SPI持续改进打下良好的基础。SPI将进入下一个改进循环。