PSP

PSP

• 基本概念
  • PSP---Personal Software Process,个体软件过程。是一种个体级用于管理和改进软件工程师个人工作方式的持续改进过程
• PSP中的基本度量项
  • 时间
    • 采用时间日志的方式
    • 番茄工作法（Pomodoro Technique）

    确定你想要干什么

    设定一个25分钟的定时器

    工作，直到定时器时间到：这就是一个"番茄钟"

    休息5分钟，继续下一个番茄钟

    每4个番茄钟做一次长时间的休息

  • 缺陷
    • 任何会引起交付产物所必要的修改。包括文档描述错误，拼写错误，语法错误，逻辑错误等
    • 缺陷类型标准，10个典型的缺陷类型

    Documentation

    • 注释、提示信息等

    Syntax

    • 拼写错误，指令格式错误等

    Build Package

    • 组件版本，调用库方面的错误

    Assignment

    • 申明、变量影响范围等方面的错误

    Interface

    • 调用接口错误

    Checking

    • 出错信息，未充分检验等错误

    Data

    • 数据结构，内容错误

    Function

    • 逻辑错误，指针，循环，计算，递归等方面的错误

    System

    • 配置，计时，内存方面的错误

    Environment

    • 设计，编译，测试或其他支持系统的错误
    • 缺陷日志记录

    方便地统计出缺陷在整个开发阶段引入和消除的状况

    为提升过程质量，更加有效地消除缺陷提供参考

    PSP中有专门的度量指标用于帮助软件工程师了解缺陷注入和消除状况

  • 规模
    • 规模度量方式的选择参考标准

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

    选择的度量方式必须精确定义

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

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

    • 常用的规模度量方式

    代码行（LOC）

    • 可以精确地度量软件产品的规模，也方便开发相应的规模统计工具，但是在项目初始阶段，很难直接估算出程序的代码行

    功能点（FP）

    • 在项目早期容易识别，但是功能点的度量也比较粗略且对于功能点的粒度缺乏一致的理解，不存在可以对功能点进行自动化统计的方法

    PROBE:PROxy Based Estimation,基于代理的估算

    • 寻找一种便于早期规划的规模度量的代理，建立这种代理与精确度量之间的关联关系
• PROBE估算的流程
  • PROBE估算方法主要用来估算待开发过程程序的规模和所需资源
  • 一个典型的PROBE流程
    • 概要设计
    • 代理识别

    类

    方法/函数

    过程

    数据库表格

    • 估算并调整程序规模

    代理规模和程序规模的区别

    由于估算本质上是一种主观判断，因此难免出现偏差，这种偏差不能简单地根据上一次的偏差进行补偿修正

    PSP：通常采用线性回归方法对估算结果进行调整，使得估算结果尽可能准确

    使用线性回归调整规模估算

    使用线性回归调整时间估算

    • 计算预测区间
  • 显著性
    • 描述的是上述两组数据的相关关系出现的偶然性。如果显著性接近1，说明出现这样的相关性是非常偶然的
  • 相关性
    • 相关性描述的是两组变化的数据之间相互关联的程度，通过用字母r来表示。相关性越大越好
• 使用线性回归方法估算程序规模和资源
  • 线性回归调整规模估算
  • 线性回归调整时间估算
• 相对大小矩阵
  • 简单方法
    • 特点：计算简单，但不稳定，随着新数据的加入会造成相对大小矩阵数据的大幅度调整
    • 方法

    将每个方法的代码行数进行排序

    选择最小值作为VS

    选择最大值作为VL

    选择中值作为M

    选择VS与M的均值作为S

    选择VL与M的均值作为L

  • 正态分布
    • 相对稳定，在历史数据基本符合正态分布的情况下，可以给出非常好的相对大小矩阵，但实际上程序规模的分布并不是正态分布的
  • 对数正态分布
    • 更加符合人们对于程序规模的直观感觉，PSP中大部分情况下使用对数正态分布法来对历史数据进行整理，进而获得相对大小矩阵；需要经常维护和更新相对大小矩阵
• 常用的PSP过程质量的度量指标
  • Yield
    • Yield指标用以度量每个阶段在消除缺陷方面的效率
    • Phase Yield=100*(某阶段发现的缺陷个数)/（某阶段注入的缺陷个数+进入该阶段前遗留的缺陷个数）
    • Process Yield=100*(第一次编译前发现的缺陷个数)/（第一次编译前注入的缺陷个数）
    • 典型的缺陷注入阶段

    设计阶段

    编码阶段

    • 典型的缺陷消除阶段

    设计评审

    代码评审

    编译

    单元测试(修改缺陷的过程中有可能引入新的缺陷)

    • Yield是一种事后质量控制手段
    • Yield可以直接通过缺陷日志统计得到，可以清楚地了解缺陷在整个开发过程中被注入和消除的状况，Yield指标越高越好，整个过程的Process Yield，期望值在80以上。
    • Yield估算

    缺陷总数不可知

    指导质量管理

    如果有历史数据，应当充分使用历史数据

    无历史数据估算

    • 将单元测试阶段的Phase Yield设定为50
    • 在测试中每发现一个缺陷，往往意味着还有一个缺陷没有被发现
  • A/FR（Appraisal to Failure Ratio）质检失效比
    • A/FR=PSP质检成本/PSP失效成本

    PSP中定义的失效成本为编译时间和单元测试时间之和

    PSP中定义的质检成本为设计评审时间与代码评审时间之和

    • 理论上，A/FR的值越大，往往意味着越高的质量，过高的A/FR往往意味着做了过多的评审，反而会导致开发效率的下降。作为指南，在PSP中A/FR的期望值为2.0.为了确保较高的质量水平，软件工程师应当花费两倍于编译加测试的时间进行评审工作，评审的对象为设计和代码
  • COQ（Cost Of Quality）质量成本
    • 用来量化质量问题所带来的成本消耗
    • 由三个主要的组成部分

    失效成本

    • 失效分析现象，查找原因，做必要的修改所消耗的成本

    质检成本

    • 评价软件铲平，确定其质量状况所消耗的成本

    预防成本

    • 识别缺陷根本原因，采取措施预防其再次发送所消耗的成本
  • PQI（Process Quality Index）过程质量指标
    • 用以度量PSP过程的整体质量
    • PQI用来全面刻画软件过程质量
    • 它是五个过程质量指标的乘积

    设计质量

    • 设计时间应该大于编码的时间

    设计评审质量

    • 设计评审时间应该大于设计时间的50%

    代码质量

    • 代码评审时间应该1大于编码时间的50%

    代码评审质量

    • 代码的编译缺陷密度应当小于10个/千行

    程序质量

    • 代码的单元测试缺陷密度应当小于5个/千行
    • PQI超过0.4，组件质量往往比较高
  • （Review Rate）评审速度
    • 评审速度是一个用以指导软件工程师开展有效评审的指标
    • 高质量的评审需要软件工程师投入足够的时间进行评审
    • 大量统计数据表明，代码评审速度小于200LOC/小时，文档评审速度小于4Page/小时
  • DRL缺陷消除效率比（Defect-Removal Leverage）
    • 度量的是不同缺陷消除手段消除缺陷的效率
    • 其计算方式是以某个测试阶段（一般为单元测试）每小时发现的缺席数为基础，其他阶段每小时发现的缺陷书与该测试阶段每小时发现的缺陷的比值就是DRL
• PSP四大设计模式
  • 操作规格模板（Operational Specification Template简称OST）
    • 描述系统与外界的交互情形。具体而言，是描述"用户"与特定设计系统的正常情况下的交互。OST可以用来定义测试场景和测试用例，也可以作为和系统用户讨论需求的基础，特别是操作相关的需求描述
    • UML

    用例图

    顺序图

  • 功能规格模板（Functional Specification Template简称FST）
    • 描述了系统对外的静态接口。软件设计人员可以通过FST来定义软件产品的功能
    • UML

    类图

  • 状态规格模板（State Specification Template简称SST）
    • 描述系统的状态信息。SST可以精确定义程序的所有状态，状态之间的转换以及伴随着每次状态转换的动作
    • UML

    状态机图

  • 逻辑规格模板（Logical Specification Template简称LST）
    • 描述了系统的静态逻辑。
• UML与PSP设计模板的关系
  • UML的用例图和顺序图提供了与PSP与OST同样的信息
  • UML中的顺序图和类图所描述的类之间的关系以及对象之间的交互信息在PSP4个设计模板中没有对应的内容
  • UML类图中记录了方法的型构，然而方法的行为没有描述，这一点在PSP的FST中有相应的内容
  • PSP中的LST用以描述程序的静态逻辑，这在UML没有对应的图示方法
  • UML中的状态机图与SST描述的状态图类型，但是SST中描述的关于状态、状态转换条件以及状态转换中的动作没有对应的UML图示方法