软件生命周期质量评价方法研究

李海霞，王 磊， 李 智，王月波

(西南电子技术研究所 天奥软件测评中心，成都 610036)

0 引言

随着人们对以软件为核心的载体依赖越来越大，软件产品质量也成为国际社会密切关注的问题，软件质量水平很大程度上决定着软件的市场推广程度及市场地位[1]。但目前软件漏洞众多等问题频频出现，软件质量理所当然地成为了大家关注的焦点，怎么确保被测软件的质量，并进行提高，从而使用户更加满意，已然成为各个国家需要重点解决的热点和难点问题。大部分企业均是依据现有的软件质量相关标准进行质量评估，但是现有的标准并未对软件生命周期某个特定的阶段进行质量评估，只是从概念上非常笼统的抽象出通用模型[2-5]，特定阶段软件质量评估和实施在我国尚未成熟，并且评估技术大多来自国外软件质量相关标准，几乎没有自主产权的有特色的评估体系[6-9]。另外，对于软件生命周期中和软件的质量问题最为密切相关的几个阶段，包括需求分析、软件设计、软件编码和软件测试，一方面缺乏对定性和定量指标的提取，另一方面，也未形成科学严谨的阶段质量评价模型。因此迫切需要制定一套专门针对软件生命周期中需求分析、软件设计、软件编码和软件测试的质量评价方法，该评价方法具有非常重大的现实意义。

1 软件生命周期概述

和世界万物类似，一个成熟的软件需要经历孕育、诞生、成长、成熟、衰亡等阶段，一般我们称之为软件生存周期(又叫软件生命周期)[10]。一般情况下，软件生命周期主要包括软件需求分析、软件设计、软件编码、软件测试和软件维护等阶段，软件测试[11]是一个系列过程，包括软件测试需求分析、软件测试计划设计、软件测试用例设计、软件测试执行等等，软件生命周期各个阶段均进行不同目的和内容的测试活动，因此，软件项目整个生命周期中均存在软件测试，从而确保软件生命周期各个阶段均正常使用。此外，软件生命周期各个过程均可能存在错误，软件测试只能确认软件存在的错误，并不能避免软件新错误的出现。

在整个软件生命周期中，其中软件需求分析、软件设计、软件编码和软件测试等4个阶段和软件质量息息相关。软件需求分析是对产品进行定义，软件设计是进行产品设计，软件编码是实现软件，软件测试则是验证软件是否满足需求。软件的质量控制有个很明显的特点，那就是发现软件问题越早，解决该软件问题的成本就会越低，反之则越高，这是因为软件问题可能出现在软件需求分析、软件设计和软件编码、软件测试这几个阶段的任意阶段，而在实际软件生命周期中，软件问题很多是等到了后面阶段才被发现，但此时很多工作已经基于这个错误的前提下进行了开展，而且引入问题的阶段越是靠前，其影响范围也就会越广，而且解决软件质量问题的成本是和开发阶段呈指数级别增长的，所以越是到后面，需要投入的人力成本和时间等成本也就会越多。因此，对软件生命周期每个阶段分别进行评价，建立合适的软件生命周期质量评价方法就尤其重要。

2 软件生命周期质量评价模型

2.1 软件生命周期质量评价流程

软件缺陷(bug)：软件在使用过程中存在的任何问题都称为软件的缺陷，简称bug。

bug引入阶段指的是在整个软件生命周期中，哪个阶段产生的bug。而在该模型中，bug引入阶段包括软件需求分析阶段、软件设计阶段、软件编码阶段和软件测试阶段。需求阶段可能因为需求描述不易理解，有歧义、错误等；设计阶段可能因为设计文档存在错误或者缺陷等；编码阶段可能开发人员代码出现错误等；测试阶段可能测试人员操作错误等引入了bug，也就是说软件生命周期任何阶段都可能引入bug。

bug发现阶段指的是在整个软件生命周期中，哪个阶段发现的bug。而在该模型中，bug发现阶段包括软件需求分析阶段、软件设计阶段、软件编码阶段和软件测试阶段。bug发现阶段一般晚于bug引入阶段，一般来说，bug发现的越早，修复的成本越低，反之，bug发现的越晚，修正该bug所付出的代价就越高，而且修复代价呈指数级增长。

bug缺陷等级：按照bug对被测系统的影响程度，可分为关键缺陷、严重缺陷、一般缺陷、建议改进。

关键缺陷：非常严重的缺陷，比如软件或系统瘫痪、异常退出、频繁的死机，软件或系统重要部件无法正常运行，从而严重影响软件或系统功能的正常运行，均定义为关键缺陷。

严重缺陷：严重地影响软件或系统要求，或未实现基本功能，主要功能无法执行、或数据被破坏、或产生错误结果，而且是在用户常规操作中频繁出现，或者非常规操作中无法避免的主要问题，软件或系统无法满足重要的业务需求，或错误设计配置项或配置项后测试中发现配置有关的问题等。

一般缺陷：软件或系统基本满足用户业务要求，但次要功能丧失，或通过变通手段可以解决，或安装手册或部署文档错误而导致安装部署软件失败，或对应的业务流程功能未实现，但有替代方法来解决，或系统响应时间变慢、产生错误的中间结果但不影响实际使用等影响有限的问题。包括性能问题、安全问题、校验问题、乱码等。

建议改进：使操作者不方便或操作麻烦，但不影响执行工作功能或重要功能。包括界面问题、提示信息、易用性、统一性等，希望提出的建议但不强制进行的修改。

bug数量：该评价模型中，指的是确认修改的bug数量，撤回的bug数量不计入该模型。

bug产生原因：通过查阅某测评中心近5年的测试报告记录，提炼总结出常见的缺陷产生原因，并根据软件生命周期不同阶段分别划分，具体bug产生原因详见表1所示。

表1 软件生命周期不同阶段bug产生原因度量元

度量元：通常用来对软件或系统进行量化管理时，需要重点关注信息对象的基本属性的描述。依据度量数据获取方式，可以把度量元划分为基本度量元(又称为直接度量元)和派生度量元(又称为间接度量元)两种。基本度量元，顾名思义，其数据来源可直接度量获得，派生度量元，其数据来源于其他的数据，一般由两个或多个基本度量元组合获得。在该评价模型中，为了量化软件生命周期不同阶段质量，采取基本度量元方式，以下简称度量元。

熵权法：是统计学领域一种客观赋权方法，在统计学领域中，但数据越分散，熵值越小，可以认为该数据包含信息越多，因此权重越大。在具体使用过程中，根据各指标的数据的分散程度，利用信息熵计算出各指标的熵权，再根据各指标对熵权进行一定的修正，从而得到较为客观的指标权重。

为了能够客观地评价软件生命周期不同阶段质量，针对需求分析、软件设计、软件编码和软件测试这4个阶段，分别从bug引入阶段、bug发现阶段、bug缺陷等级[12]、bug数量、bug产生原因、bug修正代价6个方面，筛选体现每个阶段质量的度量元，对每个度量元进行定义，并采用改进的加权模糊熵权法[13- 17]确定每个度量元的权重系数，减少主观因素干扰，提高度量元权重系数客观性，从而建立起一套行之有效的计算方法和评价机制。

该评价模型主要分以下几步。第1步：提取度量元，以bug引入阶段、bug发现阶段、bug缺陷等级、bug数量、生命周期不同阶段bug产生原因、bug修正系数6个方面作为度量元；第2步：bug产生原因度量元权重系数计算，为减少主观因素干扰，采用改进的加权模糊熵权法确定权重系数；第3步：需求阶段质量评价；第4步，设计阶段质量评价；第5步：编码阶段质量评价；第6步：测试阶段质量评价；第7步，总体质量评价。整个评价流程如图1所示。

图1 软件生命周期质量评价流程

2.2 提取度量元

软件生命周期质量评价方法中，以bug引入阶段、bug发现阶段、bug缺陷等级、bug数量、生命周期不同阶段bug产生原因、bug修正系数6个方面作为度量元，并建立需求阶段bug产生原因度量元集合R= {e1,e2,...，ei}，设计阶段bug产生原因度量元集合D={d1,d2，...，dj}，编码阶段bug产生原因度量元集合C={c1,c2，...，cj}，测试阶段bug产生原因度量元集合T={t1,t2，...，tj}。

2.3 Bug产生原因度量元权重系数计算

为了减少主观因素干扰，提高度量元权重系数客观性，采用改进的加权模糊数熵权法，首先应用模糊数来表示多名专家对bug产生原因度量元做出的评价结果，建立直觉模糊集合。

直觉模糊集的一些基本概念：设X为一给定的论域，则称A={<χi,μA(xi),νA(χi)>|χi∈X}为X上的一个直觉模糊集。其中μA：X→[0,1]和νA：X→[0,1]分别为A的隶属度和非隶属度函数，且对于任意的χi∈X，有0≤μA(χi)+νA(χi)≤1成立。进一步，称πA(χi)=1-μA(xi)-νA(χi)为模糊集A中元素χi的犹豫度，a=(μa，νa)是直觉模糊数，且满足0≤μa≤1，0≤νa≤1[9-10]；专家分别对不同阶段bug产生原因度量元进行评价，采集到需求阶段bug产生原因度量元直觉模糊数，设计阶段bug产生原因度量元模糊数，编码阶段bug产生原因度量元模糊数，测试阶段bug产生原因度量元模糊数，然后采用加权模糊数熵权法确定不同阶段bug产生原因度量元的权重，加权模糊熵权法计算公式为：

假设X={x1，x2，xi，xn}，A={<χi,μA(xi),νA(χi)>|χi∈X}为专家给出的模糊集，则模糊集的熵计算公式为：

(1)

考虑到bug产生原因权重信息的客观性，减少专家判断的主观性，以bug产生原因问题个数占比作为加权系数，提出bug产生原因度量元权重公式为：

式中，nm为软件生命周期不同bug产生原因度量元对应的问题数；Nm为软件生命周期不同bug产生原因度量元对应的问题总数。

进行归一化处理，最终bug产生原因度量元权重计算公式为：

(3)

2.4 需求阶段质量评价

需求阶段：即软件需求分析阶段，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求转述为完整的需求定义，从而确定系统必须做什么的过程。

该模型中，从两个维度对需求阶段质量减分评价

维度1：bug引入阶段+bug等级+bug数量，在bug引入阶段是需求阶段时，提出需求阶段质量评价第一个减分项公式

(4)

维度2：bug引入阶段+bug数量+bug产生原因，在bug引入阶段是需求阶段时，提出需求阶段质量评价第二个减分项

(5)

式中，RSk为需求阶段bug产生原因权重系数；rn为需求阶段bug产生原因总分类数；RMk为需求阶段bug产生原因对应的bug缺陷数量。

从而定义需求阶段质量评价减分项R=R1+R2，R越大，表明需求阶段质量越不好，在后续项目中越需要加强需求人员的能力。

2.5 设计阶段质量评价

设计阶段：即软件设计，是从软件需求规格说明书出发，根据需求分析阶段确定的功能设计软件系统的整体结构、划分功能模块、确定每个模块的实现算法以及编写具体的代码，形成软件的具体设计方案。

该模型中，从两个维度对设计阶段质量进行减分评价

维度1：bug引入阶段+bug等级+bug数量，bug引入阶段是设计阶段时，设计阶段质量评价第一个减分项:

(6)

维度2：bug引入阶段+bug数量+bug产生原因，设计阶段质量评价第二个减分项:

式中，DSk为设计阶段bug产生原因权重系数；dn为设计阶段bug产生原因总分类数；DMk为设计阶段bug产生原因对应的bug缺陷数量。

从而定义阶段质量评价减分项D=D1+D2，D越大，表明设计阶段质量越不好，在后续项目中越需要加强设计人员的能力；

2.6 编码阶段质量评价

编码阶段：即软件编码，是将设计阶段得到详细设计转换为基于某种计算机语言的程序，即源程序代码。

该模型中，从两个维度对编码阶段质量进行减分评价

维度1：bug引入阶段+bug等级+bug数量，bug引入阶段是编码阶段时，编码阶段质量评价第一个减分项公式:

(8)

维度2：bug引入阶段+bug数量+bug产生原因，bug引入阶段是设计阶段时，编码阶段质量评价第二个减分项公式:

(9)

从而定义编码阶段质量评价减分项C=C1+C2，C越大，表明编码阶段质量越不好，在后续项目中越需要加强编码人员的能力；

2.7 测试阶段质量评价

测试阶段：即软件测试，描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。换句话说，软件测试是一种实际输出与预期输出之间的审核或者比较过程。软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否满足设计要求进行评估的过程。

测试阶段质量评价不同于其他阶段，本发明中，对于bug发现阶段晚于bug引入阶段的情况，测试阶段质量评价中也需要扣分。统计资料显示在需求阶段修正一个错误的代价假如是1，则在设计阶段就是它的2～3倍，在编码阶段就是它的5～8倍，在测试阶段就是它的20～30倍[18-19]，修正错误的代价不是随时间线性增长，而几乎是呈指数增长的，软件的质量问题越到后面解决成本越高。根据修正错误的代价大小，确定需求阶段错误修正代价系数是1，设计阶段错误修正代价系数是e，编码阶段错误修正代价系数是e2，测试阶段错误修正系数是e3，归一化处理后各个阶段bug修正代价权重系数如表2所示。

表2 软件生命周期不同阶段bug修正代价系数

该模型中，从3个维度进行测试阶段质量减分评价。

维度1：bug引入阶段+bug等级+bug数量，bug引入阶段是测试阶段时，测试阶段质量评价第一个减分项公式:

(10)

维度2：bug引入阶段+bug数量+bug产生原因，bug引入阶段是测试阶段时，测试阶段质量评价第二个减分项公式:

(11)

维度3：bug引入阶段+bug发现阶段+bug修正系数，bug引入阶段是测试阶段时，测试阶段质量评价第三个减分项:

(12)

式中，Yk为bug引入阶段，本发明中把需求阶段定义为1，设计阶段定义为2，编码阶段定义为3，测试阶段定义为4；Fk为bug发现阶段，本发明中均定为测试阶段，n=4；P为bug引入阶段对应的修正系数，参见表2。

从而定义测试阶段质量评价减分项T=T1+T2+T3，T越大，表明测试阶段质量评价越不好，在后续项目中越需要加强测试人员的能力。

2.8 总体质量评价

总体质量减分评价公式

S=R+D+C+T

(13)

式中，R为需求阶段质量减分评价；D为设计阶段质量减分评价；C为编码阶段质量减分评价；T为测试阶段质量减分评价。S越大，表明该软件总体质量越差。

3 测试结果与分析

从某具有丰富经验的XX测评中心机构中，查找近5年测试报告记录，从中筛选中各个阶段bug产生原因，定义软件生命周期不同阶段度量元详见表2。

首先邀请5位具有专业知识的软件测评专家，分别对需求分析、设计、编码和测试阶段bug产生原因进行评价，为了对不同阶段bug产生原因之间的重要程度进行定量的描述，定义如表3所示的标度[20]，括号3个数字代表(μij,νij,πij)。

表3 bug产生原因重要程度定义的标度表

根据表3，各位专家两两比较软件生命周期不同阶段bug产生原因重要程度，并以某XX军用模拟训练系统中系统数据管理软件为例，其不同阶段对应问题数如表4所示。

表4 软件不同阶段对应问题数

以专家给出的直觉模糊数为基础，利用公式(1)～(3)计算软件不同阶段bug产生原因权重系数，如表5所示。

表5 软件不同阶段bug产生原因权重系数

利用公式(4)～(13)，分别计算软件生命周期不同阶段质量减分评价，如表6所示。

表6 软件不同阶段质量评价结果

根据公式(14)，计算该软件总体质量评价

S= 2.43+3.57+11.72+6.658=24.378

从表6中可以看出，被评软件中需求分析阶段评分结果为2.43，设计阶段评分结果为3.57，编码阶段评分结果为11.72，测试阶段评分结果为6.658，软件总体质量评分结果是24.378。该软件生命周期不同阶段质量优劣顺序为需求分析阶段>设计阶段>测试阶段>编码阶段，故对于项目组管理人员来说，需要重点关注编码阶段质量，提高编码人员能力。经对数据做人工分析，可以看出评价的结果和新设计的计算准则是基本吻合。

4 结束语

目前的软件质量评估标准一方面只是从概念上定义了一个笼统抽象的通用模型来评估整个软件的质量，另外一方面缺乏针对软件生命周期不同阶段质量评估模型。针对这些问题，对软件生命周期中和软件质量问题最为密切相关的几个阶段，包括需求分析、软件设计、软件编码和软件测试，制定了新的软件生命周期质量评价方法，分析度量元，并提出改进的加权模糊熵权法确定加权系数，给出评价方法和评价流程，最后通过实例对方法进行了有效验证，为软件生命周期不同阶段质量建立了一套有效的评价标准。当然，评价标准需要经过实践不断验证和不断的改良，评价度量元和加权系数也是需要在实践中不断的验证而修改和补充。