软件配置管理规范实施细则.doc
《软件配置管理规范实施细则.doc》由会员分享,可在线阅读,更多相关《软件配置管理规范实施细则.doc(45页珍藏版)》请在三一文库上搜索。
1、 软件配置管理规范软件配置管理规范 XXXXXXXXXXXXXXxXXXXXXXXXXXXXXx 科技有限公司科技有限公司 i 目目 录录 1配置管理规范配置管理规范.1 1.1概要1 1.1.1 内容.1 1.1.2 适用范围.1 1.1.3 术语和缩略语.1 1.2相关人权责3 1.2.1 项目经理(Project Manager,PM).3 1.2.2 配置控制委员会(Configuration Control Board,CCB)3 1.2.3 配置管理员(Configuration Management Officer,CMO)3 1.2.4 开发人员(Developer).4 1.
2、2.5 测试人员(Tester).4 1.2.6 软件质量保证员(Software Quality Assurance,SQA)4 1.3实施细则5 1.3.1 配置控制委员会的成立.5 1.3.2 确定配置策略.5 1.3.3 制定配置管理计划.6 1.3.4 配置项管理.7 ii 1.3.5 配置库管理.11 1.3.6 配置项基线管理.14 1.3.7 配置变更控制.16 1.3.8 配置状态报告.21 1.3.9 配置审核.21 1.3.10 发行管理.22 1.4相关文件23 1.4.1 配置管理计划.23 1.4.2 配置库管理报告.23 1.4.3 配置项变更控制报告.23 2版
3、本控制版本控制结合结合 CVSCVS 实现实现.24 2.1概要24 2.2总体处理流程25 2.3详细说明28 2.3.1 修改的过程.28 2.3.2 冲突的解决.30 2.3.3 CVS 提交中注释和标签的要求.31 2.3.4 WinCVS 日常使用.34 2.3.5 基本的 CVS update/commit 操作规范.35 2.3.6 测试(坚持每日构建).36 2.3.7 开发、质保、测试、发布的过程.37 iii 3变更管理变更管理结合结合 CVSTRACCVSTRAC 实现实现.38 3.1目的38 3.2变更过程38 附件:配置库的创建流程附件:配置库的创建流程.41 1
4、1 配置管理规范 1.1概要 1.1.1内容 本文用来规范配置管理活动,确保配置项正确地唯一标识并易于 存取,保证基准配置项的更改受控,明确基线状态,在整个软件生命 周期中建立和维护项目产品的完整性和可追溯性。 1.1.2适用范围 对于不同类别的软件项目,配置管理的流程不同,可在本流程的 基础上进行裁减。 1.1.3术语和缩略语 1.1.3.1 软件配置管理(Software Configuration Management,SCM) 软件配置管理是对软件修改进行标识、组织和控制的技术,用来 协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过 程和生命周期进行控制、规范的一系列措施。
5、配置管理的目标是记录 软件产品的演化过程,确保软件开发者在软件生命周期中各个阶段都 能得到精确的不同版本的产品配置。 1.1.3.2 配置项(Configuration Item,CI) 凡是纳入配置管理范畴的工作成果统称为配置项,配置项逻辑上 组成软件系统的各组成部分,一般是可以单独进行设计、实施和测试 的。 2 配置项主要有两大类: 1)属于产品组成部分的工作成果,例如需求文档、设计文档、源 代码、测试用例等; 2)项目管理和机构支撑过程产生的文档。这些文档虽然不是产品 的组成部分,但是值得保存,如会议纪要、交流记录等。 每个配置项的主要属性有:名称、标识符、文件状态、版本、作 者、日期等
6、。所有配置项都被保存在配置库里,确保不会混淆、丢失。 配置项及其历史记录反映了软件的演化过程。 1.1.3.3 基线(Baseline) 在配置管理系统中,基线就是一个配置项或一组配置项在其生命 周期的不同时间点上通过正式评审而进入正式受控的一种状态,这些 配置项构成了一个相对稳定的逻辑实体,而这个过程被称为“基线化” 。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素 (配置项)的一个版本,且只确定一个版本。一般情况下,基线一般 在指定的里程碑处创建,并与项目中的里程碑保持同步。每个基线都 将接受配置管理的严格控制,基线中的配置项被“冻结”了,不能再 被任何人随意修改,对其修改要严
7、格地按照变更控制的过程进行。在 一个软件开发阶段结束时,上一个基线加上增加和修改的基线内容形 成下一个基线。 基线的主要属性有:名称、标识符、版本、日期等。 3 1.2相关人权责 1.2.1项目经理(Project Manager,PM) 责任与权利: 1)接收或拒绝小范围的变更; 2)提出管理管理的建议和要求; 3)发布管理; 4)配合部门、公司质量管理员工作; 5)指派项目的质量管理员; 6)考核项目组成员规范的执行情况。 1.2.2配置控制委员会(Configuration Control Board,CCB) 责任与权利: 1)制定和修改项目的配置管理策略; 2)批准、发布配置管理计划
8、; 3)建立、更改基线的设置,审核变更申请; 4)根据配置管理员的报告决定相应的对策。 1.2.3配置管理员(Configuration Management Officer,CMO) 责任与权利: 1)执行版本控制和变更控制方案; 2)负责项目的配置管理工作(包括环境的搭建、权限分配、 配置库的建立、配置项的控制等) ; 3)配置管理工具的日常管理与维护; 4 4)配置库的日常操作和维护; 5)负责配置审核并提交报告; 6)根据项目经理批准生成发布版本; 7)对开发人员进行相关的培训; 8)对配置审核中发现的不符合项,要求相关责任人进行纠正。 1.2.4开发人员(Developer) 责任与
9、权利: 1)根据确定的配置管理计划和相关规定,提交配置项和基线; 2)负责软件集成和版本生成。 3)按照软件配置管理工具的使用模型来完成开发任务。 1.2.5测试人员(Tester) 责任和权利: 1)根据配置管理计划和相关规定,提交测试配置项和测试基 线; 2)负责软件变更的测试验证,包括日测试、集成测试、发布 测试 1.2.6软件质量保证员(Software Quality Assurance,SQA) 责任和权利: 1)负责配置审核并提交报告。 5 2)对配置审核中发现的不符合项,要求相关责任人进行纠正。 1.3实施细则 1.3.1配置控制委员会的成立 1.3.1.1 配置控制委员会成员
10、组成 配置控制委员会成员人数一般为奇数,人数在 37 人范围内, 根据各个项目的不同,顾客代表和主要开发人员可以不同。CCB 成员 一般包括: 1)部门经理; 2)项目经理; 3)配置管理员; 4)测试人员; 5)顾客代表; 6)主要开发人员等。 1.3.1.2 配置控制委员会的决策机制 寻求配置控制委员会成员的一致意见。若不能达成一致,可在听 取意见后由配置控制委员会的组长最终决定。 1.3.2确定配置策略 1.3.2.1 配置策略确定的时机 1)配置控制委员会根据项目的开发计划确定各个里程碑; 2)配置管理员负责整理确定的项目基线和配置项列表,并 6 在编制配置管理计划时列明; 3)配置管
11、理员按约定时机收集配置项和建立初始基线。 1.3.2.2 配置项的范围 1)1)技术文档(技术文档(DocumentsDocuments):):项目开发计划、需求分析报告、软 件设计书、质量保证计划、概要设计书、详细设计书、测试文档、技 术报告、用户手册、总结报告等; 2)2)程序(程序(ProgramProgram):):阶段产品、计算机程序、源程序、释放产 品等; 3)3)工具(工具(ToolsTools):):自动设计工具、开发工具、测试工具、维护 工具等; 4)4)交互文档(交互文档(CommunicationsCommunications):):与客户或项目组内交互产生文 档,如会谈
12、记录、E-mail、会议纪要、MSN 记录等。 1.3.3制定配置管理计划 1.3.3.1 配置管理计划的编制 通常情况下,由配置管理员在设计完成后,开始编制配置管理 计划 ;如有特殊需要,也可以根据合同或项目要求,由配置管理员 在某一项目或项目的某一阶段开始前制定配置管理计划 。 1.3.3.2 配置管理计划的内容 配置管理计划应包括以下方面的内容: 1) 该项目对配置管理的要求; 2) 实施配置管理的责任人、组织及其职责; 7 3) 需要开展的配置管理活动及其进度安排; 4) 采用的方法和工具等。 1.3.3.3 配置管理计划由配置管理委员会负责审批。 1.3.4配置项管理 1.3.4.1
13、 配置项标识要求 1) 合同有明确标识和追踪要求时,由开发人员按合同要求进行 标识,以保证满足合同追踪要求。 2) 在开发过程中项目组人员提交的配置项,由项目组人员按照 本节相关部分标识规则进行标识。 3) 项目组人员将要标识或已标识的配置项提交到配置库统一管 理,并填写详细的备注信息。 1.3.4.2 版本管理 1.3.4.2.11.3.4.2.1文档版本控制文档版本控制 所有文档的管理纳入配置管理库,用版本控制工具进行统一管理。 文档的版本控制主要通过文档的名称、文档控制页及版本控制工具的 标签来实现,主要分为以下几类: 1、有版本变化的 命名方式:文档名 适用文档:项目开发计划书,项目配
14、置管理计划,用户业务需求, 需求分析说明书,总体设计说明书,详细设计说明书,数据库设计说 明书,模块测试用例卷宗,用户使用手册等。而版本信息使用标签来 8 控制说明,标签结构如下: 大版本大版本 + + 子系统简称子系统简称 + + 版本号版本号 + + 日期日期 大版本大版本 : 可选 ,表示同一项目为不同用户定制的版本。 子系统简称子系统简称 : 可选,当一个项目有多个子系统时,为区分不 同子系统而设置。 版本号版本号 :采用Vx-yy的形式。具体说明如下: a.文档发布名称采用文档名+Vx-yy的形式,文档的版本号应该 和版本控制工具中相应标签上的版本号一致。 b.对文档的修改需要从配置
15、管理库中取到本地进行。 c.对于文档小的修改,如文字错误,格式调整,不需要进行标签 的变化。 d.文档内容没有大的增加和删节,意思表述没有发生重大的变化, 版本标识通过版本工具中加上 yy 标签来表示(如:V1-01) ,以及在 文档内部控制页标注变化来表示。 e.文档有重大增加和删节,意思表述有重大变化的,版本标识通 过在相应文档加上 x 标签来表示(如:V2-00) 。 f.对于纳入基线库的文档的修改需要提交变更申请,经批准才能 进行修改,并且修改的内容要经再次评审才能重新纳入基线库,作为 后续阶段的参考文档。 2、非正规次要的文档 命名方式:文档名+(日期) 9 适用文档:情况总结,各种
16、报告等不需要通过名称明确进行标识 变化过程的文档。 示 例:培训情况总结(2005 年 1 月 10 日).doc 、主要区别在于时间的 命名方式:文档名撰写时间 适用文档:文档名称有明确的含义,需要用时间标识的日常性文 档。如周例会会议纪要,项目月计划,项目月总结等等。 示 例:周例会会议纪要 20030901.doc 、主要区别在于阶段的 命名方式:阶段名文档名 适用文档:使用于不同阶段的文档,需要加阶段名称来标识文档, 有时可能也需要加版本号,如 阶段计划,阶段总结等。 示 例:需求调研阶段计划.doc,总体设计阶段计划.doc,试 运行阶段计划.doc 、 其他文档: 对于不能按照前四
17、种类型进行命名的文档 会议纪要会议纪要:会议纪要 YYYYMMDD ( ) 示 例:9 月 9 日召开的项目启动会 命名为:会议纪要 20030909(项目启动).doc 年月日 内容简述 10 评审报告评审报告:评审报告 YYYYMMDD ( ) 同”会议纪要”要求。 示 例:10 月 9 日召开的项目总体方案评审 命名为:评审报告 20030910(总体方案).doc 1.3.4.2.21.3.4.2.2发行版本表示发行版本表示 发行版本采用标签说明,结构如下: 大版本大版本 + + 子系统简称子系统简称 + + 版本类型版本类型 + + 版本号版本号 + + 日期日期 大版本大版本 :
18、可选 ,表示同一项目为不同用户定制的版本。 子系统简称子系统简称 : 可选,当一个项目有多个子系统时,为区分不 同子系统而设置。 版本类型:版本类型:分为 3 种 Beta 表示项目组内部测试版、日测试(标签) , Release 项目组外部测试版、集成测试(标签) , Version 正式发行版。 版本号版本号 对于 Version 正式发行版 是必须要注明的,而其它可 选。 发行产品基线在版本号前加 Version,如 Version_1, Version_2, Version_3.表示分支; Version_1_0, Version_1_1, Version_1_2 表示在分支 Vers
19、ion_1 上的标签; Version_0_0, Version_0_1, Version_0_2 表示在主线上 11 的标签。 1.3.5配置库管理 1.3.5.1 配置库(Repository)的分类 配置库统一由配置管理员负责管理,主要使用 CVS 版本工具。配 置库目录结构如下: 一级目录二级目录说明 01_worksho01_worksho p p 个人私有目录,里面保存开发者文件,提供备份功能 保存程序中的源代码 BinBin 二进制文件目录,存放应用程序的可执 行文件 DatabaseDatabase 数据库目录,包含数据库表结构、存储 过程等对象 HelpHelp 帮助文件目录
20、,包含使用帮助文档 InstallInstall 安装程序目录,存放安装程序源文件 PackagesPackages 安装包目录,包含应用程序的安装文件 和补丁包 02_sourcec02_sourcec odeode SourceSource 源代码目录,源码放于该目录下 开发包文档目录,里面包含设计开发文档以及各种开发规范文档 0 管理活动 项目管理相关文档 1 会议纪要以月为单位建立目录,如 2005-01 2 软件产品宣传资 料 03_documen03_documen t t 第 01 阶段(项目启 动) 可行性研究报告、项目任务书、需求说 明 12 第 02 阶段(需求调 研) 需
21、求分析说明书 第 03 阶段(项目计 划) 体进度说明、进度跟踪、配置管理计划、 质量保证计划、测试计划 第 04 阶段(系统设 计) 概要设计、详细设计和数据库设计 第 05 阶段(编码阶 段) 第 06 阶段(测试阶 段) 测试计划、测试用例、测试结果和测试 分析报告 第 07 阶段(交付验 收) 付施工文档、工具 第 08 阶段(项目总 结) 项目质量报告、测试报告 第 09 阶段(部署)项目推广相关文档包括操作手册、安装 维护手册、维护文档以及必要的业务和技术 培训文档 04_tools04_tools 工具目录,存放开发中使用的相关工具软件 1.3.5.2 配置库的建立 所有项目应建
22、立配置库,以便管理各配置项,配置管理员组织建 立配置库。程序库主要通过设置版本的分支来实现对配置项权限管理: 1)开发库:在主线上,对应的是开发人员的私有开发空间。开发 人员根据任务分工获得对相应配置项的操作许可之后,在主线上工作。 2)控制库:通过分支实现,建立控制分支。 13 3)版本库:通过在控制库上建立标签实现。 配置库统一由配置管理员管理,根据各开发阶段的实际情况定制 相应的版本选取规则,来保证开发活动的正常运作。在变更发生时, 应及时做好基线的推进。 1.3.5.3 分配权限 配置管理员为每个项目成员分配配置库操作权限。一般地,项目 成员拥有 Add、 Check in/Check
23、out 等权限,但是不能拥有“删除” 权限。配置管理员的权限最高。 存取权限 配置管理项人员角色 读 增 加 修 改 删除 公司质量管理 员 部门质量管理 员 项目经理 项目质量管理 员 开发工具库 项目组成员 项目文档库 基线 公司质量管理 员 部门质量管理 员 14 项目经理 项目质量管理 员 项目组成员 公司质量管理 员 部门质量管理 员 项目经理 项目质量管理 员 项目文档库 阶段文档 项目组成员(对己) 公司质量管理 员 部门质量管理 员 项目经理 项目质量管理 员 软件开发库 项目组成员 (他人和以做基 线控制不允许) 1.3.5.4 配置库的操作与管理 1)开发人员根据获得的授权
24、进行研发工作,操作配置库,例 如 Add、Check in / Checkout 等。 2)配置管理员根据配置管理计划创建与维护基线, “冻结”配 置项,控制变更。 15 3)配置管理员定期备份配置库。 1.3.6配置项基线管理 配置管理员根据配置管理计划,对配置项和基线进行分阶段管理。 1.3.6.1 项目启动 配置项包括可行性研究报告可行性研究报告、项目任务书项目任务书、需求说明,需求说明,评审通过 后建立发布基线。 1.3.6.2 需求分析 系统调研后开发人员进行需求分析,并整理需求分析说明书需求分析说明书。需 求分析说明书通过评审并取得客户的确认后,建立需求基线。如需升 级版本则必须通
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 配置管理 规范 实施细则
链接地址:https://www.31doc.com/p-3293384.html