信息化建设网站范本,原神移动端,网页设计与制作知到智慧树答案,百度账号出售平台一、概述配置管理#xff08;Configuration Management#xff0c; CM#xff09;的目的在于使用配置识别、配置控制、配置状态记录与报告以及配置审计#xff0c;来建立并维护工作产品的完整性。1、简介“配置管理”过程域涉及以下活动#xff1a;• 识别所选工作产品的配…一、概述配置管理Configuration Management CM的目的在于使用配置识别、配置控制、配置状态记录与报告以及配置审计来建立并维护工作产品的完整性。1、简介“配置管理”过程域涉及以下活动• 识别所选工作产品的配置其在给定的时间点上组成基线• 控制对配置项的变更• 构建或提供规格说明以便从配置管理系统构建工作产品• 维护基线的完整性• 向开发人员、最终用户与客户提供准确的状态与当前的配置数据置于配置管理下的工作产品包括向客户交付的产品、指定的内部工作产品、采购的产品、工具以及在创建并描述这些工作产品时使用的其它项。见术语表中“配置管理”的定义。可能置于配置管理下的工作产品的实例有• 硬件与设备• 图纸• 产品规格说明• 工具配置• 代码与库• 编译器• 测试工具与测试脚本• 安装日志• 产品数据文件• 产品技术出版物• 计划• 用户故事• 迭代工作清单• 过程描述• 需求• 架构文档与设计数据• 产品线计划、过程与核心资产采购的产品可能需要由供方与项目都置于配置管理之下。供方协议中应建立执行配置管理的规定。确保数据完备且一致的方法应得到建立与维护。参阅“供方协议管理”过程域以进一步了解如何建立供方协议。工作产品的配置管理可按多个粒度级别执行。配置项可以分成配置组件与配置单元。在本过程域中只使用术语“配置项”。所以在这些实践中“配置项”适当时可解释为“配置组件”或“配置单元”。 见术语表中“配置项”的定义。基线为配置项的持续演变提供稳定的基础。基线的一个实例是已批准的产品描述包括内部一致的需求版本、 需求可追溯矩阵、 设计、特定学科条目与最终用户文档。随着基线内容得到开发基线被纳入配置管理系统。 通过配置管理的配置控制、 变更管理以及配置审计功能 对基线的变更以及从配置管理系统所构建的工作产品的发布得到系统化地控制与监督。本过程域不仅适用于项目的配置管理也适用于组织级工作产品如标准、规程、复用库与其它共享的支持资产等的配置管理。配置管理关注工作产品的管理与技术方面的严格控制包括交付的产品或服务。本过程域覆盖执行配置管理职能的实践也适用于置于配置管理之下的所有工作产品。对于产品线由于产品线下各产品之间以及核心资产与产品的多个版本之间的核心资产共享配置管理还涉及另外需要考虑的事项。见术语表中“产品线”的定义。在敏捷环境中配置管理是非常重要的因为需要支持频繁变更、频繁构建通常每天、多条基线与多个配置管理支持的工作区例如为个人、团队、甚至结对编程。敏捷团队可能陷入困境如果这个组织没有 1将配置管理自动化例如构建脚本、状态记录与报告完整性检查并 2将配置管理作为单独的一套标准服务加以实施。 在敏捷团队启动时就应该识别负责确保配置管理活动正确实施的人。在每个迭代开始时重新确定配置管理支持的需要。配置管理被谨慎地集成到各团队的工作节奏中把焦点集中在尽量减少对团队的干扰以使工作完成。见第一部分中的“使用敏捷方法时对 CMMI的解读”。 二、特定目标与特定实践摘要SG 1 建立基线SP 1.1 识别配置项SP 1.2 建立配置管理系统SP 1.3 创建或发布基线SG 2 跟踪并控制变更SP 2.1 跟踪变更请求SP 2.2 控制配置项SG 3 建立完整性SP 3.1 建立配置管理记录SP 3.2 执行配置审计按目标排列的特定实践1、SG 1 建立基线所识别的工作产品的基线得到建立。本特定目标包括建立基线的特定实践。“跟踪并控制变更”特定目标下的特定实践则用于维护基线。“建立完整性”特定目标下的特定实践则记录并审计基线的完整性。SP 1.1 识别配置项识别将置于配置管理下的配置项、组件与相关的工作产品。配置识别是下列各项的选择与规格说明• 交付给客户的产品• 指定的内部工作产品• 采购的产品• 工具及项目工作环境的其它重要资产• 用于创建并描述这些工作产品的其它项配置项可以包括硬件、设备与有形资产也可以是软件与文档。文档可以包括需求规格说明书与接口文档。其它用于识别产品或服务配置的文档例如测试结果也可以包括在其中。“配置项”是为配置管理指定的实体它可以包含构成基线的多个相关工作产品。这种逻辑分组为有效识别与受控访问提供便利。为配置管理选择工作产品应基于计划期间所建立的准则。工作产品实例1. 已识别的配置项子实践1. 基于文档化的准则选择配置项与组成配置项的工作产品在适当工作产品层次上选择配置项的准则的实例有• 由两个或多个组使用的工作产品• 由于错误或需求变更预期会随着时间变更的工作产品• 相互依赖的工作产品即当其中一个改变时将会导致其它工作产品的变更• 对项目成功至关重要的工作产品可能作为配置项一部分的工作产品的实例有• 设计• 测试计划与规程• 测试结果• 接口描述• 图纸• 源代码• 用户故事或故事卡• 声明的业务用例、逻辑或数值• 工具例如编译器• 过程描述• 需求2. 为配置项分派唯一标识。3. 明确说明每个配置项的重要特征。配置项的重要特征包括作者、文档或文件类型、软件代码文件的编程语言、最低的适于销售的特征以及配置项服务的目的。4. 明确说明每个配置项纳入配置管理的时机。确定何时将工作产品纳入配置管理的准则的实例有• 当工作产品准备好进行测试的时候• 项目生命周期的阶段• 对工作产品所期望的控制程度• 成本与进度的限制• 干系人的需求5. 识别负责每个配置项的所有者。6. 明确说明配置项之间的关系。将配置项之间存在的关系类型例如父子、依赖 纳入配置管理结构例如配置管理数据库中有助于管理变更的效果与影响。SP 1.2 建立配置管理系统建立并维护用于控制工作产品的配置管理与变更管理系统。配置管理系统包括存储介质、规程与访问系统的工具。配置管理系统可以包括多个子系统 它们具有适合每个配置管理环境的不同的实现。变更管理系统包括存储介质、规程以及记录并访问变更请求的工具。工作产品实例1. 具有受控工作产品的配置管理系统2. 配置管理系统访问控制规程3. 变更请求数据库子实践1. 建立多级控制的管理机制。控制等级的选择通常基于项目目标、风险与资源。控制等级可能因项目生命周期、开发的系统类型与特定项目需求有所不同。控制等级的实例有• 不受控任何人可以变更• 工作进行中作者控制变更• 已发布指定的权限授权并控制变更当进行变更时通知相关干系人控制等级可以从非正式控制到正式的配置控制前者是对开发期间的配置项更改所作的简单跟踪后者使用基线其变更只能作为正式配置管理过程的一部分。2. 提供访问控制以确保对配置管理系统授权的访问。3. 在配置管理系统中存储并检索配置项。4. 在配置管理系统中的控制等级间共享并传递配置项。5. 存储并恢复配置项的存档版本。6. 存储、更新并检索配置管理记录。7. 从配置管理系统中创建配置管理报告。8. 保存配置管理系统的内容。配置管理系统保存功能的实例有• 备份并还原配置管理文件• 配置管理文件的存档• 从配置管理错误中恢复9. 必要时修订配置管理结构SP 1.3 创建或发布基线创建或发布供内部使用以及交付给客户的基线。基线表示为在一个特定时间点将一个标识符赋予一个配置项或配置项及其相关实体的集合。随着产品或服务的演进可以使用多个基线控制开发与测试。 见术语表中“基线”的定义。硬件产品同软件与文档一样也应该包含在基础设施相关的配置基线中例如软件、硬件并作为包含软硬件交互的系统测试的准备。一组常见的基线包括系统级需求、系统元素级设计需求以及在开发结束生产开始的产品定义。 这些基线通常被分别称为“功能基线”“已分配基线”与“产品基线”。软件基线可以是一组需求、 设计、源代码文件及其相关联的可执行代码、构建文件与用户文档相关联的实体 它们被分派了唯一的标识符。工作产品实例1. 基线2. 基线的描述子实践1. 在创建或发布配置项的基线前从 CCB 获得授权。2. 仅从配置管理系统中的配置项创建或发布基线。3. 将基线所包含的配置项集文档化。4. 使当前的基线集随时可用SG 2 跟踪并控制变更置于配置管理下的工作产品的变更得到跟踪与控制。在“建立基线”特定目标下的特定实践建立基线后 本特定目标下的特定实践用来维护基线。SP 2.1 跟踪变更请求跟踪对配置项的变更请求。变更请求不仅应对新需求或需求变更也可应对工作产品的故障与缺陷。分析变更请求以确定变更将对工作产品、相关工作产品、预算与进度带来的影响。工作产品实例1. 变更请求子实践1. 发起变更请求并记录在变更请求数据库中。2. 分析变更请求中提议的变更与修复的影响。通过确保变更与所有技术及项目需求一致的活动来评价变更评价变更对直接的项目或合同需求之外的影响。对在多个产品中使用的配置项的变更可能解决一个直接问题而在其它应用中又引发一个问题。评价变更对发布计划的影响。3. 对变更请求分类并划分优先级识别紧急请求适当时提交给紧急权限。将变更分配到将来的基线中。4. 与相关干系人一起评审将要在下个基线中处理的变更请求并达成一致。与适当的参加者一起进行变更请求的评审。记录每一变更请求的处置与决策理由包括成功准则、适当时一份简要的行动计划、以及变更满足的或不满足的需要。执行处置中要求的行动并将结果汇报给相关干系人。5. 跟踪变更请求的状态直到关闭。要及时有效地处理纳入系统的变更请求。一旦变更请求得到处理只要切实可行以适当的经批准的行动尽快关闭此请求非常关键。 让措施长时间处于未关闭状态会让状态列表变得过于庞大反而会导致附加的成本与混乱。SP 2.2 控制配置项控制配置项的变更。对工作产品基线的配置保持控制。这种控制包括跟踪每个配置项的配置、必要时批准新的配置、以及更新基线。工作产品实例1. 配置项的修订历史2. 基线的存档子实践1. 在整个产品或服务的生命期控制对配置项的变更。2. 在变更后的配置项进入配置管理系统前获得适当的授权。例如授权可来自配置控制委员会、项目经理、产品负责人或客户。3. 以维护配置项的正确性与完整性的方式 在配置管理系统中检入并检出配置项以纳入变更。检入与检出步骤的实例有• 确定这些修订得到授权• 更新配置项• 将旧基线归档并检索新基线• 为该项的变更作备注• 关联对相关工作产品的变更例如需求、用户故事与测试4. 执行评审以确保变更没有对基线造成意外的影响例如确保变更没有危及系统的安全性或保密性5. 适当时记录配置项的变更与变更的理由。如果接受对工作产品提议的变更 则识别将变更纳入工作产品及其它受影响区域的进度。可针对变更类别裁剪配置控制机制。例如 对于不影响其他组件的组件变更的批准考虑可用较低严格度。已变更的配置项需经配置变更的评审与批准后才能发布。直到发布后变更才正式生效。SG 3 建立完整性基线的完整性得到建立与维护。基线通过“建立基线” 特定目标相关的过程得到建立 通过“跟踪并控制变更”特定目标相关的过程得到维护 基线的完整性则通过本特定目标下的特定实践进行应对。SP 3.1 建立配置管理记录建立并维护描述配置项的记录。工作产品实例1. 配置项的修订历史2. 变更日志3. 变更请求记录4. 配置项的状态5. 基线间的差异子实践1. 足够详细地记录配置管理行动使得每个配置项的内容与状态都可知且能恢复以前的版本。2. 确保相关干系人能访问并了解配置项的配置状态。配置状态沟通的活动实例有• 给授权的最终用户提供访问权限• 使基线副本对授权的最终用户随时可用• 当配置项检入、检出、变更、或对变更请求做出决定时自动提醒相关干系人3. 明确说明基线的最新版本。4. 识别组成特定基线的配置项的版本。5. 描述连续的基线间的差异。6. 必要时修订每个配置项的状态与历史即变更 其它行动。SP 3.2 执行配置审计执行配置审计以维护配置基线的完整性。配置审计确定所产生的基线与文档符合规定的标准或需求。配置项相关的记录可以保存在多个数据库或配置管理系统中。在这种情况下配置审计应该适当延伸到这些其它的数据库以确保配置项信息的准确性、一致性与完备性。 见术语表中“配置审计”的定义。 )审计类型的实例有• 功能配置审计functional configuration audits FCAs这种审计的执行验证配置项的开发已经符合要求地完成该项已经达到功能基线或已分配基线中规定的功能与质量属性特征而且操作与支持文档是完备的并符合要求。• 物理配置审计physical configuration audits PCAs这种审计的执行验证所构建的配置项符合对其定义并描述的技术文档。• 配置管理审计 这种审计的执行确定配置管理记录与配置项是完备的、一致的与准确的。工作产品实例1. 配置审计结果2. 行动项子实践1. 评估基线的完整性。2. 确定配置管理记录正确地识别配置项。3. 评审配置管理系统中各项的结构与完整性。4. 确定配置管理系统中各项的完备性、正确性与一致性。配置管理系统内容的完备性、正确性与一致性基于计划中所述的需求与已批准的变更请求的处置。5. 确定符合适用的配置管理标准与规程。6. 跟踪来自审计的行动项直到关闭
