2021-软件质量管理-Lec-5 质量管理

Lec-5 质量管理

1. 经典语录

People are happy to do it wrong and invest the time to fix it, which sometimes never works, as opposed to investing the time to get it right the first time. —— Watts S. Humphrey

2. 质量策略

2.1. 质量概念

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

2.2. 面向用户的质量观

  1. PSP中也采用了面向用户的视图，定义质量为满足用户需求的程度。在这个定义中，就需要进一步明确：
    1. 用户究竟是谁？
    2. 用户需求的优先级是什么？
    3. 这种用户的优先级对软件产品的开发过程产生什么样的影响？
    4. 怎样来度量这种质量观下的质量水平？

2.3. 典型用户质量期望

  1. 这款软件产品必须能够工作
  2. 这款软件产品最好有较快的执行速度
  3. 这款软件产品最好在安全性、保密性、可用性、可靠性、兼容性、可维护性、可移植性等方面表现优异；

2.4. PSP质量策略

  1. 用缺陷管理来替代质量管理
  2. 高质量产品也就意味着要求组成软件产品的各个组件基本无缺陷；

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

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

2.4.2. 评审发现缺陷典型流程

  1. 遵循评审者的逻辑来理解程序流程；
  2. 发现缺陷的同时，也知道了缺陷的位置和原因；
  3. 修正缺陷；
  4. 重要的缺陷关注：注入阶段、消除阶段和根本原因
  5. 用缺陷管理来替代质量管理；
  6. 高质量产品也就意味着要求组成软件产品的各个组件基本无缺陷
  7. 各个组件的高质量是通过高质量评审来实现的；

2.4.3. PSP评审过程质量

  1. 评审检查表
  2. 质量控制指标
  3. 其他因素
    1. 环境
    2. 评审时机
    3. 个人评审和小组评审
    4. 缺陷预防
  4. 个人级别：单元测试和code review，code review优先
    1. 通过评审消除错误所需要的时间更少一些。
    2. 如果测试完成后再进行评审可能就没有那么认真进行评审。

2.4.4. 质量指标之一：Yield

  1. Yield指标用以度量每个阶段在消除缺陷方面的效率。
    1. Phase Yield = 100 * (某阶段发现的缺陷个数)/(某阶段注入的缺陷个数+进入该阶段前遗留的缺陷个数)
    2. Process Yield = 100 * (第一次编译前发现的缺陷个数)/(第一次编译前注入的缺陷个数)；
  2. 例子
阶段 Injected Removed remain Yield
DFD 10 0 10 0
DFD REVIEW 0 4 6 40
CODING 20 2 24 1/13 * 100
CODE REVIEW 0 12 12 50
UNIT 0 12 0 100
  1. Yield体现缺陷消除的效率问题
    1. 上游的问题可以引发更多的问题。
    2. 不能确定单元测试后是否有错误，不可知。
  2. IBM：最后的测试如果发现了一个错误，那么其中一定还有一个错误没有被发现（所以最后的Yield的值为50），修改后如下（没有发现的也按照原本的比例来分）
阶段 Injected Removed remain Yield
DFD 10+4 0 14 0
DFD REVIEW 0 4 10 2/7 * 100
CODING 20+8 2 36 2/19 * 100
CODE REVIEW 0 12 12 1/3 * 100
UNIT 0 12 12 50

2.4.5. 质量指标之二：A/FR

  1. A/FR = PSP质检成本/PSP失效成本；

  1. A/FR控制目标
    1. 理论上，A/FR的值越大，往往意味着越高的质量。
    2. 过高的A/FR往往意味着做了过多的评审，反而会导致开发效率的下降。作为指南，在PSP中A/FR的期望值就是2.0

2.4.6. 质量指标之三：PQI

  1. 5个数据乘积
    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}
  2. PQI与交付后缺陷密度的关系

  1. PQI与集成时缺陷数的关系

  1. PQI的作用
    1. 判断模块质量
    2. 评估项目质量
    3. 为软件改进做依据

2.4.7. 质量指标之四：Review Rate

  1. 评审的速度(Review Rate)是一个用以指导软件工程师开展有效评审的指标
  2. 高质量的评审需要软件工程师投入足够的时间进行评审
  3. 在PSP的实践中，代码评审速度小于200 LOC/小时，文档评审速度小于4 Page/小时
  4. 估算
    1. 估算文档数量
    2. 估算代码数量
    3. 估算评审时间等等

2.4.8. 质量指标之五：DRL

  1. 缺陷消除效率比度量的是不同缺陷消除手段消除缺陷的效率。
  2. 其计算方式是以某个测试阶段（一般为单元测试）每小时发现的缺陷数为基础，其他阶段每小时发现缺陷数与该测试阶段每小时发现的缺陷的比值就是DRL。

2.4.9. 评审的其他考虑因素

  1. 打印后评审往往效果更好
    1. 单个屏幕可以展现的内容比较有限
    2. 评审人员的注意力
  2. 评审时机选择
    1. 编译（UT）之前 VS. 之后
  3. 个人评审和小组评审
    1. 小组评审意义
    2. 先后顺序

2.5. 质量路径 Quality Journey

  1. 为了追求极高的质量，你有哪些手段？
1
2
3
4
5
6
7
8
Step 1：各种测试
Step 2：进入测试之前的产物质量提升
Step 3：评审过程度量和稳定
Step 4：质量意识和主人翁态度
Step 5：个体review的度量和稳定
Step 6：诉诸设计
Step 7：缺陷预防
Step 8：用户质量观——其他质量属性

2.5.1. 设计与质量的关系

  1. 低劣的设计是导致在软件开发中返工、不易维护以及用户不满的主要原因。
  2. 充分设计可以显著减少最终程序的规模，提升质量。（熟练的程序员每10行会注入一个错误）
  3. 设计本身也是一种排错的过程。

2.5.2. PSP 设计过程

2.5.3. 设计什么？

  1. 设计目标程序在整个应用系统中的位置；
  2. 设计目标程序的使用方式；
  3. 设计目标程序与其他组件以及模块之间的关系；
  4. 设计目标程序外部可见的变量和方法；
  5. 设计目标程序内部运作机制；
  6. 设计目标程序内部静态逻辑；

2.5.4. 设计的内容

2.6. PSP设计模板

  1. 操作规格模板（Operational Specification Template， 简称OST）
  2. 功能规格模板（Functional Specification Template， 简称FST）
  3. 状态规格模板（State Specification Template，简称SST）
  4. 逻辑规格模板（Logical Specification Template，简称LST）

2.6.1. PSP设计模板展现的信息

2.6.2. OST

  1. OST描述的是系统与外界的交互，具体而言，是描述“用户”与待设计系统的正常情况和异常情况下的交互
  2. OST可以用来定义测试场景和测试用例，也可以作为和系统用户讨论需求的基础，特别是操作相关的需求描述。

2.6.3. FST

  1. FST描述的是系统对外的接口，这是一种静态信息的描述。
  2. 在FST中提供的典型信息包括类和继承关系，外部可见的属性和外部可见的方法等。
  3. 在使用FST模板的时候，消除二义性非常重要。因此，如果有可能，尽可能用形式化符号来描述方法等行为。

2.6.4. SST

  1. SST可以精确定义程序的所有的状态、状态之间的转换以及伴随着每次状态转换的动作。
  2. 在SST模板中，需要描述如下的信息：
    1. 所有状态的名称；
    2. 所有状态的简要描述；
    3. 在SST中需要使用的参数和方法的名称与描述；
    4. 状态转换的条件；
    5. 状态转换是发生的动作；

2.6.5. LST

  1. LST可以精确描述系统的内部静态逻辑。为了消除描述的二义性，一般建议用伪代码配合形式化符号来描述设计结果。
  2. 在LST模板中，需要描述如下的信息：
    1. 关键方法的静态逻辑；
    2. 方法的调用；
    3. 外部引用；
    4. 关键数据的类型和定义；

2.7. UML常用图

  1. 用例图
  2. 时序图
  3. 类图
  4. 状态机图

2.7.1. UML 与 PSP 设计模板的关系

  1. UML的用例图和时序图提供了与PSP中OST同样的信息；
  2. UML中的时序图和类图所描述的类之间的关系以及对象之间的交互信息在PSP4个设计模板中没有对应的内容；
  3. UML类图中记录了方法的型构，然而方法的行为没有描述，这一点在PSP的FST中有相应的内容；
  4. PSP中的LST用以描述程序的静态逻辑，这在UML没有对应的图示方法；
  5. UML中的状态图与SST描述的状态图类似，但是SST中描述的关于状态、状态转换条件以及状态转换中的动作没有对应的UML图示方法。

2.7.2. 设计的层次

2021-软件质量管理
#课程笔记 #质量 #软件质量管理 #评审 #缺陷
2021-软件质量管理-Lec-5 质量管理
https://spricoder.github.io/2022/01/09/2021-software-quality-management/2021-software-quality-management-Lec-5%20%E8%B4%A8%E9%87%8F%E7%AE%A1%E7%90%86/
作者
SpriCoder
发布于
2022年1月9日
许可协议