软件配置管理规范流程模板
软件配置管理规范
流程
1 概述
1.1 目的
本文档主要目的在于规范项目配置管理活动, 确保配置项正确地唯一标识而且易于存取, 保证基线配置项的更改受控, 明确基线状态, 在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。
1.2 适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动, 针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法, 本文件以CVS( 并行版本系统) 配置管理工具为例, 规定公司的配置管理办法, 使用其它工具时也可对应本文件
的要求参照执行。
1.3 术语和缩略语
1.3.1 软件配置管理( Software Configuration Management, SCM)
软件配置管理是对软件修改进行标识、组织和控制的技术, 用来协调和控制整个过程。是经过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程, 确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。
1.3.2 配置项( Configuration Item, CI) 凡是纳入配置管理范畴的工
作成果统称为配置项, 配置项逻辑上组成软件系统的各组成部分, 一般是能够单独进行设计、实施和测试的。
每个配置项的主要属性有: 名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里, 确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。
1.3.3 基线( Baseline) 在配置管理系统中, 基线就是一个配置项或一组配置项在其生命周期的不同时间点上经过正式评审而进入正式受控的一种状态这些配置项构成了一个相对稳定的逻辑实体, 而这个过程被称为基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素( 配置项) 的一个版本, 且只确定一个版本。一般情况下, 基线一般在指定的里程碑处创立, 并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制, 基线中的配置项被冻结”了, 不能再
被任何人随意修改, 对其修改要严格地按照变更控制的过程进行。在一个软件开发阶段结束时, 上一个基线加上增加和修改的基线内容形成下一个基线。
基线的主要属性有: 名称、标签、版本、日期等。
1.4 权限与职责
1.4.1 研发总经理助理
1) 审核变更请求。
1.4.2 项目经理( Project Manager, PM)
1) 审核批准配置管理计划;
2) 接收或拒绝小范围的变更申请;
3) 召集评估变更;
4) 提出配置管理的建议和要求;
5) 配合配置管理员的工作。
1.4.3 配置管理员( Configuration Management Officer, CMO)
1) 编写配置管理计划;
2) 执行版本控制和变更控制方案;
3) 制定访问控制策略;
4) 负责项目的配置管理工作, 包括搭建环境、权限分配、配置库的建立、配置项的控制等;
5) 配置管理工具的日常管理与维护;
6) 配置库的日常操作和维护;
7) 负责配置审核并提交报告;
8) 根据配置部署表单编译发布版本, 并维护版本;
9) 对开发人员进行相关的培训;
10) 对配置审核中发现的不符合项, 拟订纠正措施, 要求相关责任人进行纠正。
11) 监督项目组成员规范的执行情况。
1.4.4 开发人员( Developer)
1) 根据确定的配置管理计划和相关规定, 提交配置项和基线
2) 负责项目组内部测试;
3) 负责软件集成和版本生成;
4) 按照软件配置管理工具的使用模型来完成开发任务。
2 实施细则
2.1 配置项管理
2.1.1 配置项的范围
软件配置可包括以下几方面: 开发文档, 代码, 第三方控件、插件, 参考资料, 测试文档, 用户文档, 项目管理文档, 验收文档等。
l 项目文档主要指: 立项建议书、可行性分析报告、技术建议书、用户需求说明书、项目计划、项目进度计划、项目阶段性计划、产品需求规格说明书、概要设计报告、详细设计、数据库设计、界面设计、用户操作手册、用户安装手册、培训文档、验收报告以
及上述文档的评审记录。
l 代码主要指: 源代码等。
l 工具主要指: 脚本文件、插件、第三方控件等。
2.1.2 配置项基线管理
结合SPP 和ISO9000 的相关规定, 配置管理员根据配置管理规范及配置管理计划, 对配置项进行分阶段管理, 每一阶段正式评审经过后纳入受控库, 作为该项目的一个基线。
l 项目启动: 配置项包括技术建议书、可行性分析报告、用户需求说明书等立项阶段产生的文档, 评审或审批经过后建立发布基线。
l 需求阶段: 系统调研后开发人员进行需求分析, 并整理产
品需求规格说明书。产品需求规格说明书经过客户的确认后, 建立需求基线。如需升级版本则必须经过评审或审批并得到客户的确认。
l 项目计划: 需求分析完成后即可制定项目的开发计划, 包
括项目计划和主要下属计划。包括项目进度计划、配置管理计划、质量保证计划、测试计划、项目阶段性计划。项目开发计划评审经过后, 建立项目计划基线。
l 设计: 系统设计可分为概要设计、详细设计、数据库设计、数据库字典、界面设计。针对用户需求规格说明书进行系统设计, 配置时应说明系统设计的版本与需求分析报告版本的对应关系。设计说明书评审或审批经过后, 建立设计基线。
l 编码（设计实现） : 编码按功能模块分子项目, 即每个模块记作一个配置项。代码在提交项目组系统测试时建立Beta 版本,系统测试产品正式发布后建立Version 版本。
l 测试: 单元测试和系统测试。单元测试经过提交《单元测试报告》, 项目启动后应提交《系统测试计划》, 系统测试完成后应提交《系统测试报告》。配置时应说明测试的版本与编码版本的对应关系。系统测试完成后建立测试基线。
l 版本发布: 项目组提交《部署表单》, CMO 根据部署表单进行编译, 发布测试服务器上, 并对版本进行维护。同时将发布的版本上传到文档服务器上备份。
l 交付与验收: 在交付前配置审核完成后建立产品基线, 产品基线包含程序以及有关文档配置项, 包括交付文档、代码、工具等。
l 产品部署: 部署时应包括操作手册、安装维护手册、维护文档以及必要的业务和技术培训文档。
l 相关资料: 相关资料也应作为配置项纳入配置管理, 此部分包括:
1) 相关法律、法规; 必须遵照或项目组约定的技术规范;
2) 与客户或项目组内部重要的交互信息记录, 如会议记录、会谈记录、e-mail 和MSN 记录等;
2.2 版本控制
2.2.1 文档的版本控制
所有文档的管理纳入配置管理库, 用版本控制工具进行统一管理。文档的版本控制主要经过文档的名称、文档控制页及版本控制工具的标
签来实现, 主要分为以下几类:
2.2.1.1 版本变化型文档
命名方式: [文档名称]+[子系统名称]( 可选)
适用文档: 项目计划、配置管理计划、质量保证计划、项目进度计划、用户需求规格说明书、产品需求规格说明书、体系结构设计报告、数据库设计报告、详细设计报告、用户操作维护手册、测试用例等。
示例: 项目计划.doc
详细设计_SP门户.doc
标签结构: [大版本] + [子系统简称] + [版本号] + 日期( 标签控