软件能力成熟度模型在航天器软件研制中的应用研究

（北京空间飞行器总体设计部，北京 100094）

1 引言

我国航天系统较早地开展了软件工程化的研究和应用工作，原航天工业总公司在20世纪90年代中期发布了相关要求，将软件纳入航天器产品配套表，对软件进行管理［1］，同时规定了对航天器软件实施规范化的工程管理［2］。然而，随着软件复杂度和规模的不断提高，传统的软件工程化方法在保证软件质量和进度方面已显得力不从心，新的理论和方法不断地被研究和实践。

本文首先介绍“军用软件能力成熟度模型”的基本内容。然后对当前我国在航天器软件工程化推行中存在的问题进行分析，提出了将“软件能力成熟度模型”思想和内容进行本地化，以解决软件工程化推行中存在的问题，进而提升软件研制能力的相关建议。

2 软件能力成熟度模型简介

20世纪80年代，美国国防部为了评估其软件承包商的能力，委托卡内基—梅隆大学的软件工程研究所（SEI）提出了一种“软件能力成熟度模型”（CMM），1991年推出1.0版［3］，2000年升级为集成能力成熟度模型（CMM Integration，CMMI）。美国国防部要求软件承研单位的CMMI等级达到三级以上，NASA 要求航天软件的研制单位达到CMMI四级以上。2000年6月，我国国务院颁发了《鼓励软件产业和集成电路产业发展的若干政策》（18 号文件）［4］，鼓励组织实施CMMI认证。针对国防领域，2003年发布了《GJB5000-2003军用软件研制能力成熟度模型》，2008年又发布了《GJB5000A-2008军用软件研制能力成熟度模型》（简称GJB5000A），内容来源于CMMI V1.2版，略有删减［5］。

GJB5000A 中软件能力成熟度模型将软件研制能力成熟度分为5 个等级，分别是初始级、已管理级、已定义级、已定量管理级和优化级。每个成熟度等级由若干过程域组成，其中初始级不包含任何过程域；已管理级包含配置管理、测量与分析、项目监控、项目策划、过程和产品质量保证、需求管理、供方协议管理等过程域；已定义级包含决策分析和决定、集成项目管理、组织过程定义、组织过程焦点、组织培训、产品集成、需求开发、风险管理、技术解决方案、确认、验证等过程域；已定量管理级包含组织过程绩效、定量项目管理等过程域；优化级包含原因分析和决定、组织创新和部署等过程域。每个过程域由若干目标组成（包括各个过程域独自的专用目标和所有过程域都包含的共用目标），每个目标又由若干实践组成。“军用软件能力成熟度模型”对初始级组织的软件研制过程无任何要求。软件开发组织要达到除初始级之外的某个成熟度等级，除了需要实施该成熟度等级包含的过程域之外，还需实施比该成熟度等级低的所有等级所包含的过程域，当一个过程域包含的所有目标均被实现时，则认为该过程域已被实现。

笔者认为，软件能力成熟度模型的核心思想主要体现在以下几个方面：

（1）将软件开发活动的整体视为一个过程，而不只是将软件工程活动视为一个过程，即关注软件开发活动各个方面的过程化，而不仅是工程活动的过程化；

（2）重视测量数据，包括软件的规模、质量、进度等，强调用数据说话；

（3）重视组织资产的积累和应用，强调成果不归个人所有，不做重复性开发；

（4）强调本地化的实践。

3 当前航天器软件研制中存在的不足

3.1 生存周期的本地化研究和实践不足

2005年，航天科技集团公司发布了软件工程化管理要求方面的标准，对航天器软件生存周期及各阶段的管理提出了要求，其中，在软件生存周期的选择上只规定了一种“瀑布模型”，如图1所示。2013年，根据新的发展形势在多个方面对原标准进行了修订和完善，如在软件生存周期上，按继承性程度的不同提出了4类软件研制流程，但依然是基于“瀑布模型”的裁剪，其中新研软件仍采用完整“瀑布模型”。

图1 航天器软件研制“瀑布模型”技术流程Fig.1 Developing flow of spacecraft software

从图1可看出，新研软件的研制流程共分为10个阶段，顺序执行。但近年来，由于航天器整器研制周期缩短，而整器测试时间加长等原因，使得产品研制的时间大大压缩。对于硬件而言，新研产品可以通过方案阶段先期开展技术攻关，来解决研制周期不足问题；软件产品却很难做到，因为软件的需求确定较晚，往往需要到初样开始后的较长时间，而且越是技术状态新的型号，软件需求下达越晚。对于为整星各个分系统提供服务的软件（如数据管理软件），往往具有“三最”特点：需求下达最晚，软件交付给航天器最早，（交付前）软件研制周期最短。因此，往往前面的许多阶段都还未完成，就直接进入航天器测试阶段。在这种情况下，新研软件很难按照图1要求的流程开展研制活动，实际操作过程中不能按照既定的软件研制技术流程进行的现象非常普遍，使得多个阶段的工作难以落实，未发挥应有的作用。

3.2 软件开发过程的数据测量和分析不足

首先是对软件开发工作量和进度缺少可信的数据采集和分析。由于软件具有修改便利、可不断完善等特点，又由于系统联试前留给软件开发的时间不足等客观原因，导致软件在开发期间存在大量交付“半成品”的现象。同时相对于航天器研制主线而言，软件产品的开发工作易被忽视，其进度也可根据需要伸缩，在此过程中软件开发自身的工作量、进度往往没有被客观地记录，而是跟着航天器系统设计进行，最初制订的软件开发计划往往写完后即束之高阁，无法指导实际的软件开发。其次，对于各个阶段出现的问题、故障（bug）、记录和统计也很不全面，如开发方测试、分系统联试中发现的大部分问题未被记录，航天器整器测试中只分析、统计占一小部分的问题。

由于缺少对工作量、进度、质量等多方面数据的采集、统计、分析，使得某些深层次问题被掩盖。例如当前航天器软件开发遇到的一个重要问题是：软件开发未完成即交付航天器，软件质量的保证主要靠航天器整器测试。

充分的航天器整器测试是当前航天器软件质量保证的“强项”。因为一方面，测试环境与真实环境的相似度更高，这对软件问题的暴露非常有利；另一方面，当前航天器整器测试的周期变长，同时测试对软件测试的项目也大量增加，与过去相比，航天器整器测试阶段对软件功能、性能的覆盖率要高很多。

依靠航天器整器测试这个强项来确保航天器软件的质量，虽然很有效，但也存在一些问题和隐忧。

1）不利于软件规模的扩大

系统测试（如航天器整器测试）对于规模不大、逻辑不很复杂的软件，是可以保证质量的，但是对于规模庞大、逻辑复杂的软件，很可能无法保证测试的充分性，因为内部的一些逻辑可能测不到。目前的航天器软件（嵌入式）的规模还不算大（例如很少有源代码超过10万行的），逻辑也不是十分复杂，随着后续软件功能的复杂化，这种过分依赖系统测试的做法是存在隐患的。

2）不利于效率的提升

资料显示，美国军用软件的系统测试时间只占开发时间的4.8%［6］；ESA 的航天器整器测试时间也很短，主要测试接口，产品本身的质量由产品交付前的研制阶段来保证，其航天器整器测试的成本是按小时计算的。相比而言，我国航天器软件开发的时间一般为4～5个月，而航天器整器测试时间初样一般1年以上，正样一般8个月以上。

现有的做法对于软件开发而言，效率不高。因为交付前留给软件开发的时间不足，使得软件无法按照最有效的开发方法进行，只能先解决最紧迫的编码问题，其他工作产品后补；同时，由于航天器整器测试的时间非常长，在此过程中软件更改的空间很大，很容易导致需求提出方在初期不进行充分考虑，提出不正确、不合理的需求，而在测试过程中频繁修改，导致软件的不断返工。

3）不利于航天器研制流程优化

长时间的航天器整器测试，使得其研制周期较长，成为我国与国外航天器竞标中的弱项。随着市场化竞争，航天器研制周期和成本可能会进一步压缩，研制过程逐步与国际接轨，航天器整器测试时间必然要缩短。但在现有的软件研制模式下，由于软件的质量过依赖于航天器电性能测试，一旦测试时间压缩，对软件质量会造成重大影响。

3.3 软件复用的随意性大

由于软件复用缺少软件开发组织的参与，如缺少组织级的软件复用库和使用指南、复用规程等，没有指定人员对复用软件模块的质量、维护负责。航天器软件的复用往往体现出与“人”相关、与“项目”相关。与“人”相关是指只有开发人员本人能够复用其过去开发的模块，其他人不会用；与“项目”相关是指只有在两个非常相似的航天器间才会复用，而且多数情况下复用者是知其然不知所以然。这种随意性给软件复用的质量、效率都带来了不利影响。

4 应用软件能力成熟度模型解决当前问题的建议

针对前文中分析的当前航天器软件工程化实施中存在的不足，结合对软件能力成熟度模型的研究和应用，提出以下几点解决措施。

1）开发本地化生存周期模型

软件能力成熟度模型非常强调本地化，要求组织建立适合自己的可用的组织过程资产集和工作环境。例如对于生存周期模型，其明确提出“生存周期模型可以对各种顾客或各种情况开发，因为一个生存周期模型不可能适合所有情况”。针对当前新研软件的特点，笔者开发了一种“原型瀑布模型”，以实现生存周期与实际软件研制流程相符，并更好地保证交付前的软件质量（如图2所示）。

图2 原型瀑布结合模型Fig.2 Model of integrated prototype with waterfall

该模型的特点是采用目标分解法，将软件开发分成两个阶段：第一阶段，采用原型法开发，以快速实现支持系统功能检查的软件功能，满足航天器第一阶段目标；第二阶段，待原型完成交付且用户需求基本明确后，再按照瀑布模型开展研制工作，经历一个完整的开发过程，以确保软件的功能完整、性能满足要求、质量可靠，满足航天器第二阶段目标。

2）应用组织资产提升软件复用能力

软件能力成熟度模型里频繁出现的一个词是“组织资产”，要求在软件的策划、开发、测试中都要使用组织已有的资产，并将在新的开发过程中形成的代码、文件、数据、经验等纳入组织资产。软件能力成熟度模型要求被复用的资产得到管理，要保证享有权限的人员能够很方便地获取到组织资产；在具体项目中，使用了组织资产要留下记录；项目开发完成后，要提炼出组织资产提交到组织资产库。因此，软件能力成熟度模型不是简单地提出软件要“复用”的要求，而是提出了很多具体的、操作性较强的软件复用实施的方法和要求，并非常强调将其上升为组织行为，这对于提升航天器软件的复用能力，减少重复开发，提高质量和效率，具有非常重要的现实意义。

3）利用数据采集和分析发现问题本质

要解决问题、提升能力，首先要发现问题和隐患，并了解导致问题的原因。按照软件能力成熟度模型的思想，根据本单位特点对项目的进度偏离情况、发生的更改、存在的风险、资源到位情况等进行监控；同时对规模、进度、工作量、质量、变更等指标进行分解，设计多个能够表征这些指标的测量项，确定采集时机、存储方法、分析方法、采集人员、复核人员、分析人员等。对软件开发中存在的深层次问题，以“数据”为判断依据，减少凭经验、凭印象等不科学方法使用的概率。

4）重视配套设施，促进软件工程过程落实

软件工程主要关注软件工程过程，而对软件工程的辅助、支持等方面的过程关注不够，例如策划、监控、测量分析、质量保证、组织培训等，使得软件工程过程经常由于“配套设施”跟不上，导致实施困难很大。软件能力成熟度模型则更加关注软件开发活动的整体，即如何对软件开发活动的各个方面进行过程化，其中包括工程活动的过程化。实践证明，通过对项目管理、支持、过程管理等工程以外的活动也充分重视，实施过程化的管理、监控等，是工程过程实施的有力保障和促进。

5 结束语

软件能力成熟度模型提供了一整套提升软件组织能力的知识体系和方法论，是在总结优秀软件组织成功经验的基础上提炼出来的，但国外的成功经验不一定适合，因此如何做好本地化，依旧是一个难题。针对航天器软件当前存在的软件生存周期与实际研制流程不符、产品质量对航天器整器测试过于依赖等问题，本文在软件能力成熟度模型的框架下提出了4点建议，并已在一定范围内开展了应用，取得了良好的效果。

（References）

［1］刘正高.航天型号软件产品总体策划［J］.质量与可靠性，2005（6）：29-31 Liu Zhenggao.Summarily plan of aerospace software［J］.Quality and Reliability，2005（6）：29-31（in Chinese）

［2］石柱.航天型号软件工程化十年回顾与展望［J］.航天控制，2006（4）：66-72 Shi Zhu.Aerospace software engineering practice——the past ten years and the future［J］.Aerospace Control，2006（4）：66-72（in Chinese）

［3］谢超，马士龙，林梦香.新一代的过程改进模型：CMMI［J］.计算机科学，2001（8）：81-84 Xie Chao，Ma Shilong，Lin Mengxiang.A process improvement mode of next generation：CMMI［J］.Computer Science，2001（8）：81-84（in Chinese）

［4］倪光南.发展嵌入式软件对我国的重要性［J］.电子产品世界，2012（3）：11-14 Ni Guangnan.The importance of the development of embedded software industry in China［J］.Electronic Engineering ＆ Product World，2012（3）：11-14（in Chinese）

［5］倪亭.在软件研发与测试中推广GJB5000A［J］.软件，2013（2）：31-35 Ni Ting.Promote GJB5000Ain software development and testing［J］.Computer Engineering ＆ Software，2013（2）：31-35（in Chinese）

［6］Capers Jones.软件评估、基准测试与最佳实践［M］.韩柯，译.北京：机械工业出版社，2003 Capers Jones.Software assessmetnts，benchmarks，and best practices［M］.Han Ke，translated.Beijing：China Machine Press，2003（in Chinese）