軟件過程與質量.ppt

建模 系统： 列控系统 规约： 不能相撞！ “相撞”状态在系统行为中是否可达? 输入： 模型与规约 遍历状态空间 检查 不可达 可达！ 返回反例 模型检验 推理验证（程序验证） 规约（数学描述） 证明（可靠性证据） 程序（数学模型） 验证 严格保证程序相对于其规约没有bug 内存安全性、功能正确性、终止性、实时性等 软件过程的管理与控制 软件质量定义 明确声明的功能和性能需求、明确文档化过的开发标准、以及专业人员开发的软件所应具有的所有隐含特征都得到满足。 软件过程管理 软件配置管理 软件项目管理 软件质量保障 软件监控 根据软件系统运行过程中产生的动态信息，监控软件系统的行为 在线监控（Online） Monitoring-Oriented Programming 离线监控（Offline） 运行时验证（Runtime Verification） 测试与形式化方法的结合 监控系统 插桩模块、监控模块、反馈控制模块 多核CPU带来的机会 软件容错 在软件运行期间容忍软件缺陷、避免软件实效 单版本技术（Single-version techniques） 立足于单个软件版本，引入相关的缺陷和失效检测、容忍、处理技术和机制 多版本技术（Multi-version techniques） 结构化地配置软件的多个版本，以抑制设计和实现缺陷所导致的实效 软件可信性度量与评估 软件系统是可信的： 人基于客观证据判定软件系统能够满足需求、摆脱缺陷。 判定 = 度量 + 评估 度量是定量，评估是定性 度量是通过工具获得客观证据，评估是基于度量结果的主观判断 软件系统的认识与理解 直接的认识与理解 制品可信 分析、测试、验证 间接的认识与理解 第三方推荐、各种网络传播等 软件过程的管理与控制 过程管理 过程可信 质量控制 软件系统的运行保障 容错 运行可信 监控 软件可信性度量与评估途径 基于认识与理解途径的可信软件性度量与评估 目的：建立人与软件之间的信任关系 基于客观证据形成主观判断 从认识、理解到信任 认识与理解软件系统 满足需求的程度 摆脱缺陷的程度 维度：模型、代码 途径：静态分析、动态测试、形式验证 认识与理解的途径 静态分析 扫描代码级制品，发现语法和语义错误 驼鸟策略，分析结果形成警告信息 警告信息需求要确认，成本很高 动态测试 动态运行程序以发现错误，是工业界常用途径 按功能、模型、代码建立测试覆盖率指标 达到既定覆盖率指标相当困难，成本很高 形式验证 建立系统的形式化模型，验证模型满足给定性质 数学模型的状态空间复杂度高 主要面对状态空间爆炸问题 核心问题 认识和理解过程中的相关复杂性控制 从认识、理解到信任 的判定机理与模型 提高分析、测试和验证等相关技术的有效性和可扩展性、降低成本 基于分析、测试和验证结果度量和评估软件可信性 怎样度量与评估？ 类似于到医院体检 需要度量工具（体检仪器） 成本受限，需要有针对性地选择度量与评估手段 度量与评估结果怎样比较？ 体现可信的重要特征：相对性、实证性、高成本 需要一个体检表（度量规约） 度量规约 度量规约（体检表） 用户可信需求和可投入成本的体现 由一组对应于度量工具的评估项构成 可信性比较的依据 度量规约本身需要度量和分级 体检表也是分级的 度量规约的完备度 度量规约也有可信级别（完备级别） 度量结果（类似于体检表中的诊断结果） 度量规约的完备度 认识理解的充分度（各项度量指标值） 检测出的缺陷与错误 不满足需求的情况 存在的缺陷 度量规约实例化 度量指标的设定 度量指标相关于分析、测试和验证技术与工具 反映认识与理解（分析、测试和验证）的充分度 静态分析的相关指标可以用不确定性分析结果（没有经过确认）的数量比例来衡量； 测试的相关指标可以是各类模型覆盖度、各类代码覆盖度等； 验证的相关指标可以是状态空间的被搜索（遍历）程度。 不直接反映检测出的错误与缺陷 度量规约和支撑工具举例 内存泄露的度量与评估 度量规约 Purify Fastchecker Matal LC …… 软件系统 代码 度量规约 完备度 各项度量指标值 Purify 80% Fastchecker 75% Matal 40% …… 摆脱内存泄漏 缺陷的程度 静态和动态分析工具 存在的错误和缺陷 基于认