一种结合软件开发质量信息的软件可靠性定量评估方法转让专利

申请号 : CN201910920661.9

文献号 : CN110688152B

文献日 :

基本信息:

PDF:

法律信息:

相似专利:

发明人 : 吴一纯蔡源凤王灵芝谢珊

申请人 : 厦门大学

摘要 :

本发明涉及一种结合软件开发质量信息的软件可靠性定量评估方法,可包括以下步骤:S1.针对软件开发生命周期过程,采用BBN模型对软件开发生命周期、软件剩余缺陷数和软件需求失效概率进行建模,得到软件开发生命周期的软件需求失效概率PFD1;S2.采用BBN方法对PFD、测试次数、失效次数和PFD置信度建模,构建PFD可靠性模型,将PFD1作为PFD的先验分布,将期望的软件需求失效概率PFD2作为PFD的后验分布,使用PFD可靠性模型进行计算,即可获得满足在预定置信度α下PFD2所需进行的无故障测试次数;S3.对软件进行测试,若实际的无故障测试次数小于S2得到的无故障测试次数,则表示软件不可靠,需要进行修改。

权利要求 :

1.一种结合软件开发质量信息的软件可靠性定量评估方法,其特征在于,包括以下步骤:

S1.针对软件开发生命周期过程,采用BBN模型对软件开发生命周期、软件剩余缺陷数和软件需求失效概率PFD进行建模,得到软件开发生命周期的软件需求失效概率PFD1,其中,软件开发生命周期包括需求阶段、设计阶段、实现阶段、测试阶段、安装和验收阶段,具体过程如下:S11.对于软件开发生命周期的每个阶段,开发一个BBN子模型用于评估该阶段完成后软件中存在的缺陷数量,具体地,每个阶段的剩余缺陷数量由3种因素决定:上一阶段的剩余缺陷数,需求阶段作为第一阶段不包含此因素;软件复杂度;软件开发活动和V&V活动的质量,其中,软件复杂度根据软件逻辑图中反馈回路的数量、连接的复杂功能模块的最大数量、连接的功能块的最大数量以及输入和输出的总数来识别;软件开发活动和V&V活动的质量通过对相关的标准和指南进行分析,开发出一系列间接度量指标作为实际质量的指示,也称为指示节点;通过专家对现有软件开发过程和V&V过程可用的历史数据研究,确定BBN模型各节点的条件概率表和先验概率分布;对照标准对待评估软件的开发活动和V&V活动中各指示节点所对应的文档和数据进行评估,输入观察值,便可生成开发活动质量和V&V活动质量节点的质量分布;通过输入BBN模型各指示节点和复杂度节点的观察值,进行运算,即可得每个阶段的剩余缺陷数的评估结果;

S12.在所有阶段的剩余缺陷数量评估完成后,通过缺陷大小分布将软件中存在的缺陷数量转换为软件的需求失效概率,计算公式为:软件失效概率=软件缺陷数*软件缺陷大小分布,其中,软件缺陷大小分布数值的确定是通过对软件开发和V&V团队开发的同等类型和同等复杂度的软件的缺陷数以及软件需求失效概率的历史数据分析得到的;

S2.采用BBN方法对需求失效概率PFD、测试次数、失效次数和PFD置信度建模,构建PFD可靠性模型,将S1得到的软件需求失效概率PFD1作为需求失效概率PFD的先验分布,将期望的软件需求失效概率PFD2作为需求失效概率PFD的后验分布,使用PFD可靠性模型进行计算,即可获得满足在预定置信度α下期望的软件需求失效概率PFD2所需进行的无故障测试次数,具体过程如下:采用BBN方法对需求失效概率PFD、测试次数n、失效次数f和PFD置信度建模,构建“PFD可靠性模型”;对于安全级低需求操作模式软件,每次测试只有一种结果:“成功”或“失败”,因此假定失效次数f符合二项分布B(n,PFD);将S1得到的软件需求失效概率PFD1作为需求失效概率PFD的先验分布;“PFD置信度”为布尔节点,其节点概率表设置为“if(PFD

S3.对软件进行测试,若实际的无故障测试次数小于S2得到的无故障测试次数,则表示软件不可靠,需要进行修改。

2.如权利要求1所述的软件可靠性定量评估方法,其特征在于,S3的具体过程为:

S31、通过引入风险分析的测试剖面,用于帮助说明软件运行场景及限制测试边界,全面模拟软件的实际操作场景,并结合运行场景的相对频率构造完整准确的运行剖面;

S32、根据软件运行剖面,进行蒙特卡罗采样并生成样本文件,其数量由可靠性目标决定;

S33、根据样本文件,利用仿真模型生成用于软件测试的测试用例;

S34、执行测试。

说明书 :

一种结合软件开发质量信息的软件可靠性定量评估方法

技术领域

[0001] 本发明属于软件可靠性分析领域,具体地涉及一种结合软件开发质量信息的软件可靠性定量评估方法。

背景技术

[0002] 软件可靠性是软件开发过程中最重要的因素之一,直接影响了软件的质量的好坏。
[0003] 软件可靠性的定义是在规定的时间和规定的环境下无故障运行的概率。软件失效是指某个特定输入状态与数字化系统内部状态交互触发了软件的一个故障,造成软件未能执行其预期功能或执行非预期功能。软件有与硬件不同的失效因素和模式,软件产品的可靠性与时间不存在直接的函数关系。软件产品不随时间发生变化,除非发生人为的变更或升级。由于现有的知识不完整,不能充分地解释和量化定义软件失效过程的所有变量。与软件失效相关的主要不确定性包括:(1)软件程序中故障的数量和分布是未知的,(2)触发故障的输入的出现是操作环境的函数,并且遵循一个随机过程。为了解决这种不确定性,软件失效可以用概率或频率来描述。
[0004] 现有的软件可靠性定量评估方法有:软件可靠性增长方法、贝叶斯置信网络方法、基于测试的方法、基于指标的方法和基于标准的方法等。一种方法可能同时被归类到上述几种方法中。每一种方法都有不同的适用范围,没有一种方法可以适用于所有情况。
[0005] 《哈尔滨工程大学学报》第35卷第12期的“核安全级仪控软件可靠性评估模型构建”,及《核动力工程》杂志第37卷第1期的“核安全级数字化仪控系统软件可靠性评估”文献中,运用贝叶斯置信网络(Bayesian Belief Network,BBN)方法,通过对系统因素关系分析,结合专家定性判断,对复杂系统进行模型构建,开展了软件可靠性定量评估方法的研究。基于BBN该方法,通过专家意见和客观数据等信息,对软件开发过程的质量分阶段依次评估,最后得到软件可靠性的定量评估结论。评估的缺陷既包含会导致需求失效的缺陷,也包含不会导致需求失效的缺陷。该方法在实践过程中较依赖于专家评分,主观性较强。
[0006] 中国发明专利“一种低需求操作模式下的软件可靠性定量评估方法”(申请号201710727374.7)中公开一种软件可靠性定量评估方法。该软件可靠性定量评估方法,运用软件统计测试(Software Statistical Testing,SST)的方法,通过引入风险分析的测试剖面,全面模拟软件的实际操作场景,并结合运行场景的相对频率构造完整准确的运行剖面;
根据软件运行剖面,进行蒙特卡罗采样并生成样本文件,样本文件用于生成测试用例;根据样本文件利用仿真模型生成用于软件测试的测试用例;最后采用贝叶斯推断,定量评估低需求操作模式下的软件需求失效概率。此方法相比于BBN方法仅考虑会导致需求失效的缺陷,未考虑软件开发过程质量对软件可靠性的影响。此外,此方法采用的是无信息的先验分布,对于安全级软件来说过于保守。

发明内容

[0007] 本发明旨在提供一种结合软件开发质量信息的软件可靠性定量评估方法,以解决上述问题。为此,本发明采用的具体技术方案如下:
[0008] 一种结合软件开发质量信息的软件可靠性定量评估方法,可包括以下步骤:
[0009] S1.针对软件开发生命周期过程,采用BBN模型对软件开发生命周期、软件剩余缺陷数和软件需求失效概率PFD进行建模,得到软件开发生命周期的软件需求失效概率PFD1,其中,软件开发生命周期包括需求阶段、设计阶段、实现阶段、测试阶段、安装和验收阶段;
[0010] S2.采用BBN方法对需求失效概率PFD、测试次数n、失效次数f和PFD置信度建模,构建PFD可靠性模型,将S1得到的软件需求失效概率PFD1作为需求失效概率PFD的先验分布,将期望的软件需求失效概率PFD2作为需求失效概率PFD的后验分布,使用PFD可靠性模型进行计算,即可获得满足在预定置信度α下期望的软件需求失效概率PFD2所需进行的无故障测试次数;
[0011] S3.对软件进行测试,若实际的无故障测试次数小于S2得到的无故障测试次数,则表示软件不可靠,需要进行修改。
[0012] 进一步地,S1的具体过程为,
[0013] S11.对于软件开发生命周期的每个阶段,开发一个BBN子模型用于评估该阶段完成后软件中存在的缺陷数量,具体地,每个阶段的剩余缺陷数量由3种因素决定:上一阶段的剩余缺陷数,需求阶段作为第一阶段不包含此因素;软件复杂度;软件开发活动和V&V活动的质量。其中,软件复杂度根据软件逻辑图中反馈回路的数量、连接的复杂功能模块的最大数量、连接的功能块的最大数量以及输入和输出的总数来识别;软件开发活动和V&V活动的质量通过对相关的标准和指南进行分析,开发出一系列间接度量指标作为实际质量的指示,也称为指示节点;通过专家对现有软件开发过程和V&V过程可用的历史数据研究,确定BBN模型各节点的条件概率表和先验概率分布;对照标准对待评估软件的开发活动和V&V活动中各指示节点所对应的文档和数据进行评估,输入观察值,便可生成开发活动质量和V&V活动质量节点的质量分布;通过输入BBN模型各指示节点和复杂度节点的观察值,进行运算,即可得每个阶段的剩余缺陷数的评估结果;
[0014] S12.在所有阶段的剩余缺陷数量评估完成后,通过缺陷大小分布将软件中存在的缺陷数量转换为软件的需求失效概率,计算公式为:软件失效概率=软件缺陷数*软件缺陷大小分布,其中,软件缺陷大小分布数值的确定是通过对软件开发和V&V团队开发的同等类型和同等复杂度的软件的缺陷数以及软件需求失效概率的历史数据分析得到的。
[0015] 进一步地,S2的具体过程为:
[0016] 采用BBN方法对需求失效概率PFD、测试次数n、失效次数f和PFD置信度建模,构建“PFD可靠性模型”;对于安全级低需求操作模式软件,每次测试只有一种结果:“成功”或“失败”,因此假定失效次数f符合二项分布B(n,PFD);将S1得到的软件需求失效概率PFD1作为需求失效概率PFD的先验分布;“PFD置信度”为布尔节点,其节点概率表设置为“if(PFD
[0017]
[0018] 假设α=95%,PFD2=10^-4,对P(PFD置信度=True|f=0,n)进行敏感性分析,对不同的n=ni计算α值,即可计算出有95%的信心认为软件满足PFD低于10^-4的可靠性目标所需要进行的无故障测试次数。
[0019] 进一步地,S3的具体过程为:
[0020] S31、通过引入风险分析的测试剖面,用于帮助说明软件运行场景及限制测试边界,全面模拟软件的实际操作场景,并结合运行场景的相对频率构造完整准确的运行剖面;
[0021] S32、根据软件运行剖面,进行蒙特卡罗采样并生成样本文件,其数量由可靠性目标确定;
[0022] S33、根据样本文件,利用仿真模型生成用于软件测试的测试用例;
[0023] S34、执行测试。
[0024] 本发明采用上述技术方案,具有的有益效果是:本发明方法考虑了软件开发过程的质量特性和用于评估软件可靠性的统计测试方法,克服了单独的开发过程质量评估主观性,以及单独的统计测试采用无信息先验分布评价结果过于保守且忽视软件开发过程质量对软件可靠性的影响等问题,从而全面地定量评估软件的可靠性是否满足预期要求。

附图说明

[0025] 为进一步说明各实施例,本发明提供有附图。这些附图为本发明揭露内容的一部分,其主要用以说明实施例,并可配合说明书的相关描述来解释实施例的运作原理。配合参考这些内容,本领域普通技术人员应能理解其他可能的实施方式以及本发明的优点。图中的组件并未按比例绘制,而类似的组件符号通常用来表示类似的组件。
[0026] 图1是根据本发明实施例的一种结合软件开发质量信息的软件可靠性定量评估方法的总体流程图;
[0027] 图2是软件开发生命周期的高层级BBN模型示意图;
[0028] 图3是软件设计阶段BBN子模型的示意图;
[0029] 图4是软件复杂度的评估模型示意图;
[0030] 图5是PFD可靠性模型的示意图;
[0031] 图6是压水堆核电站一回路模型的示意图;
[0032] 图7是图6所示的一回路流量低保护子系统软件架构图;
[0033] 图8是图7所示的软件采用本发明方法得到的置信度和测试次数曲线图。

具体实施方式

[0034] 现结合附图和具体实施方式对本发明进一步说明。
[0035] 图1为本发明的软件可靠性评估方法的流程图。图6为压水堆核电站一回路模型,由反应堆和3条并联闭合的冷却剂环路组成,每条环路包括1台主冷却剂泵、1台蒸汽发生器以及相应管道和仪表组成,其中1条环路的热管段连接着稳压器。由于3条环路基本一致,节点图仅给出带有稳压器的一个环路和不带有稳压器的一个环路。图7为一回路流量低保护子系统软件架构图,输入参数有反应堆功率P、冷却剂流量Flow和泵断路器状态,输出为停堆信号。
[0036] 如图1所示,一种结合软件开发质量信息的软件可靠性定量评估方法,可包括以下步骤:
[0037] S1.针对软件开发生命周期过程,采用BBN模型对软件开发生命周期、软件剩余缺陷数和软件需求失效概率(Probability of Failure on Demand,PFD)进行建模,获得如图2所示的软件开发生命周期的高层级BBN模型,可得到软件开发生命周期的软件需求失效概率PFD1。具体地说,通过评估软件开发生命周期5个阶段:需求阶段、设计阶段、实现阶段、测试阶段、安装和验收阶段的剩余缺陷数量和缺陷大小分布(Fault-size Distribution,FSD)间接获得软件开发生命周期过程的可靠性。软件开发生命周期每个阶段的信息都是从相关指南和标准中获取的。软件开发生命周期过程的可靠性评估为软件PFD提供先验分布。
[0038] 对于每个阶段,开发一个BBN子模型用于评估该阶段完成后软件中存在的缺陷数量。在所有阶段的剩余缺陷数量评估完成后,缺陷大小分布FSD用于将软件中存在的缺陷数量转换为软件的需求失效概率。
[0039] 剩余缺陷的数量可以使用FSD转换为软件需求失效概率。缺陷的“大小”代表了不同缺陷被激活导致软件失效的概率。FSD表示的是每个缺陷的需求失效概率的分布。FSD和软件失效概率的计算公式如下:
[0040] 软件失效概率=软件缺陷数*软件缺陷大小分布FSD。
[0041] FSD数值的确定一般是通过对软件开发和V&V团队开发的同等类型和同等复杂度的软件的缺陷数以及软件需求失效概率的历史数据分析得到。
[0042] 以设计阶段为例,搭建了一个如图3所示的BBN子模型评估该阶段结束时剩余缺陷数量。其他阶段的BBN子模型和设计阶段类似,除了需求阶段不对上一阶段的剩余缺陷数量建模。每个阶段的BBN子模型对两种类型的活动进行建模:开发活动和验证与确认(Verification and Validation,V&V)活动。软件开发活动和V&V活动的清单从相关指南和标准中获取。通常,开发团队从事开发活动,V&V团队从事V&V活动。每个阶段的剩余缺陷数量由3种因素决定:(1)上一阶段的剩余缺陷数(需求阶段作为第一阶段不包含此因素);(2)软件复杂度;(3)软件开发活动和V&V活动的质量。
[0043] 其中软件复杂度基于图4所示的模型评估,该模型是根据软件逻辑图中反馈回路的数量、连接的复杂功能模块的最大数量、连接的功能块的最大数量以及输入和输出的总数来识别软件复杂度的。
[0044] 软件的开发活动质量和V&V活动质量无法直接被度量。因此,先通过对相关的标准和指南进行分析,开发出一系列间接度量指标作为实际质量的指示,也称为指示节点。指示节点代表了实际活动质量的度量,可通过指示节点完成从结果到原因的反译推理。通过对指示节点的度量来推断开发活动和V&V活动的质量,指示节点质量的度量结果依据顺应标准和指南的程度可分为3个等级:
[0045] 高:代表完成标准和指南所要求的任务之外,还额外完成了其他的任务。
[0046] 中:完成标准和指南所要求的任务。
[0047] 低:未完成标准和指南所要求的任务。
[0048] 通过专家对现有软件开发过程和V&V过程可用的历史数据研究,确定BBN模型各节点的条件概率表和先验概率分布。专家对照标准对待评估软件的开发活动和V&V活动中各指示节点所对应的文档和数据进行评估,输入观察值,进行运算,便可生成开发活动质量和V&V活动质量节点的质量分布。
[0049] 对于图7所示的一回路流量低保护子系统软件,通过图4所示的软件复杂度评估模型可确定软件的复杂度为中。分析结果如表1所示。
[0050] 表1
[0051]
[0052] 通过输入BBN模型各指示节点和复杂度节点的观察值,进行运算,即可得每个阶段的剩余缺陷数的评估结果,如表2。
[0053] 表2
[0054]
[0055]
[0056] 对于本文的研究对象反应堆保护子系统,收集全世界所有核电站的安全级软件的运行经验来评估FSD的数值,如表3。
[0057] 表3
[0058]均值 标准差 5%分位数 中值 95%分位数
-4 -3 -7 -6 -4
1.02×10 1.34×10 0.24×10 6.12×10 3.03×10
[0059] 通过安装和验收阶段的剩余缺陷数以及FSD的取值可获得软件开发生命周期过程的软件需求失效概率分布,如表4。
[0060] 表4
[0061]均值 标准差 5%分位数 中值 95%分位数
9.56×10-4 3.01×10-3 0 1.54×10-5 2.98×10-3
[0062] 步骤S2:采用BBN方法对需求失效概率PFD、测试次数n、失效次数f和PFD置信度建模,构建如图5所示的“PFD可靠性模型”。对于安全级低需求操作模式软件,每次测试只有一种结果:“成功”或“失败”,因此假定失效次数f符合二项分布B(n,PFD),并将S1得到的软件需求失效概率PFD1作为需求失效概率PFD的先验分布,“PFD置信度”为布尔节点,其节点概率表设置为“if(PFD
[0063]
[0064] 对于可靠性确认测试,测试过程中一般无故障发生,即f=0,对不同的测试次数n=ni计算α值,也就是对P(PFD置信度=True|f=0,n)进行敏感性分析,结果如图8所示。对于一回路冷却剂流量低保护子系统,若要满足在95%的置信度条件下需求失效概率低于10^-4的可靠性要求,至少进行5734次无故障统计测试。
[0065] S3.对软件进行测试,若实际的无故障测试次数小于S2得到的无故障测试次数(5734次),则表示软件不可靠,需要进行修改。当进行5734次测试后,软件仍然没有出现故障,即表示该软件满足可靠性要求。软件测试采用SST方法进行,详见背景技术提到的中国发明专利申请“一种低需求操作模式下的软件可靠性定量评估方法”(申请号201710727374.7),这里简述如下:通过引入风险分析的测试剖面,用于帮助说明软件运行场景及限制测试边界,全面模拟软件的实际操作场景,并结合运行场景的相对频率构造完整准确的运行剖面;根据软件运行剖面,进行蒙特卡罗采样并生成样本文件,其数量由可靠性目标决定;根据样本文件,利用仿真模型生成用于软件测试的测试用例;执行测试。
[0066] 本发明方法考虑了软件开发过程的质量特性和用于评估软件可靠性的统计测试方法,克服了单独的开发过程质量评估主观性,以及单独的统计测试采用无信息先验分布评价结果过于保守且忽视软件开发过程质量对软件可靠性的影响等问题,从而全面地定量评估软件的可靠性是否满足预期要求。
[0067] 尽管结合优选实施方案具体展示和介绍了本发明,但所属领域的技术人员应该明白,在不脱离所附权利要求书所限定的本发明的精神和范围内,在形式上和细节上可以对本发明做出各种变化,均为本发明的保护范围。