基于GJB 5235的软件配置管理方法初探

刘旭奕

（中国电子科技集团公司第二十九研究所，四川 成都 610036）

随着高新武器装备向“智能化”方向的发展，以及部队信息化程度的不断提高，软件在现代武器装备中的应用日趋广泛，已逐渐成为武器装备体系中的重要组成部分。

然而由于软件产品不同于硬件产品的研发特点，如软件本身的开发高风险性、易变性、抽象性、管理难度大等使软件产品质量控制的方式方法和硬件相比也有许多明显区别。

实践证明，推行软件工程化能使软件产品的质量得到很好的控制，软件工程按照GB/T 11457–2006《软件工程术语》的定义为：应用计算机科学理论和技术及工程管理的原则和方法，按预算和进度，实现满足用户要求的软件产品的定义、开发、发布和维护的工程或进行研究的学科。从这段定义中可以看出，软件工程应贯穿软件全生命周期，同时，推行软件工程离不开标准的支撑（工程管理的原则和方法）。在众多的软件工程标准中，GJB 5235–2004《军用软件配置管理》是其中一项重要的标准，因为软件配置管理作用在软件的整个生命周期，是对软件质量的一项重要的控制手段。同时软件配置管理也是推行其它软件工程方法和活动的基础。

1 软件配置管理的主要活动和任务

根据GJB 5235–2004《军用软件配置管理》的规定，软件配置管理包括的活动和任务见表1。

通过表1，可以明确软件配置管理包括的主要活动以及每个活动的主要内容。

其中，配置标识是开展后续配置管理活动的基础，而配置活动所包括的几项工作内容的具体要求都应明确在配置管理计划中。

2 实施软件配置管理的几个误区

2.1 配置管理没有软件配置管理计划

根据表1我们可以看出，开始实施软件配置管理应编写“软件配置管理计划”，该计划是后续配置管理工作的指导性文件。在计划中既要反映管什么、怎样管的问题，还要明确如何评价管得怎样的问题。GJB 5235–2004中明确规定了软件配置管理计划中应包含的各种信息，概括起来就是：

配置管理组织及其成员的责任和权限；

实施本项目配置管理的策略；

本项目配置管理的业务范围；

项目软件配置管理采用的工具和方法；

对配置标识、配置状态记录、配置审核及评审等配置管理活动的要求。

通过上面的分析，我们可以看到，配置管理计划首先要明确配置管理机构的人员组成和职责，一些项目组片面认为配置管理就是配置管理员的工作，其实在软件配置管理小组中，各类人员要互相配合、分工协作，共同担负起整个项目的软件配置管理工作。例如：软件项目的主持设计师通常也是软件配置管理小组的组长，他应对有关软件配置管理的各项工作全面负责。由于在软件开发过程中不可避免会发生软件配置项的更改，因此，对于每项更改申请，组长负有审批的职责，对于重大的更改，组长应组织评审，并对评审的结果负责。

软件项目经理负责监督在软件配置管理工作中是否认真执行软件工程规范。

项目专职的配置管理人员协助组长开展各项软件配置管理活动，负责审查所采用的配置管理工具、技术和方法，并负责汇总、维护和保存有关软件配置管理活动的各项记录。

软件开发人员根据配置管理策略创建和修改产品。

软件测试人员负责对软件产品某些特定版本进行测试，记录结果，反馈相关人员，并验证其修复情况。

只有让配置管理组中的人员各司其职，各尽其职，才能使配置管理步入健康运行的轨道。

同时，配置管理计划还要求对配置管理的范围进行明确，即需要列出配置管理的项目标识、基线标识、软件标识和软件配置项。对于基线标识，一般应具有功能基线、分配基线和产品基线，对于更加复杂的软件项目通常还应确立开发基线、实现基线和测试基线（如图1）。每一基线都是一组配置项的集合，因此通过表格的形式列出基线及其每一基线下各配置项的标识和完成时间，是配置管理的一项重要内容。有了这份标识清单就能使配置管理员对管理的对象做到心中有数，避免了“入库什么，才管理什么”的被动局面，同时也能根据配置管理计划的要求检查进度情况，实时预警，杜绝计划延迟的情况发生。因此配置管理计划是配置管理工作有条不紊进行的基础。

图1 软件开发阶段与基线

另外，配置管理计划还应明确配置控制的要点，如修改的审批权限、更改重要性的判定原则（更改的影响是否涉及全局或局部）、修改的审批程序、对第三方软件配置检查的方法、对软件开发周期各阶段配置管理工作的评审方法和检查方法以及如何存放维护并分析配置管理活动记录等内容。GJB 5235–2004中明确要求“SCM（软件配置管理）过程应接收并处理对已建立基线的软件配置项进行更改；对纳入配置控制的软件配置项和基线的更改申请均应得到标识、记录、批准/否决和跟踪。”。可以想象，如果没有对审批权限及更改流程的严格规定，没有对更改重要性的准确认定，更改随意性就难以得到有效的控制。

2.2 认为配置管理就是版本管理

从GJB 5235–2004中我们可以看到，软件的配置控制包括以下几方面的控制工作，即：

检入检出的控制；

更改控制；

版本控制；

存取控制。

因此版本控制其实只是配置控制的一部分。另外，GJB 5000–2003《军用软件能力成熟度模型》中也明确了软件配置管理的目标是使软件配置管理活动是有计划的；所选定的软件工作产品是已标识的、受控的和可用的；已标识的软件产品的更改是受控的；受影响的组和个人能接到基线的状态和内容的通知。

从这个层面上看，配置管理不仅要对软件产品本身进行控制，还要控制其影响。因为单纯的版本控制只是做到了标识变更，而真正的配置管理还包括控制变更、确保变更的正确实现以及向相关人员通知变更情况等各环节。

可见，如果对配置管理片面理解，仅认为版本管理就是配置管理，就容易产生一些负面的影响，主要表现如下。

2.2.1 软件工作产品的版本不能确保有效

软件工作产品虽然都有版本标识，它们的检入检出也都有记录，但这种记录还仅停留在“归档什么就记录什么”，“有什么就标识什么”，“你让怎样改就怎样改”的水平。试想，当某一个需求发生变更后，若仅修改需求规格说明，而不将其体现在相应的设计文档和测试文档中，即使这个需求规格说明的版本得到了很好地控制，这个需求仍然不能最终体现在软件上，那么这种变更就是无效的变更。这种控制也是无效的控制。

2.2.2 对未经认可的变更缺乏控制机制，导致软件工作产品的变更随意

软件在开发过程中，工作产品发生变更是常有的，但必须做到这个变更所涉及的相关文档及其它工作产品应同步变更，并且这个变更所导致的一系列更改不会对软件本身的功能、性能和质量产生不良影响。有了这些要求后，变更将按照特定的流程进行，而不再是设计人员的随意行为。

GJB 5235–2004中规定变更控制一般包括：更改申请、评价更改的影响、实施更改、通报处理和结束等5个步骤，即变更的触发可能因为优化的需要、本身的错误或其他输入的变化。所有这些变更需求都需要进行评估，也就是对更改所产生的影响进行分析，若同意变更则需要对变更内容和受影响范围进行确认，然后开始实施变更、必要的验证和测试并进行通报。配置管理员完成更改日志，生成更改副本。比较成熟的变更控制流程如图2所示。

根据上面的分析，我们可以看到，没有更改控制的版本控制，将导致版本变更的随意性。版本变更的随意性将最终导致软件产品质量不可控。

2.3 配置管理过程缺少评价和质量监控机制，不能实现过程持续改进

图2 变更控制流程

根据GJB 5235–2004的要求，软件配置管理应包括配置标识、配置控制、配置状态记实、配置评价、软件发行管理和交付等活动。其中的配置评价是指软件配置管理过程应通过评审和评价的方式，确保软件配置管理任务符合配置管理计划的要求，在过程中发现问题时应及时解决，及时调整（对配置管理计划的偏离）。

很明显，配置管理既然是过程的管理，那么如同其他的流程改进活动一样，配置管理在实施过程中需要经常性地检查实施的效果。对于效果差、效果不理想的项目，配置管理委员会应提出必要的改进措施，跟踪措施的实施情况直至效果达到满意的水平。可以想象，如每一个软件项目的配置管理工作都能不折不扣地做好配置评价，则将为后续的软件配置管理提供十分宝贵的经验和教训。从而不断提高组织的软件配置管理的能力和水平。反之，缺少配置评价环节，将造成开发过程中问题不能得到暴露，即使发现了问题也不能即时采取措施纠正，或者采取了措施也不能跟踪措施的实施直至问题闭环。因此这样就将造成过程管理水平长期处于原地徘徊的状态。

然而，尽管配置评价工作十分重要，但无论是GJB 5235–2004还是GJB 5000–2003，都仅给出了配置评价的工作内容，而对于评价的方法却少有提及。正是这个原因，使得一些项目团队要么没有配置评价要么使其流于形式。

要做好配置评价工作，应注意以下几点。

2.3.1 紧扣GJB 5235-2004规定的需要进行配置评价的主要内容开展工作标准中明确了需进行配置评价的主要内容为：存储在受控库中的软件配置项是否与SCM记录相符；

软件产品相对于构造软件配置项的累积状态和批准的更改而言，是否完备和可用；

基线软件配置项是否由相关的软件配置项和各自批准的更改组成。

从中我们可以看出，配置评价主要包括配置项的完整性，配置项累积过程是否完整合法，各个基线配置项的组成是否完整和合法。

找准了上述的工作重点就为后续评价工作的可操作性打下了基础。

2.3.2 针对每项内容的评价活动应具有操作性

根据配置评价内容，有针对性地制定实施细则，是保证配置评价活动具有可操作性的关键。例如：要检查配置项的完整性应通过表格的形式对比配置管理计划中所列的配置项清单和受控库中配置项的一致性。

检查配置项的累积过程是否完整合法，也可通过表格形式（如表2所示）清理受控库中各配置项版本的历史记录及其变更的手续是否齐备。条件许可的情况下可将PDM系统和软件配置管理工具结合使用，效果更好。如表2中的更改申请单号应填写在PDM中提交更改申请时系统自动分配的唯一编号。通过这个编号可以快速查询此项更改申请的处理情况。如果配置管理过程中的每一项变更都严格执行了图2所示的变更控制流程，那么版本的变更情况及其审核和评审过程将一一对应。反过来，通过这种清理我们也能发现是否有变更在未经许可的情况下得以执行。

检查各个基线配置项是否完整和合法则可采用图形和表格的形式进行检查。首先清理出项目在过程中发布过的基线有多少，每条基线下各个配置项是否齐备，版本是否完整，每个基线的发布是否手续完备。

表2 配置项变更审核情况汇总表样例

具体来说就是要做好以下几个方面的工作：

基线在生成前检查配置项是否齐备；

针对每个配置项，确认版本是否正确；

检查配置的标识和基线标识是否正确；

基线变更是否有严格的审批流程。

3 评价应经常化

配置管理是一项过程管理，这就意味着评价工作应该经常化，但怎样才能做到经常化，怎样设置质量控制点才是科学合理的呢？

通过分析软件的生命周期以及基线的定义我们可以看出，基线实质是开发过程中各工作产品某一时刻的快照，那么将检视点设置在软件开发过程中几个重要基线建立后，对监督软件产品质量将起到事半功倍的作用。因为，如图1所示的各基线是软件开发过程中的重要里程碑，这些基线的建立是开展后续工作的基础，同时在这些基线建立之前，相关的文档和软件等配置项通常会发生较频繁的变更，所以检验这些基线的建立是否完整、准确十分重要。

4 结束语

随着军用软件质量管理体系的日趋完善，人们已逐步意识到，军用软件在开发过程中的主要问题不是单纯的技术问题，更多的是管理问题，对软件质量的控制应该摒弃单纯重测试、轻设计，重结果，轻过程的错误观念和方法。软件配置管理正是有效提升软件开发质量的重要手段。由于军用软件特殊的用户和使用对象，决定了对它的配置管理工作将比一般商用软件更加严格。因此要真正搞好军用软件配置管理就需要对其中的各个环节进行深入的研究。并切实避免软件配置管理实践活动中存在的误区，在过程中严格执行GJB 5235–2004的各项要求，认真总结经验教训，持续改进，只有这样才能不断改进软件开发过程，提高过程能力成熟度，使军用软件的开发工作更加有序和高效的进行。

[1] 阮镰，陆民燕，韩峰岩等.装备软件质量和可靠性管理[M].北京：国防工业出版社, 2006.