内容提要
软件过程改进是目前IT 企业研发管理的重点与难点。

为了提高软件过程能力，企业首先要研制软件过程规范，这是有一定难度并且费时费力的工作。

本文论述的是一套通用的CMMI 3级软件过程改进方法与规范，称为“精简并行过程”（SPP）。

SPP 2.0共有19个关键过程域，分为项目管理过程、技术开发过程和支撑过程三大类：
✧项目管理过程有7个关键过程域，分别为立项管理、结项管理、项目计划、项
目跟踪、风险管理、外包管理和需求管理。

✧技术开发过程有8个关键过程域，分别为需求开发、技术预研、系统设计、实
现与测试、系统测试、用户验收、产品维护和技术评审。

✧支撑过程有4个关键过程域，分别为配置管理、质量保证、采购管理和培训管
理。

SPP 2.0文档总数约500余页，包含了众多的过程规范和模板。

采用SPP，用户可以在最短的时间内建立适合于本企业的软件过程规范，大大降低用户研制规范的代价和风险。

一、背景介绍
在国内，绝大多数大中型IT企业几乎都面临着“研发管理混乱”的难题。

“研发管理混乱”必将导致“产品质量低下”、“进度延误”、“费用超支”等问题。

IT企业谋求发展，研发管理必须规范化，这是大中型IT企业的迫切需求。

软件过程改进（Software Process Improvement, SPI）是目前国内大中型IT企业研发管理的重点与难点。

CMM（Capability Maturity Model）是用于衡量软件过程能力的事实上的标准，同时也是目前软件过程改进最好的参考标准。

CMM是由美国卡内基-梅隆大学（Carnegie-Mellon）软件工程研究所（Software Engineering Institute, SEI）研制的，其发展简史如下：
✧CMM 1.0于1991年制定。

✧CMM 1.1于1993发布，该版本应用最广泛。

✧CMM 2.0草案于1997年制定（未广泛应用）。

✧到2000年，CMM演化成为CMMI（Capability Maturity Model Integration），CMM
2.0成为CMMI 1.0的主要组成部分。

✧CMMI-SE/SW 1.1（CMMI for System Engineering and Software Engineering）于
2002年1月正式推出。

CMM将软件过程能力分为5个级别，最低为1级，最高为5级。

目前国内只有几家IT企业达到了CMM 2级或CMM 3级。

鉴于CMM 已经被美国、印度软件业广为采纳，并且取得了卓著成效，近两年来国内兴起了CMM 热潮。

CMM受欢迎的程度远远超过了ISO同类标准。

国内IT企业采用CMM的目的大体有两种：
（1）主要想提高企业的软件过程能力，但并不关心CMM评估。

（2）既要提高企业的软件过程能力，又想通过CMM评估来提升企业的威望与知名度。

出于第一种考虑的企业占绝大多数，它们主要是一些中小型IT企业。

出于第二种考虑的一般是实力雄厚的大型IT企业。

无论是哪类IT企业，它们在实施CMM时遇到的共性问题是“费用高、难度大、见效慢”。

企业做一次比较完整的CMM 2-3级咨询和评估大约要花费60~100万元。

然而CMM咨询师只能起到“参谋”的作用，解决实际问题还得靠自己。

企业要组建软件工程过程小组（Software Engineering Process Group, SEPG）专门从事CMM研究与推广工作，SEPG 的成本并不比咨询费低。

如果企业再购买一些昂贵的软件工程工具（例如Rational的产品），那么总成本会更高。

即使企业舍得花钱，也不意味着就能够容易地提高软件过程能力。

目前国内通过CMM 2-3级评估的企业屈指可数，而这些企业的实际能力也没有宣传的那么好。

因为参加CMM评估的项目都是精心准备的，个别项目或者事业部通过了CMM评估并不意味着整个企业达到了那个水平，这里面的水分相当大。

曾经有一段时间，IT人士经常争论“CMM好不好”、“值不值得推广CMM”等话题。

现在业界关注的焦点则是“企业如何以比较低的代价有效地提高软件过程能力”，攻克这个难题必将产生巨大的经济效益和社会效益，这正是作者致力研究的课题。

二、SPP介绍
一般地，为了真正提高软件过程能力，企业至少要做三件最重要的事情：
✧首先制定适合于本企业的软件过程规范。

✧对员工们进行培训，指导他们依据规范来开发产品。

✧购买一些软件工程和项目管理工具，提高员工们的工作效率。

本书作者根据上述需求，研制了一套“软件过程改进解决方案”（Software Process Improvement Solution, SPIS）。

SPIS的主要组成部分有：
✧基于CMMI 3级的软件过程改进方法与规范，命名为“精简并行过程”（Simplified
Parallel Process, SPP）。

✧基于SPP的一些培训教材，包括软件工程、项目管理、高质量编程等。

✧基于Web的项目管理工具，包括项目计划、项目监控、质量管理、配置管理、
需求管理等功能，命名为Future。

SPP是SPIS的方法论，它由众多的过程规范和模板组成。

SPP 2.0共有19个关键过程域（如下表所示），基本满足CMMI 3级要求。

SPP模型是三层结构，上层是项目管理过程的集合，中层是技术过程的集合，下层是支撑过程的集合。

这种模型很直观，高级经理、项目经理、开发人员、质量保证员等人根据SPP模型很容易知道自己“应该在什么时候做什么事情，以及按照什么规范去做事情”。

SPP 采用CMMI 而不是CMM 作为参考标准，主要原因如下：
CMM的核心是十年前创作的，十年来IT产业有了长足的发展，相应的工业规范必然要不断地改进。

在总结CMM应用的大量经验教训的基础之上，SEI推出了CMMI。

CMMI 重大的改进在于它不仅完善了CMM本身，而且充分考虑了软件工程与系统工程的集成，使得该规范不再局限于软件范畴。

由于CMMI 1.1问世不久，人们了解和采用CMMI需要一定的时间，但是CMMI将取代CMM这是必然的趋势。

三、软件过程改进体会
✧要想提高企业的软件过程能力，本质上是靠规范化的企业管理。

而管理混乱向来是
中国企业最大的病痛，这是个非常复杂的问题。

同时，软件过程改进不是一次性买卖，不能靠“革命”，只能靠持续地改良，不进则退。

这些道理实践者一定要明白，并且要有心理准备。

✧企业要根据自身实力（人力、物力、财力）和商业目标来改进软件过程能力，不可
为了追求CMMI高级别而过分加重开发人员和管理人员的负担。

✧软件开发是如此的灵活，如果没有规范来指导与制约，就容易因无序而导致混乱。

但是规范如果不切实际或者太严密了，就容易畸变成为死板的教条，会扼杀开发人员生机勃勃的创造力。

软件过程规范应当力求简单实用。

✧要考虑中西方文化的差异。

例如CMMI中的质量保证关键过程域并不能容易地在国
内IT企业中实施，因为质量保证员在国内企业中是个非常尴尬的角色。

大部分项目经理不仅要管理项目，还要参加技术开发。

这些都是不容忽视的国情。

✧CMMI是个了不起的规范，但是仍然有很多不足之处。

CMMI对于项目管理很有指导
价值，但是它对技术开发过程的论述却不够深入。

对于大多数软件项目而言，技术开发占总工作量的70％以上，而项目管理占总工作量的30％以下。

对大多数企业而言，技术开发过程的规范化比项目管理过程的规范化尤为重要与迫切，这个问题不是单靠CMMI能解决的。

所以不要死搬硬套CMMI。

✧实施CMMI时要对全员进行培训，不能对职务高的人“网开一面”。

我们曾对试点
单位的所有项目经理和软件开发人员作了大量培训，并作了考核，群众基础相当好。

那些高级经理由于事务繁忙，不愿参加培训，导致他们不懂规范，依旧凭感觉指挥。

虽然他们口头上表示支持，但是有时反而起到了带头“破坏规矩”的作用。

✧采用一些管理工具，帮助工作人员提高效率，降低负担。

选择管理工具不必追求最
先进，简单实用就是“最好”。

四、成功的软件过程改进的关键因素
✧高层管理者应设定切实可行的目标
✧要从管理的角度提供足够的支持
✧成功地改进离不开项目经理以及软件工程师的参与
✧过程改进应被当作真正的项目加以对待
✧过程改进计划时参考过程改进规划图加以制定的
✧持续的过程改进是一条漫漫长路
✧队成员工作业绩的评估与奖励应与过程的实施效果挂钩
✧过程的实施效果应加以评估
✧确保在整个实施过程中过程目标、项目目标以及企业目标三者一致性✧组织中的每个成员均应参与到过程改进活动中来。