软件工程基础：第9章 软件质量及保证体系

第9章软件质量及保证体系主要内容软件质量基本概念软件质量度量软件复杂性分析软件可靠性分析软件质量控制ISO9000认证软件配置管理SCMCMM9.1软件质量

阿里亚娜-5型火箭

1991年海湾战争事实1：一个软件小故障造成导弹跟踪系统失灵。事实2：爆炸的根本原因在于惯性导航系统软件中技术要求和设计的错误。银弹西方民间传说：一种可怕的狼人常向人类进攻，在人受到伤害后，性格完全改变，尤其是把自己的亲人变成仇人。无奈之中，人们发现只有银弹才能制服狼人，将它打死，拯救人类。

NoSilverBullet!ThereisaSilverBullet!9.1.1软件质量特性

质量特性含义子特性功能特性(Functionality)与一组功能及其指定的性质有关的一组属性。适合性、准确性、互操作性、依从性、安全性可靠性(Reliability)与在规定的一段时间和条件下，软件维持其性能水平的能力有关的一组属性。成熟性、容错性、易恢复性可用性(Usability)与一组规定或潜在用户为使用软件所需作的努力和对这样使用所作的评价有关的一组属性。易理解性、易学性、易操作性效率(Efficiency)与在规定的条件下，软件性能水平与所使用资源量之间的关系有关的一组属性。时间特性、资源特性可维护性(Maintainability)与进行指定的修改所需的努力有关的一组属性。易分析性、易改变性、稳定性、易测试性可移植性(Portability)与软件可从某一环境转移到另一环境的能力有关的一组属性。适应性、易安装性、一致性、易替换性9.1.2软件质量评价

评价软件质量可从三个方面进行，即产品或中间产品、过程（即软件生产所需的资源和活动）和项目。

产品或中间产品评价定义质量需求质量需求包含两个方面：①问题规定或隐含的需求；②软件质量标准和其它技术信息。准备评价首先选择质量度量；然后定义质量等级；再定义评估准则。

评价过程评价过程实际上是对软件产品就第2步中准备的评价内容进行实施，也分3步：①测量——把选定的质量度量应用到软件产品上；②评级——确定某测量值的等级；③评估——根据评估准则确定产品质量，并依据管理准则判定产品是否可通过验收或是否发行等等。

过程或项目评价主要通过考察软件企业的质量保证与质量管理的质量来评价软件产品的质量。

一般来说，好的质量保证与质量管理会带来高的产品质量。

9.1.3软件质量保证

所谓质量保证（QualityAssurance）是为了提供足够的信任表明实体能满足质量要求，而在质量体系中实施并根据需要进行证实的全部有计划、系统化的活动。

质量体系（QualitySystem）是为实施质量管理所需的组织结构、程序、过程和资源

软件工程师

通过采用可靠的技术方法和措施，进行正式的技术复审、执行计划周密的软件测试来保证软件质量

SQA小组主要辅助软件工程小组得到高质量的最终产品。对项目准备SQA计划；参与开发项目的软件过程描述，以保证该过程与组织政策、内部软件标准、外界所订标准以及软件项目计划的其它部分相符；复审各项软件工程活动，对其是否符合定义好的软件过程进行核实；审计指定的软件工作产品，对其是否符合定义好的软件过程中的相应部分进行核实；确保软件工作及工作产品中的偏差已被记录，并根据预定规程进行处理；记录所有不符合的部分，并报告给高级管理者；…

9.1.4软件质量管理

确定质量方针、目标和职责，并在质量体系中通过诸如：质量策划、质量控制、质量保证和质量改进，使其实施全部管理职能的所有活动。

类型：质量检验型管理、全面质量管理和质量认证。

比较质量管理质量保证由组织内部利益相关者发起，特别是组织的管理者由利益相关者发起，特别是组织外部的顾客使所有利益相关者满意为目的以所有顾客满意为目的关系到质量结果的取得对达到质量要求的证明预期的结果是所有工作都很出色预期结果是确信组织的产品能为顾客满意9.2软件复杂性分析

各位:哪一辆车有吸引力？软件度量具有的特征(Ejiogu)简单的和可计算的;经验和直觉上有说服力;一致的和客观的;单位和维度的使用上是一致的;编程语言独立性;质量反馈的有效机制。9.2.1基于需求分析的复杂性分析

在需求分析阶段完成以后，项目的管理人员希望知道将要开发的软件有多大规模。如果是委托开发的项目软件，用户也会关心开发机构提出的报价是否恰当合理。

功能点方法

Albrecht首先提出来；功能点方法以需求规格说明书中双方确认的软件功能为依据，着重分析待开发系统的功能度（Functionality）。

假定：软件的大小与软件的功能度相关，而与软件功能的描述无关，也与功能需求的如何实现无关。

五类功能点

用户输入数；用户输出数；用户查询数；文件数；外部接口数。功能点复杂性分布

复杂性功能点简单中等复杂用户输入346用户输出457用户查询346文件71015外部接口5710影响因子及度量系统需要可靠的备份和复原吗？需要数据通信吗？有分布处理功能吗？性能很关键吗？系统是否在一个已有的、很实用的操作环境中运行？系统需要联机数据项吗？内部处理复杂吗？联机数据项是否需要在多屏幕或多操作之间切换以完成输入？输入、输出、文件或查询很复杂吗？代码需要被设计成是可复用的吗？需要联机更新主文件吗？设计中需要包括转换及安装吗？系统的设计支持不同组织的多次安装吗？应用的设计方便用户修改和使用吗？功能点计算功能点FP=未调节功能点UFP*（常数C1+常数C2*复杂度调节值CA）

职工工资管理系统例子五类功能点用户输入数为4：密码、工资打印、工资录入、错误按键；用户输出数为3：查询信息、工资报表、出错信息；用户查询数为1：工资查询；文件数为1：职工工资表；外部接口数为2：人事查询、职工信息。

影响因子分布功能点计算值假定功能点的复杂性均为“简单级”，且C1=0.65，C2=0.01，则：

UFP'=W1'C1'+W2'C2'+W3'C3'+W4'C4'+W5'C5'=3*4+4*3+3*1+7*1+5*2=44

F1+F2+...+F14=5+4+0+1+1+3+2+0+1+1+3+2+2+3=28

FP=44*（0.65+0.01*28）=40.92

功能点的应用每个功能点（FP）的错误数；每个功能点（FP）的缺陷数；每个月完成的功能点（FP）数；每个功能点（FP）的文档页数；每个功能点（FP）的成本。功能点方法的不足如何划分功能点类（即如确定那些是用户输入，哪些是外部接口等）不同的人有不同的看法；Fi和C1、C2的确定也是主观的；功能点方法最初主要是用于商业信息系统应用软件中，只强调了数据成份，从而对于强调功能及控制的非数据处理软件（如嵌入式软件、过程控制软件等）并不适用。

9.2.2基于软件设计的复杂性分析

概要设计复杂性度量主要集中在软件结构的特征上。Card和Glass定义了三种软件设计复杂度测度：结构复杂度、数据复杂度和系统复杂度。其定义分别如下：模块i的结构复杂度S（i）=f2out(i)；模块i的数据复杂度D（i）=V（i）/[fout（i）+1]；系统复杂度C（i）=S（i）+D（i）；其中fout（i）表示模块i的扇出，V（i）表示模块i的输入/输出变量的个数。

设计结构质量指标（DSQI）方法

从数据和体系结构设计中获得数据：S1=软件结构中定义的模块总数S2=正确功能依赖于输入源数据或产生在其他地方使用的数据的模块数S3=正确功能依赖于前导处理的模块数S4=数据库中项目数（包括数据对象和所有定义对象的属性）S5=特殊数据库项目总数S6=数据库段数目（不同的记录或单个对象）S7=有单个入口和出口的模块数目（异常处理不被看作是多重出口）根据S1～S7计算如下中间数据

程序结构：D1=1或0（如果软件结构是用明确的方法设计，如面向数据流设计，则D1=1，其它D1=0）模块独立性：D2=1-（S2/S1）模块不依赖于前导处理：D3=1-（S3/S1）数据库大小：D4=1-（S5/S4）数据库分区：D5=1-（S6/S4）模块出/入口特性：D6=1-（S7/S1）根据D1～D6计算DSQI的值

DSQI=W1D1+W2D2+W3D3+W4D4+W5D5+W6D6其中Wi是每个中间值的重要性的相对值且W1+W2+...+W6=1如果计算出来的DSQI明显低于平均值，则意味着应进一步改进设计；同样，如果要对一个现存的设计做重要的改动，这些改动对DSQI的影响也可以被计算出来。

McCabe环形计数法

详细设计复杂性度量主要集中在模块内部结构的复杂性上。

程序环形复杂度V（G）=程序流程图中的“判定数”+1=程序图中的“环形数”。

=m-n+2其中m对应于程序图中的弧数，n对应于程序图中的节点数。

例子从程序流程图可看出“判定数”为8；从程序图可看出，图中的弧数为26条，图中节点数为19个；若将入口节点之后一个节点和出口节点之前一个节点用弧线连起来并使弧头指向前者，则图中存在9个不同的封闭环域。因此，其对应的环形复杂度为9。

McCabe研究大量程序后发现，环形复杂度高的程序往往是最易出问题的程序。实践表明，模块规模以环形复杂度V（G）≤10为宜。

9.2.3基于源程序代码的复杂性分析

霍尔斯特德（Halstead）根据源代码中运算符和操作数的测量值来度量源程序代码的复杂度。在Halstead方法中，运算符是指用来处理程序中常量和变量的语法元素等，如算术运算符、逻辑运算符、关系运算符、流程控制语句、函数调用等；操作数则是指源程序代码中的常量和变量等。但对非执行语句，如注释，则不进行考虑。

Halstead方法的基本测量数据

程序中运算符总数N1程序中操作数总数N2程序中运算符种类数n1程序中操作数种类数n2

源程序代码复杂性度量

实际程序长度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))/3000例子：冒泡排序程序模块

SORT（int*x,intn）/*冒泡排序*/{inti,j,temp;if(n<1)return;for(i=1;i<n;i++)for(j=0;j<i;j++){if(x[i]>=x[j])continue;temp=x[i];x[i]=x[j];x[j]=temp;}}/*冒泡排序模块结束*/测量数据计算结果.N=N1+N2=30+26=56.L=(2/n1)*(n2/N2)=(2/11)*(7/26)=0.049.V=(N1+N2)*log2(n1+n2)=233.N'=n1*log2n1+n2*log2n2=58.E'=V/L=4765.E"=（(N1+N2)*log2(n1+n2)）/3000=0.07769.2.4基于软件维护的复杂性分析

IEEE建议采用一种软件成熟度指标（SMI），以提供对软件产品的稳定性指示（基于为每一软件产品发布而做的变化）。将SMI和维护工作量联系起来，形成一个经验模型，则可用来度量软件维护的复杂性。

SMI方法

基本测量数据如下：·当前发布软件中的模块数MT；·当前发布软件中已经改变的模块数Fc；·当前发布软件中已经添加的模块数Fa；·当前发布软件中已经删除的前一次发布软件中的模块数Fd。则软件成熟度指标按下式进行计算：SMI=[MT-（Fa+Fc+Fd）]/MT当SMI接近1的时候，产品便开始稳定。

9.3软件可靠性分析

按照ISO/IEC9126-1991的解释，软件可靠性是与在规定的一段时间和条件下，软件维持其性能水平的能力有关的一组属性。

一般说来，软件可靠性分析要用到概率统计方法，通过不断测试取得有关测试数据，然后根据测试结果构造可靠性模型，以分析实际达到的可靠性。基于这一点，软件可靠性可定义为软件在给定的时间间隔及规定的使用环境条件下，按分析和设计规定的要求成功地运行程序的概率。

9.3.1软件可靠性三要素

失效：是指最后执行结果与有关规格不相符或用户在软件系统边界觉察到不期望的软件出错行为。

时间：平均失效等待时间（MeanTimeToFailure，MTTF）、平均失效间隔时间（MeanTimeBetweenFailure，MTBF）和平均修复时间（MeanTimeToRepair，MTTR），且MTBF=MTTF+MTTR。

一旦确定时间基准，失效可以用三种方式表示：累积失效函数（theCumulativeFailureFunction，CFF）、失效率函数（theFailureRateFunction，FRF）和平均失效等待时间函数（theMeanTimeToFailureFunction，MTTFF）。失效率函数是累积失效函数对时间求导的结果。累积失效函数表示与时间点相关的平均累积失效。如果失效率函数可视为常数，则平均失效等待时间MTTF是失效率的倒数。环境：软件运行时所需要的支持系统及有关的因素。软件可靠性、硬件可靠性和操作可靠性三者综合起来反映整个计算机系统的可靠性。规定软件的使用环境可用来判定系统失效是否由于软件失效引起。

9.3.2软件可靠性模型

软件可靠性同硬件可靠性一样，都可看成是随机过程，用概率分布来描述。但软件可靠性与硬件可靠性的分析却不完全相同。一方面，软件不会老化，其可靠性不随时间增加而减少；另一方面，软件失效常常是由于软件分析或设计引起。这样使软件可靠性分析变得非常复杂。Jelinski-Moranda模型Jelinski和Moranda于1972年开发的可靠性分析模型是最早建立且仍被人们使用的模型之一，简称J-M模型。应用：1972年Jelinski和Moranda分析了美国海军舰队计算中心的数据，对程序固有错误数的估计为31.2，而程序在使用和再测试中发现的错误数共有34个，如果排错很彻底，可认为这就是固有错误总数，这样，估计值略低于实际值。模型的基本假设①错误检测率与当前软件错误数成比例；②在错误发生间隔期间错误检测率为常数；③出现错误即刻修正，不使新的错误引入软件；④软件运行方式与可靠性预测方式相同；⑤每个错误出现机会相等，且所有错误的严重程度相同；⑥错误被查出时，失效是独立的。假设④确保在某一特定环境下使用数据采集进行模型评价的正确性。假设⑤确保不同的失效率都具有相同的分布特性。最后一个假设可简化推导过程。J-M模型计算只能用数值法求解，需选择一个初值，再依据初值之输入后得到的结果重新选择数据逐次逼近。例子Shooman模型（1972）Shooman模型总的思想为：失效率与软件中残留错误数成比例，且失效之间的失效率为常数，而在消除错误时，失效率也以相同比率下降。

模型的基本假设

①失效率与软件潜在的错误数成比例；②所有失效发生的概率相同，且彼此独立；③所有错误的严重程度相同；④软件运行方式与可靠性预测方式相同；⑤引起失效的错误被及时修正，在修正过程中不会引入新的错误。

数据所需的数据为失效间隔时间xi或失效时刻ti，其中xi=ti-ti-1。假设：ET——测试之前程序中故障总数；

IT——程序长度（机器指令总数）；

τ——测试（包括调试）时间；

Er（τ）——在τ时刻潜在的错误数；

Ed（τ）——在0到τ期间发现的错误数；

Ec（τ）——在0到τ期间改正的错误数。

估计值①Ec(τ)=Ed(τ)因为引起失效的错误被及时修改；②Er(τ)=ET-Ec(τ)因为在错误修正过程中不会引入新的错误；令εr(τ)=Er(τ)/IT、εc(τ)=Ec(τ)/IT

，则εr(τ)=ET/IT-εc(τ)③λ=k*εr(τ)=k*(ET/IT-εc(τ))且为常数因为失效率与软件潜在的错误数成比例，且失效发生概率相同（此处λ表示失效率，k是一个比例常数）④MTTF=1/λ=1/[k*(ET/IT-εc(τ))]因为失效率λ是常数。

ET和k

的计算对程序进行两次不同的互相独立的功能测试，且测试时间τ1和τ2满足τ1<τ2

，测试中查出的错误数为Ec(τ1)和Ec(τ2)，且Ec(τ1)<Ec(τ2)，则：

λ1=k*(ET/IT-Ec(τ1)/IT)，λ2=k*(ET/IT-Ec(τ2)/IT)解得：ET=(λ1Ec(τ2)-λ2Ec(τ1))/(λ1-λ2)若λ1和λ2分别用Ec(τ1)/τ1和Ec(τ2)/τ2作近似，即：

λ1*=Ec(τ1)/τ1，λ2*=Ec(τ2)/τ2则ET的估计值为：ET*=(λ1*Ec(τ2)-λ2*Ec(τ1))/(λ1*-λ2*)从而k的估计为：k*=ITλ1*/(ET*-Ec(τ1))或k*=ITλ2*/(ET*-Ec(τ2))

此外还可采用最小二乘法去估计程序固有错误总数ET和比例常数k。

Gilb植错模型

这种模型的中心思想，是通过估计软件中残留错误的数量来确定软件的可靠性。基本假设是：设计测试用例发现植入错误和原有错误的能力相同。具体的作法是：在测试之前先由非测试人员在软件中植入一批人为的错误，在测试过程中分别统计出由测试小组发现的原有错误数和植入错误数，然后据此估算出软件中原有的错误数。

计算假设：

N表示软件中原有残留的错误数；

S表示植入软件中的错误数；

n表示测试中发现的原有错误数；

s表示测试中发现的植入错误数。则：

N=(n/s)*SHyman分别测试模型

对于Gilb植错模型而言存在两方面的问题：①如何做到设计测试用例使发现植入错误和原有错误的能力相同？②需要植入多少错误才算合适？Hyman建议由两名测试员同时相互独立地测试同一软件的两个副本。

计算假定：

B0表示软件中原有的残留错误数；

B1表示甲测试员在某一时间内发现的错误数；

B2表示乙测试员在同一时间内发现的错误数；

Bc表示甲乙两人发现的相同错误数。则：

B0=(B1*B2)/Bc9.3.3软件可靠性工程

软件可靠性工程可定义为定量地按用户对于可靠性的需求，研究基于软件系统的操作行为。它包括：（1）软件可靠性度量，是以软件可靠性模型为基础进行的评价和预测；（2）产品设计、开发过程、系统结构、软件操作环境等要点与度量标准及它们对可靠性的影响；（3）应用可靠性知识指导软件定义、开发和维护。

作用确保产品可靠性达到用户要求；降低成本；提高用户满意度；提高生产率；测试更有效;更有效地选择软件工程技术;…开展软件可靠性工程活动的有关人员

可行性和需求分析阶段

确定功能概图或直接确定操作概图；进行失效定义和分类；确定用户的可靠性要求；进行平衡关系研究，确定合理的可靠性、费用及发行日期指标；建立可靠性指标。

可靠性要求设计与实现阶段

·按模块分配可靠性指标，以保证总体可靠性指标的实现；·按可靠性指标进行设计；·根据功能概图集中分配资源；·控制错误的引入及传播；·度量现成软件的可靠性。

测试及试运行阶段

·确定操作概图；·根据操作概图，进行可靠性证明；·跟踪测试进展，根据实际达到的可靠性与预计指标间的差别采取措施；·规划必要的额外测试；·在发行前证明可靠性指标得到满足。

运行维护阶段

·监视可靠性是否达到指标，依据其间的差别采取措施；·跟踪用户对可靠性的满意程度；·通过监视可靠性，指导新功能的引入；·用可靠性度量指导产品及工程过程的改进；·规划发行后的人员需求。

9.4ISO9000软件质量体系

ISO9000系列标准是国际上影响最为深远的质量管理和质量保证标准，于1987年由国际标准化组织ISO公布。我国已将其转化为国家标准系列GB/T19000，并积极组织实施质量体系认证工作。1998年1月，我国在国际认可论坛多边互认协议上签字，这标志我国的ISO9000质量体系认证证书取得了国际上的承认。企业获得ISO9000质量体系的认证，不仅可以提高产品质量的信誉，而且也为产品进入国际市场奠定了基础。

质量体系质量体系（QualitySystem）是一种质量管理制度。建立质量体系是企业保证产品质量能够持续稳定地满足质量标准要求的根本途径。质量体系是质量管理的核心，质量管理则通过质量体系来实现。

9.4.1ISO9000族国际标准

5类标准之间的关系

（1）“质量术语标准”是讨论问题的前提，统一术语是为了明确概念，建立共同语言。（2）三个“质量保证标准“是ISO9000族标准的核心，是质量认证的基准。（3）“质量管理标准”描述了要达到质量保证标准应怎么管理。（4）“标准选用与实施指南”是对质量保证标准的解释和导引。（5）“支持性技术标准”则从更广泛的意义上给予标准实施的支持。

ISO9001ISO9000族标准中的ISO9001质量保证标准是软件机构推行质量认证工作的一个基础标准，我国已将其转化为国家推荐标准：GB/T19001-1994。

ISO9001标准在20个方面规定了供方在全部生产活动过程中的质量要求，也称为20个质量体系要素。在欧洲和日本，主要的质量标准是ISO9001。ISO9000-3ISO9000-3是计算机软件机构实施ISO9001的指南性标准。由于ISO9000族标准主要针对传统的制造业制订的，不少软件企业的技术人员和管理人员觉得ISO9001标准中质量体系要素的要求和软件工程项目有距离，ISO9000-3这个实施指南起到了桥梁作用。指南性主要表现在：（1）从软件的角度对ISO9001的内容给出了具体的说明和解释；（2）指南性的标准不是认证审核的依据，依据仍是ISO9001的各质量体系要素的实施情况。9.4.2企业软件质量体系的建立和实施

准备阶段;质量体系策划;编写质量体系文件;培训内部审核员;质量体系试运行;内部质量体系审核;管理评审;质量体系认证前的准备；质量体系认证；质量体系的进一步改进与完善。软件企业质量体系认证流程图

9.5软件配置管理（SCM）

在软件的生存周期内，变化是不可避免的，而且产生的信息又非常庞大。软件配置管理就是针对这个变化而又庞大的信息集进行有效管理的保护性活动。它可以用来:（1）标识变化；（2）控制变化；（3）保证变化被适当地实现；以及（4）记录变化，并将变化的情况报告给有关人员。

9.5.1软件配置项

软件配置项（SoftwareConfigurationItems，简称SCI）是软件配置管理的对象，它包括软件生存周期内产生的所有信息项。按ISO9000-3的说明，配置项有：与合同、源代码、过程、计划和产品有关的文档及数据；目标代码和可执行代码；相关产品，包括：软件工具、库内的可复用件、外购软件等。

9.5.2软件配置管理

按ISO9000-3的叙述，软件配置管理是一个管理学科，对配置项的开发和支持生存周期给予技术上和管理上的指导。

软件配置管理不同于软件维护，最主要的一点是软件配置管理是当软件项目开始时就启动，并且仅当软件终止运行后才结束的一组跟踪和控制变化的活动。

任务制订配置管理计划；确定配置标识；进行配置控制，实施变更管理；配置审计；记录并报告配置状态；版本控制；发行管理和交付

软件配置管理概括地说就是标识变更、控制变更以及发布变更。

9.6软件过程能力成熟度模型简介

1987年，美国卡内基-梅隆大学软件工程研究所（SoftwareEngineeringInstitute,SEI）在美国国防部的支持下，提出了“软件过程能力成熟度模型CMM(CapabilityMaturityModel）”。

作用：一方面，可以用来评价软件组织的质量保证能力；另一方面，也为软件组织改进软件过程，提高软件过程能力提供了依据。

9.6.1基本概念

软件过程：人们用于开发和维护软件及其有关产品（如项目计划、设计文档、代码、用户