大型军工组织的软件工厂总分厂设计模式

本文2025年4月完成，发表在《指挥信息系统与技术》2026年第1期

以下是论文正文：

0 引言

软件开发的演进历程反映了人类对复杂性管理的不懈追求。20世纪60年代，“软件危机”首次凸显[1]：大型系统开发中普遍存在预算超支、进度延误和质量失控问题。IBM System/360操作系统的开发便是典型案例——该项目软件研发耗资5亿美元（相当于现今40亿美元），交付延迟数年，初期版本存在大量缺陷[2]。这一危机催生了软件工程学科的诞生，人们开始寻求通过工程化方法解决软件开发的无序状态。

软件工程经历了从瀑布模型到迭代模型、再到DevOps（Development and Operations，开发与运维一体化）的演进，逐步应对复杂系统交付周期长、质量难控等挑战。随着网络安全问题日益突出，促使DevOps向更高安全等级的DevSecOps（Development, Security and Operations，开发、安全与运维一体化）演进[3-4]。这一理念提出“安全左移”，即在开发初期就将安全机制嵌入流程之中，确保每一次代码提交、每一次构建都具备可验证的安全性。这样，开发、安全、运维三者形成了更加紧密的协同关系。几种开发模式的比较如表1所示。

表1 软件开发过程和方法的演进[3]

模式

核心特征

局限性

瀑布模型

按阶段顺序推进，强调需求与设计文档完整性

缺乏灵活性，需求变更代价高，反馈周期长

迭代模型

以阶段性反馈为驱动，将开发流程划分为多个独立迭代，每轮均涵盖需求至测试全过程

持续资源投入较高，对项目管理与跨团队协同提出更高要求

DevOps

开发与运维深度融合，强调协同与自动化，通过持续集成与持续交付提升交付效率与系统稳定性

安全措施滞后，难以满足高合规场景需求

DevSecOps

安全能力前置，流程中集成合规审查机制

实施复杂度高，组织文化与工具集成挑战大

软件工厂是DevSecOps框架下的落地实践，以美国国防部为代表，逐步形成了具备自动化交付、安全内建和流程规范能力的样板工厂体系。而软件工厂的“总分厂”模式，更是借鉴工业制造中的总部—分厂体系结构，构建适用于大型组织的软件工程能力布局方案。该模式基于统一平台，通过分层治理、能力下沉与组件复用，探索军工单位构建可持续、可管控的软件工程体系的路径与机制。

1 美军软件工厂的组织模式研究

随着软件在现代战争中的战略地位不断提升，美国国防部（DoD）将软件开发能力的构建视为国防现代化的重要基石。为解决传统瀑布式开发周期过长、适应性不足的问题，美军逐步建立了分布式、多点布局的软件工厂体系。所谓“软件工厂”（Software Factory），最初由空军的Kessel Run（凯撒航线，美国国防部第一家软件工厂）项目提出，被定义为一种“软件装配厂”，即通过标准化工具链和流程，实现从开发、测试到部署的自动化与持续集成交付[4]。在此基础上，各军种陆续设立本军种的软件工厂，逐步形成“多点分布、横向协同”的组织模式。

空军是美军最早探索软件工厂模式的军种。自Kessel Run 成立后，空军不断扩展工厂布局，先后建立了 Kobayashi Maru（美空军软件工厂，2018年成立，负责太空感知系统）、BESPIN（美空军移动应用软件工厂，专注云端与移动解决方案）、Space Camp（美太空军软件工厂，负责太空作战指挥与控制系统开发）、Section 31（空军空间作战软件工厂）、LevelUP（美空军全军级 DevSecOps 平台）等工厂。据统计，到2021年9月，空军已经建立起17个分布式软件工厂，覆盖不同任务需求与作战场景[5-8]。这些工厂在功能定位上既各自独立、服务于特定项目，又通过共享平台工具形成联动。在空军示范效应下，其他军种迅速跟进：海军于2021年成立The Forge（美海军软件工厂），专注于舰艇作战系统软件开发[5]；陆军于2020年成立Army Software Factory（美陆军软件工厂，聚焦快速开发作战软件及培养军方开发人才），强调“士兵帮助士兵”的模式，由官兵直接参与软件研发[9]；海岸警卫队自2022年起规划设立软件工厂[5]；海军陆战队于2023年与陆军软件工厂共址运行，作为试点项目[5]。至此，美军软件工厂已从空军的单点实验，发展为跨军种、多点分布的整体格局。

然而，这一快速扩张也带来了新的挑战。公开资料显示，截至2025年，美国已有超过50家软件工厂投入运行，虽然在敏捷开发、CI/CD（Continuous Integration / Continuous Delivery，持续集成/持续交付）和 DevSecOps实践方面积累了丰富经验，但由于缺乏战略性的统筹规划，这些工厂多由军种、司令部或作战单位各自推动，呈“点状部署”态势，协同与复用能力较弱[6]。各工厂在平台选型、合规要求、安全边界与治理机制等方面标准不一，导致“重复建设”“平台割裂”问题日益突出。尽管这种差异在短期内体现了因地制宜的灵活性，但从长远看，不统一的体系将加剧资源浪费与生态碎片化。

当然美军方很早就发现了这些问题的存在，为缓解工厂间的割裂问题，空军早在2019年便组建了Platform One（美空军软件工厂，提供DevSecOps平台与工具链支持）团队，向全军开放并逐步成为DoD官方推荐的DevSecOps基础平台[7]。其核心能力包括：

• Iron Bank 容器库（美国国防部制品库，提供可信容器镜像管理与安全保障支持）：提供符合DoD安全标准的容器化镜像，供各工厂直接复用；

• 标准化流水线：帮助不同工厂快速集成 CI/CD能力，降低部署和合规成本；

通过Platform One，美军在一定程度上实现了工厂间的资源共享与基础设施统一，减少了“烟囱式”重复建设问题。但即便如此，由于建设主体多元、治理边界分散，跨工厂的深度协作依然不足。

为了解决上述问题，美军方从战略治理、政策指引到组织协同等多个层面推出了系统性举措。在战略层面，国防部设立了软件现代化高级指导小组（Software Modernization Senior Steering Group, SSG），负责顶层统筹与战略规划[10-12]。与此同时，还推动了DevSecOps社群实践（Community of Practice, CoP），作为跨军种的交流与协作平台，促进经验共享与能力对接，避免各军种工厂演化为孤立的“信息孤岛”，从而在统一战略目标下保持整体协同[13]。在政策层面，2022年2月，时任副国防部长Kathleen Hicks发布《国防部软件现代化战略》备忘录，明确要求在全军范围推广软件工厂模式，并依托标准化工具与平台实现跨工厂的可扩展性[5,14]。随后在2023年3月，国防部发布《软件现代化实施规划》，进一步提出构建全局性的软件工厂生态系统，以提升数字平台的复用率并实现规模经济[14-15]。进入2025年，国防部在《DevSecOps现状报告》中再次强调跨工厂整合的必要性，并以软件工厂联盟（Software Factory Coalition, SWFC）为案例，展示了推动工厂间联合与协作的最新实践[10]。

总体来看，美军软件工厂的组织模式体现了“分布式建设、集中式统筹”的特征。多点工厂的分布满足了不同任务的差异化需求，而统一平台与战略统筹则保障了整体协同与扩展性。这一模式不仅推动了美军的软件现代化进程，也为其他大型组织建设软件工厂提供了可参考的组织框架。

2 军工软件工厂核心组成和架构要素

软件工厂通过自动化手段替代原有的人工过程，使团队能够持续地向特定最终用户交付价值。可以形象的说：软件工厂=DevSecOps流程的自动化环境+管理与治理体系+团队与文化。在军工领域，软件工厂需支撑多源异构系统的研发需求、满足高度保密与可控的安全要求、适配多种采办路径与交付模式，因此其组成与架构要素必须高度系统化与工程化，如图1所示。

图1 软件工厂核心架构示意图
2.1 DevSecOps自动化流程与工具链集成环境

DevSecOps流程是软件工厂的骨架，它整合了开发（Dev）、安全（Sec）与运维（Ops），形成了一个持续、自动化、可审计的闭环。通过自动化工具链的集成，使需求提出、代码开发、测试验证、安全审查、构建打包、部署上线、运行监控等环节实现全流程数字化与自动化执行。关键要素包括[16]：

CI/CD流水线系统：如Jenkins、GitLab CI、Tekton等，实现代码持续集成、自动构建与版本化部署，国内军工则需选择符合信创要求的产品，如Gitee DevSecOps、华为CodeArts等。

代码管理与评审系统：统一管理代码版本与开发分支，结合代码评审流程与变更追踪机制，提供全链路代码可追溯性与合规性控制。

制品库与依赖管理：统一管理构建产物与开源依赖，结合SBOM（Software Bill of Materials，软件物料清单）与SCA（Software Composition Analysis，软件成分分析）进行软件成分分析与合规性控制。

安全扫描与合规检查工具：包括SAST（Static Application Security Testing，静态应用安全测试）、DAST（Dynamic Application Security Testing，动态应用安全测试）、IAST（Interactive Application Security Testing，交互式应用安全测试）、容器扫描、许可证检查等，实现左移安全。

运行监控平台：Prometheus+Grafana、ELK等，用于系统运行状态可视化与异常预警。

测试自动化平台：支持单元测试、接口测试、集成测试、模拟仿真测试等自动执行，并可追溯覆盖率与缺陷。

这一部分工具链的集成不应是松散拼接，而应借助标准协议，如Webhook（网络回调/事件通知接口）、API（应用程序编程接口）、OAuth（开放授权），以及统一身份认证（SSO）机制，实现平台级统一交付控制。

2.2 管理与治理体系

有效的治理体系是软件工厂稳定运行与持续改进的关键保障。尤其在军工领域，治理能力需严格对齐军用标准与安全要求，主要包括：

流程规范体系：覆盖需求、配置、版本、缺陷、发布等关键环节，参照GJB 5000B、CMMI等标准构建；

质量保障机制：设置质量门禁与阶段评审，结合MTTR、测试通过率、覆盖率、缺陷密度等指标，推动质量前置与持续改进；

安全治理体系：依据等级保护、可信计算、国密算法、软件供应链安全等要求，构建贯穿开发与运行全流程的安全控制机制；

合规与审计能力：软件工厂还需具备完善的可追溯与可审计能力，确保开发与交付过程中的关键活动均有记录可查，符合军工领域在采购、交付、质量等方面的合规性要求。

治理体系的落地不仅依赖平台工具，更有赖于流程制度与职责边界的明确，才能真正实现有序可控的工程管理。

2.3 专业团队与文化机制

软件工厂的高效运行并非依赖某一类“全能型开发者”，而是由一支多角色、分工明确的专业团队共同驱动。在统一的价值观和协作文化支撑下，团队具备持续交付、高可靠性和安全性的能力。具体包括以下几个方面：

角色体系建设：通常包括产品经理、系统架构师、开发工程师、测试人员、安全专家、运维人员等，每类角色承担明确定义的职责，共同协同完成研发任务。

能力模型与人才培养机制：建议以通行的软件工程职业能力框架为依据，如SFIA（Skills Framework for the Information Age，信息时代技能框架），构建岗位能力模型，明确能力成长路径，并配套培训课程和实训平台，推动人才可持续成长。

跨角色协作文化：强调“左移”思维（Shift-left）和“开发–安全–运维”一体化理念，打破开发过程中的信息孤岛，强化各工种在整个生命周期中的协同与共责。

知识沉淀与经验复用机制：通过建立知识库、最佳实践库、自动化模板及工具指引等方式，促进组织层面的知识积累，推动研发体系持续优化与能力复用。

3 大型军工组织软件工厂的现实挑战

我国在软件工厂建设方面也面临类似问题。当前，各大军工集团、部队院校及兵种单位依据自身任务背景开展本地化建设，形成了多点开花的局面[17-22]，往往在一个集团内各个院所按照自己的业务特点独立建设。这些做法在“用者建厂”“以战带训”的导向下，具备一定现实合理性，能够支撑特定场景下的研发需求。但由于缺乏统一建设思想与共享机制，逐渐暴露出“重复投入”“能力孤岛”“标准不一”等结构性问题。

此外，软件工厂以“平台+方法+组织”三位一体的建设模式为路径，在实践中也面临多方面挑战：

1）平台建设层面：当前在技术选型上缺乏统一标准，商用工具在涉密环境下的适配性不足，同时对开源工具的合规性评估机制尚不健全，影响了平台能力的安全性与可持续性。

2）组织机制层面：军工单位在职责划分上普遍存在“研发、测试、运维”界限模糊、权责不清等问题，管理架构层级冗余，缺乏专门的工厂治理机构和稳定的运行支撑机制。

3）系统工程视角下的变革需求：对于大型组织而言，软件工厂建设远非简单的平台部署，更是一场贯穿“人—技—制”的深层次重构。唯有在统一目标牵引下，协同推进技术体系重组、组织结构优化与流程制度再造，方能构建具备协同效能、可度量、可演进的数字化研发能力体系。

因此，要实现从“点式突破”迈向“系统建设”，必须回应三个关键问题：

1）集团和院所的关系如何厘清：是授权下放、自主建设，还是统一框架、分层治理？如何避免形成多个“孤岛式”的总厂？

2）能力复用与服务共享如何落地：工厂是否具备服务化输出的机制？是否能通过能力编排支撑跨单位、跨项目调用？

3）标准体系与评估机制如何建立：当前缺乏统一的工厂成熟度评估标准与项目数字化评估框架，难以推动健康生态的形成。

只有回答好这三个问题，才能真正将软件工厂建设从“战术性探索”上升到“战略性工程”，为打造现代化军工研发体系提供坚实支撑。

4 总分厂设计模式的提出与价值

针对上述所指出的当前军工软件工厂在平台、方法与组织三个方面存在的现实挑战，总分厂模式作为一种面向大型组织的软件工厂治理模式应运而生。其核心思想是通过“集中治理+分层赋能”的方式，将通用能力、标准规范、安全管控集中在总厂统一建设，而将业务特定、领域专精的研发活动下放至分厂独立开展。

4.1总分厂模型定义

“总分厂”设计模式借鉴工业制造中“总厂统一设计、分厂灵活制造”的模式，意图通过组织架构与平台能力的解耦，实现统一治理与业务弹性并存。

总厂作为软件工程基础设施的“总部”，承担统一平台建设、工具链选型与配置、制度规范发布、流程模板制定及效能度量体系构建等核心职责。其目标是为全组织构建一套标准化、可信赖、可复用的工程作业底座，确保各分厂研发活动在安全、质量、合规等方面的一致性。同时，总厂还负责集中化的运营管理与治理能力构建，包括DevSecOps工具链的统一认证与维护、平台版本控制、敏捷/瀑布/混合流程的标准落地机制等，支撑高效、低冗余的研发资源供给。

分厂则作为“业务子工厂”，可通过租户等模式实现自有业务的研制工作，主要聚焦于具体业务系统或武器装备的软件研发与交付任务。在继承总厂提供的工具链与流程规范的基础上，分厂可根据业务类型、作战场景、项目复杂度等差异化需求，对参数配置、插件能力、数据接口等进行适度调整，实现“统一规范下的灵活应变”。此外，分厂还可围绕自身业务积累领域组件、建立知识库、沉淀模型数据，反哺总厂形成持续优化闭环。

这种“中央管控+局部自治”的双层治理结构，有效兼顾了组织级工程一致性与业务响应的灵活性。在保障开发安全性、合规性和复用能力的同时，也为前线项目提供了足够的适配空间，推动整体研发体系的高效协同与有序演进。其逻辑关系如图2所示：

从平台建设角度：总厂统一提供平台底座，分厂按租户根据自有业务进行配置，灵活应用并反馈。

从方法体系角度：总厂制定流程模板，分厂结合业务特点适配执行。

从组织机制角度：总厂建立治理机构和度量平台，分厂提供执行数据并回流改进。

图 2 总分厂模型

4.2 总分厂的关键能力分工

在实践中，“总厂-分厂”之间的能力边界可以清晰划分，见表2。总厂能够通过平台化手段实现组织级的工程治理，而分厂则专注于业务价值的快速实现。

表2 总分厂职责分工

能力域

总厂职责

分厂职责

平台运维与安全

统一部署、维护与安全加固；统一用户认证与权限体系

配合运维策略实施本地部署要求

工具链组件管理

工具链标准选型、统一镜像、依赖源建设、插件审查

注册本地插件、申请使用新组件

流水线模板管理

流水线蓝图设计、模板版本控制、质量闸配置

在模板基础上定制化使用

度量体系定义

效能指标体系设计、统一采集点植入

输出本地度量数据

流程规范与制度

审批流程、需求状态流、缺陷生命周期规范化

按总厂制度开展流程活动

知识库与标准资产

建设知识中台、复用组件库、最佳实践文档归档

使用与反馈业务相关的最佳实践

1）平台与安全能力

总厂负责软件工厂平台底座的统一建设与运维，涵盖DevSecOps工具链的集成、标准化环境配置、统一流水线模板开发与发布机制规范等核心能力。同时，总厂制定技术架构蓝图与软件工程标准，明确编程规范、安全审计机制与过程框架，确保各分厂在研发过程中遵循一致的安全与合规要求，避免架构分裂与重复造轮子。

在安全治理方面，总厂建立可信组件库、镜像仓库与数据服务平台，推行“统一源、统一控、统一审”的依赖治理策略，确保组件来源可溯、版本可控、使用可审。以图3所示，总厂统一从互联网源或通过人工方式导入多种开发语言所需的组件资源，这些原始组件在引入时尚未经过安全验证，可能存在漏洞、恶意代码或合规风险。通过软件成分分析（SCA）工具进行自动化扫描与识别后，符合安全与合规要求的组件被归入可信组件库，构成组织内部唯一可信的依赖源，并形成可追溯的可信组件清单。为保障持续安全性，总厂定期对可信组件库进行复扫，确保漏洞可及时发现与处置。各分厂在开发过程中，仅可通过可信组件库获取所需组件。根据网络环境与资源能力的差异，总厂支持多种同步方式：对于资源丰富、具备边缘部署能力的分厂，可通过可信组件边缘节点进行就近同步；对于轻量化分厂，可按需直接远程拉取；对于无法联网的特殊场景，则支持通过光盘与人工方式进行离线导入，从而实现统一依赖源下的多模式分发机制，确保安全、稳定、高效的组件使用路径。

图3 统一可信组件库模型
2）工具链与流水线支撑

总厂侧重构建一体化DevSecOps工具链，统一提供代码托管、CI/CD流水线、度量平台等核心能力，并以“流水线模板”的形式下发。

分厂根据自身业务特点，裁剪或扩展模板，以形成符合领域特性的研发流水线，但核心环节保持一致，以保证跨组织协同的可对接性。

3）方法论与流程规范

在研发方法上，总厂承担“方法标准制定者”的角色，定义跨工厂通用的研发方法论与流程规范：

• 统一需求状态机与任务流转机制：确保需求、任务、缺陷在跨分厂间语义一致，避免信息孤岛；

• 敏捷—瀑布混合流程模板：针对军工领域典型的“需求刚性+研发复杂”的特点，总厂提供结合敏捷迭代与瀑布管控的流程蓝图，分厂可根据任务性质灵活裁剪；

• 模型驱动与状态驱动方法：推动分厂应用模型驱动工程（MDE）、状态驱动闭环机制等研发范式，使研发活动具备自动化与可执行性。

在此模式下，分厂在继承方法论和流程规范的前提下灵活落地，同时通过反馈实践经验推动总厂方法体系的持续优化，形成规范迭代的闭环。该机制类似于SAFe框架中“Shared Services（共享服务）”与“Agile Release Train（敏捷发布列车）”的配合模式[15]：平台团队定义框架与路线图，业务团队基于既定轨道灵活发布版本。

4）度量与效能管理

同时，为了加强研发过程的透明化与可评估性，总厂作为各个分厂的管理监督单元，还需牵头建设集团级的研发效能度量平台，定义度量指标体系和数据标准。核心度量维度应涵盖：研发效率（如功能交付周期）、质量稳定性（如缺陷密度）、安全风险（如静态扫描发现率）等。分厂则在此平台上依据总厂设定的标准，根据各自的研发特点，灵活的设置各自的过程指标，在日常开发活动中自动采集相关过程数据（如测试覆盖率、发布频次等），并按要求回传至度量平台。通过总分协同机制，一方面可推动平台工具与指标体系的持续优化，另一方面也有助于逐步建立统一的效能度量文化。通过多层级视图能力，既满足总部对集团整体运行态势的宏观掌控，也支持各分厂针对自身短板开展针对性改进，真正实现以数据驱动的能力跃升与持续改进。

4.3 管理协作模式与运行机制

在总分厂模式下，除了技术与平台层面的分工外，管理上的协作机制同样关键。其核心在于“统一治理、分级负责、双向反馈” 的运行逻辑：

1）统一治理与战略对齐

总厂作为核心治理中心，制定战略目标、建设路线与研发方法论，确保全局一致性。

分厂在执行过程中需将本地计划与总厂战略保持对齐，避免分散化发展。

2）分级负责与自治运行

总厂负责关键制度与安全合规的制定，并提供必要的支持与审查。

分厂在具体业务研发活动中拥有自治权，可根据业务特点灵活裁剪流程与定制流水线，但需在总厂框架内运行。

3）双向反馈与持续改进

分厂需定期回报业务需求、流程痛点与实践经验，总厂则据此对平台、方法和规范进行迭代优化。

通过“上行反馈—下行改进”的机制，推动形成可持续演进的良性循环。

4）跨分厂协同机制

对于跨单位、跨型号的联合研发，总厂负责建立统一的接口规范与沟通机制。

分厂之间通过总厂提供的知识库与标准资产进行共享与复用，从而降低重复研发成本。

5）治理工具与制度支撑

建立统一的效能度量平台与合规审计机制，使总厂能够实时掌握分厂研发态势。

通过数据化治理手段，既提升透明度，又形成科学的考核与改进依据。

4.4 总分厂模式带来的价值

总分厂模式通过平台、方法和机制的集中统一，在工程一致性、能力复用、成本控制和效能提升等方面展现出显著价值，具体体现在以下几个方面：

1）工程行为的统一与规范化提升

总厂通过统一配置平台工具、流程规范与制度体系，推动需求管理、开发、测试、交付、安全等关键环节实现标准化执行，显著降低了因流程割裂、工具异构导致的管理复杂度与协作障碍。

2）关键研发能力的规模化复用

总厂集中建设平台组件、流水线模板、分支规范模板与依赖仓库等工程资产，分厂可按需直接复用，有效缩短研发周期、降低重复建设成本。

3）运维与采购成本的系统性优化

平台底座由总厂集中部署与维护，显著减少了各分厂在系统运维上的人力消耗。统一采购工具与服务不仅提升了议价能力，也避免了资源分散、重复投入等问题。

4）效能数据的贯通与协同改进

度量体系由总厂定义核心指标与数据标准，分厂基于统一模型接入，打通横向数据链路，可快速形成全集团不同维度的度量视图，为组织持续改进、对标优化和能力跃升提供了坚实的数据支撑。

5）方法论的一致性与演进性

通过总厂主导的方法论统一和分厂反馈的迭代机制，形成“方法标准化—业务本地化—经验反哺”的循环。既避免了方法论碎片化，也保证了方法体系能够随着技术与任务环境的变化不断演进。

5 总分厂设计模式的实施要点

在大型组织推进软件工厂的总分厂模式过程中，成功落地的关键在于构建一套系统性、可执行的管理与技术支撑体系。

5.1组建“软件工程治理委员会”

“软件工程治理委员会”由总厂及主要业务单位的代表共同组成，负责统筹软件工厂的战略规划、技术路线制定、能力分层建设与资源统筹分配等核心事务。明确各分厂在使用总厂提供的工具链、模板、组件与流程规范时的继承范围与变更权限，从而在保障平台一致性的基础上，兼顾各分厂的差异化需求与业务灵活性。

5.2构建军工软件工厂的复用体系

在平台能力建设方面，总厂应优先搭建具备可复用、可组合特性的“流水线即服务（Pipeline-as-a-Service）”体系，提供模板管理、组件共享与统一度量能力，系统化沉淀核心开发框架、测试策略、部署规范等关键知识，减少分厂重复建设与工具割裂。

在多分厂协同层面，应采用租户隔离机制，确保不同分厂在权限、资源和数据使用上的相互独立，同时保留必要的自定义空间。通过建立规范的模板版本管理制度，由总厂统一规划“公共库”的授权与升级策略，防止平台模板与组件出现版本分叉。分厂如需定制，须在总库演进路径下进行管控与同步，确保分布式开发活动的有序性和一致性。

5.3强化跨区域网络的安全与互联

特别值得注意的是，在总分厂物理部署分散的背景下，跨区域网络的稳定与安全将直接影响平台能力的有效落地。因此，应将网络互联能力纳入平台底座设计，提前规划包括身份认证、数据加密、零信任访问等在内的跨区安全接入体系，保障代码同步、模板复用与指标上报等关键操作的连续性与可靠性。网络架构不仅承载平台运行，更是保障总分厂体系有效协同的前提。

6 结束语

软件工厂的“总分厂”设计模式是大型组织落地软件工厂的一种全新解决思路，为大型军工组织构建协同、高效、可持续发展的数字化研发体系奠定了方法论和架构基础。

展望未来，军工软件工厂的建设仍面临诸多课题：技术层面，需持续融合AI赋能、云原生、信创生态等前沿技术，提升平台的智能化与自主化水平；管理层面，需深化总分厂治理模型的精细度，探索更灵活的能力共享与服务化机制，构建科学的成熟度评估体系；生态层面，需推动跨集团、跨军兵种间的标准互认、能力互补与协同创新。唯有持续推进技术创新、管理优化与生态共建，方能将软件工厂真正锻造为支撑国防科技自主创新与快速响应未来作战需求的“战略引擎”。

参考文献(References)：

[1]陈宣文,马超,马倩,等.基于模型驱动构件库的飞行控制软件工厂研究[J].测控技术,2023,42(02):108-115.DOI:10.19708/j.ckjs.2022.08.294.

[2]王玲,张琨.面向互联网的软件发展——访中国科学院院士梅宏[J].高科技与产业化,2013,(08):45-51+44.

[3]张娟.软件工程与软件开发方法研究[C]//河南省民办教育协会.2024年高等教育发展论坛论文集（下册）.哈尔滨信息工程学院;,2024:308-309.DOI:10.26914/c.cnkihy.2024.009303.

[4]陈雪勇,于伟涛,张丹吉.基于DevSecOps的研发体系探索与实践[J].江苏通信,2024,40(06):44-48.

[5]Wikipedia. Kessel Run (USAF software factory). [R/OL].[2025-09-10].https://en.wikipedia.org/wiki/Kessel_Run.

[6]曹远,刘家智,黄友,等.美国防软件工厂发展现状[J].国防科技,2025,46(02):113-121.DOI:10.13943/j.issn1671-4547.2025.02.14.

[7]杨胜蓝,邓家磊,黄太奇,等.美军软件工厂关键技术分析及启示[J].指挥信息系统与技术,2025,16(01):1-8+14.DOI:10.15908/j.cnki.cist.2025.01.001.

[8]臧飞,党敏侠.美军软件工厂发展实践研究综述[J].中国军转民,2024,(17):61-63.

[9]Defense News. Army Software Factory experiments with a new culture to unleash coders in its ranks. 14 Apr 2021.[R/OL].(2021-04-14)[2025-09-10].https://www.defensenews.com/battlefield-tech/it-networks/2021/04/14/army-software-factory-experiments-with-a-new-culture-to-unleash-coders-in-its-ranks.

[10]Department of Defense.DoD Software Modernization Strategy.[R/OL].(2022-02-02)[2025-07-07].https://dodcio.defense.gov/Portals/0/Documents/Library/SoftwareModStrat.pdf.

[11]张庆海,彭程,尹瑞.美军软件现代化发展分析与启示[J].指挥信息系统与技术,2024,15(04):10-17+45.DOI:10.15908/j.cnki.cist.2024.04.002.

[12]曹远,曾令斌,黄友,等.美军软件工厂:模式、案例及启示[J].国防科技,2024,45(6):92-101,DOI:10.13943/j.issn1671-4547.2024.06.13.

[13]Department of Defense.Software Modernization Implementation Plan FY25–26.[R/OL].[2025-09-10]https://https://dodcio.defense.gov/Portals/0/Documents/Library/SW-Mod-I-Plan25-26.pdf.

[14]陈梅,孙茂,李南.美国国防部软件现代化战略（译文）[J].信息安全与通信保密,2022,(04):34-43.

[15]邢月亭,朱天宜,王阳阳,等.美国《国防部软件现代化实施规划》报告解读[J].军民两用技术与产品,2023,(08):20-24.DOI:10.19385/j.cnki.1009-8119.2023.08.003.

[16]子牙.DevSecOps敏捷安全[M].北京:机械工业出版社,2022.7.

[17]航天科工二院二部.二部：软件“研发流水线”，转型升级新动能——二十室“软件工厂”党员责任田攻关侧记.[EB/OL].(2024-11-05).https://mp.weixin.qq.com/s/QaYdUV55UKJep4bmUsvvGQ.

[18]中国船舶709所.【“深思”（DeepThink）第五季来了】DeepThink助力软件工厂模式转型.[EB/OL].(2025-02-21).https://mp.weixin.qq.com/s/LIqAxtvm92zU20Y1iVM-hw.

[19]中电太极集团.“平台化战略”加速度|电科太极/15所召开“太极”软件工厂全面应用动员会.[EB/OL].(2025-05-23).https://mp.weixin.qq.com/s/SShjI0Mw4dbSKU1Ojjt1kg.

[20]电科智能.智能院成功举办“智能软件工厂”技术研讨会.[EB/OL].(2024-07-23).https://mp.weixin.qq.com/s/ZarVEPadMsmGZE61Mg_a7w.

[21]刘昌磊.基于SAFe框架的J公司新能源汽车软件开发流程优化研究[D].北京邮电大学,2024.DOI:10.26969/d.cnki.gbydu.2024.003073.

[22]一部党建.新突破！航天软件研发迈入“工厂化”智造.[EB/OL].(2025-12-19).https://mp.weixin.qq.com/s/FpQ3tElBC-PMWA2SeoVpFw.