2022年配置管理计划示例 .pdf

《2022年配置管理计划示例 .pdf》由会员分享，可在线阅读，更多相关《2022年配置管理计划示例 .pdf（14页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、酒店管理系统卷号卷内编号密级分类: 专题计划使 用 者 :项 目 经理、配置变更 控制经理、集成员 、项目组成员配置管理计划Version 1.0项 目 承 担 部 门 ：配置管理部门撰写人（签名）：完成日期 ： 2010/7/18 本文档使 用部门：主管领导项目组客户（市场）维护人员用户评审负责人（签名）：评审日期：名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 14 页 - - - - - - - - - 文档信息标题 : 配置管理计划作者 : 创建日期 :2010/

2、7/18 上次更新日期: 2010/7/18 版本 : Version 1.0 部门名称 : swjtu-Java-02修订文档历史记录日期版本说明作者2010/7/18 Version 1.0 创建文档2010/7/22 Version 1.1 修改文档名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 14 页 - - - - - - - - - 目录1. 简介4 1.1 目的4 1.2 范围4 1.3 定义、首字母缩写词和缩略语4 1.4 参考资料4 4 2. 软件配置

3、管理4 2.1 组织、职责和接口4 2.2 工具、环境和基础设施4 3. 配置管理活动6 3.1 配置标识6 3.1.1 标识方法6 3.1.2 项目基线6 3.2 配置和变更控制8 3.2.1 变更请求的处理和审批8 3.2.2 变更控制委员会 (CCB)10 3.3 配置状态统计11 3.3.1 项目介质存储和发布进程11 3.3.2 报告和审计11 4. 里程碑11 5. 培训和资源12 6. 分包商和厂商软件控制错误！未定义书签。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第

4、 3 页，共 14 页 - - - - - - - - - 配置管理计划1.简介项目 CM计划说明在产品生命周期中将执行的所有与CM相关的活动。它详细说明了活动时间表、分配的职责以及必需的资源（包括人员、工具和计算机设备）。1.1目的CM 计划的目的在于，定义或参考那些描述要在软件产品开发中执行配置和变更控制管理 (CM) 方式的步骤和活动。1.2范围本规范规定了在制订软件配置管理计划时应该遵循的统一的基本要求。本规范适用于软件特别是重要软件的配置管理计划的制订工作。对于非重要软件或已开发好的软件，可以采用本规范规定的要求的子集。1.3定义、首字母缩写词和缩略语CCB - configurat

5、ion control board 变更（或配置）控制委员会CI - configuration item 配置项CM - configuration management 配置管理Baseline： 基线。PCA ：物理审计，在配置管理系统中建立基线的工件是否为“ 正确 ” 版本。FCA ：功能审计，是核实软件配置项的实际性能是否符合它的需求。CMP - configuration management plan 配置管理计划CR - change request 变更请求SCM - software configuration management 软件配置管理任意角色 项目中所有角色1.

6、4参考资料Rational Unified Process 2000SDP Plan Develop Case 2.软件配置管理2.1组织、职责和接口角色相关人员职责接口CCB 该委员会监督变更流程，由开发人员和用户的代表组成。与任意角色：任意角色提出变更请求，需提交给 CCB ，对变更请求进行处理后，将结果通知给提出者。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 14 页 - - - - - - - - - 配置经理配置经理负责为产品开发团队提供全面的配置管理 (C

7、M) 基础设施和环境。 CM 的作用是支持产品开发行为，使开发人员和集成员有适当工作区来构建和测试其工件，并且使所有工件均可根据需要包含在部署单元中。配置经理还必须确保 CM 环境有利于进行产品复审、更改和缺陷跟踪等活动。配置经理还负责撰写 CM 计划并汇报基于 “ 变更请求 ” 的进度统计信息。发布基线与项目经理：CM计划需要参照SDP计划，而且 SDP又参照 CM计划。 SCM经理每周 / 每阶段都要提供系统的配置状态报告给项目经理。与集成员 ： CM 经理创建配置管理库，而集成员创建集成工作区。集成员创建基线和提升基线，由SCM经理管理基线。与部署经理：SCM 经理创建部署单元，需要部署

8、计划。与架构设计师：SCM经理创建 CM环境，需要实施模型。与任意角色：任意角色创建开发工作区，需要配置库。与系统管理员：创建 CM环境时，需要系统管理员提供硬件和网络基础设施。与组织 SCM管理员 ：在每一阶段基线完成后提交基线工件。与评审协调员：接收评审协调员提交的评审结果工件和评审表。与 SQA人员 ：配合 SQA人员活动。任意角色项目组所有成员任何角色均可以“ 检入” 和“ 检出 ” 任何与产品相关的工件，以便在配置控制系统中进行维护。此外，任意角色都可以提交变更请求，并且对它们所拥有的变更请求进行更新。2.2工具、环境和基础设施1. 工具类型使用时期工具原因配置管理产品开发全程Svn

9、 Svn 简单，功能强大。2.CM环境和基础设施 1）产品数据量的预期大小：我们期望本项目至少有150 个文件， 50M的磁盘空间。2）产品团队的分配：角色成员名单角色说明PM 项目经理SA 需求分析师SE 设计分析师TE 测试工程师名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 5 页，共 14 页 - - - - - - - - - CM 配置管理员PPQA 产品和质量保证服务器和客户机的实际位置：1 台。 2G内存、 160G 硬盘。 Win7。服务器位置在C2-6, 客户端在

10、 C2-1.3.4.5.7.8.9.10 3.配置管理活动3.1配置标识3.1.1标识方法最终的工件的命名方式是大写字母 +缩写 +编号 +名称例： HMS-CM-101-配置管理计划相应的工件的中间版本命名方式是以对应的阶段大写字母缩写加类别大写缩写加版本编号命名发布标志为产品缩写加版本号, 阶段发布为阶段号加版本号3.1.2工件存储目录及分类项目开发过程产生的工件由相应的负责人及时上传至SVN服务器，由配置管理员统一管理。 SVN服务器文件存放目录分类如下图3.1.3文件上传管理所有模块负责人必须与每日工作结束之前上传当日工作内容上传至SVN服务器。所有上传工件必须符合标识方法中的命名方式

11、。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 6 页，共 14 页 - - - - - - - - - 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 7 页，共 14 页 - - - - - - - - - 3.1.3 项目基线基线名称基线标识产出时机计划基线JH-01 计划阶段结束需求基线XQ-01 需求分析阶段结束设计基线SJ-02 设计阶段结束产品基线CP-03

12、 实现部署阶段结束基线创建非代码类基线：由配置经理根据开发案例创建代码类基线：由集成员根据产品架构文档创建3.2配置和变更控制3.2.1变更请求的处理和审批软件配置的变更管理适用于本项目的所有文档和代码，其中包括本项目的各个运行软件，也包括为本项目专门开发的支持软件。变更请求表单是一个正式提交的工件，用于在整个项目的生命周期内跟踪所有的请求（包括新特性、扩展请求、缺陷、变更的需求等）与相关的状态信息。所有变更历史记录，包括所有状态变更及变更的日期和原因，都将随 CR 一起保存。进行多次复审和结束项目时都可使用此信息。变更过程中的活动活动角色内容提交变更请求提交者项目的任何涉众均可提交变更请求

13、(CR) 。通过将变更请求状态设置为已提交，变更请求被记录到变更请求追踪系统中（例如ClearQuest）并放置到 CCB 复审队列中。复审变更请求CCB 此活动的作用是复审已提交 的变更请求。在 CCB 复审会议中对变更请求的内容进行初始复审，以确定它是否为有效请求。如果是，则基于小组所确定的优先级、时间表、资源、努力程度、风险、严重性以及其他任何相关的标准，判定该变更是在当前发布版的范围之内还是范围之外。确认重复或拒绝CCB 代表如果怀疑某个变更请求为重复 的请求或 已拒绝 的无效请求（例如，由于操作符错误、无法重现、工作方式等），将指定一个CCB 代表来确认重复或已拒绝的变更请求。如果需

14、要的话，该代表还从提交者处收集更多信息。更新变更请求提交者如果评估变更请求时需要更多的信息（详细信息 ），或者如果变更请求在流程中的某个时刻遭到拒绝（例如，被确认为是重复 、已拒绝 等），那么将通知提交者，并用新信息更新变更请求。然后将已更新的变更请求重新提交给 CCB 复审队列，以考虑新的数据。分配工作与安排工作时间项目经理一旦变更请求被置为已打开 ，项目经理就将根据请求的类型（例如，扩展请求、缺陷、文档变更、测试缺陷等）把工作分配给合适的角色，并对项目时间表做必要的更新。进行变更指定的角色指定的角色执行在流程的有关部分中指定的活动集（例如，需求、分析设计、实施、制作用户支持材料、设计测试等

15、），以进行所请求的变更。这些活动将包括常规开发流程中所述的所名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 8 页，共 14 页 - - - - - - - - - 有常规复审活动和单元测试活动。然后，变更请求将标记为已解决 。核实测试工作版本中的变更测试员指定的角色（分析员、开发人员、测试员、技术文档编写员等） 解决 变更后，变更将放置在要分配给测试员的测试队列中，并在产品工作版本中加以核实 。核实发布工作版本中的变更系统集成员已确定的变更一旦在产品的测试工作版本中得到了核实 ，就

16、将变更请求放置在发布队列中，以便在产品的发布工作版本予以核实、生成发布版本说明等，然后关闭 该变更请求。3.2.1.1变更过程中的变更请求状态状态定义已提交出现此状态的原因为：1) 提交新的变更请求；2) 更新现有的变更请求；或3) 考虑在新的发布周期中使用已推迟的变更请求。变更请求放置在 CCB 复审队列中。本操作的结果不会指定拥有者。已推迟变更请确定为有效，但对于当前发布版来说属于“ 超出范围 ” 。处于已推迟状态的变更请求将得以保留，并在以后的发布版中被重新考虑并加以使用。可以指定一个目标发布版，以表明可以提交变更请求（以重新进入 CCB 复审队列）的时间范围。重复处于此状态的变更请求被

17、视作对已提交的另一个变更请求的重复。变更请求可由 CCB 复审管理员或被指定解决它的角色置于该状态中。将变更请求置于重复状态中时，将（在 ClearQuest 的“ 附件 ” 选项卡上）记录它所重复的那个变更请求的编号。在提交变更请求之前，提交者应首先查询变更请求数据库，看是否已有与之相重复的变更请求。这将省去复审流程中的若干步骤，从而节省大量的时间。应将重复变更请求的提交者添加到原始变更请求的通知列表中，以便以后将有关解决事宜通知他们。已拒绝CCB 复审会议或指定的角色确定此状态中的变更请求为无效请求，或者需要提交者提供更为详细的信息。如果已经指定（提出）变更请求，则它将从解决队列中删除并重

18、新复审。这将由 CCB 所指定的权威来予以确认。除非有必要，否则提交者无需进行任何操作。在此情况下变更请求状态将变为详细信息。考虑到可能会有新的信息，在 CCB 复审会议中将重新复审该变更请求。如果变更请求确认为无效，将被 CCB 关闭并且通知提交者。详细信息数据不足以确认已拒绝或重复的变更请求是否有效。拥有者自动变成提交者，将通知提交者提供更多数据。已打开对于当前发布版来说，处于此状态的变更请求已被确定为属于“ 范围之内 ” ，并且亟待解决。它已定于在即将来临的目标里程碑之前得以解决。它被确定在“ 指定队列 ” 中。与会者是提出变更请求并将其放入解决队列中的唯一权威。如果发现优先级为第二或更

19、高的变更请求，应立即通知 QE 经理或开发经理。此时，他们可以决定召开紧急 CCB 复审会议，或立即打开变更请求以将其放入解决队列中。已指定然后由项目经理负责已打开的变更请求，他应根据变更请求的类型分配工作；如果需要 , 还应更新时间表。已解决表示该变更请求已解决完毕，现在可以进行核实了。如果提交者是 QE 部门的成员，则拥有者将自动变成执行提交的 QE 成员。否则，拥有者将变成 QE 经理，以重新进行人工分配。测试已失败在测试工作版本或发布工作版本中进行测试时失败的变更请求将置于此状态中。拥有者自动变成解决变更请求的角色。已核实处于此状态的变更请求已经在测试工作版本中得到了核实，并且可以进行

20、发布名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 9 页，共 14 页 - - - - - - - - - 了。已关闭变更请求不再引人注意。这是可以指定给变更请求的最后一个状态。只有 CCB 复审管理员有权关闭变更请求。变更请求被关闭后，提交者将收到一份有关对变更请求的最终处理结果的电子邮件通知。在下列情况中可能关闭变更请求：1) 其已核实的解决结果在发布工作版本中得到确认之后；2) 其拒绝状态得到确认时；或 3) 被确认为对现有变更请求的重复。在后一种情况中，会将重复变更请求通知

21、给提交者，并将提交者添加到该变更请求中，以便以后通知他们（详情请参见状态“拒绝” 和“重复” 的定义）。如果提交者希望对关闭变更请求有异议，则必须更新变更请求并且重新将其提交供 CCB 复审。变更过程的变更请求状态( 状态图 ) ：3.2.1.2保存变更历史记录如果工件为Word 文档，则在文档的修订文档历史记录。如果工件为其他工件，必须在相应的记录中保存变更历史纪录。3.2.1.3变更请求中受影响配置项的变更在变更请求中受影响配置项需要变更时，首先由CCB协调员通知受影响配置项的变更人员，其次被通知人员按照标准变更流程进行变更。3.2.2变更控制委员会 (CCB)1.职责： CCB 的基本任

22、务是明确产品的基线、复审对基线的变更、最后批准、否决变更或延期执行。2.选择成员标准：从用户、开发人员、测试小组、项目管理中选择。3.项目的 CCB成员为：4.CCB 主席：5.处理变更请求和确认的过程：名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 10 页，共 14 页 - - - - - - - - - CCB以事触发为主要工作方式，必须定期( 每个阶段结束时) 按需召开会议。确保变更提议及时得到了复审和处理。拟定变更复审通知协议。确保变更请求提交后，各有关人员都得到了通知，决

23、定由谁复审各种工件。传达给同事和团队负责人，以及变更提议的接受者，并让他们有机会复审并参与意见。人员角色职责施皓CCB主席协调组织复审员需求复审复审员需求复审、架构复审复审员架构复审、代码复审复审员代码复审复审员测试复审协调员负责通知由谁进行复审3.3配置状态统计3.3.1项目介质存储和发布进程3.3.1.1项目介质保留策略、备份计划、事故处理计划、恢复计划1.备份机制及保留策略：1)每天实验结束时将主服务器的数据备份到ftp服务器中。2)ftp服务器只保留最近一周的备份。2.事故处理和恢复机制：如果出现事故( 如：主服务器当机、遭病毒、硬件损坏等) ，采用 ftp服务器上的数据进行恢复。3.

24、防病毒 / 杀毒机制：1)杀毒 / 防病毒软件： Antivir 2)频率：每日杀毒。3)负责人：系统管理员( 施皓 ) 。3.3.1.2介质保留方式：介质保留方式：联机。类型：移动硬盘。格式： Windows 的文件。3.3.2报告和审计目的：让项目经理确定需要报告哪些产品的相关变更数据，以及报告人和报告频率。频率：每日 / 每个阶段结束时进行报告。报告人：配置管理经理。1.基于变更请求的报告。名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 11 页，共 14 页 - - - -

25、- - - - - 1)龄期：基于时间的报告。内容和格式如下：缺陷 (Bug) 名称打开时间修复时刻滞后时间 (天 ) 备注2)分布：基于计数的报告。内容和格式如下：3)拥有者Bug 个数修复状态Bug 个数优先级Bug 个数4)趋势：与时间和计数有关的报告。内容和格式如下：2.工作版本报告。工作版本报告中列出了构成软件某一特定版本的一个工作版本的所有文件、它们的位置以及已并入的变更。3.审计。包含功能审计和物理审计。1)功能审计：核实软件配置项的实际性能是否符合它的需求。2)物理审计：验证在配置管理系统中建立基线的工件是否为“ 正确 ” 版本。4.配置状态报告（参见附录2）4.里程碑在每一次

26、迭代完成时，设立一个里程碑。CM计划：在先启阶段创建，精化阶段各迭代中进行CM计划更新，精化阶段完成时CM计划完成。5.培训和资源培训：角色人员培训内容配置管理经理相关知识基础培训项目经理相关知识基础培训数据库设计数据库相关知识及应用发现 Bug 个数修复 Bug 个数Bug 发现频率( 天) Bug 修复频率( 天) 就打开的缺陷和关闭的缺陷而言，它们之间的“ 质量差距” 有多大？解决缺陷所用的平均时间( 天) 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 12 页，共 14 页

27、 - - - - - - - - - 界面设计图形设计及制作相关知识6.附录配置管理报表及其格式附录 1 基线发布表型目编号项目名称酒店管理系统基线号本基线配置项路径基线包含工作名称版本号路径负责人备注名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 13 页，共 14 页 - - - - - - - - - 附录 2 Configuration State Accounting 1、配置项状态分类配置项配置项版本路径负 责人创建时间最后更新时间当 前 状态2、变更请求概要列表请求编号

28、请求主题提出者创建时间完成时间当前状态备注3、版本发布信息发布版本计划发布时间实际发布时间备注4、备份历史信息备份序号备份时间备份位置负责人备注5、CM环境状态51、主服务器状态服务器名称服务器状态SCM 库规模（ MB ）SCM 可用空间（ MB ）52、备份服务器状态备份服务器名称备份服务器状态SCM 库规模（ MB ）SCM 可用空间（ MB ）6、度量配置项数量变更请求数量SCM缺陷数量名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 14 页，共 14 页 - - - - - - - - -