基于流程控制及过程改进的软件技术状态管理方法

刘萍等/空间物理重点实验室

软件技术状态管理是确保软件质量的重要手段之一，随着型号软件研制工作的不断推进，在软件研制任务庞杂、研制成本高、技术状态变更频繁的环境下，软件研制面临如下问题：一是型号配套软件种类繁杂，软件总体无法及时掌握各配套软件当前的技术状态，在系统试验阶段很难实现各软件技术状态的统一；二是型号系统试验类型繁多，鉴于各自研软件特点，软件及配套技术文档的受控时机未形成统一规范，导致某些软件在试验前不能及时受控，参加试验的软件技术状态受控级别不一，管理混乱；三是非新研软件在沿用或适应性更改时，可选择的沿用软件没有进行合理管理，由于缺乏流程控制，导致沿用软件时选择了存在问题的不成熟软件，致使后期返工工作量超出可承受范围，严重影响型号研制进度。产品构件的沿用记录不完整，当构件升级时，无法及时通知到沿用的软件项目，使用的构件不是最新状态，后期可能引发不可估量的问题；四是软件研制过程中，经常发生多次不同类别的技术状态更改，由于更改过程不规范，更改影响分析这一更改过程最重要的环节容易被忽视，导致更改影响分析不到位，系统试验过程中频频出错。

针对目前存在的问题，航天某总体单位成立了软件过程改进小组，依托组织资产库和过程改进模型开展了多轮流程现状调研，对现有软件技术状态管理方法进行了改进，不仅规范了研制过程，而且提高了设计师队伍的工作效率。

一、总体思路

流程控制是指计算机指令运行或求值的顺序，引申到过程管理里，流程控制即过程的执行顺序控制，是一种规范化构造端到端的卓越业务流程，是一种以持续提高组织业务绩效为目的的系统化方法。软件过程改进是指在软件过程的实施中，为了更有效地达到优化软件过程的目的所实施的改善或改变其软件过程的系列活动。过程改进的实施是在认知现有软件过程的基础上，利用过程运作和监控中所获得的反馈信息，发现软件过程中存在的问题和缺陷，提出改进意见，进而实现对软件过程的改进和完善。

本文结合GJB5000A体系建设工作，以软件过程改进理论为指导，基于流程控制思想，构建了航天型号软件系统数据包，从系统层面分别对各型号配套软件进行技术状态管理；建立以试验线为导向的自研软件技术状态管理模型图，融合各类试验对软件技术状态的要求，使设计人员“一图看懂”，及时把控软件的各种状态；运用组织资产库对成熟软件和产品化构件的技术状态进行统一管理，固化产品沿用过程，使产品沿用时只能选择资产库中的成熟产品或构件；已受控文件的更改过程采用“线上+线下”结合的模式，强化线下更改影响分析，落实更改及验证过程，以规范技术状态更改过程。

二、软件技术状态管理方法与实践

1.项目实施方案

（1）构建软件系统数据包

型号软件系统数据包是产品研制过程中各种相关记录的集合，建立数据包的目的是对软件系统下各种记录进行技术状态管理。数据包中的数据可以采取任何形式，包括可交付的数据和不可交付的数据。在型号软件系统策划阶段，由部门型号负责人负责制定型号软件系统数据管理计划，作为后续型号数据技术状态管理的依据。

型号初始阶段，需在SVN中建立型号软件系统数据包目录，至少包括总体设计、型号管理、自研软件管理和外协软件管理4个部分。型号研制过程中，软件系统产生的数据需及时纳入数据包进行管理。

各型号数据包技术状态管理过程中，可在重要研制节点建立型号级数据包管理基线，作为后续型号研制管理依据，具体可包括但不限于在方案阶段结束时，将工程化大纲、软件配套表、协议等软件系统级文件纳入基线管理，以此基线为依据开展后续工作。综合试验、匹配试验、总装试验开始之前，分别建立试验基线，作为试验开展的依据。根据型号特点，在重要原理性验证试验、型号转阶段等节点建立相应系统级数据管理基线。每发次飞行试验结束后，将软件系统数据包进行归档管理，可在SVN开发库中建立归档文件夹，或在配置管理工具中进行受控管理，作为组织资产积累。

通过构建型号软件系统数据包对配套软件进行统一管理，软件总体单位可及时知悉各配套软件当前状态，并依此开展后续工作。

（2）以试验线为导向的软件技术状态管理模型

以往对软件技术状态管理的要求是采取“一刀切”的模式，即软件参加综合试验前必须受控，而并未对软件的配套文档何时受控作明确要求，导致代码已多次出入受控库，而作为软件研制依据的技术文档却未受控的情况时常发生，软件出现故障时，无法及时跟踪到是研制过程的哪个环节出现的问题。

随着本单位承担的软件研制任务越来越多，软件研制类型（Ⅰ类、Ⅱ类、Ⅲ类、Ⅳ类，分别对应完全沿用、修改装订参数、适应性更改、新研）、软件应用类别（嵌入式软件、非嵌入式软件等）和软件安全关键等级（A级、B级、C级、D级）的不同，使软件具有各自的特点，进而对软件配套文档和软件开发方测试甚至对第三方测试的要求各不相同。针对各类型的软件梳理了以试验线为导向的软件技术状态管理模型（见图1），以型号研制阶段的各类试验为主线，将软件技术状态管理要求融入各试验环节中，实现“一图看懂”，设计人员不用查阅相关标准要求，即可明确软件何时应该处于何种状态。

图1 以试验线为导向的软件技术状态管理模型

本单位自研软件可划分为新研软件、非新研软件两大类。新研软件未经过各种试验验证，参加第一轮综合试验时势必会发现很多问题，为避免开发方回归测试轮次太多造成测试效率低下、测试资源浪费，新研软件入受控库前按要求完成部分确认测试（见表1）即可，但初样转试样前需完成全部开发方回归测试。嵌入式新研软件代码入库前要求任务书、需求规格说明、设计说明文档通过评审（会议评审或文审）且已受控，或与代码同时受控；非嵌入式软件入库前要求任务书、需求规格说明通过评审（会议评审或文审）且已受控，或与代码同时受控。非新研软件由于沿用了成熟的经试验验证的软件，故必须完成开发方回归测试才可入库，对配套文档的受控要求，与新研嵌入式、非嵌入式软件的文档要求相同。

表1 新研软件首次入受控库需满足要求

为避免由于软件频繁改动导致第三方测试无法正常开展的情况，需开展第三方测试的软件在初样阶段试验全部完成后即可开展第三方测试，在软件研制总结之前完成测试即可。

以试验线为导向的软件技术状态管理模型在满足型号试验软件需具备的状态前提下，融合了开发方测试、第三方测试的要求，对不同类型的软件“分而治之”，各类软件对技术状态管理要求进行了“本地化”。

（3）基于组织资产库的成熟软件和产品化构件沿用

一是组织资产库的建立。

本单位在长期的型号磨砺中积累了非常丰富的软件开发、管理经验，这些经验如果缺少有效的梳理与沉淀，在组织内部就很难实现系统化的经验传承。

本单位基于5000A理论自2018年开始策划组织资产库，基于知识标签的专业知识萃取，完成涵盖研制流程、最佳实践的知识共享清单，并实现了初级共享，为组织资产库建设奠定了坚实的基础。后续，在完善组织资产架构的基础上，明确组织资产管理标准，建立标准组织资产库，同时立足组织资产价值的充分发挥，建立组织资产与科研流程双向互动机制，推进组织资产库建设与科研流程的双向良性互动。

结合软件研制流程，建立组织资产与软件研制的良性互动机制，一方面，成功的软件项目开发依赖于历史数据和所借鉴的最佳实践，依赖于具有丰富内容的组织过程资产库的支持；另一方面，组织资产库的建立、维护与项目开发运行是一个持续迭代的过程，需要在项目级管理、技术流程中不断积累与挖掘，将个体知识转化为组织资产，在海量知识库中萃取有效信息，持续丰富组织过程资产，推进组织能力持续改进。

二是沿用经验证的成熟软件。

组织资产库对经过试验验证的成熟软件进行了统一化管理，非新研软件可从组织资产库中选择成熟软件，沿用或沿用后进行适应性更改，并将此沿用过程进行流程化设计，固化到技术状态管理的支持平台配置管理工具中，通过此方式来规范沿用过程。

以研制类型为Ⅲ类的软件项目为例，设计人员填写沿用申请单，从组织资产库中选定即将沿用的某型号某软件，根据项目需要，选择某软件某个版本的产品基线中的一个或若干个配置管理项，并进行初步软件更改影响域分析。该沿用申请单经型号副总师批准后，设计人员线下完成软件更改可行性及影响域分析报告，并组织专家对更改报告进行评审。评审通过后，填写更改申请单，对沿用后需要更改的软件逐一进行分析、更改，并验证更改是否满足要求。

软件研制完成后，经飞行试验验证软件不存在问题，则可在软件过程改进小组同意后纳入组织资产库。在继承成功项目经验和数据的同时又为组织资产库提供了新的组织资产，以便后续其它型号软件的沿用参考。

三是产品化构件的沿用，实现型号线与产品线共赢。

随着本单位产品化工作的开展，非嵌入式软件复用产品和嵌入式软件复用产品构件已初具规模。组织资产库对可复用产品化构件进行了统一化管理。型号软件研制时可申请产品构件的沿用，形成构件引用清单。基于现状，型号线与产品线的选用依赖关系及良性互动愈发重要，当构件进行优化升级时，可及时通知引用构件的项目，经分析软件项目需要更新当前构件时，可重新进行构件的沿用申请。当各型号根据任务要求或者自身问题对软件进行更改时，需要将信息传达至产品化队伍，同步开展分析，确认该项更改是否同样需要反映至产品线，以保证产品库构件的不断完善和优化。型号线与产品线的双向互动既能在保证质量的前提下缩短软件研制周期，又能提升产品构件的成熟度，从而实现共赢。

组织资产库对成熟软件和产品化构件进行技术状态管理，需要申请并批准通过后才可沿用成熟软件或使用产品化构件。此过程已完成电子化流程设计，并固化到配置管理工具中，实现了组织资产沿用的流程控制。基于产品化构件自身标准化、通用化、低成本、高质量的特点，产品化构件适合大批量软件研制的复用，不仅保证质量、降低研发成本，还能大大缩短软件的研制周期。

软件研制全生命周期内可充分利用组织资产库，以组织标准为依据，以组织经验为支撑，同时要求项目组向组织级资产库做贡献，鼓励基于数据积累的设计创新，在盘活组织资产的同时实现其价值最大化，并促进组织过程能力与项目开发水平双效提升。

（4）“线上+线下”结合的更改过程管理

软件研制过程中，在受控库经常发生多次不同类别的技术状态更改，均需要遵循更改流程开展工作。因此，为加强技术状态更改环节的控制，受控文件的更改过程采用“线上+线下”结合的模式，强化线下更改影响分析。

受控库中文件原更改流程为：问题报告、更改申请、更改出库、更改入库，均在配置管理平台中完成。经过试运行效果较好，但表单多且审批流程繁琐，严重影响了效率。经过程改进小组讨论后，将原流程中的问题报告、更改申请、更改出库3张表单进行合并，在一个流程步骤中完成，简化了原有工作。但运行一段时间后发现更改影响分析普遍在线上开展，即结合更改申请单开展，由于缺乏线下正式评审环节，各型号中发现多次更改影响域分析不全面导致的技术问题，影响了软件产品质量。

经软件过程改进小组进一步调研和分析，对更改流程进行优化，将优化后的更改过程在配置管理工具中进行流程固化控制，强制采用“线上+线下”结合的更改过程（见图2）进行管理，步骤如下：线下开展更改影响分析评审（必须记录时间及参与人员）；线上提交更改申请（受控库中填写更改申请单并附更改影响分析报告，需提供线下开展更改影响分析评审的证据）；更改申请通过后，线下开展更改（代码需测试验证）；线上更改入库（受控库中填写更动入库单，代码需上传测试记录）。

图2 软件更改流程

另外，本单位制定了《软件产品更改影响分析规范》和《十字传播路径更改影响项目分析方法》，目的是确保更改项目分析全面、工作产品无漏项、技术分析到位。同时，强化对更改影响域分析过程的审核及把关，成立由各产品线技术负责人组成的专家组，在变更申请环节，线下开展更改影响域分析，并形成完整的更改影响域分析报告，在变更申请单中除描述更改项目外，需要上传更改影响域分析报告作为附件。

软件更改完成后，需要提交开发方及第三方开展回归测试，测试通过后，重新入受控库，再出库用于系统试验。目的是确保软件更改在进入系统试验之前得到充分的测试及验证。更改入库需附开发方回归测试记录，由开发方测试技术负责人制定软件测试记录采集表，包含测试用例设计及执行情况统计，临时代替冗繁的测试报告，待软件状态稳定后完成最终测试报告。

2.实施效果

软件技术状态管理方法陆续在某型号软件研制工作中得到实施应用，该型号指控系统在研制过程中按照固化的流程沿用了组织资产库的成熟软件和产品化构件，并依据以试验线为导向的软件技术状态管理模型开展软件技术状态管理，在保证软件质量的前提下极大地缩短了软件研制周期，采用“线上+线下”结合的更改过程管理软件技术状态的变化，对软件更改进行了全面的更改影响分析，软件系统技术状态管理取得了显著成果，为飞行试验圆满成功奠定了基础。

三、创新成果

1.构建了型号软件系统数据包

对型号软件系统下所有相关文件进行管理，包括系统层文件、外协软件、自研软件，使软件系统总体单位及时掌握当前各配套软件的技术状态，并依此开展验收、试验等各类型号任务，进一步提升了软件总体单位的抓总能力。

2.建立了以试验线为导向的软件技术状态管理模型

建立了以试验线为导向的软件技术状态管理模型，在满足型号试验软件需具备的技术状态前提下融合了开发方测试、第三方测试等要求，对不同类型的软件“分而治之”，各类软件将技术状态管理要求进行“本地化”，不仅满足标准要求，也大大地提升了软件研制工作效率。

3.基于组织资产库的成熟软件和产品化构件沿用

组织资产库对成熟软件和产品化构件进行技术状态管理，新项目在继承成功项目的经验和数据的同时为组织资产库提供了新的组织资产，有效提升了组织过程能力，软件质量也逐步从依赖员工个人经验向依赖组织能力转变，团队业务能力和软件产能得到有效提升。另外，将资产库中产品化构件合理规范地复用到大批量软件研制中，多型号试验验证优化又进一步提升了构件的成熟度。型号线与产品线的双向互动，既能在保证质量的前提下缩短软件研制周期，又能提升产品性能，从而实现了共赢。

4.采用“线上+线下”结合的更改过程管理

改变原来线上开展更改影响分析的模式，采用“线上+线下”结合的方式，强化了更改影响分析过程的审核及把关，确保了更改项目分析全面、工作产品无漏项、技术分析到位。在更改验证环节，测试人员制定的软件测试记录表包含测试用例设计及执行情况统计等内容，代替冗繁的测试报告，提高了更改后的测试验证工作效率。

在未来飞行器工业化大生产模式下，本文提出的软件技术状态管理方法，基于通用的型号软件系统研发标准过程，充分考虑了某装备软件系统工程研发特点，为开发高产量、高质量、低成本、易维护的软件奠定了坚实的基础，在规范管理、提高团队工作效率、缩短产品周期及软件的安全性和可靠性等方面有了很大的提高。其通用化的管理模式及研发过程同样适用于其它软件研制单位。

软件技术状态管理方法在应用过程中取得了一些成效，但同时也面临以下问题：一是有多个分支的软件在同一个项目中进行管理且变更较多时，难以区分各分支状态；二是已交付的外来配套软件技术状态发生变化时，更改过程在各配套单位开展，软件总体单位无法把控更改过程。

后续，需要对技术状态管理方法进行深入的探索与思考，针对多分支状态软件、外来配套软件的特点分别制定合理的技术状态管理措施，在软件研制过程中，加强对软件技术状态的监督控制，实现质量管控。