软件工程和开发技术第23章 小组软件过程.ppt

第23章 小组软件过程 23.1 TSP的由来与发展　　为了系统地解决软件项目管理问题，美国国防部于1984年在Carnegie-Mellon大学建立了软件工程研究所，1986年开始研究并于1991年提出能力成熟度模型CMM，1989年开始研究并于1994年提出个体软件过程PSP，1994年开始研究并于1998年在CMU/SEI召开的过程工程年会上第一次介绍了TSP草案，于1999年发表了有关TSP的一本书，使软件过程框架形成一个包含CMM、PSP和TSP三者的严密整体。 　　开发TSP的最初的原意是提供一个环境，为受过PSP培训的工程师使用规范方法提供支持。PSP要求工程师们使用统一的规范化工作过程。但是，由于环境的原因，这些工作过程并不总是能够得到坚持。其原因有多种：第一，管理者没有接受过培训，不懂得PSP或者不欣赏它的好处，他们经常反对他们的工程师们在制定计划、进行个人过程复审或收集和分析数据上花费时间；第二，即使有了支持和指导，规范化的工作做起来也是很困难的，没有TSP提供的这些支持和帮助，长时间维持不变的规范工作几乎是不可能的。TSP最初的实际目的就是着眼于解决这些问题。 　　1996年，Watts Humphrey建立了TSP过程的最早的版本。目的是为了提供一个规范的操作过程，帮助工程技术人员持续地做高质量的工作。最原始的TSP过程被称为TSP0，这一过程十分简单。他拿两个工作组来做实验，然后看结果来评价他们的工作情况。第一个TSP0过程是为经过PSP培训的小组设计的，除了小组的直接领导外，小组没有受过其他的培训和指导。　　根据这两个最初的TSP小组的结果分析，实施TSP能够明显地帮助工程技术人员进行曾接受过训练的工作，但是需要更多的指导和支持；另外，管理者要全面地支持TSP过程。在此基础上，一个增强的过程版本TSP1.0很快就被其他的小组试用，在试用过程中，搜集了更多有关进一步提升TSP的必需的过程信息。 　　在接下来的3年中，Humphery开发了另外9种TSP版本。他最初的目标是想了解一下针对通用目标的小组过程能否帮助软件项目工程组更好地完成工作。取得肯定的结论之后，他将研究方向转为简化这个过程，减少它的规模并提供更有效和有用的支持和指导。结果最近的TSP版本比TSP1.0(1996年底)和TSP2.0(1997年初)版本明显小了。　　越来越多的工程组已经使用了TSP过程。TSP中的一些基本方法已经能够被用来协助工程技术人员和管理人员建立有效的小组，使他们能更好地按照这个过程开展工作，实施定期评估，在必要时重新计划工程。不同的原型支持工具也已经被发展用来简化工程师必须要做的计划、数据采集与存储、数据分析和工程报告活动。 23.2 工程协作与工程小组　　几乎所有的工程都要求由小组来进行合作开发。虽然一些小的硬件或软件产品能被单人开发，但是考虑到现在系统的范围和复杂程度以及对开发时间的紧迫要求，使得大部分的工作实际上不可能仅仅由一个人来做。系统开发是一种小组的活动，而小组的工作效率很大程度上决定于他们所采用的工程方法的质量。 　　在工程中，开发小组的活动经常像篮球队的竞赛，所有的成员为一个共同的目标而工作，尽管成员们可能有各种各样的特点，但是必须互相配合、互相协调、互相协作。　　一个软件工程小组不只是恰巧在一起工作的一群人。小组需要公共的过程以规范大家的活动；全组人员需要统一目标；工作组的任务是进行软件开发实践，他们的工作中包含着特定的技巧，需要有效的指导和领导。基于经验，大家知道一些如何指导和领导这个小组的方法，但是了解的并不十分清楚，TSP能够指导技术工作人员管理者开展有效协作，提升小组的过程质量，改善协作状况。 23.3 小组协作的条件　　如前所述，一个小组是具有共同目标的一群人，他们必须为这个目标共同努力，必须具有一个公共的工作框架。一般来说:　　(1) 一个小组最少要由两个人组成。　　(2) 小组成员要为一个共同的目标工作。　　(3) 每个人都被分配一定的角色。　　(4) 小组使命的完成依赖于小组全体成员的努力。 　　关于小组的定义的四个部分都是非常重要的。例如，很明显一个小组必须要多于一个人，并且一个共同的目标也是应该被接受的。然而为什么每个成员必须要有自己的角色这一点好像是不明显的。角色提供了所有权和隶属感觉，它们在怎样完成自身的工作方面帮助、指导小组成员；它们避免冲突、重复的工作和无效的努力；它们以特定的工作环境为基础，按照一定的规程分配不同任务给工作成员。这种规程对于形成一个既有纪律又具有活力的小组来说是一个基本的要求。 　　相互依赖也是小组的一个基本的要素。也就是说，每一个成员的成功都在某种程度上依赖于其他成员的工作的完成