软件配置管理规范.doc

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

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

3、合。该集合中的每一个元素称为该软件产品软件配置中的一个配置项(configuration item)。3.3 产品基线 product baseline指在软件组装与系统测试阶段结束时，经过正式评审的批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标识。质量体系管理文件内部文件 文件名称3.4 配置控制配置管理的一个要素，由评估、协调、批准或不批准，和对正式创建配置标识的配置项实施变更等活动组成。3.5 软件配置管理库 software controlled library软件配置管理库又称软件受控库，是指在软件生存周期的某一个阶段结束时，存放作为阶段产品而释放的

4、、与软件开发工作有关的计算机可读信息和人工可读信息的库。软件配置管理就是对软件受控库中的各软件项进行管理。 4 配置管理规范本规范给出了软件开发项目配置项及其命名规则、配置管理活动中角色和权限的定义，便于所涉及人员在使用 CVS、SVN 工具和执行配置管理流程时更方便快捷的进行操作，以提高开发工作效率。4.1 配置项及其命名规则4.1.1 配置项软件配置指一个软件产品在软件生存周期各个阶段所产生的各种形式（机器可读或人工可读）和各种版本的文档、程序及其数据的集合。软件开发项目的配置项需要包括以下的内容： 1、 项目管理过程文档，例如：a) 项目任务书；b) 项目计划；c) 项目周报；d) 个人

5、日报和周报；e) 项目会议纪要；f) 培训记录和培训文档；g)评审记录;h)项目总结报告等等 2、 项目技术文档，例如 a) 需求文档；b) 设计文档；c) 代码说明；d) 测试文档；e) 软件安装使用手册等等； 3、 源代码和执行程序质量体系管理文件内部文件 文件名称4、 项目中使用的第三方产品和数据4.1.2 项目编号命名规则项目编号根据项目名称或项目特征采用英文字母或者英文字母、数字和下划线组合。以最少的字母达到最容易理解的意义。例如；4.1.3 配置项命名规则配置项的命名包括两个方面的内容： 1、 配置项标识在我们的项目中，源代码和执行程序命名规则可以参照编码规范中的相关内容，文档类可

6、以采用全中文或全英文命名两种方式。 全中文命名使用“项目名_模板名【_标识】”来命名。“项目名”过长的可以采用中文简称，中文简称尽量以最少的汉字达到最容易理解的意义；“模板名”使用公司的组织过程资产库中规定的名称；“【_标识】”是可选项，可以是时间（如：yyyymmdd）、序号（阿拉伯数字）、版本号（如：V1.0） 、阶段名（如：编码阶段） 、模块名等。例如：“” 简称为 “” ； “”2009年 12月 4号的 QA 周报命名为“xxx_QA 周报_20091204”。 全英文命名使用“项目编号_模板名【_标识】”来命名。例如：“xxxx”的项目计划命名为“xxx_PP”；“xxx”2009

7、年 12月 4号的 QA 周报命名为“xxxx _QAWR _20091204”。下表列出了我们在项目中使用的配置类别命名： 配置类别 命名 配置类别 命名 项目任务书 Project task book TASK 项目计划 ProjectPlan PP质量体系管理文件内部文件 文件名称项目周报 Weekly projectPWR 工作周报 Weekly workReportWWR 项目会议纪要 MinutesMeet_ YearMD培训记录和培训文档 TRD 评审记录 Assessment records 配置命名_ YearMD 项目中使用的第三方产品Third-party product

8、s TPP需求分析说明书SoftwareRequirementS pecificationRD概要设计说明书Software design specification TS01功能列表 Feature List FeaL详细设计说明书The detailed design specificationTS03测试计划 Test Plan TestP 测试用例 Test Case TestCase测试报告 Test Report TSR 用户手册 User manuals SysGuider配置计划 CMP QA周报 QAWR2、 配置项版本命名配置项版本命名是针对配置项的版本进行命名，在我们的项

9、目中，配置项版本通过对Project的 Label操作来实现，配置项版本的命名需要能清楚标识配置项的状态。公司 CVS配置管理库逻辑上分开发库、基线库和产品库，所有的配置项都保存在一个库中，对这三个库的划分是通过逻辑划分方式进行的，具体来说，就是通过配置项版本命名来划分的；SVN配置管理库物理上分开发库、受控库、基线库。我们配置项的版本命名规定如下： a) 基线版本基线版本由配置管理员进行标识。基线发布分正式基线和非正式基线。正式基线包括需求基线和产品基线；非正式基线通常包括概要设计基线、详细设计基线、代码/调试基线和测试基线。基线版本的标识一般使用“项目名称_基线名称_版本号”质量体系管理文

10、件内部文件 文件名称基线名称 命名 基线名称 命名需求基线 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值；只有当配置项版本升级幅度比较

11、大时，才允许增大 X值。处于“正在修改”状态的配置项的版本号格式为:X.Y Z，配置项正在修改时，一般只增大 Z值，X.Y 值保持不变。当配置项修改完毕，状态重新成为“正式发布”时，将 Z值设置为 0，增加 X.Y 值。例如：xxxxx_需求基线_正式发布首版本基线版本标识为：xxxx_REQ_BL1.00 b) 发布版本发布版本参照基线版本标识形式，将版本号前的 BL改为 Release即可。例如：xxxx_产品基线_正式发布客户首版本发布版本标识为：xxxx_PUR_ Release1.0c) 其他版本除基线版本外，有时候还需要在开发和维护过程中确定其他版本。例如，产品在测试过程中不断的问

12、题修复过程中，可能会有多种反复，此时需要将每次修改的内容作为一个版本。关于版本，还有另一个需要注意的问题。一般来说，按照模块来划分，每个模块有自己的版本演进比较合理。首先，一个模块一般是由一个或两个开发人员完成的；其次，一个模块的功能会比较单一且独立，在版本的演化过程中便于控制，也不会和其他模块产生过于复杂的关系。CVS 库中产品的版本需要由各个模块的不同版本组成，这个纵横的关系需要很好地管理，我们的做法是在 CVS库上用 Label来标识，同时维护一个描述产品版本质量体系管理文件内部文件 文件名称和模块版本关系的 readme.txt文件；SVN 库任何一次提交都会对所有文件增加到同一个新版

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

14、管理库由配置管理员管理。配置管理员负责分配和修改其他成员的权限，要维护所有目录和配置项。 4.2.2 项目经理 项目经理在本项目中负责主导完成需求分析和系统总体设计，对项目的总体进度负责。项目经理拥有对管理类文档的读取权限，可以对项目类文档进行读写操作；4.2.3 开发组长 开发组长对本小组的工作负有组织和管理任务，同时开发组长也需要承担一定的开发任务。开发组长对管理类文档有读取权限，对本组负责的模块有读取权限，对自己负责的模块有读写的权限；4.2.4 开发工程师 开发工程师完成具体的开发任务，对自己负责的模块目录有读写权限，对管理类文档有读取权限；质量体系管理文件内部文件 文件名称4.2.5

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

16、义我公司主营业务为外包软件开发，为方便多语言库的移植，配置管理库采用英文标识如下：项目配置库结构【项目简称】 （项目）trunk （开发主线 即开发库）DOC（项目文档类配置项存放文件夹）Requiremet（需求类）Design （设计类）Code （编码类）Test （测试类）PM （项目管理类）Maintenance （维护类）CM （配置管理类）QA （质量保证类）MA （度量类）Training （培训类） Release（实施类）Reference （参考文档）SRC ( 项目代码类配置存放文件夹)质量体系管理文件内部文件 文件名称BIN（项目数据、运行环境或第三方提供配置项存放文

17、件夹）branches （分支）tags （受控库）DOC（项目文档类配置项存放文件夹）SRC ( 项目代码类配置存放文件夹)BIN（项目数据、运行环境或第三方提供配置项存放文件夹）baseline （基线库）REQ_BL(需求基线)DD_BL (设计基线)CODE_BL(编码基线 )SysTest_BL(系统测试基线 )Proud_BL(产品基线)CVS配置库逻辑上分开发库、基线库和产品库，物理上只建开发库 develop和产品库Product ，基线库利用 CVS工具提供的标签实现；SVN配置库物理上分开发库、受控库和基线库。库结构存放内容说明：1、开发主线：日常开发进行的地方；2、分支：

18、存放分支拷贝；3、受控库：保存标签拷贝。这里存储内容作为一个里程碑的版本进行存档。当开发人员在自己的工作开发到一定程度后，认为可以提交测试或者提交给项目经理检查了，他可以提交到受控库；4、基线库：当预期的基线所包括的所有内容在受控库中都达到可基线化的状态时，可以将这些配置项转入基线库中；产品基线通过标记来注明，不单独设置产品库。基线的标签规范已在上一章节中描述，在此不再赘述。质量体系管理文件内部文件 文件名称5 配置管理工具及环境配置C V S 和 S V N 备份服务器C V S 和 S V N 服务器交换机网络防火墙路由器I n t e r n e t5.1 配置管理工具1、 CVS 并发

19、版本系统（ Concurrent Versions System）是当前主流的开放源码网络透明的版本控制系统。综合分析当前流程的配置管理工具 VSS、CC 、CVS、SVN，从其安全性、易用性、功能性以及成本几方面考虑，公司决定发展阶段选用开源CVS 技术进行版本控制，配置审计、变更控制等结合手动流程实现管理。待公司日渐扩大，软件过程能力成熟度达到一定等级时，再考虑引进配套的专业的配置管理工具。2、 CVS 工具是 C/S 客户服务器模式的开源版本控制技术，支持多个开发人员通过一个中心版本控制系统来记录文件版本，从而达到保证文件同步的目的。服务器端支持 WINDOWS 运行环境，同时给出了 W

20、INCVS 的视窗客户操作界面，可实现配置存储、版本控制备份等主要功能，同时提供集成平台下的应用环境。3、 SVN 相对于 CVS，采用了分支管理系统，它的设计目标就是取代 CVS。优于CVS 之处是：统一的版本号；原子提交；重命名、复制、删除文件等动作都保存质量体系管理文件内部文件 文件名称在版本历史记录当中；对于二进制文件，使用了节省空间的保存方法；目录也有版本历史；分支的开销非常小；优化过的数据库访问，使得一些操作不必访问数据库就可以做到；支持元数据管理。公司将逐步使用 SVN 替换 CVS。5.2 网络环境为确保配置库的安全稳定，公司采用双机备份的机制，共设两台相同环境的服务器，并实现定期备份的要求。对于远程开发项目，如必须，可将利用 INTERNET 网络，开放对外端口实现实时的版本控制。