软件配置管理规范样本.doc

配备管理规范

文献编号：QMS—PROC－SCM03
版本：1.2
受控签章

编写人

日期

评审

评审号/日期

批准

状态/日期

发布范畴
全公司

修改历史
日期
版本
作者
修改内容

1 目和范畴
本规范是为了配合公司配备管理流程文献执行所给出配备管理活动中配备项用命名、角色定义及权限分派规范，目是给配备管理流程使用人员详细操作指南。
2 目的
配备管理活动有关人员通过本规范学习，充分撑握配备项命名规范、配备管理活动中所有角色定义和权限设立，更有效执行公司配备管理流程。
3 术语
3.1 软件配备管理（Software Configuration Management，SCM）
软件配备管理是标记和拟定系统中配备项过程，在系统整个生存周期内控制这些项投放和更动，记录并报告配备状态和更动规定，验证配备项完整性和对的性。一言以蔽之，配备管理是门通过一系列技术、办法和手段来维护产品历史、鉴别和定位产品独有版本、在产品开发和发布阶段控制变化，从而使管理制度化、有效减少重复性工作、保证产品质量和效率科学。。
3.2 配备项（configuration Item，CI）
软件配备指一种软件产品在软件生存周期各个阶段所产生各种形式（机器可读或人工可读）和各种版本文档、程序及其数据集合。
该集合中每一种元素称为该软件产品软件配备中一种配备项(configuration item)。
3.3 产品基线product baseline
指在软件组装与系统测试阶段结束时，通过正式评审批准关于所开发软件产品所有配备项规格阐明。产品基线是最初批准产品配备标记。
3.4 配备控制
配备管理一种要素，由评估、协调、批准或不批准，和对正式创立配备标记配备项实行变更等活动构成。
3.5 软件配备管理库software controlled library
软件配备管理库又称软件受控库，是指在软件生存周期某一种阶段结束时，存储作为阶段产品而释放、与软件开发工作关于计算机可读信息和人工可读信息库。软件配备管理就是对软件受控库中各软件项进行管理。
4 配备管理规范
本规范给出了软件开发项目配备项及其命名规则、配备管理活动中角色和权限定义，便于所涉及人员在使用CVS、SVN工具和执行配备管理流程时更以便快捷进行操作，以提高开发工作效率。
4.1 配备项及其命名规则
4.1.1 配备项
软件配备指一种软件产品在软件生存周期各个阶段所产生各种形式（机器可读或人工可读）和各种版本文档、程序及其数据集合。软件开发项目配备项需要涉及如下内容：
1、 项目管理过程文档，例如：a) 项目任务书；b) 项目筹划；c) 项目周报；d) 个人日报和周报；e) 项目会议纪要；f) 培训记录和培训文档；g)评审记录;h)项目总结报告等等
2、 项目技术文档，例如 a) 需求文档；b) 设计文档；c) 代码阐明；d) 测试文档；e) 软件安装使用手册等等；
3、 源代码和执行程序
4、 项目中使用第三方产品和数据
4.1.2 项目编号命名规则
项目编号依照项目名称或项目特性采用英文字母或者英文字母、数字和下划线组合。以至少字母达到最容易理解意义。
例如；
4.1.3 配备项命名规则
配备项命名涉及两个方面内容：  
1、 配备项标记
在咱们项目中，源代码和执行程序命名规则可以参照编码规范中有关内容，文档类可以采用全中文或全英文命名两种方式。
l 全中文命名使用“项目名_模板名【_标记】”来命名。
“项目名”过长可以采用中文简称，中文简称尽量以至少中文达到最容易理解意义；
“模板名”使用公司组织过程资产库中规定名称；
“【_标记】”是可选项，可以是时间（如：yyyymmdd）、序号（阿拉伯数字）、版本号（如：V1.0）、阶段名（如：编码阶段）、模块名等。
例如：“” 简称为 “” ；
“”12月4号 QA周报命名为“xxx_QA周报_1204”。
l 全英文命名使用“项目编号_模板名【_标记】”来命名。
例如：“xxxx”项目筹划命名为“xxx_PP”；
“xxx”12月4号 QA周报命名为“xxxx _QAWR _1204”。
下表列出了咱们在项目中使用配备类别命名：
配备类别
命名
配备类别
命名
项目任务书Project task book

TASK
项目筹划 ProjectPlan
PP
项目周报Weekly project

PWR
工作周报 Weekly work
Report
WWR
项目会议纪要 Minutes
Meet_ YearMD
培训记录和培训文档
TRD
评审记录Assessment records
配备命名_ YearMD
项目中使用第三方产品
Third-party products
TPP
需求分析阐明书
SoftwareRequirementS pecification
RD
概要设计阐明书Software design specification

TS01
功能列表Feature List
FeaL
详细设计阐明书
The detailed design specification
TS03
测试筹划Test Plan
TestP
测试用例Test Case
TestCase
测试报告Test Report
TSR
顾客手册User manuals
SysGuider
配备筹划
CMP
QA周报
QAWR

2、 配备项版本命名
配备项版本命名是针对配备项版本进行命名，在咱们项目中，配备项版本通过对ProjectLabel操作来实现，配备项版本命名需要能清晰标记配备项状态。公司CVS配备管理库逻辑上分开发库、基线库和产品库，所有配备项都保存在一种库中，对这三个库划分是通过逻辑划分方式进行，详细来说，就是通过配备项版本命名来划分；SVN配备管理库物理上分开发库、受控库、基线库。咱们配备项版本命名规定如下：

a) 基线版本
基线版本由配备管理员进行标记。基线发布分正式基线和非正式基线。正式基线涉及需求基线和产品基线；非正式基线普通涉及概要设计基线、详细设计基线、代码/调试基线和测试基线。基线版本标记普通使用“项目名称_基线名称_版本号”
基线名称
命名
基线名称
命名
需求基线
REQ_BL
运营基线
RUN_BL
概要设计基线
HLD_BL
产品基线
Proud_BL
详细设计基线
DD_BL
筹划基线
Plan_BL
代码基线
CODE_BL
单元测试
UTEST_BL
测试基线
TEST_BL

集成测试基线
QTEST_BL

系统测试基线
SysTest_BL

基线版本号遵循《配备管理流程》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
b) 发布版本
发布版本参照基线版本标记形式，将版本号前BL改为Release即可。
例如：xxxx_产品基线_正式发布客户首版本
发布版本标记为：xxxx_PUR_ Release1.0
c) 其她版本
除基线版本外，有时候还需要在开发和维护过程中拟定其她版本。例如，产品在测试过程中不断问题修复过程中，也许会有各种重复，此时需要将每次修改内容作为一种版本。
关于版本，尚有另一种需要注意问题。普通来说，按照模块来划分，每个模块有自己版本演进比较合理。一方面，一种模块普通是由一种或两个开发人员完毕；另一方面，一种模块功能会比较单一且独立，在版本演化过程中便于控制，也不会和其她模块产生过于复杂关系。CVS库中产品版本需要由各个模块不同版本构成，这个纵横关系需要较好地管理，咱们做法是在CVS库上用Label来标记，同步维护一种描述产品版本和模块版本关系readme.txt文献；SVN库任何一次提交都会对所有文献增长到同一种新版本号，虽然是提交并不涉及文献。因此，各文献在某任意时间版本号是相似。
需要阐明是开发库中版本配备工具会依照操作人员对文献修改与提交自动化给出版本标记，例如:CVS初始版本号为1.1，修改提交一次自动递升一种子版本号为1.2，依次类推。CVS同步也支持操作人员自定义版本号，这个不属于受控库管理之列不做统一规定，开发组可依照项目实际状况进行组内商定。
4.2 角色和权限定义
角色是配备管理流程执行者和参加者，定义明确角色有助于实现明确授权和明晰流程，虽然在实际中也许各种角色由一种人担任，但还是应当保存角色定义。
   下面是该项目中咱们角色定义。
4.2.1   配备管理员
整个配备管理库由配备管理员管理。配备管理员负责分派和修改其她成员权限，要维护所有目录和配备项。
4.2.2   项目经理
项目经理在本项目中负责主导完毕需求分析和系统总体设计，对项目总体进度负责。项目经理拥有对管理类文档读取权限，可以对项目类文档进行读写操作；
4.2.3   开发组长
开发组长对本小组工作负有组织和管理任务，同步开发组长也需要承担一定开发任务。开发组长对管理类文档有读取权限，对本组负责模块有读取权限，对自己负责模块有读写权限；
4.2.4   开发工程师
开发工程师完毕详细开发任务，对自己负责模块目录有读写权限，对管理类文档有读取权限；
4.2.5   测试组长
测试组长负责组织测试，给出测试筹划和测试方案，并核定测试报告。测试组长对所有目录均有读取权限，对测试目录有读写权限；
4.2.6   测试工程师
测试工程师负责完毕测试工作，涉及测试用例开发和测试执行，测试报告编写。测试工程师对自己负责模块有读取权限，对测试用例目录有读写权限。
4.2.7   QA工程师
QA工程师拥有对所有目录读取权限，拥有对QA类文档目录读写权限。
〔阐明〕CVS配备库中，除配备管理员外，其她所有成员都没有CVSROOT目录和文献权限，这是为了防止误删除操作带来不可挽回损失。如果需要对目录进行Destroy操作，必要由配备管理员进行。
4.3 配备库构造定义
我公司主营业务为外包软件开发，为以便多语言库移植，配备管理库采用英文标记如下：
项目配备库构造
【项目简称】（项目）
――trunk （开发主线 即开发库）
――DOC（项目文档类配备项存储文献夹）
――Requiremet（需求类）
――Design （设计类）
――Code （编码类）
――Test （测试类）
――PM （项目管理类）
――Maintenance （维护类）
――CM （配备管理类）
――QA （质量保证类）
――MA （度量类）
――Training （培训类）
――Release（实行类）
――Reference （参照文档）
――SRC ( 项目代码类配备存储文献夹)
――BIN（项目数据、运营环境或第三方提供配备项存储文献夹）
――branches （分支）
――tags （受控库）
――DOC（项目文档类配备项存储文献夹）
――SRC ( 项目代码类配备存储文献夹)
――BIN（项目数据、运营环境或第三方提供配备项存储文献夹）
――baseline （基线库）
――REQ_BL(需求基线)
――DD_BL (设计基线)
――CODE_BL(编码基线)
――SysTest_BL(系统测试基线)
――Proud_BL(产品基线)

CVS配备库逻辑上分开发库、基线库和产品库，物理上只建开发库develop和产品库Product ，基线库运用CVS工具提供标签实现；
SVN配备库物理上分开发库、受控库和基线库。
库构造存储内容阐明：
1、开发主线：寻常开发进行地方；
2、分支：存储分支拷贝；
3、受控库：保存标签拷贝。这里存储内容作为一种里程碑版本进行存档。当开发人员在自己工作开发到一定限度后，以为可以提交测试或者提交给项目经理检查了，她可以提交到受控库；
4、基线库：当预期基线所涉及所有内容在受控库中都达到可基线化状态时，可以将这些配备项转入基线库中；产品基线通过标记来注明，不单独设立产品库。

基线标签规范已在上一章节中描述，在此不再赘述。
5 配备管理工具及环境配备

5.1 配备管理工具
1、 CVS并发版本系统（Concurrent Versions System）是当前主流开放源码网络透明版本控制系统。综合分析当前流程配备管理工具VSS、CC、CVS、SVN，从其安全性、易用性、功能性以及成本几方面考虑，公司决定发展阶段选用开源CVS技术进行版本控制，配备审计、变更控制等结合手动流程实现管理。待公司日渐扩大，软件过程能力成熟度达到一定级别时，再考虑引进配套专业配备管理工具。
2、 CVS工具是C/S客户服务器模式开源版本控制技术，支持各种开发人员通过一种中心版本控制系统来记录文献版本，从而达到保证文献同步目。服务器端支持WINDOWS运营环境，同步给出了WINCVS视窗客户操作界面，可实现配备存储、版本控制备份等重要功能，同步提供集成平台下应用环境。
3、 SVN相对于CVS，采用了分支管理系统，它设计目的就是取代CVS。优于CVS之处是：统一版本号；原子提交；重命名、复制、删除文献等动作都保存在版本历史记录当中；对于二进制文献，使用了节约空间保存办法；目录也有版本历史；分支开销非常小；优化过数据库访问，使得某些操作不必访问数据库就可以做到；支持元数据管理。公司将逐渐使用SVN替代CVS。
5.2 网络环境
为保证配备库安全稳定，公司采用双机备份机制，共设两台相似环境服务器，并实现定期备份规定。对于远程开发项目，如必要，可将运用INTERNET网络，开放对外端口实现实时版本控制。