001软件配置管理规范

4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 1/24文件编号STD-ZS-KF-2010-001中山森中山森创创信息技信息技术术有限公司有限公司版本/修改A/0文件名称文件名称软件配置管理规范页数共 22 页中山森创信息技术有限公司中山森创信息技术有限公司软件配置管理规范软件配置管理规范版权所有，未经双方许可不得复制或对外传阅版权所有，未经双方许可不得复制或对外传阅4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 2/24目目 录录1配置管理目标配置管理目标.32配置管理的主要内容配置管理的主要内容.33配置管理角色、职责及权限配置管理角色、职责及权限.43.1配置经理.43.2项目负责人.43.3配置管理员（CMO）.53.4开发人员.53.5软件测试人员.53.6软件维护人员.63.7质量保证人员.63.8角色、权限图.64配置管理过程配置管理过程.85配置管理工具及环境配置管理工具及环境.95.1文件服务器.95.2配置管理工具.95.3配置服务器.96配置管理计划配置管理计划.106.1配置工具的选择.106.2配置库的基本目录结构.106.3权限设置.116.4配置项标识规定.116.5协作开发规定.116.6其它.117配置项管理配置项管理.117.1配置项标识号命名规范.127.2配置项名称命名规范.137.3程序文件、数据文件.148基线建立及变更管理基线建立及变更管理.149文档版本管理文档版本管理.169.1.文档版本及版本号的概念.169.2.版本号的定义及生成方法.169.3.定版的具体操作方法.179.4.定版的具体操作方法.1710软件版本管理软件版本管理.1810.1定版的具体操作方法.1810.2版本号的定义及生成方法.184.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 3/2410.3定版的具体操作方法.1910.4在 VSS 上定版的具体操作方法.2010.5版本发布流程.2010.6版本保存.2011公用程序库的建立及公用程序库的建立及维维护护.2112配置库的安全管理配置库的安全管理.2112.1版本保存.2112.2配置服务器的安全控制.2112.3配置库备份.2112.4配置管理平台维护.2213工作空间管理工作空间管理.2214变更文件的审批与确认变更文件的审批与确认.221配置管理目标配置管理目标通过实施配置管理活动，令项目开发团队工作在一个规范的配置管理平台上，从而提高软件产品质量、提高软件开发的整体工作效率，达到用户满意。同时，通过配置管理活动，将项目开发过程中所有的产出、开发活动、管理活动等进行记录，以方便今后的软件维护及类似项目的参照。2 配置管理的主要内容配置管理的主要内容软件开发的配置管理主要包括以下内容：配置项标识的管理；配置库的建立及变更管理；版本控制；配置管理计划编制；公用程序库的建立及维护；配置库的安全管理；小组协作管理；工作空间管理；4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 4/243 配置管理角色、职责及权限配置管理角色、职责及权限在配置管理平台下，软件开发人员按照不同的角色的要求、根据系统赋予的权限来执行相应的动作。具体主要涉及下列的角色和分工：3.13.1 配置经理配置经理负责指导和控制部门配置管理的各项具体活动的进行，为项目经理的决策提供建议。配置经理由指定的专人兼任，其具体职责为以下几项：建立、管理部门配置管理平台；建立项目配置库；配置库的备份等安全管理；制定配置管理规范；辅助项目组建立配置管理环境；审核配置管理计划；指导项目组配置管理活动；监督、考核各项目组配置管理活动的执行情况。3.23.2 项目负责人项目负责人项目负责人根据配置管理员的建议，批准、监督该项目配置管理的各项活动并控制它们的进程。其具体职责为以下几项：参与规划、制定和修改项目配置管理策略；批准、发布配置管理计划；决定项目起始基线和开发里程碑；建立基线，审核基线变更申请；制定配置管理相关权限策略；监控配置管理过程；项目负责人可以查看该项目配置库中配置项，在允许的权限内可以对配置项进行增、删、改。4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 5/243.33.3 配置管理员（配置管理员（CMOCMO）各项目组指定配置管理员，配置管理员根据配置管理计划执行该项目各项配置管理任务，其具体职责为以下几项：编制、提交配置管理计划；严格管理配置项的操作权限；执行版本控制流程；执行变更控制方案；建立开发人员的工作空间；对开发人员进行相关的培训；项目小组开发协作管理；各配置项的日常管理与维护；识别配置管理过程中存在的问题并拟就解决方案；向配置经理、项目负责人定期汇报项目组配置管理情况。配置管理员可以查看该项目配置库中配置项，在允许的权限内可以对配置项进行增、删、改。3.43.4 开发人员开发人员开发人员的职责就是根据软件配置管理计划和相关规定，按照软件配置管理工具的使用方式来完成开发任务。开发人员可以查看、修改项目配置库中有权限的配置项，但不允许对配置项进行永久删除操作。3.53.5 软件测试人员软件测试人员软件测试人员的职责就是根据软件配置管理计划和相关规定，按照软件配置管理工具的使用方式来完成软件测试任务。软件测试人员可以查看软件的相关开发文档，在权限范围内可以对配置项增加、修改，但不允许对配置项进行永久删除操作。4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 6/243.63.6 软件维护人员软件维护人员软件维护人员的职责就是根据软件配置管理计划和相关规定，按照软件配置管理工具的使用方式来完成软件维护任务。软件维护人员可以查看、修改该人员负责维护的软件的相关开发文档、源程序，在权限范围内可以对配置项增加、修改，但不允许对配置项进行永久删除操作。3.73.7 质量保证人员质量保证人员质量保证人员的职责就是根据软件配置管理计划和相关规定，按照软件配置管理工具的使用模型来完成质量保证任务。质量保证人员可以查看软件的相关开发文档，在权限范围内可以对配置项增加、修改，但不允许对配置项进行永久删除操作。3.83.8 角色、权限图角色、权限图以下角色、权限图主要针对 VSS 配置管理工具。角色Project配置经理项目经理配置管理员开发人员软件测试人员质量保证人员准备阶段RRCARCADR (CA 授权)RR (CA 授权)需求分析阶段RRCARCADR (CA 授权)RR系统设计阶段RRCARCADR (CA 授权)无R系统实现阶段RRCARCADR (CA 授权)无无系统测试阶段RRCARCADRCARCAR系统维护阶段RRCARCADR (CA 授权)无R质量保证RRRCADRRRCA项目管理RRCARCADR无R配置管理RRRCADRRR测试管理RRRCADRRCAR个人工作库R无RCADRCAD无无4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 7/24项目共享库RRCARCADRRR项目基线库RR (CA 授权)RCADR (CA 授权)R (CA 授权)RCA注：1.权限R表示具有 Read 权限。C表示具有 Check in/Check out 权限。A表示具有 Add/Rename/Delete 权限。D表示具有 Destroy 权限。无表示不具有该项权限。授权表示需要项目负责人根据需要配置相应权限。2.由于配置管理员具有最高权限，可以进行任何操作，但执行非 Read 操作时必须经项目负责人同意。3. 个人工作空间允许拥有者进行任何操作，包括 destroy 操作。4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 8/244 配置管理过程配置管理过程开 始配置管理策划评审不通过建立配置管理环境通过配置、标识和管理变更控制版本控制基线审核和发布报告状态发布产品结束配置管理的策划由项目组配置管理员负责，策划的结果为配置管理计划；配置管理策划的评审由开发部配置经理、项目经理进行评审，形成相关的评审纪录；配置管理环境由开发部配置经理负责；配置库的具体管理由配置管理员负责，形成相关的记录，包括配置项信息登记表、配置管理周报、配置管理工作表、软件配置管理评分表、变更申请记录表、应用软件版本发布申请表、版本记录表、变更文件审批与4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 9/24确认登记表。5配置管理工具及环境配置管理工具及环境5.15.1 文件服务器文件服务器在开发部建立独立的文件服务器，文件服务器的主要作用为：提供共享程序服务将常用应用程序（包括开发工具、数据库工具、管理工具等）存放共享目录下，方便各开发人员随时使用，并提供共享目录以便各开发人员上传共享程序。提供共享资料服务将常用资料存放共享目录下，方便各开发人员随时使用，并提供共享目录以便各开发人员上传共享文档。提供开发人员个人空间为每个开发人员建立个人目录，开发人员可将关键文档在文件服务器上进行备份。此为开发人员的私有目录，别人无权访问。5.25.2 配置管理工具配置管理工具可采用以下配置管理工具：Microsoft Visual Sourcesafe(VSS)基于 WINDOWS 的开发采用 Microsoft Visual Sourcesafe(VSS)作为配置管理工具。基于 UNIX 下的开发采用 Samba 作为磁盘映射工具，Microsoft Visual Sourcesafe(VSS)作为配置管理工具。CVS 工具基于 UNIX 下的开发采用 CVS 作为程序版本控制工具，同时在 WINDOWS 环境下用VSS 建立项目文档等配置项的管理环境。5.35.3 配置服务器配置服务器在开发部建立统一的配置服务器，逐步进行配置库的集中管理，项目组内部不再单4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 10/24独设立配置服务器。配置服务器今后将成为软件开发的项目库，记录所有软件开发项目的开发及维护过程。对新项目的开发，项目负责人可以申请查阅配置库中相类似的项目资料，以更好地把握新项目的开发。配置服务器也是开发部的公用程序库服务器。各项目组在项目开发过程中有义务将通用的程序模块放入公用程序库中，被其他项目组使用，达到程序共享，避免重复开发。公用程序库的建立及维护见第八章。6 配置管理计划配置管理计划配置管理计划应细化以下内容：6.16.1 配置工具的选择配置工具的选择配置管理计划中明确采用的配置工具，如采用 unix 下的 CVS 工具，还必须编写完善的配置操作脚本，并注明使用方法。6.26.2 配置库的基本目录结构配置库的基本目录结构根据具体的项目设置配置库的基本目录结构，并进行基本的解释，一般可以包含以下的一级目录及二级目录：01 项目工作库 01 准备阶段 02 需求分析阶段 03 系统设计阶段 04 系统实现阶段 05 系统测试阶段 06 运行推广阶段 07 系统维护阶段02 项目管理库 01 质量保证 02项目管理 03配置管理 04测试管理03 项目共享库4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 11/24 01 项目模版02 项目规范03 项目制度04 共享资料04 项目基线库01 计划基线02 需求基线03 设计基线04 产品基线05 个人工作库下设每个项目组成员的目录06 其他6.36.3 权限设置权限设置明确项目组成员对各配置目录的操作权限。6.46.4 配置项标识规定配置项标识规定根据项目规模和实际情况的不同，在项目的配置管理计划中详细规定配置项标识的命名规则。6.56.5 协作开发规定协作开发规定在项目的配置管理计划中，必须对项目组的协作开发作相应的规定，比如，项目成员每日的工作是否必须提交？更改了公用头文件如何通知项目组成员？等等，具体项目具体规定。6.66.6 其它其它7 配置项管理配置项管理配置项是配置管理的对象，主要包括各种开发/测试文档、源程序、测试脚本、关键数据、项目报告、会议纪要等。通过建立配置库对配置项的维护、变更等进行管理，对配置项4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 12/24要进行统一的配置标识管理及名称管理。配置标识就是为产品的结构、产品的构件及其类型，分配唯一的标识符，具体项目可根据项目规模和实际情况的不同，在项目的配置管理计划中进一步补充、删减、细化配置项标识的命名规则。开发部的配置项标识及名称总体规则如下：7.17.1 配置项标识号命名规范配置项标识号命名规范配置项标识号命名规则：项目名标识-配置类别-子系统标识-组成部分标识-模块标识-配置项特殊标识，其中中的内容可根据系统规模和实际情况有所省略，项目名标识、配置项特殊标识一般是约定俗成的英文代码名。下表列出了我们在项目中使用的配置类别命名：配置类别配置类别说明说明常用配置项特殊标识举例常用配置项特殊标识举例PDP(Project Development Plan)项目开发计划CMP(Configure Management Plan)配置管理计划QAP(Quality Assurance Plan)质量保证计划FRR(Feasibility Research Report)可行性研究Init准备阶段其他文档准备阶段其他文档CRS(Client Requirement Statement)客户需求SRS(Software RequirementStatement)需求规格说明书RA(Requirement Analyse)需求分析阶段其他文档需求分析阶段其他文档EIS(External Interface Statement)外部接口规范说明文档HLD(Holistic Design)概要设计文档总体方案：-TotleDDS(Detail Design Statement)详细设计文档DBD(Database Design)数据库设计文档数据字典：-DictionaryDesign设计阶段其他文档设计阶段其他文档软件架构设计：-Architecture；阶段计划：-Plan；阶段总结报告：-SummarizeSCODE(Source Code)源代码文件4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 13/24ECODE（Executable Code）执行代码文件CF(Configure File)配置文件Code实现阶段其他文档实现阶段其他文档阶段计划：-Plan；阶段总结报告：-SummarizeUTest(Unit Test)单元测试文档单元测试记录：-RecordITest(Integration Test)集成测试文档集成测试记录：-RecordTest测试阶段文档测试阶段文档测试计划：-Plan；测试方案：-Scheme；测试案例：-Case测试记录：-Record；测试问题：-Problem；测试分析报告:-SummarizeMan软件说明书和手册操作手册：-Operate；用户手册：-User；维护手册：-Maintenance；安装手册：-SetupIssue产品发行文档产品发行文档发行记录：-RecordDelivery交付阶段文档交付阶段文档Switch切换阶段文档切换阶段文档切换方案：-SchemeSMSyyyymm0199 (Software Maintain Statement)软件维护说明书Maintain维护阶段其他文档维护阶段其他文档维护记录：-RecordPDS(Project Development Summarize)项目开发总结报告RTM(Requirement Track Matric)需求跟踪矩阵CRyyyymm0199(Change Record)变更控制号PRyyyymmddAZ(Peer Review)评审号Train培训记录和培训文档培训记录：-RecordProject项目其他文档注 1：粗体部分的配置类别是按软件生存周期的阶段划分的，如配置项具有明确的阶段性，但不属于某类具体的配置类别，则纳入所属阶段的配置类别中；如是贯穿项目多个阶段或归属于项目整体的配置项，且不属于某类具体的配置类别，则纳入“Project”配置类别中。4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 14/247.27.2 配置项名称命名规范配置项名称命名规范开发技术文档名称通过项目名称标识或项目简称文档类别名称进行命名，主要包括以下文档：可行性研究报告；项目开发计划；配置管理计划质量保证计划；测试计划；程序开发规范；需求规格说明书；总体设计说明书；概要设计说明书；详细设计说明书；数据库设计说明书；用户手册；维护手册； 部分文档名称命名时需附加相关信息，主要包括以下文档：项目周报：项目名标识或项目简称“_项目周报_YYYYMMDD”软件开发进度月报：项目名标识或项目简称“_月报_YYYYMMDD”子项目周报：项目名标识或项目简称“_子项目简称_周报_YYYYMMDD”质量周报：项目名标识或项目简称“_质量周报_YYYYMMDD”会议纪要：项目名标识或项目简称“_会议纪要_YYYYMMDD”软件维护说明书：项目名标识或项目简称“_软件维护说明书_YYMM0199”变更记录：项目名标识或项目简称“_变更记录_YYMM0199”评审记录：项目名标识或项目简称“_评审记录_YYMMDDAZ”说明：斜体部分根据实际情况用相应内容替代。7.37.3 程序文件、数据文件程序文件、数据文件按项目开发规范要求执行。4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 15/248 基线建立及变更管理基线建立及变更管理基线的是已经正式通过审核批准的某阶段成果，它可作为进一步开发的基础，并且只能通过正式的变化控制过程改变。一般在某阶段成果通过评审后，对该成果建立基线，纳入基线管理。（在项目开发的里程碑阶段一般要建立项目基线）。开发过程的阶段成果可以纳入基线管理的主要有：项目开发计划、测试计划、质量保证计划、业务需求说明书、需求分析说明书、总体设计说明书、概要设计说明书、程序开发规范、数据库设计说明书、软件维护手册、用户手册、测试案例、已通过测试的软件版本等。对项目的每个基线对应一个唯一的标识号。基线标识可采用“BL” +“基线版本号”“-”+“基线日期（YYMMDD）表示。基线类别定义如下：需求基线、设计基线、测试基线、代码基线基线版本号由 2 个数字组成，格式为：BL1.0第一位：对每个基线类型（需求基线、设计基线、测试基线、代码基线等），都从 1 开始，增改编幅或重要性比例大于 10，则在原来的基础上加 1。第二位：增改编幅或重要性比例小于 10，则在原来的基础上加 1例如： “BL1.0-050101”表示进入基线管理的阶段成果，是经过评审通过的，配置管理员对其必须进行严格的权限控制，一般只允许读取，不允许修改，确实需要修改的，执行变更管理流程。变更管理的一般流程是：A) 获得/提出变更请求；B) 变更预计影响的评估，包括可能受影响配置项以及对资源、进度、质量等影响的分析，描述实施方案；C) 项目经理审核并决定是否批准，必要时报请领导批准；D) 如变更请求被接受，由配置管理员从配置库中检出配置项，赋予相关人员修改的权限；E)项目组实施变更，修改配置项的内容，提交确认，如不通过则返回项目组继续修改；F)配置管理员回收相关权限，把配置项检入，形成新基线版本，发布新版本，并4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 16/24发布变更通知给所有相关人员，包括项目组成员、质量保证人员、测试人员及其它部门人员等。9 文档版本管理文档版本管理9.1.9.1. 文档版本及版本号的概念文档版本及版本号的概念文档的版本用于区别文档的不同状态。每个版本都有唯一的版本号进行标识。版本的概念对于文档不同的阶段还可以细分为草稿版本（Draft Versions）、版本（Versions）。草稿版本号：未定稿的文档的版本号称为草稿版本号。版本号：已定稿的文档的版本号称为版本号。9.2.9.2. 版本号的定义及生成方法版本号的定义及生成方法草稿版本号未定稿的文档，在经过修改后，如果觉得有需要，可由负责编写文档的人员制定出新的草稿版本号。草稿版本号由前缀加 2 个数字组成，格式为：DRAFT 0.1第一位：固定为 0第二位：在原来的基础上加 1草稿版本号的起始标识为：DRAFT 0.1草稿版本号的变动：第 2 位数字在原来的基础上加 1。例如：DRAFT 0.2 - DRAFT 0.3DRAFT 0.8 - DRAFT 0.9版本号的生成定稿的文档，每次的修订后，视文档的重要性由不同权限的人员制定出新的版本号。一般的文档或者重要文档中的单个文档是可由负责编写文档的人员制定出新的版本号。重要的文档如需求规格说明书详细设计等阶段性文档，由项目配置管理员与项目经理协商，在征得项目经理同意后制定出新的版本号。4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 17/24版本号由前缀加 2 个数字组成，格式为：VER 1.0第一位：增改编幅或重要性比例大于 10第二位：增改编幅或重要性比例小于 10版本号的起始标识为：VER 1.0版本号的变动：根据其实际情况选择相应位置的数值加 1，并将该位置右边的所有数值置 0。例如：VER 1.1 - VER 1.2 9.3.9.3. 定版的具体操作方法定版的具体操作方法文档的定版必须在文档开始处按模板要求填写表格。并在 checkin 到 vss 时将该版本的改动内容填写到 Comment 中。同时还要遵照变更文件审批与确认的规定执行（详见本文相关段落）。9.4.9.4. 定版的具体操作方法定版的具体操作方法示例 1，文挡封面处：XXX 系统系统需求规格说明书需求规格说明书示例 2，文挡信息部分：文档编号版本号密级XXX-SRS1.1秘密Sun Trend中山市森创公司开发部文档名称：XXX 系统_需求规格说明书共 120 页修订历史记录日期日期版本号版本号修订内容修订内容修订人修订人评审号评审号变更控制号变更控制号2010.06.090.9新建张三2010.06.121.0根据评审问题修改张三XXX-PR20040612秘密/机密/绝密当前版本号4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 18/24章节 1.1.32010.07.081.1在 1.2.4 中在增加张三XXX-CR2004060110 软件版本管理软件版本管理10.110.1 定版的具体操作方法定版的具体操作方法版本用于区别软件产品的不同状态。每个版本都有唯一的版本号进行标识。版本的概念对于不同的软件产品和不同的阶段还可以细分为测试版本（Test Versions）、版本（Versions）。测试版本号：提供测试的可执行文件的版本称为测试版本号。版本号：通过测试的可执行文件的版本称为版本号。10.210.2 版本号的定义及生成方法版本号的定义及生成方法测试版本号可执行文件的各部分通过单元测试，总体编译通过，由项目配置管理员与项目经理协商，在项目经理同意下制定出新的测试版本号。测试版本号由前缀加 2 个数字组成，格式为：TEST 0.1第一位：固定为 0第二位：在原来的基础上加 1测试版本号的起始标识为：TEST 0.1测试版本号的变动：第 2 位数字在原来的基础上加 1。例如：TEST 0.2 - TEST 0.3TEST 0.18 - TEST 0.19版本号的生成可执行文件的各部分通过单元测试，总体编译通过，并通过了系统测试，由项目配置管理员与项目经理协商，在项目经理同意下制定出新的版本号。4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 19/24版本号由前缀加 4 个数字组成，格式为：VER 1.0.0.0其中，后两个数字可选，即如果后两个数字同时为 0 时，可以同时省去。但版本号一定是两个或四个数字。第一位：系统整个框架性设计改动或者业务功能的增改编幅或重要性比例大于 10第二位：系统部分设计改动或者业务功能的增改编幅或重要性比例大于 5第三位：系统的代码改动或者业务功能的增改编幅或重要性比例小于 5第四位：对系统的 BUG 修改或者业务功能的增改编幅或重要性均微小。版本号的起始标识为：VER 1.0版本号的变动：根据其实际情况选择相应位置的数值加 1，并将该位置右边的所有数值置 0。如果在同一次的修订中，同时出现两个或以上位置的数值都符合改变的情况时，只需按照符合条件的最左位的数值加 1，并将该位置右边的所有数值置 0。如果后两个数字同时为0 时，可以同时省去。例如：VER 1.1.2.1 - VER 1.2.0.0 - VER 1.2VER 1.2.0.1 - VER 1.2.1.0VER 1.3.9.0 - VER 1.3.8.1VER 1.3.9.0 - VER 1.3.10.010.310.3 定版的具体操作方法定版的具体操作方法每个项目必须有一份版本记录表。当需要生成一个测试版本时，填写测试版本一栏信息。当某一个测试版本通过了测试，有条件生成一个版本时，在该测试版本所对应的一行中填上版本一栏信息。当某一个版本需要发布，在该版本所对应的一行中填上发布一栏信息测试版本号和版本号均由项目配置管理员与项目经理协商，在项目经理同意下制定。版本号栏可根据实际情况填写，发布版本号为空。版本类型栏选择填写以下之一：测试版本、版本、发布。对于测试版本的注释栏填写该测试版本与上一测试版本的不同之处，对于版本的注释栏填写该版本对应的测试版本号以及与上一版本的不同之处，对于发布的注释栏填写该版本发布对应的版本号以及对生产的影响等情况。项目负责人栏电子文档填写项目负责人姓名，纸质文件由项目负责人签名。4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 20/24配置管理员栏电子文档填写项目配置管理员姓名，纸质文件由项目配置管理员签名。其他相关人员栏如有需要电子文档填写其他相关人员姓名，纸质文件由其他相关人员签名。其他相关人员如公司经理。项目配置管理员负责填写版本记录表，并对VSS 库中的源代码加上版本号并填上注释。版本记录表项目名称：序号版本号定版日期版本类型注释项目负责人配置管理员其他相关人员10.410.4 在在 VSSVSS 上定版的具体操作方法上定版的具体操作方法在 VSS 上，可以通过加 Lable 的功能实现对系统中所有的源代码文件进行加版本号的管理。当需要加测试版本号是，选择所有源代码的最高一级目录，为其加上 Lable，Lable 为：Test0.1（0.1 为具体的测试版本号），并在 Comment 中填上该测试版的定版日期和注释。操作完成后，VSS 对该目录一下的所有子目录及文件均加上相同的 Lable 和 Comment。当需要加版本号时，选择所有源代码的最高一级目录，按右键并选择显示历史信息，然后在信息中选中标有该版本对应的测试版本号的 Lable，双击。在回显框上，修改 Lable，加上当前的版本号，修改后的 Lable为：Test0.1Ver1.2.2.2（0.1为具体的测试版本号, 1.2.2.2为具体的版本号），并在 LableComment 中填上该版本的定版日期和注释。操作完成后，VSS对该目录一下的所有子目录及文件均改为相同的 Lable 和 LableComment。当某一版本需要发布时，按上述操作，选择对应的 Lable，并在相应的 LableComment 中加上发布日期及注释。10.510.5 版本发布流程版本发布流程4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 21/24项目组软件版本发布流程如下图所示：序号序号流程流程责任人责任人相关人员相关人员文件文件/ /记录记录说明说明A01配置管理员配置管理员 、软件开发人员 用户测试报告、开发、维护文档、应用软件版本发布申请表开发及维护文档必须存放项目配置库中A02各项目部门负责人、局领导项目经理、开发人员应用软件版本发布申请表严格审核出部门、公司的技术文档。A03配置管理员、 相关部门项目经理软件版本、技术资料A04软件接收部门开发人员书面通知书内容包括：版本发布原因、版本业务功能、安装时间、影响范围、安装后业务验证内容A05项目负责人开发人员必要时提供现场技术支持。A06用户、测试组开发人员业务验证测试报告根据需要进行A07项目负责人维护人员、开发人员必要时现场技术支持A08开始A01提交版本发布申请A02审核版本发布申请A03版本交付是否需要业务部门验证测试A04业务验证测试通知是A05版本安装技术支持否A06业务验证测试A07系统运行技术支持A08保存版本结束配置管理员综合人员光盘可备份配置库时进行备份4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 22/2410.610.6 版本保存版本保存配置管理员必须保证发布版本源程序的完整性及一致性，质量保证人员保证发布版本的文档的完整性，配置经理及对每一次发布的版本，在配置库中对应地建立版本标识，随配置库备份刻录光盘时，交综合人员登记并永久保存，综合人员应在光盘标签上标注光盘内容、备份时间、提交人员，以便查阅。对光盘的查阅必须经部门负责人同意。11 公用程序库的建立及维护公用程序库的建立及维护公用程序主要包括：公用函数模块：提供某一特定功能。公用类模块：提供具有通用性的类的定义及方法实现。加密模块：各项目组涉及加密的功能模块由专人开发。自行开发实用工具：各项目组开发的实用工具。实现某一功能的完整程序；例如采用 SOCKET 的通讯程序。具有普遍实用的程序框架；例如 SCO UNIX 下终端程序框架。其他；各项目组在项目开发过程中应注意提炼公用程序，共同建设好公用程序库，为今后的项目开发省时省力。配置经理建立及维护公用程序库，接受、审核公用程序，定期公布公用程序清单。项目负责人可以根据需要提出使用公用程序的申请，部门负责人审核同意后，配置经理提供相应程序。12 配置库的安全管理配置库的安全管理12.112.1 版本保存版本保存项目负责人必须明确每个项目成员的操作权限，对配置项的永久删除权限必须严格控制。4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 23/2412.212.2 配置服务器的安全控制配置服务器的安全控制配置经理负责配置服务器的系统管理，不允许其他人登录配置服务器进行操作。配置经理必须做好配置服务器的病毒防范及网络安全控制。12.312.3 配置库备份配置库备份配置经理负责进行配置库的备份，主要有：1)每日备份每日下班前，配置经理备份配置库中所有配置项，每周循环。2)每月备份配置经理每月定期备份文件服务器的共享目录及配置服务器中配置库文件，刻录光盘由综合人员存放，填写配置库备份登记表。12.412.4 配置管理平台维护配置管理平台维护配置经理负责配置管理平台的维护，填写开发部配置管理平台维护日志、配置管理平台信息表，具体包括：建立项目配置库；维护相关人员的权限：系统软件升级；病毒防范；系统资源维护；13工作空间管理工作空间管理整个配置库是一个统一的工作空间，可以进一步划分为个人空间、项目组空间和共享空间这三类工作空间。个人空间是开发人员的私有工作空间，开发人员在自己的个人空间进行开发活动，不会受到他人的影响，也不会影响到其他开发人员，在个人开发空间开发出的成果，最终提交到项目组空间中。项目组空间是开发团队的成果空间以及团队共享空间，对项目组空间的配置项的操作，配置管理员必须做好权限控制及协调管理。共享工作空间是项目4.1 软件配置管理规范STD-ZS-KF-2010-003 4.3- 24/24组中子项目组共同工作的空间，子项目组成员拥有对该空间的读写权限。共享工作空间根据需要建立。配置管理员及项目负责人必须做好工作空间的分配及管理。14变更文件的审批与确认变更文件的审批与确认为了规范化管理，明确责任，避免风险，项目组要做好变更文件的审批与确认工作。规定每个项目一本变更文件审批与确认登记表，在项目启动时由项目经理负责建立，填写好项目名称和相关职责人员姓名。在项目开发生命周期内，由项目组配置代表管理，不得遗失和毁坏。属于下列情况之一者，必须有相关人员在变更文件审批与确认登记表上签字：项目的各项计划的制定需要主管部门经理审批，并得到相关部门、相关组或客户的确认。对用户需求进行分析整理而成的文档需要经过相关组和部门的确认，并得到用户的认可。各个阶段的技术文档要得到相关组和个人的认可。项目组内所有的变更要得到项目经理的认可。涉及到资源、约定的变更要得到主管部门经理的批准，并和相关部门进行协调确认。所有的变更要通知所有受影响的组和个人。工作产品交接需要相关人员确认。工作汇报或状态报告需要上级主管确认。凡签名者，均对相关内容负责，包括风险、保密和责任等方面。如果不能承担责任者，则需要报送高一级经理批准。签名者必须用黑色墨水笔认真书写自己真实、完整的姓名，不得随意涂改。在项目交付完成后，将变更文件审批与确认登记表交开发部综合人员归档保存。（完）（完）