小组软件开发过程
[绝版]
点击看大图基本信息
- 作者： （美）Watts S.Humphrey
- 译者： 韩丹 袁詈
- 丛书名： 软件工程经典系列
- 出版社：人民邮电出版社
- ISBN：7115087636
- 上架时间：2005-2-4
- 出版日期：2002 年10月
- 开本：16开
- 页码：370
- 版次：1-6
- 所属分类：
计算机 > 软件工程及软件方法学 > 软件过程
内容简介回到顶部↑
《小组软件开发过程》(简称“TSPi”)，是美国Embry—Riddle Aeronautica1大学为计算机科学系研究生和高年级本科生开设的一门软件工程课的教科书。这本书系统地论述了如何以开发小组的形式来进行软件的开发，并对开发过程作出了具体而详尽的指导，包括小组成员之间的协调、进度的管理、质量的控制等等令读者最感兴趣的方面。
全书共四个部分：第一部分—绪论，包括前两章，是对理论的简单介绍，介绍了什么是TSPi、TSP2的组织结构等内容。第二部分—TSPi过程，包括第三章到第十章，则是整个小组研究周期的详细内容，详细解释了小组软件开发的步骤，并且给出了TSPi完整形式的例子。第三部分—小组角色，包括第十一章到第十五章，提供了小组成员角色的细致描述：小组领导者、开发经理、计划经理、质量／生产经理，以及技术支持经理。第四部分—使用TSPi，包括第十六章到第十八章，讲述了在使用本书的过程中需要注意的一些原则。全书内容难度适中，全面生动地阐述了软件工程的基本知识。
本书实用性与可读性较强，适用于软件开发项目经理、程序员和一般编程爱好者在开发软件时参考，也可作为高等学校计算机软件工程课程的参考教材使用。
全书共四个部分：第一部分—绪论，包括前两章，是对理论的简单介绍，介绍了什么是TSPi、TSP2的组织结构等内容。第二部分—TSPi过程，包括第三章到第十章，则是整个小组研究周期的详细内容，详细解释了小组软件开发的步骤，并且给出了TSPi完整形式的例子。第三部分—小组角色，包括第十一章到第十五章，提供了小组成员角色的细致描述：小组领导者、开发经理、计划经理、质量／生产经理，以及技术支持经理。第四部分—使用TSPi，包括第十六章到第十八章，讲述了在使用本书的过程中需要注意的一些原则。全书内容难度适中，全面生动地阐述了软件工程的基本知识。
本书实用性与可读性较强，适用于软件开发项目经理、程序员和一般编程爱好者在开发软件时参考，也可作为高等学校计算机软件工程课程的参考教材使用。
作译者回到顶部↑
目录回到顶部↑
第一部分 绪论
第一章 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．1 为什么工程会失败
2．2 常见小组问题
2．2．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．1 为什么工程会失败
2．2 常见小组问题
2．2．1 领导不力
译者序回到顶部↑
信息时代的大潮，冲击着世界的每一个角落。计算机技术的应用，正在越来越多地渗透进人们生活的方方面面。谈起计算机技术的飞速发展，人们通常最容易想到的是硬件制造水平的进步，例如CPU主频的提高，3D显卡性能的飞跃等等。然而，软件业的发展速度也是相当惊人的。软件的编写过程，早已不仅是个把程序员的埋头苦干，而成为了一项现代化大规模生产的产业。微软的Windows 98和Windows 2000源程序多达几亿行。这样大规模的程序，如果没有一套科学的开发机制，不要说提供给用户使用，就是让它“Run”起来，也是不可能的。
我们欣喜地看到，我国的软件产业，也正在蓬勃发展起来，在软件的本地化、民族化方面取得了长足的进步。在其他领域也有了可喜的成就，金山词霸、WPS、超级解霸等等，都是成功的例子。另一方面，中国人在软件方面的才能，也得到了世界的承认，各大软件公司都活跃着中国人的身影。但是，仔细分析国内软件产业的现状，我们不能不承认这样一个事实：那就是，就国内大多数中小软件公司乃至部分大公司而言，软件的开发还处在“手工作坊”阶段，开发过程缺乏科学的计划和管理。可以说，以这样的方式开发软件，不仅效率低下，还会导致软件产品质量的低劣。
《小组软件开发过程》(简称“TSPi”)，是美国Embry-Riddle Aeronautical大学为计算机科学系研究生和高年级本科生开设的一门软件工程课的教科书。
本书作者Watts S．Humphrey教授是软件工程方面的权威，有多年的研究、实践和教学经验。这本书系统地论述了如何以开发小组的形式来进行软件的开发，并对开发过程作出了具体而详尽的指导，包括小组成员之间的协调、进度的管理、质量的控制等，也许是令读者最感兴趣的各个方面。我们把这本书介绍给国内读者，希望能够对广大的软件开发人员尤其是项目经理起到一定的参考作用，也算是为我国软件产业的发展尽一点微薄之力。
由于时间较紧，加之译者水平有限，书中疏漏和不当之处在所难免，敬请读者和专家批评指正。
我们欣喜地看到，我国的软件产业，也正在蓬勃发展起来，在软件的本地化、民族化方面取得了长足的进步。在其他领域也有了可喜的成就，金山词霸、WPS、超级解霸等等，都是成功的例子。另一方面，中国人在软件方面的才能，也得到了世界的承认，各大软件公司都活跃着中国人的身影。但是，仔细分析国内软件产业的现状，我们不能不承认这样一个事实：那就是，就国内大多数中小软件公司乃至部分大公司而言，软件的开发还处在“手工作坊”阶段，开发过程缺乏科学的计划和管理。可以说，以这样的方式开发软件，不仅效率低下，还会导致软件产品质量的低劣。
《小组软件开发过程》(简称“TSPi”)，是美国Embry-Riddle Aeronautical大学为计算机科学系研究生和高年级本科生开设的一门软件工程课的教科书。
本书作者Watts S．Humphrey教授是软件工程方面的权威，有多年的研究、实践和教学经验。这本书系统地论述了如何以开发小组的形式来进行软件的开发，并对开发过程作出了具体而详尽的指导，包括小组成员之间的协调、进度的管理、质量的控制等，也许是令读者最感兴趣的各个方面。我们把这本书介绍给国内读者，希望能够对广大的软件开发人员尤其是项目经理起到一定的参考作用，也算是为我国软件产业的发展尽一点微薄之力。
由于时间较紧，加之译者水平有限，书中疏漏和不当之处在所难免，敬请读者和专家批评指正。
前言回到顶部↑
这本书是为已经学过或是使用过个人软件程序设计(PSP)的学生或工程师们准备的。你可能在本科、高级专科或是早期导论课程中学习过PSP。或者，你也可以是一个曾经在实际工作中研究过PSP的富有经验的工程师。无论如何，只要你掌握了PSP，你就具备了使用本书中方法和实践的背景。
在你学完PSP后，你很可能需要有关如何在软件开发过程的许多任务上应用它的指导。这就是小组软件开发过程(Team Software Process，即TSP)的主旨：在软件开发过程中提供一个用来可靠地应用工程学方法的框架。
关于小组工作有很多内容可讲，这本书涵盖了最基本的内容。TSPi(theintroductory Team Software Process)介绍了小组的概念，按部就班地指导你去创建一个小组，并在小组里工作。但是要注意，这只是一门导论课程，它不可能包含你将来进行大规模产业计划时需要用到的全部资料。
一、TSPi是如何帮助工程师的
这本书将向工程师们介绍协作软件开发的知识。TSPi提供了一整套结构化的步骤，告诉工程师们每一步该怎样做，并且详细阐述了把这些步骤连接起来以完成一个完整的产品的方法。TSPi也提供了两个很有趣味而且有适当的挑战性工程计划练习，每一个都是小到只有几周就能完成、大到可以模仿一个典型的小工程计划。如果有能力的工程师们按照本书中的指导去做，他们一定会做出一个工作成品来的。
在TSPi的策略中，小组在2到3个周期内就可以研制出产品来。在第一个周期中，小组创建出一个小的工作产品内核。在接下来的周期内，再向这个内核上加入新的功能。这个策略体现了使用先前工程数据来规划新的工程的好处。同时，在每一个周期中工程师们都有新的任务，这样在一个工程中每人都可能有两到三次不同的工作经历。几个开发周期过后，工程师们就会对联合协作开发有一个充分的了解，他们也会更加愿意在自己的工作中使用 TSPi。
二、为什么我们要学TSPi这门课程
在培养从事软件工程专业的学生的过程中，工程学课程已经被证明是很有效果的。因此，许多大学现在都开这类课程。而想学这些课程的学生经常都是比开课时要多，学生们收集他们将来工作中可能用到的资料，他们发现，有关协作开发的课程恰好能够满足他们的需要。等他们毕业后，学生和雇主都认为，软件工程课是为将来在产业部门工作的一个良好基础。
现在，对于协作开发工程课程我们已经有不少经验。虽然许多这类的课程是成功的，但普遍有三个问题：第一，学生经常去尝试过于庞大的工程；第二，他们经常只注重结果而忽略过程；第三，总有一个或更多的小组成员闹分裂。虽然TSPi不能完全避免这些问题，但它提供了关于如何避免或消除这些问题的指导。
为了更充分地利用课上时间，小组软件开发课程应当基于已经经过了实践验证的工程，而且必须经过仔细的策划。如果没有详细的操作步骤和现成的小组框架结构，工程师们就只能独立地设计整个过程，使他们的工程计划付诸实施。而且在上述条件下，这些工作小组也不得不在不断地尝试和碰壁过程中去摸索小组创建和协同工作的基本原则。这显然是代价高昂而且很不必要的，因为协同工作的原则本来简单易懂、众所周知。
TSPi教给工程师们的是行之有效的协同工作方法。它从小组创建开始，然后就在开发产品的过程中应用这个标准的框架。只要工程师们有PSP的基础，他们就能按照TSPi的基本原则来对自己的工作进行计划和管理。应用TSPi，可以使工程计划变得更有效率，使工程师们得以在软件开发本身集中精力，而不是在小组创建和管理这类事情上浪费大量时间。
TSPi为小组中每一个成员都提供了确定的角色。每一个角色都有明确的任务，以及每个分计划需要完成的时间。当小组里的每一个成员都知道自己和其他人该做些什么时，他们就可以作为一个有效率的团体来进行工作了。如果某个成员没有完成任务，其他的成员可以了解到这一点，再及时地处理所遇到的问题。当小组自己无法处理个人的问题时，他们就应当向他们的教师或管理人员求助。这本书中的"给教师的话"就提供了许多解决这类常见问题的方法。
当学生小组成员分工明确、责任清楚后，教师就可以公平明确地打分了。每个学生都有个人表现和整体结果两方面的分数等级。这不但可以鼓励学生们创新，同时也是一个给出学科成绩的公平办法。
三、本书的组织结构
这本书是为了使学生掌握TSPi的过程和步骤而设计的。开头两章(第一部分)是对理论的简单介绍。第二部分中的章节则是整个小组研究周期的详细内容。本书详细解释了小组软件开发的步骤，并且给出了TSPi完整形式的例子。
第三部分提供了小组成员角色的细致描述：小组领导者，开发经理，计划经理，质量／生产经理，以及技术支持经理。读过这一部分中有关你个人角色的内容后，你就可以在工作中把书中所介绍的内容作为参考了。
TSPi课程开始的时候，每一个学生都要完成一份介绍个人兴趣和背景的INFO表格。教师将根据这些信息把整个班级分成5个工程小组，再指定每个小组成员的初步角色。如果一或两个小组有4或6个组员，教师就必须作一定的角色调整。所有的角色都要有人充当，而每个工程师必须至少扮演一个角色。对于一个有4名工程师成员的小组，其技术支持经理必须是从组员中选出的；对于有6名工程师成员的小组，质量／生产经理则必须分成两个：质量监督经理和生产监督经理。
小组选好、角色确定之后，各个小组就开始他们的工程计划，并且汇报进度。在每一个开发周期结束时，组内工程师们都要对整个小组的总体表现和各个角色的表现进行评估。根据这些信息，教师就可以对他们的工作作出评价，从而在下一个开发周期中更好地分配小组角色。如果有必要的话，教师还可以进行组间成员调动，但如果没什么严重问题的话，每个小组在整个课程期间是不会有变动的。
四、使用预先设计的标准课题
虽然TSPi可以应用于几乎任何一个工程，这本书只是提供了两个预先设计的标准课题，它们是为满足将来可能遇到的各种情况而设定的。虽然在这里使用面向顾客的实际课题可能有一些好处，但是出于3个原因，我们不推荐这样做。第一，课程本身有严格的时间表，即使大部分顾客起初都可能同意按照固定时间表来进行，也不大可能有几个顾客真正知道开发软件究竟需要多少时间。而且，通常一开始工程师们还不知道该如何依照严格的时间表来管理规划整个工程，工程失败的可能性是很大的。与这个问题同时出现的麻烦是，真正的顾客需求都是不稳定而且很不明确的，这又会导致经常性的变化，耽误大量时间。
在你学完PSP后，你很可能需要有关如何在软件开发过程的许多任务上应用它的指导。这就是小组软件开发过程(Team Software Process，即TSP)的主旨：在软件开发过程中提供一个用来可靠地应用工程学方法的框架。
关于小组工作有很多内容可讲，这本书涵盖了最基本的内容。TSPi(theintroductory Team Software Process)介绍了小组的概念，按部就班地指导你去创建一个小组，并在小组里工作。但是要注意，这只是一门导论课程，它不可能包含你将来进行大规模产业计划时需要用到的全部资料。
一、TSPi是如何帮助工程师的
这本书将向工程师们介绍协作软件开发的知识。TSPi提供了一整套结构化的步骤，告诉工程师们每一步该怎样做，并且详细阐述了把这些步骤连接起来以完成一个完整的产品的方法。TSPi也提供了两个很有趣味而且有适当的挑战性工程计划练习，每一个都是小到只有几周就能完成、大到可以模仿一个典型的小工程计划。如果有能力的工程师们按照本书中的指导去做，他们一定会做出一个工作成品来的。
在TSPi的策略中，小组在2到3个周期内就可以研制出产品来。在第一个周期中，小组创建出一个小的工作产品内核。在接下来的周期内，再向这个内核上加入新的功能。这个策略体现了使用先前工程数据来规划新的工程的好处。同时，在每一个周期中工程师们都有新的任务，这样在一个工程中每人都可能有两到三次不同的工作经历。几个开发周期过后，工程师们就会对联合协作开发有一个充分的了解，他们也会更加愿意在自己的工作中使用 TSPi。
二、为什么我们要学TSPi这门课程
在培养从事软件工程专业的学生的过程中，工程学课程已经被证明是很有效果的。因此，许多大学现在都开这类课程。而想学这些课程的学生经常都是比开课时要多，学生们收集他们将来工作中可能用到的资料，他们发现，有关协作开发的课程恰好能够满足他们的需要。等他们毕业后，学生和雇主都认为，软件工程课是为将来在产业部门工作的一个良好基础。
现在，对于协作开发工程课程我们已经有不少经验。虽然许多这类的课程是成功的，但普遍有三个问题：第一，学生经常去尝试过于庞大的工程；第二，他们经常只注重结果而忽略过程；第三，总有一个或更多的小组成员闹分裂。虽然TSPi不能完全避免这些问题，但它提供了关于如何避免或消除这些问题的指导。
为了更充分地利用课上时间，小组软件开发课程应当基于已经经过了实践验证的工程，而且必须经过仔细的策划。如果没有详细的操作步骤和现成的小组框架结构，工程师们就只能独立地设计整个过程，使他们的工程计划付诸实施。而且在上述条件下，这些工作小组也不得不在不断地尝试和碰壁过程中去摸索小组创建和协同工作的基本原则。这显然是代价高昂而且很不必要的，因为协同工作的原则本来简单易懂、众所周知。
TSPi教给工程师们的是行之有效的协同工作方法。它从小组创建开始，然后就在开发产品的过程中应用这个标准的框架。只要工程师们有PSP的基础，他们就能按照TSPi的基本原则来对自己的工作进行计划和管理。应用TSPi，可以使工程计划变得更有效率，使工程师们得以在软件开发本身集中精力，而不是在小组创建和管理这类事情上浪费大量时间。
TSPi为小组中每一个成员都提供了确定的角色。每一个角色都有明确的任务，以及每个分计划需要完成的时间。当小组里的每一个成员都知道自己和其他人该做些什么时，他们就可以作为一个有效率的团体来进行工作了。如果某个成员没有完成任务，其他的成员可以了解到这一点，再及时地处理所遇到的问题。当小组自己无法处理个人的问题时，他们就应当向他们的教师或管理人员求助。这本书中的"给教师的话"就提供了许多解决这类常见问题的方法。
当学生小组成员分工明确、责任清楚后，教师就可以公平明确地打分了。每个学生都有个人表现和整体结果两方面的分数等级。这不但可以鼓励学生们创新，同时也是一个给出学科成绩的公平办法。
三、本书的组织结构
这本书是为了使学生掌握TSPi的过程和步骤而设计的。开头两章(第一部分)是对理论的简单介绍。第二部分中的章节则是整个小组研究周期的详细内容。本书详细解释了小组软件开发的步骤，并且给出了TSPi完整形式的例子。
第三部分提供了小组成员角色的细致描述：小组领导者，开发经理，计划经理，质量／生产经理，以及技术支持经理。读过这一部分中有关你个人角色的内容后，你就可以在工作中把书中所介绍的内容作为参考了。
TSPi课程开始的时候，每一个学生都要完成一份介绍个人兴趣和背景的INFO表格。教师将根据这些信息把整个班级分成5个工程小组，再指定每个小组成员的初步角色。如果一或两个小组有4或6个组员，教师就必须作一定的角色调整。所有的角色都要有人充当，而每个工程师必须至少扮演一个角色。对于一个有4名工程师成员的小组，其技术支持经理必须是从组员中选出的；对于有6名工程师成员的小组，质量／生产经理则必须分成两个：质量监督经理和生产监督经理。
小组选好、角色确定之后，各个小组就开始他们的工程计划，并且汇报进度。在每一个开发周期结束时，组内工程师们都要对整个小组的总体表现和各个角色的表现进行评估。根据这些信息，教师就可以对他们的工作作出评价，从而在下一个开发周期中更好地分配小组角色。如果有必要的话，教师还可以进行组间成员调动，但如果没什么严重问题的话，每个小组在整个课程期间是不会有变动的。
四、使用预先设计的标准课题
虽然TSPi可以应用于几乎任何一个工程，这本书只是提供了两个预先设计的标准课题，它们是为满足将来可能遇到的各种情况而设定的。虽然在这里使用面向顾客的实际课题可能有一些好处，但是出于3个原因，我们不推荐这样做。第一，课程本身有严格的时间表，即使大部分顾客起初都可能同意按照固定时间表来进行，也不大可能有几个顾客真正知道开发软件究竟需要多少时间。而且，通常一开始工程师们还不知道该如何依照严格的时间表来管理规划整个工程，工程失败的可能性是很大的。与这个问题同时出现的麻烦是，真正的顾客需求都是不稳定而且很不明确的，这又会导致经常性的变化，耽误大量时间。
加载中...
