《软件可靠性工程培训提纲之一.ppt》由会员分享，可在线阅读，更多相关《软件可靠性工程培训提纲之一.ppt（34页珍藏版）》请在三一办公上搜索。
1、软件可靠性工程,孙 志 安051885981064,要 点,1、软件可靠性工程：重要性与必要性2、软件可靠性工程：框架与过程模型3、软件可靠性工程：概念与基础4、软件可靠性工程：模型建立5、软件可靠性工程：可靠性度量6、软件可靠性工程：可靠性要求制定与分配7、软件可靠性工程：可靠性设计8、软件可靠性工程：可靠性分析9、软件可靠性工程：可靠性测试10、软件可靠性工程：可靠性工程管理,一、软件可靠性工程：重要性与必要性,因为软件可靠性问题造成的产品故障甚至事故或灾难屡见不鲜，俯拾皆是，触目惊心！重视软件可靠性工程的研究并付诸于实践，是改进软件过程，提高软件可靠性的根本出路！加强软件可靠性工程的研究
2、和实践，势在必行，势在必然！,1.1 实例分析1.2 软件现状1.3 软件可靠性工程进展1.4 软件可靠性对装备可靠性的影响1.5 软件可靠性工程的基本问题1.6 总结,1.1 实例分析：ARAIA-5发射失败,1996年6 月4日，欧洲航天局历时10年，耗资50亿美元的ARIAN-5 火箭在发射升空40秒后，由于攻角大于20度，引起了极高的气动载荷，导致火箭的助推级与芯级分离，不得不启动自毁装置引爆火箭。导致此灾难性后果的主要原因是：主惯性参考系统在将64位浮点数转换成16位有符号整数时，数字转换超出了范围，同时没有将正确的姿态数据传送给运载火箭的箭载计算机所致。另一重要的原因是这一错误在A
3、RIAN4 上就已经同样存在，但在重用此软件时将错误一并重用而未进行完备测试。,实例一：ARIAN-5发射失败,1.1 实例分析：VIKING着陆爆炸,1963年，美国航天局火星探测器 Viking 在接近火星表面时发生爆炸，导致项目失败，造成高达数亿美元的损失。造成该问题的原因之一是：弹道计算的量纲不统一，公制英制单位混淆。地面控制系统使用磅，卫星使用牛顿；造成该问题的原因之二是该探测器软件中的一个“，”被误写为“.”。,实例二：NASA火星项目失败,1.1 实例分析：TMA1溅落偏差,实例三：TMA1飞船溅落偏差,2003年5月4日，俄罗斯的TMA1 号宇宙飞船从国际空间站返回地面时，由于
4、软件错误导致导航系统故障，自动驾驶仪只能以弹道方式降落，在降落过程中，计算机又突然开始搜索国际空间站，并试图与国际空间站对接，使得飞行控制中心在飞船返回过程中与飞船失去联系长达11分钟，最终导致飞船与原定溅落点偏差达到460多公里。,1.1 实例分析：爱国者拦截失败,实例四：爱国者拦截失败,海湾战争期间，在一次拦截任务中，爱国者防空系统未能成功拦截来袭的飞毛腿导弹，造成28名英军官兵被炸身亡。其原因就是跟踪软件在运行 100 小时后出现了一个0.36 秒的舍入误差。,1.1 实例分析：CG48动力系统故障,美海军约克城（CG-48）号巡洋舰发生动力系统失效事故，导致全舰各系统功能几乎瘫痪，使该
5、舰在海上漂流了2 小时45分钟。导致该问题的主要原因是软件出现被零除的错误，造成数据溢出，并波及到整个网络系统，导致动力系统失效。,案例五：美国CG48号巡洋舰动力系统故障,1.1 实例分析：IBM360 OS开发失败,IBM360系列计算机操作系统的开发花费了大约 5 000人/年的人力投入，最多时，1000多人同时投入开发工作，写出了近 100 万行的源程序。尽管投入了如此多的人力物力，其结果却是进度一拖再拖，最终只得放弃。据统计，这个操作系统每次发放的新版本都是从前一版本中找出1000个以上的错误而修正的结果。,案例六：IBM360操作系统失败,1.2 软件现状：软件质量,软件质量问题越
6、来越突出：令人担忧！,1.2 软件现状：软件可靠性,软件可靠性问题占装备可靠性问题的比例越来越高！,1.2 软件现状：软件可靠性,软件可靠性问题呈逐年上升趋势！,1.2 软件现状：软件工程意识,为我开发一个软件,OK,软件工程意识有待进一步加强！,软件测试：成也萧何，败也萧何！,1.2 软件现状：软件可靠性工程意识,软件可靠性工程意识亟待提高！,1.3 软件可靠性工程进展：发展历程,1、由于计算机技术的飞速发展与广泛应用，软件可靠性问题于上个世纪 50 年代在美国航空航天界得到关注和研究，相应的概念得以产生。2、上个世纪70年代中后期以来，以软件工程的大力发展为契机，假传统可靠性工程技术和方法
7、，软件可靠性工程得以产生和发展。3、软件可靠性工程的发展得益于软件可靠性模型的研究与应用。20 世纪80 年代之前，软件可靠性工作主要侧重于模型的研究和建立。迄今为止，发表了 100 多种软件可靠性模型，且新的模型还在不断推出，导致了所谓“模型战”。最早的软件可靠性模型是由于 1956年提出的一系列公式，但由于太复杂，对后来的软件可靠性模型的研究和建立几乎没有产生什么影响。到目前为止已经建立起了比较完备的、适应不同软件或不同软件阶段的软件可靠性模型。,1.3 软件可靠性工程进展：发展历程,4、20 世纪 90 年代以来，软件可靠性工程的研究和实践最终跳出了模型论战，在软件可靠性设计、测试、分析
8、评估、预计预测等方面进行了比较系统的研究和比较广泛的实践，取得了显著成效。5、以1992年AT&T Bell 实验室定义的最佳软件可靠性工程大纲为标志，开启了软件可靠性工程管理之先河，从体系上进一步完善了软件可靠性工程体系。6、目前，软件可靠性工程的发展着重于技术体系、标准规范的建立，着重于理论和方法的应用，着重于各类工具的开发与应用，正在取得工程上的突破与进展。,目前，各种软件可靠性模型相继推出并得到不断改进和优化，模型验证和使用一度成为软件可靠性工程的热点，直到今天也依然是热门话题；软件可靠性设计与测试技术得以开发并逐步应用于工程实践；软件可靠性分析、评估方法不断完善并在一些特殊的或重点工
9、程项目中得到应用；软件可靠性工程管理技术的开发倍受推崇，相应的管理方法被实践所验证，软件业界已充分认识到，绝大多数软件问题是由管理不善所引起的，因此，以过程改进、组织性能改进、管理模式改进、软件开发人员管理为重点的管理体系和管理机制得以产生并日臻成熟；软件可靠性标准化工作得到前所未有的重视，国际电工委员会的TC56技术委员会成立了软件可靠性工作组，一些迫切需要的软件可靠性、维护性标准相继发布，为软件可靠性工程实践奠定了基础。,1.3 软件可靠性工程进展：发展现状,软件可靠性工程的发展是硬件可靠性工程发展的必然结果，是系统可靠性工程发展的历史要求，是软件工程发展的的必然产物，其发展是渐进式的。软
10、件可靠性工程根植于软件工程和硬件可靠性工程，经历了一个漫长的发展过程。但尽管如此，其形态与体系、理论与技术、方法与工具等仍然远远地滞后于硬件可靠性工程，仍然难以满足工程实践的需要，甚至于很多方面或方向或领域仍然处于探索之中，或者说处于启蒙阶段，开发足够可靠的软件并测试和验证其可靠性，仍然是非常困难的问题。需要业界和各位同仁的共同携手与不懈努力。,1.3 软件可靠性工程进展：发展现状,1.3 软件可靠性工程进展：技术进展,1、软件可靠性模型：假设验证 用以描述软件过程、运行剖面、错误分布、测试策略等的假设大多以经验为基础，其正确性、合理性等难以得到有效验证，对现有模型中使用的典型假设进行验证，确
11、定能够进行测试的假设是软件可靠性模型开发的关键和主要方向之一；软件测度为了提高软件可靠性模型的准确性，应尽可能多、尽可能准确地描述软件的开发过程、设计评审、软件测试、运行剖面等测度，简化模型的数学表示及其应用；决策理论为软件可靠性模型定义合适的可使用性函数，设定合理的成本函数，使先验分布准确地反映不同的事实分布，保证估计的准确性；模型统一从软件可靠性模型所涉及的范围、结构、应用等建立一个统一的框架，实现模型统一，解决现有模型各自为政的混乱状态。,1.3 软件可靠性工程进展：技术进展,2、软件可靠性设计：避错设计是软件可靠性设计的基本方法，软件工程与软件开发技术的飞速发展与成功应用，为避错设计奠
12、定了坚实的基础。但避错设计只能确保一定的软件可靠性水平，通常达到=10-3 数量级，如果要进一步提高软件可靠性，则必须在严格遵循软件工程原理的基础上，采用查错设计、纠错设计、容错设计等技术和方法。但在这些领域内，目前尚存大量需要研究和解决的问题。3、软件可靠性测试：由于软件故障定义的主观性、不准确性以及软件可靠性目标的不确定性，使得软件可靠性测试有别于传统的软件测试，而且在技术、方法和工具等的支持上还存在着很大的差距。,1.3 软件可靠性工程进展：技术进展,4、软件可靠性预计与分配：用现有模型预计软件的可靠性往往存在着较大的偏差，当给定或已知数据分布时，极大似然估计是模型参数估计的基本方法，有
13、利于对预计的改进。通过故障强度拟合来估计模 型参数的最小二乘法能很好地代替极大似然估计，对于中小样本的情况，具有较小的偏差和较快的收敛性，Bayes 分析方法提供了一种将先验知识综合到估计过程的方法，为把不同数据源综合起来提供了有效的手段，然而其分析和计算极为复杂，数据融合算法似乎为此带来了希望，但毕竟才刚刚起步。而软件可靠性分配还缺乏成熟的技术。目前主要是按软件体系结构划分确定层次，应用分析分层过程推定需要的模型参数，然后以求解非线性规划问题，确定不同软件级别上的分配方案。,1.3 软件可靠性工程进展：技术进展,5、软件可靠性分析与评估：目前主要是在考虑软件特点的基础上，继承和应用硬件可靠性
14、分析技术如故障树分析、故障模式与影响分析、潜通路分析等方法来进行软件的可靠性分析与评估。当然，Petri网分析、基于神经网络的分析等方法的研究和应用取得了实质性的进展。6、可靠性数据处理：通常所收集的软件可靠性数据失效计数数据和失效时间间隔数据两大类。目前已经开发出一些自动收集软件可靠性数据的支持工具，但局限性很大。如何准确而高效地自动收集各种软件可靠性数据，有待进一步研究和实践。,1.4 软件可靠性对装备可靠性的影响：示例,1.5 基本问题：软件为什么失效,软件为什么失效？,软件失效是逻辑失效，没有因果关系的连续性，没有可追踪的一致性，没有透明的可测与可控性。首先，软件失效机理存在着不同的表
15、现形式，有的失效过程简单，易于追踪、分析、测量和控制；而有的失效过程可能非常复杂，难以甚至不可能进行详尽的描述和分析。另一方面，软件失效不是像硬件那样因为老化、磨损等物理原因所致，主要是软件内部错误和缺陷所引起。第三方面，软件错误能够被传播和放大，难以甚至无法进行隔离。软件的失效机理可描述为：软件错误软件缺陷软件故障软件失效。也就是说，软件中的固有错误是导致软件失效的根源，减少或杜绝软件失效的基本出发点就是尽可能地减少软件错误。,1.5 基本问题：如何开发可靠的软件,软件可靠性工程的核心问题是如何开发可靠的软件，软件可靠性工程直接面向预防和过程驱动。软件可靠性是通过设计来赋予的。软件可靠性设计
16、的实质就是在软件开发过程中，严格遵循软件工程原理，采用合适的可靠性设计技术和方法，避免人为差错以及人为引入错误，预防为主。此及所谓避错设计。但是，避错设计只能确保软件达到一定的可靠性限度，要进一步提高可靠性，在进行有效的避错设计的同时，还需要采用查错设计、纠错设计、容错设计等技术。,如何开发可靠的软件？,1.5 基本问题：如何检验软件可靠性,如何检验软件可靠性？,如何对软件所固有的可靠性水平予以考核和评价？这是确保企业诚信，增强用户信心的重要工作，也是软件可靠性工程研究和实践的重要方向之一。到目前为止，尚无一种有效的方法来证明软件的可靠性，并给出准确的量化指标，甚至难以给出其估计值的置信度。在
17、目前形式化方法和程序正确性证明等技术还无望成为实用方法的情况下，软件测试是检验和验证软件可靠性的主要有效方法。可以预测，软件测试尤其是软件可靠性测试在软件可靠性工程中将持续发挥巨大作用。,1.6 总结：软件可靠性需求,通过软件业界和可靠性工程界的不懈努力，软件可靠性工程得到广泛的研究和实践，取得了显著成效。但直到今天，开发足够可靠的软件并测试和验证其可靠性，仍然是非常困难的问题。复杂软件不管是对大工程系统还是小工程项目都越来越证明是一个薄弱环节，即使是通过完备测试与合格验证的软件也常常受到错误的困扰。与此同时，一个前所未有日益增长的需求是：软件应具有检定合格的可靠性，如武器装备系统、载人航天系
18、统、核安全控制系统等无不对软件可靠性提出了前所未有的高要求。即使是在工业和日常生活中一般应用程序的开发与销售，市场对其可靠性要求也越来越高。况且，我们还不能保证软件可靠性水平哪怕是在一段时间的将来是足够的，四十多年前就已波及到全世界范围的软件危机，直到今天依然是我们难以逾越的障碍。,1.6 总结：软件可靠性问题综述,正如IBM 360操作系统负责人FD希罗克斯在总结该项目时无比沉痛地说：“正像一只逃亡的 野兽落到泥潭中作垂死挣扎，越是挣扎，陷得越深，最后无法逃脱灭顶的灾难，程序设计工作正像这样一个泥潭 一批批程序 员被迫在泥潭中拼命挣扎，。”,1.6 总结：软件业界存在的问题,1、软件发展战略
19、研究不够，发展目标与发展方向不明确，发展路线不清晰，缺乏拥有自主知识产权的核心软件工程技术；2、软件工程化管理起步较晚，缺乏系统、规范化的软件工程管理方法，标准软件过程没有得以有效建立，项目软件过程未得以开发和维护，软件工程管理的作用不能持续地、积极地发挥出来；3、顶层软件开发、软件工程、质量管理人才匮乏，软件从业人员的工作规范化意识不强，软件设计、实现、测试人员未真正地实现分离，软件开发人员的A、B角规定难以落实；4、团队开发环境没有真正建立，软件开发依然是分散、无约束的手工作坊方式，软件三化程度低，可重构、重用能力低，软件构件匮乏；5、软件质量管理和项目管理还处于摸索阶段，缺乏定量分析方法
20、和足够的可靠性保证措施，普遍存在重技术轻管理、重开发轻组织、重结果轻过程的现象，基本没有进行软件风险管理；,1.6 总结：软件业界存在的问题,6、大多没有给定单独的软件可靠性指标，通常将系统的可靠性指标 100%地分配给硬件，认为软件可靠度R=1.0。7、软件配置管理概念模糊，配置管理不严格，配置管理工具缺乏，软件三库的设置与管理不当，致使软件在交付前基本不受控。8、软件测试，成也萧何，败也萧何。对软件测试的概念和过程认识模糊，没有开展并行的软件测试，软件测试主要还是事后验证性测试，软件测试的工程化尚未起步。9、对于嵌入式系统，普遍认为软件最终将嵌入到目标机中，常将软件开发过程与硬件研制混为一
21、体，没有软件研制任务书、不按软件过程而按硬件研制过程开发、没有单独的测试而与硬件一起调试、没有单独的评审、甚至连文档也与硬件合为一体编写，严重影响了按软件工程化方法开发与管理软件。,即便是已经走过了二十一世纪的十年。人们仍然在质量的大堤下生活，企业企业在质量的波涛中经受考验。质量工作已不再是“单个烟囱”，软件质量正在向着不同的深度和广度发生着深刻的变革。作为软件最重要质量特性的可靠性已经成为开放式技术社会中企业的最后一道防火墙与最重要的市场竞争武器。这一现实强力地推进着软件可靠性工程理论研究与实践的进展。,1.6 总结：作用与意义,软件可靠性工程的研究和实践具有如下重要意义：1、推进软件的可靠
22、性预计预测、分析设计、测试验证及其软件可靠性工程管理能力的改进提高，确保并不断改进软件可靠性，提高企业诚信，增强顾客满意，超越顾客期望；2、指导软件可靠性分析、评估、验证与鉴定，为软件验收（验证）提供依据，增强用户信心；3、推进软、硬件可靠性工程的均衡发展，提高系统可靠性水平；4、推进软件工程的不断丰富和发展，促进软件工程管理水平及其软件过程能力的改进提高；5、转变观念，有效扭转只重视硬件，忽视软件可靠性的现状。,1.6 总结：作用与意义,1.6 总结：启示与对策,可靠软件不是来自于天才和完美的代码，而是来自于：沟通（项目组之间信息的共享）设计（技术与方法）管理（整个项目资源与风险）验证与确认 风险识别与追踪 问题假设对策：软件过程建立 软件工程（质量焦点、过程、方法、工具）软件可靠性工程实践,软件：规模越来越大，结构日趋复杂，应用日趋广泛。软件危机依然是我们难以逾越的障碍！加强软件工程管理，势在必行，势在必然！改进和提高软件可靠性，为部队提供可靠顶用的装备是我们的义务和责任！,1.6 总结：出路,开发和使用软件就如同在丛林中行走，你在挫折的路上走的越远，被熊吃掉的可能性就越小，如果你总是在挫折的路上徘徊，你可能遇到的麻烦将越多。就如同两个在丛林中行走的人遇到熊时，如果你不想被熊吃掉，你不论跑得多快，但你必须跑得比另外一个人快。,
