TSP-团队软件过程

TSP-团队软件过程（Team Software Process） 团队软件过程是为开发软件产品的开发团队提供指导， TSP 的早期实践侧重于帮助开发 团队改善其质量和生产率，以使其更好的满足成本及进度的目标。加上 PSP 帮助高绩效的 工程师在一个团队中工作，来开发有质量保证的软件产品，生产安全的软件产品，改进组织 中的过程管理。 团队软件过程（Team Software Process，简称 TSP）是为开发软件产品的开发团队提供 指导， TSP 的早期实践侧重于帮助开发团队改善其质量和生产率， 以使其更好的满足成本及 进度的目标。TSP 被设计为满足 220 人规模的开发团队，大型的多团队过程的 TSP 被设计 为大约最多为 150 人左右的规模。 团队软件过程(TSP)加上 PSP 帮助高绩效的工程师在一个团队中工作，来开发有质量保 证的软件产品，生产安全的软件产品，改进组织中的过程管理。通过 TSP，一个组织能够建 立起自我管理的团队来计划追踪他们的工作、建立目标，并拥有自己的过程和计划。这些团 队可以是纯粹的软件开发团队，也可以是集成产品的团队，规模可以从 3 到 20 个工程师不 等。TSP 团队在广泛领域里可能运用 XP, RUP 或其它方法。TSP 使具备 PSP 的工程人员组 成的团队能够学习并取得成功。 如果你的组织运用 TSP， 它会帮助您的组织建立一套成熟规 范的工程实践，确保安全可靠的软件。 软件过程控制是软件企业成功的关键， 但过去一直缺乏一套可操作的规范来具体指导和 规范项目组的开发。PSP 和 TSP 为企业提供了规范软件过程的一整套方案，从而解决了长 期困扰软件开发的一系列问题，有助于企业更好地应对挑战。PSP 主要指导软件工程师个人 如何更好地进行软件设计与编码， 关注个人软件工程师的能力的提高， 从而保证个人承担的 软件模块的质量， 对于大型项目中的项目组如何协同工作、 共同保证项目组的整体产品质量 则没有给出任何指导性的原则。个人能力的提高同时需要一个有效地工作在一个团体(小组) 环境，并知晓如何一致创造高质量的产品。为了提高团队的质量及生产能力，更加精确地达 到费用、时间要求，结合 PSP 的原则提出了 TSP 以提高小组的性能，从而提供工程质量。 TSP 能够指导项目组中的成员如何有效地规划和管理所面临的项目开发任务并且告诉管理 人员如何指导软件开发队伍始终以最佳状态来完成工作。 团队软件过程 TSP 基于以下 4 条基本原理：应该遵循一个确定的、可重复的过程并迅 速获得反馈，这样才能使学习和改革最有成效；一个群组是否有效，是由明确的目标、有效 的工作环境、有能力的教练和积极的领导这 4 方面因素的综合作用所确定的，因此应在这 4 个方面同时努力，而不能偏废其中任何个方面；应注意及时总结经验教训，当学员在项目 中面临各种各样的实际问题并寻求有效的解决问题方案时，就会更深刻地体会到 TSP 的威 力；应注意借鉴前人和他人的经验，在可知利用的工程、科学和教学法经验的基础上来规定 过程改进的指令。 在软件开发(或维护)过程中， 首先需要按照群组软件过程框架定义个过程。 在设计TSP 过程时，需要按照以下 7 条原则： 循序渐进的原则，首先在 PSP 的基础上提出一个简单的过程框架，然后逐步完善； 迭代开发的原则，选用增量式迭代开发方法，通过几个循环开发个产品； 质量优先的原则，对按 TSP 开发的软件产品，建立质量和性能的度量标准； 目标明确的原则，对实施 TSP 的群组及其成员的工作效果提供准确的度量； 定期评审的原则，在 TSP 的实施过程中，对角色和群组进行定期的评价； 过程规范的原则，对每一个项目的 TSP 规定明确的过程规范； 指令明确的原则，对实施 TSP 中可能遇到的问题提供解决问题的指南。 在实施群组软件过程 TSP 的过程中，应该自始至终贯彻集体管理与自我管理相结合的 原则。具体地说，应该实施以下 6 项原则： 计划工作的原则，在每一阶段开始时要制订工作 H 划，规定明确的目标； 实事求是的原则， 目标不应过高也个应过低而应实事求是， 在检查计划时如果发现未能 完成或者已经超越规定的目标，应分析原因，并根据实际情况对原有计划做必要的修改； 动态监控的原则， 一方面应定期追踪项目进展状态并向有关人员汇报， 另一方面应经常 评审自己是否按 PSP 原理进行工作； 自我管理的原则，开发小组成员如发现过程不合适，应主动、及时地进行改进，以保证 始终用高质量的过程来生产高质量的软件，任何消极埋怨或坐视等待的态度都是不对的； 集体管理的原则， 项目开发小组的全体成员都要积极参加和关心小组的工作规划、 进展 追踪和决策制订等项工作； 独立负责的原则，按 TSP 原理进行管理，每个成员都要担任一个角色。 在 TSP 的实践过程中， TSP 的创始人 Humphrey 建议在个软件开发小组内把管理的角 色分成客户界面、设计方案、实现技术、工作规划、软件过程、产品质量、工程支持以及产 品测试 8 类。如果小组成员的数目较少，则可将其中的某些角色合并；如果小组成员的数目 较多，则可将其中的某些角色拆分。总之，每个成员都要独立相当一个用色。 软件开发小组按 TSP 进行生产、维护软件或提供服务，其质量可用两组元素来表达； 一组元素用以度量开发小组的素质， 称之为开发小组素质度量元； 另一组用以度量软件过程 的质量，称之为软件过程质量度量元。 开发小组素质的基本度量元有以下 5 项： 所编文档的页数；所编代码的行数； 花费在各个开发阶段或花费在各个开发任务上的时间(以分钟为度量单位)； 在各个开发阶段中注入和改正的缺陷数目； 在各个阶段对最终产品增加的价值。 应该指出， 这 5 个度量元是针对软件产品的开发来陈述的， 对软件产品的维护或提供其 他服务，可以参照这些条款给出类似的陈述。 软件过程质量的基本度量元有以下 5 项： 设计工作量应大于编码工作量； 设计评审工作量应占一半以上的设计工作量； 代码评审工作量应占一半以上的代码编制的工作量； 每千行源程序在编译阶段发现的差错不应超过 10 个； 每千行源程序在测试阶段发现的差错不应超过 5 个。 TSP 由一系列阶段和活动组成。各阶段均由计划会议发起。在首次计划中，TSP 组将制 订项目整体规划和下阶段详细计划。 TSP 组员在详细计划的指导下跟踪计划中各种活动的执 行情况。首次计划后，原定的下阶段计划会在周期性的计划制订中不断得到更新。通常无法 制订超过 3 到 4 个月的详细计划。所以，TSP 根据项目情况，每 3-4 个月为一阶段，并在各 阶段进行重建。无论何时，只要计划不再适应工作，就进行更新。当工作中发生重大变故或 成员关系调整时，计划也将得到更新。在计划的制订和修正中，小组将定义项目的生命周期 和开发策略，这有助于更好地把握整个项目开发的阶段、活动及产品情况。每项活动都用一 系列明确的步骤、精确的测量方法及开始、结束标志加以定义。在设计时将制订完成活动所 需的计划、估计产品的规模、各项活动的耗时、可能的缺陷率及去除率，并通过活动的完成 情况重新修正进度数据。开发策略用于确保 TSP 的规则得到自始至终的维护。图 1 中描述 的只是 TSP 阶段、活动的标准集合，实际的 TSP 更像是分成阶段的众多循环构成的。TSP 过程遵循交互性原则，以便每阶段和循环都能在上一循环所获信息的基础上得以重新规 划。