configuration160management160plan(编辑修改稿)

configuration160management160plan(编辑修改稿)内容摘要：

一个工作版本。 集成员还负责制定集成计划。 集成在子系统和系统级别进行，每次集成均有独立的集成工作区。 正如经测试的构件从实施员的专用开发工作区交付到子系统集成工作区一样，已集成的实施子系统也从子系统集成工作区交付到系统集成工作区。 与配置经理： 获取配置库的情况。 获取管理状态下的基线版本 任意角色 项目组所有成员 任何角色均可以 “签 入 ”和 “签 出 ”任何与产品相关的工件，以便在配置控制系统中进行维护。 此外，任意角色都可以提交变更请求，并 且对它们所拥有的变更请求进行更新。 工具、环境和基础设施 1. 工具 类型 使用时期 工具 原因 配置管理 先启 、 精化 、 构建 、 产品化 阶段 VSS 难度小， VSS 容易掌握。 2. CM 环境和基础设施 1) 产品数据量的预期大小 ：我们期望本项目至少有 20xx 个文件， 200M 的磁盘空间。 2) 产品团队的分配 ： 服务器和客户机的实际位置 ： 1 台。 PII450， 128M 内存、 20G 硬盘。 Win20xx Server。 服务器位置在 A310,客户端在 A310。 Configuration Management Plan 托普 LED 大屏幕播放软件项目 1ac6f1e41d382cf8f175a4c2b927fc8e Page 3 3. 配置管理活动 配置标识 标识方法 标签标识特定版本的工件。 组成某一版本 子系统的工件集，无论从整体还是从个体来说，都可通过特定的版本和标签进行标识。 因此，标签对于重新使用或引用原有的固定版本的工件集合很有帮助。 使用以下的产品工件标注约定，这些约定适用于标注 产品目录结构 中的路径和工件。 SYSTEM[A]_[SUBSYSTEM]_[A]_[R|A|B]X[.Y.Z][.BL] SYSTEM 标识系统 A 代表由三个字母组成的首字母缩写词 (TLA!)，用来表示系统创建中所使用的各种工件。 例如， 名称 对应的内容 PLN 项目计划 REQ 需求文件 USC 用例 MOD 模型文件 SRC 源代码文件 INT 公共接口 TST 测试脚本和结果 DOC 文档（用户文档、发布版本说明文档） BIN 可执行文件 SUBSYSTEM 标识子系统 A 代表由三个字母组成的首字母缩写词，用来表示在子系统创建使用的各种工件。 与上表保持一致。 名称 对应的内容 R|A|B 代表发布版、 Alpha 版或 Beta 版 X 整数，代表主发布版本号（例如 1） Y 整数（可选），代表次发布版本号 Z 整数（可选），代表备选发布版本号（修补程序、移植程序等） BL 代表基级（内部发布版本） 整数，代表内部发布版本号 以下是一些示例： 名称 对应的内容 Thorn 20xx 系统 发布版本 准备以 版本发布的 GUI 系统的内部发布版本号 Thorn 20xx 系统 Beta 发布版 计划在 发布版中发布的 Thorn 20xx 的内部系统基线第 16 号 Thorn 20xx 的维护发布版本 Configuration Management Plan 托普 LED 大屏幕播放软件项目 1ac6f1e41d382cf8f175a4c2b927fc8e Page 4 项目基线 在先启阶段、精化阶段、构建阶段和产品化阶段结束时建立 在各阶段内评审完成时建立 在各阶段内，由构架分析员或项目经理决定需建立基线时建立 工件按照信息集分组并加以说明。 基线标识 在各阶段中基线号：阶段基线号 + „_„ + 例：在精化阶段内的第三次基线： B20_3 基线 创建 非代码类基线：由配置经理根据《开发案例》创建。 代码类基线：由集成员根据产品构架文档创建。 基线发布 在每次创建基线以后进行发布。  非代码类基线：由配置经理发布。  代码类基线：由集成员发布。 基线发布表 (参见附录１ )。 配置和变更控制 变更请求的处理和审批 软件配置的变更管理适用于本项目的所有文档和代码，其中包括本项目的各个运行软件，也包括为本项目专门开发的支持软件。 变更请求表 单 变更请求表单是一个正式提交的工件，用于在整个项目的生命周期内跟踪所有的请求（包括新特性、扩展请求、缺陷、变更的需求等）与相关的状态信息。 所有变更历史记录，包括所有状态变更及变更的日期和原因，都将随 CR 一起保存。 进行多次复审和结束项目时都可使用此信息。 (参见附录 2)《变更请求表单》 变更申请的流程及涉及相关负责人如下图所示： 变更过程中的活动 活动 角色 内容 提交变更请求 提交者 项目的任何涉众均可提交变更请求 (CR)。 通过将变更请求状态设置为 已提交 ，变更请求被记录到变更请求追踪系统中（例如 ClearQuest）并放置到 CCB 复审队列中。 复审变更请求 CCB 此活动的作用是复审 已提交 的变更请求。 在 CCB 复审会议中对变更请求的内容进行初始复审，以确定它是否为有效请求。 如果是，则基于小组所确定的优先级、时间表、资源、努力程度、风险、严重性以及其他任何相关的标准，判定该变更是在基线号 建立时机 A10 先启结束 B20 精化结束 C30 构建 结束 D40 产品化 结束 Configuration Management Plan 托普 LED 大屏幕播放软件项目 1ac6f1e41d382cf8f175a4c2b927fc8e Page 5 当前发布版的范围之内还是范围之外。 确认重复或拒绝 CCB 代表 如果怀疑某个变更请求为 重复 的请求或 已拒绝 的无效请求（例如，由于操作符错误、无法重现、工作方式等），将指定一个 CCB 代表来确认重复或已拒绝的变更 请求。 如果需要的话，该代表还从提交者处收集更多信息。 更新变更请求 提交者 如果评估变更请求时需要更多的信息（ 详细信息 ），或者如果变更请求在流程中的某个时刻遭到拒绝（例如，被确认为是 重复 、 已拒绝 等），那么将通知提交者，并用新信息更新变更请求。 然后将已更新的变更请求重新提交给 CCB 复审队列，以考虑新的数据。 分配工作与安排工作时间 项目经理 一旦变更请求被置为 已打开 ，项目经理就将根据请求的类型（例如，扩展请求、缺陷、文档变更、测试缺陷等）把工作分配给合适。