软件质量控制

软件项目中的QC活动
需求评审 界面原型 测试开发 设计 编码 设计评审 代码审查 确认测试 系统测试
需求分析
需求确认 需求确认
质量控制方法
技术评审
静态方法：评审
质量控 制方法 动态方法：测试
代码评审 …… 单元测试
集成测试 确认测试 ……
技术评审（Technical Review）
技术评审是指在完成一项工作后，把工作产品 分发给合作者，让合作者检查其中的缺陷。然 后开会讨论工作产品并产生需要返工的缺陷列 表。 技术评审的主要对象：需求和设计规格说明、 测试计划、用户手册等。
软件质量的常用度量

缺陷密度：指软件单位数量的源代码中隐藏的 缺陷数量。
通常以每千行无注解源代码为一个单位。
本章内容提要
软件质量管理的基本概念 软件质量控制 缺陷预防 质量体系 软件项目质量管理计划（案例） 缺陷跟踪工具Bugzilla

第三节 缺陷预防
找到根本原因 消除根本原因
project human
Change coordinatin
软件缺陷原因分析方法

Step3:识别公共原因，制定改进措施。 在逐个分析了缺陷之后，还要对分析得到的根 本原因进行综合和归纳，识别导致缺陷产生的 公共原因，并制定有关过程、技术和人员管理 方面的改进措施。
本章内容提要
软件质量管理的基本概念 软件质量控制 缺陷预防 质量体系 软件项目质量管理计划（案例） 缺陷跟踪工具Bugzilla
软件质量的常用度量

平均失效前时间（Mean Time to Failure， MTTF）：指软件在失效前正常工作的平均统 计时间。 用来度量软件的可靠性。

平均修复时间（Mean Time to Repairation， MTTR）：指软件失效后，使其恢复正常工作 所需要的平均统计时间。 用来度量软件的可维护性。

第四节 质量体系

根据ISO9000标准，质量体系的定义是：为实 施质量管理所需的组织结构、责任、工序、工 作过程和资源。
组织结构 过 程
质量体系
工 序 资 源
质量体系的特征
一个企业的质量体系是企业质量管理的规范， 是企业长期遵循和需要重复实施的标准。 质量体系可参照一定的标准实施，例如CMM、 ISO9000系列等。 质量体系内容的核心是建立、执行和维护（改 进）软件生产过程，以保证最终生产出的软件 产品达到用户综合的质量要求。

同行评审（Peer Review）

同行评审是一种特殊类型的技术评审。

由与工作产品开发人员具有同等背景和能力的 人员对工作产品进行技术评审，因此非常有利 于发现工作产品中的问题。
代码评审（Code Review）

编码阶段的一种技术评审，由一组人员对程序 进行阅读和静态分析，可以很有效地检查程序 代码中的缺陷。 评审内容：程序是否符合编码规范，程序结构 是否合理，算法和程序逻辑是否正确，程序性 能怎样等。 很多程序逻辑错误很难通过测试发现。

Bugzilla的特点：

基于Web方式运行，安装简单，易于掌握。

缺陷从最初的报告到最后的关闭，都有详细的 操作记录，确保了缺陷不会被忽略，并允许用 户在检查缺陷状态时获取历史记录。
提供强大的查询匹配能力，能根据各种条件组 合进行缺陷查询，并能够记忆搜索条件。

Bugzilla的特点：

当缺陷状态发生改变时，会自动发送邮件通知 相关责任人。 自带基于数据库的报表生成功能，主要生成两 类图表：基于表格的视图和图形视图（条形图、 线图、饼状图）。
确定项目采用的控制手段及合适的验证手段和 方法；
确定和准备质量记录。

制订软件项目质量管理计划的依据是企业的质量体 系和项目的特点。
改进软件质量的一些要求


软件质量活动必须经过规划 软件质量活动规划必须明文规定 质量活动必须尽早开始 质量小组必须独立存在 质量小组的人员应该经过必要的培训

软件缺陷原因分析方法
缺陷原因分析工具——因果图（鱼骨图）
phase
Requirements Architecture Inadequate participation Component design Testing No/Incomplete review
review
High level design Implementation

练习题
质量控制活动主要包括哪些？ 简述质量体系和项目质量管理计划的区别。


初期故障率：指软件在初期故障期（一般以软 件交付给用户后的三个月内为初期故障期）内 单位时间的故障数。 用来评价交付使用的软件的质量，预测什么时 候软件运行达到基本稳定。 一般以每100小时的故障数为单位。
软件质量的常用度量

偶然故障率：指软件在偶然故障期（一般以软 件交付给用户后的4个月以后为偶然故障期） 内单位时间的故障数。 它用来度量软件处于稳定状态下的质量。 一般以每1000小时的故障数为单位。

质量体系实例
过程改进组织 决策、建立、维护
过程域
执行
过程规范 包含 程序规范 产品标准
产出
过程执行组织
关键过程域 支持过程域
产品
支持
保证 保证
质量文件体系
质量保证组织
质量体系要素关系图
全面质量管理（TQM）

全面质量管理是指通过全体员工的参与，改进 流程、产品、服务和公司文化，使企业运作的 每一过程都做到满足客户需要，从而达到客户 满意。

技术评来自百度文库流程

组织召开评审会议：一般应有3~5个相关人员 参加，会前每个参加者做好准备，评审会议一 般不超过两个小时。 在评审会议上，由开发小组对提交的评审对象 进行讲解。 评审组可对开发小组提问，提出建议和要求， 展开讨论。


技术评审流程
会议结束时必须做出以下三个决策之一： 接受该产品，不需要做修改。 由于错误严重，拒绝接受。 暂时接受该产品，但需要对某一部分进行修改。 评审报告与记录：对所提出的问题要进行记录，并 产生一个评审报告。

Bugzilla的基本操作说明
报告缺陷 分配缺陷 处理缺陷 验证已解决的缺陷

本章内容小结
质量管理的基本概念 软件质量、质量属性、质量形成、质量成本 质量控制 技术评审、同行评审、代码评审 缺陷跟踪 常用质量度量 缺陷预防

本章内容小结
质量体系 质量体系的构成、特征，TQM 质量管理计划（案例） 缺陷跟踪工具Bugzilla


缺陷跟踪

缺陷跟踪是指从缺陷被发现开始到被改正为止 的整个跟踪流程。
重新打开
分配 重新打开 验证 关闭
报告 开始
打开
分配
已分配
解决
已解决
已验证
已关闭
结束
退回
缺陷跟踪

缺陷跟踪一般需要软件工具支持。常用的工具 有Bugzilla、ClearQuest、Jira、 TrackRecord 等。
软件质量的常用度量
第二节 软件质量控制
质量控制(Quality Control, QC)是确定项目结果 与质量标准是否相符，并及时纠正产品缺陷的过 程。 质量控制的主要手段是验证与确认( V&V ) 验证（Verification）:是否正确地构造了产品？ 以开发者的视角进行。 确认（Validation）:是否构造了正确的产品？ 以用户的视角进行。
Not enough preparation
software defect
Time pressure Individual mistake Caused by Other product Management pressure Communication problem Lack of domain knowledge Lack of process knowledge
全员性 （全员参与质量管理）
TQM核心思想
全过程性 （管理好质量形成的全过程）
全面性 （和顾客交互的所有环节）
全面质量管理（TQM）
TQM强调建立以过程为核心的组织文化 以为客户创造价值为目标，识别组织内部的 所有过程 所有人员的职责和协作基于过程 TQM强调过程的不断优化 更强调预防而不是质量控制 要求对过程不断进行优化
软件项目质量管理计划案例
《校务通管理系统》质量管理计划
本章内容提要
软件质量管理的基本概念 软件质量控制 缺陷预防 质量体系 软件项目质量管理计划（案例） 缺陷跟踪工具Bugzilla

第六节 缺陷跟踪工具Bugzilla

Bugzilla是Mozilla公司提供的一个开源的缺陷 跟踪工具，在全世界拥有大量用户。 它能够为软件组织建立一个完善的缺陷跟踪体 系，包括报告缺陷、查询缺陷记录并产生报表、 处理解决缺陷、管理员系统初始化和设置等。

本章内容提要
软件质量管理的基本概念 软件质量控制 缺陷预防 质量体系 软件项目质量管理计划（案例） 缺陷跟踪工具Bugzilla

第五节 软件项目质量管理计划

软件项目质量管理计划一般应满足以下要求：
确定项目应达到的质量目标和所有特性的要求；
确定项目中的质量活动和质量控制程序；

优点：主动 改进软件过程，降低出错几率 降低质量成本，实现项目效益
软件缺陷预防过程
组织级DP活动
制订组织级DP计划 组织级DP会议 修改组织标准软件 过程
项目级DP活动
原因分析报告
DP效果分析报告
制订项目级DP计划
项目阶段启动会议
原因分析会议
DP效果分析
软件缺陷原因分析方法
Step1：选择缺陷数据。 对小项目，可选择某一时期内发现的所有缺陷。 对大项目，可选择一个缺陷样本集合。 Step2：分析缺陷的根本原因 对缺陷逐个进行分析，常以会议的方式进行。 可对分析出的根本原因进行分类，例如： IBM：疏忽、培训、通信失效、书写错误 Motorola：开发阶段相关、人员相关、项目相关、 复审相关