软件开发工程管理2008(九).ppt

软件开发工程管理 第九讲 软件质量保证（SQA） ——引论 为什么要引入软件质量保证？ 生产出高质量的软件 为了“在正确的时间、以正确的方式、做正确的事情” 质量（1） 什么是质量？ 某一事物的特征或属性 产品或工作的优劣程度 质量（2） 两种不同的质量 设计质量 符合质量 质量（3） 软件质量特性： 功能性 包括软件产品提供的用来满足用户需要的功能 可靠性 与软件维护其性能等级的能力相关 易用性 与使用软件所要花费的工作量相关 效率 与软件执行过程中所占用的物理资源相关 可维护性 与进行软件变更所需要的工作量相关 可移植性 与把软件转换到不同环境的能力相关 质量（4） 软件质量特性——功能性 适合性 软件是否符合用户需要 准确性 软件是否正确地实现了功能 互操作性 软件和其他系统的交互能力 功能符合性 软件和需求的匹配程度 安全性 系统访问控制 质量（5） 软件质量特性——可靠性 成熟度 软件中缺陷所造成的故障的频率 容错性 可恢复性 可靠性符合性 质量（6） 软件质量特性——易用性 可理解性 可学习性 可操作性 吸引性 可用性符合性 质量（7） 软件质量特性——效率 时间特性 资源利用 有效性符合性 质量（8） 软件质量特性——可维护性 可分析性 确定故障产生原因的容易程度 可变性 灵活性 稳定性 对软件修改的可能性 可测试性 可维护性符合性 质量（9） 软件质量特性——可移植性 适应性 可安装性 共存性 软件和其他软件分享资源的能力 可替代性 可移植性符合性 质量（10） 质量（11） 怎么能保证质量？ 质量控制 质量控制是为了保证每一件工作产品都满足对它的需求而应用于整个开发周期中的一系列审查、评审和测试 质量控制在创建工作产品的过程中包含一个反馈循环 质量保证 质量保证由管理层的审计和报告功能构成 质量成本（1） 什么是质量成本？ 所有由质量工作或者进行与质量有关的活动所导致的成本 有哪些质量成本？ 预防成本 鉴定成本 故障成本 质量成本（2） 既然质量管理需要成本，那么是不是越晚进行质量管理就越省钱？ 质量成本（3） 改正一个错误的相对成本 需求分析阶段：1倍 设计阶段：3~6倍 编码阶段：10倍 开发测试阶段：15~40倍 系统测试阶段：30~70倍 实际操作阶段：40~1000倍 软件缺陷（1） 几个概念： 缺陷（defect） 故障（bug） 错误（error） 缺陷、故障：软件交付之后发现的质量问题 错误：软件交付之前发现的质量问题 软件缺陷（2） 几个结论： 设计活动引入的错误占软件过程中出现的所有错误（和最终的缺陷）数量的50%到65% 正式技术评审在发现设计错误方面最高达到75%的有效性 软件缺陷（3） 缺陷放大模型： 软件缺陷（4） 例：假设： 概要设计阶段生成10个错误 详细设计阶段生成25个错误，同时会放大1/3的继承错误，放大系数为1.5 编码和单元测试阶段生成25个错误，同时会放大2/3的继承错误，放大系数为3 在测试中可以发现并改正50%的错误，同时不引入新的错误 概要设计阶段错误的改正成本为1，详细设计时为1.5，测试前是6.5，测试中是15，发布后是67 软件评审 技术工作需要评审 评审的目的是什么？ 指出个人或小组生产的产品所需进行的改进 确定产品中不需要或者不希望改进的部分 得到与没有进行评审相比更加一致、或者至少更可预测的技术工作的质量，从而使得技术工作更小易于管理 为什么需要评审 在去除明显的错误时，审查是非常有效的方法 鼓励开发人员产生结构更好的、不需要加以说明的软件 能促进优秀编程实践的传播 能增进团队精神 正式技术评审（FTR）（1） FTR想要达到什么目标？ 在软件的任何一种表示形式中发现功能、逻辑或实现的错误 证实经过评审的软件的确满足需求 保证软件的表示符合预定义的标准 得到以一种一致的方式开发的软件 使项目更易于管理 正式技术评审（2） 每个评审会议约束： 评审会议通常应该在3~5人之间进行 应该进行提前准备，但是每人占用工作时间应该少于2小时 评审会议时间应该不超过2小时 正式技术评审（3） 每个FTR步骤： 确定参加评审的人员 人员培训 评审准备 分发评审材料，评审员审读评审材料 开评审会议 生成评审报告和问题列表 正式技术评审（4） 评审结论： 工作产品可以不经修改而被接受 由于严重错误而否决工作产品 暂时接受工作产品 评审总结报告内容： 评审什么 由谁评审 发现和结论是什么 正式技术评审（5） 正式技术评审的指导原则： 评审产品，而不是评审生产者 制定日程并且遵守日程 限制争论和辩驳 对各个问题都发表见解，但是不要试图解决所有记录的问题 做书面笔记 限制参与者人数并坚持事先做准备 为每个可能要评审的工作产品建立一个检查表 为FTR分配