ch7-质量管理.pdf

实践者的研究方法 第七章 质量管理 本章内容本章内容 什么是软件质量 什么是软件质量 高质量软件的一般特性是什么 高质量软件的一般特性是什么 如何保证软件质量 如何保证软件质量 如何评审质量 如何有效地进行质量评审 如何评审质量 如何有效地进行质量评审 如何管理和控制软件开发过程中经常发生的变更 如何管理和控制软件开发过程中经常发生的变更 第一节 质量的概念 人们会忘记你做一件工作有 人们会忘记你做一件工作有 多快多快 但他们总会记得你做但他们总会记得你做 得有多好 得有多好 Howard Newton 又快又好 又快又好 or 又好又快 又好又快 实现高质量软件实现高质量软件 1 明确 软件质量 的含义 明确 软件质量 的含义 2 提出一组有助于确保高质量产品的活动 包括 提出一组有助于确保高质量产品的活动 包括 软件工程中的活动 需按之前章节介绍的分析软件工程中的活动 需按之前章节介绍的分析 设计概设计概 念和方法进行 念和方法进行 项目管理活动 需进行项目估算 进度计划 风险规项目管理活动 需进行项目估算 进度计划 风险规 划 变更管理 质量管理等活动 划 变更管理 质量管理等活动 3 实施质量控制和质量保证活动 实施质量控制和质量保证活动 质量控制质量控制 如评审模型 检查代码 进行测试 如评审模型 检查代码 进行测试 质量保证质量保证 是贯穿整个软件过程的普适性活动 为高 是贯穿整个软件过程的普适性活动 为高 质量的实现提供基础 质量的实现提供基础 4 运用度量技术制定软件过程改进的策略 运用度量技术制定软件过程改进的策略 软件质量的困境软件质量的困境 生产 足够好 的软件是否可行 生产 足够好 的软件是否可行 以期尽快交付以期尽快交付 而让缺陷遗留到后续版本改进 而让缺陷遗留到后续版本改进 仅限于少数的大公司和有限的几个应用领域 仅限于少数的大公司和有限的几个应用领域 质量是有成本的 但缺乏质量也有成本 质量是有成本的 但缺乏质量也有成本 质量成本包括预防成本 评估成本和失效成本 质量成本包括预防成本 评估成本和失效成本 低质量软件会增加安全风险 低质量软件会增加安全风险 软件质量常受到管理决定的影响 包括估算决策 进软件质量常受到管理决定的影响 包括估算决策 进 度安排决策 面向风险的决策 度安排决策 面向风险的决策 即使是最合适的软件工程也能被糟糕的商业决策和有问即使是最合适的软件工程也能被糟糕的商业决策和有问 题的管理活动破坏 题的管理活动破坏 软件质量软件质量 软件质量可如下定义 在一定程度上应用软件质量可如下定义 在一定程度上应用有效的软有效的软 件过程件过程 创造 创造有用的产品有用的产品 为生产者和使用者 为生产者和使用者提供提供 明显的价值明显的价值 影响软件质量和组织有效影响软件质量和组织有效 性的决定因素有三个 人性的决定因素有三个 人 员 产品 技术 员 产品 技术 其中 人员的技能和动力其中 人员的技能和动力 对产品质量影响最大 对产品质量影响最大 软件质量的评价指标软件质量的评价指标 软件的质量必须通过测量来需求分析模型 设计模软件的质量必须通过测量来需求分析模型 设计模 型 源代码 测试用例等内容来判断 型 源代码 测试用例等内容来判断 有多种评价软件质量的标准或方法 有多种评价软件质量的标准或方法 Garvin质量维度质量维度 McCall质量因素质量因素 ISO 9126质量因素质量因素 其中的许多质量属性具有明显的主观性 无法直接其中的许多质量属性具有明显的主观性 无法直接 测量 而需要通过其它的度量或指标来衡量 测量 而需要通过其它的度量或指标来衡量 通常认为通常认为正确性正确性 可维护性可维护性 完整性完整性和和可用性可用性能为能为 项目团队提供非常有用的指标 项目团队提供非常有用的指标 Garvin质量维度质量维度 Garvin的的8个质量维度并非专门针对软件 个质量维度并非专门针对软件 1 性能质量 是否交付了所有的内容 功能和特性 性能质量 是否交付了所有的内容 功能和特性 2 特性质量 是否提供了使最终用户惊喜的特性 特性质量 是否提供了使最终用户惊喜的特性 3 可靠性 是否无误地提供了所有的特性和能力 可靠性 是否无误地提供了所有的特性和能力 4 符合性 是否遵从应用领域的软件标准和惯例 符合性 是否遵从应用领域的软件标准和惯例 5 久耐性 是否能维护或改正 且不会导致副作用 久耐性 是否能维护或改正 且不会导致副作用 6 适用性 能否在短时期内完成维护和改正 适用性 能否在短时期内完成维护和改正 7 审美 具有某种优雅 特有的流畅和醒目的外在 审美 具有某种优雅 特有的流畅和醒目的外在 8 感知 生产厂家的声誉可能会影响用户对质量的感知 感知 生产厂家的声誉可能会影响用户对质量的感知 McCall质量因素质量因素 McCall的质量因素侧重于的质量因素侧重于软件产品的三个方面 操作软件产品的三个方面 操作 特性 承受变更的能力以及对新环境的适应能力 特性 承受变更的能力以及对新环境的适应能力 ISO 9126 质量因素质量因素 ISO 9126标准试图标识软件的六个关键质量属性 标准试图标识软件的六个关键质量属性 功能性 软件满足已确定要求的程度 包括适合性 准功能性 软件满足已确定要求的程度 包括适合性 准 确性 互操作性 依从性 安全保密性 确性 互操作性 依从性 安全保密性 可靠性 软件可用的时间长度 包括成熟性 容错性 可靠性 软件可用的时间长度 包括成熟性 容错性 易恢复性 易恢复性 易用性 软件容易使用的程度 包括易理解性 易学习易用性 软件容易使用的程度 包括易理解性 易学习 性 易操作性 性 易操作性 效率 软件优化使用系统资源的程度 包括时间特性 效率 软件优化使用系统资源的程度 包括时间特性 资源利用特性 资源利用特性 维护性 软件易于修复的程度 包括易分析性 易改变维护性 软件易于修复的程度 包括易分析性 易改变 性 稳定性 易测试性 性 稳定性 易测试性 可移植性 软件可以从一个环境移植到另一个环境的容可移植性 软件可以从一个环境移植到另一个环境的容 易程度 包括适应性 易安装性 符合性 易替换性 易程度 包括适应性 易安装性 符合性 易替换性 软件的可靠性和可用性软件的可靠性和可用性 软件的可靠性 在特定环境和特定时间内 计算机程软件的可靠性 在特定环境和特定时间内 计算机程 序不失败地运行的概率 序不失败地运行的概率 例 程序例 程序X在在8小时处理时间内的可靠性估计为小时处理时间内的可靠性估计为0 96 这 这 意味着 若意味着 若X执行执行100次 每次运行次 每次运行8小时处理时间 则小时处理时间 则 100次中正确运行次中正确运行 无失效无失效 的次数可能是的次数可能是96次 次 平均失效间隔时间平均失效间隔时间MTBF 平均失效时间平均失效时间MTTF 平均维修时间平均维修时间MTTR 软件的可用性 在某个给定时间点上程序能够按照需软件的可用性 在某个给定时间点上程序能够按照需 求执行的概率 求执行的概率 可用性可用性 MTTF MTTF MTTR 100 缺陷排除效率缺陷排除效率DRE 缺陷排除效率缺陷排除效率DRE是对质量控制和质量保证动作滤除是对质量控制和质量保证动作滤除 缺陷能力的测量 定义如下 缺陷能力的测量 定义如下 DRE E E D E为交付前发现的错误数 为交付前发现的错误数 D为交付后发现的缺陷数 为交付后发现的缺陷数 DRE最理想的值为最理想的值为1 即交付后没有发现缺陷 但实 即交付后没有发现缺陷 但实 际上际上D总是大于总是大于0的 的 软件团队的质量目标是使得软件团队的质量目标是使得DRE尽量接近于尽量接近于1 在项目内部也可以使用在项目内部也可以使用DRE来评估一个团队在错误传来评估一个团队在错误传 递到下一活动前发现错误的能力 递到下一活动前发现错误的能力 第二节 软件质量保证SQA 质量控制与质量保证质量控制与质量保证 在软件过程中有两类与软件质量密切相关的活动 在软件过程中有两类与软件质量密切相关的活动 质量控制质量控制 为了保证每件工作产品都满足对它的需求而 为了保证每件工作产品都满足对它的需求而 进行的一系列评审 检查和测试活动 进行的一系列评审 检查和测试活动 质量控制是整个制造过程的一部分 由开发者进行 质量控制是整个制造过程的一部分 由开发者进行 质量保证质量保证 为管理层提供能反映产品质量的数据 从而 为管理层提供能反映产品质量的数据 从而 获得产品质量是否符合预定目标的认识和信心 获得产品质量是否符合预定目标的认识和信心 如果在所有软件工程活动中强调质量 就可以减少很如果在所有软件工程活动中强调质量 就可以减少很 多必需的返工 降低成本 更快交付 多必需的返工 降低成本 更快交付 将软件质量保证作为贯穿过程的普适性活动 将软件质量保证作为贯穿过程的普适性活动 软件质量保证软件质量保证 SQA 软件质量保证软件质量保证 SQA 包括 包括 1 SQA过程 过程 2 具体的质量保证和质量控制任务具体的质量保证和质量控制任务 如评审 测试等如评审 测试等 3 有效的软件工程实践有效的软件工程实践 方法和工具方法和工具 4 对所有软件工作产品及其变更进行的控制 对所有软件工作产品及其变更进行的控制 5 保证符合软件开发标准的规程 保证符合软件开发标准的规程 6 测量和报告机制 测量和报告机制 可以按照可以按照ISO 9000标准来构建质量保证体系 标准来构建质量保证体系 SQA活动通常由专门的活动通常由专门的SQA小组进行 其成员必须小组进行 其成员必须 从客户的角度来审查软件 从客户的角度来审查软件 SQA小组的任务小组的任务 SQA小组的行动纲领是帮助软件团队实现高品质的目小组的行动纲领是帮助软件团队实现高品质的目 标产品 其任务包括 标产品 其任务包括 编制项目质量保证计划编制项目质量保证计划 SQA计划计划 参与项目的软件过程描述的编写 参与项目的软件过程描述的编写 评审各项软件工程活动 以验证是否符合规定的过程 评审各项软件工程活动 以验证是否符合规定的过程 审核指定的软件工作产品 以验证是否遵守作为软件过审核指定的软件工作产品 以验证是否遵守作为软件过 程一部分的那些规定 程一部分的那些规定 确保软件工作及工作产品中的偏差已被记录在案 并根确保软件工作及工作产品中的偏差已被记录在案 并根 据预定规程进行处理据预定规程进行处理 记录所有不符合的部分 并报告给高层管理者 记录所有不符合的部分 并报告给高层管理者 SQA计划计划 SQA计划为软件质量保证提供了一张路线图 应包括计划为软件质量保证提供了一张路线图 应包括 如下内容 如下内容 计划的目的和范围 计划的目的和范围 SQA覆盖的所有软件工程工作产品的描述 覆盖的所有软件工程工作产品的描述 应用于软件过程中的所有适用的标准和习惯做法 应用于软件过程中的所有适用的标准和习惯做法 SQA活动和任务 以及它们在整个软件过程中的位置 活动和任务 以及它们在整个软件过程中的位置 支持支持SQA活动和任务的工具和方法 活动和任务的工具和方法 软件配置管理的规程 软件配置管理的规程 收集 保护和维护所有收集 保护和维护所有SQA相关记录的方法 相关记录的方法 与产品质量相关的组织角色和责任 与产品质量相关的组织角色和责任 统计统计SQA 在基于度量的项目管理活动中 在基于度量的项目管理活动中 SQA常常是基于统常常是基于统 计的 统计计的 统计SQA包含以下步骤 包含以下步骤 1 收集软件的错误和缺陷信息 并进行分类 收集软件的错误和缺陷信息 并进行分类 2 追溯每个错误和缺陷形成的根本原因 追溯每个错误和缺陷形成的根本原因 3 使用使用Pareto原则找出那些 重要的少数原则找出那些 重要的少数 80 的缺的缺 陷源自陷源自20 的原因的原因 4 纠正引起错误和缺陷的问题 纠正引起错误和缺陷的问题 目前产业界应用最广的统计目前产业界应用最广的统计SQA策略是六西格玛 策略是六西格玛 每百万个操作发生每百万个操作发生3 4个偏差个偏差 缺陷缺陷 第三节 评审技术TR 技术评审技术评审 TR 软件的技术评审是软件过程中的软件的技术评审是软件过程中的 过滤器过滤器 在软件 在软件 开发过程中的不同阶段对开发过程中的不同阶段对需求需求分析模型 设计模型 分析模型 设计模型 源代码和测试用例等过程工作产品进行评审 能起到源代码和测试用例等过程工作产品进行评审 能起到 发现错误发现错误 进而消除进而消除 的作用 的作用 技术评审的主要目标是在软件过程中发现技术评审的主要目标是在软件过程中发现错误错误 以使它 以使它 们不会在交付之后变成们不会在交付之后变成缺陷缺陷 同行评审同行评审 软件工程师和同事们一起进行的技术评审 软件工程师和同事们一起进行的技术评审 除了同行评审 有时还会有专家 客户参与的评审 除了同行评审 有时还会有专家 客户参与的评审 技术评审是软件过程早期最有效的查错机制 技术评审是软件过程早期最有效的查错机制 缺陷放大模型缺陷放大模型 可以使用 缺陷放大模型 来说明软件工程过程中错可以使用 缺陷放大模型 来说明软件工程过程中错 误的产生和检测 误的产生和检测 矩形框表示软件过程中的某个环节 矩形框表示软件过程中的某个环节 无评审的示例无评审的示例 有评审的示例有评审的示例 技术评审的步骤技术评审的步骤 评审方法因所选评审的正式程度而异 评审方法因所选评审的正式程度而异 非正式评审 如桌面检查 临时会议 结对编程评审非正式评审 如桌面检查 临时会议 结对编程评审 正式评审 如代码走查 审查 正式评审 如代码走查 审查 一般的正式评审步骤包括 一般的正式评审步骤包括 1 计划计划 2 准备准备 3 组织会议组织会议 4 记录错误记录错误 5 进行修改进行修改 此步骤在评审会议之后进行此步骤在评审会议之后进行 6 验证是否恰当地进行了修改验证是否恰当地进行了修改 此步骤在修改之后进行此步骤在修改之后进行 正式技术评审正式技术评审 FTR 正式的技术复审正式的技术复审 FTR 是一种由软件工程师进行的软是一种由软件工程师进行的软 件质量保证活动 件质量保证活动 FTR的目标是 的目标是 1 在软件的任何一种表示形式中发现功能 逻辑或实现在软件的任何一种表示形式中发现功能 逻辑或实现 上的错误 上的错误 2 验证评审中的软件是否满足其需求 验证评审中的软件是否满足其需求 3 保证软件的表示符合预先指定的标准 保证软件的表示符合预先指定的标准 4 获得以一种一致的方式开发的软件 获得以一种一致的方式开发的软件 5 使项目更易于管理 使项目更易于管理 FTR包括走查和审查 以正式的会议形式进行 包括走查和审查 以正式的会议形式进行 评审会议的约束评审会议的约束 不论选用何种不论选用何种FTR 评审会议都应遵守如下约束 评审会议都应遵守如下约束 评审会评审会 通常通常 应该由应该由3到到5个人参加 个人参加 应该提前进行准备应该提前进行准备 参会人员准备对要评审内容的书面参会人员准备对要评审内容的书面 意见意见 但是占用每人的工作时间应该不超过 但是占用每人的工作时间应该不超过2小时 小时 评审会的时间应该少于评审会的时间应该少于2小时 小时 在上述约束之下 显然在上述约束之下 显然FTR应该关注的是整个软件中应该关注的是整个软件中 的某个特定的某个特定 且较小且较小 部分 部分 FTR关注的范围越小 发现错误的可能性就越大 关注的范围越小 发现错误的可能性就越大 在理想情况下每个工作产品都应进行评审 但由于资在理想情况下每个工作产品都应进行评审 但由于资 源有限时间不足 常只能选择某些样本先进行审查 源有限时间不足 常只能选择某些样本先进行审查 找出其中最有错误倾向的再进行重点评审 找出其中最有错误倾向的再进行重点评审 评审会议的过程评审会议的过程 评审会议由评审主席 所有评审员和开发者参加 指评审会议由评审主席 所有评审员和开发者参加 指 定一名评审员做记录员 先由开发者做简单介绍 然定一名评审员做记录员 先由开发者做简单介绍 然 后由开发者或某位评审员后由开发者或某位评审员 遍历遍历 工作产品工作产品 走查走查 而评审员则根据各自预先的准备提出问题 而评审员则根据各自预先的准备提出问题 在评审会议结束时 所有在评审会议结束时 所有FTR与会者必须做出以下决与会者必须做出以下决 定中的一个 定中的一个 工作产品可以不经修改而被接受 工作产品可以不经修改而被接受 由于严重错误而否决工作产品由于严重错误而否决工作产品 错误改正后必须再次进错误改正后必须再次进 行评审行评审 暂时接受工作产品暂时接受工作产品 发现了一些必须改正的小错误 但发现了一些必须改正的小错误 但 是不再需要进行评审是不再需要进行评审 作出决定之后 所有作出决定之后 所有FTR与会者都需要与会者都需要 签名签名 确认 确认 评审指导原则评审指导原则 1 评审工作产品 而不是评审开发者 应温和地指出评审工作产品 而不是评审开发者 应温和地指出 错误 错误 2 制定并遵守日程 制定并遵守日程 3 限制争论和辩驳 留到会后再讨论 限制争论和辩驳 留到会后再讨论 4 阐明问题但不要试图解决问题阐明问题但不要试图解决问题 由开发者会后解决由开发者会后解决 5 做笔记 做笔记 6 限制参与者人数 并坚持事先做准备 限制参与者人数 并坚持事先做准备 7 为每个将要评审的工作产品建立一个检查清单 为每个将要评审的工作产品建立一个检查清单 8 为为FTR分配资源和时间 分配资源和时间 9 对所有评审员进行有意义的培训 对所有评审员进行有意义的培训 10 评审以前做过的评审 评审以前做过的评审 软件团队应根据实际情况选用评审的方法 软件团队应根据实际情况选用评审的方法 评审的度量评审的度量 对评审进行度量 可用来评估评审活动的有效性 对评审进行度量 可用来评估评审活动的有效性 可以收集以下评审度量数据 可以收集以下评审度量数据 工作产品规模工作产品规模WPS 发现的次要错误数发现的次要错误数Errminor 发现的主要错误数发现的主要错误数Errmajor 准备工作量准备工作量Ep 评估工作量评估工作量Ea 返工工作量返工工作量Er 可以进行如下的计算 可以进行如下的计算 总评审工作量总评审工作量Ereview Ep Ea Er 发现的错误总数发现的错误总数Errtot Errminor Errmajor 错误密度错误密度 Errtot WPS 评审的成本效益评审的成本效益 使用评审花费的工作量在早期确实是增加的 但评审使用评审花费的工作量在早期确实是增加的 但评审 的早期投入可以产生效益的早期投入可以产生效益 评审导致测试和修改的评审导致测试和修改的 工作量减少了 工作量减少了 第四节 软件配置管理SCM 软件配置管理软件配置管理SCM 一个未受控制的变更流可以很容易地将一个运行良好一个未受控制的变更流可以很容易地将一个运行良好 的软件项目带入混乱 的软件项目带入混乱 在软件开发过程中 变更不可避免 为了保证产品质在软件开发过程中 变更不可避免 为了保证产品质 量 需要对变更实施有效的管理 即软件配置管理 量 需要对变更实施有效的管理 即软件配置管理 软件配置是在软件过程中产生的所有信息项的总称 每软件配置是在软件过程中产生的所有信息项的总称 每 一项信息被称为软件配置项一项信息被称为软件配置项 SCI 除了软件过程中产生的工作产品除了软件过程中产生的工作产品SCI 通常还将软件工 通常还将软件工 具也列为具也列为SCI 如编译器 浏览器等 如编译器 浏览器等 软件配置管理软件配置管理 SCM 是贯穿整个软件过程中起保护作是贯穿整个软件过程中起保护作 用的普适性活动 用的普适性活动 基线基线 基线是指那些已经通过正式评审和批准的规格说明或基线是指那些已经通过正式评审和批准的规格说明或 产品 它可作为进一步开发的基础 并且只能通过正产品 它可作为进一步开发的基础 并且只能通过正 式的变更控制规程才能修改它 式的变更控制规程才能修改它 当某软件配置项当某软件配置项 通过了评审 它通过了评审 它 将保存到项目数将保存到项目数 据库据库 也称为项目也称为项目 库或中心存储库库或中心存储库 中 成为对应的中 成为对应的 基线 基线 中 心 存 储 库 中 的 内 容 中 心 存 储 库 中 的 内 容 中心存储库的功能中心存储库的功能 SCM中心存储库具有数据库管理系统的一般功能 同中心存储库具有数据库管理系统的一般功能 同 时还需支持下列功能 时还需支持下列功能 版本控制版本控制 每个工作产品都可能有多个版本 中心存储 每个工作产品都可能有多个版本 中心存储 库需保存所有版本 以便于有效地管理产品的发布 并库需保存所有版本 以便于有效地管理产品的发布 并 允许开发者可以返回到早先的版本 允许开发者可以返回到早先的版本 依赖性跟踪和变更管理依赖性跟踪和变更管理 某些 某些SCI之间存在关联 中心之间存在关联 中心 存储库需管理和跟踪这些关系 如某存储库需管理和跟踪这些关系 如某SCI发生变更 则发生变更 则 应提醒开发者要注意哪些应提醒开发者要注意哪些SCI会受其影响 会受其影响 需求跟踪需求跟踪 指明需求和工作产品之间的关联 指明需求和工作产品之间的关联 配置管理配置管理 审核跟踪审核跟踪 SCM过程过程 SCM有有5项任务 项任务 标识标识 变更控制变更控制 版本控制版本控制 配置审核配置审核 报告报告 SCM任务可形成一个任务可形成一个 同心圆的层次 每个同心圆的层次 每个 SCI在其有效生存期在其有效生存期 内都将从内到外地经内都将从内到外地经 历各个层次 历各个层次 版本控制版本控制 版本控制系统应提供版本控制系统应提供4个主要功能 个主要功能 1 存储所有相关配置对象的项目数据库 存储所有相关配置对象的项目数据库 2 存储配置对象的所有版本的版本管理功能 存储配置对象的所有版本的版本管理功能 3 使工程师能收集所有相关配置对象和构造软件特定版使工程师能收集所有相关配置对象和构造软件特定版 本的制作功能 本的制作功能 4 错误跟踪功能 能记录跟踪与每个配置对象相关的重错误跟踪功能 能记录跟踪与每个配置对象相关的重 要问题的状态 要问题的状态 目前业内普遍使用的版本控制工具有 并发版本系目前业内普遍使用的版本控制工具有 并发版本系 统统CVS SubVersion SVN 等 等 变更控制变更控制 版本控制机制和变更控版本控制机制和变更控 制过程集成在一起 实制过程集成在一起 实 现了变更管理的两个主现了变更管理的两个主 要元素 要元素 访问控制访问控制管理哪个工程管理哪个工程 师有权限去访问和修改师有权限去访问和修改 某个特定的配置对象 某