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

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)*l

10、og2(n1+n2)/3000其中，V会随编程语言的不同而不同(对同一功能的程序，用高级语言来写要比 低级语言来写得到的程序对应的V要小)，它代表了写一个程序所需的信息量(以 位为单位)。1反映的是程序最简洁形式时的容量与程序实际容量之比。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提出以来，已经有几十个软件可靠性模型公开发表。实际应用经验表明， 没有一个普适的模型能对所有产品都能做出最好的可靠性分析。软件可靠性模型 的研究还有待进一步深入。几个较简单的模

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

15、000族国际标准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、质量体系认证过程10、质量体系的进一步改进与完善9.5软件配置管

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

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

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

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

21、管理级（可预测的软件过程）5、优化级（能持续改善的软件过程）9.6.3关键过程域除“初始级”外，每个成熟度等级均包含几个关键过程域。为了达到一个成熟度 等级，必须实现该等级上的全部关键过程域。有关概念分别说明如下：需求管理：在顾客和软件项目之间建立对顾客需求的共同理解。软件项目策划：制定软件工程和软件项目管理的合理的计划。软件项目跟踪和监督：建立适当的对实际进展的跟踪和监督，使管理者在软件 项目实施情况显著偏离软件计划时能及时采取有效措施。软件子合同管理：选择合格的软件分承包商，并有效地管理他们。软件质量保证：提供对软件项目所采用的过程和所构造的产品的某种可视性和 透明性，使管理者能较容易地发

22、现软件过程和产品的质量问题，以便采取及时有 效的措施。软件配置管理：在整个软件生存周期中建立和维护软件产品的完整性和一致 性。组织过程焦点：规定组织在提高整体过程能力、改进软件过程活动方面的责任。组织过程定义：总结和保持一组便于使用的软件过程的成功的实践经验，以便 使项目的过程实施能得到改进，为组织获得积累性的长期效益奠定基础。培训大纲：培训个人的技能和知识，以提高其执行任务的质量和效率。集成软件管理：将软件工程活动和软件管理活动集成为一个协调的、已定义的 软件过程9.6.4关键实践为了对关键实践的描述更加规范化，将关键过程域所包含的关键实践全部按5 个共同特征加以组织，即：执行约定：描述一个

23、组织在保证将过程建立起来并持续起作用方面所必须采取 的行动。执行约定一般包括制定组织的方针和规定高级管理者的支持。执行能力：描述为了实施软件过程，项目或组织中必须存在的先决条件。执行 能力一般包括资源、组织机构和培训。执行的活动：描述为实现一个关键过程域所必须的角色和规程（即描述必须由 何人做何事）。执行的活动一般包括制订计划与规程、执行计划、跟踪执行情况， 必要时采取纠正措施。测量和分析：描述对过程进行测量和对测量结果进行分析的需要。测量和分析 一般包括为了确定所执行活动的状态及有效性所能采用的测量和分析。验证实施：描述遵照已建立的过程进行活动的措施。验证实施一般包括管理者 和软件质量保证部门所作的评审和审计。关键实践一般要描述对其所在的关键过程域目标的实现和规范化实施贡献最大 的那些基础设施和实践活动。每个关键实践又可能另有若干个下级实践，用来确 定关键实践是否得到满意的实施。9.6.5软件过程能力成熟度模型的应用软件过程能力成熟度模型有两个基本用途：软件过程评估和软件能力评价。软件 过程评估用以确定一个组织的当前软件过程的状态，找出组织所面临的急需解决 的与软件过程有关的问题，进而有步骤地实施软件过程改进