基于DO－178B的软件配置管理技术研究*

毛 佳，胡林平

(中国航空计算技术研究所，西安710068)

1 概述

随着航空工业的飞速发展，航空软件产品的安全性与稳定性已经成为研制单位进行市场抗衡的重要砝码。而软件过程能力的高低往往对其起着决定性的作用。软件过程管理中，配置管理技术无疑又是重中之重:混乱的配置管理可以使所有软件工程师长期的心血毁于一旦;更严重者，可以造成机毁人亡。

为规范软件研发过程，提高软件产品的安全性，美国航空无线电技术委员会(RTCA)提出了DO－178B《机载系统和设备合格审定中的软件考虑》，它用于建立开发人员、安装人员和用户在使用计算机技术设计航空系统及设备时遵从的软件要求［2］。该标准并成为美国联邦航空管理局(FAA)和欧洲联合航空管理局(JAA)进行机载软件开发的标准。DO－178B采纳了由JAA所使用的五级失效状的分类模式将机载软件安全级别划分为灾难性、危险性、较重要、次要级和无影响级5个类型，并由此确立了对安全性方面的具体细则［2］。DO－178B制定了软件生命周期各个过程的目标;阐述了达到目标所应进行的活动。

软件配置管理技术主要解决的是软件开发过程中的资源管理问题［4］。它作为软件过程管理中的一项重要内容，在DO－178B中具有明确的目标与要求。本文作者在进行充分研究之后，对满足DO－178B研发过程的软件配置管理技术进行了探讨，并从实践出发，为如何开展满足DO－178B的软件配置管理活动提出了很好的建议。

2 配置管理组成

在满足DO－178B的软件研发过程中，软件配置管理过程应该涉及的活动如图1所示。其中，建立组织机构与配置库设置为其它活动的基础。

图1 软件配置管理活动组成

3 配置管理实施

3.1 组织机构

软件配置管理活动需要全体项目成员的参与。CCB(配置控制委员会)作为一个集中控制机构，它建立的目的是为了保证每个基线变更都经过项目相关成员的考虑与确认，每个变更在实施前都经过授权［5］。CCB一般由项目负责人、开发组、测试组、质量保证组、配置管理组等项目相关成员组成。

CCB应至少设置两级:系统级与项目级。系统级CCB成员中应增加硬件开发方等系统级相关人员。系统级CCB负责:需求基线、产品基线的审批以及这两类基线数据的变更;产品发布的审批。项目级CCB则负责其他基线的审批以及基线数据的更改。项目级CCB也可根据软件模块的分包情况再次细分。

多层次的CCB可以提高项目组内部解决问题的效率;而且对于涉及项目组外部的一切问题又保证了沟通的有效性及问题分析与解决的权威性。

3.2 配置库设置

配置库的设置一般有两种形式:按产品模块的划分建库和按产品建库。按产品模块的划分建库适合于工具统一、对并行开发有一定需求的大规模软件研发。这种配置库的建立模式能提高配置项的编译和发布效率。但这种库结构并不是面对整个软件产品，因此，在维护各模块版本的一致性方面成本较高。按产品建库适用于开发模式为线性的中小型专业软件的研发，维护方便，但不利于提高配置项的编译效率。配置库的设置应根据项目情况结合所使用的工具进行灵活选择、合理规划。

无论采用哪种方式进行配置库设置，都需要对不同稳定程度的数据版本进行区别控制，以防止重要版本的丢失或肆意篡改。因此，“开发库+受控库+产品库”的三库管理机制应运而生。区别于以往物理分开的三库管理，建议使用物理上的一库实现逻辑上的三库管理。三库物理统一，通过基线的创建来实现逻辑的分割。开发库负责收集所有软件研发过程中的电子数据，受控库保存基线数据。产品库保存所有产品基线。配置管理员设置配置库中的读、写权限，以维护数据的安全性与稳定性。物理一库的优势:避免由于物理上的隔离导致数据在三库间(主要是开发库与受控库)的频繁出入，减少了工作负荷，防止数据在传递过程中出错;再者，避免了为建立三库间数据的对应关系而付出的不必要成本。

3.3 配置标识及版本

配置标识主要包括:文档标识、源代码标识、产品标识。

文档标识存在于文档的封页，通常采用的标识规则为:“项目简称_文档名称_版本号”，版本号可以表示为X.Y。X和Y均为整数，它们的变化反映出变更程度的大小。

源代码是通过其电子文件的名称进行标识的。如果不同路径下存在有相同名称的代码，则可以通过“路径名+文件名”的方式对源代码进行标识。代码的版本号规则可以与技术文档的相同。

产品可以通过以下标识规则进行标识:“产品名称/产品版本号”。产品的版本号由三部分组成，即主版本号+特征版本号+修复版本号［3］。主版本号代表产品的第几代;特征版本号代表新功能的增加;而修复版本号的提升代表产品发布后对BUG的修复。

3.4 基线管理

传统的基线管理策略大都是基于瀑布式开发模型的基础上提出的:每个软件研发阶段结束即创建该阶段的基线。可这对于大规模复杂软件所采用的多模块并行开发的方式并不适用。基于此，对多模块并行开发模式的研发过程，软件生命周期所产生的数据应采用两级基线管理策略:

第一级基线(模块级基线):各功能模块在其软件生命周期的每个阶段结束时，产生该模块的相应阶段基线。

第二级基线(软件级基线):整个软件在其软件生命周期的每个阶段结束时，产生整个软件的相应阶段基线。

第二级基线由与其所处阶段一致的所有模块的第一级基线共同构成。一旦任意一个第一级基线的新版本形成，其构成的第二级基线也将自然形成新的基线版本。两级基线的管理策略有利于并行开发中各模块的状态管理:通过基线信息的描述，不但能清楚地记录整个软件各种基线及同类基线中不同版本的差别，更能对模块内各阶段的状态变迁进行详细的记录。依照两级基线策略的思想，表1列举了满足DO－178B的软件研发过程中软件生命周期的基线列表。

软件生命周期中的每条基线都应进行唯一的标识，并且基线的建立应该首先由项目负责人提交基线发布申请，经过相应级别的CCB批准后，由配置管理人员建立。

表1 软件生命周期基线列表

3.5 变更控制

满足DO－178B要求的软件研发过程中，所有基线化数据的变更都应在有效的控制下进行。项目成员可以在进行任何活动的过程中将所发现的问题在变更管理系统中以问题报告(PR)的形式进行记录。这包括开发过程，验证过程，又或者是用户使用过程。问题报告中需要记录问题发现人、问题重现步骤。问题在经过分析、解决、验证后，还应在报告中记录问题影响域以及解决方案。介于需求基线与产品基线的重要性，有关这两条基线的数据变更，进行PR分配及评审的必须是系统级CCB，而其它基线数据的变更评审则由项目级CCB执行。图2显示了满足DO－178B变更要求的变更控制工作流程。

图2 变更控制流程图

从图2中可以看出，满足DO－178B的软件变更流程较之一般软件的变更更为严格:所有变更活动均被详细记录、每个问题都会被详细评估和解决。对于评估与变更的实施也都需要经过独立性验证，项目成员可以对每个PR的任一环节进行回溯与跟踪。

3.6 软件发布

软件发布的目的是为了保证所使用的软件产品的有效性，以证明该产品是经过权威认可、授权使用的软件。软件发布应建立详细的发布规程。规程中应规定发布时机、发布申请人、批准机构、申请及审批流程。

3.7 软件归档、恢复

软件归档与恢复是为了保证与软件产品相关的生命周期数据在发生例如产品复制、重新生成、复测以及修改的需求时能够被及时恢复［1］。因此，软件的归档与恢复应建立相应规程。规程中应对数据归档及恢复的执行人、归档时机、归档媒介、媒介标识规则、归档及恢复的执行流程等内容进行约束。对于软件的归档与恢复还应该配套对应的审查机制(一般由质量保证人员执行)，以保证工作能准确有效的开展。

备份作为归档工作的一部分，能防止数据的丢失而带来工作上的损失。备份周期不宜过长，最好做到当天的增量备份以及以星期或月为单位的全量备份。备份媒介在使用时应注意完好性及可用性检查。备份媒介应一式两份，分别存放在物理距离相距较远的地方，进行防火防盗处理。

3.8 加载控制

软件加载控制的目的是为了保证加载到系统的软件是正确、完整的，且可以被完全加载的［1］。因此，开发者有必要对以下信息进行规范并详细记录:软件的加载格式、协议、加载工具、加载流程以及软件的完整性检查(包括加载媒介的标识)。通常，这些信息会作为交付文档中的重要组成部分交付给用户。

3.9 配置状态报告

配置状态报告作为配置管理活动中一个重要的环节，可以帮助项目成员了解基线配置项的状态、变更对项目进展的影响等情况。从而为开发决策提供参考依据。配置状态报告应包括的内容有:基线建立的信息，基线数据的变更及变更状态，软件产品的发行状况，对配置库的重要操作以及因为过程改进所导致的一些既定的配置管理活动的变化。

软件配置索引从某种程度上可以看作软件生命周期里所有配置状态报告的一个子集。它描述的是软件产品形成后，组成该产品的相关配置数据的信息。

3.10 软件生命周期环境控制

配置管理活动中，人们往往忽略一项重要的活动，那就是对用来开发、构建、验证以及加载软件的工具的配置控制，也称为软件生命周期环境的控制。DO－178B中对此有明确的要求［1］:即用来产生软件产品的工具必须进行标识、控制，以保证其可恢复性。项目组内，应创建专门的工具库，存放项目中使用到的所有工具及工具的不同版本。同时创建工具基线，基线中不仅包括工具软件，对于需要进行质量鉴定的工具还需包括对应的鉴定数据。

4 软件数据控制类别

在DO－178B中，软件生命周期数据可以划分为两种类型［1］:控制类别1(CC1)和控制类别2(CC2)。两种控制类别的数据在不同级别软件的配置管理活动中具有不同的要求与目标。

以DO－178B A级软件的研发过程为例，软件的五个计划(开发计划、验证计划、配置管理计划、质量保证计划、合格审定计划)、三个标准(需求标准、设计标准、编码标准)、需求、设计、源代码、可执行目标码以及开发工具的工具鉴定数据属于CC1;而软件验证结果、软件验证用例与程序、软件配置管理记录、质量保证记录、问题报告以及验证工具的质量鉴定数据属于CC2。DO－178B中对于CC1、CC2的具体配置管理目标详见标准的7.3节。

5 与DO－178B的符合性对照

表2提供了上述内容与DO－178B关于软件配置管理各项活动的符合性说明。

表2 与DO－178B的符合性对照

［1］美国航空无线电技术委员会.RTCA DO－178B—机载系统和设备合格审定中的软件考虑［S］.美国:航空无线电技术委员会，1992:45－50.

［2］陈绍宇，赵建军.RTCA DO－178B标准与相关国军标的对照分析［J］.航空电子技术，2009，40(1):48 －52.

［3］董勇.未雨绸缪理解软件配置管理［M］.北京:电子工业出版社，2008.

［4］张海波.软件配置管理及其过程实现［J］.舰船电子工程，2004，24(5):64 －68.

［5］瓦茨S汉弗莱.软件过程管理［M］.北京:清华大学出版社，2002.

6 结束语

RTCA DO－178B作为民用航空领域软件研发的标准，它的出现为提高航空软件的安全性及可靠性提供了保障。上述内容探讨了满足DO－178B软件研发过程要求的配置管理技术，详细阐述了开展各项软件配置管理活动的具体方法与策略，并提供了与DO－178B中相关要求的符合性说明，所有这些希望能为软件行业的配置管理人员提供一定的借鉴和参考。