软件质量和软件质量保证体系.doc

《软件质量和软件质量保证体系.doc》由会员分享，可在线阅读，更多相关《软件质量和软件质量保证体系.doc（8页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第9章 软件质量和软件质量保证体系 9.1 软件质量 9.1.1 软件质量特性 什么是软件质量？不同人或组织的看法各不相同。按照ISO/IEC 9126-1991（我国GB/T16260-1996）“信息技术软件产品评价、质量特性及其使用指南”国际标准，认为软件质量 （Software Quality）是与软件产品满足明确或隐含需求的能力有关的特征和特性的总和，例如，符合规格说明。简而言之，软件质量是软件一些特性的组合，它仅依赖于软件本身。 9.1.2 软件质量评价 评价软件质量可从三个方面进行，即产品或中间产品、过程（即软件生产所需的资源和活动）和项目。 评价可按如下三步进行： 1、定义质量

2、需求 质量需求包含两个方面：问题规定或隐含的需求；软件质量标准和其它技术信息。 2、准备评价 首先选择质量度量；然后定义质量等级；再定义评估准则。 由于一般情况下，不可能对质量特性进行直接度量，从而应选择与质量特性相关的且可定量的软件特性加以度量。定义质量等级是依据应用问题的需求将质量度量值分割成若干不同满意程度的等级，如优秀、合格与不合格等。定义评估准则是为了综合软件不同质量特性的评价结果，可采用判定表或加权平均法；同时还可兼顾其它因素，如时间、成本等。 3、评价过程 评价过程实际上是对软件产品就第2步中准备的评价内容进行实施，也分3步： 测量把选定的质量度量应用到软件产品上； 评级确定某测

3、量值的等级； 评估根据评估准则确定产品质量，并依据管理准则判定产品是否可通过验收或是否发行等等。 9.1.3 软件质量保证 软件的质量保证也和一般的质量保证一样，是确保软件产品从诞生到消亡为止的所有阶段的质量的活动。软件质量保证由各种任务构成，分别与两种不同的参与者相关负责技术工作的软件工程师和负责质量保证的计划、监督、记录、分析及报告工作的软件质量保证（SQA）小组。软件工程师通过采用可靠的技术方法和措施，进行正式的技术复审、执行计划周密的软件测试来保证软件质量。SQA小组主要辅助软件工程小组得到高质量的最终产品，对项目准备SQA计划，如确定需要进行的评价、需要进行的审计和复审、项目可采用的

4、标准等；参与开发项目的软件过程描述，以保证该过程与组织政策、内部软件标准、外界所订标准以及软件项目计划的其它部分相符；复审各项软件工程活动，对其是否符合定义好的软件过程进行核实；审计指定的软件工作产品，对其是否符合定义好的软件过程中的相应部分进行核实；确保软件工作及工作产品中的偏差已被记录，并根据预定规程进行处理；记录所有不符合的部分，并报告给高级管理者；等等。? 9.1.4 软件质量管理 所谓质量管理是指确定质量方针、目标和职责，并在质量体系中通过诸如：质量策划、质量控制、质量保证和质量改进，使其实施全部管理职能的所有活动。质量策划包括产品策划、管理和作业策划以及质量计划的编制和质量改进的准

5、备工作。质量控制是指采取某些特定作业技术或开展某些活动，以达到质量要求。质量改进是指以追求更高的效益和效率为目标的持续性活动。 质量管理和质量保证相互依赖，但他们的活动具有不同的范围、不同的目的、不同的动机和不同的结果。? 9.2 软件复杂性分析 9.2.1 基于需求分析的复杂性分析 软件工程的技术性工作始于需求分析，提供对分析模型质量的度量是有意义的和必要的。在需求分析阶段完成以后，项目的管理人员希望知道将要开发的软件有多大规模，这与将要投入的工作量、开发成本以及何时交付用户或何时投放市场都有密切的联系。同时，如果是委托开发的项目软件，用户也会关心开发机构提出的报价是否恰当合理。双方都希望有

6、一个科学、公正的估价依据。下面介绍一种面向功能的软件复杂性度量方法功能点方法。 面向功能度量是由Albrecht首先提出来的。功能点方法以需求规格说明书中双方确认的软件功能为依据，着重分析待开发系统的功能度（Functionality）。显然，软件的大小与软件的功能度相关，而与软件功能的描述无关，也与功能需求的如何实现无关。功能点（FP）度量可以用作从分析模型中获得系统大小的预测手段。 9.2.2 基于软件设计的复杂性分析 人们在设计硬件时，常利用设计测度来确定设计质量，指导设计演化。然而对于软件而言，大部分软件工程师却忽视对软件设计结果的测量以达到进一步改进软件设计的目的。软件设计由概要设计

7、和详细设计两个阶段组成，我们分别就这两个阶段讨论软件设计复杂性度量方法。 概要设计复杂性度量主要集中在软件结构的特征上。Card和Glass定义了三种软件设计复杂度测度：结构复杂度、数据复杂度和系统复杂度。美国空军提出了一种计算“设计结构质量指标（DSQI）”的方法用来度量软件结构的复杂度。该方法使用了类似于在IEEE Std.982.11988中提出的概念。 详细设计复杂性度量主要集中在模块内部结构的复杂性上。麦凯伯（McCabe）提出了一种环形计数的方法来确定程序控制流的复杂度。使用McCabe方法可直接利用程序流程图计算其“判定数”（即比较个数，对于复合条件判定要先转化成单一条件判定），

8、也可根据程序流程图导出的程序图计算其“环形数”(即封闭环域数)来进行，其计算公式为： 程序环形复杂度V（G）=程序流程图中的“判定数”+1=程序图中的“环形数”。 =m-n+2其中m对应于程序图中的弧数，n对应于程序图中的节点数。 9.2.3 基于源程序代码的复杂性分析 软件开发经过编码阶段后，便得到源程序代码。霍尔斯特德（Halstead）根据源代码中运算符和操作数的测量值来度量源程序代码的复杂度。在Halstead方法中，运算符是指用来处理程序中常量和变量的语法元素等，如算术运算符、逻辑运算符、关系运算符、流程控制语句、函数调用等；操作数则是指源程序代码中的常量和变量等。但对非执行语句，如

9、注释，则不进行考虑。Halstead方法使用了以下4个基本测量数据： 程序中运算符总数N1程序中操作数总数N2程序中运算符种类数n1程序中操作数种类数n2根据以上4个测量数据，可以在以下几个方面对源程序代码的复杂性进行度量： 实际程序长度N=N1+N2 编程语言层次L=（2/n1）*(n2/N2)程序容量 V=(N1+N2)*log2(n1+n2)? 预测程序长度N= n1*log2n1+n2*log2n2? （可在详细设计后进行预测） 估计程序工作量 E=V/L=(n1*N2*(N1+N2)*log2(n1+n2)/(2*n2)预测程序错误数E=(N1+N2)*log2(n1+n2)/300

10、0其中，V会随编程语言的不同而不同（对同一功能的程序，用高级语言来写要比低级语言来写得到的程序对应的V要小），它代表了写一个程序所需的信息量（以位为单位）。L反映的是程序最简洁形式时的容量与程序实际容量之比。 9.2.4 基于软件维护的复杂性分析 IEEE建议采用一种软件成熟度指标（SMI），以提供对软件产品的稳定性指示（基于为每一软件产品发布而做的变化）。将SMI和维护工作量联系起来，形成一个经验模型，则可用来度量软件维护的复杂性。 SMI方法涉及的基本测量数据如下： 当前发布软件中的模块数MT； 当前发布软件中已经改变的模块数Fc； 当前发布软件中已经添加的模块数Fa； 当前发布软件中已经

11、删除的前一次发布软件中的模块数Fd。 则软件成熟度指标按下式进行计算： SMI=MT-（Fa+Fc+Fd）/MT当SMI接近1的时候，产品便开始稳定。 实际上，软件维护过程也是由分析、设计、编码和测试的过程组成，从而基于分析、设计、编码以及测试的复杂性分析方法也可用于软件维护的复杂性分析 9.3 软件可靠性分析 9.3.1 软件可靠性三要素 在上面定义软件可靠性中实际给出了三个有关的主要因素：失效、时间和环境。 1、失效 在讨论软件质量和软件可靠性时，软件失效是指最后执行结果与有关规格不相符或用户在软件系统边界觉察到不期望的软件出错行为。失效是错误引起的结果。 2、时间 在进行软件可靠性分析时

12、，时间可以有三种度量方式。第一种是执行时间，是指运行软件时计算机实际花费的CPU时间；第二种是日期时间，指通常以年、月、周、日等计算的时间；第三种是时钟时间，是指运行软件时计算机自始至终所花去的累积时间，但计算机停机时间不计算在内。 3、环境 软件的使用环境涉及软件运行时所需要的支持系统及有关的因素。一个规定的使用环境是对这些因素的精确而详细的限制描述。严格地说，描述软件可靠性“规定的使用环境”包括硬件配置状态和操作人员操作等的描述，并假定其它因素对软件来说都是理想可靠的，不会影响软件的运行。也就是说软件可靠性不包含硬件和操作的可靠性。软件可靠性、硬件可靠性和操作可靠性三者综合起来反映整个计算

13、机系统的可靠性。规定软件的使用环境可用来判定系统失效是否由于软件失效引起。 9.3.2 软件可靠性模型 软件可靠性同硬件可靠性一样，都可看成是随机过程，用概率分布来描述。但软件可靠性与硬件可靠性的分析却不完全相同。一方面，软件不会老化，其可靠性不随时间增加而减少；另一方面，软件失效常常是由于软件分析或设计引起。这样使软件可靠性分析变得非常复杂。自第一个软件可靠性模型由Jelinski和Moranda提出以来，已经有几十个软件可靠性模型公开发表。实际应用经验表明，没有一个普适的模型能对所有产品都能做出最好的可靠性分析。软件可靠性模型的研究还有待进一步深入。 几个较简单的模型：1、Jelinski

14、-Moranda模型；2、Shooman模型；3、Gilb植错模型；4、Hyman分别测试模型。 9.3.3 软件可靠性工程 软件可靠性工程可定义为定量地按用户对于可靠性的需求，研究基于软件系统的操作行为。它包括： （1）软件可靠性度量，是以软件可靠性模型为基础进行的评价和预测； （2）产品设计、开发过程、系统结构、软件操作环境等要点与度量标准及它们对可靠性的影响； （3）应用可靠性知识指导软件定义、开发和维护。 围绕软件生命周期所进行的软件可靠性工程活动如下： （1）可行性和需求分析阶段 （2）设计与实现阶段 （3）测试及试运行阶段 （4）运行维护阶段 9.4 ISO 9000软件质量体系

15、9.4.1 ISO9000族国际标准 ISO 9000族国际标准是指国际标准化组织中质量管理和质量保证技术委员会（ISO/TC 176）制订的所有标准。ISO 9000以一般术语描述了能够适用于任何行业的质量保证系统的要素，这些要素包括用于实现质量计划、质量控制、质量保证和质量改进所需的组织结构、程序、过程和资源。现有5类共20个标准，如图9-7，分别是： 1、质量术语标准 它是ISO 9000族标准中最早发布的一个标准，为质量管理领域中常用的质量术语作了明确的定义，成为质量管理和理解、贯彻实施ISO 9000其他标准的基础。 2、质量保证标准 这类标准体现了对供方质量体系的不同要求，供方对这

16、些要求的满足应得到证实。 3、质量管理标准 这类标准可用以指导质量管理和建立质量体系。 4、质量管理和质量保证标准的选用和实施指南 5、支持性技术标准 9.4.2 企业软件质量体系的建立和实施 ISO 9000族标准中并没有专门提供软件企业如何建立和实施质量体系，因此，可以认为软件企业建立和实施质量体系的过程和其他企业并无多大差别，仅对某些质量体系要素有其特殊的要求。下面简要说明软件企业建立和实施质量体系的主要工作。 1、准备阶段 2、质量体系策划 3、编写质量体系文件 4、培训内部审核员 5、质量体系试运行 6、内部质量体系审核 7、管理评审 8、质量体系认证前的准备 9、质量体系认证过程

17、10、质量体系的进一步改进与完善 9.5 软件配置管理 9.5.1? 软件配置项 软件配置项（Software Configuration Items，简称SCI）是软件配置管理的对象，它包括软件生存周期内产生的所有信息项。按ISO 9000-3的说明，配置项有： 与合同、源代码、过程、计划和产品有关的文档及数据； 目标代码和可执行代码； 相关产品，包括：软件工具、库内的可复用件、外购软件等。 软件配置就是软件配置项在不同时期按不同要求进行的组合。例如：Visual Basic 6.0有专业版、企业版等不同版本。实际中，一般用“版本”来表示配置项的演化阶段。 随着软件过程的进展，软件配置项也迅

18、速增长，并且变化接踵而至，主要变化表现在： 新的商业或市场环境，引起产品需求或业务规则变化； 新的用户要求； 企业结构变化，导致项目优先级或软件工程队伍结构变化； 预算或进度的限制。 9.5.2 软件配置管理 软件配置管理是一组用于在计算机软件的整个生存周期内管理变化的活动。按ISO 9000-3的叙述，软件配置管理是一个管理学科，对配置项的开发和支持生存周期给予技术上和管理上的指导。配置管理的应用取决于项目的规模、复杂程度和风险大小。 软件配置管理不同于软件维护，最主要的一点是软件配置管理是当软件项目开始时就启动，并且仅当软件终止运行后才结束的一组跟踪和控制变化的活动。实施软件配置管理主要有

19、以下任务： 1、制订配置管理计划 2、确定配置标识 3、进行配置控制，实施变更管理 4、配置审计 5、记录并报告配置状态 6、版本控制 7、发行管理和交付 9.6 软件过程能力成熟度模型简介 9.6.1 基本概念 软件过程：人们用于开发和维护软件及其有关产品（如项目计划、设计文档、代码、用户手册等，在模型中又称为软件工作产品）的一系列活动，包括软件工程活动和软件管理活动。 软件过程能力：描述开发组织或项目组通过执行其软件过程能实现预期结果的程度。 软件过程性能：表示开发组织或项目组遵循其软件过程所得到的实际结果。 软件过程成熟度：一个特定软件过程被明确和有效地定义、管理、测量和控制的程度。成熟

20、度可以指明一个软件开发组织软件过程能力的增长潜力。 软件能力成熟度等级：软件开发组织在走向成熟的途中几个具有明确定义的、表征软件过程能力成熟度的平台。 关键过程域：互相关联的若干软件实践活动和有关基础设施的集合。 关键实践：对关键过程域的实施起关键作用的方针、规程、措施、活动以及相关基础设施的建立。 软件过程能力成熟度模型：对软件组织进化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力经过这些阶段逐步前进。 9.6.2 软件过程能力成熟度等级 SEI CMM1.1将软件过程的进化步骤分成5个等级，用以测量软件开发组织的软件过程成熟度和评价其软件过程能力： 1、初始

21、级（混沌的软件过程） 2、可重复级（经过训练的软件过程） 3、已定义级（标准一致的软件过程） 4、定量管理级（可预测的软件过程） 5、优化级（能持续改善的软件过程） 9.6.3 关键过程域 除“初始级”外，每个成熟度等级均包含几个关键过程域。为了达到一个成熟度等级，必须实现该等级上的全部关键过程域。 有关概念分别说明如下： 需求管理：在顾客和软件项目之间建立对顾客需求的共同理解。 软件项目策划：制定软件工程和软件项目管理的合理的计划。 软件项目跟踪和监督：建立适当的对实际进展的跟踪和监督，使管理者在软件项目实施情况显著偏离软件计划时能及时采取有效措施。 软件子合同管理：选择合格的软件分承包商，

22、并有效地管理他们。 软件质量保证：提供对软件项目所采用的过程和所构造的产品的某种可视性和透明性，使管理者能较容易地发现软件过程和产品的质量问题，以便采取及时有效的措施。 软件配置管理：在整个软件生存周期中建立和维护软件产品的完整性和一致性。 组织过程焦点：规定组织在提高整体过程能力、改进软件过程活动方面的责任。 组织过程定义：总结和保持一组便于使用的软件过程的成功的实践经验，以便使项目的过程实施能得到改进，为组织获得积累性的长期效益奠定基础。 培训大纲：培训个人的技能和知识，以提高其执行任务的质量和效率。 集成软件管理：将软件工程活动和软件管理活动集成为一个协调的、已定义的软件过程 9.6.4

23、 关键实践 为了对关键实践的描述更加规范化，将关键过程域所包含的关键实践全部按5个共同特征加以组织，即： 执行约定：描述一个组织在保证将过程建立起来并持续起作用方面所必须采取的行动。执行约定一般包括制定组织的方针和规定高级管理者的支持。 执行能力：描述为了实施软件过程，项目或组织中必须存在的先决条件。执行能力一般包括资源、组织机构和培训。 执行的活动：描述为实现一个关键过程域所必须的角色和规程（即描述必须由何人做何事）。执行的活动一般包括制订计划与规程、执行计划、跟踪执行情况，必要时采取纠正措施。 测量和分析：描述对过程进行测量和对测量结果进行分析的需要。测量和分析一般包括为了确定所执行活动的

24、状态及有效性所能采用的测量和分析。 验证实施：描述遵照已建立的过程进行活动的措施。验证实施一般包括管理者和软件质量保证部门所作的评审和审计。 关键实践一般要描述对其所在的关键过程域目标的实现和规范化实施贡献最大的那些基础设施和实践活动。每个关键实践又可能另有若干个下级实践，用来确定关键实践是否得到满意的实施。 9.6.5 软件过程能力成熟度模型的应用 软件过程能力成熟度模型有两个基本用途：软件过程评估和软件能力评价。软件过程评估用以确定一个组织的当前软件过程的状态，找出组织所面临的急需解决的与软件过程有关的问题，进而有步骤地实施软件过程改进，使组织的软件过程能力不断提高。软件能力评价可以识别合

25、格的能完成软件工作的承制方，或者监控承制方现有软件开发工作中软件过程的状态，进而指出承制方应改进之处。应用软件过程能力成熟度模型进行软件过程评估和能力评价的共同步骤： 第一步，建立评价评估组。小组成员应具有丰富的软件工程和管理方面的知识，并通过预先培训熟悉CMM的有关概念和评估评价细节。 第二步，填写提问单。由待评估或评价单位的代表完成。 第三步，进行响应分析。评估评价组对提问回答情况进行统计，并据此确定必须作进一步探查的领域，以便提出补充提问。待探查的领域应与CMM的关键过程域相对应。 第四步，进行现场访问。访问被评估或评价单位的现场，以便了解该现场所遵循的软件过程。当CMM的关键实践与现场

26、的实践存在明显差异时，评估或评价组必须用文档记下对此关键过程域作出判断的理论依据。 第五步，提出调查发现清单。明确指出该组织软件过程的强项和弱项。调查发现清单指出了过程改进建议，并可作为软件采购单位风险分析的一部分。 第六步，制作关键过程域剖面图。指出软件开发组织已满足和尚未满足其目标的关键过程域。 9.7 小结 软件质量是软件工程关注的焦点。提高软件质量，一方面要在软件开发过程中对开发成果进行验证，另一方面要注重软件开发过程的规范化和可视化。前者注重的是产品本身的质量，后者注重的是产品管理的质量。显然，如果产品管理质量高，那么生产的产品质量是有保证的，否则产品质量难以预测。就目前的发展趋势，软件开发过程的规范化和可视化是提高软件质量的有效手段，也可对软件生产组织将来生产的产品的质量进行预测。 软件复杂性和可靠性是软件质量的两个重要方面。有关软件复杂性和可靠性分析技术为软件质量的分析提供了量化的方法。而软件质量保证体系、软件配置管理和软件过程能力成熟度模型是实施软件开发过程规范化和可视化的流行方式。