软件过程与管理(第2~4章PSP)

第2~4章个体软件过程（PSP）

●个体软件过程（Personal Software Process，简称PSP）：包括了数据记录表格、过程操作指南和规程在内

的结构化框架，个人级用于控制、管理和改进软件工程师个人工作方式的持续改进过程；最早由卡内基梅隆大学软件工程研究所（CMU/SEI）的Humphrey领导开发；与后续的TSP很好的弥补了CMM的缺陷，形成了个体软件工程师、小组再到组织的完整的过程改进体系。

●PSP基本原则

⏹软件系统的整体质量由该系统中质量最差的某些组件所决定；

⏹软件组件的质量取决于开发这些组件的软件工程师，更加确切的说，是由这些工程师所使用的开发过

程所决定；

⏹作为合格的软件工程师，应当自己度量、跟踪自己的工作，应当自己管理软件组件的质量；

⏹作为合格的软件工程师，应当从自己开发过程的偏差中学习、总结，并将这些经验教训整合到自己的

开发实践中，也就是说，应当建立持续地自我改进机制。

●PSP成熟度级别

●PSP过程度量：仅仅考虑最基本的三个度量项，即时间、缺陷和规模，并由这三个基本度量项衍生出数个

统计指标，如PQI、A/FR等。度量时间和度量缺陷见下面给的考题的第1题，缺陷再看一张表书P53表2-2，英文不想改了，需要的看下书对应上就好。

⏹度量规模：PSP对于规模度量没有明确的定义，可以定义并且使用任何合适的规模度量方式；但PSP

对于规模度量方式的选择提供了参考的标准，即

◆选择的规模度量方式必须反映开发成本；

◆选择的度量方式必须精确；

◆选择的度量方式必须能用自动化方法来统计；

◆选择的度量方式必须有助于早期规划；

⏹规模度量这块注意一个问题：代码行（LOC）—分为逻辑行和物理行和功能点（FP）的对比；精确的

度量方式往往不便于早期规划；有助于早期规划的度量往往难以产生精确度量结果；LOC可以很精确的度量软件产品规模，也方便开发相应的规模统计工具，但是，在项目初始阶段，往往很难估算程序的代码行；FP在项目早期容易识别，但是，一来功能点的度量往往比较粗略，而且几乎不存在可以对功能点进行自动化统计的方法。

⏹早期规划问题：PSP使用一种称为代理（Proxy）的方式来解决，寻找一种便于早期规划的规模度量的

代理，建立这种代理与精确度量之间的关系，即PROBE（PROxy Based Esitimation）方法的由来。

●PROBE方法

⏹估算原理：相对大小矩阵，从统计不同用途的房子（不同用途的代码段）数目和其相对大小（规模，

一般为代码行）入手，例子就是建房子的例子，想不起来的话看书P55的表2-5

⏹通用计划框架（如果不能理解这个图再看字书P56，感觉图示记忆容易）

⏹

估算流程

◆这里给出了一堆的公式，个人认为主要理解这个流程，记住2个最基本的公式就可以了，那么复

杂不会手算的。理解下面两个式子里E

都是为代理规模（和最终的计划规模一般是不相等的）。

⏹应用

◆整理历史数据：相关大小矩阵作用很重要，三种计算方法——简单方法、正态分布、对数正态分

布

●简单方法：统计每个方法代码行数，最小的作为VS，最大的为VL，中值为M；S为VS何M

的均值，L为VL和M的均值

●正态分布：选择所有数据均值为M，计算标准差σ；则S = M-σ，VS = M-2σ，L = M+σ，VL = M+2σ

●对数正态分布：和正态对比，小规模的明显比大规模多，且正态可能算出负值，不符实际；

所以，以e为底计算所有数据的自然对数；计算取对数之后的值的均值作为M，计算相应标

准差σ；则S = M-σ，VS = M-2σ，L = M+σ，VL = M+2σ；再取反对数

●对比：简单方法——计算简单，但是，不稳定；正态分布法——相对稳定，在历史数据基本

符合正态分布的情况下，可以给出非常好的相对大小矩阵；对数正态分布法——更加符合人

们对于程序的规模的直观感觉

◆有限历史数据：两个统计学概念，相关性和显著性。前者描述两组变化数据之间相关程度，后者

描述两组数据的相关关系出现的偶然性。公式不用看，记住前面那个写法是r x，y，后面那个通常

记为s，具体的估算规模的方法分类和指标要求看下面给出的试题的第4题或书P62和P63的两

张表

◆处理极端数据：极端数据会造成相关性的假象，此时就需要看显著性这个指标，剔除极端数据重

新选择PROBE方法。

●质量与质量策略

⏹PSP的质量观：PSP中采用了面向用户的视图，定义质量为满足用户需求的程度。

⏹PSP质量策略：用缺陷管理来替代质量管理；高质量产品也就意味着要求组成软件产品的各个组件基

本无缺陷。

⏹不同缺陷消除方式消除缺陷的平均时间：具体的时间不用记，记住缺陷消除的平均代价随着开发过程

的进展会显著增加。

●评审和测试：个人评审（Review）和团队评审（Inspection）在发现缺陷的效率上往往高于系统测试。

⏹测试消除缺陷的典型流程：

◆发现待测程序的一个异常行为；

◆理解程序的工作方式；

◆调试程序，找出出错的位置，确定出错原因；

◆确定修改方案，修改缺陷；

◆回归测试，以确认修改有效

⏹评审消除缺陷的典型流程：

◆遵循评审者的逻辑来理解程序流程；

◆发现缺陷的同时，也知道了缺陷的位置和原因；

◆修正缺陷；

●评审过程质量：接上面的质量策略，各个组件的高质量是通过高质量评审来实现的

⏹评审检查表：一份个性化的用于有效指导软件工程师开展评审活动的表格；两个步骤，建立和维护；

使用

⏹质量指标（这里很值得注意，名词解释和计算都有可能涉及这部分）：Yield、A/FR和PQI见下面给

出的往年考试题的第2题

◆Review Rate：评审速度，恰当不是太快不是太慢；在实践中，代码规模一般以LOC为单位，文档

一般以页（Page）为单位，时间单位为小时，给出统计数据表明的速度，代码评审速度小于200LOC/

小时，文档评审速度小于4Page/小时。

◆Defect-removal Leverage：缺陷消除效率比，DRL，度量不同缺陷消除手段消除缺陷的效率；其计

算方式是以某个测试阶段（一般为单元测试）每小时发现的缺陷数为基础（通常选择单元测试作

为基础），其他阶段每小时发现缺陷数与该测试阶段每小时发现的缺陷的比值就是DRL。

⏹评审其他考虑因素：