栾蓉、产启兵、李敏、徐瑛、陈丽容 /中国航天科工防御技术研究院

随着装备信息化和智能化的发展，软件逐渐成为装备的大脑、中枢，大型装备系统已成为名副其实的“软件密集型”系统。软件的快速发展，对软件的功能、性能、质量和可靠性等提出了越来越高的要求，然而因软件设计的各类缺陷导致的质量问题也时有发生。自2002 年航天系统推行产品保证管理以来，软件产品保证就是其中最重要的组成部分之一。航天系统十多年来一直采用软件评测（本文“软件评测”均特指“软件第三方评测”）作为软件质量保证最重要的途径之一，其作用和效果日益受到各方的重视和关注。软件评测是对软件的功能性能是否达到需求规格说明的要求开展验证工作，同时发现并纠正软件问题，达到提高软件质量可靠性的目标。

目前，对于软件评测项目类型的选择管理较为宽松，对于评测方提出的问题未被研制方采纳的情况控制不严，从而造成质量不过关的软件产品装备系统，影响了整个系统的质量可靠性。笔者在航天软件质量管理体系的基础上，借鉴硬件技术状态更改控制流程，提出进一步完善型号软件评测过程质量管控的手段和方法。

一、目前软件评测管理过程现状

目前航天行业软件研制工程化管理的相关标准规定各类活动的工作任务、实施步骤、方法和技术、工作要求、技术要求等，明确在软件完成配置项测试后要在有认证资格的评测单位完成独立的软件测试工作。主要工作过程分为4 个方面：

一是软件研制方完成软件配置项测试。确认软件已通过研制过程的内部测试，主要包括单元测试、集成测试、配置项测试，确认软件技术状态已经固化、软件相关文件资料齐全、符合规范、形成可供测试的固化版本。

二是评测单位针对软件的不同更改量，在新测、复测和更改确认3 种测试项目类型中选择适合的类型，随后制定测试计划、测试用例、测试规程，并负责测试数据相关工作。过程中软件研制方要参与测评大纲和测试用例的设计、测试报告的评审。

三是软件研制方对评测单位评测时发现的问题要进行分析和处理，对修改内容要进行测试验证和更改控制，修改后提交评测单位进行回归测试。

四是评测单位出具评测报告和相关统计测量结果，如软件总规模、有效代码行数、软件注释率、千行代码缺陷率、文档问题数、代码问题数等，并通过正式评审，其结论作为软件验收的重要依据。

软件评测具体流程见图1。

图1 软件评测过程流程图

二、存在的主要问题

1.评测中3 种测试项目类型的选择存在就低不就高现象，质量管控较松

在相关评测技术管理要求中对新测项目、复测项目和更改确认这3 种测试项目进行了定义和区分。主要区别为新测项目需要对全部代码进行评测，复测项目和更改确认均属于回归测试，只对软件更改部分和受更改影响部分进行评测。复测项目需进行动态测试，更改确认项目测试时只对代码进行静态审查，而不进行动态测试。具体定义见表1。

表1 3种评测项目的测试条件及特点

在实际提交评测的软件存在更改量较小，评测方认为软件的更改情况满足采用“更改确认”的测试条件，而采用更改确认的方式进行验证只进行静态测试，不开展动态测试，造成测试不够全面。还有一些在试验现场临时做的偏离性更改，由于时间、场地、人员受限，大多都只是按更改确认做静态文档代码比对，缺少覆盖性更强、测试更全面的动态测试，而这些临时性的更改往往是对试验成败起关键作用的。

2.评测提出的问题容易被设计师忽视，重视程度不够，缺乏分析验证工作

评测方将发现的问题分为四类:关键、重要、一般和建议。通过统计分析近3 年来不修改的问题发现，严重问题均得到了修改，重要问题不修改量达到3%，一般和建议类问题不修改量则高达30%。一方面，评测方与软件设计师沟通不充分，未将问题及可能存在的风险描述细致清楚；另一方面，软件设计师过于自信，对评测方反馈的问题仅从程序代码表层分析，并未对软件缺陷被触发后导致的后果或者对试验可能造成的影响进行更深入的分析，对于功能较为单一的底层设备软件尤其是FPGA 软件，这种现象更为突出。例如，评测方对某产品惯测组件FPGA 进行了评测，提出FPGA 的时钟CLK 信号和DSP 的写信号未做同步处理，当评测方指出该部分逻辑需要优化设计，将两个信号做同步处理时，设计师分析认为两者相位差固定，不作同步不会有问题，并在以往产品测试中均未发现问题，故对评测方提出的信号同步问题作出本阶段不进行更改决定。后来该产品在参加某次试验时，就是因为该问题导致惯测组件没有输出正确有效的信号，试验任务中止，对产品质量声誉造成负面影响。

3.评测发现问题的更改控制流程中责任不够清晰，对不修改问题的审批要求宽松

目前，航天系统相关的软件评测管理要求中对评测发现问题的处理方法进行了规定：“不修改的问题应经过研制方软件设计师的上一级总体负责人认可；对双方存在异议的修改问题，研制方应编写风险分析报告，经双方领导确认后提交上会，由评测报告评审会给出评审意见。”在实际操作中，仍然存在重要问题不更改的现象，主要原因是时间节点紧张，不满足软件更改后的验证周期。软件研制方由于时间节点逼近，对软件评测方提出的问题没有足够的时间认真分析研究，为了达到管理流程的闭环，研制方更愿意选择写风险分析报告提交上会评审，而不愿花费足够的时间来验证软件更改是否正确。而在风险分析评审时，邀请的同行专家精力有限，很难参与某个软件开发全过程的各项评审，仅参加一次会议、审阅一份报告未必就能认识到可能存在的所有风险，这就导致了不更改问题被例外放行。

三、软件评测质量管控优化措施

1.加严控制评测项目类型的选择，强化动态测试

完善软件评测实验室体系作业文件，对评测项目类型的选择加强把关力度，不可仅根据经验或软件改动量的大小和规模进行判断，还要综合考虑被测软件的重要性、安全性、关键等级等方面的内容，强化动态测试手段，如果测试项目有裁剪必须要说明理由，当功能、性能等有所更改，需要新增测试用例测试，验证更改的正确性，以此达到评测全面性、充分性和覆盖性的要求。

2.采用审理方式，加强对软件评测提出的问题不被采纳情况的控制

修改完善GJB5000A 体系文件及相关评测标准和规范，明确不更改软件问题处理办法，根据软件的研制过程及评测过程，参照硬件产品的不合格品审理方式，提高对软件评测问题不修改情况的把关力度：对软件评测提出的问题，如果软件研制方不修改，也应办理《软件评测不修改问题审理单》，说明不修改的理由及可能存在的风险，落实责任人并提高审批等级。

3.落实软件装机许可证制度，强化软件评测过程质量管控

参照航天系统多年来一直施行的元器件装机许可证制度，对于提交评测的软件，软件单位在确认《软件评测不修改问题审理单》签署完整有效，并通过了软件评测评审会后，发放“软件评测合格证”。质量管理部门应检查软件具备“软件装机许可证”后方可入软件产品库。通过发放“软件装机许可证”，可有效提高评测单位对软件评测过程的质量监管水平。

通过推行软件评测合格证、软件评测不修改问题审理等优化措施要求，评测单位对其影响和效果进行了4 年的跟踪和统计。截止目前，据不完全统计，在该措施落实之后， 软件评测提出的问题修改率平均提高了11 个百分点，取得了显著成效，促进了软件质量管理水平的提升，进而为提升软件质量和可靠性奠定了坚实基础。