软件可靠性与安全性转训材料.ppt

2,对高质量软件的需求,软件应用广泛, 在许多领域已成为产品创新的源泉 软件使系统更加智能、灵活, 越来越多的系统能力由软件实现 系统对软件的需求和依赖, 使得软件既要满足用户的功能要求, 又必须稳定可靠地完成赋予的任务 在许多应用场景下, 软件失效有可能带来重大损失, 安全性必须得到保证,3,软件的质量状况,硬件飞速发展, 越来越可靠, 软件成为系统失效的主要原因 软件规模和复杂性持续增加, 给获得安全可靠的软件带来巨大挑战 软件质量的定量评估困难, 往往成为项目要素中最容易被忽略的部分 经济性使得相关各方都在考虑成本, 在资源受限的情况下, 质量的要求会降低, 常常不得不在带有许多缺陷的情况下发布软件,4,软件质量,明确声明的功能和性能需求、明确文档化的开发标准、以及专业开发人员开发的软件所应具有的所有隐含特征都得到满足 软件质量模型是多样的 软件质量模型是动态的 软件质量是多维度的 软件质量是多视角的 软件质量特性之间存在交互影响,5,动态的软件质量,软件质量的关键特性,6,软件失效机理,导致软件失效的缺陷主要是设计问题 老化/磨损不会导致软件失效, 软件失效没有趋势性预兆 周期性的重启可帮助防止/修复一些软件失效 除非输入(指令、数据、运行环境)发生变化,否则, 运行时间的长短不会对软件可靠性产生影响 除非影响到软件的输入(指令、数据、运行环境), 否则, 物理环境因素的变化不会对软件可靠性产生影响 通常, 不能通过对单条语句的分析来预计软件失效率 软件的接口完全是概念上的、不可见的, 但对软件可靠性有影响 标准件可用于改善可靠性和可维护性, 但软件重用还没有形成工程趋势 硬件维修使其恢复到良好状态, 而软件修改使其到达未知状态,7,使用环境对失效的影响,软件缺陷只有被遇到时才会产生故障, 才有可能导致失效, 不同使用方式下, 对软件可靠性的感受是不一样的决定软件使用方式的因素很多 内部参数、历史数据、当前输入、 软件失效状态受到操作及环境条件的影响 软件不会脱离环境运行 软件失效对系统的影响程度取决于使用环境, 在某个环境中是安全的软件, 可能在另一个环境中就不安全了,软件失效的统计特性,IBM关于缺陷与失效的统计研究数据 客户所看到的57%以上的失效是由占缺陷总数2%以下的缺陷引起的 超过总数61%的缺陷只引起低于3%的客户将会经历的失效 不同的缺陷在所引发的失效率上存在高达4个数量级的巨大差异,8,软件缺陷的特性及影响,变异的预期常常产生缺陷 在实际项目中, 完全消除缺陷是不可能的, 基于软件开发经济学的考虑, 减少缺陷是现实的选择 缺陷有可能非常简单, 也有可能极其复杂 程序设计语言与缺陷的复杂性和数量的关系是未知的 不论人的能力和背景, 都可能产生缺陷 缺陷在软件中的位置未知,软件缺陷的影响,缺陷可能导致故障, 甚至失效 同样的缺陷在不同的场景下导致的失效状态可能会有很大的差别, 可能只是使用不便, 也有可能带来灾难性后果 缺陷的复杂度与失效的严重性之间的关系是未知的 最大限度的减少缺陷, 可以提高软件的可靠性 缺陷除了带来失效损失之外, 还带来开发、验证和维护成本的全面增加,9,软件防错策略,第一次就做正确(Do It Right the First Time) 建立先进的理念, 避免错误及预防失误 采取适当的实践, 形成缺陷预防的趋势 利用一切可用的方法及工具, 确保不引入缺陷到软件 典型实践 建立组织级别的规范和指南, 全体人员共同遵守 用户的早期参与 进行专业分工, 使用有能力、经验及进取心的人员 在生命周期各阶段, 使用现代的方法论和自动化工具, 促进生产力提升的同时及达到预定质量的目标,10,软件排错策略,尽早检测, 一旦可行立即修正(Detect It Early; Fix It as Soon as Practicable) 测试及修复成为计划性和经常性活动, 对缺陷进行早期检测及消除, 使得缺陷一旦产生就立刻解决 修正系统缺陷时, 应考虑问题的严重程度、发生频率及完成测试及管理的可能性 在操作和维护阶段发现的缺陷, 不一定要立即修正 典型实践举例 在生命周期各阶段, 对软件进行原型化、仿真、审查和检查, 验证正确性, 改善可靠性 尽早开展多层次的测试工作, 发现并消除缺陷和隐患 优先解决最高风险的问题, 加强配置管理, 防止变更失控 建立并运行软件故障报告、分析及纠正措施系统, 做好软件故障管理,11,可靠性问题的答案在哪里?,你的软件可靠吗？ 你是如何知道的？ 不可靠的原因是什么？ 你的开发过程需要改进吗？ 你的测试过程需要改进吗？,12,软件失效管理,利用“信息反馈, 闭环控制”的原理, 通过一套规范化的程序, 使分散发生的产品失效能得到及时报告、查清原因、正确纠正, 防止失效再现, 从而实现产品可靠性的增长, 达到对产品可靠性和维修性的预期要求 基于风险水平管理失效 建立企业的可靠性经验,13,SFRACAS,软件失效报告、分析及纠正措施系统, 是Software Failure Report Analysis and Corrective Action System 的缩写, 有时也称为“失效信息闭环管理系统” 一组过程、规则和软件工具, 在产品生存期后端开始使用, 是跟踪系统可靠性的方法 建立企业失效信息数据库, 提供数据支持 软件可靠性分析、设计、改进和评价 维修策略、保障策略和备件策略的制定,14,SFRACAS知识积累,15,防错性设计,简化设计 算法与数据管理 慎用易错架构 使用监错技术 多任务管理,16,防错性设计-简化设计,复杂性是可靠性最凶恶的对手 复杂的软件 代码规模更大、缺陷更多 交互关系更多、缺陷更多 更难测试、不充分的可能性更大 设计、实现、配置、使用的难度更大 用户更难理解,结构复杂性 接口复杂度 调用关系复杂度 单元复杂性 规模 圈复杂度 基本圈复杂度,17,复杂度,圈复杂用于衡量一个软件单元的复杂程度, 数量上表现为独立路径的条数 V(G)=e n + 2,复杂性的影响,18,防错性设计-算法选择,对规定时间内要完成规定任务的软件, 应采用在规定时间内能得出结果的算法 例如, 不采用只有“计算迭代到|为止”的算法, 而采用迭代到一定次数为止, 或者迭代到|为止或迭代到一定次数为止的算法 算法所使用的存储空间应具有完全确定性 例如, 尽量不采用动态堆空间,19,防错性设计-数据管理,参数化 在软件设计中, 用统一的符号来表示参数、常量和标志, 以便在不改变源程序逻辑的情况下, 对它们进行修改 寻址模式的选用 尽量不使用间接寻址方式 在确实有必要采用间接寻址方式时, 慎重考虑和充分论证, 并在执行之前验证地址是否在可接受的范围内 文件 文件必须唯一且用于单一目的 文件在使用前必须成功地打开, 在使用结束必须成功地关闭 文件的属性应与对它的使用相一致,20,防错性设计-慎用易错架构,使用语言的安全子集进行实现 典型易错架构,21,防错性设计-慎用易错架构,浮点数 先天不精确, 有可能导致无效的比较 指针 指针引用错误的内存区域可能导致数据误用 递归 错误的递归容易导致内存溢出 当使用递归时, 应有明显的判据, 可预测递归的深度 中断 有可能导致关键操作的终止 使程序难以理解 类似 goto 语句,22,防错性设计-慎用易错架构,继承 代码非局部化, 代码的修改可能导致无法预期行为, 产生难以理解的问题 别名 使用多个变量名来访问相同状态变量, 会使程序的理解和修改变得困难 无界数组 如果不进行任何数组边界检查, 可能出现缓冲区溢出失效 动态内存分配 在有些场景下, 软件运行时内存块大小不能在代码编译时确定, 需要根据代码的运行环境来确定 软件执行过程中, 根据需要分配或者回收存储空间 在C/C+程序中, 应正确使用malloc、calloc、realloc、new、alloca与free、delete管理动态内存,23,防错性设计-慎用易错架构,不当动态内存分配的后果 内存泄露 内存碎片 内存泄露的原因 忘记了回收 回收前失去了对内存的追踪, 如: 存储指针值的变量被移出了作用域; 指针值被重写; 没有保存地址指针 库函数存在内存泄露缺陷, 对库函数接口的误解 全局变量 全局变量不好控制 不利于程序的结构化 不用或少用全局变量 公用数据和公共变量 指明由两个或多个模块公用的数据和公共变量 尽量减少对公共变量的改变, 以减少模块间的副作用,24,防错性设计-使用监错技术,使用条件判断 int z; if (y != 0) z = x / y; else / deal with this situation here ,在开发和维护阶段, 使用监错技术提示 相互矛盾的假设 传入程序的不良数值 主要的监错技术 断言 异常情况处理,25,防错性设计-多任务设计,多任务设计 多任务设计是软件应用的新趋势, 但是多任务之间可能存在难以预知的交互, 导致同步错误 多任务设计的原则 注意函数的可重入性 避免死锁与活锁 避免临界点竞争 注意函数的可重入性 不为连续的调用持有静态数据 不返回指向静态数据的指针, 所有数据都由函数的调用者提供 使用本地数据, 或者通过