C M M I3级软件过程改进方法与规范软件过程改进是目前IT 企业研发管理的重点与难点。

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

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

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

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

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

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

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

本书的主要读者对象是IT企业的研发主管、项目经理和软件开发人员，以及即将到企业工作的高校毕业生。

前言一、背景介绍在国内，绝大多数大中型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 ModelIntegration），CMM 2.0成为CMMI 1.0的主要组成部分。

✧CMMI-SE/SW 1.1（CMMI for System Engineering and SoftwareEngineering）于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 2.0文档总数约500余页，本书即根据这些文档改编而成。

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

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

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

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

三、研究经历与出版目的本书作者对上海贝尔软件工程和项目管理的深入研究为创作SPP 打下了良好的基础。

近几年来，上海贝尔平均每年有100个研发项目，研发经费达数亿元。

公司约有1500名研发人员，半数以上是软件开发人员。

由于公司的研发管理能力不够强，特别是软件过程能力比较薄弱，大量以软件为主的项目开发过程比较混乱，导致新产品的质量问题严重，进度不断地被拖延，直接经济损失近亿元。

痛定思痛，在2000年下半年，公司领导决定成立专门小组从事CMM的研究与推广工作。

2001年初，林锐博士在网络应用事业部（试点单位）组建了SEPG，共有6名成员。

SEPG撰写的规范累计达千页，陆续被公司千余名研发人员使用。

SEPG在试点单位的推广力度相当大，仅对规范的培训就超过了600人天。

在一年多的研究与实践中，SEPG取得了一些成功，也经历了不少挫折，积累了相当丰富的经验。

在和很多同行专家交流时我们发现，上海贝尔面临的软件工程和项目管理问题在很大程度上代表了国内IT业界面临的共性问题。

这是因为：上海贝尔虽然是合资企业，但是公司各级领导和员工们都是中国人。

千余名研发人员接受的是中国的大学教育，他们都以“中国人的方式”开发产品。

而软件工程和项目管理无疑是国内大学计算机教育最薄弱的环节，这是因为：（1）大部分学生甚至教师几乎不了解企业，（2）教科书几乎不讲如何解决企业面临的实际问题。

所以这种教育模式下产生的大部分研发人员不懂得以规范化的方式开发产品。

上海贝尔的研发项目规模“小至几个人月大至150人年”，项目经费“小至几万元大至数千万元”。

所以国内IT企业面临的各种各样的软件工程和项目管理问题，在上海贝尔几乎都能找到相似之处。

我们曾与国内很多研发人员和各级经理交谈过，大家都对研发管理的混乱局面表示了不满和无奈。

尽管“土匪游击队”的开发模式到处可见，但是没有人真的喜欢混乱，大家无不渴望以规范化的方式开发产品。

这是现状、是需求、也是希望。

基于上述背景，本书作者及合作者决心创作一套切合国情的通用的“CMMI 3级软件过程改进方法与规范”（即SPP），这是件非常有意义的事情。

我们对SPP倾注了热情，一年来草稿写了上千页，仅对SPP模型的修改就达上百次。

SPP 2.0是我们最新的作品，我们自己认为SPP不比RUP（Rational Unified Process）逊色。

但是SPP 2.0尚未经过大规模应用，也没有经过权威认证。

鉴于SPP的创作者们来自于不同的工作单位（企业和大学），SPP本身不涉及商业或技术机密。

我们决定公布SPP 2.0，这样可以让更多的人使用SPP，从而不断完善SPP。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

所以不要死搬硬套CMMI。

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

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

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

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

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