本书全面系统地介绍了软件过程的改进，向读者展示了现代软件过程改进管理的全貌。内容包括：过程思维、软件过程改进框架、如何进行软件过程改进、当前主要软件过程改进模型与标准以及软件过程改进的商业收益等。作者首选介绍了软件过程改进的有关概念、软件过程改进产生的历史根源和思想基础，然后提出了一整套完整通用的软件过程改进框架，并且对如何在企业中实施软件过程改进给出了切实可行的建议。此外，作者还以通用软件过程改进框架为基础，对当前各种主流的过程改进模型的特点与优劣进行了分析与比较，从而有助于企业在过程改进中对不同的模型加以取舍。
　　本书将帮助读者对组织内软件产品的质量加以管理与控制。由于软件缺陷会产生许多问题，处理这些问题是一件既费事又费力的事情。而Sami Zahran所提出的改进方法将使你摆脱疲于救火的窘境，最终实现具有预防性的、规范化的和持续的过程改进的企业文化。

软件开发是具有挑战性的工作
　　能够在规定的时间和预算内开发出可靠的软件对于许多组织来说都是一件非常困难的事情。在目前的商业活动以及人们的日常生活中，软件扮演着越来越重要的角色，因此由于软件产品延期、超过预算或者根本无法工作所引发的问题也变得日益严重。由于不可靠软件所导致的死亡或者在很大范围内引起的生活不便屡屡成为新闻媒体的头条。据估计，在最近几年中，由于软件缺陷导致的死亡人数已近4000人。在现代化的飞机中，如果软件停止运行200毫秒，就将造成不可挽回的损失。1996年6月，欧洲空间中心带着数颗卫星的火箭在发射数秒后发生爆炸，这次事故正是由于软件故障所导致。几年前，不可靠的软件成为英国国内的大新闻，从紧急情况处理系统的故障，到社会保障支付系统的失误，更不用说伦敦股票交易所这种大型项目中的故障了。提高软件质量是确保获得可靠产品与服务和获得客户满意度所不可或缺的。美国总审计局(US Government Accounting Office，GAO)的报告显示了以下一些情况：耗资数十亿美元的系统无法如预期的那样工作，成本以百万计的数字上升，进度的延误不是以月计而是以年计(Paulk等，1994)。仅有CASE工具是不够的
　　让新闻界激动不以的失败的软件项目与20世纪80年代中后期CASE工具在媒体上所夸下的海口形成了强烈的对比。工业界已经意识到仅有CASE工具是不够的。软件业已经形成一种共识，即"有工具的笨蛋依然是笨蛋"。通常情况下，商业解决方案包含三方面的内容：人、过程与技术。已有的工业方面的经验显示，当实施商业解决方案或者引入改革时，通常最不可能产生的问题就是技术问题，而过程和人员是导致成功或失败的关键因素。人员是过程不可分割的一部分，因为人是整个过程活动、过程监控、过程管理的关键。仅有合格的人员是不够的
　　软件行业界使用CASE工具的经验已经证明，导致软件项目失败的主要原因几乎与技术、工具没有任何关系，更多的是由于缺乏过程规范。软件开发需要团队的努力，如果缺少过程规范，团队就可能遵循不同的过程。更普遍的情况则是团队根本就没有任何经过定义的过程。这就如同"在同一支球队中，一些人在踢足球，一些人在打棒球，而其他的人却在打橄榄球。在这样的环境下，即便拥有最好的球员，也只能组成一支最差的球队(Humphrey，1995)。与此相反，一个遵循统一过程的团队可以很好地协调成员间的工作，为实现共同的目标，将团队成员工作的注意力都集中在一起并且对进展情况可以进行更加精确的跟踪。以过程为中心可以提供更多的成功机会
　　作为一种规范，软件开发已经有40多年的历史了，但是我们仍然无法将软件行业转变为工程规范化的行业。而近年来，对软件开发过程的关注则是向这个方向迈出的正确一步。只有通过创建规范的软件开发过程，我们才可能管理并控制软件产品的质量。各类组织已经意识到，他们的根本问题就在于软件开发过程的不成熟。所有的证据表明，投资于软件过程改进将会为软件行业带来更多的希望，而这就如同在制造行业和其他行业中所发生的那样。此外，提倡以工具为基础的软件开发活动的动机与基于过程改进的软件开发活动的动机是不同的。过程改进是软件开发组织的责任，其中并没有包含工具制造商的利益。通过使用工具来自动规范一个混乱的过程将导致更大的(自动化的)混乱。这样的例子比比皆是。在软件行业之外的最引人注目的一个例子就是：将复杂的武器工厂以及大规模杀伤性武器引入原始国家的两个部落之间时必定引起一场混乱的战争。这样的"技术性工具"不可能导致稳定，只可能增加人们的痛苦。经验显示，在不成熟或者没有规范的环境中，引入新的技术与工具可能会导致混乱的情况更加严重。没有规范的过程来加以控制与管理的话(例如质量保证、配
置管理以及项目管理)，这样的项目是不可能从工具中受益的。将工具用到这样的项目中只可能增加混乱，加速更多有缺陷的产品的生产，使客户的不满意度成倍提高。这样的项目最终将以各个方面的失望而告终。这里的失望有各种表现形式，例如浪费的人力、时间、金钱、资源以及可能带来的无法避免的灾难。软件过程改进运动：软件行业的第二次浪潮
　　为了满足在软件需求和复杂性方面日益增加的要求以及因此导致的开发团队规模的不断扩大，结构化开发方法于20世纪70年代逐渐发展起来了。这是软件行业的第一次浪潮。它是为了满足那些利用共享系统去建立复杂的交互式商业应用以及对这些系统进行维护而发展的。结构化方法所关注的是方法本身，即需求定义的正规化以及设计、创建那些可以在最终系统中加以追踪的需求的方法。已有的自动化的工具可以在某种程度上有助于进行部分此类转换。尽管这是将软件开发从"手工作坊"向大规模生产进行转换的开端，但这还很不够。而那些导致软件项目成功或者失败的真实原因(例如项目管理以及需求管理)还未成为关注的焦点。软件过程改进是对不断提高的软件项目失败率的一种反应。对过程的关注开始于美国国防部(DoD)最初对软件工程研究所(SEI)的赞助，SEI为美国国防部提出了评估软件转包商能力的方法。Watts Humphrey刚开始加入SEI时并没有明确的职位，在开始的数月中，他的头衔是SEI过程计划的主管。从那时开始，SEI所产生的关于过程的讯息就越来越多地影响到了全世界的软件行业。
　　人们可以很容易地将软件过程追溯到20世纪30年代，盛行于20世纪70、80以及90年代的质量控制运动。质量控制概念的领袖(例如Edwards Deming和Philip Crosby)在全世界的制造业获得了很高声望。Watts Humphrey在软件开发中引人了同样的质量控制概念。过程成熟度运动为软件行业的第三次浪潮铺平了道路，而这第三次浪潮就是"软件行业化"。在第三次浪潮中，软件开发将变得如同装配与制造过程一样。发动第三次浪潮的技术因素包括面向对象技术以及重用组件库，这使得利用标准重用组件以装配软件成为可能。第三次浪潮启动的关键因素是规范化的软件工程过程，在这个过程中，质量、进度与功能都是可以预测的。
　　本书的目的
　　本书提供了关于有效进行软件过程改进的实际方法，给出了创建过程支持架构的指南，以便读者能够以过程的观点来看待软件开发。书中概述了建立规范的以及持续改进的软件过程环境的实用方法。总的说来，本书给出了建立有效而持续的软件过程改进环境的框架。
　　本书的有关论点强调了与人有关的因素，理解过程并遵循过程和过程的定义是同样重要的，书中同样强调了过程规范对团队能力和实现商业目标的影响。
　　书中所提供的概念源于笔者从事软件行业三十多年的实际工作经验。在这些年中，笔者花费了大部分的时间去从事软件工程各个不同方面的工作与研究，其中包括软件开发以及软件项目管理中所经历的各种酸甜苦辣。这些项目覆盖了各种商业以及工业应用，包括从石油、银行、政府部门到国防、制造以及航天业。同时也包括操作系统、数据库管理系统、数据字典系统、事务处理系统以及大量的商业应用的开发。因为经历过多次的成功与失败，所以笔者于1992年第一次欣然到Carnegie Mellon大学的软件工程研究所去接受关于过程的培训。从那时开始，我对软件过程的热情就再也没有中断过。
　　读者对象　　
　　本书有广泛的读者，包括具有软件过程评估与改进知识的人们以及那些仅仅知道这个主题对他们的工作有意义的人们。换句话说，本书包括一些新的想法与方法，可能会使那些已经具有相关知识的人感兴趣，同时它又简单易读，因此同样适合于那些对此问题感兴趣的人。
　　本书主要是针对下列这些特殊人群：
　　软件工程经理和专业人员
　　参与软件过程活动的人们应该会对本书感兴趣，这些活动包括管理、协调、开发与控制。涉及的人员包括：对软件感兴趣的商业经理、项目经理、团队领导、软件工程师、软件支持人员，例如品牌管理、质量保证以及过程改进组。同时，本书也可以作为从事软件过程改进工程研究的研究生读物。
　过程改进组
　本书第一部分采用了通常的概念对过程思维进行讨论。它应该使所有关注过程改进活动的人受益。这些活动包括业务流程再造、业务流程再设计以及业务流程改进。
　　从事过程研究的科学家
　　书中提供了过程改进环境的整体方法。书中讨论的概念与方法可以使读者保持进一步研究过程建模和质量概念的热忱。
　　本书的结构
　　本书分为五个部分并附有词汇表和参考文献。
　　第一部分：过程思维
　　这部分是本书其余部分的知识基础。它定义并解释了什么是过程思维并将这个概念与过程规范联系在一起加以讨论。此部分描述了有效过程环境的特征，同时还将这些概念与软件过程环境相联系。第一部分包括4章：
　　第l章：过程思维
　　第2章：过程规范
　　第3章：有效的过程环境
　　第4章：过程成熟度：软件工业的第二次浪潮
　　第二部分：软件过程改进框架
　　这部分描述了软件过程环境框架，介绍了框架的组成、过程评估方法以及过程改进计划。
　　这个框架将会带来一个持续的过程改进环境。第二部分包括5章：
　　第5章：一个软件过程改进的框架
　　第6章：软件过程架构
　　第7章：过程改进规划图
　　第8章：软件过程评估的基本原理
　　第9章：软件过程改进的行动计划
　　第三部分：启动软件过程改进
　　这部分描述了如何在组织中计划并启动软件过程改进活动的策略与计划，讨论了将评估结果转换为改进计划的步骤，强调了度量软件过程改进收益的必要性。此外，本部分还讨论了软件过程改进的关键成功因素，总结了实施软件过程并使其制度化、度量商业收益时建议采用的一些方法。第三部分包括3章：
　　第10章：启动软件过程改进
　　第11章：软件过程改进的实现和制度化
　　第12章：度量软件过程改进带来的收益
　　第四部分：当前的软件过程改进模型与标准
　　第四部分描述了一些进行软件过程改进以及评估的著名模型与标准，其中包括软件工程研究所的过程成熟度模型(CMM)和基于CMM的评估、国际标准化组织的ISO／IEC l5504及其评估指导草案、BOOTSTRAP评估方法，此外还讨论了其他一些早期的工作，包括ISO 9001、MIL-STD-498、Trillium和V-模型。第四部分总共包括6章：
　　第13章：能力成熟度模型(CMM)
　　第14章：基于CMM的过程评估
　　第15章：ISO／IEC 15504软件过程评估的技术报告草案
　　第16章：ISO／IEC 15504评估操作指导草案
　　第17章：BOOTSTRAP软件过程评估
　　第18章：其他早期工作(ISO、MIL-STD-498、Trillium及V-模型)
　　第五部分：软件过程改进的商业收益
　　第五部分描述软件过程改进的商业收益，总结了关于追踪并度量收益方面的一些欧洲与美国的案例。最后，讨论了未来软件过程改进的一些设想。第五部分包括2章：
　　第19章：软件过程改进能够带来商业收益的证明
　　第20章：后记：软件过程改进的未来

Sami Zahran：暂无简介

陈新 罗劲枫：暂无简介

从20世纪70年代算起，国内的软件开发已经走过了30多年的岁月。但放眼国内，除了极少数几个可称得上"软件企业"的公司之外，我们的绝大部分公司仍然是"手工作坊"式的软件公司，而在我们的近邻印度，其软件出口额每年已高达几十亿美元之多。产生这种差距的原因有很多，例如政策方面的，市场方面的，人员素质方面的，但关键的一点还在于处于国内软件开发一线的大部分软件行业的从业人员缺乏对软件开发科学的正确认识，缺乏正规有效的软件开发过程。
　　可喜的是，近一两年，国内越来越多的企业认识到了软件过程的重要性，也有越来越多的有识之士投入到对软件过程以及软件过程改进的研究领域之中。但由于整个行业水平的低下，许多企业在从事这方面的工作时仍感到缺少必要的指导，致使无从下手。Sami Zahran的这本书正是为此而写的。书中讲述了什么是软件过程，为什么要使用软件过程，为什么要进行软件过程改进以及如何进行软件过程改进，他为我们指出了一条通向持续软件过程改进的光明大道。但同时应注意的是：软件过程改进是一件"知易行难"的工作，虽然书中给出了一个软件过程改进的良好框架，但在具体实施过程中仍会遇到许多困难。
　　希望本书的翻译能为国内软件行业的发展尽一份微薄之力。参加本书翻译工作的还有胡旦旦、荣勃、耿岳、王江波、潘龙、张科峰、汪洋和付钢等。
　　由于本书中大量使用专门术语，加之译者水平有限，在翻译过程中难免有错误，欢迎指正。读者还可就软件过程改进方面的内容与我们交流。我们的E－mail地址为：spi_book＠hotmail．com。

第一部分　过程思维
第1章　过程思维
1．1　什么是过程思维
1．2　什么是过程
1．3　以过程为中心
1．4　过程成熟度
1．5　小结
第2章　过程规范
2．1　过程规范
2．2　过程规范的优点
2．3　过程规范与产品质量
2．4　面向过程的组织
2．5　小结
第3章　有效的过程环境
3．1　关于过程的神话与事实
3．2　什么是高效的过程
3．3　保证高效过程机制
3．4　过程文化，
3．5　小结
第4章　过程成熟度：软件工业的第二次浪潮
4．1　软件工业的浪潮和趋势
4．2　软件过程成熟度运动
4．3　软件过程制度化的层次
4．4　软件过程成熟度标准和起步
4．5　小结
第二部分　软件过程改进框架
第5章　一个软件过程改进的框架
5．1　软件过程改进环境
5．2　软件过程架构
5．3　软件过程改进规划图
5．4　软件过程评估
5．5　软件过程改进计划
5．6　小结
第6章　软件过程架构
6．1　软件过程架构存在的原因与定义
6．2　组织与管理架构
6．3　过程的技术架构
6．4　一个软件过程支持架构的例子
6．5　保证架构的有效性
6．6　小结
第7章　过程改进规划图
7．1　向质量专家学习
7．2　软件过程改进模型
7．3　阶段型与连续型软件过程改进模型的比较
7．4　软件过程改进的标准与模型
7．5　小结
第8章　软件过程评估的基本原理
8．1　评估的定义
8．2　评估的原则以及成功的关键因素
8．3　评估领域
8．4　一般评估阶段
8．5　评估方法与通常评估周期之间的映射
8．6　小结
第9章　软件过程改进的行动计划
9．1　创建软件过程改进行动计划
9．2　为实施软件过程改进行动分配职责
9．3　行动计划指南--行动计划方法的一个实例
9．4　小结
第三部分　启动软件过程改进
第10章　启动软件过程改进
10．1　启动软件过程改进阶段
10．2　启动软件过程改进
10．3　采用一种软件过程改进的模型
10．4　Humphrey的过程改进的必要条件
10．5　成功的软件过程改进要素
10．6　小结
第11章　软件过程改进的实现和制度化
11．1　实现和制度化阶段
11．2　软件过程改进的实现和制度化原则
11．3　实现软件过程改进行动和管理变化
11．4　软件过程改进的制度化
11．5　SEIDEAL模型--SPI实现模型的范例
11．6　小结
第12章　度量软件过程改进带来的收益
12．1　度量软件过程的性能
12．2　软件过程度量的原则
12．3　软件过程度量中的问题
12．4　软件过程度量方法的实例
12．5　小结
第四部分　当前的软件过程改进模型与标准
第13章　能力成熟度模型(CMM)
13．1　能力成熟度模型简介
13．2　CMM中成熟度的级别
13．3　CMM的内部结构
13．4　CMM的使用
13．5　CMM 2．0版
13．6　小结
第14章　基于CMM的过程评估
14．1　基于CMM的评估
14．2　SEI成熟度问卷
14．3　SEI辅助评估过程
14．4　SEI的软件能力评价(SCE)
14．5　小结
第15章　ISO／IEC　15504软件过程评估的技术报告草案
15．1　简介
15．2　ISO／IECl5504技术草案的体系结构
15．3　ISO/IECl5504的过程类别
15．4　ISO／IECl5504的能力等级
15．5　ISO／IECl5504能力度量
15．6　ISO／IECl5504与其他国际标准的关系
15．7　小结
第16章　ISO／IECl5504评估操作指导草案
16．1　概述
16．2　评估计划
16．3　数据收集
16．4　数据分析
16．5　提交评估结果
16．6　ISO/IECl5504指南在评估方面的作用
16．7　在评估过程中使用ISO／IECl5504指南
16．8　小结
第17章　BOOTSTRAP软件过程评估
17．1　动机和背景
17．2　BOOTSTRAP过程模型
17．3　能力等级和评估手段
17．4　BOOTSTRAP的评估过程
17．5　BOOTSTRAP及其他早期活动
17．6　小结
第18章　其他早期工作(ISO、MIL-STD-498、Trillium及V-模型)
18．1　ISO 9000质量标准
18．2　ISO／IECl2207--"软件生命周期过程"
18．3　DoD标准MIL-STD-498
18．4　Trillium
18．5　V-模型
18．6　小结
第五部分　软件过程改进的商业收益
第19章　软件过程改进能够带来商业收益的证明
19．1　SPI收益与商业的关系
19．2　来自欧洲的证据
19．3　来自美国的证据
19．4　经验教训
19．5　小结
第20章　后记：软件过程改进的未来
20．1　过程成熟度是另一个漂亮的口号吗
20．2　国际标准的角色
20．3　过程规范是软件工业化的先决条件
20．4　下一步该怎么办
词汇表
参考文献