高秉亚,黄 强,王高飞
(1.空军驻沪宁地区军事代表室, 南京210039; 2.南京电子技术研究所, 南京210039)
随着武器装备作战使用性能的不断提升、信息化程度的不断提高,使得大量的软件技术运用到装备系统中,软件的规模越来越大,复杂度越来越高,武器装备的很多功能需要由软件来实现,很多性能需要靠软件来提升,因此软件质量在全系统质量中所占的砝码越来越重。我国装备软件工程化管理起步较晚,十年前,还普遍将软件视为硬件的一个附属部分,没有将软件列为型号配套表,作为产品来单独控制,缺乏完整的指标体系和严格的测评验证手段,尚未建立完整的质量保证体系。目前,软件开发与管理大多仍为“自设计、自编码、自测试”手工作坊模式,造成软件质量普遍偏低、开发效率低、技术和进度风险大、维护困难和开发费用高等一系列问题,给部队的作战和保障带来了很大困难,其根本原因就是技术和质量管理薄弱,工程化管理水平低[1]。军代表对软件质量监督也缺少有效的手段和方法,工作很被动。可喜的是,目前国家、军队对软件质量控制越来越重视,相继出台了一系列标准和法规,旨在抓好软件全寿命周期,特别是研制开发阶段的软件产品质量控制[2]。
在整个软件研制过程中,软件需求分析是在明确软件分配需要后的一个核心环节。在软件需求分析过程中应明确软件需要达到的性能指标,并将需求作为软件设计的约束条件,为软件设计提供依据,为软件测试提供测试准则和验收标准[3]。软件需求分析是软件研制的起点,也是项目实施的关键点。据统计数据显示,在查找出的软件错误中,属于需求分析和软件设计的错误约占64%,属于程序编写错误的仅占36%。另据有关统计,软件产品存在的不完整性、不正确性,其80%以上是需求分析错误所致,而且由于需求分析错误或偏差造成根本性的功能问题尤为突出。
1.1.1 存在的问题
在软件需求分析方面,大部分军工企业存在以下两点问题:(1)需求分析和确定过程不严谨、不深入、功能基线不具体,分配基线欠准确;(2)与用户的沟通力度有限,需求分析不细致,没有准确理解或描述用户的真实意图。
1.1.2 案例分析
案例1:2009年12月,一种武器系统制导雷达在外场靶试中发现信号处理相关处理/融合插件在低温环境下有时不能正常启动,系统任务可靠性大幅下降。其故障机理为:该处理模块中的某桥片为CMOS芯片,在低温条件下运行速度会下降,如出现偶发的异常数据,会导致数据无法及时发送,造成桥片内部PCI缓冲区堵塞,从而PCI接口进入死锁状态。对应解决措施为:修改程序,开启PCI缓冲区保护机制,问题可以复现,并得到验证。从该案例剖析,得出结论是:软件设计师对武器装备工作环境需求不明确,对桥片的工作机理和保护机制了解不全面。
案例2:1996年4月,阿丽亚娜5发射升空后6 s,在3 700 m高度爆炸,造成重大损失。其主要原因是承制方对军方的需求存在理解偏差,软件中的技术指标和设计错误引起故障。
1.1.3 对策
1)软件承制单位必须加强同军方及其代表的全面、全过程沟通,并将其制度化。积极主动邀请用户参加各阶段的需求变更确认和评审,而不是消极应付,从需求识别确认、需求跟踪与反跟踪、需求变更控制、需求版本控制[2]四个方面,无限逼近用户的真实需求,确保软件需求分析内容正确、完整、一致和可验证,需求描述无歧义、可追溯、可修改。
2)提高研发团队对软件需求"重要性"意识的培养,确定软件承制单位的高层管理者、软件工程组、软件配置管理组、软件质量保证组与用户以及相互之间的有效沟通和无缝对接。在工程研制过程中,设计人员要克服一接到任务就匆忙着手编写程序的习惯,而是先要在明确需求的前提下,准确分析系统的需求,并逐步细化对软件的要求,编制出符合用户要求的软件设计规范、软件需求规格说明、接口规格说明等文档,提交用户评审,以达到需求的共识。
3)督促软件承制单位建立健全软件质量管理体系,制定本单位的软件标准过程,特别是软件需求甄别和确定过程。以软件需求分析质量为突破口,提出软件全过程质量要求,配置相应的资源,落实相应的质量保证活动,不断提高软件过程质量保证能力,从源头杜绝管理和设计缺陷。
软件配置是指软件开发过程中,构成软件产品的各种文档、程序及其数据的优化组合。该组合中的每一个元素被称为配置中的一个配置项[4]。通俗地讲,软件生存周期各个阶段活动的产物经审批后即可称之软件配置项。
软件配置项要素包含有:软件需求分析文档、软件概要设计文档、软件详细设计文档、软件实体、软件测试文档、用户支持文档等,包括与合同、过程、计划和产品有关的文档和资料;源代码、目标代码和可执行代码;相关产品包括:软件工具、库内的可重构软件、外购软件及顾客提供的软件等。
软件配置管理是一种标识、组织和控制修改的技术,要对软件生存期内各阶段的文档、实体和最终产品的演化及变更进行管理,简单而言就是管理软件的变化,目的是将错误减少至最低,并提高效率。软件配置管理贯穿软件生命周期,是开发高质量软件必不可缺的,是软件质量管理的精髓。
软件配置管理的主要任务包括:识别和确定配置项、定义配置项和版本的标识规则、制定控制变更的权限和实施步骤、记录、跟踪配置项的变更状态、验证配置项的正确性和完整性、进行版本管理和发行管理。应有文档化的配置项识别准则,根据准则进行配置项识别,明确配置项列表,给予配置项唯一的编号、名称,并标明一些重要属性,如受控级别、存储位置、负责人、源代码语言等。相对于硬件配置,软件的“配置”包括更多的内容并具有易变性。
1.2.1 存在的问题
1)在软件开发时,不可能一步到位,变更是不可避免的。由于配置管理经验少、水平低,加剧了软件工程之间的混乱,造成软件设计缺陷多、质量差、开发效率低。主要原因是变更前没有协调一致的有效分析或变更控制管理不严格,其次是文档质量较差,“三库”管理不到位,内部测评开展不充分,内部测评发现的缺陷与定型测评发现的缺陷出现倒挂现象。
2)配置项识别准则不完善,项目设置不合理。普遍存在配置项过大或过小而不能较好适应软件配置管理中的版本控制、变更控制、技术状态及成本控制要求,并对软件开发各阶段产生的各种文档的管理缺乏一致性和完整性验证的手段。
1.2.2 案例分析
在一种型号雷达的软件研制过程中,由于研制进度和管理经验的缺乏,在软件集成测试和定型测评中,发现各配置项与软件需求、各配置项之间存在不一致的问题数十项;其次,配置项设置过大(以雷达分系统为单位进行划分),没有设置合理的关键、重要软件单元(CSU),造成管理和技术状态控制上的困难,也大幅增加了软件开发、测试、测评的成本。
1.2.3 对策
1)督促承制单位制定配置项管理计划,严格落实“三库”管理。制定软件“三库”管理规定,建立相应的软件配置管理组织,对整个研制过程中的软件实施不同管理等级的控制。将早期开发并通过内部测评的软件纳入软件开发库管理,将通过阶段正式测评的软件纳入软件受控库管理,将最终通过定型测评的软件纳入软件产品库管理。严格入库/出库控制、访问控制、更动控制、版本控制、配置审核、配置报告、库间转换、维护规程等,严把文档审查、代码审查、阶段评审、测试验证等关口,并将评价意见和改进建议的归零/整改与否,作为“三库”管理的重要方面。
2)加强和完善软件版本管理,建立“版本树”管理机制。版本控制是所有配置项管理系统的核心功能。标识一个配置项变更(如需求变化或设计更改)的最好方法就是版本(树),它的主要作用是记录和追踪文件的变更,如文件更改的内容、时间、原因和更改审批人员等。版本(树)不仅记录了配置项当前状态,为后续开发提供依据,而且还可以根据版本追溯以前的状态,避免未经授权的访问和修改,避免因旧版本丢失/无法重现、更改出错或原设计人员离职等导致无法研制后果。此外,版本管理可以有效解决不同设计师之间的沟通、协调问题,减少错误。特别是需重点控制版本升级的时机:当出现大的变更时,如需求变化,导致软件需求文档需要增加新功能时,主版本号升级(由V 1.**升级到V 2.**);当出现小的变更时,如局部的修改完善,主版本号不变,次版本号升级(由V**.0升级到V**.1);
3)优化完善配置项识别准则,合理确定配置项,突出软件质量监督重点,提高配置项管理效率。软件配置项的通俗定义:软件中可以独立进行开发的一个实体,包括程序、数据及其相应的文档和说明。所以,系统配置项可按功能进行逐级细化、按层次标识,如分系统(第一层标识)、子系统(第二层标识)、功能模块(第三层标识)……,过大过细两个极端均不利于配置项的管理。以一种雷达系统软件配置项划分为例,其数据管理分系统的能力调度软件及其组成模块在表1(配置项划分粒度过大)中未被有效标识出来;通过优化完善(采纳军代表审查意见),在表2中配置项的划分就比较合理,功能模块大小适中,更切合技术状态控制和质量监督的实际。
表1 不合理的软件配置项(过大)组成表
表2 合理的软件配置项组成表
4)建议搭建或提倡承制单位使用“基于需求基线的软件管理系统(BSCM)”,建立BSCM数学模型,以解决软件配置管理过程中软件配置项一致性、完整性和可追溯性等问题。
虽然国家、军队对软件工程化管理和软件研制质量控制越来越重视,要求承研、承制单位建立、健全软件质量管理体系,并将软件作为装备及其配套产品的一部分纳入型号研制计划,严格按照软件质量和工程化要求抓好软件全生存周期管理;要求军代表从设计源头入手,狠抓软件文档审查、软件研制阶段评审、软件技术状态控制(“三库”的建立和管理),确保软件文档质量符合要求、软件测试充分有效、软件技术状态受控,最终确保软件质量。但是,由于惯性思维和出于成本考虑,大部分企业又把软、硬件变成了“两张皮、两条线”,在质量、进度管理上不尽一致,依然是硬件优先。主要表现在以下三点:(1)在研制计划管理上不尽协调,软件开发和质量保证计划滞后于硬件计划;(2)软、硬件质量管理力度不同,仍然是硬件强、软件弱,没有真正将软件视为产品;(3)对软件的资源投入仍然不够,在人力、物力、财力上均有较大欠缺等,结果就是硬件更强、软件更弱。此外,还会造成二者技术状态协调和衔接上的困难,不利于全系统/整机技术状态的控制。
相对于企业软件工程化管理水平低的现状,军代表开展软件质量监督也存在一些困难。(1)方法、手段有限,根基薄弱;(2)一线军代表中软件人员严重匮乏;(3)扭转质量监督理念需要一个过程。这三个方面决定了军代表开展软件质量监督的难度很大,需要适应新形势、加紧补课,积极探索研究开展软件质量监督的新方法、新手段。
将软、硬件在计划、质量和成本管理上捆绑起来,二者并重。以立项论证为起点,在型号装备研制的各个阶段乃至全生命周期内,真正将软件视为产品,纳入型号研制计划和型号配套表,建立完整的指标体系和完备的测评考核平台。同步制定全过程研制计划、同步开展过程质量控制和验收把关、同步进行成本审核控制,两者缺一不可,并将其“原则化、制度化”,彻底打破“硬件优先”的惯例,从根本上解决软、硬件研制的管理“两张皮、两条线”的问题,促进软件质量监督和工程化水平迈上一个新的台阶。同时,实施软、硬件捆绑把关,亦可解决两者的技术状态控制的协调性问题,有利于整机技术状态控制,确保整机研制质量。
1)严格按照软件质量和工程化管理要求,同步抓好软/硬件立项评审、需求评审、概要/初步设计、详细设计、集成测试 /初样试验、软件测评/硬件鉴定和定型等重点环节,做到同步转阶段、同步冻结技术状态,同步开展定型试验、同步开展价值工程和成本分析审查,同步设计定型。
2)军代表依据软硬件捆绑把关的原则,对照各个研制阶段的软件成果,明确软件研制阶段监控重点,如表3所示,以点带面,抓好软件全生命周期的质量监督。目前,已将该表格落实应用于部分在研重点雷达型号中,成效明显。
表3 软件研制阶段监控重点
鉴于当前军用软件面临的工程化管理水平低、软件产品质量低的形势,军代表应加快研究软件质量监督的相关方法,加强对策研究,积极探索软件质量监督的新手段、新方法,按照系统监督、突出重点、预防为主、防检结合的原则,切实抓好软件需求分析和设计评审、文档审签、配置管理、定型测评等重点环节,抓好里程碑节点控制,尽快提升软件研制质量和工程化管理水平。
[1] 阮 镰,陆民燕,韩峰岩,等.装备软件质量和可靠性管理[M].北京:国防工业出版社,2006.Ruan Lian,Lu Minyan,Han Fengyan,et al.The software quality and reliability management[M].Beijing:National Defense Industry Press,2006.
[2] 何新贵.GJB5000《军用软件能力成熟度模型》实施指南[M].北京:国防工业出版社,2004.He Xingui.GJB5000 military software capability maturity model implementaiton guide[M].Beijing:National Defense Industry Press,2004.
[3] 常云丽,邬欣明,郑 威.军用软件需求分析研究[J].火力与指挥控制,2013,38(1):126-128.Chang Yunli,Wu Xinming,Zheng Wei.Research on military software requirement analysis[J].Fire Control& Command Control,2013,38(1):126-128.
[4] 王珍英.配置管理在软件项目管理中的应用[J].计算机系统应用,2008,17(6):101-104,61.Wang Zhenying.Application of configuration management in software project management[J].Computer Systems & Applications,2008,17(6):101-104,61.