软件配置管理规范

  • 格式:docx
  • 大小:186.59 KB
  • 文档页数:13

Word 文档资料

文件编号: QMS —PROC-SCM03 版本: 1.2

受控签章

编写人

评审

批准

发布范围 日期

评审号/日期

状态/日期

全公司 Word 文档资料

Word 文档资料

本规范是为了配合公司配置管理流程文件的执行所给出的配置管理活动中配置项用命

名、角色定义及权限分配规范,目的是给配置管理流程的使用人员详细的操作指南。

配置管理活动相关人员通过本规范的学习,充分撑握配置项命名规范 配、置管理活动中

所有角色的定义和权限的设置,更有效的执行公司配置管理流程。

软件配置管理是标识和确定系统中配置项的过程,在系统整个生存周期内控制这些项的

投放和更动,记录并报告配置的状态和更动要求,验证配置项的完整性和正确性。一言以蔽

之 配,置管理是门通过一系列技术、方法和手段来维护产品的历史、鉴别和定位产品独有的

版本、在产品开辟和发布阶段控制变化,从而使管理制度化、有效减少重复性工作、保证产

品的质量和效率的科学。 。

3.2 ( configuration Item,CI )

软件配置指一个软件产品在软件生存周期各个阶段所产生的各种形式(机器可读或者人工

可读)和各种版本的文档、程序及其数据的集合。

该集合中的每一个元素称为该软件产品软件配置中的一个配置项 (configuration

item) 。

指在软件组装与系统测试阶段结束时,经过正式评审的批准的有关所开辟的软件产品的 Word 文档资料

全部配置项的规格说明。产品基线是最初批准的产品配置标识。

配置管理的一个要素,由评估、协调、批准或者不批准,和对正式创建配置标识的配置项 实施变更等活动组成。

软件配置管理库又称软件受控库,是指在软件生存周期的某一个阶段结束时,存放作为

阶段产品而释放的、与软件开辟工作有关的计算机可读信息和人工可读信息的库。软件配置

管理就是对软件受控库中的各软件项进行管理 。

本规范给出了软件开辟项目配置项及其命名规则、配置管理活动中角色和权限的定义,

便于所涉及人员在使用 CVS 、SVN 工具和执行配置管理流程时更方便快捷的进行操作,以提

高开辟工作效率。

软件配置指一个软件产品在软件生存周期各个阶段所产生的各种形式(机器可读或者 人工可读)和各种版本的文档、程序及其数据的集合。软件开辟项目的配置项需要包括 以下的内容:

1 、 项目管理过程文档,例如:a) 项目任务书; b) 项目计划; c) 项目周报;

d) 个人日报和周报; e) 项目会议记要; f) 培训记录和培训文档; g)评

审记录 ;h)项目总结报告等等

2 、 项目技术文档,例如 a) 需求文档; b) 设计文档; c) 代码说明; d) 测

试文档; e) 软件安装使用手册等等; Word 文档资料

3 、 源代码和执行程序

4 、 项目中使用的第三方产品和数据

项目编号根据项目名称或者项目特征采用英文字母或者英文字母、数字和下划线组合。

以 至少的字母达到最容易理解的意义。

例如;

配置项的命名包括两个方面的内容:

1 、配置项标识

在我们的项目中,源代码和执行程序命名规则可以参照编码规范中的相关内容,文档

类可以采用全中文或者全英文命名两种方式。

全中文命名使用“项目名_模板名【_标识】”来命名。

“项目名”过长的可以采用中文简称,中文简称尽量以至少的汉字达到最容易理解的意义;

“模板名”使用公司的组织过程资产库中规定的名称;

“【 _标识】”是可选项,可以是时间(如: yyyymmdd )、序号(阿拉伯数字)、版本号

(如: V1.0 ) 、阶段名(如:编码阶段) 、模块名等。

例如:“” 简称为 “” ;

“”2022 年 12月 4号的 QA周报命名为“xxx_QA周报_20221204”。

全英文命名使用“项目编号_模板名【_标识】”来命名。

例如:“xxxx”的项目计划命名为“xxx_PP”;

“xxx”2022 年 12月 4号的 QA周报命名为“xxxx _QAWR _20221204”。

下表列出了我们在项目中使用的配置类别命名:

配置类别 配置类别 命名 命名 Word 文档资料

2 、配置项版本命名

配置项版本命名是针对配置项的版本进行命名,在我们的项目中,配置项版本通过对

Project的 Label操作来实现,配置项版本的命名需要能清晰标识配置项的状态。公司CVS

配置管理库逻辑上分开辟库、基线库和产品库,所有的配置项都保存在一个库中,对这三个

库的划分是通过逻辑划分方式进行的,具体来说,就是通过配置项版本命名来划分的; SVN

配置管理库物理上分开辟库、受控库、基线库。我们配置项的版本命名规定如下:

项目任务书 Project task

book TASK 项目计划 ProjectPlan PP

项目周报 Weekly project

PWR 工作周报 Weekly work WWR Report

项目会议记要 Minutes Meet_ YearMD 培训记录和培训文档

配置命名_ 项目中使用的第三方产品 评审记录 Assessment records YearMD Third-party products TRD

TPP

需求分析说明书

SoftwareRequirementS

pecification

功能列表 Feature List

测试计划 Test Plan

测试报告 Test Report

配置计划

RD

FeaL

TestP

TSR

CMP 概要设计说明书

Software design

specification

详细设计说明书

The detailed design

specification

测试用例 Test Case

用户手册 User manuals

QA周报

TS01

TS03

TestCase

SysGuider

QAWR

Word 文档资料

基线版本由配置管理员进行标识。基线发布分正式基线和非正式基线。正式基线包括需

求基线和产品基线;非正式基线通常包括概要设计基线、详细设计基线、代码/调试基线和

测试基线。基线版本的标识普通使用“项目名称_基线名称版_本号”

基线的版本号遵循《配置管理流程》 5.3.2配置项版本规范定义的 X.YZ模式命名。其

中 X 为主版本号, Y 为次版本号,取值范围均为 1-9配.置项第一次“正式发布”时,版本号

为 1.0 。若配置项的版本升级幅度较小,普通只增大Y值;惟独当配置项版本升级幅度比较

大时,才允许增大 X值。处于“正在修改”状态的配置项的版本号格式为:X.Y Z ,配置项正

在修改时,普通只增大 Z值, X.Y值保持不变。当配置项修改完毕,状态重新成为“正式发

布”时,将 Z值设置为 0 ,增加 X.Y 值。

例如: xxxxx_需求基线_正式发布首版本

基线版本标识为: xxxx_REQ_BL1.00

发布版本参照基线版本标识形式,将版本号前的 BL改为 Release即可。

例如: xxxx_产品基线_正式发布客户首版本

发布版本标识为: xxxx_PUR_ Release1.0

除基线版本外,有时候还需要在开辟和维护过程中确定其他版本。例如, 产品在测

试过程中不断的问题修复过程中,可能会有多种反复,此时需要将每次修改的内容作为一个

版本。 基线名称 命名 基线名称 命名

需求基线 REQ_BL 运行基线 RUN_BL

概要设计基线 HLD_BL 产品基线 Proud_BL

详细设计基线 DD_BL 计划基线 Plan_BL

代码基线 CODE_BL 单元测试 UTEST_BL

测试基线 TEST_BL

集成测试基线 QTEST_BL

系统测试基线 SysTest_BL