航天软件工程化标准体系建设的实践与思考

王力文 毛宇君 丁冠期 齐宝力 张健锋

（上海机电工程研究所， 上海， 201109）

从两弹一星的研制到载人飞船、 探月工程、空间站的建立、 火星探测等项目的实施， 面对各种挑战， 进一步完善型号软件工程化工作规范，实现全周期的型号软件工程化管理， 是软件研制的一项重要工作。

国外航天软件的研制采用新技术、 新工具提升软件质量。 软件产品线提供了一套产品中管理共性和可变性的系统化方法， 是系统性软件复用的重要途径。 NASA 的LMA 软件产品线， 通过大幅度地复用软件资产， 使得需求分析周期由4个月缩短到2 周； 洛克希德·马丁的CSL 软件产品线， 近3年节约成本达1.66 亿美元[1]。

航天八院战术导弹武器系统总体设计单位（以下简称总体部） 面临型号科研生产模式变更频繁、 软件研制固有思想严重、 软件产品种类繁多、系统验证复杂等诸多挑战， 我所在落实国家军用标准 《军用软件研制能力成熟度模型》 （以下简称 《成熟度模型》） 体系本地化的工作中， 对标“三高” （高质量、 高效率、 高效益） 要求， 采取了全方位的体系建设、 全员培训、 全流程使用信息化技术、 全型号纳入体系管理的 “四全” 措施，为推动软件工程化标准体系建设积累了宝贵经验。

1 落实 《军用软件研制能力成熟度模型》本地化面临的挑战

1.1 型号科研生产模式的挑战

软件产品需求通过层层传递， 从系统总体—分系统—单机设备， 每一层级在研制中受设计状态、 产品形态、 专业约束等因素影响， 呈现变更频繁的状态； 型号各阶段工作并行， 科研生产流程中实施型号纵向分层管理， 由于变更频发最终导致策划工作落地困难。

1.2 软件研制固有模式的挑战

总体所长久以来的工作模式主要是以型号纵向牵引为主， 尤其是系统、 分系统及管理人员，对基于 《成熟度模型》 的过程管理、 软件工程等规范化和精细化要求的认识不足， 引入 《成熟度模型》 需要改变原有的工作习惯和传统思维， 在思想上和行动上都会产生很多困难。

1.3 软件产品种类繁多的挑战

软件产品种类多。 按照应用领域分为武器控制、 飞行控制、 发射控制、 仿真测试等软件； 按照软件工作方式分为实时处理软件和非实时处理软件； 按照研制类型分为研制、 批生产以及预研军贸等软件。 各类软件在质量管理、 进度要求、重用程度等方面特点各异， 落实本地化的软件研制模型分类存在一定困难。

1.4 系统验证的挑战

导弹武器系统庞大复杂， 测试试验繁多。 以软件研制任务书为代表的软件功能基线迟迟无法建立。 系统设计仿真不充分便直接开发软件产品， 导致软件在分系统、 系统级验证过程中不断迭代， 软件功能性能验证层次多， 频繁更改软件带来的风险隐患不可控。

1.5 基础架构的挑战

导弹武器系统采用架构定制， 每个配置项一条生产线， 因此导致系统级任务、 软件任务纷繁复杂， 软件产品在平台架构、 功能模块、 文档规范等方面的共性组织资产难以有效形成。

2 面向“三高” 发展的软件工程化措施

2.1 专职团队建立全方位标准体系

总体部依据 《成熟度模型》 标准要求， 结合航天软件工程化管理要求， 分3 个层次建立软件过程管理体系文件。 第一层次是 《软件过程管理手册》， 覆盖了 《军用软件研制能力成熟度模型》标准要求、 上级软件工程化管理要求， 是软件过程改进的纲领性文件， 内容包括软件过程改进的目标方针、 组织机构和职责、 过程模型、 组织验证等。 第二层次按照 《软件过程管理手册》 中规定的过程域， 识别出应编制的过程文件。 第三层次根据需要针对过程域梳理形成规程、 指南等作业指导文件。

整个体系架构中， 第一层次中， 过程类型分为过程管理、 项目管理、 工程、 支持等4 大类。根据顾客及相关方要求， 工程类开展主要研制业务， 由项目管理类进行监督管理， 由过程管理类和支持类不断提供改进意见， 审查作业流程的合规与否， 最终生成顾客及相关方满意的产品。 按照第一层的4 大类制定了第二层的过程文件， 而第三层次文件再对过程文件进行细分， 形成规程和指南文件。 如图1 所示。

根据实际工作需求， 进一步制定了作业指导书 （第四层次文件）， 如型号软件配置项测试报告作业指导书， 具体描述测试报告的格式、 模板等要求。 依据体系文件框架和实际工作， 梳理出18 个过程域、 29 份程序文件和规程文件、 13 份文档编制作业指导书、 7 类软件生命周期模型。

2.2 组织全员培训， 规范队伍建设

总体部以现行质量管理体系组织机构为基础，根据软件过程管理体系建设要求， 成立了《成熟度模型》 管理指导组 （MSC）、 软件过程改进组（EPG）、 软件配置管理委员会 （SCCB）、 质量保证组（QA）、 配置管理组 （CM）、 软件培训组， 以领导、 推进、 监督软件过程改进活动； 明确了相关部门定位、 职责， 建立了软件过程管理体系组织机构， 如图2 所示。 再按过程设置岗位， 分配职责和权限， 并结合 “走出去、 请进来” 的方式， 培训、学习、 宣贯标杆单位的实践经验， 确保岗位人员熟悉业务和顺利履职。

图2 软件过程管理体系组织机构图

2.3 软件研制全流程纳入信息平台

借助软件过程管理平台， 实现型号产品的过程管理。 组织过程改进组 （EPG） 根据产品软件类型、 规模及安全关键等级， 结合软件工程化实施经验， 将各类软件分为沿用、 参数修改、 适应性修改、 快速更改、 瀑布、 迭代、 快速开发共7种生存周期模型， 并明确了模型选择准则、 过程及文档裁剪要求。

以瀑布模型为例， 定义出软件生命周期阶段为4 个软件工程活动， 分别为需求分析与设计、项目策划、 需求分析和测试、 软件验收交付。 通过运用项目管理、 配置管理、 缺陷管理等工具，完成系统需求分析与设计、 项目策划、 制定WBS (工作分解结构)、 软件项目估计、 需求分析（细化任务书要求， 建立与研制任务书的追踪关系）、 软件设计 （定义软件单元）、 软件实现与测试、 验收与交付， 如图3 所示。 这种模型需要对照任务书明确划分软件需求， 根据需求划分子模块， 并进行单元、 组装、 配置项测试， 大多适用于产品化软件、 全新架构软件。 依据顶层管理手册文件， 软件研制变得更加井井有条， 尤其在改善需求变更过于频繁方面有了明显的成效。

图3 项目具体的评估实施过程

在管理流程方面， 如图4 所示， 以信息化平台建设为抓手， 打通管理条线间壁垒， 提高在产品研制过程中反复审查修正、 闭环缺陷的效率， 实现软件研制过程刚性管理。 同时通过与协同研制系统（Avidm4.0） 互联， 为设计师提供文档变更、 编校审流程等便利功能。 管理方式逐步走向 “智能化、网络化”， 为推进软件产品线工程奠定基础。

图4 管理流程一体化

2.4 各型号全部软件纳入体系管理

按照航天型号软件工程化要求， 软件研制类型分为I 类 （沿用）、 II （修改装订参数）、 III（适应性修改）、 IV 类 （新研）， 见表1。 结合软件本身特点， 首先建立相应的软件生命周期模型。 对于相同领域的在研型号软件、 批产型号软件、 同期多状态型号软件， 可以直接采用适应性修改/快速更改模型， 使得软件项目管理的效率显著提升。 又如多状态的飞控软件通过保留主干版本， 建立偏离产品基线， 使得偏离版本的更改更易于管理。

表1 软件研制类型与生命周期模型对照表

3 总结与展望

三级体系文件的建立与实施， 包括过程域、 程序文件和规程文件、 检查单、 作业指导书、 生命周期模型等， 完善了企业本地化过程体系和组织资产， 有效指导了软件研制。 产生的组织工作环境、重用库构件、 历年质量案例数据等组织资产也给后续的推进工作积累了宝贵经验和财富。

全方位的体系建设、 全员培训、 全流程使用信息化技术、 全型号纳入体系管理的“四全” 措施对标“三高” 要求； 通过软件研制过程管理平台， 将过程文件、 实践活动转化为信息化流程； 针对主要软件研制模型制定了详细的WBS 分解模板， 有效指导项目组开展项目策划和监控。 在完善工具、 规范软件研制过程的同时， 也有效提升了项目管理效率。

而在实际工程活动中， 完善标准体系固然不是最终目的， 而是为了提高工作效率和产品质量，软件过程改进不是一蹴而就的， 体系文件在交给各试点项目实施后会发现一些问题， 从而需要改善， 因此体系文件的改进与实施项目是相辅相成的。 接下来， 《军用软件研制能力成熟度模型》5000B 体系建设已逐步上线， 体系的创新点和难点更需要通过项目实践去挖掘和探讨。