范文一:剖析计算机软件可靠性设计论文
剖析计算机软件可靠性设计
【摘 要】本文介绍了软件可靠性设计的基本概念,软件故障产生的机理,软件质量的可靠性参数,并且着重介绍了软件可靠性设计方法。
【关键词】计算机软件;可靠性设计;机理;参数
随着科学技术的不断进步,软件可靠性成为我们关注的一个问题,软件系统规模越做越大越复杂,其可靠性越来越难保证。应用本身对系统运行的可靠性要求越来越高,在一些关键的应用领域,如航空、航天等,其可靠性要求尤为重要,在银行等服务性行业,其软件系统的可靠性也直接关系到自身的声誉和生存发展竞争能力。特别是软件可靠性比硬件可靠性更难保证,会严重影响整个系统的可靠性。在许多项目开发过程中,对可靠性没有提出明确的要求,开发商(部门)也不在可靠性方面花更多的精力,往往只注重速度、结果的正确性和用户界面的友好性等,而忽略了可靠性。在投入使用后才发现大量可靠性问题,增加了维护困难和工作量,严重时只有束之高阁,无法投入实际使用。本文仅就软件可靠性工程在软件开发过程中的应用谈谈自己的认识。
1 软件可靠性设计的基本概念
1.1 软件及软件故障。软件(也称程序)本质上是一种把一组离散输入变成一组离散输出的工具,它由一组编码语句组成,这些语句的功能基本上是以下功能之一:①计算一个表达式并将其结果存储在单元里;②决定下一步要执行哪个语句;③进行输入/输出控
范文二:论文-浅析计算机软件可靠性设计
浅析计算机软件可靠性设计
摘要:本文介绍了软件可靠性设计的基本概念,软件故障产生的机理,软件质量的可靠性参数,并且着重介绍了软件可靠性设计方法。
关键词:计算机软件;可靠性设计;机理;参数
随着科学技术的不断进步,软件可靠性成为我们关注的一个问题,软件系统规模越做越大越复杂,其可靠性越来越难保证。应用本身对系统运行的可靠性要求越来越高,在一些关键的应用领域,其可靠性要求尤为重要,在银行等服务性行业,其软件系统的可靠性也直接关系到自身的声誉和生存发展竞争能力。特别是软件可靠性比硬件可靠性更难保证,会严重影响整个系统的可靠性。在许多项目开发过程中,对可靠性没有提出明确的要求,开发商(部门)也不在可靠性方面花更多的精力,往往只注重速度、结果的正确性和用户界面的友好性等,而忽略了可靠性。在投入使用后才发现大量可靠性问题,增加了维护困难和工作量,严重时只有束之高阁,无法投入实际使用。本文仅就软件可靠性工程在软件开发过程中的应用谈谈自己的认识。
1.软件可靠性设计的基本概念
1.1 软件及软件故障。软件本质上是一种把一组离散输入变成一组离散输出的工具,它由一组编码语句组成,这些语句的功能基本上是以下功能之一:(1)计算一个表达式并将其结果存储在单元里;(2)
决定下一步要执行哪个语句;(3)进行输入/输出控制。
软件产品与硬件产品一样。软件的可靠性工作也是贯穿于软件的整个寿命周期的。软件的寿命周期,是指从软件任务的提出一直到它完成使命,因陈旧而被废弃为止的整个时间历程,这个寿命周期包括了提出要求/规格说明、设计、实现、检验、维护等五个阶段,前四个阶段为开发期,维护阶段为使用期。
1.2 软件可靠性。关于软件可靠性的定义是什么。较多的人认为软件的可靠性与“概率统计的可靠性”的概念密切相关,软件的可靠性是软件在规定的条件下、规定的时间周期内执行所要求功能的能力。软件的可靠度是软件在规定的条件下、规定的时间内不引起系统故障的概率,该概率是系统输入与系统使用的函数。
2.软件质量的可靠性参数
2.1 系统平均不工作间隔时间(MTBSD或MTBD)。设d为软件正常工作总时间,d为系统由于软件故障而停止工作的次数,则定义TBSD=Tv/(d+1)。式中,TBSD—MTBSD;Tv—软件正常工作总时间(h);d—系统由于软件故障而停止工作的次数。MTBSD反映了系统的稳定性。
2.2 系统不工作次数(一定时期内)。由于软件故障而停止工作,必须由操作者介入再启动才能继续工作的次数。
2.3 可用度A。设Tv为软件正常工作总时间,TD为由于软件故障使系统不工作的时间,则定义A=TV/(TV+TD)。它反映了系统的稳定性,亦可表达为A=TBD/(TBD+TDT)。式中,TBD—MTBD(h),TDT—平均不工
作时间,以下简称MDT(h)。对一般生产用计算机系统,要求A≥99.8%;银行计算机系统,要求A>99.9%。
2.4 MTTR。它反映了出现软件缺陷后采取对策的效率。在一定程度上也反映了软件企业对社会服务的责任心。对于在线系统而言,MTT只要求不超过2天,变差系数应小于1。一般的MTTR也应小于7天,变差系数小于1。
2.5 平均不工作时间(MDT)。即由于软件故障,系统不工作的均值。对在线系统而言。MDT要求不超过10min一般的MDT<>
2.6 初期故障。一般以软件交付使用后的三个月内为初期故障期。初期故障率的大小取决于软件设计水平、检查项日数、软件规模、软件调试彻底与否等因素。
2.7 偶然故障率。一般以软件交付给使用方四个月后为偶然故障期,偶然故障率以每1000h的故障数为单位,它反映了软件处于稳定状态下的质量。一般最少要求偶然故障率不超过1,即每千小时不到1个故障,亦即MTBF超过1000h。
2.8 使用方误用率。使用方不按照软件规范及说明等使用造成的错误叫使用方误用。在总使用次数中,使用方误用次数占的百分率叫使用方误用率。造成使用方误用的原因之一是使用方对说明理解不深,操作不熟练,但也有可能是说明没有讲得很清楚而引起误解。其他的原因还有软件系统的可操作性还应改进、对使用方的使用培训还要更深入等等。 2.9 用户提出补充要求数。这反映软件未能充分满足用户的需要,有时要求是特定用户的特定要求,生产方为了更好地为社
会服务,应该尽力满足他们的要求。
2.10 处理能力。处理能力有各种指标。例如可用每小时平均处理多少文件、每项工作的反应时间多少秒等来表示,根据需要而定。在评价软件及系统的经济效益时需用这项指标。
3.软件可靠性设计方法
从软件可靠性的概念可知,软件的缺陷可以导致错误并造成系统的故障,因此,缺陷是一切错误的根源。为了提高软件的可靠性,最关键的还是力求减少软件中的缺陷。软件的缺陷来自软件寿命周期的各个阶段,因此应想方设法在寿命周期的各个阶段减少缺陷。缺陷在一定的环境条件下暴露,导致系统运行中出现错误。软件的错误概括地说可能由规范(要求/规格说明)、软件系统设计及编码过程产生。
3.1 要求/规格说明。只要在规格说明与用户要求说明之间存在误差,就会产生规范错误。
规范它不仅规定程序的要求,还规定所用的结构、研制及试验中需要的程序试验要求和文件,以及程序语言、输入和输出的基本要求。通过对这些方面作出适当的规定,就可以建立使产生错误的可能性最小、并保证错误能被发现和改正的程序生成的结构。
这种说明书是软件设计人员和用户间相互了解的基础,是软件设计人员进行程序设计、调试的基础和评价软件的依据。要求/规格说明书应具有以下性质:
(1)可测性:生产出来的软件产品应能根据要求/规格说明书的内容进行测试。(2)完整性:对软件要求的描述要完整无缺。(3)明确性:
对软件的要求必须是明确的,不存在语义上的支义性。(4)一致性:要求说明书中的概念与规范化。(5)弹性:当软件的工作环境发生变化时,其功能说明也相应地扩充或压缩。
3.2 软件设计。软件系统是根据要求/规格说明(规范)设计的,通过设计将确定程序结构、测试点及限制等。为设计出可靠的软件,需要在考虑诸如机型、资源、语言、模型及数据结构等实际问题的基础上,采取一些有效的设计方法。
3.2.1 “自顶向下设计”法。这种设计方法是处理分级问题最有效的设计技术。它是以一个系统功能的最抽象描述开始作为最高层次;从它出发,设计一系列较详细的子系统。由这些子系统来完成员高层次的功能;再以每个子系统为基础,设计出一系列更详细的子系统,等等。如此逐次向下作功能分解,直到最低层次的子系统能够比较方便用计算机程序设计语言来实现为止。自顶向下设计方法的价值在于,它在设计的同时,指出了复杂性不同的处理层次,而且各种设计要素之间的关系是比较清楚的。通过这样一种结构化构造途径,有可能在早期就洞察出设计问题,从而避免了不必要地先去考虑较低层次的细节问题。
3.2.2 结构化程序设计。软件结构对软件的可靠性具有重要的意义。结构良好的程序易于编写、检查,便于查错定位、修改和维护。结构化程序设计(也称为模块化程序设计)把程序要求分成若干独立的、更小的程序要求或模块化的功能要求,分别提出各自的要求/规格说明,并注明是如何与程序中的其他部分接口,还必须指出所有的输
入与输出,以及测试要求。对每一个更小的程序和模块,可分别编程和测试,使得模块间高度分离。
3.2.3 容错设计。对软件错误所引起的后果特别严重的情况,如飞机的飞行控制系统、空中交通管制系统、核反应堆安全系统等,需采用容错软件。容错设计的途径有:(1)加强软件的健壮性;使程序设计得能够缓解错误的影响,不致造成诸如死锁或崩溃这样的严重后果,并能指出错误源。(2)采用N(>2)版本编程法:即尽可能用不同的算法与编程语言,经不同的班组编制,以提高各软件版本的独立性。这N个软件版本同时在N台计算机上运行,各计算机间能进行高效通信,并作出快速比较,当结果不一致时,按多数表决或预定的策略选择输出。
(3)恢复块法:给需要作容错处理的块(基本块)提供备份块,并附加错误检测和恢复措施。 3.3 软件编码。在软件结构设计的基础上就可以进行编码,编码产生的缺陷是软件错误的主要来源。一般的编码错误是:键入错代码;数值错误(尤其是单位不统一时易出这类错误);丢失代码(如括号);用了被零除这样不定值的表达式等。为了减少编码错误,实现设计与生产分离,首先由高水平的软件工程师完成结构设计,再由程序设计员完成程序的编制是合理的、必要的,并在编码过程中尽早地查出缺陷予以改正。
4.结束语
软件可靠性设计工程是一门虽然得到普遍承认,但还处于不成熟的正在发展确立阶段的新工程学科,任然存在很多问题,需要去探索、研究和解决。
范文三:论文-系统与软件可靠性定义的研究
系统与软件可靠性定义的研究
崔倩楠,袁玉宇
(北京邮电大学软件学院,北京 100876)
摘要:软件可靠性是软件质量的一个重要因素, 但在可靠性理论方面尚缺乏系统而全面的理 论研究, 目前还没有一个相对于当前可靠性研究领域普遍适用的可靠性定义。 基于此种情况, 本文将结合软件工程实践, 从一些已有的可靠性的定义出发并分别对其进行分析, 在此基础 上给出适合当今软件工程领域研究的软件可靠性的改进定义,并对改进定义进行详细的阐 述, 最后从软件可靠性与硬件可靠性的关系和软件可靠性工程过程的角度对改进定义进行深 入分析,以证明改进可靠性定义的正确性。
关键词:软件可靠性 ; 可靠性定义 ; 软件可靠性工程过程 ; 软件工程
中图分类号:TP311.5
Research on the Definition of Reliability in System and Software
Cui Qiannan1, Yuan Yuyu2
(Beijing University of Posts and Telecommunications, Beijing 100876)
Abstract: Software reliability is specified as an important property of the software quality. But it is deficient in systemic and comprehensive research of reliability theory. There is not a definition of reliability which can be generally applied to present reliability research fields. So this paper will be based on introducing and analyzing the existing reliability definitions. And then educe a more exact definition of reliability. Finally, in order to prove the correctness of the new definition, we will analyze the new definition in depth from the angles of the relation between the software reliability and the hardware reliability and the process of software reliability engineering.
Key words: Software reliability; Reliability definition; Process of software reliability engineering; Software engineering
0引言
近十几年来,随着软件工程的快速发展,软件的规模越来越大,系统越来越复杂,功能 也越来越强大。 然而随之产生的系统可靠性问题也日益突出, 软件系统的失效给社会带来的 影响也会越来越大。在软件质量的范畴内,软件可靠性是其中最重要的固有特性 [1],它关心 的问题主要是存在于软件产品中的缺陷, 而软件系统中的缺陷代表了程序设计过程中最大的 成本因素。 这不仅要求我们将软件可靠性问题在软件工程领域中进一步考虑和重视, 而且要 求我们在软件可靠性理论方面的深入探索和研究。 目前国内在软件可靠性领域的研究还存在 空白,为此中国电子技术标准化研究所申请了《系统与软件 XX 性》系列标准,其中包括系 统与软件可靠性。 对软件可靠性进行研究的首要问题就是明确它的定义, 本文的目的就是给 出一个配合该国家标准研究的可靠性的定义。
基于此种情况, 本文将从一些已有的可靠性的定义出发并分别对其进行分析, 在此基础 上给出适合当今软件工程领域研究的软件可靠性的改进定义, 并对改进的可靠性定义进行详 细的阐述, 最后从软件可靠性与硬件可靠性的关系和软件可靠性工程过程的角度对改进定义 进行深入分析,以证明改进可靠性定义的正确性。
作者简介:崔倩楠(1985-08-14),女,北京邮电大学计算机科学与技术专业研究生,主要研究方向软件测 试 . E-mail: kristy6282004@yahoo.com.cn
1现有软件可靠性的定义及其分析
1.1软件可靠性研究背景
一个工程应用学科的发展, 必然伴随着标准化的进程。 该工程应用学科标准内容的准确 性、概括性、实用性在一定程度上标志着该学科的发展程度。因此,标准化的程度也是该应 用学科发展成熟度的重要因素。软件可靠性的标准化,早在 80年代中期就已起步了。国际 上从事这项工作的,主要是国际标准化组织(ISO )及国际电工委员会(IEC )。目前在我 国 获 得 广 泛 认 可 的 主 要 标 准 包 括 :ISO 9126 软 件 工 程 -产 品 质 量 系 列 标 准 , GB/T11457-1995— 软件工程术语,以及最新发布的 ISO CD3 25010 系统和软件工程 -软件产 品质量需求和评估系列标准。
1.2各可靠性定义的分析
1.2.1GB/T 11457中软件可靠性定义的分析
软件可靠性是描述和评价软件质量属性的一个特征量。 它表明了一个软件系统按照用户 的要求和设计的目标, 执行其功能的正确程度。 关于软件可靠性的确切含义, 学术界有过长 期的争论。曾经有人否认软件具有可靠性属性,把软件可靠性说成是科学家寻求的一种 “ 神 圣梦想 ” ,也有人认为软件的正确性就是可靠性。现在仍然保持这种偏颇观点的认识已十分 罕见。 还有一些软件工程专家, 认为软件具有与硬件不同的性质, 不宜将硬件可靠性的定义 引申到软件领域。经过长期的争论和研究, 1983年美国 IEEE 计算机学会对 “ 软件可靠性 ” 正式做出定义, GB/T-11457采用了这个定义:
a) 在规定的条件下,在规定的时间内软件不引起失效的概率。
该概率是系统输入和系统使用的函数, 也是软件中存在的缺陷的函数。 系统输入将确定 是否遇到已存在的缺陷 (如果有缺陷存在的话 ) 。
b) 在规定的时间周期内所述条件下程序执行所规定功能的能力 [2]。
其中 a 是一个定量的定义, 而 b 则是一个定性的定义。 软件可靠性的定义虽与硬件可靠 性定义貌似雷同, 却需要给定义中的要素赋予新的含义。 下面着重分析定义中所述的规定的 时间、规定的条件、规定功能及失效的概念。
(1)规定的条件
在软件可靠性定义中,规定的条件是指:
软件运行的软、硬件环境:软件环境包括运行的操作系统、应用程序、编译系统、数据 库系统等;硬件环境包括计算机的 CPU , CACHE , MEMORY , I/O等。
软件运行剖面:不严格的说, 是指软件运行的输入空间及其概率分布。 软件的输入空间 是指所有可能的输入值构成的空间。按照欧空局标准的定义,软件的运行剖面是指 “ 对系统 使用条件的定义。 即系统的输入值用其按时间的分布或按它们在可能输入范围内的出现的分 布来定义 ” 。
(2)规定的时间
规定的时间是指软件的工作周期。软件可靠性只是体现在其运行阶段,所以将 “ 运行时 间 ” 作为 “ 规定的时间 ” 的度量。 “ 运行时间 ” 指软件系统一旦投入运行后的计算机运行挂起 (开 启但空闲 ) 和工作的累计时间,不包括停机占用的时间。常用的时间概念有:软件执行时间、 日历时间和计算机使用时间。
http://www.paper.edu.cn 中国 科技论文在线
(3)完成规定的功能
完成的功能是指软件不出现失效。 由于要完成的任务不同, 软件的运行剖面会有所区别,
则调用的子模块就不同, 其可靠性也就可能不同。 所以要准确度量软件系统的可靠性必须首
先明确它的任务和功能。但是即使完成了规定的功能而对软件产品原有的其他性质产生影
响,那也将直接影响软件产品的可靠性。
(4)失效的含义
任何软件开发出来都要履行某特定的功能。 这些功能通常在 “ 软件需求规格说明书 ” 中得
到充分而详尽的阐述。 软件失效是指程序运行中出现偏离预期正常状态的事件。 即偏离了 “ 软
件需求规格说明书 ” 的要求。不引起系统失效是指软件可靠性不仅要有正确性,还应包含健
壮性。所谓健壮性是指万一硬件发生故障或输入数据不合理等意外条件时系统能做适当工
作。
综上所述,从对 “ 规定的功能 ” 及 “ 失效 ” 的分析可以得出, “ 软件的失效 ” 即没有完成 “ 规
定的功能 ” , 故 1995年我国国标这个可靠性定义两个方面的唯一区别就在于强调软件可靠性
具有定性的和定量的两层含义。 但是仅仅用 “ 执行规定功能 ” 就来表征软件的可靠性显然是不
够全面的, 应强调在不影响软件的其他性质的同时软件产品能执行要求的功能来表征软件的
高可靠性。
1.2.2ISO 9126 中软件可靠性定义的分析
根据国际标准 ISO 9126 软件工程 -产品质量 -第一部分质量模型, 软件可靠性的定义为:
在指定条件下使用时,软件产品维持规定的性能级别的能力 [3]。
注:1、软件不会损耗或老化。可靠性的种种局限是由于需求、设计和实现中的故障所致。由这些故
障引起的失效取决于软件产品的使用方式和所选择的程序选项,而不是经时时间;
2、在 ISO/IEC 2382-14:1997中可靠性的定义是 “ 功能单元完成所需功能的能力 ……” 。在本部分
中,功能性仅是软件质量诸特性之一。因此,可靠性的定义已被扩展为 “ 维持规定的性能级
别 ……” ,而不是 “…… 完成所需功能 ” 。
该定义直接把软件可靠性定义成了一种能力, 是一种定性的描述, 而去掉了 GB/T 11457
中对可靠性定量内容的描述。下面来对定义中的几个重要概念进行深入分析。
(1)指定条件
在该软件可靠性定义中, 指定条件是指:规定的时间、 软件运行的软硬件环境及软件运
行剖面三方面的内容。
此处只指明 “ 在指定条件下使用 ” 而没有指明 “ 在规定的时间内 ” , 而实际上时间对于软件
可靠性来说具有重要的作用。 因为软件可靠性只是体现在其运行阶段, 如果没有运行时间的
限制那所有软件最终都会出现失效、 都不能保证其可靠性。 那样的话软件的可靠性将变得不
可描述其优劣。故该定义中的 “ 指定条件 ” 应理解为包括 “ 规定的时间 ” 这一重要条件。
另外, 理解 “ 指定条件 ” 时仍然应包括软件运行的软、 硬件环境及软件运行剖面两方面的
内容。对于这两方面的具体内容上文已有详细分析,这里不再赘述。
(2)性能级别
对于软件产品的 “ 性能级别 ” , ISO 9126-1中给出的定义是:要求被满足的程度,它由一
组质量特性的特定值来表示。
“ 性能 ” 的定义为机械、器材、物品等所具有的性质和功能。由定义可看出 “ 性能 ” 包括所
描述对象的性质和功能两方面的内容,用 “ 性能 ” 来定义可靠性比前一定义中的 “ 功能 ” 更全
面。
综上所述,在 ISO 9126.1对可靠性的定义中去除了对软件可靠性定量的描述,只保留 了对其定性的描述,这样的描述是不够全面的。另外,该定义中用 “ 指定条件 ” 囊括了 “ 规定 的时间 ” 这一重要概念, 使其成为一个隐含条件, 而实际上时间条件应该作为一个前提条件。 个人认为这种概括方式使定义表述不够清晰明确,没有突出强调时间这一重要条件。最后, 该定义用 “ 维持规定的性能级别 ” 取代了 “ 执行所规定功能 ” ,扩大了可靠性的范围,可理解为 在不影响该软件产品原有性质的基础上实现软件需求规格说明书中的软件功能。 这样使软件 可靠性的定义更全面、准确。
1.2.3ISO FCD 25010中软件可靠性定义的分析
根据软件质量最新的国际标准 ISO FCD 25010系统及软件工程 -软件产品质量需求及评 估 -第一部分质量模型,软件可靠性的定义为:
在规定的时间周期内,规定条件下,一个系统或组件执行所需求的功能的程度 [4]。 与以上分析的两个软件可靠性定义相比较, 该定义的变动之处主要是将 GB/T 11457 及 ISO 9126.1中的 “ 能力 ” 在这里被表述为一种 “ 程度 ” 。
该定义中摒弃了之前定义所一直使用的 “ 能力 ” 一词而使用了 “ 程度 ” 。 “ 程度 ” 一词在保留 了 “ 能力 ” 所表达出的可靠性定性的概念外, 又隐含了部分定量的含义。 使可靠性的定义更加 完善。
1.2.4其他软件可靠性的定义
(1)软件可靠性工程的创始人之一 John D. Musa在其著作《软件可靠性工程》一书中 给出的软件可靠性定义为:
可靠性是指在规定时间周期内,软件无失效工作的概率 [5]。
该定义是可靠性的一个早期的定义, Musa 认为软件可靠性是一种概率。定义中没有指 出测试软件可靠性的前提条件, 只是给出了 “ 在规定时间周期内 ” 。 并且在该定义中也没有明 确给出 “ 无失效工作 ” 中 “ 工作 ” 的具体含义。故该定义是不够清晰、明确的。
(2)何国伟在《软件可靠性》一书中对软件可靠性给出的定义为:
在规定环境下, 在规定时间内, 软件不引起系统失效的概率。 或在规定时间区间和规定 条件下,软件实现所要求的功能的能力 [6]。
该定义与 GB/T 11457中的可靠性定义很相似,都是强调软件可靠性具有定性的和定量 的两层含义,即可靠性既可以用 “ 概率 ” 来描述,也是一种实现要求功能的 “ 能力 ” 的体现。故 两定义无明显区别,这里不再重复对该定义进行深入分析。
2改进的软件可靠性定义
2.1改进的可靠性定义的提出
基于 2.2节中对以上三个广为认可的国际 /国家标准的分析比较,以及我们对软件可靠 性的理解,现对软件可靠性定义进行了改进,给出以下定义:
规定的时间内,在规定的条件下使用时,软件产品维持规定的性能级别的程度。
注:1、这里的 “ 规定的时间 ” 是指软件的工作周期;
2、这里的 “ 规定的条件 ” 是指软件运行的软、硬件环境及软件运行剖面条件;
2.2改进的可靠性定义的详述
对于新的可靠性定义给出以下几方面的说明:
(1)规定的条件及规定的时间
对于这两方面内容的理解在分析 GB/T 11457-1995中的可靠性定义时已给出详细说明, 这里不再赘述。 简言之, 规定的条件是指软件运行的软、 硬件环境及软件运行剖面两方面的 内容。规定的时间是指软件的工作周期。需强调的是,规定时间一般采用 “ 运行时间 ” 作为时 间的尺度。 规定的时间既是指广义时间。 也是因对象不同而用诸如次数、 周期等变量来表征 时间。
(2)性能级别
此处可靠性定义中用 “ 性能级别 ” 代替了 GB/T 11457及 ISO 25010中所使用的 “ 规定的功 能 ” 。对于 “ 性能级别 ” 前文已略有分析,作为新的可靠性定义的一个重要组成要素,此处对 性能级别进行更深入的分析,以阐明为何采用其来定义软件可靠性。对于软件产品的 “ 性能 级别 ” , ISO 9126-1中给出的定义是:要求被满足的程度,它由一组质量特性的特定值来表 示。首先来说明为何用 “ 性能 ” 来替代之前定义中出现的 “ 功能 ” 一词。
“ 性能 ” 的定义为机械、器材、物品等所具有的性质和功能。由定义可知,性能包括两方 面的内容, 即一个产品所具有的性质和功能这两方面的内容。 可见用 “ 性能 ” 来定义可靠性比 “ 功能 ” 更全面。 放在具体的定义中可理解为在不影响该软件产品原有性质的基础上实现软件 需求规格说明书中的软件功能。 比如软件产品的容错性、 易恢复性, 这些都是产品的性能指 标而非功能指标, 一个软件产品即使实现了需求说明书上的全部功能, 但它的容错性、 易恢 复性很差,那该产品的可靠性也是不高的。因此,可靠性定义中采用 “ 性能 ” 比 “ 功能 ” 更为准 确。
接下来说明为何用 “ 性能级别 ” 一词。 软件可靠性是软件系统固有特性之一, 它表明了一 个软件系统按照用户的要求和设计的目标, 执行其功能的正确程度。 软件可靠性与软件缺陷 有关,也与系统输入和系统使用有关。理论上说,可靠的软件系统应该是正确、完整、一致 和健壮的。 但是实际上任何软件都不可能达到百分之百的正确, 故用 “ 级别 ” 来表征软件产品 维持规定性能的程度。
因此, 我们在新的定义中可把 “ 可靠性 ” 广义地理解为 “ 可靠性能 ” , 以此表征一个软件产 品所具有的与可靠性相关的性质和功能。
(3)程度
对 “ 程度 ” 一词的理解介乎前文所分析的 “ 能力 ” 和 “ 概率 ” 之间(见 GB/T 11457及 ISO 9126.1中可靠性定义),如采用 “ 能力 ” 的可靠性定义描述一个软件产品时可以用能力 “ 好 ” 、 “ 坏 ” 来定性地形容; 采用 “ 概率 ” 的可靠性定义描述一个软件产品时可定量地给出这个概率的 具体数值。而采用 “ 程度 ” ,则既可以用程度 “ 高 ” 、 “ 低 ” 来定性地描述软件产品可靠性,又可 以定量地给出这个 “ 程度 ” 的具体量化值。可见 “ 程度 ” 兼具 “ 能力 ” 与 “ 概率 ” 两层含义。故使用 “ 程度 ” 一词使可靠性的定义更加完善。
3改进的软件可靠性定义的分析
本章主要通过研究软件可靠性与硬件可靠性的关系来明确软件可靠性的研究内容, 以及 区别软件可靠性与硬件可靠性, 从而使得可靠性的本质更加突出, 并体现在改进的软件可靠 性定义中。 而通过引入可靠性的软件工程过程, 可以从整个软件工程过程角度帮助我们理解 软件可靠性。
3.1软件可靠性与硬件可靠性的关系
系统是由系统软件与硬件共同构成的, 故系统的可靠性是由系统软件可靠性与硬件可靠 性共同决定的。 硬件可靠性的研究及技术发展已较为成熟, 而软件可靠性是近三十年才兴起 的研究方向, 所以很多软件可靠性的研究内容都是基于硬件可靠性的研究的, 二者之间既有 区别又有联系。
(1) 硬件可靠性定义
根据国家标准的规定, 产品的可靠性是指:产品在规定的条件下、 在规定的时间内完成 规定的功能的能力。
(2) 两者的区别
软件作为一种产品与硬件有许多不同, 但从可靠性的角度来看, 它们间的主要不同点在 于:软件是逻辑实体,始终不会自然变化,只是其载体可变;其不可靠问题基本是由于开发 过程中的人为差错所造成的缺陷而引起的;程序是指令序列,即使每条指令都正确, 但由 于在执行时其逻辑组合状态千变万化, 不一定完全正确; 系统数学模型是离散型的, 其输入 在合理范围内的微小变化可能引起输出的巨大变化, 故障的形成无物理原因, 失效的发展取 决于输入值和运行状态的组合, 无前兆。 而硬件是物理实体, 每件同规格产品的质量特性之 间有散布, 会随时间和使用而老化磨损以至失效; 其不可靠问题不只是设计问题, 在生产和 使用过程中也会产生新的故障; 硬件失效总是由其零部件或其结合的故障所引起的; 系统在 正常工作条件下其行为是渐变的,故障的形成和失效的发生一般都有物理原因,有前兆。 总的说来,软件可靠性与硬件可靠性的本质差别是智力失效与物理失效之间的差别。 (3) 两者的联系
从宏观上讲, 软件可靠性和硬件可靠性是没有严格区别的, 因为软件和硬件统一组成系 统, 系统的可靠性就包括软件可靠性和硬件可靠性, 对此, 可靠性的研究就直接转入系统可 靠性的研究,使用统一的定义。
从微观上讲,任何一个软件产品需要在硬件上运行,其可靠性应考虑硬件可靠性因素。 同样,任何一个硬件产品也包含软件因素,例如产品的设计,自动控制程序等。从这种层面 上讲没有绝对的软件和绝对的硬件,因此研究方法是相同的。
可见软件可靠性与硬件可靠性是相互作用相互联系的, 软件可靠性的研究可以借助于现 有成熟的硬件可靠性研究成果, 这其中也包括软件可靠性的定义, 但软件可靠性又不等同于 硬件可靠性。 因此软件可靠性的定义应当不仅仅只是对硬件可靠性定义的简单重复, 因为评 价软件的可靠性不仅包括度量软件实现所需功能的能力, 还应包括在完成功能的同时软件性 能的表现。所以软件可靠性定义中应该包括对软件维持规定性能级别的定义。
3.2软件可靠性工程过程
软件可靠性工程不仅仅是用数理统计的方法来详细说明设计、 预计、 估计和评价基于软 件的系统可靠性,还包括软件可靠性的需求、分析、设计、实施、售后及维护、工程管理活 动。因此,我们可以定义软件可靠性工程为:获得软件可靠性而进行的一系列开发、维护软 件产品的活动。 其内涵涉及以下四方面活动和有关技术 :
1. 软件可靠性分析:进行软件的可靠性需求分析、指标分配、故障树分析、失效模式和 影响分析以及软件开发过程中有关软件可靠性的特性分析等,从而确定软件可靠性目标; 2. 软件可靠性设计和实现 :进行防错设计、容错设计、纠错设计、故障恢复设计和软件 可靠性增长等;
3. 软件可靠性测量、测试和评价:在软件生存周期各阶段进行有关软件可靠性设计、制 造和管理方面的属性测量, 进行软件可靠性测试、 软件可靠性预计、 软件可靠性评估和软件 可靠性验证等;
4. 软件可靠性管理:确定影响软件可靠性的因素,指定必要的设计和实现准则,以及对 软件开发各阶段软件可靠性相关过程和产品的要求 . 依据 3中所述有关测量数据和分析结果 控制与改进开发过程,进行风险管理 (不仅考虑安全性等技术风险,而且考虑进度和经费方 面的风险 ) ,改进费用效益关系,改进开发过程,对采购或重用的软件进行可靠性管理等。 图 1为软件可靠性工程过程概图。
图 1 软件可靠性工程过程概图
Fig. 1 Software Reliability Engineering Process Figure
4结论
在硬件技术迅速发展的前提下, 以及在软件危机的刺激和推动下, 软件工程学得以建立 和发展。 软件可靠性问题是软件工程学得以建立的一个强大推动力, 也是软件工程界力图解 决的一个重要目标。 本文通过对可靠性的几个权威定义的综合分析最后给出了改进后的软件 可靠性定义。目的是使软件可靠性的定义更加严谨、清晰、明确,以方便后续对软件可靠性 测试方法、度量方法的深入研究。
[参考文献 ] (References)
[1]刘云,赵玮 . 软件可靠性研究与进展[J ]. 微机发展, 2003
[2]GB/T 11457-1995信息技术 -软件工程术语 [S]. 1995
[3]ISO/IEC 9126 Software Engineering - Product Quality - Part1 :Quality Model. 2002
[4]ISO/IEC FCD 25010 Systems and software engineering - Software product Quality
Requirements and Evaluation (SQuaRE) - Quality models for software product quality and system quality in use . 2009
[5] John D. Musa. Software Reliability Engineering[M]. McGraw-Hill, 2003
[6]何国伟 . 《软件可靠性》 [M]. 北京:国防工业出版社, 1995
范文四:计算机软件论文浅探软件可靠性工程的应用
浅探软件可靠性工程的应用
摘要:本文就武器装备软件开发的现状和中存在的问题,介绍了软件可靠性工程的发展及其研究的内容,对软件可靠性工程如何在软件开发中应用进行了重点说明,并提供了成功应用软件可靠性工程的典型案例,指出软件可靠性工程研究的必要性。
关键词: 软件 可靠性工程
随着科学技术的不断进步,计算机技术被越来越多地应用到武器系统中。计算机软件的复杂程度随着功能的增强,因而系统的可靠性也越来越与软件直接相关。例如AFTI/F-16飞机首航因软件问题推迟1年,事先设计的先进程序wu法使用;海湾战争中F/A–18飞机飞行控制系统计算机500次故障中,软件故障次数超过硬件。软件可靠性成为我们关注的1个问题,本文仅就软件可靠性工程在软件开发过程中的应用谈谈自己的认识。
1、软件可靠性工程的基本概念及发展
1.1什么是软件可靠性工程
软件可靠性工程简单地说就是对基于软件产品的可靠性进行预测、建模、估计、度量及管理,软件可靠性工程贯穿于软件开发的整个过程。
1.2软件可靠性工程的发展历程
软件可靠性问题获得重视是2十世纪60年代末期,那时软件危机被广泛讨论,软件不可靠是造成软件危机的重要原因之1。1972年正式提出Jelinski—Moranda模型,标志着软件可靠性系统研究的开始。在70年代(软件可靠性的理论研究获得很大发展,1方面提出了数十种软件可靠性模型,另1方面是软件容错的研究。在80年代,软件可靠性从研究阶段逐渐迈向工程化。进入90年代后,软件可靠性逐渐成为软件开发考虑的主要因素之1,软件可靠性工程在软件工程领域逐渐取得相对独立的地位,成为1个生机勃勃的分支。
1.3软件可靠性工程研究的基本问题
软件可靠性工程的主要目标是保证和提高软件可靠性。为达到这1目标,首先要弄清软件为什么会出现故障或失效。只有这样,才有可能在软件开发过程中减少导致软件故障或失效的隐患,且1旦出现软件故障或失效,有可能采取有效措施加以清除。但是软件是开发出来的,满足可靠性要求的软件也是开发出来的,因此,软件可靠性工程的核心问题是如何开发可靠的软件。而有了软件,又该如何检验其是否满足可靠性要求?这是软件可靠性工程的又1个问题。
2、软件可靠性工程在软件开发中的应用
2.1项目开发计划及需求分析阶段
在项目开发计划阶段需根据产品具体要求作出软件项目开发计划,明确项目的目的、条件、运行环境、软件产品要求、人员分工和职责及进度,并估计产品的可靠性。需求分析阶段要根据项目开发计划阶段确定软件开发的主要任务、次要任务和其它任务,并设计软件程序的基本流程、软件结构、模块的定义和输入输出数据、接口和数据结构等同时应对项目开发计划阶段作出的可靠性预计进1步细化形成可靠性需求,建立具体的可靠性指标。这个阶段的可靠性工作1般应如下安排:
?确定功能概图
所谓功能概图就是产品的各种功能及其在不同环境条件下使用的概率。为确立功能概图必须定义产品的功能,功能定义不但包括要完成的任务,还包括影响处理的环境因素。
?对失效进行定义和分类
这里应从用户的角度来定义产品失效,将软件和硬件失效及操作程序上的失效区分开,并将其按严重程度进行分类。
?确定用户的可靠性要求
在这个阶段应由系统设计师、软件设计师、可靠性师、测试人员及用户方代表可靠性评估小组共同根据用户提出的系统可靠性来确定软件的可靠性。
?进行平衡关系研究
通常应考虑可靠性和功能之间的关系以及可靠性、开发费用和开发周期之间的关系。1般来说,增加功能会导致可靠性降低,可靠性提高的程度1般与测试加强程度相对应,这意味着时间和费用的增加。
?建立可靠性指标
在这个阶段应对每种失效分别建立可靠性指标。通常,首先建立系统可靠性指标,然后在硬件和软件间分配。影响建立可靠性指标的因素主要有:合同或有关标准中明确规定的可靠性指标,相似产品的可靠性指标,产品的质量保证,使用已有模块的可靠性,技术能力和局限(如容错技术的使用)等。
2.2软件设计和功能实现阶段
软件设计是对上1阶段定义的每1个功能模块逐步细化,确立系统体系结构,形成若干可编程的模块。说明硬件和软件模块之间的接口及它们与外部环境的接口,详细描述各模块的输入、处理过程及输出。功能实现是根据设计方案进行软件编程。该阶段主要应做:
?在模块间分配可靠性指标
定义系统体系结构时,应将系统分解成模块同时保证总体可靠性指标。进行系统分解是应考虑以下因素:系统的物理特性、以前收集的数据的特性及收集数据需要的工作量等。确定每个模块的可靠性要求时,首先进行可靠性分配,然后根据试分配值计算系统的可靠性。这样及时调整,使各模块开发周期、难度和风险大致相当,系统的开发费用也才能降至最低。
?按可靠性指标进行设计
目前,可靠性设计有以下几种方法:设计恢复策略、使用冗余软件单元、鉴别高风险区域。设计恢复策略是指软件只须重新启动即可消除失效的设计,设计恢复应能保存修复可能破坏的数据,应具备确定失效发生时间和阻止继续运行的机制,以减少程序数据的破坏。使用冗余软件单元时是采用与原软件单元不同的冗余软件单元来提高可靠性。鉴别高风险区域采用FMEA(失效类型与后果分析)和FTA(错误树分析)的方法来进行可靠性分析。
?根据功能概图集中资源配置
根据功能概图把人力、物力等资源用到用户认为最重要的地方。
?控制错误的引入和传播
错误是引起软件失效的根本原因,所以控制每个开发步骤中引入的错误数目及未被察觉的而传入下1步的错误数目,对于控制产品的可靠性是非常重要的。错误控制受多种因素影响,其中主要有:
a.构造模块化系统;
b.进行软件重用;
c.进行单元和集成测试,阻止错误向下1开发步骤传播;
d.进行检查和复核;
e.控制改动。
?度量现成软件的可靠性
如果在产品中使用现成的未在本产品中开发或测试过的软件,必须对其进行可靠性证明,证明其可靠性指标在可以接受的范围内方可采用。2.3系统测试和现场试运行阶段
系统测试和现场运行以确认产品的软件要求是否得到满足,用户是否可以实际应用。系统测试阶段是开发过程阶段的最后阶段,如果措施得当,可以在产品首次使用前进1步提高可靠性。现场试运行阶段在用户环境中验证产品的各种说明及系统测试所得的可靠性指标。这
个阶段的工作有以下工作:
?确定操作概图
操作概图是指实现系统功能的操作及其概率的集合,1个操作可以是特定环境下执行的1条命令,或同时附有限定范围内的参数或输入变量集。确定操作概图是测试计划的1个重要部分,1般在系统测试阶段之前由测试计划人员,在系统设计师和软件设计人员的协助下完成。
?进行可靠性增强测试
在系统测试阶段需进行可靠性增强测试。在可靠性增强测试中,系统测试员根据操作概图描述各种操作的现场发生概率,按比例的执行测试用例,通过模仿用户的应用方式可靠性增强测试,易于发现令用户最不满意的失效,能够反映出用户使用时的可靠性感受。
?根据测试进展并证明可靠性指标是否达到要求
在可靠性增强测试中,要收集失效数据,利用已有或自行设计并经验证的可靠性工具跟踪测试进展及规划必须的额外测试,根据进展情况在系统测试进行中可以对资源和进度安排随时做必要的调整。
?现场可靠性评估
系统测试阶段完成后,转入现场试运行阶段。在试运行中,从现场收集失效数据,利用此数据和软件工具评估现场可靠性,然后与系统测试结束后测得的可靠性相比较,同时对可靠性差异的产生原因进行分析。
2.4维护阶段
维护阶段是在产品用户使用过程中改正软件暴露出来的与失效有关的错误。在这个阶段监视产品现场运行的可靠性,并和预定指标及用户的满意程度进行对照比较,以便提高后继版本的可靠性,改进软件开发过程中的质量。此阶段主要做的工作是:
?用可靠性模型规划产品交付使用之后的人员需求,如:用户恢复失效操作的人员,承制方处理用户报告的失效的人员,承制方处理与用户报告的失效有关的错误的软件开发人员。
?监视现场可靠性是否达到预期指标,根据其间的差距采取相应的措施。同时还应跟踪用户是否满意,根据不满意的情况,进行必要的现场支持服务及产品改动。
?当加入新的功能时,通过监视可靠性,消除由此带来的失效强度增加。
?分析软件交付使用后的失效产生原因,指导工程的改进,降低引入类似错误的可能性。
3、软件可靠性工程成功应用的实例
美国AT&T公司的国际DEFINITYR程控交换机部在系统软件开发过程中应用了软件可靠性工程,相对于以前发行的主要软件版本,产品的质量提高是惊人的:
?用户反映的问题下降了10倍;
?项目维护费用下降了10倍;
?系统测试件的间隔缩短了2倍;
?引入新产品的间隔缩短了30%。
而且,在投入运行的前两年,从未发生严重影响业务的机器中断,客户满意程度大为提高。具体分析原因,有以下两点:
?把可靠性作为确定是否发行的标准,可避免用户在使用中反映过多问题和进行相应的维护工作。
?采用―操作概图驱动‖的测试方法,提高了测试效率;20%的操作覆盖了95%的应用,20%的错误导致了95%的实效;先测试20%的使用最频繁的操作可以加速可靠性的提高。
4、结束语
软件的可靠性中正越来越引起软件研发部门的重视,但因为这是1门新兴的学科,对于提高软件质量,国内外还未能从软件可靠性工程的角度总结出1套行之有效的管理方法。
软件可靠性工程是1项涉及面很广的系统工程,应加强这项技术的研究力度。尤其要结合具体项目进行课题研究,使软件的开发过程同时也是软件可靠性工程的实施过程。使自发的可靠性工作成为有计划、有组织和有目标的研究工作。相信经过不断的探索和实践,软件可靠性工程会象硬件可靠性工程那样走向成熟,它的应用将对提高我国软件开发的可靠性起到积极的推动作用。
毕业论文网 www.lwkoo.cn 论文
范文五:【软件工程论文】通过软件测试提高软件可靠性的方法分析
通过软件测试提高软件可靠性的方法分析
作者简介:司艳艳 (1979-),女,中国空空导弹研究院工程师,研究方向为软件测试。
0引言
随着计算机应用范围的日益广泛,软件系统作为计算机系统的神经中枢,也早已延伸到了产品中的各个方面。为了能够适应各种复杂的背景环境和完成复杂的任务,近年来软件系统的应用规模、复杂度以及重要性程度均呈急剧上升趋势。
随着软件应用范围和规模的不断扩大,软件设计的复杂程度不断提高,软件开发中出现错误或缺陷的机会越来越多。同时,人们对软件质量的要求也越来越高,要保证产品的质量并确保其有效性,提高软件的质量与可靠性是最关键的一个途径,这已成为航空、航天等领域的共识。此时,作为软件质量保证手段之一的软件测试越来越受到重视,对其要求也越来越高。因此,要根据软件故障产生和发展的规律,检测出软件存在的故障和可能存在的隐患,控制和减少软件故障所造成的影响,构建一个可以支撑高质量、高可靠性软件研制的技术保障体系,从而全面提高软件系统在产品关键应用中的可靠性和可用性。
1工程实例
1.1测试过程
笔者所在院系的软件产品通常要经历4个阶段的开发研制,在软件开发的每个阶段,软件内部测试都要进行以下几个方面的测试工作:静态分析、代码审查、单元测试、部件测试、配置项测试。
(1)静态分析。软件静态分析主要是通过专业软件静态分析工具对程序结构、数据结构、代码品质等在非运行状态下进行分析,提取软件大量的静态内部信息,为代码审查及动态测试提供辅助参考信息,依据现有的度量模型定量评价软件的内在质量[1]。静态分析中需关注的指标有圈复杂度、基本复杂度、扇出数和模块行数。
(2)代码审查。代码审查主要是检查代码和设计的一致性;检查代码执行标准的情况;检查代码的可读性;检查代码逻辑表达的正确性和完整性;检查代码结构的合理性等。
(3)单元测试。单元测试的依据是软件详细设计说明文档,单元测试对模块内所有的控制路径设计测试用例,针对被测单元生成驱动模块,将被测单元需调用的其它函数打桩,模拟实现被测单元的接口,执行插桩后的测试用例,得到最终的测试结果。单元测试的目的
是检查每个软件模块能否正确地实现设计说明中的功能、性能、接口和其它设计约束等要求,并发现模块内可能存在的各种错误。
(4)部件测试。部件测试中,根据测试计划和被测试软件的设计文档,采用自顶向下或自底向上的模式把各个模块逐步装配成所需的功能模块并进行测试,部件测试对部件内所有的接口设计测试用例,针对被测部件生成驱动,将被测部件需调用的函数真实调用,实现被测单元的真实接口,执行测试用例,得到最终的测试结果。部件测试的目的是检验软件单元和软件部件之间的接口关系,并验证软件部件是否符合设计要求。 思想汇报 /sixianghuibao/
(5)配置项测试。软件配置项是为独立的配置管理而设计的并且能满足最终用户功能的一组软件。在这种测试中,首先根据测试计划和被测试软件的设计文档,细化分解软件需求,形成测试需求,然后再针对每一个测试需求,采用功能分解法、边界值分析法、错误猜测法、程序插桩法、等价类划分法等方法逐一设计测试用例,最后在实际测试环境中运行测试用例并取得测试结果,并将实际结果与预期结果进行比较分析,根据一致性原则判定测试用例是否通过。软件配置项测试的目的是检验软件配置项与软件需求规格说明的一致性。
1.2问题现象
某产品软件到了后期阶段仍在进行频繁更改,通过对其分析,得出软件复杂度高是其存在的主要问题。
GJB/Z 102-97《软件可靠性和安全性设计准则》中对软件编程要求做了如下规定:
(1)除中断情形外,模块应使用单入口和单出口的控制结构。
(2)在设计软件时,将模块在逻辑上构成分层次的结构,在不同的层次上可有不同的扇入扇出数。模块的实际结构形态应满足下述准则:?模块的扇出一般应控制在7以下;?为避免某些程序代码的重复,可适当增加模块的扇入;?应使高层模块有较高的扇出,低层模块有较高的扇入。 开题报告 /html/lunwenzhidao/kaitibaogao/
(3)软件单元的圈复杂度(即McCabe 指数)应小于10。
(4)对于用高级语言实现的软件单元,每个软件单元的源代码最多不应超过200行,一般不超过60行。
据统计,某产品软件某版本总模块数251个,行数超标的模块数有11个,基本复杂度超标的模块数有15个,圈复杂度超标的模块数有87个,占到了总模块数的34.7%,最高的圈复杂度达到了89,超出了规定值的8倍,软件中频繁更改的模块大多是复杂度比较高的模块。
1.3问题分析
在软件经过几个阶段的测试之后,所发现的软件错误和缺陷均已得到了更正,但静态分析结果中的软件圈复杂度、基本复杂度等指标超高的现象一直没有被重视,到了后期软件越来越复杂导致软件潜在风险发生。
软件复杂度是衡量软件质量的一个因素,圈复杂度大说明程序代码质量低且难于测试和维护。经验表明,程序的可能错误和高的圈复杂度有着很大关系,基本复杂度高意味着程序模块的结构不够良好,难以理解和模块化,软件质量的可维护性低。从图1和图2中可以看出,复杂度越高,内部结构越复杂,其潜在的出错可能性也就越大。
2测试指导设计
2.1软件质量的pareto原理
pareto原理[2] 指出,20%的软件模块包含了软件中80%的缺陷,20%的软件改进,需花费80%的适应性维护费用。通过软件测试问题分析可以看出,少部分的高复杂度模块引起了大部分的软件错误,且经常出错的模块改错后还会经常出错。复杂度超标问题修正越 开题报告 /html/lunwenzhidao/kaitibaogao/
晚,修正的难度越大,并且会出现修改了一个错误,却引出了更多错误的情况,或是修改了有缺陷的代码,却又导致先前正确的功能模块出现错误等。因此,必须在发现软件复杂度超标的早期阶段就及时进行修正。
2.2降低软件圈复杂度
2.2.1圈复杂度定义
在软件测试的概念里,圈复杂度用来衡量一个模块判定结构的复杂程度,数量上表现为独立线性路径条数,即合理的预防错误所需测试的最少路径条数。1976年Thomas McCabe提出了圈复杂度(Cyclomatic Complexity)的概念,依据圈复杂度定义了软件的复杂性。1977年Halstead提出了软件科学复杂度度量。文献[3]通过实验证实 开题报告 /html/lunwenzhidao/kaitibaogao/
其他参考文献
thBaker, Sheridan. The Practical Stylist. 6 ed. New York: Harper & Row, 1985.
Flesch, Rudolf. The Art of Plain Talk. New York: Harper & Brothers, 1946.
Gowers, Ernest. The Complete Plain Words. London: Penguin Books, 1987. Snell-Hornby, Mary. Translation Studies: An Integrated Approach. Amsterdam: John
Benjamins, 1987.
Hu, Zhuanglin. [胡壮麟], 语言学教程 [M]. 北京: 北京大学出版社, 2006. Jespersen, Otto. The Philosophy of Grammar. London: Routledge, 1951. Leech, Geoffrey, and Jan Svartvik. A Communicative Grammar of English. London:
Longman, 1974.
Li, Qingxue, and Peng Jianwu. [李庆学、彭建武], 英汉翻译理论与技巧 [M]. 北京: 北京
航空航天大学出版社, 2009.
Lian, Shuneng. [连淑能], 英汉对比研究 [M]. 北京: 高等教育出版社, 1993. Ma, Huijuan, and Miao Ju. [马会娟、苗菊], 当代西方翻译理论选读 [M]. 北京: 外语教学
与研究出版社, 2009.
Newmark, Peter. Approaches to Translation. London: Pergmon P, 1981. Quirk, Randolph, et al. A Grammar of Contemporary English. London: Longman,
1973.
Wang, Li. [王力], 中国语法理论 [M]. 济南: 山东教育出版社, 1984. Xu, Jianping. [许建平], 英汉互译实践与技巧 [M]. 北京: 清华大学出版社, 2003. Yan, Qigang. [严启刚], 英语翻译教程 [M]. 天津: 南开大学出版社, 2001. Zandvoort, R. W. A Handbook of English Grammar. London: Longmans, 1957. Zhong, Shukong. [钟述孔], 英汉翻译手册 [M]. 北京: 商务印书馆, 1983. Zhou, Zhipei. [周志培], 汉英对比与翻译中的转换 [M]. 上海: 华东理工大学出版社, 2003.
转载请注明出处范文大全网 » 剖析计算机软件可靠性设计论文