生活中，电脑、手机中的软件、app伴着我们度过日出日落。同样，对于苍穹之上的卫星，星载软件也在全天全时地保障着卫星的正常运作。随着科技的飞速发展，星载软件的规模也日益扩大，在研制软件的过程中，设计师们必须要面对“软件危机”带来的挑战，不断探索实践工程化开展软件产品研制，从而保证星载软件产品质量。
“软件危机”（Software Crisis）是早期计算机科学中的一个术语，是指在软件开发及维护的过程中所遇到的一系列严重问题，这些问题都有可能导致软件产品的寿命缩短、甚至夭折。
随着技术的发展，20世纪60年代中期计算机的应用范围得到了迅速拓展。随着软件系统的规模、复杂程度不断增加，计算机程序设计的复杂度也随之提高，软件开发量激增，软件可靠性的问题也逐渐凸显。
1968年，北大西洋公约组织（NATO）在联邦德国的国际学术会议上首次提出了“软件危机（Software Crisis）”概念。会上，科学家们发现了中大型软件系统与小型软件的本质性差距，若仍保持以往个人设计、个人开发的方式便无法满足用户需求。他们急需改变软件的生产方式，提高软件的生产效率。
1972年，计算机学家艾兹赫尔·戴克斯特拉（Edsger Wybe Dijkstra）更是直言不讳地在计算机协会图灵奖演讲上强调软件危机产生的原因：“在没有机器的时候，编程根本不是问题；当我们有了计算机，编程开始变成问题，而现在我们有了巨大的计算机，编程就成了一个同样巨大的问题。”
在他发表演讲后的20余年里，Stand Group机构以美国境内的8000个软件项目为对象开展调查研究，结果显示：接受调查的软件项目中有84%的计划无法于既定的时间、经费中完成，其中超过30%的项目在运行过程中被取消，项目实际支出平均超预算189%。同样的情况也逐渐蔓延至航天软件研制领域中，1996年阿里安五号原型火箭因飞控软件故障爆炸，1998年波音Delta III火箭因导航软件失效自毁……一系列软件研制质量问题，让无数航天工作者的心血化为残烬。
▲ 计算机科学家艾兹赫尔·戴克斯特拉
软件危机在本质上指向了软件生产的客观规律性，在缺少明确的需求输入、足够的技术投入、合理的研制周期、规范的开发过程、全面的测试覆盖这些条件时，执行像星载软件这类复杂程度高、安全性可靠性要求同样高的中大型软件开发工作便成了一项高难度、高风险的生产活动。
1968年，计算机科学家们在定义软件危机的同时，也提出了“软件工程”（Software Engineering）的概念，借鉴工程化思想并重点关注技术和管理两方面研究，期以系统化、规范化的工程原则、方法和实践进行软件开发和维护。经过50多年的发展，软件工程经历了萌芽、成长、应用和发展阶段，对全球软件产业和世界经济发展起到了巨大推进作用。
我国于20世纪80年代启动软件工程的研究与实践，从起初开展方法学研究，逐步大面积部署面向对象的软件工程环境，到创新发展中大型软件构件化开发，软件工程已在星载软件研制工作中从软件研制标准、过程管控和测试覆盖三个层次融入软件生产活动，为研制高可靠高安全的星载软件保驾护航。
从两弹一星的研制到载人航天、月球探测、行星探测等重大工程的实施，软件的重要性、复杂性不断增加。面对各种挑战，进一步完善型号软件工程化工作过程，是软件研制的一项重要工作。星载软件研制标准要求从整星软件系统角度出发，预估软件规模、识别软件关键等级、分析软件产品沿用程度。以软件生命周期模型为依据，按照研制标准规定的技术流程开发星载软件，典型的开发过程是“V模型”。
▲ 星载大型软件研制V模型
如上图所示，V模型将开发过程横向分为设计和与之对应的测试阶段：左边向下的链路代表了需求分析、系统设计、概要设计、详细设计，到底层的编码实现，形成软件开发生命周期；右边向上的链路连接了单元测试、集成测试、系统测试到验收测试的流程，称为软件测试生命周期，每个设计阶段都与一个测试阶段相对应。
V模型纵向上划分了研制任务自顶向下的各个阶段，顶层需求分析、验收测试过程主要面向用户，越往底层技术工作越深入，从而构成了一个V型的模样。
敏捷开发作为一种注重快速响应、持续迭代和团队协作的开发方法，近年来在星载软件研制中也展现了独特的价值和意义。敏捷开发以“快速迭代、小步快跑”的方式，将星载软件开发过程划分为多个有明确目标和交付成果的小阶段，面对技术风险大、突发情况多的研制项目，能快速响应需求变更，减少开发过程中的资源耗费，及时调整软件研制攻坚方向，确保项目顺利推进。
▲ 敏捷开发软件研制模型
早在20世纪70年代中期，美国国防部统计数据表明，在失败的软件项目中，70%的项目是由管理不善造成的。美国国防部为解决大型软件采购风险，委托卡耐基一梅隆大学软件工程研究院制定用于软件过程改进和评估的模型，提出“软件能力成熟度模型”（Capability Maturity Model for Software），简称CMMI。
CMMI包含了大型软件从产品需求提出、设计、开发、编码、测试、交付到产品退役的整个生命周期里各项基本要素，是过程改进的有机汇集。经过40多年的发展，已经成为指导大型软件开发过程的蓝本，为包括软件企业、系统集成企业等各类组织改进其过程和提高其对产品或服务的开发、采购以及维护的能力提供指导。
▲ CMMI V2.0架构与实践域组织结构图
为提高软件研制质量和效率，持续改进软件产品线，大型软件研制团队会基于软件能力成熟度模型评估结果，确定需要改进的流程和实践，建立持续改进机制并定期审查和评估效果。NASA的LMA软件产品线通过大幅度地复用软件资产，使得需求分析周期由4个月缩短到2周；洛克希德•马丁公司的CSL软件产品线，近3年节约成本达1.66亿美元，都离不开CMMI模型持续改进的实践。
部分借鉴CMMI模型，我国围绕软件研制过程管理的需要建立了相关标准，对软件全过程的各个活动、角色及其职责关系进行具体描述，进而达到星载软件在开发实践过程中不断改进软件研制能力、提高软件成熟度的效果。
该标准定义了初始级（1级）、规范级（2级）、全面级（3级）、量化级（4级）和卓越级（5级）5个从低到高的成熟度等级，为航天软件工程化提供了一个清晰的进化路径。遵循该标准意味着星载软件研制的组织已经具备了一套完整的管理体系和技术能力，能够保证星载软件的高质量、高安全性和高可靠性。
▲ 成熟度模型等级图
星载软件研制标准和软件研制能力成熟度模型为星载软件研制提供了理想化的研制流程和流程管控方式，但实际的产品研制也会受到各类现实因素的影响，在交付验收前需要进行足够的软件测试确保符合使用要求。
软件的测试覆盖率被视为软件测试验证的“金指标”，表征了测试用例执行的代码数量在软件全部代码中的占比，以及测试用例是否真正覆盖了软件代码中的各种可能。根据测试的不同阶段，可以使用适当的测试覆盖技术衡量软件状态是否足以进入生产过程下一个环节直到最终验收交付。
常见的星载软件测试覆盖技术包括语句覆盖、分支覆盖、条件覆盖和需求覆盖。语句覆盖确保被测软件全部代码都被运行过，分支覆盖使得软件中每个判断条件取值全部遍历，条件覆盖确保软件运行各种结果都能执行，需求覆盖追溯任务要求说明软件状态和开发目标保持一致。几种策略可以共同组合，在星载软件单机级、分系统级、系统级和整星级不同层次的软件测试中充分运用，确保软件产品进行了严格、充分、完全的测试，经测试符合交付验收的要求。
▲ 软件测试覆盖示意图
来源：上海卫星
