关于武器装备软件问题产生原因分析

任喜录，胡 勇

(解放军63961部队，北京 100012)

关于武器装备软件问题产生原因分析

任喜录，胡 勇

(解放军63961部队，北京 100012)

为了提高武器装备软件工程化水平，在对武器装备设计定型软件测评工作中发现的软件问题进行分析、归纳的基础上，总结提出了武器装备软件问题产生的7种可能原因：装备软件指标可操作性差、软件需求分析不充分、软件设计说明内容不详实、软件编程不规范、软件文档评审不严谨、软件研制单位内部软件测试不落实、软件研制过程的软件工程化管理水平不高，阐述了武器装备软件问题产生原因的各种表现，并通过具体软件问题实例对每一个软件问题产生原因进行了进一步的说明，这对从根本上减少或避免装备软件问题的产生具有促进作用。

武器装备;软件问题;产生原因

0 引言

随着装备信息化程度的不断提高，软件在装备中的规模和复杂程度越来越大，软件在装备中的作用越来越重要，信息化装备的功能和性能越来越多地由软件来实现，因此，信息化装备中软件的质量对信息化装备完成任务成败的影响也越来越大。为了保证定型装备中的软件质量，陆军装备在设计定型时由必须进行基地试验、部队试验的基础上增加了软件测评考核项目。自这时起作者开始从事陆军装备设计定型软件测评工作，在这期间参加并完成了几十个型号的设计定型软件测评任务，在软件测试过程中发现了数千个软件问题，其中有大量的致命问题和严重问题。这些问题在装备定型前被发现并得到有效解决，保证了这些新研装备软件质量的提高[1]。

在软件测评过程中发现，有的新研装备软件中存在的问题很多，多达上千个。虽然装备设计定型时进行软件测评是一种减少或避免软件问题的有效手段，但这不能从根本上减少或避免新研装备软件问题的产生。为了找到解决在新研装备的研制过程中减少或避免软件问题产生的根本手段，作者对以往发现的软件问题产生原因进行了分析总结。

1 软件问题产生原因分析

软件生命周期始于装备型号论证，经过一系列阶段之后进入编程阶段，实现软件编程。程序中存在的软件问题并不一定是由编码所引起的，有的软件问题是由编程阶段之前的某个阶段存在的问题所引起的，装备软件测试模型见图1。通过对以往软件测试发现的软件问题的原因进行分析、总结，可将软件测评过程中发现的软件问题产生的原因归纳为7个方面：

1)装备软件指标可操作性差；

2)软件需求分析不充分；

3)软件设计内容不详实；

4)软件编程不规范；

5)软件产品评审不严谨；

6)研制单位内部软件测试不落实；

7)软件研制过程的工程化管理水平不高。

图1 装备软件测试W模型

1.1 装备软件指标可操作性差

装备型号论证分为作战使用要求论证和战术技术指标论证两个方面。装备型号论证的主要工作是确定装备型号的作战使命、任务及作战对象，确定装备型号的系统组成、主要战术技术指标与作战使用要求等。装备型号论证的产品是《武器装备研制总要求》，为开展装备型号研制提供依据。

在设计定型软件测评发现的软件问题中，有些软件问题是由于装备的软件指标可操作性差造成的，这为研制高水平的武器装备留下了隐患。装备软件指标可操作性差的表现为：作战使用需求不明，战技指标不细，总体技术方案不清。

例1：在某型节点交换设备的研制总要求中对节点交换设备接入战术互联网的战术技术指标要求是“具有接入战术互联网数据传输功能”，仅仅这么一句笼统要求，对接入战术互联网的组网类型有哪些没有要求。节点交换设备接入战术互联网的组网类型实际可有多种：

1)直接接入战术互联网的节点交换设备的数字终端间通过战术互联网能进行数据传输；

2)直接接入战术互联网的节点交换设备的数字终端与战术互联网的数字终端之间能进行数据传输；

3)非直接接入战术互联网的节点交换设备的数字终端之间通过战术互联网进行数据传输；

4)非直接接入战术互联网的节点交换设备的数字终端与战术互联网的数字终端之间能进行数据传输。

从满足作战使用角度来讲，上述所有组网类型均应实现。在进行设计定型软件测评时发现：研制方由于难于实现其中的某些接入战术互联网的组网类型而发生了随意剪裁指标要求情况，当软件测评时作者对此提出软件实现存在问题时，研制方以研制总要求对接入战术互联网的组网类型没有明确要求为由，找出各种理由解释他们这样做的合理性，并坚称他们这样做满足研制总要求的要求。

例2：在某型节点交换设备的研制总要求中对节点交换设备的信道监测指标要求是“支持链路状态监测功能”。对链路状态监测的约束没有要求。因此，在型号研制时，研制方只从功能达到的角度实现了这一功能，未考虑实现方法是否符合作战使用。研制方对链路状态监测功能的实现方式是：节点交换设备通过不可控、周期性地发送握手数据来监测链路状态。采用这种链路状态监测方式的后果是：在作战使用时，不论是在不要求电磁静默使用状态下，还是要求在电磁静默使用状态下，只要节点交换设备开机工作，节点交换设备就使作为中继信道的通信设备——超短波电台、短波电台、高速数据电台、无线接力机、卫星通信地面收发设备等开始周期性地向外发射电磁波信号以传输监测握手数据；这样，在需要电磁静默时就有可能造成电磁暴露。

1.2 软件需求分析不充分

软件需求分析阶段的主要任务是依据研制总要求和软件研制任务书对软件的功能、性能、数据和接口等要求逐项细化，通过分析深入地、全面地理解研制总要求和软件研制任务书对软件的要求，编写形成《软件需求规格说明》，为下一步开展软件设计提供依据。

在设计定型软件测评过程中发现的软件问题中，有些软件问题是由于软件需求分析不充分造成的。软件需求分析不充分的表现为：《软件需求规格说明》的内容没有完全覆盖研制总要求中关于软件方面的要求或软件研制任务书的要求，没有覆盖隐含需求；《软件需求规格说明》中的要求不全面、不清晰、不准确。

例3：在某探测系统的研制总要求中对GPS定位定向仪的定向指标要求是“定向精度：≤Xmil(基线长度Z米)”，同时，在研制总要求中明确规定了系统的作战使用条件“探测阵列的倾斜角≤Y°”。GPS定位定向仪的研制单位在进行软件需求分析时没有全面分析研究研制总要求的各项战技指标要求，因此，对GPS定位定向仪的定向精度满足要求的条件只考虑了被定向物体处于水平状态下是否满足要求，未考虑被定向物体处于作战使用要求允许的非水平状态下是否满足要求。软件测评时，作者在对其他定型试验单位已通过测试的GPS定位定向仪进行软件测试时发现：当被定向物体处于研制总要求允许的非水平状态下工作时，GPS定位定向仪的寻北精度严重超出指标要求，并且，当被定向物体处于在研制总要求允许的较大倾斜姿态时GPS定位定向仪不能进行寻北。探测系统在实际使用时被定向物体处于水平状态的情况较少，大多数情况下是处于非水平状态下使用。作为探测系统重要组成部分的GPS定位定向仪所存在的只能在被定向物体处于水平状态下正常工作、在非水平状态下寻北精度严重超出指标要求或者不能寻北的问题如果不被发现和解决，那么，这样的探测侦查装备在作战时将无法为取得战争的胜利起到应有的积极作用。

例4：在某武器系统的研制总要求中对引信的指标要求之一是“炮口可靠保险距离不小于X米”。引信研制单位在进行软件需求分析时未考虑到炮弹旋转加速度计信号线开路时引信解除保险对使用安全的影响，未考虑炮弹旋转加速度计信号线开路时不解除保险这一隐含需求，因此，在引信的软件需求规格说明文档中没有要求炮弹旋转加速度计信号线开路时不解除保险。软件测试时作者发现：当炮弹旋转加速度计信号线开路时引信电保险装置上电后就解除保险，未能满足炮弹旋转加速度达到预定值后解除保险的要求。如果存在这一软件设计缺陷的引信被装备到部队，那么，当发射安装有炮弹旋转加速度计信号线开路的引信的炮弹时将有可能发生炮弹在炮口附近爆炸的事故。

1.3 软件设计内容不详实

软件设计通常分软件概要设计和软件详细设计。软件概要设计是软件的总体设计或架构设计，软件详细设计是确定软件模块内部特征和内部详细执行过程的设计。通过软件设计编写形成《软件设计说明》，为下一步开展软件编程提供依据。

在设计定型软件测评过程中发现的软件问题中，有些软件问题是由于软件设计说明内容不详实造成的。软件设计内容不详实的表现为：《软件设计说明》的内容没有完全覆盖《软件需求规格说明》的要求，《软件设计说明》的设计内容不全面、不详细、不准确。

例5：在某显示控制软件需求规格说明中对RS-232C接口字节传输的要求是：传输速率19.2kBPS，字节传输格式：起始位1位、数据位8位、奇/偶校验为奇校验、停止位2位。研制单位在软件的详细设计时对RS-232C接口接收字节处理流程中的字节奇/偶校验考虑不周，因此，致使按照软件设计说明编制实现的程序在对RS-232C接口接收字节的奇/偶校验处理时存在软件缺陷。软件测试时作者发现：当显示控制软件通过RS-232C接口接收到字节校验位错误的数据帧时，显示控制软件发生死机。

例6：在某显示控制软件的概要设计中要求：显示控制软件能够将接收到的各种信息叠加到侦察视频图象上显示。研制单位在软件的详细设计时从功能实现角度出发仅考虑了将接收到的各种信息以白色、透明显示方式叠加到侦察视频图象的深色部分显示情况，因此，致使按照软件设计说明编制实现的程序在实现信息叠加到侦察视频图象上显示时未能满足在各种灰度的侦察视频图象上清晰显示的要求。软件测试时作者发现：当叠加信息的侦察视频图象位置也为白色时被叠加的信息无法看见，影响系统的正常使用。

1.4 软件编程不规范

软件编程阶段的主要任务是依据《软件设计说明》按指定的编程语言、采用结构化编程方法、以与软件详细设计完全一致的方式完成编程。

在设计定型软件测评过程中发现的软件问题中，有些软件问题是由于软件编程不规范造成的。软件编程不规范的表现为：程序没有完全覆盖《软件设计说明》，程序的规范性、安全性、可靠性、可维护性等指标不满足装备软件相关管理规定的要求。

例7：在武器系统研制时有的软件研制单位编制的程序结构非常复杂，函数圈复杂度非常大，高达200；源程序注释率很低，低至3%，不满足注释率不低于20%的要求；单元规模过大，大至数千行，不满足重要软件单元规模不超过100行，一般软件单元规模不超过200行的要求；编程方式还是“手工作坊式”生产方式，即对于一个独立功能软件的开发从软件需求分析到软件实现仍是由一个软件开发人员完成，未按软件需求分析、软件设计、软件编程分工进行软件开发，因此，导致编制的程序存在各种意想不到的软件缺陷，软件的可维护性、可扩充性、可移植性差。

1.5 软件产品评审不严谨

软件产品评审作为软件验证和确认的重要手段，是一种排除软件缺陷的有效机制。按照软件生存周期组织进行软件产品评审，可以及时发现和排除软件产品存在的缺陷或错误，防止在下一阶段蔓延和扩大，保证软件产品质量。

在设计定型软件测评过程中发现的软件问题中，有些软件问题是由于软件产品评审不严谨造成的。软件产品评审不严谨的表现为：软件产品评审准备不充分，评审会议时间短致使对软件产品审查不充分，评审会专家构成不合理、代表性不强，审查意见落实不到位。

例8：在已经过评审的某武器系统的跟踪测角装置软件需求规格说明中，对发射接收机与跟踪测角装置通信协议的要求是通过串行通信进行信息传输时要以含有帧头、帧长度、信息体、校验字节和帧尾的帧格式进行传输，而设计的通信协议中对发射接收机与跟踪测角装置之间进行握手的信息格式和握手应答信息格式是只有一个字节的信息体，没有帧头、帧长度、校验字节和帧尾，这明显不符合通信协议对信息传输格式的要求，却通过了评审。

1.6 研制单位内部软件测试不落实

根据软件开发生存周期研制单位内部软件测试可分为单元测试、集成测试、配置项测试、系统测试，研制单位内部软件测试的主要目的是验证软件是否满足软件研制任务书、软件需求规格说明、软件设计说明等文档所规定的要求，尽可能早、尽可能多地发现软件中存在的缺陷，为软件转入下一阶段工作提供依据。

在设计定型软件测评过程中发现的软件问题中，有些软件问题是由于软件研制单位内部的软件测试不落实造成的。软件研制单位内部软件测试不落实的表现为：软件测试队伍不健全，软件测试人员的软件测试水平不高，软件研制过程中未组织软件测试人员对不同阶段开发的程序进行软件测试。

例9：有些软件的研制单位在进入设计定型阶段时虽然提交了研制单位进行软件测试的有关文档，但往往是为了满足有关软件质量管理规定要求而撰写的软件测试文档，实际上并未进行内部软件测试。在对某武器系统的跟踪测角装置软件进行设计定型软件测评中发现的许多软件问题都是很容易发现的软件问题就说明了这一点。譬如：在跟踪测角装置与执行同步模块通信正常时，发送目标坐标信息后跟踪测角装置软件控制显示的不是“发送成功”，而是“发送失败”；在非设置状态下“确认”键不是不响应操作，而是响应了确认操作，并发生了显示屏闪烁；跟踪测角装置软件控制显示的经度、纬度的单位符号错误；当目标坐标信息中的距离值为0时不是不发送目标坐标信息，而是发送不确定的目标坐标信息等。如果研制单位进行了有效的内部软件测试，那么，这些软件问题是不难被发现的。

1.7 软件研制过程的工程化管理水平不高

软件工程化管理就是要建立一套系统的技术和管理规则，对软件研制、生产和维护过程实行控制和管理，以保证获得质量可靠的软件。

在设计定型软件测评过程中发现的软件问题中，有些软件问题是由于软件研制过程的软件工程化管理水平不高造成的。软件研制过程的软件工程化管理水平不高的表现为：单位领导对软件工程化管理工作不重视，软件工程化管理体系不健全，软件工程化管理人员职责不明，软件工程化管理措施未落实。

例10：有些软件研制单位在软件开发过程中对软件过程产品管理不到位，未做到通过对基线的版本控制实现对软件的版本控制，未做到通过对基线的变更控制实现对软件的变更控制，未做到通过对基线的管理实现对软件过程的管理。在设计定型阶段提交被测软件时软件开发人员对入库的软件研制任务书、软件需求规格说明、软件设计说明等软件产品未经变更请求、变更许可、变更实施和变更验证而随意进行更改，这对软件状态控制和软件质量的保证带来很大风险。

2 结束语

作者对于软件问题产生的原因可从不同角度进行了分析、总结，本文对武器装备设计定型阶段软件测评时发现的软件问题产生原因的分析、总结是按照型号论证、软件需求分析、软件设计、软件编程、软件产品评审、内部软件测试、软件工程化管理的线索进行的，在此基础上将软件问题产生原因归纳为7个方面：装备软件指标可操作性差、软件需求分析不充分、软件设计说明内容不详实、软件编程不规范、软件产品评审不严谨、软件研制单位内部软件测试不落实、软件研制过程的软件工程化管理水平不高，并且，对归纳出的每一方面软件问题原因均通过软件问题实例进行了说明。

为了促进武器装备软件开发质量的进一步提高，作者建议：(1)提高武器装备型号论证水平，确保软件指标的描述全面、准确；(2)加强有关软件开发国军标的宣贯工作，确保武器装备软件开发单位的软件开发产品规范、详实、准确；(3)加大对武器装备软件开发单位的检查、监督力度，确保其软件工程化管理工作得到真正落实。

[1] 张善文,等.软件测试及其案例分析[M].西安：西安电子科技大学出版社，2012.

Reason Analysis on Problems of Weaponry Software

Ren Xilu, Hu Yong

(63961st Unit of PLA, Beijing 100012, China)

In order to raise the level of software engineering for weapons and military supplies, on the base of analyzing and categorizing the problems during the software testing and evaluation for weaponry design and finalization work, 7 kinds of possible reasons for weaponry software development are summarized in this article: bad operability of the KPIs, incomplete analysis for the requirements, inadequate explanations about the software design, nonstandard software programming, imprecise checking on software documentation, weak implementation of internal software testing and evaluation by developer unit, low level of software engineering management. Furthermore, this article lists the various behaviors of the above different weaponry software problems, and demonstrate the deep reasons of the problems by the practices of software testing and evaluation.

weaponry; software problem; root reason

2016-04-07；

2016-06-21。

任喜录(1964-)，男，河北定兴人，高级工程师，主要从事软件测评及软件工程化工作。

1671-4598(2017)02-0110-03

10.16526/j.cnki.11-4762/tp.2017.02.030

TP311.5

A