1 组织机构、角色及职责
依据体系要求文件建立两级配置控制委员会：公司配置控制委员会（公司级 CCB）和项目配置控制委员会（项目级 CCB）。配置管理组
为项目级管理配置组（项目级 CM）。公司级 CCB 负责审批产品库的配置项出入库及配置项的Ⅰ类变更。项目级 CCB 负责审批软件基线建立、受控
库软件配置项出入库及Ⅰ类、Ⅱ类变更。项目负责人负责软件变更的确认及基线建立的功能配置审核。项目级 CM 负责软件项目配置库的建立和管理；建立、发布软件基线。配合项目组进行配置变更控制，并负责进行配置项入库、基线建立的物理配置审核。
2 配置管理工具、技术及方法
2.1 配置库的建立
GJB 5000B 的相关项目均使用软件配置管理系统（以下简称“系统”）进行配置管理，对于所有项目成员及相关人员，可以通过公司内局域网对配置库进行访问。
在“系统”中建立项目的配置库，配置库路径如下：
开发库：//svn/ 配置库名 /SDL
受控库：//svn/ 配置库名 /SCL
产品库：//svn/ 配置库名 /SPL
2.2 配置库的结构
项目开发库、受控库、产品库中数据的目录组织结构分别如图 1、图 2、图 3 所示。据目录结构中“管理类文档”文件夹存放开发计划、研制总结报告等管理类文档；“需求类文档”文件夹存放研制任务书、需求规格说明等需求类文档；“设计类文档”文件夹存放设计说明等文档；“测试类文档”文件夹存放单元测试计划、单元测试说明、单元测试报告等测试、集成类文档；“需方输入文档”文件夹存放项目开展必须的、由需方提供 OOP、接口文件等相关文档；“用户类文档”文件夹存放固件保障手册、版本说明、产品规格说明、验收计划、验收报告等文档。“工具”文件夹存放除公司统一管理（软件资源下载服务器）的软件资源外，其他软件开发所必须的开发环境、工具、中间件、组件等。“过程资料”文件夹存放通知单、进度表、跟踪表等相关过程资料。
项目组成员可在开发库中上传过程工作产品，工作产品完成后，可将工作产品发布，并与配置项相关联，形成待受控的工作产品。待文档类工作产品审签完成或代码类工作产品审查通过后，可申请入受控库。受控库中产品基线建立后，可申请将工作产品提交产品库。
2.3 配置库的访问权限控制
配置管理库采用多级控制机制，开发库、受控库、产品库三库逻辑分离，软件负责人与项目级 CM 确定软件项目组成员对配置库的访问权限。人员角色发生变化时，项目级 CM 进行人员权限修改。配置库的权限分配规则见表 1。
软件开发过程中，达到受控状态的配置项可纳入受控库的管理。对受控库，配置项出入库需提交申请，只有项目配置管理人员有读写权限；
项目其他人员对受控库具有只读权限，项目无关人员无权访问项目受控库。产品库只有配置管理员对产品库具有读写权限。
3 配置标识
3.1 配置项标识
配置项标识包含项目研制阶段、配置项名称、
配置项标识、受控时机等相关要素。
研制过程分为系统需求分析与策划、软件需
求分析、软件设计和软件实现、软件单元测试、
CSCI 合格性测试、软件验收与交付等阶段。
程序类配置项命名方式为：软件名称 + 程序
种类（程序种类分为源代码、可执行程序），对
应配置项标识方式为：软件标识 _ 程序种类标
识 ( 程序种类标识用英文字母表示，与程序种类
一一对应：S- 源代码，O- 可执行程序 )；文档
类配置项命名方式：软件名称 + 文档名称，对应
配置项标识方式为：软件标识 _ 文档缩略名。
配置项受控时机选择按照评审后 7 日内完成
受控。
3.2 基线标识
基线建立标识包含所属项目研制阶段、基线
名称、基线配置项、受控时机等相关要素。
各软件项目应至少建立功能基线、分配基线
和产品基线三条基线，可根据实际情况依据对设
计基线、测试基线进行裁剪；基线包含的配置项
采用向上包含的形式。
本次评价抽取的软件项目中，由于该软件未
具体应用在项目中，系统组未编制《软件研制任
务书》，以《任务通知单》代替，项目组在建立
功能基线考虑不全面，将软件需求规格说明书纳
入了功能基线，造成项目功能基线和分配基线所
包含的配置项均为需求规格说明（如图 4）。结
合评价过程评价组专家将软件项目的该实践域评
定为弱项。
经与评价专家讨论、沟通，后期类似情况可
以在体系文件中明确：“若软件无具体应用项目
等其他特殊情况下未编制《软件研制任务书》，
可将《任务通知单》代替《软件研制任务书》纳
入功能基线管理。”
基线建立时，软件负责人的配置库流程编号
管理规范（见表 2）在系统上发起基线发布申请，
并对相应基线的配置项进行功能配置审核。项目
级 CCB 审批通过后，项目级 CM 进行物理配置
审核，在受控库中建立和发布相应的基线，更新
基线配置状态报告，并通过项目会议通知利益相
关方。
4 配置控制
4.1 出入库控制
申请人在“系统”上按配置库流程编号管理
规范（见表 2）发起入库申请，软件负责人及项
目级 CCB 审批（开发库无需审批；产品库由公
司级 CCB 审批）。审批通过后，项目级 CM 进行
物理配置审核，将开发库中通过评审、审查或测
试的软件配置项入受控库，并更新配置状态报告。
当软件配置项变更或测试需提取受控库中的
配置项时，由申请人在平台上按配置库流程编号
管理规范（见表 2）发起出库申请，提交软件负
责人及项目级 CCB 审批（开发库无需审批；产
品库由公司级 CCB 审批），审批通过后执行后续
的配置项出库。
4.2 变更控制
4.2.1 变更申请
当发现软件有问题或用户提出需求变更时，
变更申请人在“系统”上发起配置项变更申请，
填写变更原因（明确变更源）、需变更的软件配
置项（变更范围）、变更类型等内容。
4.2.2 变更影响分析
软件负责人评估变更可能产生的影响和风
险，组织相关人员分析变更的必要性、可行性和
对系统的影响，并指定变更实施负责人、变更验
证人。
分析变更影响应包括：
a）自身文档的影响（例如：软件研制任务书、
软件需求规格说明、源代码等）；
b）相关内、外部模块的影响，应包含本软
件其他需求、对本系统其他 CSCI、对其他系统
的影响。
4.2.3 变更级别
配置项的变更级别分为Ⅰ类、Ⅱ类、Ⅲ类，
软件负责人根据配置项变更影响范围确定变更的
级别。
Ⅰ类配置项变更：
（1）已交付未定型的软件配置项发生更改，
导致功能基线、分配基线等基线重新建立的配置
项，致使下列任一要求发生变化的：
• 性能和功能；
• 可靠性、测试性、兼容性、安全性、保密
性等特性。
（2）已定型的软件配置项发生更改，对软件
状态有影响的配置项，并致使以下一个或多个方
面发生变化：
• 性能和功能；
• 可靠性、测试性、兼容性、安全性、保密
性等特性；
• 已交付的用户文档，包括：软件版本说明、
软件产品规格说明、软件用户手册、固件保障手
册等。
Ⅱ类配置项变更：
（1）已交付未定型软件配置项发生更改，未
导致功能基线、分配基线等基线重新建立的配置
项，对满足软件状态要求有影响；
（2）已定型的软件配置项发生更改，对软件
状态有影响的配置项，未达到 I 类配置项变更所
规定的程度；
（3）未交付未定型软件配置项发生更改，对
满足软件状态要求有影响。
Ⅲ类配置项变更：
除以上Ⅰ类、Ⅱ类变更外的变更，如勘误类、
格式类、进一步明确技术要求等不影响满足软件
质量要求的更改和补充。
4.2.4 变更审批
变更申请人将变更影响分析结果及变更类型
填入变更申请中，由软件负责人确认后，提交相
应级别的软件配置控制委员会或项目负责人审
批。配置控制委员会接收到变更申请后，进行评
估分析，找出其中可能出现的问题，对变更范围
和影响（工作量、进度、风险）进行审核，根据
分析结果，对变更做出判断，决定是否实施变更，
并根据结论审批通过或驳回更改申请流程。不同
级别配置项变更的审批要求分为：
Ⅰ类变更由公司级 CCB 和项目级 CCB 两级
审批；
Ⅱ类变更由项目级 CCB 审批；
Ⅲ类变更由软件负责人确认并审批。
4.2.5 实施及验证变更
变更实施负责人将相关配置项出库，实施变
更，变更实施完成后将变更内容填入变更申请的
“更改内容”部分，并提交变更验证人。
由验证人对变更内容进行验证并将结论填写
到“验证方案”的相应部分。
4.2.6 实施入库
配置项变更申请通过后，按配置库流程编号
管理规范（见表 2）在系统上发起入库流程，经
审核通过后，项目级 CM 对需入库的配置项进行
物理审核，审核通过后实施入库。当基线配置项
变更时，软件项目负责人需发起基线发布申请，
重新建立基线，升级基线版本。
变更正确执行并完成后，平台自动更新配置
状态报告，并形成配置项变更记录。
5 配置审核
配置审核分为物理配置审核、管理配置审核、
功能配置审核三级审核。
当软件工作产品到达受控时机，由项目成员
提交入库申请单，项目级配置管理员依据物理配
置审核检查项（检查项见表 3），对待受控配置
项执行受控前的物理配置审核。
当项目到达创建某条基线的时机，由软件负
责人提交基线建立及发布申请单，配置管理员依
据物理配置审核检查项（检查项见表 3）进行物
理审核；软件负责人依据功能配置审核检查项
（检查项见表 5），对所建立的基线配置项执行功
能配置审核。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。