面向复杂装备的全寿命周期软件保障研究

段 斌

(中国航空综合技术研究所，北京 100028)

0 引言

随着信息技术的发展，装备系统的性能有了很大的提升，但同时装备变的越来越复杂，复杂带来的是使用和维护费用的不断攀升，面对有限的经费预算，如何在装备的全寿命周期内以较合理的可承受的费用实现有效的综合保障是一个突出的问题。随着信息技术在装备研制中的大量应用，计算机资源保障作为综合保障的重要一部分，其重要性也渐渐凸现出来。而对于软件密集型的装备系统来说，计算机资源保障的重点便是软件保障。研究显示，典型软件产品的保障费用占整个寿命周期费用的60%～80%，同时在软件密集型系统中，软件是最主要的系统风险源，无论是从经济可承受性还是系统安全性的角度来说，需要对软件密集型的大型装备开展软件保障工作。

1 软件保障的内涵

软件保障是在软件的整个寿命周期内为包容各种变化并持续保证软件的效能而采取的一系列活动的总和，这些活动包括从初始的需求分析、设计研发、验证鉴定到软件交付用户使用，以及对所发现问题的评估、软件的修改、变更管理和鉴定等。具体来说软件保障从两方面来满足用户的需求:一是保证所交付的软件具有良好的设计特性来包容软件整个寿命周期内的变化，该设计特性涵盖易修改性、交互性、良好的扩展性和可移植性，以及软件可靠性等方面，目的是实现软件的好保障;另一方面以可接受的费用提供保障能力来满足用户对服务质量的需求。这两方面交织在一起共同实现对软件保障的规划［1］。

软件保障性反映的是在软件全寿命周期内有效执行软件保障的能力。同软件保障相对应，大体上涉及到两个方面:一是软件本身的设计特性(包括软件的可靠性、安全性、测试性和维护性等)及软件的开发工具和方法是否健全;二是实施和推动软件保障活动(包括软件的使用、后勤管理和软件修改等活动)的人员、产品和设施等资源是否完备。

可以看出，软件保障不同于软件维护。IEEE对软件维护的定义是:软件产品交付使用后，通过修正软件缺陷，改善性能或其他属性，或为适应变化的环境而对软件产品所实施的修改。软件维护分为四类。

(1)修正型维护:软件产品交付后，对所发现的问题进行及时修正;

(2)预防型维护:软件产品交付后，在潜在的缺陷演变成使用故障之前予以修正;

(3)适应型维护:软件产品交付后，为适应变化的应用环境所做的修改;

(4)完善型维护:软件产品交付后，在潜在的缺陷暴露之前发现其并予以修正。

软件保障的概念范围超过软件维护，在软件维护中包括软件的持续使用和功能增强，而软件保障除了软件维护的内容外，还包括了基础设施、技能和设计等可在寿命周期内推动保障活动的所有要素。软件维护是软件保障的重要内容之一，是软件保障的主题［2］。软件保障的费用占软件寿命周期全部费用的60%～80%，其用于保障的基础设施和组织架构比初始的开发组织规模大和能力要求高。对于软件开发来说，与软件保障既有相同之处，又有不同之处。不同之处在于软件开发人员没有现成的系统可以参考，而维护人员需要在现有软件框架的限制下阅读并理解已有软件的源代码并提出解决方案。相同之处在于维护人员有时所执行的任务同开发人员一样，如定义分析用户需求、设计解决方案、编码实现、测试并升级软件文档。

2 影响软件保障性的因素

程序加文档统称为软件，理论上软件没有磨损，也不会退化，但实际情况下软件同硬件一样，其故障率符合浴缸曲线。刚开始故障率很高，随着软件缺陷的不断修正，软件故障率降到较低的水平，但随后的应用中，需要不断修正软件潜在的缺陷、适应变化的环境及改善软件的性能，软件自身的这些变更会导致软件产品的故障率陡然升高，随着不断完善又渐渐的回归到较低的故障率。由于软件没有备用部件，每次出现故障唯一可行的方式是对软件进行修改，每次对软件设计的修改都会带来新的潜在缺陷，恰恰是对软件的修改又引入了新的缺陷，进而导致了软件可靠性的降低;而硬件是由于缺乏维护保障而导致产品功能的退化或故障，这正是软件保障同物理硬件保障的真正不同之处。因此，基于软件的固有属性，可从四个方面来分析影响软件保障的各种因素。

(1)设计特性:软件的可靠性与安全性

软件的可靠性反映了软件无故障运行的能力。可靠性与软件的变更量有密切的关系，可靠性越高，扩展性和可移植性越好，软件的变更量越小，所要求的软件修改工作量越少。

软件产品的安全性是根据软件产品所提供的功能的安全危害度来确定的。系统总的安全危害度应通过适当的危险分析技术来确定，而具体软件产品的危害度是在系统设计过程中对系统功能进行划分的基础上得出的，设计时应使执行关键功能的软件最小化。系统要求应当明确安全危害度类别，并规定适当的软件安全性等级。并将软件开发、测试和修改的各个约束与要求同各个安全性等级相联系。

(2)扩展能力:软件的运行环境(硬件环境)

扩展能力是一种系统设计属性，包括CPU、Memory、大容量存储器和输入/输出(I/O)等;反映的是软件在不受计算资源约束的情况下可以容许被修改的程度。在实际的软件开发中应考虑诸如物理、逻辑地址空间等有关的限制。扩展能力不够可能限制软件修改的范围，有时为了克服系统本身的限制，简单的修改也可能带来大量的重复工作。如机载设备的扩展能力有限，对运行在机载设备上的软件的实时性、空间利用率、代码效率和代码的冗余度都有较高的要求。

(3)软件开发

——技术

技术包括软件的设计规范和设计方法，以及所用的操作系统、编程语言、编译器、软件测试方法和工具，项目专用工具和技术，体系结构。使用专门的某项技术可能会对系统和软件设计方案有约束，还可能会影响软件工程的生产率和完整性，因此在选择技术时要谨慎。

——人员技能

软件设计与实现，以及后期的软件修改要求人员具有相应的软件工程实践能力，对具体机能的要求可能与软件的应用范围、所用的技术和方法有关。应当根据系统设计、软件设计和软件的保障策略来确定技能要求，从而确定人员和培训需求。

——软件的模块化数量

模块化设计是软件底层编码时的一种策略，软件模块化的程度与开发人员的工程实践和所选择的设计方法、工具和编程语言有关。通常来说，模块化的最佳实践应当是针对可理解和可保障的设计要求，在功能和性能之间取得最佳平衡。若软件的模块化设计较差，可能会导致在修改某部分软件代码时而需要修改其他部分的代码，从而导致修改费用的增加。可用接口管理和标准化的方法来影响软件的模块化设计。

——软件规模

软件的规模取决于应用程序和设计方案，通常采用代码行数来衡量软件的规模。相同品质的软件，软件的潜在缺陷随着软件规模的增加而成倍增加，软件规模直接影响到实施软件维护时所需要的保障资源和所花费用。由于大多数软件保障的测算都基于对软件规模和复杂度的评估，因此在软件的采办要求中应当明确对数据收集和分析的要求，以便衡量软件的规模。

——文档

文档指与软件相关的要求、规范、设计、分析、实施、测试和运行有关的所有电子或纸质的记录。文档作为软件的重要组成部分，必须按照统一的标准生成，并确保可用并易于使用。在正式接受软件之前要验证软件保障活动中所需的各种文档都得以交付。

——保密

软件产品的密级取决于应用程序和装备设计，应尽量将高密级的软件与系统的其他软件实现物理隔离。系统保密要求中应当规定软件产品的密级标准，并说明与该密级相关的修改和操作限制。其密级可能会对软件保障活动和保障环境有额外的约束和要求，如可能会限制对软件的访问及需要专用的软件保障设备。

(4)软件部署

投入使用的装备数量(部署数量)及实施软件保障的地点，对软件保障性要求和保障费用都有影响。重要的用户出于自己的实际需求，可能对软件有不同的要求，装备的数量和分布情况会影响软件保障的工作量，以及软件保障设施的最佳地点设置。部署量越多，装备累积的利用率就越高，检测软件故障及确认修正性更改要求的可能性就越大。

3 软件保障和数据模型

软件保障的核心是提供合适的功能服务来分析、优化及实施软件变更。软件保障模型也在应用中不断地发展，软件模型如图1所示，不同于先前的基于组织的模型，是基于功能且包含了数据保障的模型，该模型是对软件保障功能的顶层描述，是一个动态的模型，不仅描述了软件保障的整个过程，同时涵盖了外部实体同软件保障过程的互动。各个功能单元的具体阐述如下。

(1)外部实体

包含两部分:平台环境和外部驱动，为软件保障过程提供输入，或接受输出数据。

平台硬件宿主:软件寄住的目标硬件平台，软件可通过多种方式加载到下述硬件中，移动硬盘、PCMICA卡、磁带、专业设备和工业站点。

外部变更驱动:由用户需求或外部环境的变化所引起的变更源，包括5个方面。

——由于外部威胁变更，从而增强功能;

——由于外部环境变更，需维持原有能力;

——平台的能力变更;

——由于预算减少需降低整个寿命周期费用;

——工业技术升级。

(2)软件使用保障

包括用户使用过程中的所有活动。

——对软件、数据和固件的加载、重载、复制、标注、恢复和执行等;

——数据和软件的准备、发布和恢复。

图1 软件和数据保障模型［3］

(3)问题评估功能

询问主要是同用户进行互动，获取用户在使用和维护过程中的各种问题，在软件的整个寿命周期内扮演着十分重要的角色，主要功能如下。

①评估和过滤软件使用中的各种问题以便识别事件的原因。相应组织可通过领域知识的累积，具备清晰的工程决策能力。

②对于任何问题，调查引起问题的事件特性、去除任何重复项，并证明是接受还是拒绝该问题，同时评估接受的益处、开销和风险。

③确定待解决问题的优先次序，生成变更需求，需优先解决的问题提交管理决策功能，未提交的问题备案留待后用。

④实时解决可以解决处理的问题，以防止系统功能的衰退，对于需要修改软件的重大问题统一备案并提交变更管理功能。

(4)变更管理功能

通过控制和对变更需求排定优先次序来管理可用性和完备性。管理功能处理用户提出的变更需求，以及外部事件驱动的变更需求。在该过程中，最好使用软件技术状态管理来监控和管理软件的状态，来自军方、工业部门的专家对软件修改进行评估，对需要修改的软件授权并予以修改。

(5)软件修改功能

软件修改负责实施已批准的变更需求。此外，还应同变更管理功能进行及时的沟通，并反馈实际的实施能力已便于管理机构做出准确的评估。对于实施软件修改的机构可以使军方，也可以是工业部门，或是两者的联合工作组。

(6)验证及发布

验证及发布功能负责保证软件的变更需求得以满足，并保证软件安全可用。应负责制定安全实例，并提供可靠的耐飞性证明，验证及发布是一个迭代的过程，贯穿软件开发和修改的全过程。在软件的不同阶段要收集测试数据和证据，并保证软件变更需求和安全性都可以满足。

(7)数据保障功能

数据保障涉及信息、任务和工程相关数据，软件的上传和下载数据。数据保障活动涵盖需要创造、保持、修改、分析和发布数据的活动，任务和工程数据包括:

①电子对抗和职能数据;

②地图和气象数据;

③发动机、疲劳和部件使用数据;

④武器和传感器信息数据;

⑤功能故障和故障数据。

4 软件保障的关键技术

在传统的装备综合保障中，可通过LSA(保障性分析)确定故障模式和影响、修理级别、维修任务、寿命周期费用等方面的内容，保障性分析是综合保障的所有合理高效的保障活动的源泉，是一切技术资料的输入，是装备可靠性、维修性和测试性设计的有效反馈的数据来源，因此保障性分析是综合保障的核心和灵魂。软件与硬件系统的保障思路基本相似，因此软件保障性分析是软件保障的核心。通过软件保障性分析可以得出软件保障的思路和保障方案，实施软件保障的初衷在于减少装备的使用费用，提高装备的经济可承受性，一个软件保障方案的好与坏最终反映在保障费用是否最小化，而软件保障费用评估是评价软件保障是否合理的基准。因此在软件保障中，软件保障性分析和软件保障费用评估是关键技术之一。

4.1 软件保障性分析

软件保障的核心是软件保障性分析(SSA)。软件保障性分析目的是确定软件保障的可能要求，以及影响软件保障的约束，并确定能提高系统可用性和保障性的软件要求，以此形成适用的软件保障方案。SSA包含需求分析和过程建模［4］两项主要的活动。

软件保障性分析是贯穿软件产品全寿命周期的一项分析活动，在不同的生命周期阶段实施不同的分析任务，依据阶段的不同，分析任务的重要性有所增减，如图2所示。如在设计和开发阶段，通过实施SSA，得出加载、服务或修改软件等相关的保障性需求，以此确定保障触发因素，借鉴FMEA，确定软件设计过程中导致系统故障的功能故障模型，并以此影响软件架构和软件设计。在早期的概念阶段，通过SSA可以得出基本的软件保障需求。在服役期，适用于硬件的方方面面同样对软件有效。不同阶段不同范围内的软件修改，需要反复的进行SSA/ILS分析，每次分析的深度也不尽相同。所要执行的活动同设计和开发阶段及生产和推广阶段基本相同，但略有扩展。报废阶段，对数据的处理很重要。报废硬件时，细心的处理相应的软件和数据，敏感数据须从报废硬件上擦除(如在军事环境下)。为了存档，须对废置硬件中的已有数据加以保护。若现有数据需要在新系统中使用，须分析数据移植的可能性，并确定数据移植的方案。

图2 不同工程阶段的软件保障性分析活动［5］

4.2 软件保障费用评估

在软件的全寿命周期内，由于未来变更的种类和范围的不可预知性，外加预算的不确定性给保障费用的评估带来了很大的挑战。多种软件评估模型都对软件保障费用进行了评估，但是不同的模型之间，软件保障活动的类型差异度较大。如大多数基于参数的软件保障评估模型都对后续的工程和保障需求进行了粗略估计，但在工程实践中实际的用处并不大，其仍在发展中。

5 结语

近年来，随着装备综合保障工作的不断推进，国内相继制定了一系列的装备保障标准，软件保障也刚刚起步，从软件的固有特性着手，从软件保障的内涵、软件保障模型和软件保障费用评估等方面进行了探讨。在后继工作中将继续围绕着软件保障的重点——软件保障性分析，开展软件采办措施、软件保障性分析过程和软件保障模式的相关研究。并在工程中积极实践，为复杂的软件密集型装备的保障提供科学依据和指南。

［1］SAE JA 1004.Software Supportability Program Standard［S］.

［2］刘世军.装备软件保障技术研究［J］.中国电子科学研究院学报，2008，3(6):639-943.

［3］COOPER LB.Is Partnered Software Support appropriate for Military Aerospace Platforms［D］.British:University of Oxford Kellogg College，2007:1-18.

［4］DEF STAN 00-60(Part 3).Integrated Logistic Support Part3:Guidance for Application of Software Support［S］.

［5］ASD S3000L.International Procedure Specification for Logistics Support Analysis［S］.