软件配置管理规范实施细则.doc

软件配置管理规范 XXXXXXXXXXXXXXx科技有限公司iii目 录1 配置管理规范 11.1 概要 11.1.1 内容 11.1.2 适用范围 11.1.3 术语和缩略语 11.2 相关人权责 31.2.1 项目经理（Project Manager，PM） 31.2.2 配置控制委员会（Configuration Control Board，CCB） 31.2.3 配置管理员（Configuration Management Officer，CMO） 31.2.4 开发人员（Developer） 41.2.5 测试人员（Tester） 41.2.6 软件质量保证员（Software Quality Assurance，SQA） 41.3 实施细则 51.3.1 配置控制委员会的成立 51.3.2 确定配置策略 51.3.3 制定配置管理计划 61.3.4 配置项管理 71.3.5 配置库管理 111.3.6 配置项基线管理 141.3.7 配置变更控制 161.3.8 配置状态报告 211.3.9 配置审核 211.3.10 发行管理 221.4 相关文件 231.4.1 《配置管理计划》 231.4.2 《配置库管理报告》 231.4.3 《配置项变更控制报告》 232 版本控制——结合CVS实现 242.1 概要 242.2 总体处理流程 252.3 详细说明 282.3.1 修改的过程 282.3.2 冲突的解决 302.3.3 CVS 提交中注释和标签的要求 312.3.4 WinCVS 日常使用 342.3.5 基本的CVS update/commit操作规范 352.3.6 测试（坚持每日构建） 362.3.7 开发、质保、测试、发布的过程 373 变更管理——结合CVSTRAC实现 383.1 目的 383.2 变更过程 38附件：配置库的创建流程 411 配置管理规范1.1 概要1.1.1 内容本文用来规范配置管理活动，确保配置项正确地唯一标识并易于存取，保证基准配置项的更改受控，明确基线状态，在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。

1.1.2 适用范围对于不同类别的软件项目，配置管理的流程不同，可在本流程的基础上进行裁减1.1.3 术语和缩略语1.1.3.1 软件配置管理（Software Configuration Management，SCM）软件配置管理是对软件修改进行标识、组织和控制的技术，用来协调和控制整个过程是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置1.1.3.2 配置项（Configuration Item，CI）凡是纳入配置管理范畴的工作成果统称为配置项，配置项逻辑上组成软件系统的各组成部分，一般是可以单独进行设计、实施和测试的配置项主要有两大类：1)属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等；2)项目管理和机构支撑过程产生的文档这些文档虽然不是产品的组成部分，但是值得保存，如会议纪要、交流记录等每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等所有配置项都被保存在配置库里，确保不会混淆、丢失配置项及其历史记录反映了软件的演化过程。

1.1.3.3 基线（Baseline）在配置管理系统中，基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，这些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化”每一个基线都是其下一步开发的出发点和参考点基线确定了元素（配置项）的一个版本，且只确定一个版本一般情况下，基线一般在指定的里程碑处创建，并与项目中的里程碑保持同步每个基线都将接受配置管理的严格控制，基线中的配置项被“冻结”了，不能再被任何人随意修改，对其修改要严格地按照变更控制的过程进行在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线基线的主要属性有：名称、标识符、版本、日期等1.2 相关人权责1.2.1 项目经理（Project Manager，PM）责任与权利：1) 接收或拒绝小范围的变更；2) 提出管理管理的建议和要求；3) 发布管理；4) 配合部门、公司质量管理员工作；5) 指派项目的质量管理员；6) 考核项目组成员规范的执行情况1.2.2 配置控制委员会（Configuration Control Board，CCB）责任与权利：1) 制定和修改项目的配置管理策略；2) 批准、发布配置管理计划；3) 建立、更改基线的设置，审核变更申请；4) 根据配置管理员的报告决定相应的对策。

1.2.3 配置管理员（Configuration Management Officer，CMO）责任与权利：1) 执行版本控制和变更控制方案；2) 负责项目的配置管理工作（包括环境的搭建、权限分配、配置库的建立、配置项的控制等）；3) 配置管理工具的日常管理与维护；4) 配置库的日常操作和维护；5) 负责配置审核并提交报告；6) 根据项目经理批准生成发布版本；7) 对开发人员进行相关的培训；8) 对配置审核中发现的不符合项，要求相关责任人进行纠正1.2.4 开发人员（Developer）责任与权利：1) 根据确定的配置管理计划和相关规定，提交配置项和基线；2) 负责软件集成和版本生成3) 按照软件配置管理工具的使用模型来完成开发任务1.2.5 测试人员（Tester）责任和权利：1） 根据配置管理计划和相关规定，提交测试配置项和测试基线；2） 负责软件变更的测试验证，包括日测试、集成测试、发布测试1.2.6 软件质量保证员（Software Quality Assurance，SQA）责任和权利：1） 负责配置审核并提交报告2） 对配置审核中发现的不符合项，要求相关责任人进行纠正1.3 实施细则1.3.1 配置控制委员会的成立1.3.1.1 配置控制委员会成员组成配置控制委员会成员人数一般为奇数，人数在3～7人范围内，根据各个项目的不同，顾客代表和主要开发人员可以不同。

CCB成员一般包括：1) 部门经理；2) 项目经理；3) 配置管理员；4) 测试人员；5) 顾客代表；6) 主要开发人员等1.3.1.2 配置控制委员会的决策机制寻求配置控制委员会成员的一致意见若不能达成一致，可在听取意见后由配置控制委员会的组长最终决定1.3.2 确定配置策略1.3.2.1 配置策略确定的时机1） 配置控制委员会根据项目的开发计划确定各个里程碑；2） 配置管理员负责整理确定的项目基线和配置项列表，并在编制《配置管理计划》时列明；3） 配置管理员按约定时机收集配置项和建立初始基线1.3.2.2 配置项的范围1)技术文档（Documents）：项目开发计划、需求分析报告、软件设计书、质量保证计划、概要设计书、详细设计书、测试文档、技术报告、用户手册、总结报告等；2)程序（Program）：阶段产品、计算机程序、源程序、释放产品等；3)工具（Tools）：自动设计工具、开发工具、测试工具、维护工具等；4)交互文档（Communications）：与客户或项目组内交互产生文档，如会谈记录、E-mail、会议纪要、MSN记录等1.3.3 制定配置管理计划1.3.3.1 《配置管理计划》的编制通常情况下，由配置管理员在设计完成后，开始编制《配置管理计划》；如有特殊需要，也可以根据合同或项目要求，由配置管理员在某一项目或项目的某一阶段开始前制定《配置管理计划》。

1.3.3.2 《配置管理计划》的内容《配置管理计划》应包括以下方面的内容：1) 该项目对配置管理的要求；2) 实施配置管理的责任人、组织及其职责；3) 需要开展的配置管理活动及其进度安排；4) 采用的方法和工具等1.3.3.3 《配置管理计划》由配置管理委员会负责审批1.3.4 配置项管理1.3.4.1 配置项标识要求1) 合同有明确标识和追踪要求时，由开发人员按合同要求进行标识，以保证满足合同追踪要求2) 在开发过程中项目组人员提交的配置项，由项目组人员按照本节相关部分标识规则进行标识3) 项目组人员将要标识或已标识的配置项提交到配置库统一管理，并填写详细的备注信息1.3.4.2 版本管理1.3.4.2.1 文档版本控制所有文档的管理纳入配置管理库，用版本控制工具进行统一管理文档的版本控制主要通过文档的名称、文档控制页及版本控制工具的标签来实现，主要分为以下几类：1、有版本变化的命名方式：[文档名]适用文档：项目开发计划书，项目配置管理计划，用户业务需求，需求分析说明书，总体设计说明书，详细设计说明书，数据库设计说明书，模块测试用例卷宗，用户使用手册等而版本信息使用标签来控制说明，标签结构如下：[大版本] + [子系统简称] + [版本号] + 日期 [大版本]： 可选 ，表示同一项目为不同用户定制的版本。

[子系统简称]： 可选，当一个项目有多个子系统时，为区分不同子系统而设置[版本号]：采用[Vx-yy]的形式具体说明如下：a. 文档发布名称采用[文档名+Vx-yy]的形式，文档的版本号应该和版本控制工具中相应标签上的版本号一致b. 对文档的修改需要从配置管理库中取到本地进行c. 对于文档小的修改，如文字错误，格式调整，不需要进行标签的变化d. 文档内容没有大的增加和删节，意思表述没有发生重大的变化，版本标识通过版本工具中加上yy标签来表示（如：V1-01），以及在文档内部控制页标注变化来表示e. 文档有重大增加和删节，意思表述有重大变化的，版本标识通过在相应文档加上x标签来表示（如：V2-00）f. 对于纳入基线库的文档的修改需要提交变更申请，经批准才能进行修改，并且修改的内容要经再次评审才能重新纳入基线库，作为后续阶段的参考文档2、非正规次要的文档命名方式：[文档名]+（日期）适用文档：情况总结，各种报告等不需要通过名称明确进行标识变化过程的文档示 例：培训情况总结（2005年1月10日）.doc３、主要区别在于时间的命名方式：[文档名＋撰写时间]适用文档：文档名称有明确的含义，需要用时间标识的日常性文档。

如周例会会议纪要，项目月计划，项目月总结等等示 例：周例会会议纪要20030901.doc４、主要区别在于阶段的命名方式：[阶段名＋文档名]适用文档：使用于不同阶段的文档，需要加阶段名称来标识文档，有时可能也需要加版本号，如 阶段计划，阶段总结等示 例：需求调研阶段计划.doc，总体设计阶段计划.doc，试运行阶段计划.doc２、 其他文档：对于不能按照前四种类型进行命名的文档会议纪要：会议纪要YYYYMMDD ( )年月日内容简述 　示 例：9月9日召开的项目启动会命名为：会议纪要20030909(项目启动).doc评审报告：。