软件可信性度量

高级软件工程
软件可信性度量 18/30
活动
设计浏览 代码检查 单元测试 功能测试 系统测试

高级软件工程
软件可信性度量 19/30
触发器



设计的一致性 逻辑或流 向下兼容性 水平兼容性 合作性 内部文档 语言依赖性 旁路效应 稀缺情况 简单路径 复杂路径 覆盖范围
软件可信性度量 33/30
Байду номын сангаас
讨论

度量的能力：
– 不同可信性质的需求不同?
– 度量的边界? 哪些是不可度量的？

度量的自动性：
– 如何形式化地描述可信的某个属性 – 代价(时间、空间开销）?

度量的副作用：
– 成本（三聚氰胺） – 负面影响（教学评估）
高级软件工程
软件可信性度量 34/30
谢谢观看！
用性
易分析性 易改变性 稳定性 易测试性
高级软件工程
软件可信性度量 10/30
3、刻度（依据、标准）是什么？
度量对象不同，度量刻度也不同！
产品（制品）
发展过程 分析 设计 编码 集成 部署
维护
高级软件工程
软件可信性度量 11/30
产品（Product）与制品(Artifact)：
产品：最终交付给用户的软件 （主要是代码） 制品：软件生命周期中，所有各个阶段的人工产物 包括： 产品 以及 开发过程中产生的设计模型 分析模型 等等 企业内部称为制品，发布给客户称为产品
高级软件工程
软件可信性度量 7/30
2、度量什么？
软件“可信性”的属性：仍然从“质量”的性质开始！
过程 过程 质量 依赖 影响 内部 质量 属性 软件产品 影响 外部 质量 属性 影响 软件产品的效用 使用 质量 属性
依赖 内部 外部 测量
依赖 使用质量的 测量
使用 条件
过程 测量
测量
目前主要关注产品质量！
高级软件工程
软件可信性度量 17/30
2）软件缺陷分类
IBM ODC（IBM 垂直检测分类）
剔除缺陷的活动:指的是在缺陷被发现时的活动； 触发器：为缺陷到表面存在的环境或条件 ； 影响 目标：代表与固定的实体的高度水平一致性； 缺陷类型：代表做出的准确的纠正； 合格者：捕获不存在，错误或不相关实现，遗失，不正确 或外来的组件； 年龄或状态：指的是基础的，新的，重写的或重固定的内 容。
软件可信性度量 30/30
3）离线代码缺陷度量
是否遵守编程语言规范？ 编译技术 是否遵循低层库的正确使用方式？ 静态分析 重点介绍！ 是否与用户需求一致？ 动态测试
高级软件工程
软件可信性度量 31/30
4）在线服务缺陷度量 服务提供者（内部）； 最终用户（外部）； （具体请见下一页中的表格所示）
高级软件工程

方法自然不同
高级软件工程
软件可信性度量 26/30
经典的软件缺陷度量

缺陷密度——软件缺陷在规模上的分布
如：每KLOC或每个功能点（或类似功能点的度量—— 对象点、数据点、特征点等）的缺陷数

缺陷率——缺陷在时间上的分布
如：对应用软件的角度来说，90%以上的缺陷是在发布 后两年内被发现出来 。

功能性的 依从性
可靠性的 依从性
效率的依 从性
***的依从性：软件产品遵循与***相关的标准、约定或法规以及类 似规定的能力
高级软件工程
软件可信性度量 9/30
软件可信性
功能性
可靠性
安全性
高效性
维护性
可用性
正确性 准确性
（精度、不 少、不多）
成熟性 容错性 易恢复性
机密性 完整性 抗抵赖性
时间特性 的资源利
– 服务提供者；
– 服务使用者；
– 第三方；
刻度也很多！
高级软件工程
软件可信性度量 14/30
软件可信性度量问题 转化为：
在软件生命周期的不同阶段。
模型、代码、服务 是否 与刻度有偏差？ 存在缺陷？
高级软件工程
软件可信性度量 15/30
4、软件缺陷
1）什么是软件缺陷：缺陷、错误、故障、失败， 每个的定义如下解释： 缺陷 (defect) ： 制品（模型、数据、程序） 错误 (error) ： 人 故障 (fault) ： 运行结果(内部,局部) 失败 (failure) ：总体后果（外部）
高级软件工程
外部和内部质量
软件可信性度量 8/30
功能性
可靠性
易用性
效率
维护性
可移植性
适合性 准确性 互操作性
保密安全 性
成熟性 容错性 易恢复性
易理解性 易学性 易操作性 吸引性 易用性的 依从性
时间特性
资源利用 性
易分析性 易改变性 稳定性 易测试性 维护性的 依从性
适应性 易安装性 共存性 易替换性 可移植性的 依从性

可变性 序列 交互 负载或压力 恢复或例外 开机或重启 硬件配置 软件配置 拥堵测试
高级软件工程
安装装置 服务装置 标准 集成性或安全性 转移性 依赖性 性能 文件 要求 维护 可用性 可达性 性能

软件可信性度量 20/30
高级软件工程
软件可信性度量 1/30
软件可信性度量
高级软件工程
软件可信性度量 2/30
可信性是软件性质的子集 软件性质的静态判定问题 本质上是不完备的（图 灵机的判定）。 我们能做的是： 在一定约束条件下 对一些重要的性质给出较准确的度量
在每1000个 发生一个错误的可能性是4.59西格玛。 6西格玛代表在每一百万行代码中发生3.4个错误。

整体缺陷清除率
在软件开发过程中发现的所有缺陷数 /发现的总缺陷数
阶段性缺陷清除率
高级软件工程
软件可信性度量 27/30
2、不同阶段的缺陷度量
1）需求模型缺陷度量 2）设计模型缺陷度量 3）代码缺陷度量 4）在线服务缺陷度量
高级软件工程
软件可信性度量 28/30
1）需求模型缺陷度量



高级软件工程
软件可信性度量 16/30
Prof. Brian Randell: 当传递服务被判决从完全满足系统功能中脱离时，系统 崩溃。 错误是指的导致子错误的系统状态的一部分：一个影响 服务的错误意味着一个系统崩溃发生或者已经发生。对 于一个错误的判定或假设是一个错误。
请注意，错误不一定导致崩溃，这可以由机会或设计来 避免，组件错误不一定会导致周边环境的崩溃。是否会 导致环境崩溃依赖于环境对该组件的依赖性。 无论如何你都应该选择用于它们。
高级软件工程
软件可信性度量 3/30
内容
一、软件可信性度量 二、如何度量软件的可信性？
高级软件工程
软件可信性度量 4/30
一、软件可信性度量
1、测量、度量与指标 2、度量什么？ 3、刻度是什么？ 4、软件缺陷
高级软件工程
软件可信性度量 5/30
1、测量、度量与指示
测量（Measure）是一个过程，用于对产品或者过
性能 性能 可用性 性能
● ●
软件可信性度量 32/30
性能
●
可用性
可信度
●
安装 装置
○
文档 维护
● ●
可达性
●
●
○
○
○
○
●
○
●
○
可用性
安装装 置 维护
●
○
●
○
○
○
○
○
○
●
○
●
○
●
○
●
○
○
文档
可达性
●
○
○
●
○
○
○
○
●: 代表与另外一个冲突, ○: 代表支持另外一个, 空白: 代表不相关
高级软件工程
发布可信度要求 实现可信度规则 分析规则结果 确认规则
高级软件工程
软件可信性度量 24/30
1、基本步骤
质量度量： ISO9126-2：外部度量 ISO9126-3：内部度量 ISO9126-4：使用质量的度量
高级软件工程
软件可信性度量 25/30
不同阶段度量对象不同： – 早期的制品： 发现偏差 – 发布的产品：发现缺陷 – 提供的服务： 发现异常
高级软件工程
软件可信性度量 6/30
你不能控制无法由你能够描绘的东西！
我们需要测量那些因素？

长度 规则 米或分米等等 时间 时钟 日或小时或分等等 重量 平衡 里或公里等等 温度计 摄氏度等等 湿度，光照度，等等 面积、体积、速度，密度；
对于软件来说：千行代码数，出错率，平均无故障时间。
程的某个属性的范围、数量、维度、容量或大小提 供“一个”“定量的指示”； 获取了一个数据！ 度量（Metric）是对软件产品进行范围广泛的测度， 它给出一个系统、构件或过程的某个给定属性的 “度”的定量测量； 指示 (Indicator) 是一个度量或一组度量的组合，采 用易于理解的形式，对软件过程、项目或产品质量 提供更全面、深入的评价和了解，以利于过程和质 量的分析。
软件是否考虑了足够多的可信属性？ 是否有足够多的预案？ 表述是否合理？ 是否与用户做了足够多的沟通？ 需求度量方法？
高级软件工程
软件可信性度量 29/30
2）设计模型缺陷度量
模型中是否描述了足够的可信属性？ 是否与需求中的内容一致？ 设计模型度量方法

– 模型检测

重要且困难
高级软件工程
高级软件工程
软件可信性度量 12/30
为什么要度量早期制品？
问题要尽早发现、尽早解决！以降低总的可信性 保障开销，但越往前也越困难，因为：
用户需求不够清晰； 制品形态不够清晰； 自动成分较少，人工方式更多。
高级软件工程
软件可信性度量 13/30
产品度量之后呢？

对服务进行度量，包括如下几个方面：
冲击
高级软件工程
软件可信性度量 21/30
二、如何度量软件的可信性？
1、基本步骤 2、不同技术
高级软件工程
软件可信性度量 22/30
1、基本步骤
IEEE质量规则方法
发布质量要求 验证质量规则 实现质量规则 分析规则结果 确认规则
高级软件工程
软件可信性度量 23/30
1、基本步骤
可信规则方法