05-质量管理

管理定义：目标定义，状态跟踪，纠偏

1. 质量策略

1.1. 质量概念

1. 软件质量为“与软件产品满足规定的和隐含的需求能力有关的特征或者特性的全体”。[ANSI/IEEE STd 729]
2. 软件质量为内外两部分的特性：其外部质量特性面向软件产品的最终用户，其内部质量特性则不直接面向最终用户。 《代码大全》
3. 软件质量为软件产品可以改变世界，使世界更加美好的程度。从用户的角度考察软件质量，用户满意度是最为重要的判断标准。 [Tom Demarco]
4. 软件质量为对人（用户）的价值。这一定义强调了质量的主观性，即对同一款软件而言，不同的用户对其质量有不同的体验。 [Gerald Weinberg]

内部，外部，主观

1.2. 面向用户的质量观

• 面向用户的质量观：定义质量为满足用户需求的程度
  1. 用户是谁？
     • 客户不一定是用户
  2. 用户需求是否有优先级？
     • 和用户对软件的期望有关
  3. 这种用户优先级对软件产品的开发过程产生什么样的影响？
  4. 怎样来度量这种质量观下的质量水平？

软件可工作，可度量：优先级高

• 典型的用户期望
  1. 产品必须能工作
  2. 产品最好有比较快的执行速度
  3. 产品在安全性、保密性、可用性、可靠性、兼容性、可维护性、可移植性等方面表现优异

1.3. PSP质量策略

1. 首先确保基本没有缺陷，在考察其他质量目标
2. 用缺陷管理代替质量管理
   1. 缺陷管理的正当性：如果软件没有缺陷，其他质量属性也会比较好。
   2. 安全，隐私，交互友好等几乎都无法有效管理
3. 高质量产品也就意味着要求组成软件产品的各个组件基本无缺陷
4. 各组件的高质量是通过高质量评审来实现的
   1. 测试是获取质量状态的手段，而不是提高质量的手段
   2. 经验数据：假设项目缺陷综述确定（但我们不知道），测试团队的消除缺陷能力稳定，测试的时候发现一个错误就有一个没发现的错误，所以希望暴露出来的错误越少越好

重视Code Review
一旦缺陷到了系统级，消除成本会很高，所以要在早期消除

1.4. 消除缺陷的典型流程

1.4.1. 测试消除缺陷的典型流程

1. 发现待测程序的一个异常行为
2. 理解程序的工作方式
   • Measure twice, cut once
3. 调试程序，找出出错的位置，确定出错原因
   • 耗时
4. 确定修改方案，修改缺陷
5. 回归测试，以确认修改有效

1.4.2. 评审消除缺陷典型流程

经过适当培训和基类，有经验的评审者可以发现80%左右的缺陷

1. 遵循评审者的逻辑来理解程序流程
2. 发现缺陷，知道缺陷的位置和原因
3. 修正缺陷

评审时机：先评审，再编译

1.5. 质量指标

过程度量：在过程中度量出来数值，根据这个数值还有机会在过程中修正
结果度量：算出来就没法修改

1.5.1. Yield

结果度量
缺陷消除的效率，度量每个阶段在消除缺陷方面的效率，Yield 指标越高越好，Process Yield 我们期望在 80 以上

问题：知道分子，但是不知道分母

设计、编码注入缺陷
评审、测试消除缺陷

1.5.2. A/FR

过程度量
质检失效时间比:理论上 A/FR越大，意味着质量越高，说明评审越充分
2.0是比较理想的值，ASR过大说明开发效率低下

1.5.3. PQI

最全面，123过程，45结果，在一个指标里包含了过程和结果

• 组成：5个数据的乘积，每个分量都在[0,1]内，结果越接近1说明质量越高
  1. 设计质量：设计时间应该大于编码时间
     • min{设计时间/编码时间, 1}
  2. 设计评审质量：设计评审的时间应该大于设计时间的50%
     • min{(2 * 设计评审时间 / 设计时间), 1}
  3. 代码评审质量：代码评审时间应该大于编码时间的50%
     • min{(2 * 代码评审时间)/编码时间 , 1}
  4. 代码质量：代码的编译缺陷密度应该小于10个/千行
     • min{20/(编译缺陷密度 + 10), 1}
  5. 程序质量：代码单元测试的缺陷密度应该小于5个/千行
     • min{10/(单元测试缺陷密度 + 5), 1}
• 用途
  1. 判断模块开发质量
  2. 规划质量活动计划
  3. 过程改进

PQI达到0.4，说明模块很不错
大部分人的PQI都是0

1.5.4. Review Rate

过程度量
评审速度：一个用于指导软件工程师有效评审的指标，高质量的评审需要软件工 程师投入足够的时间进行评审

高质量的评审需要软件工程师投入足够的时间进行评审

在PSP的实践中，代码评审速度小于200LOC/H，文档评审速度小于4 Page/H

1.5.5. DRL

结果度量
缺陷消除效率比值：不同缺陷消除手段消除缺陷的效率

计算：某个阶段每小时消除缺陷个数 / 单元测试每小时消除个数

期望：所有DRL都大于1，即单元测试缺陷个数最少

1.5.6. 其他质量

个人评审和小组评审（标志重捕法）

Z：总缺陷
a 评审者1独立发现的缺陷
b 评审者2发现缺陷
c 评审者2发现的1发现的缺陷

先评审再单元测试：先评审解决一些问题，测试时需要修复的问题少一些，需要的时间也少

1.6. 质量路径

为了追求高质量的手段：

1. 各种测试
2. 进入测试之前的产物质量提升
   • 各种评审
3. 评审过程度量和稳定
   • 评审阶段yield稳定
4. 质量意识和主人翁意识
5. 个体Review的态度和稳定
6. 诉诸设计
   • 终极手段，review测试都用上了还是没达到质量要求
7. 缺陷预防
   • 从这一步开始不是针对特定项目
   • 根据历史项目制定checklist
8. 用户质量观——其他质量属性
   • 前面都是解决缺陷问题，从8开始解决用户质量观的其他质量问题

2. 设计与质量的关系

2.1. 设计的过程

2.2. 设计的内容

完整设计（可评审设计）包含以下4个方面:

	动态信息	静态信息
外部信息	交互信息（服务、消息等）	功能（继承、类结构等）
内部信息	行为信息（状态机）	结构信息（属性、业务逻辑等）

2.3. UML常用图

	动态信息	静态信息
外部信息	用例图，时序图	类图（只有signature，没有实现）
内部信息	状态机图	缺失

2.4. PSP设计模板

	动态信息	静态信息
外部信息	操作，功能	功能
内部信息	状态	逻辑

1. 操作规格模板
   1. 描述系统与外界交互，用于场景描述：也就是用户与待设计系统的正常情况和异常情况下的交互
   2. 定义测试场景和测试用例，用来与用户讨论需求的基础，特别是操作相关的需求描述
   3. 与UML比较：用例图、时序图
2. 功能规格模板
   1. 描述系统的对外接口，是一种静态信息的展现
   2. 提供的典型信息有类和继承关系、外部可见的属性和方法等
   3. 用形式化符号描述方法等行为，消除二义性
   4. 与UML比较：UML类图，但类图的方法行为没有描述
3. 状态规格模板
   1. 精确定义程序的所有状态、状态之间的转换以及伴随着每次状态转换的动作
   2. 包含信息：状态名称、状态描述、参数和方法的名称与描述、状态转换条件、状态转换发生的动作
   3. UML：状态图
4. 逻辑规格模板
   1. 可以精确描述系统中的静态逻辑。
   2. 为了消除描述的二义性，一般用伪代码配合形式化符号来描述设计结果
   3. 包含信息：关键方法静态逻辑、方法调用、外部引用、关键数据的类型和定义
   4. UML没有对应图

2.5. 设计的层次

2.6. 设计验证方法

• 意义
  • 简单评审不足以发现复杂缺陷
• 方法
  1. 状态机验证
  2. 符号化执行验证
  3. 执行表验证
  4. 跟踪表验证
  5. 正确性验证

2.6.1. 状态机验证

PSP的状态机用文本描述

• 检查状态机的完整性和正交性
  1. 完整性：对于状态机中任何一个状态，对应的所有条件组合，下一个状态的转换都有定义
  2. 正交性：对于状态机中任何一个状态，所有下一个状态的转换条件不能相同
• 验证步骤
  1. 检查状态机，消除死循环和陷阱状态
  2. 检查状态转换，验证完整性和正交性
  3. 评价状态机，检验是否体现设计意图

2.6.2. 符号化执行

• 用符号替换关键的变量，带入伪码程序，分析行为
• 优点：
  1. 实施简单，可以给出一般化结果
  2. 适合不复杂的算法，特别是遗漏系统改造中，应用这种方法世界和理解原有的设计
• 缺点
  1. 不适合复杂逻辑的场景
  2. 纯手工验证容易出错

2.6.3. 执行表验证

• 主要争对伪代码：
  1. 识别伪码程序的关键变量；
  2. 构建表格，表格左侧填入主要程序步骤，右侧填入关键变量；
  3. 初始化被选定的变量；
  4. 跟踪被选择的关键变量的变化情况，从而判断程序行为。

伪代码+关键变量
问题：只能检验一个样例

• 优点：实施简单；结果可靠，可用于验证复杂逻辑
• 缺点：每次只能验证一个用例；手工验证比较耗时，容易引入错误
  

2.6.4. 跟踪表

伪代码+关键变量

1. 识别伪码程序的关键变量；
2. 构建表格，表格左侧填入主要程序步骤（伪代码），右侧填入关键变量；
3. 初始化被选定的变量；
4. 识别将伪码程序符号化的机会，并加以符号化；
5. 定义并且优化用例组合；
6. 跟踪被选择的关键变量的变化情况，从而判断程序行为。

2.6.5. 正确性检验

• 用形式化语言描述程序，加以验证和推理
  1. 分析和识别用例；
  2. 对于复杂伪码程序的结构，应用正确性检验的标准问题逐项加以验证；
  3. 对于不能明确判断的复杂程序结构，使用跟踪表等辅助验证