航天重大工程复杂软件系统管理的创新与实践

薛 凯，高 飞，阎 君，吴晓蕊，杨 飞

（1. 空间物理重点实验室，北京，100076；2. 北京航天自动控制研究所，北京，100854；3. 中国运载火箭研究院，北京，100076）

0 引 言

航天某重大工程是一项探索性强、风险性高的国家重大科技工程，相对于传统航天器围绕特定任务开展研制工作的产品性导向而言，其最大特点是科研性。以产品性为特点的项目工作思路是用最成熟的技术做最稳定的产品，而以科研性为特点的工作思路则是充分验证技术方案和快速探索极限能力，这就决定了该工程项目的研制工作和演示验证方案的复杂性和多变性，也意味着其技术状态的多样化、试验产品交付的高频性等特点。为了尽快完成研制工作，队伍基于硬件产能与产品交付频度难匹配的现状，采取了相对固化硬件产品的技术状态，通过调整软件方案来实现各种研制目标，从而在有限时间内开展更多的试验。这就要求软件的开发需适应状态变化大、交付频次高、功能兼容强的研制模式。而随着航天市场竞争环境的变化，各航天器项目衍生状态多、产品交付快、进度要求紧等新常态也逐渐蔓延到了所有航天产品研制过程中，软件质量与进度的矛盾愈发激烈，复杂软件系统管理亟需采取更有效的技术管理模式与实施方法。

传统的软件系统研制依附于单机，信息传输链条冗长，各软件相互独立，为系统主动服务意识不足，针对软件系统的总体需求解读常常出现偏差，各软件在设计过程中历经多次反复，影响产品交付进度；在研制过程中，航天各项目、各任务均开展质量问题举一反三，而在该工作中各专业往往以被动的方式参与到其中，没有充分地吸收既往经验、理解准则，并应用到自己的产品中；目前航天器已形成了技术状态控制要求以及软件更改影响域分析要求，以指导配置项级软件更改影响分析，但针对软件更改对其他支撑软件、软件系统，甚至其他系统的影响推演方法目前还不完善。

为解决上述问题，航天重大工程从进度和质量两条线索入手，通过建立连接、调整结构、聚焦关键节点及核心环节，以提高研制效率和质量为目标，在现有研制模式的基础上优化流程，最终形成一种面向复杂软件系统的敏捷式精细化过程管理模型，推动了重大工程软件系统管理的科学化、系统化和规范化发展，解决了复杂系统软件按时保质交付的难题，为任务完成奠定了基础。

1 航天重大工程软件研制的特点与难点

传统的软件管理是依附于单机的管理，软件之间相互独立，软件系统设计和管理并没有作为一个重要的设计、管理环节进行系统的开展，这造成了软件的主动服务系统意识不足，总体的需求不能自顶向下有效地落实，软件设计中总体需求的落实情况、标准规范的推广情况没有得到及时的确认，软件研制经验和成果积累少，开发效率难以提升。

作为国家重大科技项目，重大工程集中体现了电气系统集成化、智能化的发展方向，由于采用“通用化硬件+定制化软件”为基本设计思路，软件实现的功能在整体系统功能的所占比重越来越高。与此同时，由于重大工程的一个重要目标是尽可能获取边界状态的试验数据，因而重大工程设计了多发次、多状态的演示验证试验，各发次验证目标具有关联性。在研发迭代周期上，新技术、新产品从不成熟到成熟的过程致使从设计到验证的迭代次数增多、迭代链条变长。在新一次任务确定后，从总体系统方案的设计到软件的实现、测试、试验等环节均需要逐步改进优化，才能达到最终较为理想的工作效果。因此，重大工程的软件对外面临的是呈爆炸式增长的软件规模和复杂度、调整范围和频率极高的技术状态变化和密集化、并行化、连续化的交付压力。

当软件规模和复杂度不断攀升、配套协作单位剧增，软件需求的传递是否失真、技术要求的执行是否到位、设计水平是否匹配等问题随之而来。信息传递是管理的基础，要求的准确传达、执行的及时反馈都依赖于信息传递的效率和效果。基础有效才能带来过程的高效。任务书、工程标准、质量标准、举一反三要求等都是以某种信息形式从顶层总体单位向下游配套单位传递；信息传递效率低以及信息失真问题带来的是进度成本，后期信息的失真带来的则是质量成本、甚至是系统功能的妥协。在人员组成上，重大工程研制初期，项目配套单位众多，各单位专业化发展不平衡，团队年轻，经验较少，导致对标准、要求理解和执行有偏差，各单位的航天经验也存在薄厚之分，从而带来质量风险，工作协同过程中，各单位工作节奏不一致也会导致潜在的进度风险。

由于航天重大工程高频的、大幅度的技术状态更改，加之需求变化的不确定性和进度的紧迫性，在软件研制工作中，每次试验的软件需要根据任务要求进行大调整；研制进度上，软件需求确认工作最早只能在前一次验证结束后、本次试验顶层方案设计基本完成时开始，整个软件系统研制的周期要求极短。因此软件需基于庞大的系统状态完成快速、全面的更改影响分析，提前协调及调度必要资源，对可能产生的进度影响进行预警，从而降低技术变更带来的管理成本。

基于上述分析，航天重大工程软件系统管理解决的重点聚焦于软件设计要求的传递、设计过程的质量控制、技术状态变更控制、设计能力统一与提升4项问题。

2 航天重大工程复杂软件系统管理的创新与实践

2.1 航天重大工程软件管理理念

航天重大工程的软件系统根据验证目标，运用多专业学科的设计方法，通过设计、研制和验证转化形成了一套满足系统全生命周期使用要求、综合最优的系统产品。因此航天软件系统研制亦是系统工程。软件系统研制的实施过程也应按照识别关键活动并制定活动流程，然后在系统工程专业技术、标准规范及工具方法等要素的支持下，开展系统工程全寿命周期活动的过程[1,2]。另一方面，软件系统管理的对象主体是软件系统的开发活动，要实现软件开发、运行、维护活动系统化、制度化、度量化。因此，针对航天器软件系统这种多专业强耦合的集成系统可以结合两种管理方式。

随着航天软件管理经验的不断积累，软件工程标准日趋完善，各软件组织开始实施软件过程改进，为与总体系统工作有机的结合，一种较为有效地做法是将软件工程化、系统工程管理和产品保证相融合[2]，实施该方法需要实现多方联动的组织架构，并尽可能降低管理成本；针对此问题，为应对需求频繁更替的现状，越来越多的软件组织偏向于在高度纪律性的规范化过程实施基础上，构建扁平化组织，在策划、控制、沟通等环节采取敏捷方法[3,4]，但实施该方法后，随即要面对的是如何使扁平化组织快速有效地做出正确的决策，而这依赖于敏捷团队的能力；面临严峻的质量、进度压力，很多企业通过组织学习的方式实现设计团队的进化[5,6]，通过组织学习可以逐步培养扁平化组织的决策、控制能力，最终实现可快速响应变化、质量可控的软件系统管理。

航天重大工程软件管理模型如图1所示。

图1 重大工程软件管理模型Fig.1 Management Concept Model of Major Aerospace Projects

该模型以信息传递的效果和效率作为工程管理基础，形成扁平化的沟通平台，以支持技术交流、规范制定、质量控制的常态化执行；依托该平台以软件关键里程碑为质量控制节点，以“敏捷沟通圆桌会议”的形式开展面向用户的任务书解读和基于专家审核的交付确认工作，加快需求确认过程并提前发现共性问题；为弥补设计师队伍技术经验不足的短板，提高一次性设计质量，积累、利用好本任务和其他任务的故障案例和设计经验，依托专家组强化故障案例总结、设计准则提炼能力，通过组织学习和针对性举一反三，让设计师充分吸收既往经验、理解准则，并应用到自己的软件产品中，在整体软件设计水平站在前人积累的基础上，全面提升软件产品质量；在研制过程中如发生了状态变化，工作重点关注反馈及时准确和影响范围控制，项目集中定期统计技术状态变更情况，提前协调及调度必要资源，对可能产生的进度影响进行预警，降低因技术变更带来的管理成本，对发生的状态更改创新性地提出了一套“十字链条”技术状态控制方法开展全要素管理要素识别。

2.2 基于自组织学习的软件队伍组织架构

重大工程通过软件总体专业牵头，以任务整体PHA分析结果、软件安全等级分析结果、配置项分布为线索，从承研软件数量及重要程度两个维度综合考虑工作组的代表人员构成，以此形成软件系统管理组织机构。

软件工作组在软件系统工作中坚持服务与统筹、连接与共享的原则。在软件工作组中不同背景的软件人员，充分地进行思想交流碰撞，取人之长补己之短，打造软件全系统融合及共享平台，互学互鉴，促进队伍整体能力提升。工作组服务系统总体目标、服务各级研制单位。立足研制痛点、细致规范开展工作，确保任务全面成功。通过统筹研制工作中的难点、统筹协调项目资源，研究过程中核心风险环节，形成一套适应项目特点的规范化软件工作程序，并落地实施。

根据上述原则，重大工程软件工作组形成了工作的职责，主要分为3项：

a）负责顶层策划与软件总体设计，负责全系统软件技术状态管理工作，负责分系统、重要单机软件验收工作，负责编写软件研制总结报告等。

b）辨识重大工程软件研制风险点，研究对策、创新方法、执行落地，针对性地开展工程化要求之外的特定工作。针对重大工程软件研制过程中的痛点，如任务书理解不一致问题、低层次重复性软件设计问题、软件技术状态控制问题，形成规范化的信息沟通、举一反三、技术状态管理等例行制度，并通过工作组牵引软件研制队伍落地开展工作。

c）组织开展技术经验交流与分享工作。

重大工程同时成立了由各单位软件专家组成的重大工程软件专家组，为重大工程软件研制提供技术支撑，协助设计师系统进行重大软件技术问题攻关，负责专项软件关键节点及归零评审、审查项目软件复查及举一反三结果、对研制过程中的重大软件技术问题提供技术支持等工作。

2.3 敏捷式扁平化软件研制信息传递模式

信息传递的效果和效率是工程管理的基础，依托软件工作组，重大工程软件系统形成了一个扁平化的沟通平台，让信息流动更加便捷有效，确保将各级配套单位的思想认识和行动标准统一，信息流动关系如图2所示。

图2 软件工作组信息传递示意Fig.2 Schematic Diagram of Information Transmission

图2的信息传递模式的优势在于扁平化组织打破了分系统、单位的壁垒，共享技术与管理信息，充分发挥软件设计师队伍的主观能动性，通过工作组的集体智慧，及时化解研制风险。通过压扁信息传递结构，软件工作组作为整个研制队伍的代表，直接与两总系统、调度与质量系统、其他专业设计师系统、第三方测评单位建立直接沟通渠道，随时沟通信息、随时反馈风险、随时解决问题。依托扁平化敏捷式的组织沟通形式可以支持常态化、例行化的专业技术交流、需求及技术状态集中监控和风险问题跟踪。

2.4 基于多域评审的软件设计过程确认方法

为彻底解决任务书理解不一致、交付后产品质量不高的问题，工作组针对此类问题频发的研制单位配套软件，策划并开展了任务解读、过程中复核、交付审核走查的“三环节”软件设计过程质量把关机制，如图3所示。

图3 “三环节”软件设计过程质量控制机制Fig.3 Quality Control Method of Software Design Process

工作组在首轮任务书及任务书更改阶段，针对上下游任务传递过程中可能出现的文档表述不一致、双方理解不一致问题，通过工作组平台，直接对接需求方和承制方集中解读，必要时邀请分系统设计人员参与解读，消除理解歧义；在设计过程中，工作组开展接口解读、可靠性安全性设计复核等工作。在设计过程中，如通过月例会分析辨识出软件技术风险点，则针对性地开展对具体软件的复核工作；在软件产品交付前开展代码走查工作。在产品正式交付前，组织工作组骨干并邀请专家组成员开展2至3天的封闭式代码走查，避免交付后出现问题。

2.5 知识环绕式软件组织资产库共享机制

航天重大工程以建设和维护组织资产库为顶层设计，将标准规范、项目经验、研制过程风险、典型案例纳入组织知识集中，工作组由专人负责外部环境知识的引入，针对引入的知识进行精细化提炼和精准化推送。

同时，为保证知识在软件设计师队伍内的循环效果，工作组采取了知识吸收效果确认的策略，防止知识衰减。在实施过程中，重大工程以举一反三为组织资产建设的切入点，建立了知识环绕式的组织资产库共享机制。

重大工程软件举一反三故障案例的收集由工作组负责，以月为周期收集故障案例，数据来源包括了其他航天器各年度的故障案例，以及通过工作组成员渠道反馈的故障案例。在每次例会安排举一反三专题，会上结合本系统软件特点，识别典型、有针对性的软件质量案例，组织集中开展学习讨论、经验分享，加深对故障案例的理解，精细化提炼举一反三要点。

在举一反三专题会中，工作组在月例会上直接明确需开展举一反三的软件配置项及责任单位，会后将举一反三要点及具体要求发全系统开展彻底的举一反三工作。软件工作组负责汇总全系统举一反三报告，并由专家组对举一反三结果进行审查。专家组对各单位举一反三工作的全面性、准确性以及针对性进行审查确认，对于不满足要求的举一反三结果，由工作组牵头督促相关单位整改到位，确保工作闭环。在质量问题数据库及相应举一反三要点梳理的基础上，为充分利用组织资产，实现应用迭代，软件工作组牵头组织各级专家及配套单位，及时梳理并确认各类设计准则，下发各单位，进一步反哺设计。

2.6 多环节关联性软件技术状态控制方法

为降低技术状态更改带来的质量风险，工作组提出了基于“十字链条”的多环节关联性软件技术状态控制方法，如图4所示。

软件技术状态控制工作需要关注监控的及时性、影响分析的全面性以及技术状态更改确认的充分性。

重大工程依托软件工作组对于A、B级软件在系统试验阶段的技术状态更改，由工作组牵头采用十字传播路径软件更改影响分析方法开展工作，十字传播路径分为水平向和垂直向，水平向以研制历程时间线描述本软件生命周期各工作环节，垂直向以软件利益相关维度描述可能受影响的方案或产品，通过十字传播路径可通过水平向确认软件平行依赖项如对设计文档、测试验证的影响，通过垂直向确认对系统功能和其他软硬件的影响。

在技术状态监控环节，软件工作组从总体层面维护全系统软件技术状态表，包括各软件任务书、软件版本、各套设备软硬件部署、待解决问题等。根据工作计划，工作组对关键里程碑节点依托系统转段、系统试验前后、出厂评审等节点，开展专家确认，对其他节点采取按月快速确认的方式监控技术状态。对产生重大变化的关键软件，工作组采用专题代码走查，进行技术状态更改确认。

图4 基于“十字链条”多环节关联性软件技术状态控制方法 Fig.4 Software Technology State Control Method based on Relevance

3 实践结果

为验证软件系统管理的目标实现情况，统计了航天重大工程中部分典型演示验证项目P、K、T型的软件过程测量数据，各任务按时间序列抽取6、3、4项子样产品的关键研制数据，按研制效率和质量数据统计形成了如下分析结果，见图5。

图5 典型项目软件质量问题数量统计Fig.5 Software Development Productivity Trends of Great Projects of Aerospace

从软件引起的质量问题数量来看，重大工程累计发生12项软件质量归零问题，其中P项目共有6批次，共发生软件质量问题8项，K项目、T项目共计15发次，软件问题仅为4项。

从软件问题的二级原因分类来看，P项目的8项问题中4项为需求问题，即与任务要求理解不一致有关，而K项目、T项目未出现一项需求问题，均为设计问题，常态化例行化的软件任务书解读工作收到了实效。

如图6所示，以全系统软件第三方测评中统计的千行代码缺陷率为测量指标，全面分析航天重大工程软件研制质量趋势，缺陷率越低，代表软件研制质量越高。

图6 航天重大工程软件研制质量趋势Fig.6 Trend of Software Defect Rate of Great Projects of Aerospace

P项目试验阶段，平均每千行代码，测评人员能发现6.4个软件缺陷，K试验阶段，随着设计过程中的质量提升工作的常态化开展，重大工程软件研制质量大幅提升，截至K项目结束代码缺陷率下降至每千行3.5个。T项目试验阶段，软件技术状态仍保持高频变化，但代码缺陷率进一步下降至每千行2.6个。与重大项目初期相比，截至到T项目，软件代码生产率提高了105%，软件缺陷率下降了59%，说明软件里程碑节点质量控制和技术状态控制策略收到了明显的成效。

如图7所示，P项目，队伍的研制效率平均约为32.4行/人天，即一名设计人员每天仅生产32.4行代码，各发次的研制效率基本变化不大，P5由于新研设备配套软件规模大、复杂度高，研制效率较低，约为29.9行/(人·天)。

图7 航天重大工程软件研制效率趋势Fig.7 Software Development Productivity Trends of Great Projects of Aerospace

K项目阶段，尽管研制工作量和研制难度陡增，但队伍在研制过程中形成了技术管理新方法并付诸实践，航天重大工程软件研制工作逐渐走出低谷，研制效率开始呈“V”字翻转，研制效率分别提升至42.3 行/(人·天)（较P项目试验阶段提升30.6%）及50.4 行/(人·天)（较P项目试验阶段提升55.6%）。

T试验阶段，队伍已全面适应新型工作模式，生产力进一步提升，代码生产率达66.7行/(人·天)，研制效率较P试验阶段提高一倍。上述数据反映出了重大工程软件研制效率和软件研制质量都有了大幅提升。软件需求准确落实、关键环节的把控和设计能力的提升推动了软件研制效率，为重大工程高质量软件产品产品快速交付提供了有利条件。

4 结束语

随着中国航天事业以及信息技术的飞速发展，软件在航天装备中所占比重越来越大，软件规模及复杂度呈指数级增长，传统的航天器软件研制理念和工作方法已难以适应新形势下“高质量、高效率、高效益”的发展要求。航天重大工程软件研制的特点与难点，已成为当前重大型号软件研制的新常态，航天重大工程的实践证明，以扁平化组织、敏捷式反应为特点的软件工作组为牵引组织全型号软件研制工作，可以有效落实软件工程化要求，缩短研制进度、提升产品质量，具有广泛的推广价值和借鉴意义。