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

1、软件配置管理规范样本配置管理规范文件编号：QMSPROC一SCM03版本：1. 2受控签章编写人丨丨期评审评审号/日期批准状态/日期发布范围全公司修改历史日期版本作者修改内容本规范是为了配合公司配置管理流程文件的执行所给出的配 置管理活动中配置项用命名、角色定义及权限分配规范，目的是 给配置管理流程的使用人员详细的操作指南。2目标配置管理活动相关人员经过本规范的学习，充分撑握配置项 命名规范、配置管理活动中所有角色的定义和权限的设置，更有 效的执行公司配置管理流程。3术语3.1 软件配置管理(Software Configuration Management, SCM)软件配置管理是标识和确定

2、系统中配置项的过程，在系统整 个生存周期内控制这些项的投放和更动，记录并报告配置的状态 和更动要求，验证配置项的完整性和正确性。一言以蔽之，配置管 理是门经过一系列技术、方法和手段來维护产品的历史、鉴别和 定位产品独有的版本、在产品开发和发布阶段控制变化，从而使 管理制度化、有效减少重复性工作、保证产品的质量和效率的科 学。3.2配置项(configuration Item, CI)软件配置指一个软件产品在软件生存周期各个阶段所产生的 各种形式(机器可读或人工可读)和各种版本的文档、程序及其 数据的集合。该集合中的每一个元素称为该软件产品软件配置中的一个配 置项(configuration i

3、tem) o3.3产品基线 product baseline指在软件组装与系统测试阶段结束时，经过正式评审的批准 的有关所开发的软件产品的全部配置项的规格说明。产品基线是最 初批准的产品配置标识。3.4配置控制配置管理的一个要素，由评估、协调、批准或不批准，和对 正式创立配置标识的配置项实施变更等活动组成。软件配置管理库又称软件受控库，是指在软件生存周期的某 一个阶段结束时，存放作为阶段产品而释放的、与软件开发工作 有关的计算机可读信息和人工可读信息的库。软件配置管理就是对 软件受控库中的各软件项进行管理。4配置管理规范本规范给出了软件开发项目配置项及其命名规则、配置管理 活动中角色和权限的定

4、义，便于所涉及人员在使用CVS、SVN工具 和执行配置管理流程时更方便快捷的进行操作，以提高开发工作 效率。4. 1配置项及其命名规则4.1.1配置项软件配置指一个软件产品在软件生存周期各个阶段所产生 的各种形式（机器可读或人工可读）和各种版本的文档、程序 及其数据的集合。软件开发项目的配置项需要包括以下的内容：1、 项目管理过程文档，例如：a）项目任务书；b）项目 计划；c）项目周报；d）个人日报和周报；e）项目 会议纪要；f）培训记录和培训文档；g）评审记录;h） 项目总结报告等等2、 项目技术文档，例如a）需求文档；b）设计文档；c）代码说明；d）测试文档；e）软件安装使用手册3、 源代

5、码和执行程序4、 项目中使用的第三方产品和数据4.1.2项目编号命名规则项目编号根据项目名称或项目特征采用英文字母或者英文字 母、数字和下划线组合。以最少的字母达到最容易理解的意义。例如；4.1.3配置项命名规则配置项的命名包括两个方面的内容：1、配置项标识在我们的项目中，源代码和执行程序命名规则能够参照编码 规范中的相关内容，文档类能够采用全中文或全英文命名两种方 式。全中文命名使用”项目名模板名【一标识】”來命名。”项目名”过长的能够采用中文简称，中文简称尽量以最少的汉 字达到最容易理解的意义；”模板名”使用公司的组织过程资产库中规定的名称；”【标识】”是可选项，能够是时间（如：yyyym

6、mdd）、序号 （阿拉伯数字）、版本号（如：V1.0）、阶段名（如：编码阶 段）、模块名等。例如：” ”简称为”；12月4号的QA周报命名为” xxx_QA周报1204”。全英文命名使用”项目编号_模板名【标识】”來命名。例如：” XXXX”的项目计划命名为” XXX_PP” ;” XXX” 12 月 4 号的 QA 周报命名为” xxxx _QAWR _ 1204”。下表列出了我们在项目中使用的配置类别命名：配置类别命名配置类别命名项目任务书Project task bookTASK项目计划ProjectPlanpp项目周报Weekly projectPWR匸作周报Weekly workRe

7、portWWR项目会议纪要MinutesMeet.YearMD培训记录和培训文档TRD评审记录 Assessment records配置命名YearMD项目中使用的第三方产品Third-party productsTPP需求分析说明书SoftwareRequirementSpecificationRD概要设计说明书 Software design specificationTSOI功能列表Feature ListFeaL详细设计说明书The detailed designspecificationTS03测试计划Test PlanTestP测试用例Test CaseTestCase测试报告Te

8、st ReportTSR |用户手册User manualsSysGuider配置计划CMPQA周报QAWR2、配置项版本命名配置项版本命名是针对配置项的版本进行命名，在我们的项 目中，配置项版本经过对Project的Label操作來实现，配置项版 本的命名需要能清楚标识配置项的状态。公司CVS配置管理库逻辑 上分开发库、基线库和产品库，所有的配置项都保存在一个库中, 对这三个库的划分是经过逻辑划分方式进行的，具体來说，就是 经过配置项版本命名來划分的；SVN配置管理库物理上分开发库、 受控库、基线库。我们配置项的版本命名规定如下：a）基线版本基线版本由配置管理员进行标识。基线发布分正式基线和

9、非正 式基线。正式基线包括需求基线和产品基线；非正式基线一般包括 概要设计基线、详细设计基线、代码/调试基线和测试基线。基 线版本的标识一般使用”项目名称_基线名称版本号”基线名称命需基线名称命名需求基线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.配置项

10、第一次”正式发布”时，版本号为1. Oo若配置 项的版本升级幅度较小，一般只增大Y值；只有当配置项版本升 级幅度比较大时，才允许增大X值。处于”正在修改”状态的配置 项的版本号格式为:X.Y Z,配置项正在修改时，一般只增大Z值, X.Y值保持不变。当配置项修改完毕，状态重新成为”正式发布” 时，将Z值设置为0,增加X.Y值。例如：xxxxx_需求基线正式发布首版本基线版本标识为：xxxx_REQ_BLl. 00b） 发布版本发布版本参照基线版本标识形式，将版本号前的BL改为 Release 即可。例如：xxxx_产品基线_正式发布客户首版本发布版本标识为：xxxx_PUR_ Re lease

11、 1. 0c） 其它版本除基线版本外，有时候还需要在开发和维护过程中确定 其它版本。例如，产品在测试过程中不断的问题修复过程中，可能 会有多种重复，此时需要将每次修改的内容作为一个版本。关于版本，还有另一个需要注意的问题。一般來说，按照模块 來划分，每个模块有自己的版本演进比较合理。首先，一个模块一 般是由一个或两个开发人员完成的；其次，一个模块的功能会比 较单一且独立，在版本的演化过程中便于控制，也不会和其它模 块产生过于复杂的关系。CVS库中产品的版本需要由各个模块的不 同版本组成，这个纵横的关系需要很好地管理，我们的做法是在 CVS库上用Label來标识，同时维护一个描述产品版本和模块版

12、本 关系的readme, txt文件；SVN库任何一次提交都会对所有文件增 加到同一个新版本号，即使是提交并不涉及的文件。因此，各文件 在某任意时间的版本号是相同的。需要说明的是开发库中的版本配置工具会根据操作人员对文 件的修改与提交自动化的给出版本标识，比如:CVS初始版本号为 1.1,修改提交一次自动递升一个子版本号为1.2,依次类推CVS 同时也支持操作人员自定义版本号，这个不属于受控库管理之列 不做统一要求，开发组可根据项目实际情况进行组内约定。4.2角色和权限定义角色是配置管理流程的执行者和参与者，定义明确的角色有 利于实现明确的授权和明晰的流程，虽然在实际中可能多个角色 由一个人担

13、任，但还是应该保留角色的定义。下面是该项目中我们的角色定义。4.2.1配置管理员整个配置管理库由配置管理员管理。配置管理员负责分配和修 改其它成员的权限，要维护所有目录和配置项。4.2.2项目经理项目经理在本项目中负责主导完成需求分析和系统总体设计, 对项目的总体进度负责。项目经理拥有对管理类文档的读取权限, 能够对项目类文档进行读写操作；4.2.3开发组长开发组长对本小组的工作负有组织和管理任务，同时开发组 长也需要承担一定的开发任务。开发组长对管理类文档有读取权限, 对本组负责的模块有读取权限，对自己负责的模块有读写的权限；4.2.4开发工程师开发工程师完成具体的开发任务，对自己负责的模块

14、目录有 读写权限，对管理类文档有读取权限；4.2.5测试组长测试组长负责组织测试，给出测试计划和测试方案，并核定 测试报告。测试组长对所有目录都有读取权限，对测试目录有读写 权限；4.2.6测试工程师测试工程师负责完成测试工作，包括测试用例开发和测试执 行，测试报告编写。测试工程师对自己负责的模块有读取权限，对 测试用例目录有读写权限。4.2.7QA工程师QA工程师拥有对所有目录的读取权限，拥有对QA类文档目录的读写权限。（说明）CVS配置库中，除配置管理员外，其它所有成员都没 有CVSROOT目录和文件的权限，这是为了防止误删除操作带來不 可挽回的损失。如果需要对目录进行Destroy操作，

15、必须由配置管 理员进行。4.3配置库结构定义我公司主营业务为外包软件开发，为方便多语言库的移植，配置 管理库釆用英文标识如下：项目配置库结构【项目简称】（项目）一一trunk （开发主线即开发库）一一D0C（项目文档类配置项存放文件夹） Requiremet （需求类） Design （设计类） Code（编码类） Test（测试类）一一PM （项目管理类） Maintenance （维护类） CM（配置管理类）QA（质量保证类） MA（度量类） Training （培训类） Release （实施类） Reference （参考文档）一一SRC （项目代码类配置存放文件夹）一一BIN（项目数

16、据、运行环境或第三方提供配置项存 放文件夹） branches （分支）-tags （受控库）一一DOC（项目文档类配置项存放文件夹）一一SRC （项目代码类配置存放文件夹）一一BIN（项目数据、运行环境或第三方提供配置项存放 文件夹） baseline （基线库）一一REQ_BL （需求基线）一一DD_BL （设计基线） CODE_BL （编码基线） SysTest_BL（系统测试基线）一一Proud_BL（产品基线）库结构存放内容说明:1、 开发主线：日常开发进行的地方；2、 分支：存放分支拷贝；3、 受控库：保存标签拷贝。这里存储内容作为一个里程碑的 版本进行存档。当开发人员在自己的工作

17、开发到一定程度后，认为 能够提交测试或者提交给项目经理检查了，她能够提交到受控库；4、 基线库：当预期的基线所包括的所有内容在受控库中都达 到可基线化的状态时，能够将这些配置项转入基线库中；产品基 线经过标记來注明，不单独设置产品库。基线的标签规范己在上一章节中描述，在此不再赘述。5配置管理工具及环境配置5.1配置管理工具1、 CVS 并发版本系统(Concurrent Versions System)是当前 主流的开放源码网络透明的版本控制系统。综合分析当前流 程的配置管理工具VSS、CC、CVS、SVN,从其安全性、易 用性、功能性以及成本几方面考虑，公司决定发展阶段选 用开源CVS技术进

18、行版本控制，配置审计、变更控制等结 合手动流程实现管理。待公司日渐扩大，软件过程能力成熟 度达到一定等级时，再考虑引进配套的专业的配置管理工 具。2、 CVSI具是C/S客户服务器模式的开源版本控制技术，支持 多个开发人员经过一个中心版本控制系统來记录文件版本, 从而达到保证文件同步的目的。服务器端支持WINDOWS运行 环境，同时给出了 WINCVS的视窗客户操作界面，可实现配 置存储、版本控制备份等主要功能，同时提供集成平台下 的应用环境。3、 SVN相对于CVS,釆用了分支管理系统，它的设计目标就是 取代CVS。优于CVS之处是：统一的版本号；原子提交；重 命名、复制、删除文件等动作都保存在版本历史记录当中; 对于二进制文件，使用了节省空间的保存方法；目录也有 版本历史；分支的开销非常小；优化过的数据库访问，使 得一些操作不必访问数据库就能够做到；支持元数据管理。 公司将逐步使用SVN替换CVSo5.2网络环境为确保配置库的安全稳定，公司釆用双机备份的机制，共设 两台相同环境的服务器，并实现定期备份的要求。对于远程开发项 目，如必须，可将利用INTERNET网络，开放对外端口实现实时的 版本控制。