质量管理体系软件,软件开发质量管理

本章介绍软件质量管理的基本概念

全面的软件质量管理

缺陷跟踪

缺陷的去除和预防

软件质量的一般测量

个案研究

第一节软件质量管理的基本概念软件质量是指软件在多大程度上符合用户的需求。 具体地说，软件质量是指软件适合明确描述的功能和性能的需要，以及所有专业开发的软件应该具有的隐含特征的程度。 用户需求是衡量软件质量的基础。 除了明确定义的需求外，还满足隐含的需求。 软件质量的重要性

软件质量问题可能导致经济损失和灾难性后果。 质量是软件产品和软件组织的生命线。 质量问题会增加软件产品开发和维护的成本。 软件质量属性

McCall软件质量模型

形成软件质量软件质量形成软件质量形成于整个软件开发过程，而不是事后检验(如测试)。 从20世纪80年代开始，质量管理从单一的关注产品转变为关注生产优质产品的过程，并将过程的作用扩展到了组织运营的各个领域。 质量要通过过程真正提高软件的质量，需要一个成熟稳定的软件过程。

由于特殊原因导致工艺性能不稳定。 杜绝特殊原因，稳定工艺性能，防止质量问题发生。

质量成本(CoQ )质量成本是为实现产品或服务质量而付出的所有努力的总成本，包括预防成本(不将缺陷引入软件的预防工作所需的费用)三部分。 评估成本：检查软件是否包含缺陷所需的费用。 失效成本：修复缺陷工作所需的成本。

认证/应用/故障(PAF )成本模型

与项目末期检测和排除缺陷相比，项目早期预防和检测缺陷更有效，也节约成本。

软件项目质量管理的目标软件项目质量管理的目标无疑是保证软件产品的质量但对一个具体的软件项目来说，保证软件产品的质量并不意味着追求“完美的质量”。 大多数常见软件不需要付出巨大的成本来追求“零缺陷”。 如果追求完美的质量导致严重的成本超支和日程延迟，并且获得的质量提高给用户带来的利益极其有限，就必须弥补损失。 在软件项目中，对于软件的各种质量属性，并不是把它们放在同等重要的位置，而是项目组织应该关注那些用户最关心的、对软件整体质量影响最大的质量属性，这些质量属性被称为“质量要素” 软件质量管理的目标是在整个项目目标的约束下，软件质量满足用户的需求。 第二节全面软件质量管理

质量管理计划质量管理计划是指为了实现项目的质量目标，对项目的质量管理工作进行全面的计划。 软件项目质量管理计划一般应当满足以下要求： 确定项目要实现的质量目标和所有特性要求； 确定确定项目内质量活动和质量管理流程的项目采用的控制手段和相应的验证手段和方法； 确定并准备质量记录。 质量管理计划一般包括以下主要内容。 质量要素分析；

质量目标；

人员和责任；

流程检查计划；

技术评审计划；

软件测试计划；

缺陷跟踪工具。

(模板)“审阅”(Review )审阅相当于软件开发过程的“过滤器”，在软件开发的某个时间点对半成品进行审阅，以发现并排除错误，避免在以后的阶段留下错误。 因此，评论对于保证软件质量，降低开发成本是极其重要的。 审查可以在软件项目的任何阶段执行，无需等待软件变为可执行状态，从而可以尽早发现和消除缺陷，提高软件质量，降低开发成本。 根据统计数据，审查中发现了75%的设计错误。 技术评审(Technical Review )技术评审(Technical Review，TR )是指对工作成果进行审核分析，发现其中的缺陷，帮助开发者及时消除缺陷。 技术审查的主要对象：要求和设计规格的说明、代码、测试计划、用户手册等。 正式技术评审和非正式技术评审分为正式技术评审和非正式技术评审两种基本类型，前者要求严格，需要召开评审会议，参与者较多。 后者形式灵活，通常在伙伴之间进行，不需要召开审查会议，参加者相对较少。 一般来说，可以对重要性和复杂性较高的工作成果进行正式技术审查，对重要性和复杂性相对较低的工作成果进行非正式技术审查。 技术评审会议的技术评审以会议形式进行，一般有评审会议通常3~5人参加的限制。 会议前评委应做好准备，但人均准备时间不超过2小时。 审查会议的时间不超过两个小时。 技术审查只关注软件的特定部分，例如要求和设计规格说明的一部分。 集中审查的焦点，会提高发现错误的可能性。 正式技术审查程序的审查组长将审查对象的资料分发给各审查者，审查者(包括审查组长)对资料进行审查，记录相关要点，为审查会议做准备。 召开评审会议。 审阅会议由审阅发起人、审阅者和被审阅的开发人员参加。 其中一人充当记者，负责记录会议中发现的所有问题。 说明开发小组提出的审查对象。 同时审查者可以向开发者提问，提出建议和要求，并展开讨论。 讨论中发现问题或错误，由记录员记录。 会议结束时，必须作出以下三项决定之一： 不需要接受和修改产品。 因为错误很严重，所以拒绝接受。 等错误纠正后，再进行另一次审查。 暂时接受此产品，但需要修改某些部分，修改后无需进行其他评论。 决定后，所有参加会议的人签字，确认会议结果。 技术评审会议后，应完成《评审总结报告》。 其内容如下。

评审对象是什么？谁参加了评审？评审的结论是什么？有哪些重要发现？评审会议上所记录的问题列表通常作为评审总结报告的附件。跟踪与审核。开发者修改工作成果，消除已发现的缺陷。由指定的审查人员跟踪每个缺陷的状态，直到工作成果合格为止。技术评审的注意事项评审产品，而不是评审人。评审会议的气氛要轻松和愉快，注意提出问题时的方式和态度，不要让产品开发者产生被审问的感受。制订评审会议的议程并遵守进度。不要让会议过分拖延。问题的具体解决方案可以在会后讨论。使用检查清单。为不同的软件产品（需求、设计、代码等）开发检查清单，在检查清单中列出所有重要的、常见的问题，这样可以使评审会议聚焦于一些重要问题。同行评审（Peer Review）同行评审是一种特殊类型的技术评审。由与工作产品开发人员具有同等背景和能力的人员对工作产品进行技术评审，因此非常有利于发现工作产品中的问题。代码评审（Code Review）编码阶段的一种技术评审，由一组人员对程序进行阅读和静态分析，可以很有效地检查程序代码中的缺陷。评审内容：程序是否符合编码规范，程序结构是否合理，算法和程序逻辑是否正确，程序性能怎样等。很多程序逻辑错误很难通过测试发现。软件测试软件测试是通过执行软件来发现缺陷，它是控制软件质量的重要手段和关键活动。软件测试要在有了软件编码后才能执行，但测试的计划和设计应在项目前期就开始。测试计划确定了测试的内容和目标，明确了测试范围，制定了测试策略和用例设计方法，安排人力和设备资源等。测试设计就是利用各种测试用例设计方法，编写测试用例，并准备测试数据，开发辅助测试工具和编写自动化测试脚本。在测试执行阶段，要执行测试用例，发现和记录软件缺陷。测试执行完毕后，还要对测试的结果进行分析总结，撰写测试报告，给出结论。 过程检查过程检查就是检查软件项目的工作过程和工作成果是否符合既定的规范。在软件项目中，如果工作过程和工作成果不合规范，很可能会导致质量问题。例如，代码和文档的版本及其命名不符合版本控制规范，重要的变更不遵循变更控制流程，都有可能造成开发工作的混乱，进而导致产品质量下降。 工作过程和工作成果符合既定规范，也并不意味着产品质量一定能得到保证。因此过程检查只是保证质量的一个必要条件，而不是充分条件，它还需要与技术评审、软件测试、缺陷跟踪、过程改进等各方面措施互相配合，共同促进软件质量的提高。 对过程检查要事先做出规划，确定主要检查项、检查时间（或频度）、负责人等。过程检查计划一般包含在软件项目质量管理计划中。软件过程改进软件过程（Software Process）是指开发和维护软件产品的活动、技术、实践的集合。软件过程描述了为了开发和维护用户所需的软件，什么人（who）、在什么时候（when）、做什么事（what）以及怎样做（how）。软件开发的过程观认为，软件是由一组软件过程生产的，因此软件质量和生产率在很大程度上是由软件过程的质量和有效性决定的，而软件过程可以被定义、控制、度量和不断改进。所谓软件过程改进是指根据实践中对软件过程的使用情况，对软件过程中的偏差和不足之处进行不断优化。软件过程改进是面向整个软件组织的。一个成熟的软件组织应该对其软件过程进行定义，形成一套规范的、可重用的软件过程，称为“组织级过程资产”。软件过程改进示意图

软件过程改进可遵循某种过程改进模型（如CMMI）来执行。 第三节 缺陷跟踪缺陷跟踪是指从缺陷被发现开始到被改正为止的整个跟踪流程。

缺陷跟踪工具缺陷跟踪一般需要软件工具支持。常用的工具有Bugzilla、ClearQuest、JIRA、TrackRecord 等。缺陷跟踪工具BugzillaBugzilla是Mozilla公司提供的一个开源的缺陷跟踪工具，在全世界拥有大量用户。它能够为软件组织建立一个完善的缺陷跟踪体系，包括报告缺陷、查询缺陷记录并产生报表、处理解决缺陷、管理员系统初始化和设置等。Bugzilla的功能和特点：基于Web方式运行，易于掌握。缺陷从最初的报告到最后的关闭，都有详细的操作记录，确保了缺陷不会被忽略，并允许用户在检查缺陷状态时获取历史记录。提供强大的查询匹配能力，能根据各种条件组合进行缺陷查询，并能够记忆搜索条件。Bugzilla的特点：当缺陷状态发生改变时，会自动发送邮件通知相关责任人。自带基于数据库的报表生成功能，主要生成两类图表：基于表格的视图和图形视图（条形图、线图、饼状图）。Bugzilla的基本操作说明报告缺陷分配缺陷处理缺陷验证已解决的缺陷第四节 缺陷移除和预防为了提高软件质量，必须在软件开发的各阶段尽量多地移除缺陷，并通过缺陷预防尽量少地引入缺陷。

缺陷移除效率软件开发阶段的缺陷移除效率是衡量该阶段软件过程能力的一个重要指标，该指标可以定义为：

例如，在某软件项目的高层设计阶段通过设计审查发现和移除了730个缺陷，在该阶段开始时存在120个缺陷，在该阶段引入了860个缺陷，则该阶段的缺陷移除效率为：

缺陷的早期发现百分比应该在软件项目的早期阶段尽可能多地移除缺陷，这样不仅能够提高软件质量，还有利于降低项目成本。IBM公司用来管理质量的四个度量之一就是缺陷的早期发现百分比，也就是审查缺陷移除效率，如下式：

早期开发阶段的缺陷移除早期开发阶段的缺陷移除一般来说代价较低。缺陷的发现距离被引入的时间越近，移除缺陷所需的工作量就越少。有研究者对来自IBM Santa Teresa实验室的数据进行了分析，发现软件生命周期的三个主要阶段，即设计、编码和用户使用（维护阶段）的缺陷移除代价的比率为：1：20：82。缺陷预防

优点：主动

              改进软件过程，降低出错几率
              降低质量成本，实现项目效益

缺陷的概念软件缺陷是指软件对其期望属性的偏离，它包含三个层面的信息：

1. 失效(failure)：指软件系统在运行时其行为偏离了用户的需求，即缺陷的外部表现。
2. 错误(fault)：指存在于软件内部的问题，如设计错误、编码错误等，即缺陷的内部原因。
3. 差错(error)：指人在理解和解决问题的思维和行为过程中所出现的问题，即缺陷的产生根源。

缺陷原因分析一个差错可导致多个错误，一个错误又可导致多个失效。软件缺陷原因的分析不能只停留在“错误”这一层面上，而要深入到“差错”层面，才能防止一个缺陷（以及类似缺陷）的重复发生。因此软件缺陷的根本原因往往与过程及人员问题相关，缺陷预防总是伴随着软件过程的改进。软件缺陷原因分析过程一般包括选择缺陷数据、分析缺陷数据、识别公共原因并提出改进措施三个步骤。采用该方法的软件组织通常是在软件项目的每个开发阶段结束后，或者定期（如每个月末）进行缺陷原因分析，提出改进措施，从而促进组织的过程改进。软件缺陷原因分析方法

Step1：选择缺陷数据。
    对小项目，可选择某一时期内发现的所有缺陷。
    对大项目，可选择一个缺陷样本集合。
Step2：分析缺陷的根本原因
    对缺陷逐个进行分析，常以会议的方式进行。
    可对分析出的根本原因进行分类，例如：
    IBM：疏忽、培训、通信失效、书写错误
    Motorola：开发阶段相关、人员相关、项目相关、复审相关

缺陷原因分析工具——因果图（鱼骨图）

Step3:识别公共原因，制定改进措施。
   在逐个分析了缺陷之后，还要对分析得到的根本原因进行综合和归纳，识别导致缺陷产生的公共原因，并制定有关过程、技术和人员管理方面的改进措施。

第五节 软件质量的常用度量初期故障率：指软件在初期故障期（一般以软件交付给用户后的三个月内为初期故障期）内单位时间的故障数。

    用来评价交付使用的软件的质量，预测什么时候软件运行达到基本稳定。
    一般以每100小时的故障数为单位。

偶然故障率：指软件在偶然故障期（一般以软件交付给用户后的4个月以后为偶然故障期）内单位时间的故障数。

    它用来度量软件处于稳定状态下的质量。
    一般以每1000小时的故障数为单位。

平均失效前时间（Mean Time to Failure，MTTF）：指软件在失效前（两次失效之间）正常工作的平均统计时间。

    用来度量软件的可靠性。

平均修复时间（Mean Time to Reparation，MTTR）：指软件失效后，使其恢复正常工作所需要的平均统计时间。

    用来度量软件的可维护性。

缺陷密度:指软件单位数量的源代码隐藏的缺陷数量

通常以每千行无注解代码为一个单位

案例分析

“软件缺陷管理和度量系统”质量管理计划

改进软件质量的一些要求软件质量活动必须经过规划并明文规定
质量活动必须尽早开始
质量小组必须独立存在
质量小组的人员应该经过必要的培训
本章内容小结

理解质量管理的基本概念
    软件质量、质量属性、质量形成、质量成本
理解全面软件质量管理所包含的措施
理解缺陷跟踪流程
理解缺陷预防的作用和方法
掌握常用质量度量