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