型号软件外场技术状态精细化管理方法

型号软件外场技术状态精细化管理方法摘要：针对GJB5000A配置管理在型号软件研制外场期间存在的适用性差、型号多条样机异地并行开展研制工作以及与软件技术状态频繁变更的实际情况脱节等问题，本文借鉴GJB5000A的精细化管理理念，并结合型号软件研制的实际特点，提出型号研制外场期间的软件技术状态精细化管理方法，作为GJB5000A配置管理的补充，规范型号研制外场期间的软件技术状态管理。

某型产品实施该软件精细化管理的成效表明：该管理方法能够有效管控型号研制外场期间的软件技术状态，为型号软件质量的提升起到很好的促进作用。

关键词：软件技术状态管理；精细化管理； GJB5000A；配置管理1引言相较于GJB9001C质量管理体系，GJB5000A软件工程化管理体系本身就是一种精细化质量管理方法，对于软件研发过程中实施的各个过程域，不仅给出了目标，还给出了具体实践、子实践等，其标准框架严谨细致、逻辑性强、可操作性强。

所以，实施软件工程化管理就是在推进软件精细化质量管理，而软件技术状态管理（即：配置管理）是软件工程化管理中最基础、最重要、也是最容易出成效的一个过程域。

实施软件技术状态管理，能解决软件研发过程中版本状态混乱、变更不受控、继承性弱等问题，同时能将软件代码等重要的组织资产进行统一管理。

型号研制过程中，在很长一段时间的外场期间，多条样机由多部门并行开展试制、异地工房装配调试和湖海试验，仅按照GJB 5000A配置管理过程域的要求实施软件技术状态管理，适应性较差，且与型号软件技术状态频繁发生变更以及多条样机并行开展研制的实际情况脱节。

这是由GJB5000A标准自身高度抽象、通用的特点所致，相对嵌入式软件而言，上位机软件与GJB5000A的适配性更好，上位机软件在整个研发过程中与运行硬件环境相对独立，实施软件测试对硬件的依赖性不大，但型号软件大多为嵌入式软件，研制期间需灌装在硬件上形成样机，而为了充分验证型号（含软件）技术状态，往往样机数量都多于一条。

因此，为确保型号多条样机外场期间的软件技术状态受控，避免由软件状态失控诱发的质量问题，本文在现有软件工程化管理体系关于软件配置管理的基础之上，借鉴GJB5000A的精细化管理理念，并结合型号软件研制实际特点，对型号软件外场期间的技术状态实施精细化管理，规范型号研制外场期间的软件配置管理。

具体地，建立软件外场受控库；其次，结合多条样机试制、装配调试和湖海试验由不同部门在不同场所并行开展的实际情况，提出软件版本更新发放机制；为确保多条样机软件版本一致而又避免某条产品软件变更后重复刷新其他产品导致的大量无用工作，提出试验联调报检前软件版本确认机制；针对型号外场湖海实航试验验证的特殊性以及软件频繁变更的实际情况，优化软件变更流程，将软件变更分为正式变更和临时变更，使变更流程更符合型号实际情况；最后，为提高每条样机的软件技术状态可视性，建立各条样机的软件技术状态经历簿。

2 型号软件研制外场期间存在的问题军品型号研制过程中，一般首条样机质量评审后至转阶段前的较长一段时间，处于科研大楼之外的试制现场、装配调试工房、湖试现场及海试现场。

首条样机质量评审前，型号研制过程中的软件设计、编码、测试等工作主要集中在科研大楼开展，软件受控库建立在部署到科研大楼局域网的软件管理平台上，期间的软件技术状态管理只涉及到首条样机，严格按照GJB5000A的配置管理要求实施配置项出入库及变更管理就能容易得到管控。

首条样机质量评审后，为确保型号研制的进度，首条样机会由设计师系统负责在靶场开展湖试，期间会发生软件技术状态变更，而其他样机由生产试制部门在车间同步开展试制、装配调试等工作，待第二批样机质量评审后又加入到湖上试验，而下一批样机继续进行试制、质量评审，直至所有样机先后投入到湖上试验，完成要求的湖试、海试工作。

纵观型号研制外场期间的整个过程，在很长一段时间内，多条样机由多部门在不同场所并行开展试制、工房装配调试和湖海试验，涉及到多条样机软件技术状态处于不同研制阶段时的管理，仅按照GJB 5000A配置管理过程域的要求实施管理不再适用，主要表现在以下几个方面：a) 建立在软件管理平台上的软件受控库，在外场期间由于局域网以及保密原因不能继续使用，而外场期间的软件配置管理主要集中在软件配置项技术状态的管理，涉及到的软件文档变更较少，没必要纳入到外场管理的范畴；b) 多条样机并行开展研制工作时的责任部门、工作场所不同，尽管每批次样机质量评审后，都会对软件技术状态进行一次固化并统一出库发放至生产试制部门，但设计师系统在部分样机湖试期间实施的软件技术状态变更，导致生产试制部门仍在使用旧的软件版本进行组部件试制；c) 型号多条样机并行开展试制、装配调试、湖海试验的特点，使得严格按照软件配置管理流程实施出入库灌制、变更管理，虽然能够确保型号软件受控库中的配置项技术状态的变更受控、版本可追溯，但却无法确保每条样机的软件技术状态在同一时间段内为当前最新状态，除非当某一软件配置项变更完成入库后，将所有样机的该软件配置项重新灌制，这显然是不必要的，因为某些样机可能在一段时间内搁置在湖试现场工房不参加试验，灌制软件配置项时会诱发大量的组部件拆装工作，花费大量人力、物力灌制的软件很可能在短时间内伴随着软件技术状态的变更而再次沦为失效版本；d) 型号软件的许多潜在缺陷并不能在软件配置项测试完成时得到彻底释放，因此，往往在湖海试验（系统）测试期间，软件配置项技术状态会发生频繁的变更，某些变更是为闭环处理湖海试验过程中暴露出的软件缺陷，某些变更是为满足某特定实航验证试验而进行更改（如：特定功能屏蔽、软件参数优化等），任何软件变更都按照软件配置管理的流程去进行管理，可操作性差。

3 软件状态外场精细化管理主要做法针对上述存在的问题，主要从以下5个方面入手，并结合在某型号研制过程中的实施情况，给出了软件技术状态的精细化管理方法。

3.1 建立软件配置项外场受控库首条样机质量评审通过后，在试验现场建立软件外场受控库，由质量管理人员统一管理型号软件配置项的技术状态，从软件配置项标识、软件版本标识、软件入库命名、软件出入受控库、软件变更、软件灌制等方面进行软件管控。

以某军品型号为例，软件研制任务书通过评审后，软件试点项目配置管理员负责在科研大楼局域网终端机上建立试点项目受控库，用于管理所有的软件管理配置项(CMI)。

该型号软件通过配置项测试后一周内，外场受控库管理员负责在外场配置管理专用计算机上建立软件外场受控库，其结构如图1所示，专门用于管理型号外场期间的软件配置项及其版本状态。

图1 外场受控库结构示意图外场受控库全生存周期流程如图2所示，通过确认测试的软件配置项入库、湖海试验（系统测试）期间的软件变更、通过系统测试的软件配置项入库。

湖海试验（系统测试）完毕，外场受控库管理员将外场受控库中软件配置项以及管理记录导入内网，整合到试点项目受控库，使受控库完整。

转阶段评审完成后，软件试点项目配置管理员负责建立产品库，用于阶段软件产品的管理。

图2 外场受控库全生存周期流程示意图3.2 实行软件版本更新发放机制结合多条样机试制、装配调试和湖海试验由不同部门异地场所并行开展的实际情况，各批次样机质量评审后，及时将受控库中全部软件可执行程序刻盘发放至生产试制部门，从事后续样机的试制工作，待软件后续发生变更并入库后，外场受控库管理员及时更新软件版本，将变更后的最新软件版本以光盘刻录的方式发放至生产试制部门，并告知停止使用旧版本，使用新版本软件进行组件试制或产品调试，避免旧版本的错误使用。

表1所示为某军品型号软件外场管理时使用的《软件版本更新发放单》。

表1 软件版本更新发放单3.3 开展试验联调报检前软件版本确认产品试验前进行联调报检时，各系统负责人应会同质量管理人员依据软件灌制记录，重点对近期发生变更的软件的版本进行确认，将试验样机各软件配置项的版本与当前软件受控库中最新的软件版本进行比对，无法确认的软件版本需重新灌制最新的主版本或征得顾客代表同意的分支，否则，不明软件版本诱发的质量问题自行负责。

某军品型号项目制定了表2所示的软件配置项版本状态检查表，并将其纳入到《试前调试检查表》中，每个试验条次均要对试验样机的软件技术状态进行确认。

为提高软件版本确认的效率，该型号设计师系统增加了产品联调时软件版本自动读取功能。

试前软件版本状态确认时，先通过综合调试台自动读出样机当前各软件版本号，质量管理人员再通过查阅软件技术状态电子经历簿的方式核查确认，确保软件版本万无一失。

因为，若软件开发人员在变更软件时忘记更新程序中记录版本信息的代码行，会导致软件实际版本功能性能正确，但读取的版本号错误。

表2 湖海试验软件配置项版本状态检查表3.4 优化软件变更流程针对型号外场湖海实航试验验证的特殊性以及软件频繁变更的实际情况，优化变更流程，将软件变更分为正式变更和临时变更：a) 正式变更：为消除软件缺陷、不断优化软件而进行更改，验证通过后需固化其更改后的软件技术状态，如：软件测试发现BUG变更进行回归测试，湖海试验发现软件缺陷进行变更等。

b) 临时变更：为满足某特定实航验证试验而进行更改，试后仍恢复其原来的软件技术状态或根据试验结果才能判定是否固化软件更改后的技术状态，如：特定功能屏蔽、软件参数优化等。

正式变更只能在主版本上进行，变更后版本变为下一个主版本。

临时变更只能在主版本上进行，其变更流程得到简化，不需要履行像正式变更一般复杂的流程。

试验完成后，软件负责人根据试验结果判定是否将该分支升级为主版本，若是，按照流程在主版本上实施正式变更，得到新的软件主版本入库；若否，恢复软件原主版本，在原主版本上继续下一次临时变更（需要时）。

某临时变更对应的分支升级触发的正式变更，其变更内容与临时变更一致，只是采用正式变更的形式对临时变更进行认可，固化已经通过验证的软件分支的技术状态。

软件发生变更，不同的变更类别对应不同版本号的变化，图3所示为某军品型号软件外场管理过程中由软件变更触发的版本变化，正式变更对应软件主版本的变化，临时变更对应软件分支的变化。

某两个相邻的主版本之间可能经历多个分支的变化，期间最后一个分支的升级触发软件正式变更，实现主版本变化。

图3 软件变更触发的版本变化3.5 建立各条样机的软件配置项技术状态经历簿为提高每条样机的软件技术状态可视性，对样机的软件技术状态变化过程实施表格化管理，建立了各条样机的软件技术状态经历簿，当软件配置项发生变更或重新灌制时动态更新，不仅各条样机当前的软件版本状态可视，而且也能追溯过去任一时间的软件版本状态。

图3所示为某军品型号软件外场管理过程中建立的各条样机软件配置项版本状态，通过建立该技术状态表，可以清晰地获得各样机当前的最新软件技术状态，便于试前调试检查软件版本状态。