1.4 软件工程与软件可靠性

软件是新经济的使能因素和驱动器。自20世纪60年代末起，随着微电子技术的发展，计算机硬件的性能价格比和质量稳步提高，相应的计算机软件逐步变为以计算机为基础的系统的核心部件。随着计算机应用领域的不断扩大，对软件的需求不断增多，软件数量急剧增长，软件复杂度和规模越来越大，软件需求日益繁复，这些都使得手工作坊式的软件开发方法难以应对软件的开发任务，同时导致软件研制费用在整个系统研制费用中所占比例越来越大，软件开发成本越来越高，软件维护难度越来越大，软件研制和软件可靠性暴露出来的问题越来越突出。例如，进度计划和成本估算往往很不准确；软件无文档或文档不适当；用户往往对交付的系统不满意；软件质量常被怀疑；软件常常是不可维护的等。这种由软件的开发和生产仍停留在手工作坊方式致使出现的开发和生产的软件产品质量不高、生产率过低、资金大量浪费、进度无法保证的局面，也使得软件成为计算机发展的关键因素，从而导致了所谓的“软件危机”。软件危机是指在软件的研制和维护中所遇到的一系列严重的问题，通常来说包括如何开发软件，怎样才能满足对软件的日益增长的需求，如何维护数量不断增多的已有软件等。软件危机无疑与软件本身的特性有关。软件是逻辑的系统部件而不是物理的系统部件，软件的维护往往意味着要修改设计，而不是简单地进行备件替换。产生软件危机的主要原因就是采用不正确的方法进行软件的研制和维护。据报道，20世纪最后十年里，计算机软件故障已成为导致系统瘫痪的主要原因，为了摆脱软件危机所造成的困境，保证开发出优质、高效、低成本的软件产品，迫切需要采取一系列措施来提高软件质量。为此，软件工程这一工程技术学科应运而生。1968年在联邦德国Garmush召开的计算机软件技术、管理和维护讨论会上，首次以“软件工程”一词来标志会议主题。也是在这次会议上，软件工程作为一门独立的学科正式诞生，它融合了各个学科的知识和技术，如计算机科学、工程管理、界面设计和知识发现等，其目的是为软件开发过程建立具有良好定义的工程化原理，以便能够经济地获得可以在实际机器上有效运行的可依赖的软件。软件工程关注软件的设计、开发和文档化。此后，这一术语很快为科技界所接受。

1.4.1 软件工程的内涵及目标

软件工程过程是指为获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动，包括以下四方面。

第一，P（Plan）——软件规格说明。规定软件的功能及其运行时的限制。

第二，D（Do）——软件开发。开发出满足软件规格说明的软件。

第三，C（Check）——软件确认。确认开发的软件能够满足用户需求。

第四，A（Action）——软件演进。在软件运行过程中不断改进软件以满足用户新需求。

从软件开发的观点看，软件工程就是使用适当的资源（包括人员、软硬件资源、时间等），为开发软件进行的一组开发活动，在活动结束时输入（用户需求）转化为输出（满足用户需求的软件产品）。

将科学的软件工程方法应用于软件生命周期的全过程，可达到以下软件工程的基本目标。

第一，得到一种定义良好的方法学，该方法学是面向包括计划、开发和维护等阶段的软件生命周期的。

第二，得到一组可以预测的里程碑，在整个软件生命周期，每隔一定时间可以对它们进行评审。

第三，得到一组确定的软件成分，它对软件生命周期的每一步建立文档资料，并且具有按步显示轨迹的能力。

1.4.2 软件需求工程及需求抽取

到20世纪80年代中期，逐步形成了软件工程的子领域——需求工程。需求工程过程是发现、记录和管理计算机系统需求的过程。其目标是尽可能产生一组完整的、一致的、相关的、能够反映用户真实需求的系统需求。进入20世纪90年代后，需求工程成为软件界研究的重点之一。从1993年起，每两年举办一次需求工程国际研讨会（the International Symposium on Requirements Engineering，ISRE）。从1994年起，每两年举办一次需求工程国际会议（the International Conference on Requirements Engineering，ICRE）。1996年，Springer-Verlag发行新的刊物——Requirements Engineering。2002年，ISRE和ICRE合并为需求工程国际联合大会（the Joint International Requirements Engineering Conference，Re’02）。

需求工程问题无疑是当前软件工程中的关键问题，由美国Standish Group于1995年开始进行的一项调查的结果就足以看出这一点。在这项调查中，研究人员对全国范围内的8000个软件项目进行跟踪调查，结果表明，从总体上说，项目的成功率只有16.2%，有1/3的项目没能完成，而在完成的2/3的项目中，又有1/2的项目没有成功实施。未完成和未成功实施的项目所消耗的经费平均超出预定经费189%，所消耗的时间平均超出规定时间222%，所消耗的经费和时间远远超出了预算或计划。根据这些统计数据估计，当时美国的公司和政府代理在被取消的项目上白白花费了近81亿美元。研究人员仔细分析失败原因后发现，与需求工程相关的原因占45%，而其中缺乏最终用户的参与及不完整的需求又是两大首要原因，各占13%和12%。此外，美国麻省理工学院系统与软件安全性项目组的研究人员通过对大量与软件相关的事故进行统计分析发现，几乎所有与软件相关的事故都涉及软件需求问题。

从本质上说，软件开发由若干知识密集型活动组成，其中最难以建模的过程便是需求抽取。因此，需求抽取被认为是软件开发中最为关键的知识密集型活动。需求抽取在传统的软件开发过程中扮演了重要角色，这是因为需求定义和构建是需求规约的基础，并可作为后续设计和编码的依据。随着软件系统规模的扩大，需求抽取与定义在整个软件生命周期中的作用越来越重要，甚至直接关系到软件开发的成功与否。人们逐渐认识到需求抽取活动不再仅发生在软件开发的最初阶段，而是贯穿软件开发的整个生命周期。

从总体上说，需求抽取应完成如下四方面任务。

第一，理解应用领域。应用领域知识是系统将要运行于其中的领域的一般性知识。

第二，理解问题域。根据一般性领域知识发现目前解决方案中的问题，也就是定位待开发系统将要解决的特定领域问题。

第三，理解物理世界运作流程。软件加强型系统中的软件的作用一般来说都是使系统能更好地运作，有更好的性能，因此必须理解这些待开发软件系统如何与整体系统的其他部分发生交互，如何对它们产生影响，以及它们融为一体后如何对提高整体系统的性能做出贡献。

第四，理解需求相关者的需要和约束。系统如何支持需求相关者工作的特殊需要是进行需求抽取时要特别关注的，必须理解待开发系统须支持的工作流程，以及支持这些工作流程的现有系统所能起到的作用。

需求抽取不仅包括一系列对软件系统目标和动机充分理解的活动，还包括确认系统为了实现其目标而必须满足的需求。被抽取需求的范围为从对易理解问题和系统的修改到对要被自动化实现的新问题的模糊理解，再到相对自由的需求。就此而言，大部分需求抽取的研究关注改善需求细节的精确性、正确性和多样性的技术，这些技术具体如下。

确认利益相关者（Identifying Stakeholders）的技术。这项技术能够确保与软件相关的所有人都能参与到需求抽取过程中。

类推技术（Analogical Techniques），如Metaphors和Personas。这项技术能够帮助利益相关者对他们的需求进行更为深入和精确的考虑。

上下文和个人需求工程技术（Contextual and Personal RE Techniques）。这项技术分析关于特定上下文、环境及个人用户的利益相关者需求，以确保最终系统在那种环境下是适用的。

创造需求技术（Techniques for Inventing Requirements），如头脑风暴（Brain-Storming）和创造力工作组（Creativity Workshops）。这项技术用于确认一些不重要的需求，从而使得产品更具吸引力。

反馈技术（Feedback Techniques）。这项技术使用模型、模型动画、仿真和脚本来抽取系统早期表示的正面和负面反馈。

此外，在需求抽取过程中，模型的使用将有助于促进讨论及发现和了解利益相关者需求。这类解释模型，如用例（Use Cases）、场景（Scenarios）、企业模型（Enterprise Models）和某些策略及目标模型（Policy and Goal Models）是倾向于非正式的和直觉的，并能实现利益相关者处的早期反馈。

从字面意思上看，需求抽取就是一个简单的信息转换过程，即需求工程师从需求提供者那里获得存在的信息并记录下来。但在实际操作层面上，这个过程却有相当的难度。一是，需求提供者一般很难清楚地勾画出他们对待开发系统的期望；二是，不同的需求提供者可能会有不同的期望，这些期望中蕴含着冲突的需求；三是，需求的可实现性还可能受到技术上的限制；等等。同时，随着软件规模的不断增大和复杂性的不断提高，参与研发的人员日趋庞杂，软件需求抽取过程的知识密集化趋势愈演愈烈。这一特征在航电系统领域软件上表现得尤为明显，这也是由航电系统的自身特点，如结构复杂、应用面广，具有高可靠性、高安全性要求，包含大量实时嵌入式软件，与硬件联系紧密，与交互环境相关等决定的。因此，如何使软件需求抽取成为一项知识完备、知识精确的活动，从而为获得高质量软件奠定坚实基础也成为业界面临的一大难题。需要说明的是，本书的研究将主要在软硬件综合系统的子类——航电系统领域内进行。

1.4.3 软件可靠性

1.4.3.1 软件可靠性定义

可靠性是软件的一个质量要素。关于软件可靠性的确切含义，学术界有过长期的争论。有人认为软件的正确性就是可靠性，还有一些软件工程专家认为软件具有与硬件不同的性质，不宜将硬件可靠性的定义引申到软件领域。经过长期的争论和研究，1983年美国IEEE计算机协会对“软件可靠性”一词正式做出了如下定义。

第一，在规定的条件下，在规定的时间内，软件不引起系统失效的概率，该概率是系统输入和系统使用的函数，也是软件中存在的错误的函数。系统输入将确定是否会遇到已存在的错误（如果错误存在的话）。

第二，在规定的时间周期内，在所述条件下程序执行所要求的功能的能力。

这个定义随后经美国国家标准与技术研究院批准作为美国国家标准。1989年我国国家标准GB/T 11457采用了这个定义。该定义表明，软件可靠性具有定性和定量两层含义。在强调其定量含义时，工程上常用软件可靠度来代替软件可靠性。

采用更简洁的表述为，软件可靠性是软件产品在规定的条件下和规定的时间内完成规定功能的能力。该定义中要注意四个要素，即条件、时间、功能和能力。描述软件可靠性要先规定前三个要素，在此前提下谈该软件的可靠性才有意义。同一个软件，如果这三个要素不一样，其可靠性一般也会不同。

条件是指软件的实际运行条件，即直接与软件运行相关的计算机系统状态和软件的输入条件，统称为外部输入条件，也称为操作剖面。这些条件与硬件产品的使用条件不同。

时间是指软件的实际运行时间区间。时间区间是指时间标尺上两个给定时刻之间的部分，时间标尺可能是连续的日历时间，也可能是离散的周期数。

功能是指一个实体或其特征动作能实现特定目标的能力，或者动作的方式，通过此动作，系统设计可以实现一个或多个规定的性能特性。规定功能是指为提供给定的服务，产品必须具备的功能。

能力的含义就是一般词源的给定解释，没有特殊的定义。与硬件一样，用概率来表示这种能力就是软件可靠度。

1.4.3.2 软件可靠性工程

软件可靠性一词出现后近20年，研究焦点基本局限于软件可靠性数学模型，真正的工程化应用比较少见，更谈不上用软件可靠性理论指导软件开发。进入20世纪90年代后，局面发生变化，软件可靠性工程一词出现并为IT产业界所接受，表明软件可靠性迎来了理论和应用相结合的新时代，这是一项意义重大的进展。

1988年，贝尔实验室（AT&T）将其内部软件可靠性系列教程命名为软件可靠性工程教程，软件可靠性工程从此登上了学术和工程舞台。贝尔实验室在解释这个词汇时明确说明，它不仅包括软件可靠性模型及软件可靠性度量，还包括应用模型和度量实现软件可靠性管理。1990年，IEEE计算机协会成立了软件可靠性分技术委员会，该委员会在成立的第一年就发起召开了第一届软件可靠性工程国际会议（International Symposium on Software Reliability Engineering，ISSRE），科技界的反应十分积极。此后这个会议每年召开一次，沿袭至今，会议的影响日益扩大，当代IT产业界的知名企业纷纷成为该会议的赞助者和积极参与者。这个事实说明IT产业界已经认识到软件可靠性工程应用的价值。但是软件可靠性工程一词的准确含义仍有待权威性的标准化机构做出定义。为了帮助读者认识和理解该词汇，本书引用1992年贝尔实验室对软件可靠性工程内涵的说明。贝尔实验室的研究人员认为针对重要软件项目的开发应该制定一个软件可靠性大纲，一个好的软件可靠性大纲应当包括下列4个系列20个工作项目。

1.可行性和需求

（1）确定功能剖面。

（2）失效定义和分类。

（3）识别需方的可靠性需求。

（4）进行权衡分析。

（5）设置可靠性目标。

2.设计和实施

（1）在部件中分配可靠性需求。

（2）适应可靠性目标的工程措施。

（3）确定基于功能剖面的重点资源。

（4）进行对故障的引入和传播的管理。

（5）进行外供软件的可靠性测量。

3.系统测试和现场试验

（1）确定运行剖面。

（2）进行可靠性增长测试。

（3）跟踪测试进展。

（4）进行项目必需的附加测试。

（5）认可可靠性目标。

4.售后及维护

（1）建立必需的售后服务机构。

（2）监视现场可靠性是否满足可靠性目标。

（3）跟踪需方对可靠性的满意程度。

（4）拟定软件的改进和提高进度。

（5）拟定产品和开发过程改进指南。

由于软件可靠性工程是为了达到软件产品的可靠性要求而进行的一系列软件工程活动，因此也可以认为其内涵涉及以下四方面活动和有关技术。

第一，软件可靠性分析：进行软件可靠性需求分析、指标分配、故障树分析、失效模式和影响分析，以及软件开发过程中有关软件可靠性的特性分析等。

第二，软件可靠性设计和实现：进行防错设计、容错设计、纠错设计、故障恢复设计和软件可靠性增长设计等。

第三，软件可靠性测量、测试和评估：在软件生命周期各阶段进行有关软件可靠性的设计、制造和管理方面的属性测量，进行软件可靠性测试、软件可靠性预计、软件可靠性评估和软件可靠性验证等。

第四，软件可靠性管理：确定影响软件可靠性的因素，制定必要的设计和实现准则，以及对软件开发各阶段软件可靠性相关过程和产品的要求。依据上述第三条所述有关测量数据和分析结果控制与改进开发过程，进行风险管理（不仅要考虑安全性等技术风险，还要考虑进度和经费方面的风险），改进效费比，改进开发过程，对采购或重用的软件进行可靠性管理等。

实施软件可靠性工程要解决三个问题，即软件可靠性指标的确定与分配、软件可靠性要求的实现和软件可靠性的验证。

1.4.4 软件工程与软件可靠性的关系

软件工程与软件可靠性既有密切关系，又有重要区别。

第一，软件可靠性低是造成软件危机的重要原因之一。

软件作为一种产品，是计算机系统的灵魂，也是许多复杂系统的神经中枢和关键部分。由软件缺陷造成系统瘫痪、失效、人员伤亡和重大经济损失的例子时有发生。1963年，在美国发射金星探测火箭的控制程序中，有一条循环语句中的“，”误写为“.”，仅这一点之差，就酿成发射失败、损失达上千万美元的事故。1996年6月4日，阿丽亚娜5型运载火箭首航，原计划运送4颗太阳风观察卫星到预定轨道，但因软件引发的问题导致火箭在发射39秒后偏离轨道，从而激活了火箭的自毁装置。后来查明事故原因是，阿丽亚娜5型运载火箭的发射系统代码直接重用了阿丽亚娜4型运载火箭的相应代码，而阿丽亚娜4型运载火箭的飞行条件和阿丽亚娜5型连载火箭的飞行条件截然不同。此次事故造成的损失约为3.7亿美元。2011年7月23日20时30分05秒，甬温线浙江省温州市境内，由北京开往福州的D301次列车与由杭州开往福州的D3115次列车发生动车组列车追尾事故，造成40人死亡、172人受伤，中断行车32小时35分钟，直接经济损失达19371.65万元。“7·23”动车事故原因是温州南站信号设备在设计上存在严重缺陷，遭雷击发生故障后导致本应显示为红灯的区间信号机错误地显示为绿灯。软件可靠性是软件质量的重要特性之一。软件质量不高首先反映为软件可靠性低从而被人们广泛关注和重视，也自然成为人们讨论软件危机的一个热点。

第二，软件工程是保障软件可靠性的基础。

优质、高效、低成本是软件工程的三大目标。保证和提高软件可靠性是开展软件可靠性活动的目标。实施软件工程，包含保证和提高软件可靠性这一重要的子目标。

软件可靠性与技术、社会、经济、文化等各种因素密切相关，即与软件开发方法、测试策略、程序设计语言、运行环境、开发工具、参与开发项目的各类人员的能力和经验等密切相关。因而在软件可靠性多年的研究过程中，人们逐步认识到要确保和提高软件可靠性，必须要求软件行业全体人员积极自主地工作和广泛协作。1990年前后，形成了软件可靠性工程的概念。在美国，每年都要举办一届国际软件可靠性工程学术年会。可以认为，软件可靠性工程是预计、度量和管理以软件为基础的系统的可靠性，以最大限度地满足用户要求的应用科学。也可以认为，软件可靠性工程是软件工程与软件可靠性的结合，是为保证经济、及时地实现软件可靠性目标而采取的系统的活动和方法。没有软件工程，便没有软件可靠性。在软件可靠性工程中须坚持以下6条原则。

（1）系统地考虑软件生命周期全过程。选用最适合的软件开发方法学（如结构化方法、面向对象方法、形式化方法等）和相应的软件生命周期模型，作为软件开发和组织管理的统一依据。

（2）根据选定的软件生命周期模型，制订软件开发计划，认真实施，不轻易变更。

（3）加强开发过程与产品的控制，逐阶段明确转移准则，进行验证或评审。

（4）重视人的因素，配备适当的人员，明确职责，制定奖优罚劣政策。

（5）规范开发过程，切忌随意化，开发过程持续改进。美国卡内基梅隆大学软件工程研究所（SEI）研制的软件工程能力评估模型（CMM）是评估、改进软件过程的一种科学的系统化模型。

（6）采用先进技术和工具，并且及时组织相应培训，充分发挥先进技术和工具的作用。

第三，软件可靠性具有专门的技术和方法。

为保证软件可靠性，除以软件工程为基础，遵循软件工程的一般规范之外，还需要某些专门的软件可靠性技术和方法。

（1）软件可靠性分析与设计。确定软件可靠性指标（含总指标及其分配），进行软件故障模式及影响分析（FMEA）和故障树分析（FTA），进行软件可靠性设计（如避错、查错、容错设计，通常采用N文本法及恢复块法）。

（2）软件可靠性度量与评估。在软件生命周期进行有关软件可靠性设计、制造、管理的度量、评估和预计，用失效数据和软件可靠性模型评估（或预计）软件可靠性。

（3）软件可靠性增长与验证测试。设计软件可靠性测试环境，进行软件可靠性增长及验证测试。

（4）软件可靠性管理与控制。确定影响软件可靠性的因素，利用质量数据和其他信息来控制和改进软件开发过程，改进效费比，并对采购或重用的软件进行管理。