PSP、TSP 与CMMI：发展历史
CMM与PSP
在20 世纪80 年代后期到90 年代早期，SEI 开发了能力成熟度模型（CMM），为软件开发总结了
组织级的最佳实践。SEI 特别会员Watts Humphrey 决定将CMM 的基本原理应用于单个开发人员
的软件开发实践中。个人软件过程（PSP）就是他努力的成果，为单个软件开发人员设计的CMM
五级过程。
CMM与TSP
不久大家就发现，虽然使用PSP 可以取得优异的结果，但是如果周围的环境不能鼓励并且要求遵
守PSP 实践，这些必要的规范性是几乎不可能得到维持的。所以汉弗莱为大多数组织中最小的运
作单位——项目组，开发了团队软件过程（TSP），TSP 是为项目组设计的CMM5 级过程。在一
份SEI 技术报告中，记录了使用TSP 在满足成本和进度估算的同时达到一流质量水平的最新结果
CMM的演变
同时，CMM 的成功也引发了相似模型的开发以覆盖系统工程（SE-CMM）、集成产品开发（IPDCMM）
、软件采购（SA-CMM）以及人力资源（P-CMM）。为了缓解模型数量的过快增长，SEI
使用从未正式发布的CMM 第二版、系统工程CMM 和IPD-CMM 开发了能力成熟度模型集成
（CMMI），
关于PSP
何为PSP?
个人软件过程（PSP）向工程师显示 如何
• 管理其项目质量
• 做出可以实现的承诺
• 改进估算与计划
• 减少产品缺陷
由于人员成本占据了软件开发的70%，所以工程师的技能与工作习惯很大程度决定了软件开发过
程的结果，基于CMM 中发现的实践，PSP 可以被工程师作为指导，帮助建立开发软件的一套结构
化和规范的方法。PSP 是组织计划引入TSP 的前提条件。
PSP 可以被应用于软件开发过程的许多方面，包括
• 小型程序开发
• 需求定义
• 文档编写
• 系统测试
• 系统维护
• 大型软件系统的加强
图一：PSP过程的演化

图二到图四显示了工程师经历的部分收益。图二显示了估算偏差从55%降到27%约两倍的改进。如
图三所示，编译和测试缺陷的改进最为显著。从PSP0级到PSP3级，工程师的编译和测试缺陷从每
千行代码110个缺陷降低到20个缺陷，超过5倍。图四显示了尽管计划和质量绩效有了显著改进，工
程师的生产率基本保持常数。
图二：工作量估算结果

图三：质量结果

图四：生产率结果

图五：进度估算错误

PSP 的行业结果
使用PSP的组织数量正在增长，比如微软、Baan、波音、摩托罗拉以及Teradyne. 来自于早期使用者
的数据清楚地展示出PSP培训的收益。图五显示的是来自于佩奥利亚的高级信息服务团队（AIS）
的数据。该团队的成员在项目进行中接受了PSP培训。表格左边三个属性显示的是工程师估算前三
个组件开发所需的星期数。例如组件1，原来的估算是4周，但实际花了20周。平均估算偏差为
394%。PSP培训之后，同一批工程师完成了剩余6个组件。如右边所示，平均估算偏差为-10.6%。
比如组件8，原始估算为14周，实际工作正是在14周内完成。
表格1显示了AIS工程师的一个组产品验收测试的数据。在PSP培训之前，他们验收测试的缺陷数很
大，而且产品一直延误。在PSP培训之后，下一个产品基本按期交付而且只有一个验收测试缺陷。
表格2显示的是9个PSP项目系统测试节约的时间。在表格顶端，显示了几个产品在PSP培训之前的
系统测试时间。底端显示的是同一组AIS工程师在PSP培训之后完成产品的系统测试时间。注意A1
和A2是同一产品的两个部分，所以对于它们的测试是在一个半月内一起完成的
表 1 Acceptance Test Improvement

导入PSP
尽管对PSP的导入可以进行得很快，但也必须做得正确。首先，工程师需要得到合格的PSP讲师培
训。SEI会自己培训或授权PSP讲师提供数量有限的现场PSP培训。也有越来越多的经过SEI培训的
PSP讲师提供商业化的PSP培训。潘树仁，循序咨询客户服务总监，是唯一长驻中国的合格的PSP讲
师。
PSP导入的第二个重要步骤是分组培训。当组织要求志愿者参加PSP培训时，他们只得到PSP技能的
冰山一角，一般对任何项目的绩效都没有什么影响。
第三，有效的PSP导入要求强有力的管理支持。这反过来要求管理层理解PSP，知道他们的工作人
员一旦受训后如何支持他们，并定期监督他们的绩效。没有恰当的管理层的支持，很多工程师逐渐
又回到他们的老习惯。问题是软件经理，象大多数的专业人士一样，当无人注意或关心时，发现很
难持续进行规范的工作。软件工程师需要定期的指导和支持以保持高水平的个人绩效。
最后的问题是即使当一组工程师都是接受过PSP 培训的并得到恰当的支持，他们
还是需要找出如何将他们的个人过程组合到整个团队过程中去的方法。即使在高一
些的CMMI 级别，这也会是一个问题。这也就是为什么SEI 开发团队软件过程
TSP 的原因
关于TSP
什么是TSP?
团队软件过程(TSP), 和个人软件过程结合在一起，帮助高绩效工程师来
• 确保高质量软件产品
• 生产安全的软件产品
• 改进组织的过程管理
工程组使用TSP 将集成团队概念应用到软件密集系统的开发中。一个4 天的启动过程帮助团队和
他们的经理
• 建立目标
• 定义团队角色
• 评估风险
• 制订团队计划
在启动后，TSP 提供一个定义的过程框架用以管理、跟踪和报告团队过程
使用TSP, 组织可以建立自我导向的团队，计划并跟踪他们的工作，建立目标，并拥有他们的过程
和计划。可以是纯软件团队或集成产品团队，3 到20 个工程师
TSP 将帮助你的组织建立一个成熟规范的工程实践，生产安全、可靠的软件。对软件买家和开发
商，TSP 也作为一个新度量框架的基础得到使用
团队软件过程(TSP)扩展和完善CMMI和PSP方法，指导工程师开发和维护团队的工作。它展示如何
建立一个自我导向的团队及如何扮演一个有效团队成员的角色。它还向管理层展示如何指导和支持
这些团队和如何维护一个培养团队高绩效的环境。TSP有5个目标：
• 建立自我导向的团队，计划和跟踪他们的工作，建立目标，并拥有过程和计划。可以是纯软件团
队或集成产品团队(IPT)，3到20个工程师
• 向管理者显示如何教导和鼓励团队和如何帮助他们维持颠峰状态的绩效
• 通过使CMM5级行为成为正常和可预期的行为从而加速软件过程改进
• 为高成熟度组织提供改进指南
• 支持行业团队技能的大学教学
TSP的根本好处是它向工程师展示在成本控制和大胆的进度计划下如何生产高质量的产品。它通过
向工程师展示如何管理自己的工作，并使他们成为计划和过程的主人来实现这一点
TSP 的行业结果
TSP 帮助团队表现得职业化
也许TSP最强大的效果是可以帮助团队管理其工作环境，产品组遇到的最常见问题是不合理的进度
压力。尽管这很正常，也具有破坏性。当团队被迫按照不合理的进度工作时，他们无法制订有用的
计划。他们生成的每份计划都不符合管理层命令的进度要求因此不能接受。结果是他们必须在没有
一个有序的计划指导情况下进行工作。在这样的条件下团队通常要比其他时候花费更多的时间以完
成项目。
TSP团队的职责是尽可能迅速并且有效地制定计划并生产一个高质量产品。相对地，管理层的职责
是及时启动项目并根据需要完成。当相似的项目花了18个月而管理层却要求9个月完成，这明显是
不实际的。9个月之前项目本应启动的时候管理层在哪里？尽管的确有实际的商业需要，项目组的
进度安排只是问题的一部分。在这些情况下，管理层和项目组共同工作并合理确定最有

[1] [2] 下一页