软件配置管理的运用及优化

王 梦， 王飞飞， 刘 钰

（潍柴动力股份有限公司， 山东潍坊 261061）

CMMI是由卡内基梅隆大学软件工程研究所指定和发布的用来评价开发商过程能力和组织成熟度的一套标准， 也可以作为厂商提升产品开发过程中管理水平的参考模型。CMMI框架的模型包含CMMI服务、 CMMI开发、 CMMI采购，其中CMMI开发包含16个过程域， 配置管理过程域 （CM）为CMMI开发的核心过程域之一， 它贯穿软件开发工作全生命周期， 与软件品质有着紧密关系， 做好软件配置管理，能够有效保障软件品质。

1 配置管理内容

1.1 目的

配置管理的主要目的是保证项目和产品的整个生存周期内， 工作产品处于受控状态、 为项目参与者提供准确的信息、 实现历史版本维护、 在项目需要时能 “返回” 过去的状态， 保证产品可追溯性。

1.2 配置管理三要素

配置管理三要素： 配置项、 基线、 配置库。

1） 配置项是工作产品的集合， 可以作为单个实体进行处理， 配置项的版本和标识具有唯一性， 即一个项目中某一配置项具有唯一的版本和标识， 可采用版本树实现追溯。

2） 基线是一组正式评审通过的工作产品， 基线内的产品作为进一步开发的基础， 只有通过更改控制过程方可进行修改， 为配置项连续演变提供稳定的基础。 常见的基线有3条， 分别为功能基线、 分配基线、 产品基线。

功能基线主要包含输入至项目的协议文件与软件研制任务书文件， 功能基线的建立， 标志着需求已被理解和确认。

分配基线在功能基线基础上增加需求规格说明文件，分配基线的建立， 标志着需求已被分解为具体条目化软件需求， 可直接指导软件开发与设计。

产品基线包含分配基线及需要交付至客户的配置项，产品基线的建立， 标志着产品已通过测试及验证， 可被客户获取与使用。

3） 配置库用于存放项目生命周期中产生的配置项与数据， 是用于支持项目开发、 保护项目资产的过程资产库。 项目应当具备3 个配置库， 分别为开发库、 受控库和产品库。

开发库主要用于存放项目中所有配置项与数据项， 所有项目组成员均具有开发库的读写权限， 开发库是软件研发时项目组成员信息交互的主要场所， 应当保证其公开性。

受控库主要用于存放已通过产品测试或者评审的配置项， 作为阶段性产品的集合。 受控库需具有严格的权限管理， 通常仅有配置管理员 （执行配置管理操作的人员） 具有写权限， 项目组所有成员具有读权限， 且配置项进行受控库出入库前， 要经过项目级CCB （配置控制委员会）的审批授权， 此角色通常由本项目的项目经理承担。 此外，基线也纳入受控库进行配置管理。

产品库用于存放已定型 （鉴定） 且供交付、 生产、 检验验收的配置项。 产品库应当具有严格的权限管理， 仅有配置管理员具有产品库的读写权限， 项目组成员及客户具有读权限， 客户只具有产品库的读权限， 不具有受控库和开发库的读写权限， 以此保证开发过程对外具有保密性。只有在产品基线建立完成后， 才将产品基线内的工作产品纳入产品库进行管理。 产品库内配置项的出库及更改必需由公司级CCB进行审批授权 （一般为部门领导）， 且必需征得客户同意， 产品库内配置项出库需严格按照变更控制的要求执行。

1.3 配置管理的过程

配置管理过程主要有以下几个步骤。

1.3.1 制定 《配置管理计划》

《配置管理计划》 需按照 《软件开发计划》 中对配置管理的要求来制定， 需明确配置库、 配置项、 基线、 项目组成员权限、 配置管理工具等内容， 《配置管理计划》 经过利益相关方评审确定后， 方可由配置管理人员按照该计划内容开展配置管理活动， 若有 《配置管理计划》 发生变更，应按照变更管理要求执行， 变更后的文件在评审通过后方可生效。

1.3.2 建立并维护配置库

在建立配置库前， 应选取合适且成熟的配置管理工具，常见的配置工具有： IBM公司的ClearCase系统、 SVN系统，或其它本地化开发管理工具。 根据项目成员角色设置对应配置库的读写权限， 根据项目阶段及各过程域设置配置库结构， 并在整个项目生命周期内进行维护， 确保配置项按照配置管理要求进行管理。

1.3.3 配置项出入库及基线的建立

按照 《配置管理计划》 中明确的配置项明细与入库时机， 开展配置项入库， 并根据配置管理规程执行出库操作。 出入库申请单按配置管理规程审批通过后， 才可由配置管理员执行出入库操作， 且执行出入库前需对配置项版本、 标识、 名称和实际内容符合性进行审核， 并检查配置项是否完好无损坏。 出入库操作完成后， 需及时将出入库明细记录在配置项状态表中， 以便后续追溯配置项变更情况。

基线的建立按照 《配置管理计划》 执行， 需按照明确的时机及纳入的配置项清单完成建立。 基线建立前需要向对应的项目级CCB或公司级CCB进行申请， 申请通过后方可执行基线建立。 基线建立完成后应当进行基线发布， 可以采用邮件、 会议等方式通知利益相关方。

配置项出入库及基线建立的时机均需在配置管理体系文件中明确， 以便指导配置管理员准确执行操作。

1.3.4 配置活动审核

配置活动审核主要包含功能配置审核、 物理配置审核、配置管理审核。

1） 功能配置审核主要审核配置项的功能、 性能是否达到功能基线文件中提出的需求， 开展功能配置审核时， 可通过测试及评审结果辅助审核。

2） 物理配置审核包含入库前审核与基线建立或变更时审核。 入库前主要审核版本、 标识及配置项内容与文档是否一致且正确可用； 在基线建立及变更时开展的物理配置审核需对配置库内的配置项进行全面检查， 确保入库的配置项内容与其文档一致且正确可用。

3） 配置管理审核主要审核配置管理工作是否按配置管理相关标准与 《配置管理计划》 执行， 配置管理活动是否有效。

1.3.5 变更的控制

变更在项目开发中无法避免， 变更发生时会产生大量工程及管理工作。 由于软件是看不见摸不着， 内部又错综复杂， 配置项之间也有着密切关系， 针对变更造成的潜在影响一旦未被识别， 将会给测试、 使用、 维护造成风险和困难。 为保证项目变更有效准确进行， 必需制定变更控制规程， 并对变更影响模板进行定制式出具。 常见的变更影响分析主要考虑以下几方面： 对开发进度的影响、 对发布进度的影响、 对人员安排的影响、 对成本的影响、 对现有功能的影响、 风险分析、 对其他工作产品的影响、 对基线的影响。

2 配置管理常见问题及建议

配置管理是软件项目管理的核心， 如果配置管理工作做不好， 会造成软件开发过程中多代码多版本混乱， 无法准确地进行追溯、 增加产品返工的风险。 在配置管理工作中， 常见问题如下。

2.1 配置管理人员问题

在软件研制项目中， 部分项目任命未接受过专业培训的项目开发人员担任配置管理员， 由于该人员未经过系统学习， 缺少配置管理工作经验， 在配置管理过程中易导致配置项受控时机不准确， 配置审核有效性差， 不能及时发现问题及纠正。

建议任命经过专业培训的专人承担配管工作， 若由于人力资源紧张， 则可以由一个专业配置管理员承担多个项目的配管工作。 若缺少具备专业能力的配置管理员， 建议由项目助理或集成人员兼职， 项目助理需参与项目全生命周期， 需整体掌握项目进度及交付物情况； 集成人员在集成前需要准确提取模型代码， 需具备对配置项准确识别的能力， 并在开展系统测试前， 需有能力检查模型及代码是否完整。 此外， 项目品质保证人员需要保证对配置管理工作的审核能力， 并根据关键节点多频次、 全方位开展审核工作。

2.2 配置管理计划不合理问题

由于 《配置管理计划》 制定后评审不足， 与实际工作要求不符， 工作中未按照计划开展配置管理工作及建立基线， 导致实际工作与计划冲突， 出现未及时对计划进行变更， 漏入库或者多入库的情况。

建议软件配置管理计划完成后组织有效的同行评审，确保计划准确、 与工作实际相符。 配置管理员执行入库时需严格按照计划执行， 当计划无法满足工作实际时， 应及时对 《配置管理计划》 进行修订。 进行物理配置审核时，按照计划内容对入库的明细与计划入库明细进行对比， 确保工作产品完整入库。

2.3 变更问题

变更管理是配置管理的难点所在， 常出现问题有： 实际变更内容与申请变更内容不一致； 配置项变了， 基线未变； 变更不完整或错误； 变更审批有效性差。

建议出具专业的变更申请单及变更报告单模板， 当发生变更时， 按照模板内容进行填写、 执行评审， 明确本次变更的配置项及对应内容， 明确变更后要重新建立的基线明细， 变更后需开展的审核及对应审核的执行人员和时间。配置管理员在执行变更出库时， 应核对变更申请单和出库申请单内容， 确认无误后再执行出库操作， 变更后入库时对变更报告单及入库申请单进行核对， 确认无误后再执行入库操作。 不同类型变更由不同级别CCB审核， 并制定对应检查项列表， 审核变更时采取会议形式， 按照检查项列表逐条进行审核， 减少不必要的变更， 确保变更审批有效性。

3 结论

本文通过介绍配置管理过程的内容、 常见问题及改进建议， 旨在有效降低软件项目版本管理中存在的风险， 提升软件管理水平， 保证软件品质， 推动软件研制过程标准化， 使配置管理过程能更好地服务于科研生产。