软件配置管理规范.docx
《软件配置管理规范.docx》由会员分享，可在线阅读，更多相关《软件配置管理规范.docx（9页珍藏版）》请在冰豆网上搜索。
软件配置管理规范
配置管理规范
文件编号：
QMS—PROC－SCM03
版本：
1.2
受控签章
编写人
日期
评审
评审号/日期
批准
状态/日期
发布范围
全公司
修改历史
日期
版本
作者
修改内容
1
目的和范围
本规范是为了配合公司配置管理流程文件的执行所给出的配置管理活动中配置项用命名、角色定义及权限分配规范，目的是给配置管理流程的使用人员详细的操作指南。
2目标
配置管理活动相关人员通过本规范的学习，充分撑握配置项命名规范、配置管理活动中所有角色的定义和权限的设置，更有效的执行公司配置管理流程。
3术语
3.1软件配置管理（SoftwareConfigurationManagement，SCM）
软件配置管理是标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。
一言以蔽之，配置管理是门通过一系列技术、方法和手段来维护产品的历史、鉴别和定位产品独有的版本、在产品开发和发布阶段控制变化，从而使管理制度化、有效减少重复性工作、保证产品的质量和效率的科学。
。
3.2配置项（configurationItem，CI）
软件配置指一个软件产品在软件生存周期各个阶段所产生的各种形式（机器可读或人工可读）和各种版本的文档、程序及其数据的集合。
该集合中的每一个元素称为该软件产品软件配置中的一个配置项（configurationitem）。
3.3产品基线productbaseline
指在软件组装与系统测试阶段结束时，经过正式评审的批准的有关所开发的软件产品的全部配置项的规格说明。
产品基线是最初批准的产品配置标识。
3.4配置控制
配置管理的一个要素，由评估、协调、批准或不批准，和对正式创建配置标识的配置项实施变更等活动组成。
3.5软件配置管理库softwarecontrolledlibrary
软件配置管理库又称软件受控库，是指在软件生存周期的某一个阶段结束时，存放作为阶段产品而释放的、与软件开发工作有关的计算机可读信息和人工可读信息的库。
软件配置管理就是对软件受控库中的各软件项进行管理。
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、配置项标识
在我们的项目中，源代码和执行程序命名规则可以参照编码规范中的相关内容，文档类可以采用全中文或全英文命名两种方式。
●全中文命名使用“项目名_模板名【_标识】”来命名。
“项目名”过长的可以采用中文简称，中文简称尽量以最少的汉字达到最容易理解的意义；
“模板名”使用公司的组织过程资产库中规定的名称；
“【_标识】”是可选项，可以是时间（如：
yyyymmdd）、序号（阿拉伯数字）、版本号（如：
V1.0）、阶段名（如：
编码阶段）、模块名等。
例如：
“”简称为“”；
“”2009年12月4号的QA周报命名为“xxx_QA周报_20091204”。
●全英文命名使用“项目编号_模板名【_标识】”来命名。
例如：
“xxxx”的项目计划命名为“xxx_PP”；
“xxx”2009年12月4号的QA周报命名为“xxxx_QAWR_20091204”。
下表列出了我们在项目中使用的配置类别命名：
配置类别
命名
配置类别
命名
项目任务书Projecttaskbook
TASK
项目计划ProjectPlan
PP
项目周报Weeklyproject
PWR
工作周报Weeklywork
Report
WWR
项目会议纪要Minutes
Meet_YearMD
培训记录和培训文档
TRD
评审记录Assessmentrecords
配置命名_YearMD
项目中使用的第三方产品
Third-partyproducts
TPP
需求分析说明书
SoftwareRequirementSpecification
RD
概要设计说明书Softwaredesignspecification
TS01
功能列表FeatureList
FeaL
详细设计说明书
Thedetaileddesignspecification
TS03
测试计划TestPlan
TestP
测试用例TestCase
TestCase
测试报告TestReport
TSR
用户手册Usermanuals
SysGuider
配置计划
CMP
QA周报
QAWR
2、配置项版本命名
配置项版本命名是针对配置项的版本进行命名，在我们的项目中，配置项版本通过对Project的Label操作来实现，配置项版本的命名需要能清楚标识配置项的状态。
公司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.YZ，配置项正在修改时，一般只增大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并发版本系统（ConcurrentVersionsSystem）是当前主流的开放源码网络透明的版本控制系统。
综合分析当前流程的配置管理工具VSS、CC、CVS、SVN，从其安全性、易用性、功能性以及成本几方面考虑，公司决定发展阶段选用开源CVS技术进行版本控制，配置审计、变更控制等结合手动流程实现管理。
待公司日渐扩大，软件过程能力成熟度达到一定等级时，再考虑引进配套的专业的配置管理工具。
2、CVS工具是C/S客户服务器模式的开源版本控制技术，支持多个开发人员通过一个中心版本控制系统来记录文件版本，从而达到保证文件同步的目的。
服务器端支持WINDOWS运行环境，同时给出了WINCVS的视窗客户操作界面，可实现配置存储、版本控制备份等主要功能，同时提供集成平台下的应用环境。
3、SVN相对于CVS，采用了分支管理系统，它的设计目标就是取代CVS。
优于CVS之处是：
统一的版本号；原子提交；重命名、复制、删除文件等动作都保存在版本历史记录当中；对于二进制文件，使用了节省空间的保存方法；目录也有版本历史；分支的开销非常小；优化过的数据库访问，使得一些操作不必访问数据库就可以做到；支持元数据管理。
公司将逐步使用SVN替换CVS。
5.2网络环境
为确保配置库的安全稳定，公司采用双机备份的机制，共设两台相同环境的服务器，并实现定期备份的要求。
对于远程开发项目，如必须，可将利用INTERNET网络，开放对外端口实现实时的版本控制。
升级会员 