软件质量控制 ppt课件

第第3 3章章 软件质量控制软件质量控制 Software Quality Control *1 3.1 引言 3.1.1 基本概念 一、质量控制 制造业的质量控制开始于二战期间的军事采购 中，是一种采用统计技术的工具 主要活动包括： p建立质量标准：定义每一质 量特性的规约 p制定计划：对制造过程、设备 、采购、培训作出计划 p确定预防措施：分析质量要 素，谨慎控制生产过程 p确定质量符合度 D 确定质量符合度的方法： 解释质量标准 随机抽样检查 抽样审查和度量 度量与标准的对照 评价质量符合度 应用统计方法决定是否接受该批次产品 审查数据、形成文档 D 根据质量控制模型中，工厂把原材料转变为 可用的产品，用以下模型表示： U=F（R） 其中，R是一组材料，U是一组产品 工厂有2个特征： p有明确定义的原材料（ 类型、质量特征） p有明确定义的产品、产 品的缺陷、质量特征 D 质量特征 产品概 念定义 产品质量 特征规约 销售 使用 质量审查 产品制造 设备安装采购与 获取 产品设计 过程工程 制造质量环 质量控制与制造过程的关系 D 产品质量符合度的测量可采用统计抽样方法，用 总缺陷率估计： =D/N 其中，D是存在缺陷的产品数，N是总产品数。如果总 缺陷率总是低于某个可接受值，即可达到较高的置 信率 另一种方法是验收抽样，即抽取K个产品进行审 查，若缺陷产品数小于某个可接受值C，即可认为总 体可接受 D 二、软件质量控制 软件质量控制是一组由开发组织使用的程序 和方法，用以在规定的资金投入和时间限制条 件下，提供满足用户质量要求的软件产品并持 续不断地改善开发过程和开发组织 特征： p软件质量控制是开发组织执 行的一系列过程 p目标是以最低的代价获得客 户满意的产品 p改进开发过程和组织以改善 质量控制 p度量是改善过程和组织的基 础 D 软件 质量特征 软件概 念定义 软件质量 特征规约 销售 使用 质量审查 软件实现 设备安装采购与 获取 软件设计 过程工程 软件质量环 D 三、软件质量控制与质量管理的区别与联系 软件质量控制对开发过程中的软件产品的质量特 性进行连续的收集和反馈，通过质量管理和配置管理 机制，使软件开发进程向着既定的质量目标发展 质量控制是质量管理的路标和动力，质量管理是 质量控制的执行机制 D 质量 管理 技术 开发 质量 控制 配置 管理 客户变更需求 客户需求 管理指令 汇报和报告 错误/问题报告 需求变更 被拒绝的产品 标准和程序 状态/进展报告 阶段产品 质量控制系统的基本结构 D 3.1.2 有关软件质量控制的问题 软件质量控制为什么难？ 软件质量目标难于达到 相对成本和时间，质量问题易被管理者忽略 客户似乎更关心预算和交付时间 软件质量控制需要增加成本 软件开发是人的智力活动，有较大易变性 质量控制成本有哪些？ 前期成本：制定计划、执行计划和前期的纠错 评估成本：评估产品、过程质量 内部工作失效：因过程、产品缺陷返工 外部失效成本：维护费用 D 如何理解软件质量控制的重要性？ 软件质量控制的目标是为了获得更高的开发效率和 效益，为客户提供高质量的软件产品 p某些质量关键的软件产品要 求更高的质量特性 p质量控制是开发者及时发现 早期缺陷的主要方法 p实行TQC可避免返工而节省 时间和经费 p实施TQC可获得较高质量的 产品，较少维护费用 由谁来进行质量控制？ 客户：间接控制系统需求、资金分配、开发计划和过程 里程碑、选择组织、质量控制手段 开发商：直接控制确定技术、方法和程序 D 什么时候进行质量控制？ 在整个软件生命周期中都该进行 不同阶段活动不同，应采用不同技术 预开发开发维护 概念定义需求分析修复 初步制作设计改进 系统需求编码、单元测试适应性修改 资源集成测试和确认测试 招标、合同验收交付 D 3.1.3 软件质量控制的一般方法 目标问题度量法 通过确定软件质量目标并连续监视这些目标是否达到来控制 软件质量 具体方法是： 对每一个项目要素（产品、过程和资源）规定明确 的具体目标 对每一目标建立一系列要回答的问题，问题的答案 应能回答目标是否达到，并有助于目标的量化 将对问题的回答映射到软件质量等级的度量上，并 得出是否达到目标的结论 收集并管理数据 D 目标：改善软件的可维护性 问题： 可维护性开发过程对于预防缺陷是有效的吗？ 正在发生的缺陷是什么？ 产生缺陷的原因是什么？ 度量： 产品的缺陷密度 按缺陷类别划分的缺陷发生频率 缺陷产生的频率分布、分阶段发生缺陷的频率分布 运行维护 可维护性开发 开发预开发 例：软件的可维护性开发 D 鱼骨图 可维护性缺陷 文档 代码 环境 工具 评审 计划 D 风险管理法 识别和控制软件开发过程 中对软件质量危害最大的 因素（SEI） 主要内容： 选择风险估计和 控制技术 进行风险估计和 控制 基本步骤： 根据经验识别项目要素的 有关风险 评估风险发生的概率和发 生的代价 按发生概率和代价划分风 险等级并排序 在项目限定条件下选择控 制风险的技术并制定计划 执行计划并监视进程 持续评估风险状态并采取 正确的措施 D 跟踪 识别 分析 计划 控制 在风险转化为 问题前发现 对风险的影响 、发生概率等 进行分析 基于分析的 决策 弱化、转移 、控制风险 监督风险，检查 对策的适应性 SEI的风险管理模型 D 项目各阶段的风险 阶段可能面临的风险问题 计划 目标不清 范围不清 缺少沟通 业务不清 缺乏可行性分析 设计 缺乏经验 没有变更控制计划 项目计划仓促（进度风险） 设计疏漏 实施 缺乏环境 设计错误 开发能力 项目范围变更 进度变更 人员变更 内部沟通不畅 备选方案无效 测试计划不充分或缺少经验 发布 质量差 客户不满意 设备未按时到货 资金不能及时回收 D 风险严重性等级 影响程度标准等级 危险 严重影响项目，可能导致项目取消或直接失 败 109 高影响进度，导致延期，客户抱怨严重87 中影响预算或软件性能差，客户不满意65 低影响进程但很快解决，客户有些不满43 小影响较小，客户未察觉或认可20 D 风险控制方法 风险避免 通过变更计划消除风险的触发条件 如采用成熟技术、增加资源、减少软件范围 风险弱化 降低风险发生的概率 如简化流程、更多测试、开发原型系统 风险承担 制定应急方案，随机应变 风险转移 将风险发生的结果连同应对权利转移给有承受能力 的第三方 D 与目标问题度量法相比 p风险管理法中质量控制技术的使用目的更 有针对性，直接针对最具危险的、严重影响质 量的关键因素 p正确地选择质量控制技术是风险管理法的 重要部分，而目标问题度量法更多地关注质量 目标及监视它们的改善进程 D PDCA质量控制法 PDCA是一个基于统计方法的迭 代过程，由W.E.Deming提出， 已被作为国际标准。 Plan（计划）：确定产品的 质量、过程和资源计划，明确 目标和配置标准 目标是量化的 Do（实施）：根据已确定的 过程实施计划活动 实施过程中质量被构造进产品 ，缺陷也同时发生 Check（检查）：评审和测 试产品，确定已达到目标 Action（改进）：纠正已知 缺陷，确认待改进因素 Plan Do Check Action Deming cycle D PDCA的特点： p持续的采用PDCA方法将有助于产品过程的不 断改善，从而提高产品质量 p通过持续地收集数据和评审不断提高产品的质 量目标 pPDCA更关注过程、资源和质量的度量，并以 此为基础寻找产生缺陷的原因和发现改善质量的机 会 D 3.2 全面软件质量控制 3.2.1 全面软件质量控制模型 TSQC是指导开发者计划和控制软件质量的框架， TSQC模型用来描述各组成要素间的关系 确定质量目标 提高质量开发质量 评估质量 质量控制参数 产品、过程、资源 定义 改善 估计 度量 计划Plan 改进 Action 实施 Do 检查Check D TSQC过程是一个调节和控制那些影响软件质 量的参数的过程 影响软件质量的参数包括： 产品：所有可交付物 过程：所有活动的集合 资源：活动的物质基础（人力、技术、设备、时间、资金等） TSQC过程是PDCA四个活动的循环： 计划Plan：确定参数要求 实施Do：根据要求开展活动 检查Check：通过评审、度量、测试，确认满足要求 改进Action：纠正参数要求，再开发 D 3.2.2 TSQC控制参数 参数不是孤立的，需要综合调节和平衡 产品 产品是软件生命其中某个过程的输入和输出， 或者是对最终产品的需求、最终产品本身或开发过 程中产生的任何中间产品 这些产品包括计划、报告、编码、数据 D p 中间产品是某个阶段的输出，也是后续阶段的输入 p 作为输入的产品的质量不会比过程的输出更高 p 产品的缺陷在后续阶段不会自动消失，影响会更大 过程1过程2过程n 输出1 输入2 输出2输入n 输入1输出n 反馈及纠错 D 过程 过程是为完成开发、维护和为保证软件质量所 进行的管理和技术活动 管理过程：包括计划、监控、资源分配 、组织 技术过程：以软件工程方法为特征，包 括工具 对于软件质量，过程分两类： 质量设计和构造过程 质量检查过程 D 过程对质量的影响： 产品质量是通过开发过程设计并构造进产品 的，同时也引入了缺陷 产品的质量是通过检查过程检查并确认的 每个过程所涉及的组织的数量以及它们之间 的关系都直接影响引入缺陷的概率和纠正错误 的概率 在软件开发过程中人的心理、社会、组织因 素对产品生产率和质量有强烈影响 D 资源 资源是指为得到要求的产品质量，过程所需的时间、资金、 人力、设备等 资源的数量和质量影响产品质量： 人力因素是影响软件质量和生产率的主要因素 时间、资金不足将削弱软件质量控制活动 不充分、不合适、不可靠的开发环境和测试环境会 使缺陷率增加，发现并纠正错误的时间和资金也将增 加 D 3.2.3 全面软件质量控制的实施过程 软件质量控制过程是在软件生命期的各个阶段，应 用TSQC模型对产品、过程、资源的控制过程 计划 实施 检查 改进 计划 实施 检查 改进 计划 实施 检查 改进 计划实施检查 改进 预开发开发维护 D 软件质量管理的14点准则： 制定坚定的改进质量的目标，满足客户需要 管理者必承担责任 停止使用大规模审查（尤其是测试）方法提高质量， 太晚也不可靠 不要仅靠价格决定业务，选择客户并作为长期伙伴 持续改进过程以提高质量和生产率，降低成本 进行工作培训 确立领导地位 消除恐惧，让员工更有效地工作 消除领域障碍，建立团队精神 不以口号要求零缺陷、高效率 不要使用量化的目标和任务分解 建立工艺尊严，关注质量而不是进度 为所有人建立教育和自我提高机制 改革是工作的一部分，每个人都该为改革做贡献 D 影响软件质量的7个问题： 缺少满足客户要求的坚定目标 关注短期进度 绩效考核、评审 专业人员、经理的流动性 单纯依赖可见的数字管理 过高的人力成本 过高的维护成本 D 软件质量的障碍： 希望有更高效的解决方案，真正的方案是知识和信心+勤奋 相信硬件会改进过程。质量是人造的 “我的问题不同”。没有不同寻常的软件质量问题 落后的教育。热衷于技术而忽略质量教育 糟糕的统计方法教育 “已经够好了，没有时间做得更好”。但有时间测试、修改错误 “我们的质量控制人员解决所有问题”。质量是管理者责任 “所有问题都是程序员的错”。其实是管理员雇用、培训、管理程序员 错误的起点。质量改进是长期的，需要持续关注 “我们曾建立了质量控制”。质量控制是日常工作 使用神奇的CASE工具而忽略软件工程的知识基础 相信只有满足规格是必要的。需要持续改进 零缺陷错误。持续改进的结果不是零缺陷，也不能保证客户满意 测试原型不足。测试原型的目的是学习，然后强化系统 “任何要帮助我们的人都必须懂得我们的系统”。只是有必要懂得必须 要知道的 D 预开发阶段 主要活动包括买主与客户研究建立需求，发布招标请求，选择 资源，与开发者签订合同等 买主和客户的工作： pP：计划质量控制过程；选择开发标准；选择工具和 方法 pD：制定招标方案，包括功能和质量需求规格、任务 描述、资源选择标准、招标书评价指导、进度计划数据 、交付产品 pC：检查招标方案质量，研究承包商的反应 pA：根据取得的经验和数据，改进质量控制计划 D 开发者的工作： pP：确定要开发的中间产品 pD：制定开发方案，说明技术和工艺 pC：检查资金、人力资源、开发设施、计划进度的适 当性 pA：提出改善产品质量的措施 D 开发阶段 开发阶段的质量控制活动涵盖从产品开发到移交产品并获得客 户的满意度结束的全过程 代表性工作有： pP：分析需求和风险，制定详细的开发过程、使用资 源、产品的质量控制计划，并取得客户的认可 pD：执行质量控制计划 pC：与客户一起检查计划与预期结果得以执行 pA：改善计划、过程、资源分配及产品，重新认识风 险 D 维护阶段 维护阶段的活动主要是对产品的更新，其目的是修复缺 陷、适应需求变更或提高性能 主要质量控制活动有： pP：根据客户反馈或审查结果，制定软件更新质 量控制计划 pD：实施软件更新并控制质量 pC：检查是否达到质量目标，主要是缺陷修复率 等 pA：收集客户反馈，研究软件产品的性能、可维 护性等质量要素 D 3.3 软件质量控制技术 3.3.1 软件质量控制技术的特征 p软件生命周期的阶段可用性：不同阶段不同技 术 p综合使用“预防性”和“检测性”技术 预防性技术：用于避免错误，如Plan 检测性技术：用于查找产品、过程、资源的 缺陷，如Check p不同技术对不同的质量要素有影响 D 软 件 质 量 控 制 技 术 的 生 命 周 期 特 征 质量控制技术预开发开发维护 因果分析 配置管理 独立的确认与验证 IV&V 检查 管理度量 性能工程 初样 可靠性建模 软件审计 SEI能力评估 软件设计 度量 软件开发能力/资格评审 软件工程环境 软件工程实践 软件工程初样 软件质量保障 软件问题报 告分析 标准 测试 D 软件质量控制技术的控制类型 p预防性技术：通过为过程、产品和资源设立标 准等途径，来避免在产品开发过程中产生缺陷 p检测性技术：用于发现和纠正缺陷，甚至分析 产生缺陷的原因 D 质量控制技术预防性特征检测性特征 因果分析分析原因，提出改进建 议，预防出错 配置管理控制软件配置，防止引 入新的错误 独立的确认与验证 IV&V及时发现 和纠正需求、 设计 、编码 的错误 检查在测试 之前检查 并纠正 设计 和编码 的缺陷 检查 和纠正设计 、编码 缺陷 管理度量检查 早期问题 并调整质 量控制参数 性能工程提供某种方法避免潜在的 性能问题 度量实际 性能，确认是 否满足需求 初样对早期需求和问题 的确 认，用户界面设计 确认 可靠性建模度量软件的可靠性，并 预测 附加测试 软件审计识别 关键风险 并提出规 避方法 检测 超时、超支和质量 缺陷 SEI软件能力评估评估组织 的开发过 程， 确定成熟度等级 D 质量控制技术预防性特征检测性特征 软件设计 度量检查 早期的设计问题 并 修改设计 检查 并纠正设计 和编码 问题 软件开发能力/资格评审对比成熟的开发过 程， 评估开发组织 软件工程环境借助工具和程序进行一致 性检查 软件工程实践使客户能够评 价开发过 程和开发商 软件工程初样能较早检查 出开发过 程 的缺陷，防止对需求说明 的内容、形式的理解错误 软件质量保障基于标准，检查 、分析 产品已发现错误 软件问题报 告分析配合开发过 程，跟踪具 体问题 的解决 标准建立过程、产品的一致性 测试确认满 足要求 D 软件质量控制参数对质量参数的影响 质量控制技术受影响的质量控制参数 产品过程资源 因果分析需求分析、开发与 测试 人力、设备 、进 度 配置管理需求、接口、编码 及文档 配置管理、软件质 量保障 独立的确认与验证 需求、设计 、编 码及测试 文档 需求分析、开发与 测试 设备 检查设计 、编码 及文 档 管理度量需求、设计 、编 码 需求分析、开发与 测试 、开发工具、 软件状态 计算机资源、人 力、资金、进度 性能工程设计 、编码 、定 时分配、规模估计 测试 初样需求、客户界面开发与测试设备 可靠性建模设计 、编码为测试 、评估确 定进度计划 软件审计需求、接口、定时 分配和规模估计 需求分析、开发与 测试 、初样工程、 配置管理、SQA 人力、管理、开 发和测试设备 D 质量控制技术受影响的质量控制参数 产品过程资源 SEI软件能力评估开发与测试 软件开发能力/资格评 审 开发与测试 软件工程环境开发与测试工具集、设备 软件工程实践开发与测试 、开发 工具 人力、工具集 、设备 软件工程初样开发与测试 、开发 工具 人力、工具集 、设备 软件质量保障需求、设计 、 编码 、测试 文 档 分析、开发、测试 、SQA 软件问题报 告分析软件问题 文档开发与测试 、SQA 、配置管理 标准接口标准软件开发和测试 、 获取管理 人力、工具集 、设备 测试编码 、测试 和 文档 测试 程序 D 3.3.2 软件质量控制问题与质量控制技术 最终产品的质量需求是什么？ 所需技术： p运行概念文档：描述软件的运行环境和方式， 是对软件动态特征的描述 p招标建议书的准备和评审：需制定质量标准并 确保需求清楚、详尽且可验证 p初样：系统的有限实现，用于描述复杂的或有 争议的需求 D 选择什么样的开发组织？ 选择开发组织使客户的重要工作。所需技术： p招标建议书的准备和评审：建议书中包含 选择标准，竟标者须提供足够信息应标 开发组织的软件工程方法、标准、实践和开发 环境（工具及设备） 是否拥有相应的业务领域知识能力 是否拥有必需的经验，是否熟悉所需要的开发 过程 所提出的软件工程方法和过程是否成熟 能提供的质量保障和配置管理措施 对项目的承诺和对开发管理技术的理解程度 组织的内部结构及与其他组织的关系，任务分 配方案 技术方案的健全性 费用、进度计划的可信性D pSEI软件能力评估：用于评估开发组织控制和 改进软件开发过程并使用现代软件工程技术的能力 SEI的CMM评估可以在不同开发组织之间、同一组 织的不同时间点上较客观、一致地评估组织的软件开 发能力 p软件开发能力/资格评审：用于评估开发组织开 发一个具体项目的能力 p软件工程实践：借助微型开发，客户评估开发 商的过程、工具和技术能力，评估领域经验 D 为预防软件质量缺陷应该做点儿什么？ 客户和开发上都有必要采取措施以预防缺陷的产生，客户可以 提出要求，开发商更应该主动行动 p标准：即活动规范，分三类 客户标准：提供管理和维护程 序的一致性 开发组织标准：目的是使过程 可重复、对工具的投资与过程相适应、训练 开发人员、使开发过程可度量和改进，客户 需要了解开发组织标准 技术标准：用于描述功能部件 和接口，包括 良好定义的技术规格 说明 与其他系统的互操作 性 设计方法的可维护性 接口的通用性 产品的可移植性、灵 活性和可适应性 D p软件工程初样：是由客户要求的针对原型系统的开发 实践，目的是要证明开发商的开发能力。初样的技术指 标中包含一组指令，以便客户的评审。 使用初样的目的包括： 便于客户了解开发组织的过程 和能力 显示软件的开发环境和开发组 织的理解程度 了解开发组织对软件应用环境 和工程原理的理解水平 根据初样的经验和教训改进开 发过程 可以将初样作为实际系统的一 部分 p配置管理：目的是在整个生命期内控制配置的变化， 保持配置的完整性和可追踪性。步骤为： 标志配置项的功能部件及特性 ，建立文档 控制配置项特性的变化 记录并存储状态报告 D p性能工程：是估计、度量和控制软件时效性的活动， 由客户、开发组分别或共同执行。包括以下性能特征： 执行时间：即执行一个特定任 务的时间 反应时间：即系统对输入做出 反应的时间 吞吐量：即系统完成一特定任 务或处理一特定加载的速率 储备：即未使用单可用的处理 时间、输入/输出容量及对需求变更的适应性 性能工程技术包括分析建模、 仿真、软硬件选择等 D p软件工程环境：由一组集成的自动化工具组成，用于制成 开发组织的开发过程。对质量的影响包括： 对软件及相关文档的产生、修改和 管理提供帮助 对各种文档及相关设计的一致性检 查 使配置管理自动化 检查相对编码标准的偏差 度量测试覆盖 从其他形式的文档产生代码，如图 、表、字典等 p重用：即利用已开发的软件或部件，目的是提高开发效率 和质量。可重用的软件包括： 已经开发并取得充分经验的软件 已经广泛使用并具有完整文档，可 靠且支持好的商业软件 客户提供的类似软件 对以上软件进行修改并已经确认的 软件 D 怎样检查软件质量？ 检查质量既包括预测质量也包括评估质量，既可以连续进行也可 以设置检查点 主要技术包括： p评审和审计 客户评审：属于计划评审，与阶 段开发活动进度吻合。目的是检查开发进度、 质量和预防缺陷、理解错误 软件审计：是客户对开发过程的 关键点的评审，目的是： 评估开发组织是否完成 了必要的需求分析和系统设计，是否为软 件的初步设计做好了准备 评估开发组织是否有合 适的开发计划 评估需求规格说明和需 求分解的完整性 评审时效性分析、客户 界面设计、测试理论和计划及设计准备 检查：是开发者在测试前进行的 评审，目的是及早发现和纠正错误。可以是正 式的或非正式的 D p独立的确认和验证IV&V 在软件开发过程中，由客户雇用某独立组织对照技术 规格说明评估软件产品，IV&V连续、客观地向客户提 供可视的软件质量和开发状态 IV&V过程包括需求验证、设计验证、编码验证、程序 确认、文档验证等 p软件质量保障 是由开发者执行的一系列质量控制活动，也可以由组 织内独立的小组完成，主要是检查过程、程序与标准 的一致性 D p测试 通常，开发过程中的测试由开发者完成，客户的测试是在 开发结束时或在向客户提交了某个版本时进行的，客户也 可以通过以下方式介入开发者的测试活动： 评审和批准开发者的测试计划和 程序 提供测试设备、工具和人员 提供测试环境 测试等级包括： 非正式测试 初步的鉴定测试：针对特定配置 项，客户可不在 正式的鉴定测试：客户到现场， 由独立机构组织 开发性测试：在开发环境下的集 成测试，客户参与 验收测试 起始运行测试：在客户运行环境 下的确认测试 正式运行测试：目的是客户学习 D p可靠性建模 软件可靠性建模是用统计学方法分析软件故障的一种 方法，即在软件测试或软件运行、维护期间，收集软 件发生故障的时间数据，或收集在一定时间间隔内的 故障数据，并运用于一个或几个软件可靠性模型中， 以预测软件可靠性的增长情况 可靠性建模应用于对软件可靠性有明确规定的场合， 也适用于预测测试过程达到可靠性要求的所需时间的 场合 D 在检查点应该获得哪些信息？ 检查点是为评估和预测软件质量设置的，应收集的信息包 括： p计划：开发者是如何执行开发活 动的 p状态：已完成了多少工作，使用 了多少资源 p产品文档：外部、内部的描述 p客户文档：使用指南，维护文档 p证明软件质量的产品分析 可使用的技术包括： p软件问题报告分析：用于度量质 量、预测进度和改进过程 p模块开发卷宗 审计、检查和评审过程 ，分析单元问题 确定是否遵守了组织的 或计划的SQA标准 有助于配置管理 D 开发组织为改善过程和资源，应做些什么？ 许多技术可用于开发组织改善过程和资源，比较重要的有 ： 因果分析：目的在于辨别有内在联系的缺陷的产生原因。 对当前项目，可以改变过程或改变资源以避免缺陷的产生 。对将来项目，可修改、改善过程、资源标准 SEI自我评价：开发组织通过自我评估以确定开发过程的 薄弱环节。不同于SEI能力评估，自我评估由开发组织内部 实施，结果不与客户共享 D 3.3.3 软件质量控制技术的选择 选择控制技术需考虑的因素 有些技术是任何时候都要考虑的，尽管它们的使用等级 可以变化 要考虑所选技术的效益并使需求、风险和限制得到平衡 有些技术是冗余的或是矛盾的，只需或只能选择其一 有些技术是互补的，同时使用可能提高效益 控制技术的选用不能与约定相矛盾 有些技术只能用于特定的开发阶段或特定的开发活动中 检测性技术宜尽早使用，以防早期缺陷的产生和传播 对于高风险的设计和程序，质量控制活动和检查点的安 排时间上不要隔太久 D 软件质量 控制的核心 技术 根据理论和实践 ，有些核心技术 在质量控制时是 必需的，应无条 件选用，而不必 考虑系统的规模 、已有的经验等 因素 核心技术执行人 招标方案的评审客户 配置管理开发商、客户 软件开发计划开发商 培训开发商、客户 排查开发商 测试开发商、客户 SQA开发商 软件问题报 告分析开发商、客户 D 3.4 全面软件质量控制实践 质量控制计划的编制 3.4.1 概述 软件质量控制计划编制准则 软件质量控制是通过控制产品、过程和资源得到的 质量控制技术的选择取决于与系统最重要的需求相 关的风险等级 资源应更早地分配在针对特殊问题的研究、评估、 初样、仿真等程序上 软件质量投资必须是可承担的 如果提供的资金和时间太少，受此限制，任何质量 控制技术都得不到可接受的质量 相对于检测性技术，应优先使用预防性质量控制技 术 改进开发组织的过程是持续和渐进的 D 软件质量控制计划编制过程 计计 划划 检查检查 质量评价、估计 实施实施 计划、程序执行 质量控制计划： 控制技术 资源 评估标准 检查点 度量： 产品 过程 资源 改进改进： 纠错 程序计划： 活动 资源 进度 开发方法 移交产品 预算 项目的具体 限制和需求 历史经验： 风险、开发方 法、质量控制 技术、数据 产品 改进改进 D 软件质量控制计划的内容 全面质量控制计划 1.0 背景 对系统任务的简要描述，预计 的和实际 的软件规模 ，系统的表示和软件的结构 2.0 软件质量需求系统和软件的质量因素及质量需求的优先顺序排列 3.0 限制条件 客户与开发组织 关于产品、过程、资源的预定需求 和限制 4.0 软件风险当前特定风险 或风险 区域的严重性等级列表 5.0 全面软件质量 控制过程概述 客户和开发组织 所选定的质量控制活动的进度，相 关的风险 ，设置的检查 点的时刻，检查 的目的 6.0 全面软件质量 控制活动 p描述每一质量控制活动，包括活动的目的、执行 者、执行时间 等 p描述每一检查 点：检查 点安排的时间 、能够获 得 的信息，计划的检查 活动和最低限的检查 活动 D 软件开发前的质量控制计划编制 主要回答以下问题： p想要得到的是什么？ p那些因素妨碍想要得到的？ p未得到想要得到的可以做些什么？ 注意以下问题： p质量控制计划是关键，要认真编制、仔细评审 p开发期间要持续检查已确认计划的有效性 p当条件变化时，要及时升级计划 D 3.4.2 确定软件质量需求 高质量的产品来源于高质量的需求 p质量需求是针对整个系统的，而不仅仅是软件，对需求 的描述应反映质量因素的重要性 p对重要的质量需求须详细分析相应的质量因素 p对质量需求及相关质量要素要仔细评审 软件质量需求 买主成本、资源使用的有效性 客户/操作者功能、可靠性、易用性 维护者易改性、可扩展 D 质量因素定 义 效率资源（存储空间、处理时间 、通信时间 等）的利用率 完整性在规定时间 内，在未经授权访问编码 或数据时，无故 障工作的能力 可靠性在规定时间 内，无故障正常运行的概率 健壮性在规定时间 内，部分失效时，关键功能无故障运行的 能力 可用性使用系统（培训和操作）的相对难 易程度 正确性产品与技术指标规 格说明和标准的一致程度 可维护 性在规定时间 内，确认并纠正缺陷的难易度 可验证 性验证规 定的功能和性能的相对难 易度 可扩展性增强、扩充功能或提高性能的相对难 易度 灵活性为满 足其他要求而改变功能、数据的难易程度 互操作性系统与其他系统交接的难易程度 可移植性改变系统运行环境的相对难 易程度 重用性将系统部件及女性变换 以集成到其他系统的难易程度 软 件 质 量 因 素 的 定 义 D 3.4.3 确认限制条件 限制条件是强加在开发人员身上的，约束了对质量控制技术 的选择 可能的限制条件包括： p进度：交付日期，中间里程碑或决策点 p资金：数量和来源 p所涉及的部门：客户、测试组织及其他组织之间的关 系 p其他部门资源：能提供的设备、信息和可参加的活动 p合同形式及条件：客户关系 p对开发者的要求：规范、条件和标准的约束 D 3.4.4 识别风险 风险的根源和引发风险的原因 风险的根源与三大质量控制参数相关 参数风险 的根源风险 的原因 产品 系统需求、系统/产品技术 规格说明 定义、困难、稳定性、清晰度 产品接口、接口控制文档正确性、完整性、适合性 过程软件获取过程 稳定性、完整性、组织 复杂性 、管理控制 过程需求分析正确性、完整性 过程软件开发和测试过 程成熟性 资源 开发人员、客户提供的设 备、信息及参加活动的质量 能力、资格、可靠性、可用性 、稳定性 资源预算、进度可用性、稳定性 D 软件质量的风险是变化的，有三个必须进行风险分析的时间 ： 在选择开发商前的预开发：因不确定因素多而更重 要 在选定开发商后的预开发：随开发商的理解会消除 部分风险，也会带来新的风险 开发期间：质量度量和控制有助于消除风险 风险分析阶段风险区域 选择开发商前的预开 发 需求、客户、进度计划和预算 选定开发商后的预开发 需求、客户、开发者、进度计划 和预算 开发阶段 需求、设计和测试、维护计 划、 客户、进度计划和预算 D 风险估计 风险估计既是一种 质量控制活动也是 质量控制技术的基 础 软件质量控制计划编制期间的 风险估计模型 历史数据和经验产品需求限制条件 计划计划 执行风险估计 选择质量 控制技术 实施实施 研究分析 实施实施 执行技术 检查检查检查检查 已知风险 未知风险 管理 质量度量 风险识别 度量 改改 进进 D 3.4.5 对质量控制技术选择方案的提炼 对已选择的质量控制技术应该再提炼，以进一步节省