文件编号：GM/KFB/CMS/20090720版本号：V产品开发部配置管理制度部 门： 产品开发部 编 写：********审 核：批 准：日 期：2009-07-20********##修 改 历 史序号版本更改处·更改内容更改人/日期1V创建文件******/2009-07-202345678910111213141516目录第一章概述51.目的52.范围53.术语54.角色与职责65. VSS配置库目录结构76. 配置项命名规则77. 配置项编号规则78. 配置项状态变迁规则109. 配置项版本号规则10第二章配置管理范围11第三章配置库建立11第四章配置管理流程121. 配置管理流程122. 基线建立流程143. 变更控制流程154. 产品发布流程16第五章配置库权限变更管理17第六章配置库备份17第七章配置库使用规范17第八章附录18附录1 《附录清单》18附录2 《配置库目录结构》19附录3 《配置申请单》20附录4 《受控库产品清单》21附录5 《变更申请单》22附录6 《发布产品配置表》23附录7 《产品发布申请与验收表》24附录8 《产品发布检查表》26附录9 《产品发布清单》27第一章 概述1. 目的为了保证产品开发部研发项目文件的安全性、##性；为了保证软件产品的完整性、有效性与可追溯性,特根据部门实际情况制订本制度.2. 范围适用于产品开发部所有项目.3. 术语概念描述软件配置管理基线就是一个CI或一组CI在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态,而这个过程被称为"基线化".每一个基线都是其下一步开发的出发点和参考点.每个基线都将接受配置管理的严格控制,对其的修改将严格按照变更控制要求的过程进行,在一个软件开发阶段结束时,上一基线加上增加和修改的基线内容形成下一个基线,这就是基线管理的过程.<基线：是指在软件开发过程中的里程碑,这些里程碑的标志是一项或多项经过正式的技术评审并一致认同的CI的提交>4. 角色与职责角色职责项目经理确定配置项、确定配置库目录权限；审查配置库变更；项目开发过程中,监督配置库使用情况；员工离职时,配置库归档完整性审核.开发小组根据配置管理制度,进行配置库的日常使用测试小组从开发库中取出版本进行整合测试；负责验证代码变更与修改是否正确执行.测试小组测试通过的版本方可放入受控库.配置管理员负责配置库的建立、权限设置、负责培训开发人员使用配置管理工具、对配置库使用情况进行管理和监督、建立配置库基线；定期备份配置库；建立和完善配置管理制度.评审小组对项目中的变更进行评审、监控；协调开发小组、测试小组、配置管理员进行配置库的优化和管理.5.VSS配置库目录结构配置库〔vss_PDMIS〕开发库〔1work〕受控库〔2confirmed〕发布库〔3release〕存放基线产品存放发布产品存放配置项l 开发库：主要用来保存开发过程中不稳定的配置项〔源码和相关文档〕,主要由开发人员支配.l 受控库：用来保存基线产品〔阶段性提交的通过评审且相对稳定的配置项〕,主要由配置管理员支配.l 发布库：用来保存发布的产品,即交付给用户的产品、升级包、文档等,主要由测试人员支配.〔这里的用户特指总工办,这里的发布属于公司内部发布.〕6. 配置项命名规则配置项的命名规则分两种：1) 在开发库和受控库中,命名规则为：项目编号_子模块名称_类型名称l 类型名称：为用户需求说明书、源代码、可执行文件、测试报告等.l 例子：CDDT-1_地铁维护单元_源代码,CDDT-1_用户需求说明书.2) 在发布库中,命名规则为：项目编号_子模块名称_类型名称_版本号〔日期_[序号]〕l 例子1：CDDT-1_CDDT-1_地铁维护单元_源代码_Vl 例子2：CDDT-1_受控库产品清单_200907147. 配置项编号规则1) 配置项编号规则：固定字段 /项目编号_[子模块编号] /版本号〔日期_[序号]〕l 示例1：以下表《可行性分析报告》为例：QR704/01/KFB/固定字段GM2000-MN项目编号_[子模块编号]/V版本号〔日期_[序号]〕l 示例2：以下表《质量月报》为例：QR701/01/KFB/GM2000-MN/2009072) 表1说明l 红色部分为公司内/外审时,必须提交的文档.其余为部门内部文档.l 编号第二字段为01-50,表示是公司内/外审必须文档,51以后的数字代表部门内部文档.l 改表预留了,以后可以根据实际需要添加删除文档.阶段文档类型文档编号固定字段+项目编号_[子模块编号]+版本号〔日期_[序号]〕,此处所示为固定字段编号备注定义《需求调研计划》QR704/51/KFB《需求调研记录》QR704/52/KFB《可行性分析报告》QR704/01/KFB《用户需求说明书》QR704/02/KFB《软件/系统需求规格说明书》QR704/53/KFB《需求确认表》QR704/54/KFB《项目计划》〔包含附件:进度Project文档〕QR704/03/ KFB《配置管理计划》QR706/01/ KFB《质量保证计划》QR701/51/KFB设计《概要设计说明书》QR704/04/ KFB《详细设计说明书》QR704/55/KFB实现测试《测试计划》QR704/05/KFB《测试报告》QR704/06/KFB《未关闭缺陷原因说明表》QR704/56/KFB发布硬件/软件设计更改说明QR704/07/KFB改造项目需提交《项目总结报告》QR704/08/KFB《用户手册》QR704/09/KFB日常支持文档配置管理类：《配置管理报告》QR706/02/ KFB《配置申请单》QR706/51/ KFB《变更申请单》QR706/52/ KFB《受控库产品清单》QR706/53/ KFB《配置状态报告》QR706/54/ KFB《产品发布申请与验收表》QR706/03/KFB《发布产品配置表》QR706/04/KFB日常支持文档质量保障类：《质量保证报告》QR701/51/KFB《质量保证检查表》QR701/52/KFB《质量月报》QR701/01/KFB《代码检查表》QR701/53/KFB日常支持文档管理评审类：《评审通知》QR704/10/KFB《预读记录》QR704/57/KFB《评审意见汇总表》QR704/11/KFB《评审问题跟踪表》QR704/58/KFB《评审会议纪要》QR704/59/KFB《设计开发任务书》QR704/60/KFB《工作任务单》QR704/12/KFB8. 配置项状态变迁规则1) 配置项的状态有三种："草稿"〔Draft〕、"正式发布"〔Released〕和"正在修改"〔Changing〕.2) .配置项状态变迁如下图所示.配置项刚建立时其状态为"草稿".配置项通过评审〔或审批〕后,其状态变为"正式发布".当配置项的状态成为"正式发布"时任何人都不能随意修改,必须依据"申请－审批－执行变更－再评审－结束"的"变更控制流程"执行.当配置项修改完毕并重新通过评审〔或审批〕时,其状态又变为"正式发布",如此循环.通过变更控制正式发布否决评审或审批自由修改正在修改草稿9. 配置项版本号规则配置项的版本号与配置项的状态紧密相关：〔1〕处于"草稿"l "V"Version的首字母,代表后面的数字为版本号.l Z数字范围为001-999l 随着草稿的不断完善,"Z"的取值应递增.l "Z"的初值为001,增幅为001.l 例子：V 〔2〕处于"正式发布"状态的配置项的版本号格式为：V X.Y.000l X为主版本号,取值范围为1-9.Y为次版本号,取值范围为00-99.l 配置项第一次"正式发布"时,版本号为V .l 如果配置项的版本升级幅度比较小,一般只增大Y值,X值保持不变.只有当配置项版本升级幅度比较大时,才允许增大X值.l 例子：V 〔3〕处于"正在修改"状态的配置项的版本号格式为：V X.Y.Zl Z数字范围为001-999l 配置项正在修改时,一般只增大Z值,X.Y值保持不变.l 当配置项修改完毕,状态重新成为"正式发布"时,将Z值设置为0,增加X.Y值.参见规则〔2〕.l 例子：V 第二章 配置管理范围配置管理包括：所有研发项目文档、源代码、可执行程序,特殊工具与相关资料等.项目文档主要指：立项建议书、项目计划、需求说明书、软件规格说明书、概要/详细设计说明书、数据库表结构、测试文档、用户使用说明书以与项目过程中管理类文档等.特殊工具与其相关资料指开发或测试过程中比较特殊的工具,以与其使用文档等,如觉得有必要也纳入配置库的管理.第三章 配置库建立1. 项目立项时,由项目经理申请建立项目配置库,配置管理员与项目经理确定配置项,并参考附录2：配置库目录结构,建立配置库以与配置库目录结构；项目经理提供配置库权限清单〔内容应包括员工##、项目名称、目录权限等〕,由配置管理员为相关人员的设置配置权限.2. 配置库权限设置完成之后,由配置管理员将配置库名称、访问路径、访问权限等信息以方式通知各相关人员；配置库使用人员以各自的用户名和密码进行访问配置库.3. 配置库密码只能在服务器上设置,但使用人员可以在客户端修改自己的秘密,如配置库使用人员密码遗忘,可以与配置管理员取得联系,进行修改密码.第四章 配置管理流程1.配置管理流程定义阶段项目经理编写《项目计划》并通过评审.配置管理员依据《项目计划》编写《配置管理计划》项目经理审批《配置管理计划》项目经理依据《配置管理计划》在规定时间申请建立定义基线.申请建立基线的流程见《基线建立流程》项目经理依据《配置管理计划》在规定时间申请建立定义基线.设计。
