如何领导分布式团队？如何管理过程?如何使用质量模型?
世界范围的软件开发已经发生显著变化，游戏规则正在不断地改写：
逐步消失的地域界限
不断缩短的产品生命周期
竞争的加剧
商业模式的变化
技术的商品化
为了取得成功，满足日益变化的情况，产品必须更快地推向市场，质量还必须更高，而且要利用全球的资源。
本书讲述软件项目管理的三个方面--人员．过程和技术，以及它们之间的相互关系，特别是分布式团队情况下的一些特点。
本书重点介绍了以下几个方面：
全球化和分布式团队面临的项目管理问题。
合理地平衡人员，过程和技术这三个方面，有助于分布式团队的成功。
实际的例子和常犯的错误。
涵盖一些对项目成功至关重要的问题，比如每个职能需要的技能。过程模型的商业意义。
本书还包含了CMM的关键过程域和IS0-9001的20项条款。
本书可以使：
实践者领悟到众多过程的来龙去脉
教师找到现实生活中的丰富例子
学生理解业界软件项目的本质，为走向社会做好充分准备 可以在站点http://www.tatamcgrawhill.com/digital_solutions/gramesh/找到本书的更新。指导手册。幻灯片以及更多的资料。
软件开发从本地开发逐渐发展到异地开发，再到现在的全球化软件开发，全球化软件项目有什么特点呢？管理这样的项目又面临哪些挑战？本书作者根据自身丰富的全球化软件项目的管理经验和教学经验，从实践的角度对上述问题进行了透彻讲解，避免了理论说教的空泛。
本书第一部分讲了软件工程的理论背景知识；第二部分讲述了贯穿项目始终的伞式活动-包括度量、软件配置管理、软件质量保证和风险管理；第三部分介绍了以顺序发生为特点的流式活动-包括项目启动、项目计划与跟踪、项目结项；第四部分介绍项目周期中的工程活动-包括需求收集、估计、设计和开发、测试和维护；第五部分介绍了项目管理的未来趋势。
本书适合的读者范围很广，学生、教师及业界实践者都能从本书获益。
Gopalaswamy Ramesh是Oracle印度公司负责软件开发的高级主管。他还足位于Chennai的Anna大学的计算机学院兼职教授。此前他曾在班加罗尔的印度管理学院教授软件项目管理，并曾在新加坡领导东盟地区Oracle产品的技术支持工作。
在20多年的全球性职业经历中，Ramesh先生在软件开发、过程质量、项目管理、支持和咨询等众多领域都有工作经验。在众多国际会议上发表过多篇相关主题的论文。
作者在班加罗尔的印度科技大学获得电子和通信工程学士学位，在Madras的印度技术大学获得计算机科学硕士学位，并在斯坦福大学获得工程管理硕士学位。
本书体现了作者管理全球化软件项目的实践和教学经验精髓。
这里的全球化不仅仅限于软件开发领域。现在每件事都在向全球化方向发展，包括市场方面、竞争方面以及资源方面。即使本地开发的优点还没有完全消失，那它也是处于日益减少的状态。全球化将会成为历史的主角！今天，假设你正位于世界的一角进行着软件产品的开发，可能你所开发的产品在本地并没有什么市场，但是你仍可为世界上的其他市场进行开发，也就是进行全球化开发。为了减少开发的时间，解决本地人力资源的短缺，一些组织不得不利用全球范围内的人力资源。分布式的项目团队，即团队成员位于地球上的不同角落，以协作的方式进行软件产品的设计、开发、测试以及维护，这种情况越来越普遍了。
全球化的成功在很大程度上归因于Internet的存在。分布式团队之所以能够成为现实，技术的因素是主要的，但Internet也是不可或缺的。从技术的角度来说，争论什么是影响分布式团队成功的最重要的因素是无意义的，但是有效的项目管理以及沟通却是十分重要的。让我们看一眼那些失败的项目就能马上发现，导致失败的根本原因就在于忽视了一些基本原则（例如主动沟通）。
如果要求我在印度一所名牌学校讲授项目管理的话，我将集中讲授那些事关成败的有意义的经验，并且采用通常的工程化的角度来讲。本书乃心血之作，书中主要讲述三件事情：
1) 集中讲述全球化以及分布式项目团队所面临的问题。对于那些本地化的团队，这些问题是不会碰到的。
2) 书中试图通过实际的、可操作的例子，标识出那些可行的或不可行的东西。虽然本书的内容略偏重于实践，但总的来说我还是努力维持理论与实践两方面内容的平衡。
3) 最后，本书通过人员、过程以及技术这三个对于成功的分布式团队来说至关重要的因素，对有关内容加以论述，而不是单纯从技术或工程方法的角度来论述。
G. Ramesh
在过去的日子里，优秀软件人才市场正发生着巨大的变化。作为一名在印度以及海外从事了三十多年软件教学的人而言，首先让我在此与诸位分享我的感受，即在这些年中我所看到的，由于市场对软件人员不断增长的需求而导致的显著变化。在早先，计算机教育还只局限于诸如IIT Kanpur（以及后来的IIT Madras）等研究院所，并且计算机本身也十分昂贵，那时我们所讲授的计算机科学方面的知识也仅停留在“技术的层面”上。当时的课程包括汇编语言（也许还包括一门高级语言）编程、计算机体系结构、数值计算方法等，这就是整个计算机科学（虽然这个术语还没有得到认同）的内容。由于一些硬件方面的限制，当时还只有很少量的应用程序，所以早期的培训与教育条件还是满足要求的。后来纯粹面向编程的教育开始转为以软件工程为中心，使学生认识到应用程序对用户的作用，并且用户需要高质量的产品。而这导致了整个教育系统将注意力集中于这类概念上，例如生命周期模型、质量模型等。现在我们又进入了一个新的阶段，即面向Internet的应用—不用关心用户身在何方，但产品应具有高的性能、极强的稳定性、可以处理海量数据。因此现在教学方面所面临的问题是，如何将学生培训成为适合基于Web项目的、符合业界要求的人员。为了实现上述要求，并且满足业界对高质量人才的需求，我们在教学过程中需要满足下列要求：
1) 软件开发的成功并不仅仅依赖于技术的优秀。过去那种基于详细规范说明或工作指导的、以精英为核心的、面向任务的开发，已让位于更加灵活的、优化利用全球资源的开发了。这就要求人员不仅要具有基本的技术方面的能力，而且要有良好的管理与人际沟通技能，而这正是计算机科学/软件工程教学大纲中所缺乏的。
2) 当人们走出学校时，也就开始了他们的“流浪之旅”，他们必须了解当前的技术以及当前企业中一流的方法。但考虑到技术更新的速度，针对工程师以及管理者的单纯的培训是不够的，更重要的则是使他们成为“终生的学习者”，从而可以快速学习新的技术与方法。而这需要学生们明白“为什么”以及“如何做”，这样他们才能适应新的技术以及新的软件过程管理。
而这正是本书适用于不同人员的原因。首先，我认为本书对于那些想在研究院所中培训出业界所需的软件专业人才的教师们来说是十分有价值的。每位教师都愿意通过现实生活中的具体事例来充实自己，但是由于缺乏业界的工作经验，这一点对于大多数人来说是可望而不可及的。本书正好提供了这样一个充实自己的机会，教师们可以利用它使理论知识变得更加吸引人。我喜欢那些来源于现实生活的作业，我敢说，通过这本书及相应网站中的有关提示（针对老师，尤其是那些没有什么实际经验的老师），他们最终会学会给学生们布置作业的。其次，我认为学生们可以通过本书了解到业界进行软件项目开发的本质，即集体协作。他们会学到一个团队如何通过有关的软件工具制定项目计划，并基于计划进行开发。此外，他们还将学到如何遵循严格的质量保证流程。我希望他们还应认识到沟通以及协调人际关系的重要性。第三点，我希望业界的那些实践者们能够认识到多数过程的真正本质是什么，而有些人往往却将这些过程看作是强加于身上的条条框框。书中对那些著名理论进行了基于实践经验的解释，每个人都能从中得到启发。最后要说的是，这本书为我们带来了全新的管理观念。
IT行业应当认识到测试以及维护工程师的价值，并且把他们与开发人员同等对待。只有那些测试及维护人员能够将他们所从事的工作看成是一项具有挑战性的工作的话，我们才能指望他们实现更高的工作效率，从而使他们的工作也更有价值。通过整整两章对测试以及维护的论述和展望，作者为我们指出了那些常为人所忽视的重要内容。
专业的软件人员总是抱怨说他们没有时间阅读。对于那些有抱负的软件工程师来说，我想不出除了自学以外，还有什么更好的提高自身水平的方法。一个有抱负的软件工程师应将此作为成功的秘诀。而本书则可以作为一本有价值的参考书。
在某种意义上说，“软件工程”类似于“管理”，这是因为二者都没有什么基本的深奥道理。世上没有放之四海而皆准的东西，而是要人们通过个体的实践来发现很多经验，并且通过自身所犯的错误去加以验证，在当今这个快速发展的IT行业，我们没有时间去从他人的错误中加以学习。本书作者为我们带来了有趣的、活生生的事例，而不是那些枯燥无味的理论。很多年轻的软件人员有时也意识到改进方法的重要性，但是却苦于没有时间或不相信自己的感觉。通过多角度的观察训练，本书可以帮助他们变得更具创造性。
作为Ramesh的老师，我很高兴他克服了种种困难，将其多年作为学生以及专业软件人员所积累下来的经验付诸笔墨。正如本书标题所表达的，本书所强调的主题也正迎合了当今IT行业的需要。从行业支持到研发，从Oracle印度开发中心的初创到现在在班加罗尔领导着一个超过300人的团队，作者有着丰富的全球化开发经验，他是最有资格告诉我们什么内容最重要的人了。此外，本书是基于他针对硕士研究生讲授的为期一个学期的课程整理而成的。希望本书的出版能将他在Anna大学所讲授的内容传播到印度乃至于国外的其他学校。总之，我希望这本书为IT业，尤其是印度IT业从“编码工厂”迈向“全球化软件组织”尽一份力。
印度信息技术研究院Hosakere N Mahabala教授
hnmahabala@yahoo.com
（印）Gopalaswamy Ramesh：暂无简介
陈新 孙肖峰 徐军：暂无简介
译者在软件企业一直从事软件项目管理和过程改进工作，深感资料的匮乏。国内的软件工程书籍往往过于理论化，偏重技术层面，给人以纸上谈兵的感觉；而项目管理的书籍也往往过于通泛。而软件项目又有很多特色之处，常有无从下手之感，而像ISO-9001、能力成熟度模型（CMM）这样的质量（过程管理）体系，往往又被许多企业盲目甚至急功近利地生搬硬套，最终反而成为一种负担，让实施人员惟恐避之不及。
在翻译本书的过程中，对书中的许多论述常常产生强烈的共鸣。作者谈到的许多问题，会让我们想起经历过的某个项目，而作者提出的见解又让人有相见恨晚的感觉。作者Gopalaswamy Ramesh，作为Oracle印度公司负责软件开发的高级主管，有着深厚的理论基础和教学经验，还有相当长的业界实践经历。作者对软件开发中常见的问题和应对措施进行了精彩的总结，并且把过程、质量、管理—许多人认为“太虚”或者“负担”的东西，融合在每个软件开发活动中，让你看到软件工程、管理、过程的“实处”，实在是一本不可多得的好书。
我国许多有竞争力的软件企业在国内有很高的市场占有率，甚至进入到国际市场。也有不少的企业是国外公司软件研发的分支机构或者合作伙伴。随着前段时间国内对印度模式的热烈讨论和思考，越来越多的企业进入到国际软件外包业，软件开发团队分布在国内或者世界各地，这些企业的管理人员将面临更多的分布式团队的管理问题，而作者的经历及其有关见解，对分布式开发团队的项目管理人员来说会有很大的帮助。
本书的第一部分和第二部分重点介绍软件工程的基础理论，由陈新翻译；第三部分和第四部分偏重于介绍项目管理，由孙肖峰翻译；第五部分阐述了项目管理趋势和Internet对项目管理的影响，由徐军翻译。
本书对学习软件开发和软件工程的学生、教授相关课程的老师、企业中实施CMM、ISO-9001过程管理的人员、软件开发人员、项目管理人员等等，都会有很大的帮助。
译 者
2003年4月
第一部分 背景知识
第1章 介绍 3
1.1 概述 3
1.2 关于本书 4
1.3 本书的组织结构 5
1.4 书中所用符号说明 6
参考资料 7
第2章 产品生命周期 9
2.1 介绍 9
2.2 想法的形成 13
2.3 原型开发阶段 14
2.4 Alpha阶段 14
2.5 Beta阶段 15
2.6 产品生产阶段 15
2.7 维护与退役阶段 16
结论 17
参考资料 18
问题 18
第3章 项目生命周期模型 21
3.1 什么是项目生命周期模型 21
3.2 用于研究不同生命周期模型的框架 22
3.3 瀑布模型 22
3.4 原型开发模型 23
3.5 快速应用开发模型 26
3.6 螺旋模型及其变种 28
结论 30
参考资料 30
问题 30
第4章 过程模型 33
4.1 介绍 33
4.2 过程的特点 33
4.3 如何建立有效的过程 36
4.4 为什么过程很重要 37
4.5 过程模型 38
4.6 关于过程的常见错误观点 45
结论 46
参考资料 46
问题 47
第二部分 伞式活动
第5章 度量 53
5.1 介绍 53
5.2 度量路标 55
5.3 典型的度量策略 58
5.4 需要度量什么 59
5.5 设定目标并加以跟踪 60
5.6 理解并尝试将变化最小化 62
5.7 针对数据展开行动 66
5.8 度量中与人员及组织有关的话题 67
5.9 度量过程中常见的问题 68
5.10 实施度量的检查单与工具 70
结论 73
参考资料 73
问题 73
第6章 软件配置管理 77
6.1 介绍 77
6.2 一些基本的定义与术语 79
6.3 软件配置管理的过程与活动 80
6.4 配置状态统计 88
6.5 配置审计 89
6.6 分布式开发团队中的软件配置管理 90
6.7 软件配置管理中的度量 91
6.8 软件配置管理工具与自动化 91
结论 95
参考资料 95
问题 96
第7章 软件质量保证 99
7.1 如何定义质量 99
7.2 为什么说质量（一致性方面的）对于
软件很重要 100
7.3 质量控制与质量保证 101
7.4 质量的费用与收益 103
7.5 软件质量分析员的作用 104
7.6 对软件质量分析员作用的的一些
常见误解 106
7.7 软件质量保证工具 107
7.8 组织结构 111
7.9 成功的软件质量分析员的特点 112
7.10 对软件质量分析员工作成功与否
的度量 113
7.11 软件质量分析员角色易犯的错误 114
结论 115
参考资料 115
问题 115
第8章 风险管理 117
8.1 介绍 117
8.2 什么是风险管理，为什么说它很重要 118
8.3 风险管理周期 119
8.4 风险标识：通用工具与技术 120
8.5 风险量化 123
8.6 风险监控 125
8.7 风险规避 126
8.8 全球化项目团队中的风险及其规避 127
8.9 风险管理中的部分实践技巧 128
8.10 风险管理中的度量 128
结论 129
参考资料 129
问题 129
第三部分 项目管理过程与活动
第9章 项目生命周期：流式活动 135
9.1 伞式活动和流式活动的区别 135
9.2 主要的流式活动 135
9.3 过程/项目库 136
第10章 项目启动 139
10.1 介绍 139
10.2 项目启动中的活动 139
10.3 项目启动阶段的输出、质量记录
和完成准则 146
10.4 过程库的接口 146
结论 147
参考资料 147
问题 148
第11章 项目计划与跟踪 149
11.1 项目计划与跟踪的组成部分 149
11.2 项目计划的“做什么”部分 151
11.3 项目计划的“成本”部分 155
11.4 项目计划的“何时”部分 156
11.5 项目计划的“如何做”部分: 针对项目
裁剪组织的过程 158
11.6 项目管理计划的“由谁做”部分：
分配资源 160
11.7 整合所有部分: 软件项目管理计划 161
11.8 项目跟踪活动 163
11.9 过程库的接口 170
结论 171
参考资料 171
问题 171
第12章 项目结项 175
12.1 项目结项什么时候发生 175
12.2 为什么我们应该明确地做结项 175
12.3 有效的结项过程 175
12.4 在结项中要讨论的问题 177
12.5 项目结项的度量 180
12.6 过程库的接口 180
结论 181
问题 181
第四部分 工 程 活 动
第13章 项目生命周期中的工程活动 185
第14章 软件需求收集 187
14.1 需求收集的输入和开始准则 187
14.2 需求收集的几个方面 187
14.3 需求收集遵循的步骤 193
14.4 需求阶段的输出和质量记录 195
14.5 需求阶段需要的技能 195
14.6 成品软件的不同 196
14.7 需求管理阶段的挑战 197
14.8 需求阶段的度量 198
结论 199
参考资料 199
问题 199
第15章 估计 201
15.1 什么是估计 201
15.2 何时做估计以及为什么做估计 202
15.3 估计的三个阶段 202
15.4 估计方法 205
15.5 规模估计的形式化模型 207
15.6 将规模估计转换为工作量估计 209
15.7 将工作量估计转换为进度估计 210
15.8 估计中常见的挑战 211
15.9 估计过程的度量 212
参考资料 213
问题 213
第16章 设计和开发阶段 215
16.1 我们所选择的方法中的一些不同 215
16.2 设计的突出特征 216
16.3 体系结构/蓝图的演化 216
16.4 可重用性设计 218
16.5 技术选择/限制 218
16.6 面向标准的设计 219
16.7 可移植性设计 220
16.8 用户界面问题 221
16.9 可测试性设计 222
16.10 可诊断性设计 223
16.11 可维护性设计 225
16.12 可安装性设计 227
16.13 互操作性设计 227
16.14 设计和开发阶段的挑战 228
16.15 设计和开发的技能 229
16.16 设计和开发阶段的度量 231
结论 232
参考资料 232
问题 232
第17章 测试阶段的项目管理 235
17.1 介绍 235
17.2 什么是测试 235
17.3 构成测试的活动 236
17.4 测试进度和测试类型 243
17.5 测试中的人员问题 252
17.6 在全球化团队中测试的管理结构 254
17.7 测试阶段的度量 257
结论 257
参考资料 258
问题 258
第18章 维护阶段的项目管理 261
18.1 介绍 261
18.2 维护阶段的活动 261
18.3 维护阶段的管理问题 267
18.4 维护阶段的配置管理 269
18.5 维护阶段人员的技能 270
18.6 维护阶段的规模、工作量和人员
估计 271
18.7 维护阶段采用分布式团队的好处 272
18.8 维护阶段的度量 272
结论 273
问题 273
第五部分 未来趋势
第19章 项目管理中的全球化问题 277
19.1 全球化的演化 277
19.2 组建全球化团队面临的挑战 279
19.3 全球化项目的实施模型 280
19.4 有效管理全球化团队的技巧 284
结论 285
问题 286
第20章 Internet对项目管理的冲击 289
20.1 介绍 289
20.2 Internet对项目管理的影响 289
20.3 针对Internet的项目管理 294
20.4 对项目管理活动的影响 296
参考资料 300
问题 300
第21章 以人为中心的过程模型 301
21.1 逐渐强调以人为中心的模型 301
21.2 人员能力成熟度模型 302
21.3 其他的以人为中心的模型 305
21.4 组织如何选择使用哪一个模型 305
问题 307
参考资料 307
参考文献 309
