项目配置管理规范模板.doc

项目配置管理规范

14

资料内容仅供参考，如有不当或者侵权，请联系本人改正或者删除。

卷号

卷内编号

密级

分类:
　　<规范>
使用者:
<项目组、 项目管理部>
文档编号:

©托普信息( iTOP) 集团,

软件配置管理规范

Version 2.1

技术委员会

文档信息
标题:软件配置管理规范
作者:技术委员会
创立日期: -6-20
上次更新日期: 2020/3/26 周四 2:02:44
版本:2.1

部门名称: 托普信息( iTOP) 集团

修订文档历史记录
日期
版本
说明
作者
-06-20
草稿
创立
HUI XINGHAI
-8-21
1.0
修订
HUI XINGHAI
-3-7
2.0
根据 11月的TPCA CMM3级评估报告, SEPG对当前标准软件过程进行统一修订。
SEPG
-8-28
2.1
为了托普信息( iTOP) 集团推广CMM成果, 对封面及部分内容作了调整
托普信息( iTOP) 集团技术委员会

目 录
1. 简介 1
1.1 目的 1
1.2 范围 1
1.3 文档结构 1
1.4 词汇表 1
1.5 参考信息 2
1.5.1 可追溯性 2
1.5.2 方针 2
1.5.3 过程/规范 2
1.5.4 指南 2
1.5.5 模板 2
1.5.6 检查表 2
1.5.7 培训 2
1.5.8 工具 2
1.6 参考网站 3
2. 配置管理规范 3
2.1 配置管理流程图 3
2.2 角色 3
2.3 进入准则 4
2.4 输入 4
2.5 活动 4
2.6 输出 5
2.7 验证与确认 5
2.8 退出准则 6
2.9 度量 6
3. 变更控制规范 7
3.1 变更控制流程图 7
3.2 角色 8
3.3 进入准则 8
3.4 输入 8
3.5 活动 8
3.6 输出 8
3.7 验证与确认 9
3.8 退出准则 9
3.9 度量 9
4. 参考文献 9
附录 A – 流程框图符号 10
附录B　文档命名指南 11

1. 简介
软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。
1.1 目的
本文档指导项目开展配置管理活动。
1.2 范围
本文档适用于托普信息( iTOP) 集团技术委员会批准立项的软件项目。
1.3 文档结构
第一部分:
简介, 包括本规范的目的、 范围、 词汇以及所涉及到的参考信息。
第二部分:
配置管理工作规范的正文, 包括活动的流程图、 进入以及退出准则、 所涉及的角色、 相关活动的阐述、 验证与确认以及度量。
第三部分:
变更控制工作规范的正文, 包括活动的流程图、 进入以及退出准则、 所涉及的角色、 相关活动的阐述、 验证与确认以及度量。
第四部分:
参考文献, 列出了编写本规范所参考的相关的文献资料。
第五部分:
附录, 本文中流程图的标准符号定义。
1.4 词汇表
CM( Configuration management)
配置管理。
CCB( Change control board)
变更控制委员会。
CI( Configuration item)
配置项, 包含文档、 程序。
CR( Change Request)
变更请求, 对提出的要变更工件或流程的任何请求的统称。在变更请求中记录的信息是有关当前问题、 提议解决方案及其成本的起源和影响的信息。
PCA( Physical Configuration Audit)
物理审计, 在配置管理系统中建立基线的工件是否为”正确”版本。
FCA( Functional Configuration Audit)
功能审计, 核实软件配置项的实际性能是否符合它的需求。
基线( Baseline)
已经过复审和批准的工件发布版, 由此构成进一步演进或开发的公认基础, 而且只能经过正式程序, 例如变更管理和配置控制才能进行更改。
配置管理库( Configuration Management Library)
存储项目工件的所有版本, 即存储项目的定义的配置项。
版本( Version)
某个工件的变体, 工件的后期版本一般是在初期版本的基础上进行的扩展。
1.5 参考信息
1.5.1 可追溯性
CMU/SEI-93-TR-024 Capability Maturity Model SM for Software, Version 1.1
1.5.2 方针
托普信息( iTOP) 集团项目开发与管理工作方针
1.5.3 过程/规范
项目计划与控制规范
1.5.4 指南
配置管理计划指南
基线策略指南
配置状态报告编制指南
配置审计工作活动指南
配置管理工具指南
VSS使用手册
组织管理配置库使用指南
软件开发文档命名约定
1.5.5 模板
配置管理计划
配置状态报告
配置审计报告
文档变更请求
1.5.6 检查表
无
1.5.7 培训
《软件配置管理教材》
《软件变更控制管理教材》
《Clear Case配置管理培训教材》
1.5.8 工具
Clear Case
Visual SourceSafe
Office 95/97/ /XP
1.6 参考网站
http://cdweboa/app/jswy.nsf/
2. 配置管理规范
2.1 配置管理流程图

2.2 角色
本文档在组织中实施所涉及的角色
角色名称
职责
配置管理经理
配置管理经理负责为产品开发团队提供全面的配置管理基础设施和环境, 负责制定配置管理计划, 负责对文档类的配置项建立基线, 负责基线审计, 报告配置状态。
集成员
集成员负责制定集成计划, 建立基线(程序类)。
任意角色
提交配置项。
CCB
审批基线。

2.3 进入准则
进入准则描述
· 项目立项

2.4 输入
输入名称
输入描述
参考指南、 模板
项目开发计划

只要有了项目开发计划草稿, 就能够根据项目开发计划编写配置管理计划。
项目计划与控制规范

2.5 活动
序号
活动名称
角色
活动描述
参考
1
· 计划配置管理
配置管理经理
CCB
· 制定配置管理策略
· 制定变更控制策略
· 编写配置管理计划
· 评审配置管理计划
《配置管理计划指南》

《配置管理计划》模板
2
· 创立配置管理环境
配置管理经理
· 设置硬件环境
· 设置网络环境
· 设置软件环境
建立一个配置管理库, 储存项目中定义的配置项; 安装配置管理工具, 例如: ClearCase, VSS等。
· 提供配置管理培训
《配置管理工具指南》
3
· 配置项的标识
配置管理经理

· 对文档类的配置项进行的标识,参见附录B
· 对程序(coding、 模型)的配置项进行标识
《软件开发文档命名约定》
4
· 建立基线
配置管理经理
集成员
· 标识基线: 根据配置管理计划, 对经过测试或者评审经过的工件进行标识。
· 审批基线: CCB负责召开会议, 评审配置管理经理建立的基线。
· 发布基线: 将建立的基线向相关人员发布。
《配置管理计划指南》

《基线策略指南》
5
· 报告配置状态
配置管理经理
根据配置管理计划, 收集配置活动数据, 编写配置状态报告。
《配置状态报告编制指南》

《配置状态报告》模板
6
· 执行配置审计
配置管理经理
· 根据配置管理计划定期地执行配置审计, 它包括:
物理审计
功能审计
· 编写配置审计报告
《配置审计工作活动指南》

《配置审计报告》模板
7
· 变更控制管理
CCB
任意角色
· 参见《变更控制规范》
《文档变更请求》

2.6 输出
输出名称
输出描述
参考
配置管理计划
· CM 计划说明要在项目生命周期过程中执行的所有配置和变更控制管理活动。说明了活动时间表、 指定的职责和需要的资源( 包括人员、 工具和计算机设备) 。
《配置管理计划》模板
变更请求
· 对项目当前问题说明
· 提出的变更请求内容
· CCB的复审结果
· 确认变更的结果
《文档变更请求》
配置状态报告
· 主要报告变更请求情况, 当前基于工作的工件版本以及版本说明基线的状态
《配置状态报告》模板
配置审计报告
· 对基线物理审计和功能审计进行描述。
《配置审计报告》模板

2.7 验证与确认
验证与确认名称
验证与确认细节
参考
配置计划的评审
· 高级管理者、 SQA、 项目经理参与配置管理计划的评审

阶段状态报告评审
· 高级管理者和项目组成员参与

SQA验证
· SQA对项目的变更控制流程, 配置管理流程进行审计

CCB的审计
· 对基线进行评审

配置审计
· 配置经理将配置审计结果报告给项目经理

2.8 退出准则
退出标准描述
· 项目验收经过或项目终止、 暂停

2.9 度量

3. 变更控制规范
3.1 变更控制流程图

3.2 角色
角色名称
定义/职责
CCB
复审变更请求, 确认变更请求。
任意角色
提出变更请求
项目经理
根据变更请求分配任务

3.3 进入准则
进入准则描述
· 变更请求已提交给CCB

3.4 输入
输入名称
输入描述
参考指南、 模板
配置管理计划
配置管理计划中定义了变更控制策略。
配置管理计划模板
变更请求
变更请求是一个正式提交的工件, 用于在整个项目的生命周期内跟踪所有的请求( 包括新特性、 扩展请求、 缺陷、 变更的需求等) 与相关的状态信息。
变更请求模板

3.5 活动
序号
活动名称
角色
活动描述
参考
1
· 提交变更请求
任意角色
· 任意角色填写变更请求并提交CCB。
变更请求表模板
2
· 评估变更请求
CCB
· CCB 评审会议中对变更请求的内容进行评审, 以确定它是否为有效请求。
· CCB评估影响范围并做出决定。

3
· 分配任务
项目经理
· 项目经理根据CCB批准的变更请求分配任务。

4
· 实施变更
任意角色
· 执行变更任务。
· 提交变更结果。

5
· 确认变更
CCB
· CCB确认变更是否完成, 发布变更结果。

36 输出

输出名称
输出描述
参考
变更请求
· 经过CCB评审后的变更请求
变更请求模板
变更通知
· 项目经理根据CCB评审后的变更请求, 安排指定的人员完成变更。

3.7 验证与确认
验证与确认名称
验证与确认细节
参考
变更请求评审
· CCB对变更请求进行评审, 分析其影响而且做出决定

变更确认
· CCB指派人员对完成后的变更进行确认。

SQA验证
· SQA对变更流程的实施进行审计

3.8 退出准则
退出标准描述
· 变更请求被拒绝或者变更经过确认。

3.9 度量
.
4. 参考文献
[BUC93]
Implementing Configuration Management, Hardware, Software and Firmware. Los Alamitos, CA: IEEE Computer Science Press, J. Buckley 1993.
[Rational ]
Rational Unified Process, Version , Rational Software Corporation, .附录
附录 A – 流程框图符号

Parallelograms represent inputs and outputs to or from a process/procedure.

Rectangles represent individual process/procedure activities.
Diamonds represent important decision points in the process/procedure.

Lines with arrowheads connect symbols to show the progression or direction of the activities.
Circles represent connectors when a process/procedure flowchart continues on the next page.

附录B　文档命名指南
根据公司的需要及软件工程文档命名规则GB8567中的建议, 文挡命名采用以下规则:
文挡命名由两部分构成, 格式如下:
project_filename.XXX
其中解释如下:
Project代表是项目名称的简写, 一般不超过６个字符。
Filename.XXX是文件名称。
Version代表版本号。
例如:
JDM_SCMPlan.doc表示的意义如下: JDM项目组的软件配置计划。