图书信息

内容简介

作译者介绍

目录

译者序

前言

图书信息

原书名： Introduction to the Team Software Process原出版社： Addison-Wesley Professional

作者： (美)Watts S. Humphrey [作译者介绍]

译者： 吴超英 师春泽 汪浩

丛书名： 软件工程经典系列

出版社：人民邮电出版社

ISBN：9787115251893

出版日期：2011 年6月

开本：16开

页码：382

内容简介

《团队软件过程(第2版)》(简称“tspi”)，是美国embry-riddle aeronautical大学为计算机科学系研究生和高年级本科生开设的一门软件工程课的教科书。这本书系统地论述了如何以开发团队的形式来进行软件的开发，并对开发过程作出了具体而详尽的指导，包括团队成员之间的协调、进度的管理、质量的控制等令读者最感兴趣的方面。

《团队软件过程(第2版)》内容包括四个部分：第一部分——绪论，包括前两章，是对理论的简单介绍，介绍了什么是tspi、tspi的组织结构等内容。第二部分——tspi过程，包括第3章到第10章，则是整个小组研究周期的详细内容，详细解释了小组软件开发的步骤，并且给出了 tspi完整形式的例子。第三部分——小组角色，包括第11章到第15章，提供了小组成员角色的细致描述：小组领导者、开发经理、计划经理、质量/进度监督经理，以及技术支持经理。第四部分——使用tspi，包括第16章到第18章，讲述了在使用本书的过程中需要注意的一些原则。

《团队软件过程(第2版)》实用性与可读性较强，适用于软件开发项目经理、程序员和一般编程爱好者在开发软件时参考，也可作为高等学校计算机软件工程课程的参考书使用。

作译者介绍

Watts S.Humphrey 是位知名作者，在软件开发过程和软件过程改进方面著有多本影响深远的图书：Managing the Software Process(1989)、A Discipline for Software Engineering(1995)、Managing Technical People(1997)。Humphrey曾长期在IBM公司担任高级软件开发经理，获得了大量的软件开发过程方面的经验，是卡内基梅隆大学软件工程研究所的研究员，就软件质量和软件过程方面的主题著书立说、提供咨询，并在世界各地发表这方面的演讲。

目录

《团队软件过程(第2版)》

第一部分　绪论

第1章　tspi简介　2

1.1　tspi是什么　2

工程小组为何需要过程　3

1.2　tspi原则　3

1.3　tspi的设计　3

1.3.1　在个体软件过程(psp)的基础上提供一个简单的框架　4

1.3.2　在几个周期内开发产品　4

1.3.3　建立标准的质量和绩效度量　5

1.3.4　为团队和学生提供精确的度量　5

1.3.5　进行角色和团队评阶　5

1.3.6　需要过程规范　5

1.3.7　提供团队问题的指导　6

1.4　tspi的结构和流程　6

周期性开发策略　6

1.5　tspi过程　7

1.6　本书结构和流程　10

1.7　小结　10

第2章　团队软件过程的基本原理　11

.2.1　项目为何失败　11

处理压力　12

2.2　常见的团队问题　12

2.2.1　无效的领导力　12

2.2.2　不能做出妥协安排或不善于合作　13

2.2.3　缺少参与　13

2.2.4　拖拉与缺乏信心　13

2.2.5　质量低劣　13

2.2.6　功能多余　13

2.2.7　无效的组员互评　14

2.3　团队是什么　14

2.3.1　团队规模　14

2.3.2　具有凝聚力的团队(jelled team)　14

2.3.3　团队协作的基本条件　15

2.4　建设高效团队　15

2.4.1　团队凝聚力　15

2.4.2　挑战性的目标　15

2.4.3　反馈　16

2.4.4　共同的工作框架　16

2.5　团队如何发展　16

团队如何成为具有凝聚力的团队　17

2.6　tspi如何建设团队　17

2.6.1　目标　17

2.6.2　角色　18

2.6.3　计划　18

2.6.4　沟通　18

2.6.5　外部沟通　19

2.7　小结　19

2.8　参考文献　19

第二部分 tspi过程

第3章　启动一个团队项目　22

3.1　为什么需要团队启动过程　22

3.2　团队目标　23

3.2.1　设定目标需要考虑的因素　23

3.2.2　设定团队目标　24

3.2.3　tspi的目标设定　24

3.3　团队成员目标　25

设定团队成员目标　25

3.4　角色目标　26

3.4.1　团队领导目标　26

3.4.2　开发经理目标　26

3.4.3　计划经理目标　27

3.4.4　质量和过程经理目标　27

3.4.5　支持经理目标　27

3.5　tspi启动脚本　27

3.5.1　学生信息　31

3.5.2　产品目标　33

3.5.3　团队分工　33

3.5.4　团队目标　33

3.5.5　团队会议与第一次团队会议　33

3.5.6　数据需求　37

3.5.7　项目开始　38

3.5.8　项目资料库　38

3.5.9　tspi支持工具　38

3.6　小结　38

第4章　开发策略　39

4.1　计划先行　39

4.1.1　承诺之前先计划　39

4.1.2　为本课程制定计划　40

4.2　策略是什么　40

4.3　概念设计　41

4.4　风险管理　41

管理风险　42

4.5　复用策略　42

4.6　策略脚本　43

4.6.1　入口准则　45

4.6.2　建立策略评判准则　45

4.6.3　完成概念设计　46

4.6.4　选择开发策略　46

4.6.5　完成初步规模估算　48

4.6.6　完成初步时间估算　48

4.6.7　评估风险　49

4.6.8　建立策略文档　49

4.6.9　更新开发策略　49

4.6.10　制定配置管理计划　49

4.6.11　出口准则　50

4.7　小结　50

第5章　开发计划　51

5.1　计划的必要性　51

5.1.1　为什么制定计划　51

5.1.2　平衡的计划　52

5.1.3　对照计划跟踪进展　52

5.1.4　详细计划　53

5.1.5　处理未计划任务　54

5.1.6　估算级别　54

5.1.7　实现计划　55

5.2　tspi计划过程　56

5.3　tspi支持工具　57

5.4　开发计划脚本　57

5.4.1　入口准则　60

5.4.2　项目计划步骤2.1　60

5.4.3　项目计划步骤2.2　60

5.4.4　项目计划步骤3.1　63

5.4.5　项目计划步骤3.2　63

5.4.6　项目计划步骤4.1　66

5.4.7　项目计划步骤4.2　66

5.4.8　项目计划步骤5　67

5.4.9　项目计划步骤6　72

5.4.10　项目计划步骤7　72

5.4.11　最后的计划步骤　73

5.4.12　出口准则　77

5.5　跟踪工作情况　77

5.5.1　项目跟踪步骤1　78

5.5.2　项目跟踪步骤2　78

5.5.3　项目跟踪步骤3　78

5.5.4　项目跟踪步骤4　79

5.5.5　项目跟踪步骤5　79

5.5.6　项目跟踪步骤6　79

5.5.7　项目跟踪步骤7　79

5.5.8　项目跟踪步骤8　79

5.6　质量计划　80

5.6.1　概要比率　80

5.6.2　零缺陷率(pdf)　81

5.6.3　每页缺陷数　81

5.6.4　缺陷数/kloc　82

5.6.5　缺陷比率　83

5.6.6　开发时间比率　83

5.6.7　a/fr　83

5.6.8　评审速率和审查速率　84

5.6.9　缺陷注入率　84

5.6.10　缺陷排除率　85

5.6.11　阶段收益　86

5.6.12　过程收益　86

5.6.13　处理低质量部件　86

5.6.14　出口准则　87

5.7　小结　87

5.8　参考文献　87

第6章　定义需求　88

6.1　需求是什么　88

6.2　为什么需要需求　89

6.3　需求变更　89

需求提取　90

6.4　软件需求规格说明书　90

6.4.1　需求可追溯性　91

6.4.2　平衡工作量　92

6.5　tspi需求脚本　92

6.5.1　入口准则　95

6.5.2　要求陈述评审　95

6.5.3　要求陈述澄清　96

6.5.4　需求任务分配　96

6.5.5　需求文档　96

6.5.6　系统测试计划　96

6.5.7　需求和系统测试计划审查　97

6.5.8　需求更新　97

6.5.9　用户srs评审　97

6.5.10　需求基线　97

6.5.11　出口准则　98

6.6　小结　98

6.7　参考文献　98

第7章　与团队一起设计　99

7.1　设计原则　100

7.2　在团队中设计　100

7.2.1　利用整个团队　100

7.2.2　设计研究　101

7.2.3　利用所有团队成员的才智　101

7.3　设计标准　102

7.3.1　设计表达标准　102

7.3.2　用例或psp操作场景　103

7.3.3　状态机分析　103

7.3.4　产生精确的设计　103

7.4　复用性设计　104

7.4.1　可复用接口标准　104

7.4.2　可复用文档标准　104

7.4.3　可复用部件质量　105

7.4.4　应用支持　105

7.5　可用性设计　105

7.6　可测试性设计　106

黑盒测试与白盒测试　106

7.7　设计评审和审查　106

审查的其他好处　107

7.8　tspi设计脚本　107

7.8.1　入口准则　110

7.8.2　高层设计　110

7.8.3　设计标准　110

7.8.4　产品总体结构　110

7.8.5　设计任务分配　112

7.8.6　设计规格说明书　113

7.8.7　集成测试计划　113

7.8.8　设计审查　113

7.8.9　设计更新　113

7.8.10　设计基线　114

7.8.11　出口准则　114

7.9　小结　114

7.10　参考文献　115

第8章　产品实现　116

8.1　设计完成准则　116

8.1.1　设计级别　116

8.1.2　平行实现　117

8.2　实现标准　117

8.2.1　标准评审　117

8.2.2　编码标准　118

8.2.3　规模标准　118

8.2.4　度量其他类型产品的规模　119

8.2.5　缺陷标准　119

8.2.6　缺陷预防　120

8.3　实现策略　121

8.3.1　实现策略：评审　121

8.3.2　实现策略：复用　122

8.3.3　实现策略：测试　122

8.4　评审和审查　122

8.4.1　随机缺陷　122

8.4.2　对测试的影响　123

8.4.3　完全测试的困难　123

8.4.4　源程序的设计审查　123

8.5　imp脚本　124

8.5.1　入口准则　127

8.5.2　实现计划　127

8.5.3　详细设计与设计评审　127

8.5.4　测试开发　128

8.5.5　详细设计审查　128

8.5.6　编码及代码评审　128

8.5.7　代码审查　129

8.5.8　单元测试　129

8.5.9　组件质量评审　129

8.5.10　组件发布　133

8.5.11　出口准则　133

8.6　小结　133

8.7　参考文献　134

第9章　集成与系统测试　135

9.1　测试原则　135

9.2　tspi测试策略　136

9.3　构建和集成策略　137

9.3.1　大爆炸策略　137

9.3.2　一次一个策略　137

9.3.3　测试群策略　137

9.3.4　扁平系统策略　138

9.4　系统测试策略　138

可选系统测试策略　138

9.5　测试计划　139

9.6　跟踪与度量测试　140

9.6.1　测试日志　140

9.6.2　缺陷易发模块　141

9.6.3　模块缺陷数据　142

9.6.4　跟踪缺陷数据　142

9.7　文档　143

9.7.1　文档的重要性　143

9.7.2　文档设计　143

9.7.3　文档提纲　144

9.7.4　书写风格　144

9.7.5　文档评审　145

9.8　tspi测试脚本　145

9.8.1　入口准则　149

9.8.2　测试开发　149

9.8.3　构建　149

9.8.4　集成　150

9.8.5　系统测试　150

9.8.6　回归测试　151

9.8.7　文档　151

9.8.8　出口准则　151

9.9　小结　151

9.10　参考文献　152

第10章　结项总结　153

10.1　为什么要进行结项总结　153

10.2　结项总结能为你做什么　153

10.3　过程改进建议　154

10.4　tspi结项总结脚本　154

10.4.1　入口准则　157

10.4.2　评审过程数据　157

10.4.3　质量评审　158

10.4.4　角色评估　158

10.4.5　准备周期报告　159

10.4.6　周期报告　159

10.4.7　角色报告　159

10.4.8　工程师个人报告　160

10.4.9　撰写报告　160

10.4.10　角色评估　160

10.4.11　角色评估建议　162

10.4.12　出口准则　162

10.5　小结　163

10.6　参考文献　163

第三部分　团队角色

第11章　团队领导角色　167

11.1　团队领导的目标　167

11.1.1　团队成员的共同目标　167

11.1.2　团队领导的目标1　168

11.1.3　团队领导的目标2　168

11.1.4　团队领导的目标3　168

11.1.5　团队领导的目标4　169

11.1.6　团队领导的目标5　169

11.2　有用的团队领导的技能和能力　169

11.2.1　有拥护者的领导　170

11.2.2　领导需要表现　170

11.2.3　领导需要面对困境　172

11.2.4　领导处理人际关系　172

11.3　团队领导的主要活动　172

11.3.1　团队领导的主要活动1　173

11.3.2　团队领导的主要活动2　176

11.3.3　团队领导的主要活动3　176

11.3.4　团队领导的主要活动4　176

11.3.5　团队领导的主要活动5　177

11.3.6　团队领导的主要活动6　178

11.3.7　团队领导的主要活动7　181

11.3.8　团队领导的主要活动8　181

11.4　团队领导的项目工作　181

11.5　小结　181

第12章　开发经理角色　183

12.1　开发经理的目标　183

12.1.1　团队成员的共同目标　184

12.1.2　开发经理的目标1　184

12.1.3　开发经理的目标2　184

12.2　对开发经理有益的技能和能力　185

12.3　开发经理的主要活动　187

12.3.1　开发经理的主要活动1　187

12.3.2　开发经理的主要活动2　188

12.3.3　开发经理的主要活动3　188

12.3.4　开发经理的主要活动4　189

12.3.5　开发经理的主要活动5　189

12.3.6　开发经理的主要活动6　190

12.3.7　开发经理的主要活动7　191

12.3.8　开发经理的主要活动8　191

12.3.9　开发经理的主要活动9　193

12.3.10　开发经理的主要活动10　194

12.3.11　开发经理的主要活动11　194

12.4　开发经理的项目活动　194

12.5　小结　194

第13章　计划经理角色　196

13.1　计划经理的目标　196

13.1.1　团队成员的共同目标　196

13.1.2　计划经理的目标1　197

13.1.3　计划经理的目标2　197

13.2　对计划经理有益的技能和能力　198

13.3　计划经理的主要活动　198

13.3.1　计划经理的主要活动1　199

13.3.2　计划经理的主要活动2　201

13.3.3　计划经理的主要活动3　201

13.3.4　计划经理的主要活动4　204

13.3.5　计划经理的主要活动5　207

13.3.6　计划经理的主要活动6　208

13.4　计划经理的项目活动　208

13.5　小结　208

第14章　质量和过程经理角色　209

14.1　质量和过程经理的目标　209

14.1.1　团队成员的共同目标　209

14.1.2　质量和过程经理的目标1　210

14.1.3　质量和过程经理的目标2　210

14.1.4　质量和过程经理的目标3　211

14.1.5　质量和过程经理的目标4　212

14.2　对质量和过程经理有益的技能和能力　212

14.3　质量和过程经理的主要活动　213

14.3.1　质量和过程经理的主要活动1　214

14.3.2　质量和过程经理的主要活动2　214

14.3.3　质量和过程经理的主要活动3　214

14.3.4　质量和过程经理的主要活动4　215

14.3.5　质量和过程经理主要活动5　215

14.3.6　质量和过程经理的主要活动6　216

14.3.7　质量和过程经理的主要活动7　218

14.3.8　质量和过程经理的主要活动8　218

14.3.9　质量和过程经理的主要活动9　218

14.4　质量和过程经理的项目活动　219

14.5　小结　220

第15章　支持经理角色　221

15.1　支持经理的目标　221

15.1.1　团队成员的共同目标　221

15.1.2　支持经理的目标1　222

15.1.3　支持经理的目标2　222

15.1.4　支持经理的目标3　222

15.1.5　支持经理的目标4　223

15.2　对支持经理有益的技能和能力　223

15.3　支持经理的主要活动　223

15.3.1　支持经理的主要活动1　223

15.3.2　支持经理的主要活动2　224

15.3.3　支持经理的主要活动3　224

15.3.4　支持经理的主要活动4　225

15.3.5　支持经理的主要活动5　225

15.3.6　支持经理的主要活动6　226

15.3.7　支持经理的主要活动7　227

15.3.8　支持经理的主要活动8　227

15.4　支持经理的项目活动　227

15.5　小结　229

第四部分　使用tspi

第16章　管理自我　232

16.1　责任心　232

16.1.1　一个失败的项目　232

16.1.2　履行责任　233

16.1.3　决不放弃　233

16.1.4　面对现实　234

16.1.5　负责任所带来的风险　234

16.1.6　陈述事实　234

16.1.7　事实往往是可以争议的　235

16.2　目标导向性　235

16.2.1　着眼于日程表　235

16.2.2　目标提供了工作重点和优先级　236

16.2.3　你想让我做什么？　236

16.3　原则性　237

16.3.1　不与团队中其他人合作　237

16.3.2　如何遵循处事的几个原则　237

16.4　小结　240

16.5　参考文献　240

第17章　在团队中工作　241

17.1　具有凝聚力的团队　241

17.2　团队工作的责任　242

17.3　团队成员间的沟通　242

17.3.1　可见性　242

17.3.2　聆听　242

17.3.3　协商　243

17.3.4　为什么有原则的协商是有效的　244

17.3.5　花费足够的时间　245

17.4　作出和履行承诺　245

17.4.1　负责的承诺　245

17.4.2　做出承诺　246

17.5　参与团队活动　246

17.5.1　勇于发表自己的看法　246

17.5.2　支持坚持己见的人　247

17.5.3　唤起别人的注意　247

17.5.4　对他人的意见要给予关注　247

17.6　团队建设的责任　248

17.7　接受并承担团队所分配的角色　248

17.8　建立并努力完成团队目标　249

17.9　建立和维护团队　249

17.9.1　难以相处的团队成员　250

17.9.2　院校团队的问题　250

17.9.3　寻求帮助　251

17.9.4　支持　251

17.10　小结　251

17.11　参考文献　252

第18章　团队工作　253

附录a　tspi采样练习的要求说明　256

a.1　目的　256

a.2 “变化计数器”功能要求说明　256

a.3 “程序分析器”功能要求说明　259

a.4　参考文献　260

附录b　软件配置管理　261

b.1　软件配置管理问题　261

b.2　软件配置管理概要　262

不需要的项　262

b.3　scm计划　262

b.3.1　配置标识计划　262

b.3.2　配置控制规程　263

b.3.3　配置控制委员会　263

b.3.4　变更申请表　263

b.4　系统基线　265

b.4.1　基线提交　265

b.4.2　备份规程　266

b.4.3　配置状态报告　266

b.5　scm过程自动化　267

b.6　软件配置管理过程　267

b.6.1　第一步：制定scm计划　269

b.6.2　第二步：管理系统基线　269

b.6.3　第三步：管理变更　270

b.6.4　第四步：报告scm状态　271

附录c　软件审查　272

c.1　什么是审查　272

c.1.1　审查是如何进行的　272

c.1.2　评审的时机　272

c.1.3　使用规定的审查程序　273

c.2　什么使审查有效　273

c.2.1　审查整个程序　273

c.2.2　集思广益　273

c.2.3　采取不同的视角　273

c.2.4　提供发现错误的机会　274

c.2.5　全面测试的重要性　274

c.2.6　只审查经个人评审过的产品　274

c.3　审查方法　274

c.3.1　检查单　275

c.3.2　视角　275

c.3.3　产品侧重点　275

c.3.4　审查实践　276

c.4　审查数据　276

c.4.1　审查速率　276

c.4.2　评审占开发比率　276

c.4.3　审查收益　277

c.5　审查报告：ins表　277

c.6　估算遗留的缺陷数　280

c.6.1　估算总数　280

c.6.2　估算程序中的缺陷数　280

c.6.3　软件审查中的捕获-重捕获方法　280

c.6.4　2个工程师的估算范例　281

c.6.5　3个工程师的估算范例　282

c.6.6　注意　284

c.6.7　一些改进　284

c.7　具有高个人审查收益的重要性　285

c.8　安排审查时间　285

c.9　tspi审查脚本　286

c.9.1　入口准则　287

c.9.2　计划审查工作　287

c.9.3　召开审查介绍会　288

c.9.4　评审产品　288

c.9.5　召开审查会议　288

c.9.6　遍历产品　288

c.9.7　估算遗留缺陷数　289

c.9.8　总结审查会议　289

c.9.9　修改产品，验证缺陷修复　289

c.9.10　出口准则　289

c.10　参考文献　290

附录d　tspi脚本　291

附录e　角色脚本　319

附录f　tspi表格及其使用说明　333

附录g　tspi标准与规格说明　379

译者序

人民邮电出版社邀请我们重新翻译《团队软件过程》 (Introduction to the TeamSoftware Process)这本书，我们欣然答应了。该书面向软件工程师和团队管理者而写，将软件工程与管理方法很好地融合在一起，具有很强的实践指导意义。该书集成了软件工程、估算、计划与跟踪、质量管理和自我指导团队的概念，使之更容易结合一个组织机构内的现有实践。TSP适合大多数业务开发和技术，可以在小周期、螺旋增量式周期或者在瀑布模型中迭代实施，敏捷而有规范地管理，正是适合当前的开发模式，也更适应小型软件组织机构开发管理的特点。虽然这本书出版了很多年，但是书中的精髓还没有真正为人们理解和掌握。如今TSP在世界范围越来越广泛地被采用，CMU/SEI每年都举办TSP研讨会，提供一个交流TSP实践方法和概念的场所。2010年年会的主题为“改变软件工程的世界”，不得不使我们要加倍关注它在当今软件工程和管理上的价值。

软件开发是一个极具有挑战性的工作。每个项目都可能面临不断变更的需求，进度永远是紧迫的，资源也总是短缺的。在其他行业，工程师是个令人羡慕的职业。而对软件业来讲，大部分的工程师大都以一个受害者的形象在行业中出现，他们陷入困境不能自拔。该书的作者Watts Humphrey说软件工程师要想摆脱这个局面，需要做到四件事：第一，具有正确的态度；第二，适当的技能；第三，要有改进的勇气；第四，富有可信度。TSP/PSP帮助软件工程师做到了。

本书主要是针对开发软件密集型产品的工程团队而写的指导书。使用团队软件过程帮助软件工程师、项目经理和组织机构建立一个成熟和有规范的工程实践，在最短的时间和较低成本条件下生产出安全、可靠的软件。本书对经过Personal Software Process (PSP，个体软件过程)培训后的工程师和学生特别有用，它介绍了TSP和具体的改进软件团队工作需要的具体步骤。TSP不但提高团队绩效，同时也能提高工程师的个人绩效。TSP已经在世界近百家企业采用，如IBM、微软、oracle、Adobe等。据2008年的统计，特别是微软，已经投资大约300万美元在IT公司引进TSP，已经培训了上千名PSP开发人员，超过200个TSP项目。由于微软已经在质量和进度预测方面得到了改善，预计TSP已经为它们节省8400万美元。墨西哥政府自2000年开始，出资支持企业实施TSP。同时TSP是对CMMI模型的补充，提供了最优实践和操作实例来指导团队获得更优的性能绩效。它可以加速实施CMMI各个等级，特别是高成熟度等级，是高性能实施过程改进的最佳途径。TSP已经应用在各种领域的小型和大型组织机构，都取得了相似的结果。例如在企业生产力方面提升了25%，甚至更多；减少成本和进度偏差55+/—10%以下；测试成本和进度减少超过80%。

Watts Humphrey曾经说过，软件是大量的知识智力工作，当人们不理解他们正在做的事的话就很难去管理这些人。自1986年，他将全部精力献身于软件工程领域，努力通过实践有效的管理原则来改变软件软件工程的世界。他创造了个体软件过程(PersonalSoftware Process，PSP)，来帮助软件工程师通过使用有规范的、数据驱动的方式进行自我管理他们的项目。Humphrey获得了举世瞩目的成就，终于在2005年荣获美国总统颁发的国家技术奖章。

我们将这本书再版翻译出来，推荐给读者，目的是提供更具体详细的关于小组软件过程的方法和实践，期望将这些方法运用到你的组织机构中，对软件开发和改进产生深刻的影响。本书内容丰富，通俗易懂，实用性强，可作为大学、研究生计算机专业教材，更适合企业中的软件开发团队作为实训和培训的指导教材。

在我国，已有一些企业在实施CMMI前或过程中，将PSP和TSP作为建立实践基础的必要阶梯。PSP和TSP的引入和推广，已经成为培养优秀软件工程师的摇篮。

从国内整体来看，软件工程师的从业专业水准还没有与国际接轨，积极推广PSP和TSP是解决软件开发人才短缺、缩短培养周期的主要途径之一，也是为持续过程改进，提高生产率、软件质量和缩短开发工期的长远之计。

在这本书的翻译过程中，从SEI传来了一个不幸的消息，Watts Humphrey于2010年10月28日与世长辞了，我们为失去这位伟大的行业领袖而遗憾，这个译文也是为了纪念他，希望他的遗产能为中国软件产业的发展和改进造福。

最后，由于我们的水平有限，在本书的翻译中难免有错误或不妥之处，恳请读者批评指正。

吴超英 师春泽 汪浩

2011年3月

前言

这本书是为已经学习并使用过个体软件过程(PSP)的学生和工程师准备的。你可能在研究生课程、高级培训课程或者初级导论课程中学过PSP。或者，你可能是工程师，正在探索如何在实际的团队工作环境中应用PSP。不论是哪种情况，只要你学过PSP，你就具备了使用本书中的方法和实践的基础。

学习过PSP之后，你可能需要指导，以便弄清如何将它应用于软件过程的诸多任务上。这就是团队软件过程(TSP)的主旨：为在软件开发领域中应用成熟的工程学方法提供一个框架。

关于团队协作有很多东西可讲，本书只涵盖了最基本的内容。TSPi(团队软件过程导论)介绍了团队的概念，组建团队的基本步骤，以及在团队中工作的方法。但是要注意，本书是为导论课程设计的，并没有涵盖在大规模工业项目中使用TSP的全部资料。

TSPi是如何帮助工程师的

本书向工程师介绍有关软件开发团队协作的内容。TSPi提供了一系列结构化的步骤，告诉工程师每一步该做什么，并且详细阐述了如何将这些步骤连接起来以开发完整的产品。TSPi还提供了两个饶有趣味且相对具有挑战性的项目练习，每个练习都具有适当的规模。既不过大，以保证在几周之内可以完成：也不过小，以保证可以模拟典型的小规模项目。如果有能力的工程师遵循本书的指导，那么他们一定能开发出完整的工作产品。

在本书建议的TSPi策略中，团队在两到三个周期内开发一个产品。在第一个周期内，团队构建工作产品内核。在后续的每个周期内，逐渐向内核加入新功能。这种策略体现了使用历史项目数据来制定新项目计划的好处。另外，由于在每个周期中都有新的角色，工程师们可以在一个项目中就经历两到三种不同类型的工作。经过几个开发周期后，工程师们就会对团队协作方法有一个广泛的了解，这样一来，他们就更有可能在自己将来的工作中继续使用TSPi方法。

为何要学习TSPi课程

经实践证明，在培养软件工程专业的学生方面，项目课程是行之有效的，因此，越来越多的大学开始开设相关课程。这些课程很受学生欢迎，修习人数一般都会超过预期。学生想学习可应用于将来工作的知识，而团队训练课程正好满足了他们的需要。毕业后的学生及其雇主普遍反映，软件项目课程为实际工作打下了良好的基础。

现在，在团队项目课程方面，已经有很多有益的实践。尽管大多数此类课程都是成功的，但普遍有三个问题：第一，学生经常去尝试过大的项目；第二，他们大多只强调产品而忽略了过程；第三，总有一些成员会破坏团队气氛。虽然TSPi不能完全避免这些问题，但它提供了有关避免这些问题或减少这些问题影响的有益指导。

为了高效利用课程时间，团队软件课程应该精心组织，并且要基于经实践证明的项目经验。如果没有明确定义的过程或结构化的团队框架，工程师就必须自己决定该如何完成项目。如果没有过程和框架，工作组就必须自己学习团队建设和团队协作的基本要素，而这一过程通常都会伴随着痛苦的尝试和失败。显然，这样做代价高昂并且没有必要，因为团队协作的原则通常众所周知、简单明了。

TSPi以行之有效的团队协作方法训练工程师，首先帮助他们熟悉团队建设的过程，然后指导他们使用经过明确定义和度量的框架来开发产品。在经过PSP训练的前提下，工程师一般都能遵循TSPi脚本步骤，并使用TSPi支持工具来计划和管理自己的工作。遵循TSPi的指导，项目工作会变得更有效率，工程师也可以更加专注于学习软件工程，而不是在团队建设和团队管理方面花费大量的时间。

TSPi明确定义了团队角色，每个团队成员都要以某种角色进行工作。每个角色都有详细说明，指出这个角色应该做什么，何时以及如何去完成任务。在每个团队成员都知道他们自己和其他人应该做什么的情况下，他们就能更好地作为一个团队高效工作。如果一个团队成员没有完成工作，其他团队成员就会知道相关情况，从而及时地采取措施处理相关问题。如果团队不能独立解决人际关系问题，他们可以求助于教师或管理人员。本书的教师手册给出了处理很多常见的团队协作问题的有效方法。

如果学生团队成员担任明确的角色和职责，并使大家都了解，教师就能给出更加公平和详细的成绩。除了给整个团队打分，还可以给每个人的表现打分。这不仅激励学生表现得更好，同时也是一种更公平的给团队训练课程打分的方式。

本书组织结构

本书是为引导团队学习TSPi过程而设计的。前两章(第一部分)是简介，第二部分阐述了完整的团队开发周期。书中详细解释了过程脚本，并且给出了TSPi表格的完整示例。

第三部分给出了TSPi团队成员角色的详细说明：团队领导、开发经理、计划经理、质量和过程经理，以及支持经理。当阅读有关每个角色的章节后，你可以将TSPi角色脚本作为工作参考。

TSPi课程伊始，每个学生都要填写一个INFO表格(见附录F)，这个表格记录了有关学生兴趣和背景的信息。教师根据这些信息将整个班级划分为5人小组，再给每个小组成员分配初始角色。如果个别小组有4或6个人，教师就必须对角色进行适当调整。每个角色都要有人担任，每个工程师必须担任至少一个角色。对于一个4人的小组，支持经理角色的任务要在所有小组成员间分摊。对于一个6人小组，质量和过程经理角色要分割为两个角色：质量经理和过程经理。

选择团队成员并进行角色分配之后，各个团队就启动各自的项目，并定期汇报项目进展。每个开发周期结束时，工程师要评估团队的整体表现和每个角色的个人表现。基于这些信息，教师就能评估每个团队和每个人的工作，并且在后续的开发周期中更好地分配角色。如果有必要，教师可以对团队的人员组成进行调整，但是，除非出现了严重问题，否则团队的人员组成应该在整个课程中保持稳定。

使用标准及预定义的问题

尽管TSPi可以应用于各类项目，但本书只提供了两个标准和预定义的问题，它们是为满足课程多样性的要求而专门设计的。虽然使用真实的客户需求也有好处，但是，因为以下三个原因，我们不推荐这样做。第一，课程有严格的进度要求。虽然多数客户一开始都同意按照固定的时间表推进项目，但是很少有客户真正知道开发软件需要多长时间。另外，因为入门工程师一般不知道如何按照严格的进度来管理项目，所以项目失败的几率是很高的。这个问题的根源在于，实际的客户需求大多既不够清晰也不稳定，导致频繁变更和大量延期。

.　第二，团队协作课程应该为特定主题而设计。虽然开发工作产品是项目的目标之一，但是本课程的主要目的是展示使用成熟的软件工程方法的好处。对于真实的客户需求，满足客户要求永远都是最高优先级。一旦需求变更或客户插进来回答问题，工作就会延期，进度就会压缩，导致团队经常把精力集中在完成产品上，而忽略了过程。从结果来看，事与愿违，我们从这类课程中得到的主要经验就是如何避免开发软件。

第三，使用标准及预定义的问题，有助于比较各团队的表现。同样的需求有不同的实现方式，所有的团队都可以加入课程评价。每个团队都可以介绍自己的方案，解释有关设计、实现和测试的问题。这个过程能够充分体现出各种开发方案的实际效果，同时也为评价将来的团队提供了参考数据。

虽然使用预定义的标准练习具有很多好处，但是这也让学生没有机会接触某些重要问题。例如，如果没有实际经验，就很难察觉用户需求描述的混乱和模糊。应付模糊和多变的需求是一种重要的经历，但是这可以在专门讲授需求过程的课程中进行详细学习。本书采取这种方案，首先是要讲授高效的团队协作和过程方法，然后，在后续课程中集中研究大规模开发项目中的复杂问题。

给教师的建议

本书可以多种方式使用。最主要的用法就是作为一学期或两学期的团队训练课程的教材。这种情况下，TSPi可用来开发一个单独的产品，例如附录A中介绍的两个产品之一。一学期的课程大概有2—3个周期，而两学期的课程大概有3个或者更多的周期，以开发更大规模的产品或者附录A中产品的完整版本。过程步骤可根据项目工作的规模进行适当增加和减少。表P1、P2、P3给出了3种课程方案。

在表P1所示的每个开发周期内，团队计划并跟踪每一步工作，最终完成一个完整的小型项目，包括需求、设计、编码和测试。在每个开发周期结束时，团队评估整个团队和每个角色的表现，之后，教师重新分配团队角色。在一个包含3个开发周期的项目中，工程师们实质上获得了3个完整项目和3种不同团队角色的经验。同时，他们也得到了每个开发周期的数据，在每个开发周期中，他们都可以学习如何使用从前面的开发周期中获得的经验。

本书还可在其他课程中作为团队协作练习来使用。小型项目可以在3～7周的单个开发周期中完成，例如，简单的需求开发周期大概需要3～4周，设计开发周期大概需要四周或五周，而最短的完整开发项目可能需要6周或7周。表P2展示了一个时间跨度为几周的，开发一系列需求的团队项目。类似地，表P3展示了一个设计项目。本书还可用于半个学期的课程教学，这样一来，完整的3个周期的课程需要15周，两个周期的课程需要11周，单个周期的开发项目只需要7周。

不管采用哪种课程方案，标准TSPi脚本都将指导学生成立团队、计划并实施项目。除非团队已经有过TSPi课程经历，否则任何团队都不太可能在少于3周或4周的时间内完成任何一个项目周期。原因在于，新的团队成员需要时间去学习团队过程，还要学会如何作为一个团队一起工作。这也是第一个TSPi周期需要7周时间，而后续周期只需要4周时间的原因所在。

学习本课程的基础

本课程的主要先修课是PSP课程，无论在研究生课程中或在PSP导论课程学习过都可以。如果学生是在几个学期以前学习的PSP，则要求他们在最近的课程中使用过PSP，否则，他们就需要一到两节课来回顾一下PSP计划、数据收集和质量管理的相关知识。如果学生使用PSP的经验不足或者根本没有用过PSP，那么就需要在整个课程期间对他们进行仔细的指导和帮助。

在尝试团队项目以前，学生应该具有软件设计和软件需求的知识背景，配置管理、项目管理和软件测试的相关知识和经验也会很有帮助。另外，学生还必须熟练掌握一门编程语言，熟练使用编程工具。

Watts S.Humphrey

Sarasota,Florida