第六章 软件项目质量管理_yongchaocsdn的博客-CSDN博客_软件质量管理

本章内容提要

软件质量管理的基本概念
全面软件质量管理
缺陷跟踪
缺陷移除和预防
软件质量的常用度量
案例分析

第一节 软件质量管理的基本概念

• 软件质量就是软件与用户需求相一致的程度。具体地说，软件质量是软件符合明确叙述的功能和性能需求、以及所有专业开发的软件都应具有的隐含特征的程度。

1. 用户需求是衡量软件质量的基础。
2. 除满足明确定义的需求外，还要满足隐含的需求。

软件质量的重要性

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

软件质量属性

软件质量的属性

McCall软件质量模型

软件质量的形成

• 软件的质量形成于软件的整个开发过程中，而不是事后的检查（如测试）。
• 20世纪80年代起，质量管理逐步从单一的关注产品，转移到关注生产好产品的过程上，并且将过程的作用扩大到了组织运行的所有领域。

质量产生于过程

要真正地提高软件质量，必须有一个成熟和稳定的软件过程。

特殊原因造成过程性能不稳定。

根除特殊原因，使过程性能稳定，防止质量问题的出现。

质量成本（CoQ）

• 质量成本是为了达到产品或服务的质量而付出的所有努力的总成本，包括三部分：

1. 预防成本：为防止将缺陷引入软件而进行的预防工作所消耗的费用。
2. 评价成本：检查软件是否包含缺陷的工作所消耗的费用。
3. 失效成本：修复缺陷工作所消耗的成本。

PAF（Prevention / Appraisal / Failure）成本模型

在项目早期预防和检测缺陷比在项目晚期检测和排除缺陷更有效、更节省成本。

软件项目质量管理的目标

• 软件项目质量管理的目标无疑是保证软件产品的质量。但是，对于一个具体的软件项目来说，保证软件产品的质量并不意味着追求“完美的质量”。
• 对于绝大多数普通软件来说，没有必要付出巨大代价追求“零缺陷”，如果由于追求完美质量而造成严重的成本超支和进度拖延，而获得的质量提升为用户所带来的效益又极为有限，就得不偿失了。
• 在软件项目中，对于软件的各种质量属性并不是放在同等重要的位置上，项目组织应该把关注点放在那些用户最关心的，对软件整体质量影响最大的质量属性上，这些质量属性称为“质量要素”。
• 软件项目质量管理的目标是在项目整体目标的约束之下，使软件质量满足用户需求。

第二节 全面软件质量管理

质量管理计划

• 质量管理计划就是为了实现项目的质量目标，对项目的质量管理工作所做的全面规划。软件项目质量管理计划一般应满足以下要求：

1. 确定项目应达到的质量目标和所有特性的要求；
2. 确定项目中的质量活动和质量控制程序；
3. 确定项目采用的控制手段及合适的验证手段和方法；
4. 确定和准备质量记录。

质量管理计划一般包括以下主要内容：

质量要素分析；

质量目标；

人员与职责；

过程检查计划；

技术评审计划；

软件测试计划；

缺陷跟踪工具。

评审（Review）

• 评审相当于软件开发过程的“过滤器”，在软件开发的一些时间点上对中间产品执行评审，发现和排除错误，防止错误被遗留到后续阶段。因此评审对于保证软件质量和降低开发成本都极为重要。
• 评审可以在软件项目的任何阶段执行，不必等到软件可运行之后，因此可以尽早发现和消除缺陷，提高软件质量，并降低开发成本。
• 有统计数据表明，评审可发现75%的设计错误。

技术评审（Technical Review）

• 技术评审（Technical Review, TR）就是对工作成果进行审查和分析，发现其中的缺陷，并帮助开发人员及时消除缺陷。
• 技术评审的主要对象：需求和设计规格说明、代码、测试计划、用户手册等。

正式和非正式技术评审

• 技术评审分为正式技术评审和非正式技术评审两种基本类型，前者比较严格，需要举行评审会议，参加人员比较多，后者的形式比较灵活，通常在同伴之间开展，不必举行评审会议，参与人员相对较少。
• 一般来说，对重要性和复杂性较高的工作成果，应进行正式技术评审，对重要性和复杂性相对较低的工作成果，可进行非正式技术评审。

技术评审会议

• 技术评审以会议形式进行，一般有如下约束：

1. 评审会议通常由3~5人参加。
2. 会议之前评审人员要做准备，但每人的准备时间不超过2个小时。
3. 评审会议的时间不超过2个小时。

• 一次技术评审只关注软件的某一特定部分（例如需求或设计规格说明的一部分）。缩小评审焦点可提高发现错误的可能性。

正式技术评审流程

• 评审组长把待评审的材料分发给每个评审者，评审者（包括评审组长）审查材料，记下相关的要点，为评审会议做准备。
• 开评审会议。评审会议由评审组长、评审者、评审对象的开发者参加。其中的一个评审者充当记录员，负责记录会议中发现的所有问题。
• 由开发小组对提交的评审对象进行讲解。同时评审者可对开发者提问，提出建议和要求，展开讨论。
• 在讨论中如果发现了问题和错误，由记录员记录下来。
• 会议结束时必须做出以下三个决策之一：

1. 接受该产品，不需要做修改。
2. 由于错误严重，拒绝接受。等到错误改正后，还要进行另一次评审。
3. 暂时接受该产品，但需要对某一部分进行修改，修改后不需要再进行另一次评审。

• 决定作出后，所有参加会议的人员签字，确认会议结果。

• 技术评审会议后，要完成一个“评审总结报告”，其内容包括：评审对象是什么？谁参加了评审？评审的结论是什么？有哪些重要发现？
• 评审会议上所记录的问题列表通常作为评审总结报告的附件。
• 跟踪与审核。开发者修改工作成果，消除已发现的缺陷。由指定的审查人员跟踪每个缺陷的状态，直到工作成果合格为止。

技术评审的注意事项

• 评审产品，而不是评审人。评审会议的气氛要轻松和愉快，注意提出问题时的方式和态度，不要让产品开发者产生被审问的感受。
• 制订评审会议的议程并遵守进度。不要让会议过分拖延。问题的具体解决方案可以在会后讨论。
• 使用检查清单。为不同的软件产品（需求、设计、代码等）开发检查清单，在检查清单中列出所有重要的、常见的问题，这样可以使评审会议聚焦于一些重要问题。

同行评审（Peer Review）

• 同行评审是一种特殊类型的技术评审。
• 由与工作产品开发人员具有同等背景和能力的人员对工作产品进行技术评审，因此非常有利于发现工作产品中的问题。

代码评审（Code Review）

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

软件测试

• 软件测试是通过执行软件来发现缺陷，它是控制软件质量的重要手段和关键活动。
• 软件测试要在有了软件编码后才能执行，但测试的计划和设计应在项目前期就开始。测试计划确定了测试的内容和目标，明确了测试范围，制定了测试策略和用例设计方法，安排人力和设备资源等。测试设计就是利用各种测试用例设计方法，编写测试用例，并准备测试数据，开发辅助测试工具和编写自动化测试脚本。
• 在测试执行阶段，要执行测试用例，发现和记录软件缺陷。测试执行完毕后，还要对测试的结果进行分析总结，撰写测试报告，给出结论。

过程检查

• 过程检查就是检查软件项目的工作过程和工作成果是否符合既定的规范。在软件项目中，如果工作过程和工作成果不合规范，很可能会导致质量问题。
• 例如，代码和文档的版本及其命名不符合版本控制规范，重要的变更不遵循变更控制流程，都有可能造成开发工作的混乱，进而导致产品质量下降。
• 工作过程和工作成果符合既定规范，也并不意味着产品质量一定能得到保证。因此过程检查只是保证质量的一个必要条件，而不是充分条件，它还需要与技术评审、软件测试、缺陷跟踪、过程改进等各方面措施互相配合，共同促进软件质量的提高。
• 对过程检查要事先做出规划，确定主要检查项、检查时间（或频度）、负责人等。过程检查计划一般包含在软件项目质量管理计划中。

软件过程改进

• 软件过程（Software Process）是指开发和维护软件产品的活动、技术、实践的集合。软件过程描述了为了开发和维护用户所需的软件，什么人（who）、在什么时候（when）、做什么事（what）以及怎样做（how）。
• 软件开发的过程观认为，软件是由一组软件过程生产的，因此软件质量和生产率在很大程度上是由软件过程的质量和有效性决定的，而软件过程可以被定义、控制、度量和不断改进。
• 所谓软件过程改进是指根据实践中对软件过程的使用情况，对软件过程中的偏差和不足之处进行不断优化。
• 软件过程改进是面向整个软件组织的。一个成熟的软件组织应该对其软件过程进行定义，形成一套规范的、可重用的软件过程，称为“组织级过程资产”。

软件过程改进示意图

• 软件过程改进可遵循某种过程改进模型（如CMMI）来执行。

第三节 缺陷跟踪

• 缺陷跟踪是指从缺陷被发现开始到被改正为止的整个跟踪流程。

缺陷跟踪工具

• 缺陷跟踪一般需要软件工具支持。常用的工具有Bugzilla、ClearQuest、JIRA、TrackRecord 等。

缺陷跟踪工具Bugzilla

• Bugzilla是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）：指软件失效后，使其恢复正常工作所需要的平均统计时间。

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

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

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

案例分析

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

改进软件质量的一些要求

软件质量活动必须经过规划并明文规定

质量活动必须尽早开始

质量小组必须独立存在

质量小组的人员应该经过必要的培训