001软件配置管理规范.doc

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配置管理目标配置管理目标.3 2配置管理的主要内容配置管理的主要内容.3 3配置管理角色、职责及权限配置管理角色、职责及权限.4 3.1配置经理.4 3.2项目负责人.4 3.3配置管理员（cmo）.5 3.4开发人员.5 3.5软件测试人员.5 3.6软件维护人员.6 3.7质量保证人员.6 3.8角色、权限图.6 4配置管理过程配置管理过程.8 5配置管理工具及环境配置管理工具及环境.9 5.1文件服务器.9 5.2配置管理工具.9 5.3配置服务器.9 6配置管理计划配置管理计划.10 6.1配置工具的选择.10 6.2配置库的基本目录结构.10 6.3权限设置.11 6.4配置项标识规定.11 6.5协作开发规定.11 6.6其它.11 7配置项管理配置项管理.11 7.1配置项标识号命名规范.12 7.2配置项名称命名规范.13 7.3程序文件、数据文件.14 8基线建立及变更管理基线建立及变更管理.14 9文档版本管理文档版本管理.16 9.1.文档版本及版本号的概念.16 9.2.版本号的定义及生成方法.16 9.3.定版的具体操作方法.17 9.4.定版的具体操作方法.17 10软件版本管理软件版本管理.18 10.1定版的具体操作方法.18 10.2版本号的定义及生成方法.18 4.1 软件配置管理规范 std-zs-kf-2010-003 4.3- 3/24 10.3定版的具体操作方法.19 10.4在 vss 上定版的具体操作方法20 10.5版本发布流程.20 10.6版本保存.20 11公用程序库的建立及公用程序库的建立及维维护护.21 12配置库的安全管理配置库的安全管理.21 12.1版本保存.21 12.2配置服务器的安全控制.21 12.3配置库备份.21 12.4配置管理平台维护.22 13工作空间管理工作空间管理.22 14变更文件的审批与确认变更文件的审批与确认.22 1配置管理目标配置管理目标 通过实施配置管理活动，令项目开发团队工作在一个规范的配置管理平台上，从而提高 软件产品质量、提高软件开发的整体工作效率，达到用户满意。同时，通过配置管理活动， 将项目开发过程中所有的产出、开发活动、管理活动等进行记录，以方便今后的软件维护及 类似项目的参照。 2 配置管理的主要内容配置管理的主要内容 软件开发的配置管理主要包括以下内容： 配置项标识的管理； 配置库的建立及变更管理； 版本控制； 配置管理计划编制； 公用程序库的建立及维护； 配置库的安全管理； 小组协作管理； 工作空间管理； 4.1 软件配置管理规范 std-zs-kf-2010-003 4.3- 4/24 3 配置管理角色、职责及权限配置管理角色、职责及权限 在配置管理平台下，软件开发人员按照不同的角色的要求、根据系统赋予的权限来执行 相应的动作。具体主要涉及下列的角色和分工： 3.13.1 配置经理配置经理 负责指导和控制部门配置管理的各项具体活动的进行，为项目经理的决策提供建议。配 置经理由指定的专人兼任，其具体职责为以下几项： 建立、管理部门配置管理平台； 建立项目配置库； 配置库的备份等安全管理； 制定配置管理规范； 辅助项目组建立配置管理环境； 审核配置管理计划； 指导项目组配置管理活动； 监督、考核各项目组配置管理活动的执行情况。 3.23.2 项目负责人项目负责人 项目负责人根据配置管理员的建议，批准、监督该项目配置管理的各项活动并控制它们 的进程。其具体职责为以下几项： 参与规划、制定和修改项目配置管理策略； 批准、发布配置管理计划； 决定项目起始基线和开发里程碑； 建立基线，审核基线变更申请； 制定配置管理相关权限策略； 监控配置管理过程； 项目负责人可以查看该项目配置库中配置项，在允许的权限内可以对配置项进行增、删、 改。 4.1 软件配置管理规范 std-zs-kf-2010-003 4.3- 5/24 3.33.3 配置管理员（配置管理员（cmocmo） 各项目组指定配置管理员，配置管理员根据配置管理计划执行该项目各项配置管理任务， 其具体职责为以下几项： 编制、提交配置管理计划； 严格管理配置项的操作权限； 执行版本控制流程； 执行变更控制方案； 建立开发人员的工作空间； 对开发人员进行相关的培训； 项目小组开发协作管理； 各配置项的日常管理与维护； 识别配置管理过程中存在的问题并拟就解决方案； 向配置经理、项目负责人定期汇报项目组配置管理情况。 配置管理员可以查看该项目配置库中配置项，在允许的权限内可以对配置项进行增、删、 改。 3.43.4 开发人员开发人员 开发人员的职责就是根据软件配置管理计划和相关规定，按照软件配置管理工具的使用 方式来完成开发任务。 开发人员可以查看、修改项目配置库中有权限的配置项，但不允许对配置项进行永久删 除操作。 3.53.5 软件测试人员软件测试人员 软件测试人员的职责就是根据软件配置管理计划和相关规定，按照软件配置管理工具的 使用方式来完成软件测试任务。 软件测试人员可以查看软件的相关开发文档，在权限范围内可以对配置项增加、修改， 但不允许对配置项进行永久删除操作。 4.1 软件配置管理规范 std-zs-kf-2010-003 4.3- 6/24 3.63.6 软件维护人员软件维护人员 软件维护人员的职责就是根据软件配置管理计划和相关规定，按照软件配置管理工具的 使用方式来完成软件维护任务。 软件维护人员可以查看、修改该人员负责维护的软件的相关开发文档、源程序，在权限 范围内可以对配置项增加、修改，但不允许对配置项进行永久删除操作。 3.73.7 质量保证人员质量保证人员 质量保证人员的职责就是根据软件配置管理计划和相关规定，按照软件配置管理工具的 使用模型来完成质量保证任务。 质量保证人员可以查看软件的相关开发文档，在权限范围内可以对配置项增加、修改， 但不允许对配置项进行永久删除操作。 3.83.8 角色、权限图角色、权限图 以下角色、权限图主要针对 vss 配置管理工具。 角色 project 配置经理 项目经理配置管理员开发人员软件测试人员质量保证人 员 准备阶段 rrcarcad r (ca 授权) r r (ca 授权) 需求分析阶段 rrcarcad r (ca 授权) rr 系统设计阶段 rrcarcad r (ca 授权)无 r 系统实现阶段 rrcarcad r (ca 授权)无无 系统测试阶段 rrcarcadrcarcar 系统维护阶段 rrcarcad r (ca 授权)无 r 质量保证 rrrcadrrrca 项目管理 rrcarcadr 无 r 配置管理 rrrcadrrr 测试管理 rrrcadrrcar 个人工作库 r 无 rcadrcad 无无 4.1 软件配置管理规范 std-zs-kf-2010-003 4.3- 7/24 项目共享库 rrcarcadrrr 项目基线库 r r (ca 授权) rcad r (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/24 4 配置管理过程配置管理过程 开 始 配置管理策划 评审 不通过 建立配置管理环境 通过 配置、标识和 管理 变更控制版本控制 基线审核和发 布 报告状态 发布产品 结束 配置管理的策划由项目组配置管理员负责，策划的结果为配置管理计划； 配置管理策划的评审由开发部配置经理、项目经理进行评审，形成相关的评审纪录； 配置管理环境由开发部配置经理负责； 配置库的具体管理由配置管理员负责，形成相关的记录，包括配置项信息登记表 、配置管理周报、配置管理工作表、软件配置管理评分表、变更申 请记录表、应用软件版本发布申请表、版本记录表、变更文件审批与 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 requirement statement) 需求规格说明书 ra(requirement analyse)需求分析阶段其他文档需求分析阶段其他文档 eis(external interface statement)外部接口规范说明文档 hld(holistic design)概要设计文档总体方案：-totle dds(detail design statement)详细设计文档 dbd(database design)数据库设计文档数据字典：-dictionary design 设计阶段其他文档设计阶段其他文档 软件架构设计： -architecture；阶段计划： -plan；阶段总结报告： -summarize scode(source code)源代码文件 4.1 软件配置管理规范 std-zs-kf-2010-003 4.3- 13/24 ecode（executable code）执行代码文件 cf(configure file)配置文件 code实现阶段其他文档实现阶段其他文档 阶段计划：-plan；阶段总结 报告：-summarize utest(unit test)单元测试文档单元测试记录：-record itest(integration test)集成测试文档集成测试记录：-record test测试阶段文档测试阶段文档 测试计划：-plan；测试方案： -scheme；测试案例：-case 测试记录：-record；测试问 题：-problem；测试分析报 告:-summarize man软件说明书和手册 操作手册：-operate；用户手 册：-user；维护手册：- maintenance；安装手册：-setup issue产品发行文档产品发行文档发行记录：-record delivery交付阶段文档交付阶段文档 switch切换阶段文档切换阶段文档切换方案：-scheme smsyyyymm0199 (software maintain statement) 软件维护说明书 maintain维护阶段其他文档维护阶段其他文档维护记录：-record pds(project development summarize)项目开发总结报告 rtm(requirement track matric)需求跟踪矩阵 cryyyymm0199(change record)变更控制号 pryyyymmddaz(peer review)评审号 train培训记录和培训文档培训记录：-record project项目其他文档 注 1：粗体部分的配置类别是按软件生存周期的阶段划分的，如配置项具有明确的阶段 性，但不属于某类具体的配置类别，则纳入所属阶段的配置类别中；如是贯穿项目多个 阶段或归属于项目整体的配置项，且不属于某类具体的配置类别，则纳入“project”配置 类别中。 4.1 软件配置管理规范 std-zs-kf-2010-003 4.3- 14/24 7.27.2 配置项名称命名规范配置项名称命名规范 开发技术文档名称通过项目名称标识或项目简称文档类别名称进行命名，主要包括以下文 档： 可行性研究报告； 项目开发计划； 配置管理计划 质量保证计划； 测试计划； 程序开发规范； 需求规格说明书； 总体设计说明书； 概要设计说明书； 详细设计说明书； 数据库设计说明书； 用户手册； 维护手册； 部分文档名称命名时需附加相关信息，主要包括以下文档： 项目周报：项目名标识或项目简称“_项目周报_yyyymmdd” 软件开发进度月报：项目名标识或项目简称“_月报_yyyymmdd” 子项目周报：项目名标识或项目简称“_子项目简称_周报_yyyymmdd” 质量周报：项目名标识或项目简称“_质量周报_yyyymmdd” 会议纪要：项目名标识或项目简称“_会议纪要_yyyymmdd” 软件维护说明书：项目名标识或项目简称“_软件维护说明书_yymm0199” 变更记录：项目名标识或项目简称“_变更记录_yymm0199” 评审记录：项目名标识或项目简称“_评审记录_yymmddaz” 说明：斜体部分根据实际情况用相应内容替代。 7.37.3 程序文件、数据文件程序文件、数据文件 按项目开发规范要求执行。 4.1 软件配置管理规范 std-zs-kf-2010-003 4.3- 15/24 8 基线建立及变更管理基线建立及变更管理 基线的是已经正式通过审核批准的某阶段成果，它可作为进一步开发的基础，并且只能 通过正式的变化控制过程改变。一般在某阶段成果通过评审后，对该成果建立基线，纳入基 线管理。（在项目开发的里程碑阶段一般要建立项目基线）。开发过程的阶段成果可以纳入 基线管理的主要有：项目开发计划、测试计划、质量保证计划、业务需求说明书、需求分析 说明书、总体设计说明书、概要设计说明书、程序开发规范、数据库设计说明书、软件维护 手册、用户手册、测试案例、已通过测试的软件版本等。 对项目的每个基线对应一个唯一的标识号。基线标识可采用“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.3 draft 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.3 2010.07.081.1在 1.2.4 中在增 加 张三xxx-cr20040601 10 软件版本管理软件版本管理 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.3 test 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.2 ver 1.2.0.1 - ver 1.2.1.0 ver 1.3.9.0 - ver 1.3.8.1 ver 1.3.9.0 - ver 1.3.10.0 10.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/24 10.610.6 版本保存版本保存 配置管理员必须保证发布版本源程序的完整性及一致性，质量保证人员保证发布版本的 文档的完整性，配置经理及对每一次发布的版本，在配置库中对应地建立版本标识，随配置库备份 刻录光盘时，交综合人员登记并永久保存，综合人员应在光盘标签上标注光盘内容、备份时间、提 交人员，以便查阅。对光盘的查阅必须经部门负责人同意。 11 公用程序库的建立及维护公用程序库的建立及维护 公用程序主要包括： 公用函数模块：提供某一特定功能。 公用类模块：提供具有通用性的类的定义及方法实现。 加密模块：各项目组涉及加密的功能模块由专人开发。 自行开发实用工具：各项目组开发的实用工具。 实现某一功能的完整程序；例如采用 socket 的通讯程序。 具有普遍实用的程序框架；例如 sco unix 下终端程序框架。 其他； 各项目组在项目开发过程中应