团队软件过程

第一部分　绪论第1章　tspi简介1.1　tspi是什么工程小组为何需要过程1.2　tspi原则1.3　tspi的设计1.3.1　在个体软件过程（psp）的基础上提供一个简单的框架1.3.2　在几个周期内开发产品1.3.3　建立标准的质量和绩效度量1.3.4　为团队和学生提供精确的度量1.3.5　进行角色和团队评阶1.3.6　需要过程规范1.3.7　提供团队问题的指导1.4　tspi的结构和流程周期性开发策略1.5　tspi过程1.6　本书结构和流程1.7　小结第2章　团队软件过程的基本原理2.1　项目为何失败处理压力2.2　常见的团队问题2.2.1　无效的领导力2.2.2　不能做出妥协安排或不善于合作2.2.3　缺少参与2.2.4　拖拉与缺乏信心2.2.5　质量低劣2.2.6　功能多余2.2.7　无效的组员互评2.3　团队是什么2.3.1　团队规模2.3.2　具有凝聚力的团队（jelled team）2.3.3　团队协作的基本条件2.4　建设高效团队2.4.1　团队凝聚力2.4.2　挑战性的目标2.4.3　反馈2.4.4　共同的工作框架2.5　团队如何发展团队如何成为具有凝聚力的团队2.6　tspi如何建设团队2.6.1　目标2.6.2　角色2.6.3　计划2.6.4　沟通2.6.5　外部沟通2.7　小结2.8　参考文献第二部分 tspi过程第3章　启动一个团队项目3.1　为什么需要团队启动过程3.2　团队目标3.2.1　设定目标需要考虑的因素3.2.2　设定团队目标3.2.3　tspi的目标设定3.3　团队成员目标设定团队成员目标3.4　角色目标3.4.1　团队领导目标3.4.2　开发经理目标3.4.3　计划经理目标3.4.4　质量和过程经理目标3.4.5　支持经理目标3.5　tspi启动脚本3.5.1　学生信息3.5.2　产品目标3.5.3　团队分工3.5.4　团队目标3.5.5　团队会议与第一次团队会议3.5.6　数据需求3.5.7　项目开始3.5.8　项目资料库3.5.9　tspi支持工具3.6　小结第4章　开发策略4.1　计划先行4.1.1　承诺之前先计划4.1.2　为本课程制定计划4.2　策略是什么4.3　概念设计4.4　风险管理管理风险4.5　复用策略4.6　策略脚本4.6.1　入口准则4.6.2　建立策略评判准则4.6.3　完成概念设计4.6.4　选择开发策略4.6.5　完成初步规模估算4.6.6　完成初步时间估算4.6.7　评估风险4.6.8　建立策略文档4.6.9　更新开发策略4.6.10　制定配置管理计划4.6.11　出口准则4.7　小结第5章　开发计划5.1　计划的必要性5.1.1　为什么制定计划5.1.2　平衡的计划5.1.3　对照计划跟踪进展5.1.4　详细计划5.1.5　处理未计划任务5.1.6　估算级别5.1.7　实现计划5.2　tspi计划过程5.3　tspi支持工具5.4　开发计划脚本5.4.1　入口准则5.4.2　项目计划步骤2.15.4.3　项目计划步骤2.25.4.4　项目计划步骤3.15.4.5　项目计划步骤3.25.4.6　项目计划步骤4.15.4.7　项目计划步骤4.25.4.8　项目计划步骤55.4.9　项目计划步骤65.4.10　项目计划步骤75.4.11　最后的计划步骤5.4.12　出口准则5.5　跟踪工作情况5.5.1　项目跟踪步骤15.5.2　项目跟踪步骤25.5.3　项目跟踪步骤35.5.4　项目跟踪步骤45.5.5　项目跟踪步骤55.5.6　项目跟踪步骤65.5.7　项目跟踪步骤75.5.8　项目跟踪步骤85.6　质量计划5.6.1　概要比率5.6.2　零缺陷率（pdf）5.6.3　每页缺陷数5.6.4　缺陷数/kloc5.6.5　缺陷比率5.6.6　开发时间比率5.6.7　a/fr5.6.8　评审速率和审查速率5.6.9　缺陷注入率5.6.10　缺陷排除率5.6.11　阶段收益5.6.12　过程收益5.6.13　处理低质量部件5.6.14　出口准则5.7　小结5.8　参考文献第6章　定义需求6.1　需求是什么6.2　为什么需要需求6.3　需求变更需求提取6.4　软件需求规格说明书6.4.1　需求可追溯性6.4.2　平衡工作量6.5　tspi需求脚本6.5.1　入口准则6.5.2　要求陈述评审6.5.3　要求陈述澄清6.5.4　需求任务分配6.5.5　需求文档6.5.6　系统测试计划6.5.7　需求和系统测试计划审查6.5.8　需求更新6.5.9　用户srs评审6.5.10　需求基线6.5.11　出口准则6.6　小结6.7　参考文献第7章　与团队一起设计7.1　设计原则7.2　在团队中设计7.2.1　利用整个团队7.2.2　设计研究7.2.3　利用所有团队成员的才智7.3　设计标准7.3.1　设计表达标准7.3.2　用例或psp操作场景7.3.3　状态机分析7.3.4　产生精确的设计7.4　复用性设计7.4.1　可复用接口标准7.4.2　可复用文档标准7.4.3　可复用部件质量7.4.4　应用支持7.5　可用性设计7.6　可测试性设计黑盒测试与白盒测试7.7　设计评审和审查审查的其他好处7.8　tspi设计脚本7.8.1　入口准则7.8.2　高层设计7.8.3　设计标准7.8.4　产品总体结构7.8.5　设计任务分配7.8.6　设计规格说明书7.8.7　集成测试计划7.8.8　设计审查7.8.9　设计更新7.8.10　设计基线7.8.11　出口准则7.9　小结7.10　参考文献第8章　产品实现8.1　设计完成准则8.1.1　设计级别8.1.2　平行实现8.2　实现标准8.2.1　标准评审8.2.2　编码标准8.2.3　规模标准8.2.4　度量其他类型产品的规模8.2.5　缺陷标准8.2.6　缺陷预防8.3　实现策略8.3.1　实现策略：评审8.3.2　实现策略：复用8.3.3　实现策略：测试8.4　评审和审查8.4.1　随机缺陷8.4.2　对测试的影响8.4.3　完全测试的困难8.4.4　源程序的设计审查8.5　imp脚本8.5.1　入口准则8.5.2　实现计划8.5.3　详细设计与设计评审8.5.4　测试开发8.5.5　详细设计审查8.5.6　编码及代码评审8.5.7　代码审查8.5.8　单元测试8.5.9　组件质量评审8.5.10　组件发布8.5.11　出口准则8.6　小结8.7　参考文献第9章　集成与系统测试9.1　测试原则9.2　tspi测试策略9.3　构建和集成策略9.3.1　大爆炸策略9.3.2　一次一个策略9.3.3　测试群策略9.3.4　扁平系统策略9.4　系统测试策略可选系统测试策略9.5　测试计划9.6　跟踪与度量测试9.6.1　测试日志9.6.2　缺陷易发模块9.6.3　模块缺陷数据9.6.4　跟踪缺陷数据9.7　文档9.7.1　文档的重要性9.7.2　文档设计9.7.3　文档提纲9.7.4　书写风格9.7.5　文档评审9.8　tspi测试脚本9.8.1　入口准则9.8.2　测试开发9.8.3　构建9.8.4　集成9.8.5　系统测试9.8.6　回归测试9.8.7　文档9.8.8　出口准则9.9　小结9.10　参考文献第10章　结项总结10.1　为什么要进行结项总结10.2　结项总结能为你做什么10.3　过程改进建议10.4　tspi结项总结脚本10.4.1　入口准则10.4.2　评审过程数据10.4.3　质量评审10.4.4　角色评估10.4.5　准备周期报告10.4.6　周期报告10.4.7　角色报告10.4.8　工程师个人报告10.4.9　撰写报告10.4.10　角色评估10.4.11　角色评估建议10.4.12　出口准则10.5　小结10.6　参考文献第三部分　团队角色第11章　团队领导角色11.1　团队领导的目标11.1.1　团队成员的共同目标11.1.2　团队领导的目标111.1.3　团队领导的目标211.1.4　团队领导的目标311.1.5　团队领导的目标411.1.6　团队领导的目标511.2　有用的团队领导的技能和能力11.2.1　有拥护者的领导11.2.2

TSP是由“软件质量之父”Watts s．Humphrey提出的一种采用广泛的团队过程。本书是软件工程专业的重要专业课程。　　本书上一版销量达22000册，是国内最有影响力的软件工程译著。 　　本书是美国embry-riddle aeronautical大学为计算机科学系研究生和高年级本科生开设的一门软件工程课的教科书。这本书系统地论述了如何以开发团队的形式来进行软件的开发，并对开发过程作出了具体而详尽的指导，包括团队成员之间的协调、进度的管理、质量的控制等令读者最感兴趣的方面。团队软件过程（修订版）是美国embry-riddle aeronautical大学为计算机科学系研究生和高年级本科生开设的一门软件工程课的教科书。这本书系统地论述了如何以开发团队的形式来进行软件的开发，并对开发过程作出了具体而详尽的指导，包括团队成员之间的协调、进度的管理、质量的控制等令读者最感兴趣的方面。本书内容包括四个部分：第一部分——绪论，包括前两章，是对理论的简单介绍，介绍了什么是tspi、tspi的组织结构等内容。第二部分——tspi过程，包括第3章到第10章，则是整个小组研究周期的详细内容，详细解释了小组软件开发的步骤，并且给出了 tspi完整形式的例子。第三部分——小组角色，包括第11章到第15章，提供了小组成员角色的细致描述：小组领导者、开发经理、计划经理、质量/进度监督经理，以及技术支持经理。第四部分——使用tspi，包括第16章到第18章，讲述了在使用本书的过程中需要注意的一些原则。【作者简介】Watts S. Humphrey，ACM会士，IEEE终身会士，卡内基—梅隆大学软件工程研究所（SEI）的资深研究员，SEI软件过程研究奠基人，SEI软件过程成熟度模型发明人。2005年被授予由美国总统颁发的美国国家技术奖。他曾在IBM工作了长达27年，担任技术研发部门副总裁，掌管IBM所有软件产品的研发工作。他还是PSP和TSP先驱。