CMMI3配置管理文件

– 建立配置管理记录 – 执行配置审计
SP 3.1 建立配置管理记录
建立并维护描述配置项的记录 1. 配置项的修订历史 2. 变更日志 3. 变更请求记录 4. 配置项的状态 5. 基线间的差异
配置状态报告
20
SP 3.2 执行配置审计
执行配置审计，以维护配置基线的完整性 配置审计确定所产生的基线与文档符合规定的 标准或需求。 配置项相关的记录可以保存在多个数据库或配 置管理系统中。在这种情况下，配置审计应该 适当延伸到这些其它的数据库以确保配置项信 息的准确性、一致性与完备性
基线是一组配置项(CI)的集合：
– 经过了正式的评审和批准 – 作为进一步工作的基础 – 变更必须经过正式的变更控制程序
不同的基线可能：
– 在开发的不同阶段建立 – 控制权限会有不同
1.2 定义基线
31
推荐的基线
基线 需求 开发 运行 何时建立 客户需求评审 概要设计评审 发布给客户 CCB 项目经理 CCB 控制者
CM 主要活动
在给定的时间点上识别出配置项(CI) 建立一个基线库 系统地控制对配置的变更 在项目生命周期中维护配置的完整性和可 跟踪性
9
CM的目标
SG 1 Establish Baselines
– Baselines of identified work products are established. – 识别出了工作产品的基线
配置管理计划
配置项和基线
12
SP 1.2 建立配置管理系统
建立并维护用于控制工作产品的配置管理与 变更管理系统
配置管理计划
• 软件配置库的管理
13
SP 1.2 建立配置管理系统
软件配置库的要求
– 安全可靠性
• 保证软件配置库中的内容不被任意删除、修改 • 保证软件配置库不被非法用户获取
– 完整性
41
42
1. 2. 3. 4. 5. 6. 7. 8. 9. 所有经过批准的变更都已经得到实施 相关的配置项得到更新 没有进行未经授权的变更 已经建立了适当的状态报告入口 所有的新增或者变更的配置项都经过了质量检查点 发布的产品和软件需求、设计保持一致的 对发布进行评审，以确保产品满足客户需求 相关的变更控制机构已经审核过未处理的变更请求 版本描述文件已经准备完成
基线审计报告
22
配置审计
配置审计是指对于存储配置项及相关记录的软件 基线库的结构、内容进行检验，其目的在于验证 基线是否符合描述基线的文档。
配置审核工作主要集中在两个方面，即：
– 功能配置审核 (FCA)—— 验证配置项的实际功效是与其 软件需求一致的。 – 物理配置审核 (PCA)—— 确定配置项符合预期的物理特 性，即特定的媒体形式。 – 配置管理审计：这种审计的执行确定配置管理记录与 配置项是完备的、一致的与准确的。
• 保证各阶段基线各配置项的完整性
– 备份和恢复
14
SP 1.3 创建或发布基线
创建和发布了内部使用以及发布给客户的基线 基线表示为在一个特定时间点，将一个标识符赋予一个配置项 或配置项及其相关实体的集合。 随着产品或服务的演进，可以使用多个基线控制开发与测试。 一组常见的基线包括系统级需求、系统元素级设计需求以及在 开发结束／生产开始的产品定义。这些基线通常被分别称为 “功能基线”，“已分配基线”与“产品基线”。
2.3管理 问题报告
34
定义变更权威
正式基线（如客户需求）通常在配置控制 委员会CCB的控制之下，对于在工程过程中 的基线(如设计、代码基线)一般由项目经理 或者项目技术主管进行控制(手续不用很烦 琐)。
2.1 定义 变更权威
35
配置变更委员会CCB
CCB是授权进行正式基线变更的机构
– 例如客户需求、运行基线
职能：
– – – – 确保变更被分类以及被评估 评审和批准变更 确保只有被批准的变更得到实施 决定需要实施的变更的优先级
变更控制活动必须在整个项目中具有可视性 CCB成员可能包括： 项目经理，配置管理员，质 量保证人员，开发人员代表，客户代表
36
CCB主席的职责
设立接收变更的标准 发起对请求的变更的评估 从CCB成员获取建议的行动方案 解决关于变更请求的争议 做出CCB负责的裁决的最终决策 记录CCB会议纪要，记录 CCB对变更请求的 处理行动
32
推荐基线的内容
配置项 客户需求 软件需求
基线
需求 开发 运行
概要设计
详细设计 数据库设计 源代码
可执行代码
测试计划 测试案例/流程 开发工具 用户文档 运行文档
33
2. 控制基线的变更
目的
– 识别变更授权人 – 维护配置的稳定性和完整性 – 确保变更控制的有效性
2.1 定义 变更权威
2.2 控制变更
4.1 质量检查点
4.2 配置审计
4.3 基线发布
39
基线审计
在软件的每次发布之前都必须进行基线审 计以确保产品的一致性 进行基线审计的日程和步骤必须在配置管 理计划中得到规定 进行基线审计的人：
– 必须不是开发该软件的开发人员 – 必须具有相应的技术资格
4.2 配置 审计
40
配置审计
审计的目的是确定：
分析变更请求，以确ห้องสมุดไป่ตู้变更将对工作产品、相关工作 产品、预算与进度带来的影响
软件变更申请表
变更记录
17
SP 2.2 控制配置项
控制配置项的变更
– 对工作产品基线的配置保持控制。这种控制包 括跟踪每个配置项的配置、必要时批准新的配 置、以及更新基线。
软件变更申请表
变更记录
18
SG 3 建立完整性
基线的完整性得到建立与维护
在项目和产品整个生命周期范围内，CM可 以确保主要的工作产品得到适当的控制：
– 向项目参与者提供有关配置状态的最新信息 – 提供一种有序的配置环境，保证工作产品的变 更需求都能够达成，并采用非破坏性的方式来 实现 – 将更新错误版本造成的返工降至最低 – 维护版本的历史记录，必要时项目能够“回查” – 提供一致的基线，用于内部使用或者交付给客 户
– Integrity of baselines is established and maintained. – 基线的完整性得到了建立和维护
10
SG 1 建立基线
所识别的工作产品的基线得到建立
SP 1.1 识别配置项
– 识别出需要置于配置管理之下的的配置项，组 件和相关的工作产品
• • • • • 交付给客户的产品 指定的内部工作产品 采购的产品 工具及项目工作环境的其它重要资产 用于创建并描述这些工作产品的其它项
SG 2 Track and Control Changes
– Changes to the work products under configuration management are tracked and controlled. – 在配置管理之下的配置项变更得到跟踪和控制
SG 3 Establish Integrity
6
目的
配置管理（Configuration Management，CM） 的目的在于使用配置识别、配置控制、配置状 态记录与报告以及配置审计，来建立并维护工 作产品的完整性。
针对产品和服务的演变过程，配置管理 过程可以对它进行控制 这些过程也可避免出现混乱的工作环境， 以及无法控制的变更
7
配置管理的好处
1.1 识别需要 控制的产品
1.2 定义基线
1.3 建立 可追溯性
1.4 建立 配置管理库
26
配置项识别
“配置项"
– 开发中产生或者使用的任何条目 – 或者加入到产品中的条目
“例子”
– – – – – 规格说明 源代码 测试案例 编译器 数据库
“软件配置"
– 定义一个软件产品的所有配置项
1.1 识别需要 控制的产品
基础管理篇
之（一）
1
配置管理（CM)
Agenda
项目中的CM问题 CMMI中CM过程域描述与定义 CM的实践 CM工具
3
项目中的CM问题
4
开发中典型的CM问题
发错了版本 安装后不工作 异地不能正常工作 已经解决的缺陷过后又出现错误 开发人员把产品拿出去出售赢利 找不到最新修改了的源程序
5
CMMI模型有关CM实践解析
23
重要的GP
GP 2.3 提供资源 配置管理活动需要哪些充足的资源？ 例如：
– 配置管理工具 – 数据管理工具 – 存档与复制工具 – 数据库程序
CM实践
1. 定义基线 2. 对基线的变更控制 3. 配置状态统计报告 4. 评审、审计和发布 5. 管理CM活动
25
1. 定义基线
目的
– 创建能够在项目的整个生命周期上维护软件 产品完整性的框架
29
COTS, 工具等
现成的商业软件 (COTS)
– 在放入CM和发布之前，进行验收测试
供应商提供的软件 (如编译器)
– 必须评估其对现有软件的影响程度
非交付的软件工具 (e.g., test drivers)
– 在第一次使用之前必须放在CM中 – 变更必须经过项目经理的批准
30
基线是CM的基础
37
配置变更控制过程
拒绝请求
评估对产 品的影响
配置变更 请求 评估对项 目的影响
否
允许 变更
否
是
实施变更
结果 理想
是
更新基线
注：对于非正式的基线变更，配置管理人 员直到更新基线的步骤才参与。
38
4. 评审、审计和发布
目标：
– 确保放在配置控制下的每一项达到质量要求 – 基线在发布前确保其完整性得到验证 – 确保基线按照受控的方式进行发布