软件可靠性

软件可靠性是个大问题
闵应骅
如果说计算机体系结构描写了计算机的躯体，那么，软件就是计算机的灵魂。

软件可靠性对可信计算起着举足轻重的作用。

几十年来，硬件技术特别是集成电路技术飞速发展，但软件技术在产品质量、生产力、成本及性能等众多方面都滞后于硬件技术的发展。

随着软件系统规模和复杂性的增加，其开发成本以及由于软件故障而造成的经济损失也正在增加，软件质量问题已成为制约计算机发展的关键因素之一。

软件可靠性是个大问题
不要认为，软件仅仅是一个计算机指令序列，它是为用户提供所需信息处理能力的逻辑上的信息处理设备。

用户需要的是一个满意的软件产品。

但是，不要把软件的产品实现和开发管理混为一谈，或者顾此失彼。

产品实现包括从需求描述、系统设计、系统实现、测试验证到运行维护的整个生命周期。

但是，几十年的经验表明，要实现一个高质量的软件产品，开发管理极其重要。

软件生命周期定义了软件过程的框架和原则，但没有描述软件过程的活动、组织形式、工具和操作规程，以及开发方针和约束。

这些正是当下所谓软件过程技术要研究的。

由于当今的软件，无论是系统软件、中间件或应用软件，都不是一个单位、一个人能够完成的，需要合作和协同，因此，软件产业需要国际标准。

20世纪80年代，卡内基-梅隆大学的软件工程研究所在美国国防部的支持下，提出了评价软件供应商过程能力的能力成熟度模型（CMM）。

一个软件组织的能力成熟度的高低，就看该组织是否能站在比软件项目更高的层次上考察其实施软件开发所使用的软件过程。

能够定义该软件过程者为成熟度三级；如能度量和管理，则达到成熟度四级；如果还能优化该过程，则达到了成熟度五级。

只有在成熟的软件过程管理之下，才能生产出高质量的软件产品。

CMM模型现在还在不断地丰富和改进。

质量和生产率是软件工程的两个核心目标。

CMM等已被公认为软件质量保证方面的事实标准。

它强调软件过程的管理与控制，忽略软件人员个人的主动性和创造性。

所以，进入二十一世纪，在美国成立了Agile联盟，提出了敏捷软件开发方法，以适应那些需求不够确定、软件开发团队不是很大的软件开发项目。

在2000年，美国政府和商业机构公布了CMM水平评估结果。

在第一、二级者超过一半，30%达到第三级，只有17%达到第四、五级。

实际情况可能比这还要糟。

CMM现在正发展成CMMI，以更广泛地评估一个单位创造复杂软件系统的能力。

一个信息技术（IT）项目经理最重要的责任是为各种活动分配资源。

其他责任还有项目计划和评估、控制、组织、合同管理，质量管理，风险管理，通讯和人力资源管理。

项目经理的错误决策也许是今天软件失效的主要原因。

技术管理的失误引起技术差错，但可以纠正，而错误的项目管理决策，例如雇用程序员太少或合同类型的错误，可能引起全盘皆输。

2005年9月IEEE Spectrum 杂志专门报导了用户定制的企业软件及许多软件失效的问题，这些失效导致公司破产、政府和工业界每年损失在美国达到600-750亿美元，这类计划的15-20%不是中途停止，就是完成后很快被抛弃。

问题在那里？为什么软件会失败？没有过程文档或者很糟的过程文档、不可能满足的需求、很差的或者不断更改的规格说明和质量控制。

最大的问题可能在于人，用户无法说清究竟他希望要什么，卖主无法控制，管理者看到这种情况只有另图别路。

我们不妨举几个典型的例子来说明问题。

①最著名的一个软件失效是美国联邦调查局（FBI）的“虚拟案件文件系统”。

这个用户软件希望自动化该局的纸上工作环境，允许下属通过计算机网络分享与调查相关的信息。

但是，
FBI说，开发商开发的软件错误太多，使他们丢弃了这个1.7亿美元的项目。

但是许多人说FBI对此失败也有责任。

当FBI准备花更多的钱来做这个项目时，应该搞清楚现在的问题出在哪里。

研究表明问题还是出在软件开发过程的错误。

②所有的信息技术系统都是很脆弱的。

对一个砖瓦建筑大楼，你需要拆掉几百块置于战略位置的砖才能使一面墙倒塌。

但是，对于一个十万行程序的软件，只要有一两行是坏的，就会出现大问题。

1991年，AT&T电话网络失灵，使一千二百万用户丢失电话服务，完全是由于一行程序中一个字符的键入错误造成的。

③另一个不成熟的IT实践是1997年美国税收服务的40亿现代化项目，美国国税局现在还继续投80亿。

把税收编码翻译成软件编码基本上是不可能的。

税收法规非常复杂，基于常常是含糊的法律条文，并且经常改变。

从信息工程的观点来看，那是一个需求梦想。

如果考虑到来自内部和外部的恶意攻击，问题就更加复杂。

④Sydney Water Corp.是澳洲最大的水提供商，该公司的自动顾客信息和计费系统，经费3,320万美元，在2002年被取消。

根据澳大利亚总审计师的研究，该项目的计划和规范不适当，使许多需求改变，而且要追加经费和推迟项目的计划。

Sydney Water 不得不在花费了3,320万美元之后，中断该项目。

⑤Oxford Health Plans Inc. 在1997年，该公司的自动计费和索赔系统不能处理扩展的商务，导致4亿美元没有收上来，6.5亿美元没有付出去。

而高级经理们对扩展牛津的生意比提供满足目前需求的计费系统更有兴趣。

甚至在问题出现以后，例如服务清单送出几个月以后，经理们并不在意。

当计费系统失效时，公司丢失几千万美元，股票价格一天内由68降到26美元，勾销了34亿企业价值。

股东们告状，最后输掉2.25亿美元。

政府部门对该公司展开调查，最后发现300万违规。

⑥在1986年，London Stock Exchange想设计一个新的股票结算系统，决定研制股票交易自动化系统。

7年后，到1993年，花费了6亿美元，停止了这个系统的开发,不但因为设计太复杂、太麻烦，而且因为管理太差，太幻想化了。

研究表明，虽然出现了许多问题，工期一再推迟，花费很高，但没有人对该项目的真实情况进行调查研究。

⑦2004年10月，一家英国食品上市公司注销了一个5.26亿美元投资的自动贮藏链管理系统项目。

由于该系统失效，公司不得不雇用3000人来把商品从仓库送到各商店的货架上。

这种软件项目失败的例子还有很多。

从这些例子中我们首先看出，发达国家的软件开发费用是很高的，软件失效的损失是惨重的。

就我国目前的情况看，这两点都未做到。

我们常常以为，软件不过是编码，找几个学生就可以做了，不需要很多经费。

所以，一般软件项目经费较少。

另一方面，软件完成以后，公司或机关并不完全依赖该软件，而是锦上添花，即使软件失效也无关大局，因而损失也不大。

俗语说“便宜没好货”，越是便宜的东西，质量就越差。

当然，这种情况正在改变，例如飞机场的管理系统崩溃，飞机就无法进出航空港。

你也就无法期望很廉价地开发一个高可靠的飞机场管理系统。

其次，我们可以看出，软件并不光是指它的编码。

软件是一个过程。

整个生命周期中的任何故障都可能引起软件的失效。

许多信息技术专家相信，软件失效实际出现的次数比人们感知的还要多。

这些故障通常不可预计，它们出现在各个国家、大公司，商业，事业单位和政府机关，造成的纳税人和股东以及投资者的金钱损失一年就是几十亿美元。

随着信息技术无处不在地增长，这个问题将更加严重。

今年，全世界的组织和政府将投资约1万亿元于信息技术，包括硬件、软件和服务。

5-10%将半途而废，其他的将推迟或追加经费，只有少数真正成功。

最大的悲剧在于，人们知道，软件失效总体来说不可避免，许多组织即使看到了危害甚至毁灭该组织的威胁，也不把预防失效看作紧急之事。

这并不是由于技术上的原因，而是由于复杂的商业和社会原因。

近十几年来，即使对于已成功的软件开发项目，软件代码量大增也是影响软件可靠性的大问题。

例如，航天飞机机载系统有近五十万行代码，地面控制和处理系统也有大约三十五万行
代码。

在美国电信业中，电信线路的正常运转需要数百个软件系统的支持，其代码总量超过一亿行。

有两个原因使计算机软件越来越大：一个是人们对计算机需求和依赖的与日俱增，计算机系统的规模和复杂性急剧增加；另一个是软件体系结构越来越复杂。

为了提高软件生产力，软件过程趋于复杂，许多人协同工作，层次化的或网状的体系结构和层次化的开发方法，都使得计算机软件的大小以惊人的速度急剧膨胀。

与此同时，计算机出现故障引起危机的可能性也逐渐增加。

由于计算机硬件技术的进步，元器件可靠性的提高，硬件故障相对显得次要了。

研究表明：由于软件设计故障引起的系统失效与由于硬件设计故障引起的失效之比是10:1。

表1.1给出了某些成熟的计算机系统失效源的统计数据。

系统数据发表年份硬件(%) 软件(%) 维护(%) 操作(%) 环境(%)
AT&T ESS 1978 20 15 - 65 -
Tandem 1985 18 26 25 17 14
Bellcore 1986 26 30 - 44 -
Tandem 1987 19 43 13 13 12
表1 计算机系统失效源的统计数据
由表1可以看出，软件故障正逐渐成为导致计算机系统失效和停机的主要因素。

对复杂计算机系统需求的急剧增加，远远超过计算机软/硬件设计、实现、测试及维护的能力，结果出现了许多可怕的计算机工程事故，其中大多数都是由于软件故障所致。

面对系统需求和软件复杂性的增长，软件行业碰到两个大问题：一个是软件生产力的问题；一个是软件可靠性的问题。

几百、几千万行的程序，要在较短的时间内拿出来，就必须要有多人分工协同，重用已有的软件，使从规范到程序的许多过程自动化，这样才能提高软件生产力。

因此，软件设计方法在不断发展。

可另一方面，怎么保证这么快开发出来的这么大的软件没有故障？这就是软件可靠性的问题。

勿庸置疑，如何提高软件可靠性，如同如何提高软件生产力一样，已成为整个软件开发过程中必须始终关心和设法解决的问题。

软件故障与硬件故障的异同
计算机系统中可能出现的故障多种多样，可以进行不同的分类。

如果把故障分为硬件故障、软件故障、操作故障和环境故障四类，情况各不相同。

硬件故障是因为物理性能的恶化所造成；软件故障是由设计阶段的人为因素所造成；操作故障是指操作人员和维护人员的错误；环境故障则包括电源、外界干扰、地震、火灾、病毒等各种外界因素引起的故障。

软件故障导致软件在其运行期间的表现偏离了事先规定的行为要求。

如果规格说明书错了，即使软件的实现与规格说明书的要求符合，但它与用户的要求不吻合，从用户立场上来看，这也是对事先规定行为的偏离，它将直接影响到用户的使用。

因此，只要用户有抱怨，就可以说，是由于软件故障所致。

但是，另一方面，如果用户提出的对系统的要求过于复杂，前后矛盾，或者不全面，就会天生地出现故障，甚至整个项目的崩溃。

软件故障是指软件设计上的错误，它是人为的。

而硬件故障虽然也有由于设计错误而引起，但大部分是物理故障，例如寿命、磨损、外界干扰等。

而软件既没有寿命问题，也没有磨损的问题。

软件故障是一个软件固有的，不在一定的条件下不会表现出来。

恰恰是由于尚未表现出来，常常被人误认为没有故障。

虽然说软件故障不像硬件故障可能由于元件老化产生，但软件由于长期使用使软件性能下降，甚至完全失效的故障也是有的。

例如，无休止的线程、无释放的文件锁闭、数据污染、存储空间的彻底分裂与积聚差错等。

软件故障是人为的，其来源主要有以下几个：
(1) 软件规范（Specification）
软件规范是软件开发的出发点，是需求分析的结果，一般是用自然语言书写。

保证软件规范完全性和无矛盾性是很困难的。

例如一个银行取款机，用户的操作错误应该是允许的，只要取款机不出钱、不计账就可以。

但是，你不能允许用户无限制地试下去，以防止他恶意地刺探别人密码或其他攻击。

对于一个操作系统写一个规范，你几乎无法穷尽地考虑所有可能的情况。

越是大的、复杂的软件项目，其软件规范就越难写，写出来的规范存在故障的概率也就越大。

(2) 软件开发过程
软件开发过程是一个需要很多人参与协同的过程。

协同过程中的漏洞容易造成软件故障。

软件管理过程不到位，出现软件故障的可能性就加大。

(3) 软件工具
在软件开发过程中，必然要使用很多软件工具，例如，编译器就是最基本的一种。

现在，越来越多的软件工具已在市场出现。

事实上，越是大型的软件，越是需要更多的工具。

值得注意的是，软件工具本身并不能保证完全正确。

工具中固有的软件故障就可能使新开发的软件产生故障。

(4) 编码过程
编码一般由程序员完成。

程序的质量与程序员的素质很有关系，甚至和程序员的性格、作风和经历都有关系。

编码过程的故障最能体现程序员的编程水平。

但出错仍然是不可避免的，而且是大量的。

软件可靠性
已投入运用的软件的一个重要标志是软件可靠性。

从实验系统所获的统计数据表明，运行软件的驻留故障密度各不相同，与财产有关的关键软件为每千行代码1-10个故障，而生命攸关的关键软件为每千行代码0.01-1个故障。

正是由于软件可靠性的大幅度提高才使得计算机得以广泛应用于社会的各个方面。

一个可靠的软件应该是正确的、完整的、一致的和健壮的。

美国电机电子工程师协会（IEEE）定义软件可靠性为系统在特定的环境下，在给定的时间内，无故障地运行的概率，用来评价软件按照用户的要求和设计目标，完成规定功能的能力。

软件可靠性牵涉到软件的性能、功能性、可用性、可服务性、可安装性、可维护性以及文挡等多方面特性，是对软件在设计、生产以及在它所预定环境中具有所需功能的置信度的一个测度，是衡量软件质量的主要参数之一。

关于软件可靠性方面的量度，主要有：
• 软件中初始故障个数。

• 软件经过测试后，通过查错、改错，在软件中剩余故障的个数。

•平均无故障时间。

• 故障间的时间长度
• 故障发生率
• 软件的可靠度
• 预测下一次故障的发生时间等。

软件开发过程中，测试过程的完整文档使对测试结果的收集和评价成为可能，从而可以定量地估计软件可靠性。

软件可靠性模型就是利用软件测试所提供的有关软件系统的故障数据，估算软件的可靠性，对软件将来的故障行为进行预测，以协助开发人员监督软件开发过程，
辅助软件过程管理，如过程评估、风险分析、项目估计与决策等。

这类软件可靠性数学模型已经有了几十种，但人类的实践活动很难用数学方法描述出来，所以至今没有很理想的模型。

可是，从另一方面看，软件可靠性的预测是软件产业界极其关心的。

因为，软件不达到一定的可靠性，不能推向市场，所以必须经过详细测试。

但是，测试的时间又不能拖得过长，以致影响进入市场的时间，造成经济损失。

那么，一个软件究竟应该测试多长时间再推向市场才算最好，自然成为业界关注的重要问题。

软件安全性浅析
前言
现今，软件安全性已成为一个越来越不容忽视的问题，提起它，人们往往会想起一连串专业性名词：“系统安全性参数”、“软件事故率”、“软件安全可靠度”、“软件安全性指标”等等，它们可能出现在强制的规范性文档中的频率比较多，但却不一定能在开发过程中吸引开发者的眼球。

几乎每一个程序员都或多或少的在项目维护时遭遇过自己软件的安全性bug，这种经历使我们有幸在一个设计严谨而又性能良好的系统平台上工作时，都会对其大为感叹：“那真是一段很棒的代码！”这是因为，专业的软件设计开发人员会重视软件的安全性，而不仅仅把它当做是书面字眼。

在这里本文将通过对软件安全性概念的引入，以及对软件安全性各阶段的任务的介绍和如何通过软件测试来验证是否完成了软件安全性目标，较全面的阐述软件安全性对软件质量起的重要作用。

首先，应该从加固对软件安全性的认识开始。

一、软件安全性分析的重要性
“安全性分析”（safety analysis）是一种系统性的分析，应在研发过程的早期开始进行，用于确定产品在每一个使用模式中执行其功能的方式，识别潜在的危险，预计这些危险对人员及（或）设备可能造成的损害，并确定消除危险的方法。

其中对于计算机系统来说，安全性分析的一项重要内容是“软件安全性分析”，这是对软件程序进行的一种分析，以保证程序在其设计的运行环境中，不会引起（或可以容忍的小概率引起）或诱发对人员或设备的危害。

例如多级火箭一级点火、二级点火指令如果错了，火箭就会失败。

但只要对火箭指令及传递机构采取足够的防错设计，错发指令的概率就可以小到能容忍的程度。

如果各关键项目的开发单位能从软件安全性这方面重视“安全”这个题目，那么项目的安全性链条就不会轻易地由于诸如小数点错位的原因而断开。

在软件和信息系统的开发过程中，由于技术难度高，项目复杂，开发周期短而带来的一系列困难，潜伏安全性隐患的几率其实是很大的。

现代化的软件本身变得越来越复杂，开发一个软件产品或一个大型系统所需要依靠的技术也越来越多样化，需要考虑的问题也越来越多，例如，开发团队需要在研发开始前就确定好软件系统能够承受的出事概率。

很多软件开发的组织由于没有掌握和利用必要的控制软件安全性的技术，无法妥善解决相应的问题，把时间耗费在事后补救上，使得开发的效率大为降低，产品的质量大打折扣，甚至因为某个关键错误的发生，导致产品的信誉度降低，更严重的结果则会导致生命财产安全的损失。

如果你发现有关安全性的要求已经出现在安全相关软件项目的合同书或任务书中，并提出软件安全性分析的范围和任务，那么说明已经需要开始进行软件安全性分析的准备了。

二、软件安全性分析的指导原则
如果将软件安全性分析作为一项目标明确的项目去做，从管理的角度分为五个阶段，每个阶段有不同的任务需要完成。

如（图一）：
启动和范围确定：在安全相关软件的合同或任务书中应提出软件安全性分析的范围和要求。

实施方明确责任，管理者检查必备的资源（包括人员、技术、基础设施和时间安排），确保软件安全性分析的开展；
策划：软件安全性分析管理者应制定安全性分析计划，该计划可作为所属软件过程或活动的计划的一部分。

执行和控制：管理者应监控由软件安全性分析计划规定的任务的执行。

管理者应控制安全性分析进展并对发现的问题进行调查、分析和解决（解决方案有可能导致计划变更）。

评审和评价：管理者应对安全性分析及其输出的软件产品进行评价，以便使软件安全性分析达到目标，完成计划。

结束（收尾阶段）：管理者应根据合同或任务书中的准则，确定软件安全性分析的是否完成，并应核查软件安全性分析中产生的软件产品和记录是否完整。

（图一）
上文将软件安全分析在一个典型的项目中各个阶段所要做的工作做了一个总结，每个阶段都有侧重的工作重点。

我们在实际工作中，应调动所有有关人员，努力完成各阶段的任务。

三、软件安全性分析的任务
根据上面所总结的各阶段需要做的安全分析重点，可以相应地总结出以下七种需要做的分析工作。

在这里为抛砖引玉，再对相应的应用分析技术作一些介绍：
1. 软件需求安全性分析——对分配给软件的系统级安全性需求进行分析
做软件需求安全性分析需要对分配给软件的系统级安全性需求进行分析，规定软件的安全性需求，保证规定必要的软件安全功能和软件安全完整性。

评测人员需要根据软件安全性分析准备的结果和系统的初步结构设计文档，包括系统分配的软件需求、接口需求，完成对系统安全性需求的映射，以安全相关性分析和对软件需求的安全性评价。

有了这些积累，评测人员才有把握对软件在系统中的安全性需求作出一个综合性的评价，更好地提交对后续的软件设计和测试的建议。

2. 软件结构设计安全性分析——评价结构设计的安全性，以保证软件安全功能的完整性
从安全角度讲，软件结构设计是制定软件基本安全性策略的阶段，因为这一阶段负责定义主要软件部件，以及它们如何交互，如何获得所要求的属性，特别是安全完整性，是软件安全性需求在结构定义中实现的阶段。

对结构设计进行安全性分析要做到将全部软件安全性需求综合到软件的体系结构设计中，确定结构中与安全性相关的部分，并评价结构设计的安全性。

结构设计是开发人员对系统期望功能和功能实现方式的表示方法，但是沟通的一致性，和设计的合理性，通常会影响到安全完整性，这里可以借助一些技术来验证：用动画/仿真技术证实功能的实现状态；借助接口分析技术分析安全相关部件与其他部件的相互依赖关系和独立性。

等等。

3. 软件编程安全性分析——选择合适的编程语言
所有编程语言无论在其定义还是在其实现中都有其不安全性。

这通常汇号称程序员对语言的误用，而对这些误解，一些相对开放的语言又缺乏相应的解释。

现举例如下：
a) 未初始化的变量。

除非进行特别的检查，否则单元测试不会发现他们。

而这将导致，一个程序在不同的环境下虽然运行成功，但运行结果却不是期望值。

b) 当要求重新分配存储器的调用时应予以检查，以确保不仅释放指针而且释放该结构所用的存储器。

c) 运算符优先级的规则，一些语言的要求并不是那么严格，容易是程序员发生误解。

如果某种语言有精确的定义（也有完备的功能性），从逻辑上说是清晰的，有易管理的规模和复杂度，那么就认为这个语言适用于安全相关性软件。

使用编程语言时，也应该针对该语言的特点，努力满足安全性要求。

如果一种编程经验或编程风格因为能够提高软件安全性而被公认为专用性编码标准，可以选择这样一种编码标准来约束对不安全语言的使用。

编码标准对程序员的编程修养和对语言正确使用是有指导意义的。

MISRA协会在1994年发布了它的软件开发指南，在其中特别指出。