软件配置管理过程指导说明书目录1 前言 (2)1.1 目的 (2)1.2 适用范围 (2)1.3 术语名词解释 (2)2 角色和职责说明 (3)3 输入 (4)4 入口准则 (4)5 配置管理实施 (4)5.1 配置库结构 (4)5.1.1 配置库 (4)5.1.2 配置管理库系统 (6)5.2 配置管理流程 (6)5.2.1 配置管理流程图 (6)5.2.2 配置变更流程图 (7)5.3 配置标识 (8)5.3.1 配置库划分 (8)5.3.2 配置库结构 (8)5.3.3 配置项命名 (11)5.3.4 版本编号规范 (11)5.4 配置管理活动 (12)5.4.1 制定配置管理计划 (12)5.4.2 建立配置库 (12)5.4.3 建立配置项 (12)5.4.4 基线建立及发布过程 (12)5.4.5 配置变更 (13)5.4.6 配置审计 (15)5.4.7 备份 (16)6 输出 (16)7 出口准则 (16)8 本过程裁剪规定 (16)1 前言1.1 目的用于描述配置管理作用和过程，规范配置管理的实施过程、活动和操作。

1.2 适用范围适用于在软件生命周期中对各类软件项目的配置管理活动。

1.3 术语名词解释CCB：Configuration Control Board，配置管理委员会，每个项目组需要建立项目级的CCB作为变更控制权威。

CCB由质量工程师、项目经理、测试经理、配置管理员构成，有时也可以包括客户代表、上级质量部门主管。

CCB组长可以是质量工程师或质量部领导，但不能是项目经理。

软件配置项：是指软件工程过程中所生产或使用的任何元素，或者是纳入软件产品的元素。

它可以是说明书、计算机程序、数据结构或者开发软件产品所使用的工具等，包括：项目文档，源代码，执行程序，相关设备及资料。

软件配置管理：对软件配置项的管理称为软件配置管理。

软件配置管理的目的是建立和维护软件项目整个生命周期中工作产品的完整性和可追溯性。

软件工作产品：由定义、维护和使用一个软件过程所产生的任何人工制品，包括过程描述、计划、规程、计算机程序和相关文档，无论是否打算将它们交给客户或最终用户。

软件产品：可交付给客户或最终用户的软件工作产品的子集称作软件产品基线：基线，是开发过程中标识出的里程碑所交付的一个或多个配置项，也即指一个（或一组）配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态它有如下特征：（1）已经过正式的评审和批准；（2）作为项目发展和产品升级的基础。

（3）基线变更必须经过CCB审批。

变更控制：对配置项的更改进行评价、协调、认可或不认可以及执行更改的过程。

版本发布：指从项目的配置库中将需交付给客户的所有配置项组装成一个完整的软件产品。

即交付给客户的一个包括可执行程序和文档的发布基线称为发布（release）。

配置审计：可以分为物理审计和功能审计。

物理审计审查配置项的外在特征的正确性与一致性，主要考查软件受控库的结构、内容及其它相关信息，以验证基线和描述它的文档的一致性；功能审计审查配置项内容的正确性与一致性，主要考核配置项在实现功能上的一致性，功能审计主要通过评审和测试报告体现。

物理审计的内容包括：• 确认配置项标识的正确性；• 确认已受控配置项的更改是受到控制的；• 验证配置库内容与相应记录之间的一致性；• 验证配置管理活动与相应记录之间的一致性；• 验证配置管理工作是否符合适用的标准和规程；• 验证配置管理系统与系统备份的有效性、一致性等。

功能审计的内容包括：• 验证当前基线所含配置项对前一基线所含配置项的追溯性；• 确认当前基线所含配置项均正确反映了项目需求；• 评估基线的完整性；• 验证当前基线和各基线间所含配置项的一致性；验证配置库内容的完备性和正确性等。

2 角色和职责说明表1 角色及职责3 输入《项目计划书》4 入口准则《项目计划书》已经形成文档并通过评审（项目启动会）。

5 配置管理实施5.1 配置库结构5.1.1 配置库配置管理系统支持建立和维护三库：开发库、受控库、产品库，结合实际，采用四库管理：开发库、部门受控库、组织级受控库、产品库，配置库库结构如下图所示。

表2 配置库结构配置库涉及诸多功能，主要如下：表3 配置库功能产品库组织级受控库A 部门受控库B 部门受控库C 部门受控库A 部门开发库B 部门开发库C 部门开发库产品发布基线基线基线基线基线5.1.2 配置管理库系统产品库图1 配置管理库系统5.2 配置管理流程5.2.1 配置管理流程图图2 配置管理流程图5.2.2 配置变更流程图配置管理过程输入项目经理项目成员配置管理员CCB质量工程师制定配置管理计划执行配置管理编写配置管理计划建立项目配置库提交工作成果结束开始评审配置管理计划申请建立基线执行配置审计建立并发布基线项目计划书CCB 审批批准？Yes No属于基线？配置项入受控库No配置状态跟踪协助配置审计审核配置管理活动审核产品组织产品评审Yes图3 配置变更流程图5.3 配置标识 5.3.1 配置库划分配置库分为开发库、受控库和产品库，分别标识为：1) 开发库的命名为：[01]开发库； 2) 受控库的命名为：[02]受控库； 3) 产品库的命名为：[03]产品库。

5.3.2 配置库结构每一个项目的配置库可分为：[开发库]、[受控库]；以下分别为这三个配置库的建库结构,并可以根据实际情况在《配置管理计划》中根据与项目经理或产品经理商讨结果进行增减，形成项目或产品的具体库结构分支： 5.3.2.1 开发库结构表4 开发库结构配置变更流程输入项目经理项目成员输出配置管理员CCB输入基线变更配置项变更配置项变更申请配置项变更结束开始基线变更申请执行变更验证变更变更申请及跟踪记录配置状态报告变更审批通过不通过配置审计报告批准变更更新基线配置审计通过不通过结束开始配置状态报告问题报告需求变化审核协助审计变更申请单变更跟踪记录分析后的变更申请测试报告变更后的配置项5.3.2.2 受控库结构表5 受控库结构5.3.2.3 产品库结构表6 产品库结构5.3.3 配置项命名在受控库，产品库中的配置项的命名规则如下。

a) 文档类配置项命名规则：[项目名称]_[文档名称]_[版本号]_{YYYYMMDD} “[]”：必需的；“{}”：可选的.YYYYMMDD ：为文档创建或更新的日期。

b) 源代码类配置项命名规则：[项目名称]_Src_ [版本号] _{YYYYMMDD} “[]”：必需的；“{}”：可选的.注：源代码的标识是通过配置管理工具的标签实现的。

5.3.4 版本编号规范 5.3.4.1 文档版本编号对于产品或项目生产过程中产生的技术文档的版本号管理按照以下约定进行：1) 起草版本的编号为“A0.1”、“A0.2”、“A0.3”……“A0.10”，对于未经过最终评审通过的技术文档中间版本按照此规则进行升级，如：初稿为“0.1”版，经评审进行修订后升级为“A ”版本，及提交到受控库前的版本均在“0.1”至“0.10”版本范围内进行版本号的升级； 2) 一旦文档版本得以定稿确认后（即提交到受控库后），版本编号应该始自“A ”。

在受控库中由变更引起的文档版本编号变化为：“B ”、“C ”、“D ”……“Z ”、“AA ”、“AB ”……； 3) 在B 版以后的版本上修改，未经评审的版本为：“B0.1”、“B0.2”、“B0.3”……“B0.10”。

经评审进行修订后升级为“C ”版本，以此类推。

5.3.4.2 程序版本编号1) 版本号命名格式：主版本号.子版本号.修订版本号[.编译版本号][.测试版本号]示例1：1.0.0.bd-190825-1 ：2019年8月25日编译第1版的V1.0.0版本示例2：1.0.0.bd-190825-1.test.1 ：2019年8月25日编译第1版的V1.0.0版本用于测试用第1版主版本号子版本号修订版本号X.Y.Z[.bd-xxxxxx-n][.test-测试版本号]编译版本号测试版本号编译标记符号编译日期当天编译轮次测试版本符号测试版本图4 软件版本号示例2) 版本号管理策略：(1) 项目初版本时,版本号可以为“1.0.0”；(2) 当项目在进行了局部修改或bug修正时,主版本号和子版本号都不变,修正版本号加“1”；(3) 当项目在原有的基础上增加了部分功能时,主版本号不变,子版本号加“1”,修正版本号复位为“0”；(4) 当项目在进行了重大修改或局部修正累积较多,而导致项目整体发生全局变化时,主版本号加“1”；(5) 编译版本号一般是开发设计人员在开发编译过程中使用的,按照日期，当天编译的轮次从1开始，一直到99截止，编译版本加上符号标记“bd”。

(6) 测试版本号是提供测试组进行测试时使用的，在最新编译版本上加上测试版本标记“test”，测试版本从1开始，每修改一轮在增加1，一直到99。

如：test-1、test-2标识首轮测试，首轮回归提供的版本。

(7) 正式发布出去的版本，只保留主版本号、子版本号和修订版本号，编译版本号和测试版本号去除，且修订版本号增加1.如“1.1.0.bd-190821-9.test”测试后，对外发布，版本为“1.1.1”作为发布版本。

5.3.4.3 打包标签命名规则配置项打包时标签命名规则。

5.4 配置管理活动5.4.1 制定配置管理计划a) 在项目策划阶段配置管理员起草配置管理计划，项目经理给予必要的协助。

b) 配置管理计划要进行评审，参与人员是CCB、质量工程师、项目经理及其他相关人员。

5.4.2 建立配置库a) 配置管理计划完成后，配置管理员建立项目配置库，按组织统一规定建立项目配置库目录结构，并设置访问权限。

b) 配置库建立完成后，配置管理员邮件通知项目组全员。

5.4.3 建立配置项项目成员按配置管理计划，将配置项提交到自己有权限的配置库目录内。

配置管理员每月提交配置项状态报告。

5.4.4 基线建立及发布过程a) 基线所属的配置项，全部经过同行评审并解决了评审中提出的问题，由项目经理审核后，开发设计人员填写《基线创建申请单》。

• 开发设计人员进行产品研发，阶段性工作完成后，整理工作产品。

• 开发设计人员对工作产品进行验证，文档类工作产品采用评审的方式进行验证；代码类工作产品采用单测试的方式进行验证。

• 验证通过后，填写《基线创建申请单》。

• 将《基线创建申请单》提交配置库管理工程师，配置库管理工程师将《基线创建申请单》提交CCB进行审批。

• 不会变化的东西不要纳入基线；• 变化对其他没有影响的可以不纳入基线。

b) CCB对申请进行审批，审批通过后由配置管理员执行配置检查，然后可以建立基线。