基于Qone工具的船舶软件配置管理系统设计

王 妍，董 曦

（扬州船用电子仪器研究所，江苏扬州 225101）

0 引言

使用人工方式或简单开源软件配置管理工具（如 SVN、CVS等）进行软件配置管理活动，存在着配置项易丢失、对象版本易失控、出入库不及时等缺点。因此，以上方式不利于进行大型复杂项目的软件配置管理操作。而配置管理又是 GJB 5000A—2008标准的重要组成部分，GJB 5000A—2008标准要求在整个项目的软件生命周期内建立并且维护软件产品的完整性和可追踪性。因此，船舶软件研制企业在引入Qone工具后，如何使用好其内置的配置管理功能模块进行船舶软件配置管理活动是个值得探究的课题。

1 Qone工具及配置库关联

Qone工具是一款功能齐全的软件过程管理平台，由中科方德公司研制。本文示范的Qone工具版本为5.9，内含配置管理功能。

使用配置管理功能首先需进行“配置库关联”操作。“配置库关联”操作是由系统配置管理员设置Qone工具与配置库存储工具的关联。只有实现配置库关联步骤后，才可以对配置管理软件进行出入库等操作[1]。对库信息进行配置的操作见图1。

图1 配置库信息

2 CM 过程域对配置管理系统的要求

GJB 5000A—2008二级CM过程域中专用目标SG1“建立基线”下的专用实践SP1.2为“建立一个配置管理系统”[2]。该专用实践的主要目标就是利用建立的配置管理系统，更好地对软件状态进行控制。

船舶软件研制单位为了满足该专用实践以及整个CM过程域的要求，可用Qone工具中配置管理模块实现其固有的存储、访问、变更、记录配置项的配置管理操作。然后在此基础上，定义整个船舶软件生命周期内Qone工具配置管理操作规程。将工具与规程结合，以此建立一套科学的船舶软件配置管理系统方案。

3 建立“三库”与构建配置项目录

3.1 建立“三库”

所有在生命周期内的船舶软件项目必须先建立一种管理机制，即所有软件在开发库中研制和修改、在软件受控库中版本受控、在软件产品库中进行发布。一旦变更需要分层级操作，比如：船舶软件在经过一定条件（如合格性测试等）之后，需入受控库进行版本固化，如果受控库中产品需要变更，则首先需要审批后出库至开发库中进行修改，然后再次入受控库。产品库中操作亦是如此。

“三库”之间关系见图2。

图2 “三库”关系图

软件开发库可以设立在开发人员所在单位建设的开发网中，软件受控库和软件产品库则建立在Qone工具中。此处需要说明的是，Qone工具并不是在物理上部署出三库，而是从逻辑上加以区分。Qone工具的配置管理功能及软件受控库、软件产品库的操作界面见图3。

图3 配置管理功能界面

项目组人员日常开发中所涉及的软件代码、软件文档等均应在存放于开发库中；研制过程的各个阶段性版本应保存在受控库中；经过确认的阶段性版本或最终版本转入产品库。软件产品入产品库后，受控库内容封存，除变更外，不再进行出入库操作，仅供项目有关人员检索和查阅。产品库建立后，将产品库内容刻录光盘，连同纸质文档存入档案室以备份。

3.2 构建配置项目录结构

配置项的内容包括船舶软件整个研制生命周期内的所有工作产品集，如：软件任务书、软件需求规格说明等文档；软件源代码、目标代码等工作中间过程及产品；开发工具、外协供方产品等相关内容[3]。因此在“三库”中建立1个架构清晰、方便管理、易于查询的目录结构显得尤为重要。

开发库的目录结构一般根据开发人员特点而定，不做特别要求。

受控库的目录结构通常与船舶软件开发阶段的3个基线（即功能、分配和产品基线）相一致，见图 4。如单位有特定或增加的其他基线，可以在受控库中增加相应的目录，目录下的存放内容必须符合该基线的定义和要求。

图4 受控库目录结构示意图

产品库中存放交付版本的各项工作产品，可按产品种类划分目录，见图5。

图5 产品库目录结构示意图

4 确立配置标识

配置标识是在整个软件生命周期内各软件配置项在配置管理系统中的唯一标识[4]。因此，配置标识应当遵循唯一性、可追溯性、可扩充性的原则。本系统中，配置标识包括基线配置标识、文档配置标识和代码配置标识。

基线配置标识按照船舶研制项目代号、船舶软件配置项名称、分支号、基线类型和版本号进行标识，见表1。

表1 基线配置标识

如XXX项目的XYZ配置项000分支的功能基线的基线配置标识可以标识成为XXX_XYZ_000_FBL_V1.0.00，此时，该基线的版本为V1.0.00。文档配置标识按照船舶研制项目代号、船舶软件配置项名称、分支号、文档类型和版本号进行标识，见表2。

表2 文档配置标识

如XXX项目的XYZ配置项000分支的软件需求规格说明的配置项标识可以标识成为XXX_XYZ_000_SRS_V1.0.00，此时，该文档的版本为V1.0.00。代码配置标识按照船舶研制项目代号、船舶软件配置项名称、分支号、代码类型和版本号进行标识，见表3。

表3 代码配置标识

如XXX项目的XYZ配置项000分支的软件源代码的配置项标识可以标识成为XXX_XYZ_000_SC_V1.0.00，此时，该源代码的版本为V1.0.00。

5 配置变更控制

配置变更控制其主要目的是为了严格控制受控库或产品库中配置项的任何一次变更，保证配置项的状态可控。

配置项如需变更，变更申请人需如实填写变更内容、变更理由、变更影响，并提交项目SCCB审批[5]。项目SCCB收到变更申请后，需要对变更进行影响域客观分析，主要分析此次变更对该工作产品和关联的工作产品的整个人力、物力、财力、进度、难度等影响。记录影响分析结果，并给出变更级别。项目SCCB负责人根据影响分析意见，确定变更级别、变更方案及内容，审批意见为同意变更或不同意变更。

若受控库变更申请被批准，由项目配置管理员从受控库中取出被批准更改的配置项，将配置项置于开发库，开发人员实施变更。产品库变更得到批准后，变更配置项应出产品库、入受控库、出受控库、入开发库，其中出产品库、出受控库审批手续可在一张出库单上完成，入受控库、入开发库审批手续可在一张出库单上完成。

变更活动通过验证后，变更实施人在Qone中提交入库申请，得到批准后重新提交入受控库，Qone工具对该次变更自动进行记录，更新配置项的状态，关闭此次变更。基线配置项（如软件研制任务书、软件需求规格说明等）变更时，应实施新的基线建立和发布相关过程。

6 配置审核

配置审核是检查并确认所产生的待审核产品符合制定的标准或需求，维护基线的完整性和正确性[6]。

配置审核分为3种类型：

1）物理配置审核。配置项入库、基线建立前需进行物理配置审核，其目的是验证构造的配置项是否符合定义它的技术文档，并保证软件交付版本中已进行了所有已批准的更改，所有要求的软件项目、数据和文档都包含其中。物理配置审核一般是从齐套性上去判别是否符合要求。

2）功能配置审核。功能配置审核顾名思义就是从功能和性能上验证配置项的特性是否满足需求，并且包含一套完备的操作支持文档。产品基线建立前应审核软件产品的功能特性是否达到功能基线、分配基线规定的需求。产品基线配置项变更涉及功能、性能、接口时，在基线版本升级前需执行功能配置审核。功能配置审核主要从正确性上判别是否符合要求。

3）配置管理审核。船舶软件研制单位的配置管理组长在一定周期内或某个合适的时间点，同单位的质量保证组、配置管理组成员组成临时审核小组，对配置管理系统内的软件项目进行配置管理审核。主要确认项目配置管理员的工作是否合格、项目配置管理记录是否完整、项目的配置项是否准确。

配置审核的结果应当以配置审核报告的形式提供，审核报告内容包括审核日期、审核人、项目名称、配置项名称、审核类型、被审核产品等。Qone工具中配置审核报告见图6。

图6 配置审核报告

7 结论

配置管理过程域是 GJB 5000A—2008二级非常重要的一个支持类过程域，配置管理工作的好坏在一定程度上决定了软件项目的成功与否。本文依托软件项目管理平台Qone工具，结合船舶软件研制企业的实际工作情况，设计了一种船舶软件配置管理系统。按照文中的系统架构和配置管理活动实施方案，既可覆盖GJB 5000A—2008配置管理过程域的主要活动，也可满足船舶软件研制单位本地化的实施要求。