军用软件可靠性评估技术研究

军用软件可靠性评估技术研究
军用软件可靠性评估技术研究

军用软件可靠性评估技术研究

(版权声明:本文的著作权人,对该作品拥有完整的版权,受著作权法保护。严禁任何媒体、网站、个人或组织以任何形式或出于任何目的在未经本人书面授权的情况下用于商业目的或发行,但允许非商业目的使用。)

摘要:软件可靠性是衡量软件质量的重要指标之一,软件可靠性测试和评估是提高软件可靠性的有效手段。本文针对某系统的嵌入式软件,研究了软件可靠性测试关键技术及统计方案,将软件可靠性测试评估技术应用在某嵌入式系统的软件中,通过验证软件是否满足可靠性指标要求,为评价软件质量提供定量依据。

1引言

随着数字化技术的大量应用,软件在XXX系统中的重要性越来越大,其规模和复杂性急剧增加,软件已逐步成为独立的产品。为保证软件可靠性,需要对软件进行可靠性测试和评估工作,从而可以尽早发现并改正软件中影响质量的缺陷,有效提高软件可靠性,缩短产品的研制周期和降低软件研制成本。

软件可靠性是指在规定环境下,规定时间内软件不引起系统失效的概率。软件可靠性是衡量软件质量的重要指标之一,不但与软件存在的差错有关,而且与系统输入和系统使用有关。通常来说,软件发生失效的次数越多或时间间隔越短,软件可靠性越低。

软件可靠性要求可以包括定性定及量要求。软件可靠性测试是在软件生存周期的系统测试阶段提高软件可靠性水平的有效途径。同时,软件可靠性测试也是评估软件可靠性水平,验证软件产品是否达到软件可靠性要求的重要且有效的途径。软件可靠性测试流程如图1。

图1 软件可靠性测试流程

2软件可靠性测试关键技术

1.操作剖面

操作剖面“是指对系统使用条件的定义。即系统的输入值用其按时间的分布或按它们在可能输入范围内的出现概率的分布来定义”。粗略地说, 操作剖面是用来描述软件的实际使用情况的。操作剖面是否能代表、刻画软件的实际使用取决于可靠性工程人员对软件的系统模式、功能、任务需求及相应的输入激励的分析,取决于他们对用户使用这些系统模式、功能、任务的概率的了解。操作剖面构造的质量将对测试、分析的结果是否可信产生最直接的影响。

操作剖面的分解次序为:客户-用户-系统模式-功能-操作,操作剖面构造的具体流程如下。

l)客户剖面由独立的客户类型序列构成。

客户类型是群体中以相近的方式使用系统的一个或多个客户,这些客户在使用软件的方式上与其他客户存在显著区别。客户剖面中需要为每一种客户类型确定发生概率。

2)用户剖面是用户组及其发生概率的集合,通常在客户剖面的基础上建立。

3)系统模式剖面是系统模式及其相应发生概率的一个集合。系统模式可以来源于软件的需求或使用情况分析。XXX系统软件的配置项的使用模式主要分为:协同运行、独立运行和试验台三种使用模式。

4)功能剖面是在系统模式下分解系统所需的功能,并确定每个功能的发生概率。功能剖面的构造通常需要依据软件的研制任务书或软件的需求文档,再结合运行环境的各种情况得到功能列表,并为每个功能分配发生概率。

5)操作剖面是操作及其发生概率的集合,确定操作剖面的主要步骤是列出操作并确定每个操作的发生概率。一个功能可以映射成一个或多个操作,一组功能也可以重新合并成一组不同的操作,因此能够根据功能剖面获取操作列表。

2.软件可靠性环境构建

图2 软件可靠性测试环境

软件可靠性测试环境是指为被测软件提供测试输入并采集测试输出的软硬件环境。实时嵌入式软件进行可靠性测试可以采用全数字仿真技术、半仿真模式的测试环境。为了得到尽可能真实的可靠性测试结果,实物仿真平台和系统联试等可靠性测试应尽量在真实的环境下进行,但是在许多情况下,一般采用半实物仿真环境,如北航GESTE、德国的ADS-2航空电子设备开发

仿真测试系统等。

测试环境的体系结构定义系统的组成和各个节点的定义以及它们的物理连接和数据通信协议。它同时决定了其功能是如何组织和整个测试环境的载荷是如何分布的。以下对最基本的结构进行说明。仿真测试环境的基本结构如图2所示。

1) 主机(Host)Host

通常是一台Windows NT PC机。它的主要任务是:用户命令接口;系统配置;测试用例及测试方案生成;测试脚本编写;测试过程监控;测试回放;测试结果分析和处理;可靠性评估;测试文档辅助生成;数据库管理。有时,数据库采用专门的数据库服务器。

2) 激励—仿真机

一般采用具备实时处理能力的工作站或微机,它们可以是运行实时操作系统的工作站和微机,也可以是本文后面提及的对普通操作系统进行实时扩展的微机,还包括一系列的IPO 设备(如MIL STD21553、ARINC429、ARINC629、RS2232P422、APD、DPA 等)和它们的驱动程序。其任务主要包括:解释测试脚本,对数据进行仿真处理;生成激励信号,驱动被测软件运行;接收测试数据,进行实时比较;实时显示。

3) Host和激励—仿真机的通信

通常采用以下方式进行通信:TCP/IP。

3.可靠性验证测试方案设计

可靠性验证测试是一种统计试验,测试策划阶段应选定可靠性测试统计方案。选择统计测试方案时应考虑验证指标的类别、软件的质量要求、可承受的最大测试时间、可承受得最大失效数、测试经费、费用与时间的权衡等诸多因素。针对采用成功率表示产品可靠性的验证测试,通常采用成功率的验证测试方案。所规定的成功率是一个产品将完成所要求的功能的概率或是产品在规定的条件下试验成功的概率。观测的成功率可以定义为在试验结束时未失效的产品数对试验产品总数的比值或成功的试验次数对试验总次数的比值。成功率的验证测试方案的主要参数有:

R 成功率;

N 接收所要求的固定试验数;

R 积累失效数;

R1 拒收失效数;

生产方风险;

使用方风险。

成功率的验证测试方案采用截尾序贯统计方案。

图3 截尾序贯方案示意图

通过数据收集,收集的数据包括软件的输入数据、输出结果,以便进行失效分析和进行回归测试;可靠性失效数据包括每次失效发生的时间或一段时间内发生的失效数,失效数据可以实时分析得到,也可以事后分析得到。数据收集的质量对于最终的可靠性分析结果有着很大的影响,采用了自动化手段进行数据的收集,以提高效率、准确性和完整性。

3可靠性测试结果分析

按照上述方法生成了100 个测试用例。在一台配置为研华工控机、两台台式机环境的计算机上,通过手动方式将测试用例输入到被测软件,利用一个为配合这种软件可靠性测试方法而开发的数据辅助收集软件,采集测试运行的时间与失效信息,包括测试用例序号、测试日期、测试开始时刻、测试结束时刻/ 失效发生时刻、测试运行时间、累计运行时间、失效现象等。通过测试记录下了6次失效。计算出当时提交给测试组的软件的可靠性为0.9,需要进一步提高质量。4结束语

本文通过对软件可靠性测试和评估技术进行了研究和应用,验证了软件可靠性测试和评估的有效性,可靠性测试和评估工作提供技术和范例支持对XXX系统研制工作的可行性,对后续产品开展有较大的指导意义。

软件可靠性与安全性分析、评估方法及建议

软件可靠性与安全性分析、评估方法及建议 一、背景介绍 随着产品技术的发展及数字化技术的应用,软件在产品中所占的比重越来越大,其规模和复杂性急剧增加,对产品的可靠性、安全性工作提出了严峻的考验。为保证软件可靠性,需要对软件进行可靠性测试和评估工作,从而尽早发现并改进软件中影响产品质量的缺陷,有效提高软件可靠性。为保障软件安全性,需要对软件进行安全性分析与验证工作。 目前,随着GJB Z 161-2012 军用软件可靠性评估指南、GJB 900A-2012 装备安全性工作通用要求、GJB 102A-2012军用软件安全性设计指南、ARP4761与民用机载系统安全性评估流程及DO-178B/C机载系统合格审定过程中的软件考虑等标准的颁布实施,以及空军航定〔2012〕4号《航空军用软件定型测评进入条件评估准则》中明确提出关键软件在进入定型测评前必须具备《软件失效风险分析报告》;空军装型〔2010〕131号《空军重点型号软件工程化要求》中也明确提出在软件研制阶段中,必须要开展软件安全性分析与验证工作等规定。美国在70年代研制F/A-18飞机期间首次引入软件安全性技术。在研制F-22和F-35飞机时,则明确要求按照MIL-STD-882和DO-178B开展机载软件安全性工作。在民机领域,波音和空客均严格按照ARP-4761及DO-178B/C标准开展了软件安全性分析与验证,并作为适航审定的核心要素。在高铁、核工业、汽车、医疗等领域,同样要求按照IEC 61508、EN50128、IEC60880、IEC 61513、ISO 14971等标准,对构建高安全性软件做出严格规定。 从上述可以看出,当前世界各国对于软件产品的可靠性评估、安全性分析验

浅析软件质量指标度量

软件质量指标度量 V 1.0 2012.3

目录 1综述 (3) 1.1编写目的 (3) 1.2阅读指南 (3) 2软件质量指标 (4) 2.1需求功能点覆盖率 (4) 2.2用例执行覆盖率 (4) 2.3缺陷修复率(截至于**年*月*日) (5) 2.4缺陷遗留个数(截至于**年*月*日) (5) 2.5缺陷分布统计(模块缺陷率) (5) 2.6缺陷分布统计(严重缺陷率) (6) 2.7缺陷密度及收敛 (7) 3测试过程质量指标 (9) 3.1缺陷探测率 (9) 3.2有效缺陷率 (9) 3.1用例执行效率 (10) 3.2缺陷发现率 (10) 4交付质量指标 (12) 4.1加载回退率 (12) 4.2故障回退率 (12) 5版本说明 (13)

1综述 1.1 编写目的 本文档主要为测试经理、测试组长/测试人员、技术负责人、项目经理、开发人员等提供软件质量、测试质量、交付质量等衡量依据。通过不同指标的目标设定、过程跟踪、结果分析,为当期被测产品的质量提供可参考的数据,也为后续测试提供数据的基础积累,并作为制定方法流程的依据。 1.2 阅读指南 ●软件测试质量指标主要针对研发项目、商务项目被测产品出具数据 度量。 ●测试过程质量指标主要为测试经理、测试组长对测试人员的测试执 行质量出具数据度量。 ●交付质量主要为新需求的交付质量出具数据度量。 三者可单独使用,也可结合使用。

2软件质量指标 2.1 需求功能点覆盖率 【需求覆盖率】:计算测试用例总数之和除以与之一一对应的功能点数之和,主要查看是否有功能点遗漏测试的情况。 【公式】:∑测试用例数(个)/ ∑功能点(个) 说明:用例覆盖需求矩阵,一个需求对应多个功能点。 【数据来源】:《联通集中集团客户业务支撑系统销售管理用户需求说明书》《联通集中集团客户业务支撑系统销售管理需求跟踪矩阵》 【计算结果】需求覆盖率=113/8=14.13 2.2 用例执行覆盖率 【用例执行覆盖率】:计算测试用例执行总数除以与之一一对应的测试数之和,主要查看是否有测试用例执行遗漏或有效的情况。 【公式】:∑执行的测试用例个数(个)/ ∑测试用例个数(个)*100% 【数据来源】:《iSMS测试进度跟踪表》 【计算结果】:用例执行覆盖率=100%

最新软件需求分析(案例)

案例one:教学管理系统(用例驱动的交互式需求获取) 以一个教学管理系统JXGL的分析与设计作为示例,说明用例驱动技术在软件项目开发中的应用。 高等学校的教学管理内容十分丰富,工作繁多。作为一个示例,规定开发教学管理系统JxGL只处理每学期的课程选修注册和学生的成绩管理。教学管理系统JXGL的用户是学校的学生、教师和教学管理员。学生使用JXG系统查询新学期将开设的课程和授课教师的情况,选择自己要学习的课程,并进行登记注册。学生还可以使用JXGL系统查询自己的课程成绩。教师使用JXGL系统查询新学期将开设的课程、参加听课的学生情况,以及学生的考试成绩。教学管理员使用JXGL系统进行教学管理,包括新学期的课程选课注册管理和学生成绩管理。 1.需求描述: 对教学管理系统JXGL要求提供两个方面的服务: (1)选课管理,负责新学期的课程选课注册工作; (2)成绩管理,负责学生成绩管理。 在选课管理方面应填写的用户需求描述如下。 (1)录入与生成新学期课程表 教学管理员在新学期开始前录入新学期课程,打印将开设的课程目录表,供师生参 考选择。若某课程的实际选课学生少于10人,则停开该课程,把该课程从课程目 录表中删除;若某课程的选课学生多于30人,则停止选课。 (2)学生选课注册 新学期开始前一周为选课注册时间,在此期间学生可以选课注册,并且允许改变或 取消注册申请。 每个学生选课不超过4门课程。每门课程最多允许30名学生选课注册。 学生可以在图书馆、各系资料室、学生宿舍等处的计算机上联网进行选课注册。在 选课注册结束后,教学管理员打印学生选课注册名单和开课通知书,送交有关部门 和授课教师。 (3)查询 可以查询课程信息、学生选课信息和学生、教师信息。 学生、教师、教学管理员可以查询课程表,获得课程信息。查询的关键词以是:课 程名,授课教师名,学分。 教师、教学管理员可以查询学生选课情况。查询的关键词可以是:学生名、程名, 授课教师名,学分。学生只允许查询自己的选课信息,不允许查询别人选课信息。 学生、教师、教学管理员可以查询学生或教师的信息。查询的关键词可以是学生名、 教师名,性别、班级、职称。 (4)选课注册信息的统计与报表生成。 教学管理员对学生的选课注册信息进行统计(按课程,按学生,按班级),印汇总统 计报表。 在成绩管理方面应填写的用户需求描述如下: (1)成绩录入:

串并联可靠性模型的应用及举例

上海电力学院 选修课大型作业 课程名称:机电系统可靠性与安全性设计报告名称:串并联可靠性模型的应用及举例院系:能源与机械工程学院 专业年级:动力机械140101 学生姓名:潘广德 学号:14101055 任课教师:张建平教授 2015年4月28日

浅谈串并联可靠性模型的应用并举例 摘要 详细阐述了机械可靠性工程中串并联可靠性模型的应用,并详细的举例说明。系统可靠性与组成单元的数量、单元可靠性以及单元之间的相互联接关系有关。以便于可靠性检测,首先讨论了各单元在系统中的相互关系。在可靠性工程中,常用可靠性系统逻辑图表示系统各单元之间的功能可靠性关系。在可靠性预测中串并联的应用及其广泛。必须指出,这里所说的组件相互关系主要是指功能关系,而不是组件之间的结构装配关系。 关键词:机械可靠性串联并联混联应用举例 0前言 学技术的发展,产品质量的含义也在不断的扩充。以前产品的质量主要是指产品的性能,即产品出厂时的性能质量,而现在产品的质量已不仅仅局限于产品的性能这一指标。目前,产品质量的定义是:满足使用要求所具备的特性,即适用性。这表明产品的质量首先是指产品的某种特性,这种特性反应这用户的某种需求。概括起来,产品质量特性包括:性能、可靠性、经济性和安全性四个方面。性能是产品的技术指标,是出厂时产品应具有的质量属性,显然能出厂的产品就赢具备性能指标;可靠性是产品出厂后所表现出来的一种质量特性,是产品性能的延伸和扩展;经济性是在确定的性能和可靠性水平下的总成本,包括购置成本和使用成本两部分;安全性则是产品在流通和使用过程中保证安全的程度。在上述产品特性所包含的四个方面中,可靠性占主导地位。性能差,产品实际上是废品;性能好,也并不能保证产品可靠性水平高。反之,可靠性水平高的产品在使用中不但能保证其性能实现,而且故障发生的次数少,维修费用及因故障造成的损失也少,安全性也随之提高。由此可见,产品的可靠性是产品质量的核心,是生产厂家和广大用户所努力追求的目标。 1串联系统可靠性模型的工作原理 如果一个系统中的单元中只要有一个失效该系统就失效,则这种系统成为串联系统。或者说,只有当所有单元都正常工作时,系统才能正常工作的系统称为串联系统。 设系统正常工作时间(寿命)这一随机变量为t,则在串联系统中,要使系统能正常工作运行,就必须要求每一个单元都能正常工作,且要求每一单元的正常工作时间都大于系统正常工作时间t。假设各个单元的失效时间是相互独立的,按照概率的乘法定理和可靠性定

可靠性软件评估报告

可靠性软件评估报告 目前,关于可靠性分析方面的软件产品在市场上出现的越来越多,其中比较著名的有以下3种产品:英国的ISOGRAPH、广五所的CARMES和美国Relex。总体上来说,这些可靠性软件都是基于相同的标准,因此它们的基本功能也都十分类似,那么如何才能分辨出它们之间谁优谁劣呢?根据可靠性软件的特点和我厂的实际情况,我认为应主要从软件的稳定性、易用性和工程实用性三个方面进行考虑,现从这几个方面对上述软件进行一个简单的论证,具体内容如下。 稳定性 要衡量一个可靠性软件的好坏,首先是要看该软件的运行是否稳定。对一个可靠性软件来说,产品的稳定性十分重要。一个没有经过充分测试、自身的兼容性不好、软件BUG很多、经常死机的软件,用户肯定是不能接受的。当然,评价一个可靠性分析软件是否具有良好的稳定性,其最好的证明就是该产品的用户量和发展历史。 ISOGRAPH可靠性分析软件已将近有20年的发展历史,目前全球已有7000多个用户,遍布航空、航天、铁路、电子、国防、能源、通讯、石油化工、汽车等众多行业以及多所大学,其产品的每一个模块都已经过了isograph的工程师和广大用户的充分测试,因而其产品的稳定性是毋庸置疑的。而广五所的CARMES和美国Relex软件相对来说,其用户量比较少,而且其产品的每一个模块的发布时间都比isograph软件的相应模块晚得多,特别是一些十分重要的模块。 例如,isograph的故障树和事件树分析模块FaultTree+是一个非常成熟的产品,它的发展历史已经有15年了。Markov模块和Weibull模块也具有多年的发展历史,这些模块目前已经拥有一个十分广泛的用户群,它们已经被Isograph的工程师和大量的客户广泛的测试过,产品的稳定性值得用户信赖。而Relex的故障树和事件树相对比较新,它大约在2000年被发布,而Markov模块和Weibull模块2002年才刚刚发布,这些模块还没有经过大量用户的实际使用测试,其功能的稳定性和工程实用性还有待于时间的考验。广五所的CARMES软件的相应模块的发布时间就更晚了,有些甚至还没有开发出来,而且其用户主要集中在国内,并没有经过国际社会的广泛认可。 易用性 对一个可靠性分析软件产品来说,其界面是否友好,使用是否方便也十分重要,这关系到工程师能否在短时间内熟悉该软件并马上投入实际工作使用,能否充分发挥其作用等一系列问题。一个学习十分困难、使用很不方便的软件,即使其功能十分强大,用户也不愿使用。 ISOGRAPH软件可以独立运行在Microsoft Windows 95/98/Me/2000/NT/XP平台及其网络环境,软件采用大家非常熟悉的Microsoft产品的特点,界面友好,十分容易学习和使用。该软件提供了多种编辑工具和图形交互工具,便于用户在不同的模块间随时察看数据和进行分析。你可以使用剪切、复制、粘贴等工具,或者直接用鼠标“托放”来快速的创建各种分析项目,你还可以将标准数据库文件,如Microsoft Access数据库、Excel电子表格以及各种格式的文本文件作为输入直接导入到isograph软件中,使项目的建立变得非常简单。另外,Isograph 各软件工具都提供了功能强大的图形、图表和报告生成器,可以用来生成符合专业设计要求的报告、图形和表格,并可直接应用到设计分析报告结果中。 ISOGRAPH软件的一个显著特性就是将各软件工具的功能、设计分析信息、分析流程等有机地集成在一起,其全部的分析模块可以在同一个集成界面下运行,这既可以保证用户分析项目的完整性,还可以使用户在不同的模块间共享所有的信息,不同模块间的数据可以实时链接,而且还可以相互转化。例如,你可以在预计模块和FMECA模块之间建立数据链接,当你修改预计模块中的数据时,FMECA模块中对应的数据会自动修改,这既可以节省

软件系统需求分析报告

需求分析报告 《高校学生学籍管理信息系统》 目录 1-------------------------------------------------------------------------------概述 1.1-----------------------------------------------------------------------------背景 1.2-----------------------------------------------------------------------------系统目标1.2.1------------------------------------------------------------------------完成的任务1.2.2------------------------------------------------------------------------不完成的任务1.3-----------------------------------------------------------------------------业务模式 1.4-----------------------------------------------------------------------------业务状况 2---------------------------------------------------------------------------------用户需求 2.1-----------------------------------------------------------------------------业务需求2.1.1------------------------------------------------------------------------使用范围2.1.2------------------------------------------------------------------------功能要求2.1.3------------------------------------------------------------------------权限管理 2.2-----------------------------------------------------------------------------性能需求 3---------------------------------------------------------------------------------业务流程 3.1----------------------------------------------------------------------------与其他系统的关系3.2----------------------------------------------------------------------------业务流程图 4---------------------------------------------------------------------------------业务逻辑 4.1-----------------------------------------------------------------------------业务分解 4.2-----------------------------------------------------------------------------业务描述

几种常见软件可靠性测试方法综述及应用对比(精)

几种常见软件可靠性测试方法综述及应用对比 上海交通大学陈晓芳 [摘要]软件可靠性测试是软件可靠性工程的一项重要工作内容,是满足软件可靠性要求、评价软件可靠性水平及验证软件产品是否达到可靠性要求的重要途径。本文探讨、研究了软件可靠性测试的基本概念,分析、对比了几种软件可靠性测试主要方法的优缺点。 [关键词]软件可靠性软件可靠性测试软件测试方法 引言 软件可靠性工程是指为了满足软件的可靠性要求而进行的一系列设计、分析、测试等工作。其中确定软件可靠性要求是软件可靠性工程中要解决的首要问题,软件可靠性测试是在软件生存周期的系统测试阶段提高软件可靠性水平的有效途径。各种测试方法、测试技术都能发现导致软件失效的软件中残存的缺陷,排除这些缺陷后,一般来讲一定会实现软件可靠性的增长,但是排除这些缺陷对可靠性的提高的作用却是不一样的。其中,软件可靠性测试能最有效地发现对可靠性影响大的缺陷,因此可以有效地提高软件的可靠性水平。 软件可靠性测试也是评估软件可靠性水平,验证软件产品是否达到软件可靠性要求的重要且有效的途径。 一、软件可靠性测试概念 “测试”一般是指“为了发现程序中的错误而执行程序的过程”。但是在不同的开发阶段、对于不同的人员,测试的意义、目的及其采用的方法是有差别的。在软件开发的测试阶段,测试的主要目的是开发人员通过运行程序来发现程序中存在的缺陷、错误。而在产品交付、验收阶段,测试主要用来验证软件产品是否达到用户的要求。或者说,对于开发人员,测试是发现缺陷的一种途径、手段,而对于用户,测试则是验收产品的一种手段。

二、软件测试方法 软件测试方法有以下几个主要概念:白盒测试、黑盒测试、灰盒测试。 白盒测试(W h ite-box testing或glass-box testing是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法,溢出,路径,条件等等中的缺点或者错误,进而加以修正。 黑盒测试(B lack-box testing是通过使用整个软件或某种软件功能来严格地测试,而并没有通过检查程序的源代码或者很清楚地了解该软件或某种软件功能的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。通常测试人员在进行测试时不仅使用肯定出正确结果的输入数据,而且还会使用有挑战性的输入数据以及可能结果会出错的输入数据以便了解软件怎样处理各种类型的数据。 灰盒测试(Gray-box testing就像黑盒测试一样是通过用户界面测试,但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的,甚至于还读过部分源代码,因此测试人员可以有的放矢地进行某种确定的条件或功能的测试。这样做的意义在于:如果你知道产品内部的设计和透过用户界面对产品有深入了解,你就能够更有效和深入地从用户界面来测试它的各项性能。 1、白盒测试 白盒测试又称结构测试,透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法,盒子指的是被测试的软件,白盒指的是盒子是可视的,你清楚盒子内部的东西以及里面是如何运作的。 白盒的测试用例需要做到: (1保证一个模块中的所有独立路径至少被使用一次; (2对所有逻辑值均需测试true和false;

软件可靠性模型综述(完整资料).doc

【最新整理,下载后即可编辑】 软件可靠性模型综述 可靠性是衡量所有软件系统最重要的特征之一。不可靠的软件会让用户付出更多的时间和金钱, 也会使开发人员名誉扫地。IEEE 把软件可靠性定义为在规定条件下, 在规定时间内, 软件不发生失效的概率。该概率是软件输入和系统输出的函数, 也是软件中存在故障的函数, 输入将确定是否会遇到所存在的故障。 软件可靠性模型,对于软件可靠性的评估起着核心作用,从而对软件质量的保证有着重要的意义。一般说来,一个好的软件可靠性模型可以增加关于开发项目的效率,并对了解软件开发过程提供了一个共同的工作基础,同时也增加了管理的透明度。因此,对于如今发展迅速的软件产业,在开发项目中应用一个好的软件可靠性模型作出必要的预测,花费极少的项目资源产生好的效益,对于企业的发展有一定的意义。 1软件失效过程 1.1软件失效的定义及机理 当软件发生失效时,说明该软件不可靠,发生的失效数越多,发生失效的时间间隔越短,则该软件越不可靠。软件失效的机理如下图所示:

1)软件错误(Software error):指在开发人员在软件开发过程中出现的失误,疏忽和错误,包括启动错、输入范围错、算法错和边界错等。 2)软件缺陷(Software defect):指代码中存在能引起软件故障的编码,软件缺陷是静态存在的,只要不修改程序就一直留在程序当中。如不正确的功能需求,遗漏的性能需求等。 3)软件故障(Software fault):指软件在运行期间发生的一种不可接受的内部状态,是软件缺陷被激活后的动态表现形式。 4)软件失效(Software failure):指程序的运行偏离了需求,软件执行遇到软件中缺陷可能导致软件的失效。如死机、错误的输出结果、没有在规定的时间内响应等。 从软件可靠性的定义可以知道,软件可靠性是用概率度量的,那么软件失效的发生是一个随机的过程。在使用一个程序时,在其他条件保持一致的前提下,有时候相同的输入数据会得到不同的输出结果。因此,在实际运行软件时,何时遇到程序中的缺陷导致软件失效呈现出随机性和不稳定性。 所有的软件失效都是由于软件中的故障引起的,而软件故障是一种人为的错误,是软件缺陷在不断的测试和使用后才表现出来的,如果这些故障不能得到及时有效的处理,便不可避免的会

软件需求分析论文

青岛理工大学 软件需求分析论文 题目:宿舍管理系统 班级: ********* 学号: ********* 学生姓名: *** 指导教师: **** 2015年11月17日 一、摘要 需求分析是指理解用户需求,就软件功能与客户达成一致,估计软件风险和评估项目代价,最终形成开发计划的一个复杂过程。需求分析在IT项目中具有十分重要的作用。IT项目的需求分析不仅是项目的开端,也是确保项目成功的基石。本文从IT项目的需求定义、重要性、过程、方法等层面来了解IT项目的需求分析。 关键词:项目需求分析定义过程方法 二、需求的定义和重要性 (一)需求的定义 软件需求是用户为解决某个问题或达到某个目标而需具备的条件或能力。系统或系统组件为为符合合同、标准、规范或其它正式文档而必须满足的条件或必须具备的能力。以上所述为定义条件和能力的文档表达。这一定义既体现了用户对需求的看法(系统的外部行为),也代表了开发人员的观点(一些深层次的

特性)。术语用户隶属于涉众,因为并非所有涉众都是用户。产品为涉众提供价值而必须具备的特性。 显然,需求没有一个统一的定义。为了便于交流,需要协商来决定一组限定词来修饰“需求“这个内涵丰富的术语。并认识到用可通用的形式记录需求的重要性。 (二)需求的重要性 实现有效的需求工程过程可以让组织受益匪浅。减少开发后期以及整个维护过程中不必要的返工并可带来极大的回报。但优质需求的高回报往往不明显,以至人们常常错误的认为讨论需求所花费的时间会导致推延产品的交付。然而,对质量成本的整体评估却显示出重视早期质量工作的意义。 合理的需求过程强调产品开发过程中的协作,要求涉众始终参与合作。收集需求使开发团队对产品的用户和市场有更好的了解。用户和市场是任何项目成功与否的关键因素。在开发产品之前了解市场和用户,与用户收到产品后在进行理解相比,所需的代价要低得多。 邀请用户参与收集需求可以激发他们对产品的热情,并建立他们对产品的忠诚。强调用户的目标而不是华而不实的功能,就能避免那些永远排不上用场的代码。客户的参与能够缩小用户需要的产品与开发人员提交产品之间的期望差。开发者迟早都要面对用户的反馈。应该尽早得到用户的反馈,也可以借助原型来激励用户产生反馈。需求开发的确需要时间,但要比产品测试时或发布后大量的修改所需的时间要少的多。 优质的需求带来的好处远不止这些。把选定的系统需求明确的分配到各个不同的软件、硬件和人员子系统这种方式突出了产品的系统设计方法。有效的变更控制过程可以把需求变更的负面影响降至最低。无歧义的需求文档给测试工作带来了极大的便利,使交付让各方都满意的优质产品的可能性大大提高。 没有人能够保证需求工作所作出的投入一定能够收到回报。但能够通过分析来思考及推测需求能够提供的帮助。首先来看改进过程的投入。其中包括用于评估现状、开发新的过程和文档模板、人员培训、购买参考书籍与工具,以及可能要聘请的顾问和产生的成本等。最大的投入则是开发团队收集、编写、检查和管理需求的时间。接下来则看可以得到的好处和因此而节省的时间和金钱。 三、需求分析的过程 调研

什么是软件可靠性

关于软件可靠性 什么的软件可靠性? 软件可靠性是指在给定时间内,特定环境下软件无错运行的概率。 软件可靠性的内容 软件可靠性包含了以下三个要素: 1.规定的时间 软件可靠性只是体现在其运行阶段,所以将“运行时间”作为“规定的时间”的度量。“运行时间”包括软件系统运行后工作与挂起(开启但空闲)的累计时间。由于软件运行的环境与程序路径选取的随机性,软件的失效为随机事件,所以运行时间属于随机变量。 2.规定的环境条件 环境条件指软件的运行环境。它涉及软件系统运行时所需的各种支持要素,如支持硬件、操作系统、其它支持软件、输入数据格式和范围以及操作规程等。不同的环境条件下软件的可靠性是不同的。具体地说,规定的环境条件主要是描述软件系统运行时计算机的配置情况以及对输入数据的要求,并假定其它一切因素都是理想的。有了明确规定的环境条件,还可以有效判断软件失效的责任在用户方还是研制方。 3.规定的功能 软件可靠性还与规定的任务和功能有关。由于要完成的任务不同,软件的运行剖面会有所区别,则调用的子模块就不同(即程序路径选择不同),其可靠性也就可能不同。所以要准确度量软件系统的可靠性必须首先明确它的任务和功能。 软件可靠性的测试 软件可靠性测试的目的 软件可靠性测试的主要目的有:

(1)通过在有使用代表性的环境中执行软件,以证实软件需求是否正确实现。 (2) 为进行软件可靠性估计采集准确的数据。估计软件可靠性一般可分为四个步骤,即数据采集、模型选择、模型拟合以及软件可靠性评估。可以认为,数据采集是整个软件可靠性估计工作的基础,数据的准确与否关系到软件可靠性评估的准确度。 (3)通过软件可靠性测试找出所有对软件可靠性影响较大的错误。 软件可靠性测试的特点 软件可靠性测试不同于硬件可靠性测试,这主要是因为二者失效的原因不同。硬件失效一般是由于元器件的老化引起的,因此硬件可靠性测试强调随机选取多个相同的产品,统计它们的正常运行时间。正常运行的平均时间越长, 则硬件就越可靠。软件失效是由设计缺陷造成的,软件的输入决定是否会遇到软件内部存在的故障。因此,使用同样一组输入反复测试软件并记录其失效数据是没有意义的。在软件没有改动的情况下,这种数据只是首次记录的不断重复,不能用来估计软件可靠性。软件可靠性测试强调按实际使用的概率分布随机选择输入,并强调测试需求的覆盖面。软件可靠性测试也不同于一般的软件功能测试。相比之下,软件可靠性测试更强调测试输入与典型使用环境输入统计特性的一致,强调对功能、输入、数据域及其相关概率的先期识别。测试实例的采样策略也不同,软件可靠性测试必须按照使用的概率分布随机地选择测试实例,这样才能得到比较准确的可靠性估计,也有利于找出对软件可靠性影响较大的故障。 此外,软件可靠性测试过程中还要求比较准确地记录软件的运行时间,它的输入覆盖一般也要大于普通软件功能测试的要求。 对一些特殊的软件,如容错软件、实时嵌入式软件等,进行软件可靠性测试时需要有多种测试环境。这是因为在使用环境下常常很难在软件中植入错误,以进行针对性的测试。 软件可靠性测试的效果 软件可靠性测试是软件可靠性保证过程中非常关键的一步。经过软件可靠性测试的软件并不能保证该软件中残存的错误数最小,但可以保证该软件的可靠性达到较高的要求。从工程的角度来看,一个软件的可靠性高不仅意味着该软件的失效率低,而且意味着一旦该软件失效,由此所造成的危害也小。一个大型的工程软件没有错误是不可能的,至少理论上还不能证 明一个大型的工程软件能没有错误。因此,保证软件可靠性的关键不是确保软件没有错误,而是要确保软件的关键部分没有错误。更确切地说,是要确保软件中没有对可靠性影响较大的错误。这正是软件可靠性测试的目的之一。软件可靠性测试的侧重点不同于一般的软件功能测试,其测试实例设计的出发点是寻找对可靠性影响较大的故障。因此,要达到同样的可靠性要求,可靠性测试比一般的功能测试更

软件可靠性模型综述

软件可靠性模型综述 可靠性是衡量所有软件系统最重要的特征之一。不可靠的软件会让用户付出更多的时间和金钱, 也会使开发人员名誉扫地。IEEE 把软件可靠性定义为在规定条件下, 在规定时间, 软件不发生失效的概率。该概率是软件输入和系统输出的函数, 也是软件中存在故障的函数, 输入将确定是否会遇到所存在的故障。 软件可靠性模型,对于软件可靠性的评估起着核心作用,从而对软件质量的保证有着重要的意义。一般说来,一个好的软件可靠性模型可以增加关于开发项目的效率,并对了解软件开发过程提供了一个共同的工作基础,同时也增加了管理的透明度。因此,对于如今发展迅速的软件产业,在开发项目中应用一个好的软件可靠性模型作出必要的预测,花费极少的项目资源产生好的效益,对于企业的发展有一定的意义。 1软件失效过程 1.1软件失效的定义及机理 当软件发生失效时,说明该软件不可靠,发生的失效数越多,发生失效的时间间隔越短,则该软件越不可靠。软件失效的机理如下图所示: 1)软件错误(Software error):指在开发人员在软件开发过程中出现的失误,疏忽和错误,包括启动错、输入围错、算法错和边界错等。 2)软件缺陷(Software defect):指代码中存在能引起软件故障的编码,软件缺陷是静态存在的,只要不修改程序就一直留在程序当中。如不正确的功能需求,遗漏的性能需求等。3)软件故障(Software fault):指软件在运行期间发生的一种不可接受的部状态,是软件缺陷被激活后的动态表现形式。 4)软件失效(Software failure):指程序的运行偏离了需求,软件执行遇到软件中缺陷可能导致软件的失效。如死机、错误的输出结果、没有在规定的时间响应等。

军用软件工程标准研究

军用软件工程标准研究 2010-06-21来源:网络 一、软件工程标准产生的背景 众所周知,计算机(硬件)一问世,软件即如影随形而来,井进而发展成一门产业--软件开发。早在60年代,软件开发通常还只是编程者个人行为,软件开发者和使用者往往是同一个(或同一小组的)人。这种个体化的特性使软件设计成为人头脑中的一个隐含过程,除了程序清单之外,没有其他文档保存下来。 从60年代中期到70年代中期,随着计算机应用的日益普及及软件需求量的急剧增加,出现了以小组或小集体为单位的"软件作坊",他们开发的软件主要供本单位使用。这种"软件作坊"基本上仍然沿用早期形成的"个体式"的软件开发方法。但是,由于用户不断提出新需求,所以程序也必须不断做出相应修改;随着硬件或操作系统的频繁更新,又要修改程序以适应新的环境;程序运行时发现错误也需设法改正,所以,不仅"作坊"式的开发方法不能满足客观需求,而且人们发现软件维护工作以令人吃惊的比例在耗费着资源。更严重的是,程序设计的个体化特性使软件最终难于甚至不能维护,于是出现了"软件危机"。软件危机主要体现在: a.不能正确估计软件开发的成本和进度; b.对"已完成的"软件系统,用户经常不满意; c.软件质量靠不住; d.软件常常不能维护; e.没有建立适当的文档资料记录软件开发过程中的信息及其变化; f.软件费用占计算机系统总费用的比例逐年上升等等。 软件危机的产生与软件开发和维护时所使用的方法有关,但根本的还是软件本身的特点使然。软件是计算机系统中的逻辑部件而不是物理部件,在计算机上运行之前,软件质量较难评价,因此,管理和控制软件开发过程相当困难。软件的另一个显著特点是规模庞大,复杂程度高,如美国穿梭号飞船的软件含4000万行代码,相当于4000人年的编程工作量,如何保证每个人完成的工作合在一起构成一个高质量的大型软件显然是一个极端复杂的问题。再者,软件维护常常意味着要修改原来的设计,这样大型复杂的软件的修改,其难度之大是不难想像的。 总之,解决软件危机,仅靠技术措施是办不到的,它更需要有先进的管理措施。60年代后期计算机科学家们就开始研究解决软件危机的方法,并逐渐形成了计算机科学技术领域中的一门新兴学科一一软件工程学。软件工程学是研究采用工程的概念、原理和方法进行软件开发和维护的一门学科。它是软件发展到一定阶段的产物。软件工程学的出现既有工程技术发展提供的客观背景,也是软件发展的必然。 软件发展到软件工程学时代,根本上摆脱了软件"个体式"或"作坊式"的生产方法,人们更注重项目管理和采纳形式化的标准和规范,并以各种生命周期模型来指导项目的开发进程。在此期间出现了CASE(计机算机辅助软件工程)工具,并被广泛用于辅助人们的分析和设计活动,并试图通过创建软件开发环境和软件工厂等途径来提高软件生产率和软件产品质量。

软件质量度量指标v1.0

软件质量指标度量 1综述 (2) 1.1编写目的 (2) 1.2阅读指南 (2) 2软件质量指标 (3) 2.1需求功能点覆盖率 (3) 2.2用例执行覆盖率 (3) 2.3缺陷修复率(截至于**年*月*日) (4) 2.4缺陷遗留个数(截至于**年*月*日) (4) 2.5缺陷分布统计(模块缺陷率) (4) 2.6缺陷分布统计(严重缺陷率) (5) 2.7缺陷密度及收敛 (5) 3测试过程质量指标 (8) 3.1缺陷探测率 (8) 3.2有效缺陷率 (8) 3.1用例执行效率 (9) 3.2缺陷发现率 (9) 4交付质量指标 (11) 4.1加载回退率 (11) 4.2故障回退率 (11) 5版本说明 (12)

1综述 1.1编写目的 本文档主要为测试经理、测试组长/测试人员、技术负责人、项目经理、开发人员等提供软件质量、测试质量、交付质量等衡量依据。通过不同指标的目标设定、过程跟踪、结果分析,为当期被测产品的质量提供可参考的数据,也为后续测试提供数据的基础积累,并作为制定方法流程的依据。 1.2阅读指南 ●软件测试质量指标主要针对研发项目、商务项目被测产品出具数据 度量。 ●测试过程质量指标主要为测试经理、测试组长对测试人员的测试执 行质量出具数据度量。 ●交付质量主要为新需求的交付质量出具数据度量。 三者可单独使用,也可结合使用。

2软件质量指标 2.1需求功能点覆盖率 【需求覆盖率】:计算测试用例总数之和除以与之一一对应的功能点数之和,主要查看是否有功能点遗漏测试的情况。 【公式】:∑测试用例数(个) / ∑功能点(个) 说明:用例覆盖需求矩阵,一个需求对应多个功能点。 【数据来源】:《联通集中集团客户业务支撑系统销售管理用户需求说明书》《联通集中集团客户业务支撑系统销售管理需求跟踪矩阵》 【计算结果】需求覆盖率=113/8=14.13 2.2用例执行覆盖率 【用例执行覆盖率】:计算测试用例执行总数除以与之一一对应的测试数之和,主要查看是否有测试用例执行遗漏或有效的情况。 【公式】:∑执行的测试用例个数(个) / ∑测试用例个数(个)*100% 【数据来源】:《iSMS测试进度跟踪表》 【计算结果】:用例执行覆盖率=100%

软件需求分析方案设计

软件需求分析方案设计 软件需求分析是研究用户需求得到的东西,完全理解用户对软件需求的完整功能,确认用户软件功能需求,建立可确认的、可验证的一个基本依据。今天小编为大家准备了软件需求分析方案设计,欢迎阅读! 软件需求分析方案设计如果我们用数学方法来描述软件需求分析,可以将一个应用软件定义为S,可能应用软件涉及功能性问题非常广,我们用抽象化理论分析,可以划分为各个功能域,可以用D1、D2、… Dn表示,那么,我们可以用一个表达式描述为 S={D1,D2,D3,…Dn} 但是,功能域Di依然存在着有若干个问题P1、P2、P3、…Pm组成,并且每个功能对应于子系统中的一个软构件,我们可以表示为 Di={P1,P2,P3,…Pm} 同样,功能Pj有若干个行为F1、F2、F3、… Fk,每个行为对应于软构件中的实现方法 Pj={F1,F2,F3,…Fk} 一个软件包含了所有功能的集合,同时包含了实现所有功能的所有方法和算法描述。需求分析是依据于用户需求,经过需求问题识别,进行分析、消化与综合,制订规格说明,评审,分为四个阶段,形成用户需求与设计同步,设计满足

用户需求目标。 需求分析方法始终贯穿着吸收、同化、贯彻方法和手段,用商业化行为解决需求与实现中存在的矛盾,解决用户需求与商业化产品融通,解决规范与个性化追求。 软件需求分析的主要实现目标: 1)对实现软件的功能做全面的描述,帮助用户判断实现功能的正确性、一致性和完整性,促使用户在软件设计启动之前周密地、全面地思考软件需求; 2)了解和描述软件实现所需的全部信息,为软件设计、确认和验证提供一个基准; 3)为软件管理人员进行软件成本计价和编制软件开发计划书提供依据; 需求分析的具体内容可以归纳为六个方面:软件的功能需求,软件与硬件或其他外部系统接口,软件的非功能性需求,软件的反向需求,软件设计和实现上的限制,阅读支持信息。 软件需求分析应尽量提供软件实现功能需求的全部信息,使得软件设计人员和软件测试人员不再需要需求方的接触。这就要求软件需求分析内容应正确、完整、一致和可验证。此外,为保证软件设计质量,便于软件功能的休整和验证,软件需求表达无岔意性,具有可追踪性和可修改性。 、软件功能需求

可靠性建模资料整理

软件可靠性建模 1模型概述 1.1软件可靠性的定义 1983年美国IEEE计算机学会对“软件可靠性”作出了明确定义,此后该定义被美国标准化研究所接受为国家标准,1989年我国也接受该定义为国家标准。该定义包括两方面的含义: (1)在规定的条件下,在规定的时间内,软件不引起系统失效的概率; (2)在规定的时间周期内,在所述条件下程序执行所要求的功能的能力; 其中的概率是系统输入和系统使用的函数,也是软件中存在的故障的函数,系统输入将确定是否会遇到已存在的故障(如果故障存在的话)。 软件失效的根本原因在于程序中存在着缺陷和错误,软件失效的产生与软件本身特性、人为因素、软件工程管理都密切相关。影响软件可靠性的主要因素有软件自身特性、人为因素、软件工程管理等,这些因素具体还可分为环境因素、软件是否严密、软件复杂程度、软件是否易于用户理解、软件测试、软件的排错与纠正以及软件可靠性工程技术研究水平与应用能力等诸多方面。 1.2软件可靠性建模思想 建立软件可靠性模型旨在根据软件可靠性相关测试数据,运用统计方法得出软件可靠性的预测值或估计值,下图给出了软件可靠性建模的基本思想。

图软件可靠性建模基本思想 从图中可以看出软件失效总体来说随着故障的检出和排除而逐渐降低,在任意给定的时间,能够观测到软件失效的历史。软件可靠性建模的目标如下:(1)预测软件系统达到预期目标所还需要的资源开销及测试时间;(2)预测测试结束后系统的期望可靠性。1.3软件可靠性建模基本问题 软件可靠性建模需要考虑以下基本问题: (1)模型建立 模型建立指的是怎样去建立软件可靠性模型。一方面是考虑模型建立的角度,例如从时间域角度、数据域角度、将软件失效时刻作为建模对象,还可以将一定时间内软件故障数作为建模对象;另一方面是考虑运用的数学语言,例如概率语言。 (2)模型比较 在软件可靠性模型分类的基础上,对不同的模型分析比较,并对模型的有效性、适用性、简洁性等进行综合权衡,从而确定出模型的适用范围。 (3)模型应用 软件可靠性模型的应用需要从以下两方面考虑:一是给定了软件的开发计划,如何选择适当的模型;二是给定了软件可靠性模型,如何指导软件可靠性工程实践。 软件系统的失效历史可以通过对测试得到的失效数据分析获得,而实际情况中,人们最为关注的是软件未来的失效趋势。软件可靠性模型基本都是建立在一定的假设基础之上,所以,即使花费了大量的时间和精力对软件的可靠性进行预计,也只是一种预测,这

1520950-实验3 软件需求分析

上海建桥学院 本科实验报告 课程名称:软件工程 1520950 学号: 吴明亚 姓名: 软件工程 专业: B15-2 班级: 指导教师:贾铁军 课内实验目录及成绩 信息技术学院 2017年3 月9 日

上海建桥学院实验报告 课程名称:软件工程实验类型:验证、设计 实验项目名称:实验三编写《软件需求规格说明》 实验地点:信息中心222 实验日期:2017年 3 月9 日 1. 实验目的 (1) 根据所选定应用软件的题目,完成整个需求分析工作; (2) 通过实例掌握结构化数据流分析技术; (3) 进行业务需求分析、用户需求、功能需求、非功能需求分析; (4) 写出“软件需求规格说明(SRS)”(含利用工具画出数据流图)。 2. 实验要求 要求做到使用结构化数据流分析技术分析应用软件选题的具体需求,完成详细的数据流图和数据字典,数据流图的基本处理的个数不得少与5个。 3. 实验内容和步骤 用结构化数据流分析技术进行软件系统需求分析,完成数据流图和数据字典。 (1) 深入相关企事业单位进行调研和需求分析。 (2) 综合利用Internet网和相关书籍整理并完善需求分析。 (3) 画出系统数据流图(分清系统是事务型还是加工型)。 (4) 得出软件系统具体的数据字典。 实验学时:2-4学时(建议课外进行2学时)。 4. 实验报告要求 除了实验项目名称、实验目的、实验内容、实验步骤外,还应该有以下内容: (1)软件需求描述:(从功能、性能、接口进行描述) (2)数据流图(PowerDesigner建模工具画出数据流图,由加工、数据流、文件、源点/终点4种元素组成): ①顶层数据流图②1层数据流图③2层数据流图 (3)软件系统数据字典: ①数据流条目②加工条目③文件条目 (4)实验报告 【提示】参考以下《软件需求规格说明(SRS)》编写主要内容(红色部分)和具体格式,对照上述“实验目的”、“实验要求”、“实验内容”、“实验步骤”等方面的完成情况,最后进行认真具体总结,并按时提交实验报告。 《软件需求规格说明(SRS)》格式模板

软件可靠性的评价准则

软件可靠性的评价准则 迄今为止,尚无一个软件可靠性模型对软件的不同特性和不同使用环境都有效。已公开发表的100余种软件可靠性模型,表达形式不同,适应性各异,与实际的软件开发过程有较大差异。而且,新模型还在不断发表。因此,在进行软件可靠性预计、分析、分配、评价和设计之前,对软件可靠性模型进行评价及选择与软件项目相符或相近的模型非常重要。通过建立有效的评价准则,在考虑它们与各种软件的关系的基础上,对拟评价的可靠性模型就有效性、适应性和模型能力等进行评价,判定它们的价值,比较它们的优劣,然后选择有效的软件可靠性模型。另一方面,在可接受的模型之间无法做出明确的选择时,可根据模型的使用环境等,在模型评价准则的基础上,进行模型择优。当然,软件可靠性模型的评价不仅依赖于模型的应用,还依赖于理论的支持和丰富的、高质量可靠性数据的支持。软件可靠性模型的评价最早始于1984年Iannino、Musa、Okumoto和Littlewood所提出的原则。根据这一原则,结合后人的工作,形成了基本的软件可靠性评价准则集。它们是软件可靠性模型比较、选择和应用的基础。 准则一:模型预测有效 软件可靠性模型最重要的评价指标是模型预测的有效性。它根据软件现在和过去的故障 行为,用模型预测软件将来的故障行为和可靠性水平。它主要通过能有效描述软件故障随机过程特性的故障数方式对模型进行描述与评价。基于软件故障时间特性的随机过程也是一种常用的方法,而且这两种方法相互重叠。 要确定软件可靠性模型预测的有效性,首先要比较模型预测质量。这种比较通常通过相 对误差法、偏值、U图法、Y图法、趋势法等方法进行。故障数度量是一种在工程上被广泛应 用的方法。此外,还可以通过比较不同数据集合所做出的中位线图形来评价模型预测的有效性。如果一个模型产生的曲线最接近于0,则该模型是最优的。而且,这种有效性测定方法有效地克服了规范化图形评价与具体软件项目之间的联系,保证了它的独立性。 用给定可靠性数据对软件可靠性模型进行比较时,必须考察拟合模型与观察数据的一致 性和符合性。当然,根据拟合模型进行采样,是否可以获得足够的观察数据非常重要。拟合优度检验是一种系统地表达并证明观察数据和拟合模型之间全局符合性的方法,使用最广泛的是x2检验。 1.准确性 软件可靠性模型预测的准确性可用前序似然函数来测定。设观察到的失效数据对应于软 件相继失效之间的时间序列t1,t2,..,ti-1,并用这些数据来预测软件在未来可能的Ti,即希 望得到Ti的真实概率密度函数Fi(t)的最优估计值。假设以t1,t2,...,ti-1为基础预测Ti的 分布Fi(t)的概率密度函数 @@42D11000.GIF;表达式1@@ 对Ti+1,Ti+2,...,Ti+n的这种向前一步预测,即进行了n+1次预测之后的前序似然函数为 @@42D11001.GIF;表达式2@@ 由于这种度量常常接近于0,所以常用其自然对数进行比较。假定比较的两个软件可靠性 模型分别为A和B,则对它们进行n次预测之后的前序似然比为 @@42D11002.GIF;表达式3@@

相关文档
最新文档