软件配置管理过程指导说明书（超级实用）

软件配置管理过程指导说明书（超级实用）
软件配置管理过程指导说明书
目录
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对申请进行审批，审批通过后由配置管理员执行配置检查，然后可以建立基线。

一般项目要
建立的基线见下面的基线分类表。

基线建立后，邮件方式发布基线，填写《基线发布说明》。

注意：基线只能由配置管理员创建，建立后分配给相关干系人只读权限。

CCB审批通过后，通知配置管理员审批结果。

如果通过审批，配置管理员从开发库中取出相应的工作产品创建基线。

基线完成创建后，配置管理员填写《基线发布说明》，并通过邮件的方式通知项目组人员。

表7 基线分类表
c) 建立基线后，配置管理员要编写《配置状态报告》，将基线建立结果发布给CCB及项目组全体成
员。

5.4.5 配置变更
5.4.5.1 配置项变更
1) 出现以下情况时一般需要对配置项进行变更：
测试发现错误。

文档内容发生较大变化。

CM审计发现较大错误。

其他变更要求，如客户需求存在变化，需要增删改的需求功能等。

2) 非基线的配置项变更只要做到及时通知项目经理，由项目经理认可即可。

3) 基线创建后，如果基线所包含的工作产品要进行变更，必须提交《变更申请审批表》。

4) 变更是否执行，需要通过评审方式进行确定。

评审会议由质量工作师发起。

5) 变更的批准由CCB决定。

6) 变更的执行由项目组进行，完成后必须通过验证。

如果是技术类文档验证以评审方式进行，
所有干系人均认可当前的文档符合研发需要。

如果是代码，验证以单元测试/集成测试/合格性测试方式进行，保证当前代码的业务流程和业务逻辑测试通过。

7) 变更执行完成后，必须再次提交基线创建的申请。

5.4.5.2 基线变更
基线变更流程
8) 基线的变更来源包含两个方面的因素：
基线化的配置项发生重大的变更。

? 基线建立有误。

9) 当配置项发生重大变更时，由项目经理向CCB 提交基线变更申请，由CCB 评估并审批是否可
以对基线进行变更。

10) CCB 审批通过后，由项目组成员执行变更。

11) CCB 对变更进行审核。

12) 由配置管理员进行物理审计，并填写《配置审计报告》。

13) 配置管理员更新基线，并编写或更新《配置状态报告》。

5.4.5.3 变更影响分析
变更影响分析应当从以下方面进行分析。

1) 技术影响分析：主要考虑在总体上如何实施变更和何时实施为好。

2) 接口影响分析：识别更改要涉及到的其它配置项，并描述对其它配置项进行变更的影响，受
影响的配置项应包括各种计划。

3) 成本影响分析：分解实施变更的工作，核算实施变更所需花费的工作量，成本和其他附加资
源。

4) 进度影响分析：估计实施进度，量化对项目里程碑或交付目标日期的影响。

5) 质量影响分析：识别是否会带来不确定的高的质量风险。

5.4.5.4 变更结束准则
1) 结束变更的准则：
经验证表明变更已正确的实施；
变更未产生非预期的副作用；
有关的代码、文档和数据项已全部更新并已纳入受控库。

2) 配置管理员职责：
必要时将原基线备份，建立新的基线；
完成配置记录；
关闭变更请求，并通知变更提请人。

5.4.6 配置审计
a) 为确保配置管理工作过程的规范性，需定期进行配置审计工作
b) 基线发布前或变更后，配置管理员需要执行物理审计以保证配置项的完备性；
c) 基线发布前，由项目经理组织基线所属文件的功能审计；
d) 配置审计结果记录在《配置审计报告》中，如有问题由配置管理员统一跟踪解决直到关闭。

5.4.
6.1 基线审计
在基线发布之前，质量工程师依据《配置管理计划》，对基线内
容、基线状态登记表进行审计，以保证完整性、正确性和一致性，并维护《基线审计检查表》的记录填写。

审计要点：
1) 受控库是否包括所有计划纳入的配置项；
2) 受控库中配置项自身的内容是否完整（如：文档中所提到的参考或引用是否存在）；
3) 对于代码，要根据代码清单检查是否所有源文件都已存在于受控库；
4) 版本号命名是否规范；
5) 配置项的命名是根据软件配置管理计划规定的命名方法；
6) 基线命名是否规范；
7) 需要的配置项能否在基线库中找到；
8) 配置项是否正确标识、确定版本并记载变更历史；
9) 配置人员记录并提交统计报告。

5.4.
6.2 发布审核
软件发布中中需要进行配置审核，对发布的文档和软件进行审计。

审计要点：
1) 发行文档是否已经明确规定了发行范围；
2) 所有已经发现的缺陷或隐含差错是否均作记录；
3) 是否有文档说明了再次发行的环境；
4) 是否有文档说明了部件极其发行部件的版本情况；
5) 是否所有发行的配置项相互之间协调一致；
6) 发行的产品是否从配置仓库取出的合适版本。

5.4.
6.3 实施变更的审核
1) 所有的变更申请均已经处理了吗
2) 变更请求是否列入所有要做变更的配置项
3) 在变更请求中所有被标识要变更的配置项都已经作了变更？都作了质量控制？
4) 任何配置项的两个版本相互交换能查出来吗
5) 对配置项进行变更之前已经将变更请求文档化？
6) 对配置项进行变更之前，变更申请是否已经分析、评价和批准？
5.4.
6.4 功能审计
功能审计主要考核配置项在实现功能上的一致性，功能审计主要通过评审和测试报告体现。

具体审计项参见《配置审计报告》。

5.4.
6.5 物理审计
物理审计考查软件受控库的结构、内容及其它相关信息，以验证基线和描述它的文档的一致性，具体审计项参见《配置审计报告》。

1) 配置项是否齐备；
2) 版本是否齐全。

5.4.7 备份
配置库备份方式：配置管理员每周备份配置库，采用增量备份方式，但每两个月要完全备份一次。

6 输出
《配置管理报告》
《基线变更记录》
《基线创建申请单》
《基线发布说明》
《软件基线状态报告》
《软件基线计划》
《配置审计报告》
《基线审计检查表》
7 出口准则
项目结束并通过验收。

8 本过程裁剪规定
小型项目的配置审计可以只做发布前的审计。

? 配置库备份可配置管理人员统一执行。