配置管理计划

《配置管理计划》由会员分享，可在线阅读，更多相关《配置管理计划（11页珍藏版）》请在装配图网上搜索。

1、精品文档，仅供学习与交流，如有侵权请联系网站删除卷号卷内编号密级分类:专题计划使用者:项目经理、配置变更控制经理、集成员、项目组成员软件开发一组,2007酒店管理系统项目编号:SQMS-001HOTEL MANAGE SYSTEMVersion 1.0作者:袁杰 文档信息项目名:酒店管理系统项目编号:SQMS-001 标题:HOTEL MANAGE SYSTEM作者:袁杰创建日期:2007-8-6上次更新日期:2007-8-6 版本:1.0部门名称:软件开发一组1.简介41.1目的41.2范围51.3定义、首字母缩写词和缩略语51.4参考资料52.软件配置管理52.1组织、职责和接口52.2工

2、具、环境和基础设施73.配置管理活动73.1配置标识73.1.1标识方法73.1.2项目基线83.2配置和变更控制93.2.1变更请求的处理和审批93.2.2变更控制委员会 (CCB)133.3配置状态统计133.3.1项目介质存储和发布进程133.3.2报告和审计144.里程碑145.附录 配置管理报表及其格式14酒店管理系统配置管理计划1. 简介项目配置管理计划说明在产品生命周期中将执行的所有与配置管理相关的活动。它详细说明了活动时间表、分配的职责以及必需的资源（包括人员、工具和计算机设备）。为项目的顺利完成提供了很重要的材料。1.1 目的编写配置管理计划的目的在于，定义或参考那些描述要在

3、软件产品开发中执行配置和变更控制管理 (CM) 方式的步骤和活动。1.2 范围本规范规定了在制订软件配置管理计划时应该遵循的统一的基本要求。本规范适用于软件特别是重要软件的配置管理计划的制订工作。对于非重要软件或已开发好的软件，可以采用本规范规定的要求的子集。1.3 定义、首字母缩写词和缩略语CCB - configuration control board 变更（或配置）控制委员会CI - configuration item 配置项CM - configuration management 配置管理CMP - configuration management plan 配置管理计划CR -

4、 change request 变更请求SCM - software configuration management 软件配置管理AR- any role 任意角色 项目中所有角色1.4 参考资料Rational Unified Process 2000SDP PlanDevelop Case2. 软件配置管理2.1 组织、职责和接口角色相关人员职责接口CCB闫永会、赵文福、李旭、尹小平、高嵚、李灵玲、袁杰该委员会监督变更流程，由所有利益方包括客户、开发人员和用户的代表组成。与任意角色：任意角色提出变更请求，需提交给CCB，对变更请求进行处理后，将结果通知给提出者。配置经理袁杰配置经理负责为

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

6、，需要部署计划。与架构设计师：SCM经理创建CM环境，需要实施模型。与任意角色：任意角色创建开发工作区，需要配置库。与系统管理员：创建CM环境时，需要系统管理员提供硬件和网络基础设施。与组织SCM管理员：在每一阶段基线完成后提交基线工件。与评审协调员：接收评审协调员提交的评审结果工件和评审表。与SQA人员：配合SQA人员活动。集成员袁杰集成员在集成工作区将构件组合起来，生成一个工作版本。集成员还负责制定集成计划。集成在子系统和系统级别进行，每次集成均有独立的集成工作区。正如经测试的构件从实施员的专用开发工作区交付到子系统集成工作区一样，已集成的实施子系统也从子系统集成工作区交付到系统集成工作区

7、。与配置经理：获取配置库的情况。获取管理状态下的基线版本任意角色项目组所有成员任何角色均可以“签入”和“签出”任何与产品相关的工件，以便在配置控制系统中进行维护。此外，任意角色都可以提交变更请求，并且对它们所拥有的变更请求进行更新。2.2 工具、环境和基础设施1. 工具类型使用时期工具原因配置管理先启、精化、构建、产品化阶段VSS难度小，VSS容易掌握。2. CM环境和基础设施基础设施和CM环境：服务器和客户端的实际位置：PC机一台，Windows2000操作系统，60G硬盘，128M内存，服务器位置在E1-3，客户端位置在E1-3。3. 配置管理活动3.1 配置标识3.1.1 标识方法标签标

8、识特定版本的工件。组成某一版本子系统的工件集，无论从整体还是从个体来说，都可通过特定的版本和标签进行标识。因此，标签对于重新使用或引用原有的固定版本的工件集合很有帮助。使用以下的产品工件标注约定，这些约定适用于标注产品目录结构中的路径和工件。_R|A|B.BL 标识系统 代表由三个字母组成的首字母缩写词 (TLA!)，用来表示系统创建中所使用的各种工件。例如，名称对应的内容PLN项目计划REQ需求文件USC用例MOD模型文件SRC源代码文件INT公共接口TST测试脚本和结果DOC文档（用户文档、发布版本说明文档）BIN可执行文件 标识子系统 代表由三个字母组成的首字母缩写词，用来表示在子系统创

9、建使用的各种工件。与上表保持一致。名称对应的内容R|A|B代表发布版、Alpha 版或 Beta 版整数，代表主发布版本号（例如 1）整数（可选），代表次发布版本号整数（可选），代表备选发布版本号（修补程序、移植程序等）BL代表基级（内部发布版本）#整数，代表内部发布版本号以下是一些示例：名称对应的内容T2K_R1.0Thorn 2000 系统 1.0 发布版本T2K_GUI_R2.0.BL5准备以 2.0 版本发布的 GUI 系统的内部发布版本号T2K_B1.1Thorn 2000 系统 1.1 Beta 发布版T2K_R2.0.BL16计划在 2.0 发布版中发布的 Thorn 2000

10、的内部系统基线第 16 号T2K_R1.0.5Thorn 2000 的维护发布版本3.1.2 项目基线1、 在先启阶段、精化阶段、构建阶段和产品化阶段结束时建立2、 在各阶段内评审完成时建立3、 在各阶段内，由构架分析员或项目经理决定需建立基线时建立工件按照信息集分组并加以说明。3.1.2.1 基线标识基线号建立时机A10先启结束B20精化结束C30构建结束D40产品化结束在各阶段中基线号：阶段基线号 + _ + 次数例：在精化阶段内的第三次基线：B20_33.1.2.2 基线创建非代码类基线：由配置经理根据开发案例创建。代码类基线：由集成员根据产品构架文档创建。3.1.2.3 基线发布在每次

11、创建基线以后进行发布。l 非代码类基线：由配置经理发布。l 代码类基线：由集成员发布。基线发布表(参见附录)。3.2 配置和变更控制3.2.1 变更请求的处理和审批软件配置的变更管理适用于本项目的所有文档和代码，其中包括本项目的各个运行软件，也包括为本项目专门开发的支持软件。3.2.1.1 变更请求表单变更请求表单是一个正式提交的工件，用于在整个项目的生命周期内跟踪所有的请求（包括新特性、扩展请求、缺陷、变更的需求等）与相关的状态信息。所有变更历史记录，包括所有状态变更及变更的日期和原因，都将随 CR 一起保存。进行多次复审和结束项目时都可使用此信息。(参见附录2)变更请求表单3.2.1.2

12、变更过程中的活动变更申请的流程及涉及相关负责人如下图所示：活动角色内容提交变更请求提交者项目的任何涉众均可提交变更请求 (CR)。通过将变更请求状态设置为已提交，变更请求被记录到变更请求追踪系统中（例ClearQuest）并放置到 CCB 复审队列中。复审变更请求CCB此活动的作用是复审已提交的变更请求。在 CCB 复审会议中对变更请求的内容进行初始复审，以确定它是否为有效请求。如果是，则基于小组所确定的优先级、时间表、资源、努力程度、风险、严重性以及其他任何相关的标准，判定该变更是在当前发布版的范围之内还是范围之外。确认重复或拒绝CCB 代表如果怀疑某个变更请求为重复的请求或已拒绝的无效请求

13、（例如，由于操作符错误、无法重现、工作方式等），将指定一个 CCB 代表来确认重复或已拒绝的变更请求。如果需要的话，该代表还从提交者处收集更多信息。更新变更请求提交者如果评估变更请求时需要更多的信息（详细信息），或者如果变更请求在流程中的某个时刻遭到拒绝（例如，被确认为是重复、已拒绝等），那么将通知提交者，并用新信息更新变更请求。然后将已更新的变更请求重新提交给 CCB 复审队列，以考虑新的数据。分配工作与安排工作时间项目经理一旦变更请求被置为已打开，项目经理就将根据请求的类型（例如，扩展请求、缺陷、文档变更、测试缺陷等）把工作分配给合适的角色，并对项目时间表做必要的更新。进行变更指定的角色指

14、定的角色执行在流程的有关部分中指定的活动集（例如，需求、分析设计、实施、制作用户支持材料、设计测试等），以进行所请求的变更。 这些活动将包括常规开发流程中所述的所有常规复审活动和单元测试活动。然后，变更请求将标记为已解决。核实测试工作版本中的变更测试员指定的角色（分析员、开发人员、测试员、技术文档编写员等）解决变更后，变更将放置在要分配给测试员的测试队列中，并在产品工作版本中加以核实。核实发布工作版本中的变更系统集成员已确定的变更一旦在产品的测试工作版本中得到了核实，就将变更请求放置在发布队列中，以便在产品的发布工作版本予以核实、生成发布版本说明等，然后关闭该变更请求。变更过程中的活动(活动图

15、)：3.2.1.3 变更过程中的变更请求状态状态定义已提交出现此状态的原因为：1) 提交新的变更请求；2) 更新现有的变更请求；或 3) 考虑在新的发布周期中使用已推迟的变更请求。变更请求放置在 CCB 复审队列中。 本操作的结果不会指定拥有者。已推迟变更请确定为有效，但对于当前发布版来说属于“超出范围”。处于已推迟状态的变更请求将得以保留，并在以后的发布版中被重新考虑并加以使用。可以指定一个目标发布版，以表明可以提交变更请求（以重新进入 CCB 复审队列）的时间范围。重复处于此状态的变更请求被视作对已提交的另一个变更请求的重复。变更请求可由 CCB 复审管理员或被指定解决它的角色置于该状态中

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

17、求状态将变为详细信息。考虑到可能会有新的信息，在 CCB 复审会议中将重新复审该变更请求。如果变更请求确认为无效，将被 CCB 关闭并且通知提交者。详细信息数据不足以确认已拒绝或重复的变更请求是否有效。拥有者自动变成提交者，将通知提交者提供更多数据。已打开对于当前发布版来说，处于此状态的变更请求已被确定为属于“范围之内”，并且亟待解决。它已定于在即将来临的目标里程碑之前得以解决。它被确定在“指定队列”中。与会者是提出变更请求并将其放入解决队列中的唯一权威。如果发现优先级为第二或更高的变更请求，应立即通知 QE 经理或开发经理。此时，他们可以决定召开紧急 CCB 复审会议，或立即打开变更请求以将

18、其放入解决队列中。已指定然后由项目经理负责已打开的变更请求，他应根据变更请求的类型分配工作；如果需要,还应更新时间表。已解决表示该变更请求已解决完毕，现在可以进行核实了。如果提交者是 QE 部门的成员，则拥有者将自动变成执行提交的 QE 成员。否则，拥有者将变成 QE 经理，以重新进行人工分配。测试已失败在测试工作版本或发布工作版本中进行测试时失败的变更请求将置于此状态中。拥有者自动变成解决变更请求的角色。已核实处于此状态的变更请求已经在测试工作版本中得到了核实，并且可以进行发布了。已关闭变更请求不再引人注意。这是可以指定给变更请求的最后一个状态。只有 CCB 复审管理员有权关闭变更请求。变更

19、请求被关闭后，提交者将收到一份有关对变更请求的最终处理结果的电子邮件通知。在下列情况中可能关闭变更请求：1) 其已核实的解决结果在发布工作版本中得到确认之后；2) 其拒绝状态得到确认时；或 3) 被确认为对现有变更请求的重复。在后一种情况中，会将重复变更请求通知给提交者，并将提交者添加到该变更请求中，以便以后通知他们（详情请参见状态“拒绝”和“重复”的定义）。如果提交者希望对关闭变更请求有异议，则必须更新变更请求并且重新将其提交供 CCB 复审。变更过程的变更请求状态(状态图)：3.2.1.4 保存变更历史记录如果工件为Word文档，则在文档的修订文档历史记录。如果工件为其他工件，必须在相应的

20、记录中保存变更历史纪录。3.2.1.5 变更请求中受影响配置项的变更在变更请求中受影响配置项需要变更时，首先由CCB协调员通知受影响配置项的变更人员，其次被通知人员按照标准变更流程进行变更。3.2.2 变更控制委员会 (CCB)1. 职责：CCB 的基本任务是明确产品的基线、复审对基线的变更、最后批准、否决变更或延期执行。2. 选择成员标准：从用户、开发人员、 测试小组、 项目管理中选择。3. 项目的CCB成员为：陈拓彬、田昊、付进、刘玉强、周永帅、李静、覃洁4. CCB 主席： 陈拓彬5. 处理变更请求和确认的过程：CCB以事触发为主要工作方式，必须定期(每个阶段结束时)按需召开会议。确保变

21、更提议及时得到了复审和处理。拟定变更复审通知协议。确保变更请求提交后，各有关人员都得到了通知，决定由谁复审各种工件。传达给同事和团队负责人，以及变更提议的接受者，并让他们有机会复审并参与意见。人员角色职责闫永会CCB主席协调组织赵文福复审员需求复审尹小平复审员需求复审、架构复审匡志辉复审员架构复审、代码复审袁伟复审员架构复审、代码复审李灵玲复审员代码复审、测试复审袁杰协调员负责通知由谁进行复审3.3 配置状态统计3.3.1 项目介质存储和发布进程3.3.1.1 项目介质保留策略、备份计划、事故处理计划、恢复计划1. 备份机制及保留策略：1) 每天下班时将主服务器的数据备份到备份服务器中。2)

22、备份服务器只保留最近一天的备份。2. 事故处理和恢复机制：如果出现事故(如：主服务器当机、遭病毒、硬件损坏等)，采用备份服务器上的数据进行恢复。3. 防病毒/杀毒机制：1) 杀毒/防病毒软件：Norton 2000。2) 频率：每周末杀毒。3) 负责人：系统管理员(袁杰)。3.3.1.2 介质保留方式：介质保留方式：联机。类型：磁盘（硬盘）。格式：Windows的文件。3.3.2 报告和审计目的：让项目经理确定需要报告哪些产品的相关变更数据，以及报告人和报告频率。频率：每周/每个阶段结束时进行报告。报告人：配置管理经理。1. 基于变更请求的报告。工作版本报告。工作版本报告中列出了构成软件某一特

23、定版本的一个工作版本的所有文件、它们的位置以及已并入的变更。2. 审计。包含功能审计和物理审计。1) 功能审计：核实软件配置项的实际性能是否符合它的需求。2) 物理审计：验证在配置管理系统中建立基线的工件是否为“正确”版本。3. 配置状态报告（参见附录3）4. 里程碑在每一次迭代完成时，设立一个里程碑。CM计划：在先启阶段创建，精化阶段各迭代中进行CM计划更新，精化阶段完成时CM计划完成。5. 附录 配置管理报表及其格式附录1基线发布表型目编号SQMS_001项目名称社区服务管理系统基线号01本基线配置项路径集成工作区基线包含工作名称版本号路径负责人SQMS1.0备注 无 【精品文档】第 11 页