软件工程配置管理.ppt

SP3.1 建立配置管理记录 评价要点： 配置项状态记录（包括版本情况、最新基线、变更情况） 状态记录向受影响的人员通报。 直接证据： 配置管理的各项记录（更改申请、出/入库单、软件更改单、配置状态记录、配置管理报告、基线审核报告、产品发布清单等）。 SG 3 建立完整性 SP3.2 执行配置审核 SP3.2 执行配置审核 执行配置审核以维持配置基线的完整性。 配置审核确认所产生的基线和文档符合指定的标准或需求。合适时应记录审核结果。 审核类型的例子，包括： 功能配置审核（FCA）：其目的是验证配置项的所测试功能特征是否已达到其功能基线文档中所规定的需求，且操作和支持文档是否完备和满意。 物理配置审核（PCA）：其目的是验证构造的配置项是否符合定义它的技术文档。 配置管理审核（CMA）：其目的是确认配置管理记录和配置项是否完备、一致和准确。 SP3.2 执行配置审核 典型工作产品： 配置审核结果。 措施项。 SP3.2 执行配置审核 子实践 ： 评估基线的完整性。 确认配置管理记录正确地标识配置项的配置状态。 评审配置管理系统中配置项的结构和完整性。 确认配置管理系统中配置项的完备性和正确性。 内容的完备性和正确性是基于计划中所阐述的需求和所批准的更改申请的处置。 确认与可用的配置管理标准和规程的一致性。 跟踪来自审核的措施项，直至关闭。 SP3.2 执行配置审核 评价要点： 有配置审核记录，审核包括：功能审核、物理审核和配置管理审核； 通过配置审核保证基线的完整性、一致性和正确性。 直接证据： 《配置审核报告》。 请各位批评指正 谢谢！ SP1.2 建立配置管理系统 子实践： 在配置管理系统中各控制级之间共享和传递配置项 。 存储和恢复配置项的归档版本。 存储、更新和检索配置管理记录。 从配置管理系统中生成配置管理报告。 SP1.2 建立配置管理系统 子实践： 保护配置管理系统的内容。 配置管理系统的保护功能的例子，包括： 配置管理文件的备份和恢复。 配置管理文件的归档。 从配置管理错误中恢复。 必要时，修改配置管理结构 。 SP1.2 建立配置管理系统 评价要点： 有配置管理系统； 有配置管理系统访问控制规程； 有配置库结构划分，访问权限的分配； 有更改申请数据库。 直接证据： 配置管理工具； 《访问控制规程》； SCMP中有关库结果、访问权限分配等的描述； 更改申请、出/入库单、配置管理报告。 SG1 建立基线 SP1.3 生成或发布基线 SP1.3 生成或发布基线 生成或发布基线供内部使用或交付给顾客 。 基线是一组经过正式评审同意后，作为进一步开发或交付基础的规格说明或工作产品，且若需更改基线，则应遵循更改控制规程。 基线表示将一个标识符赋予一配置项或配置项集及其相关实体。 随着产品的演进，可以使用多个基线控制其开发和测试 。 软件基线可以是已赋予唯一标识符的一组需求、设计、源码文件和相关的可执行代码、构建文件，以及用户文档（有关实体）。 SP1.3 生成或发布基线 典型工作产品： 基线。 基线说明。 SP1.3 生成或发布基线 子实践： 在生成或发布配置项的基线之前，从配置控制委员会（CCB）取得授权。 仅从配置管理系统中的配置项生成或发布基线。 文档化基线中的配置项。 使当前这组基线就绪可用。 SP1.3 生成或发布基线 评价要点： 有明确的基线定义； 有遵循规程生成或发布基线的记录。 直接证据： SCMP中有关基线的定义、构成，及创建和发布时间； 有关基线生成或发布的申请、审批、生成或发布的记录。 按专用目标组织的专用实践 SG 2 跟踪和控制更改 SG2 跟踪和控制更改 跟踪和控制对基线的更改。 在SG1 “建立基线”下的专用实践建立基线后，使用在SG2下的专用实践来维护此基线。 SG2 跟踪和控制更改 SG2 跟踪和控制更改的专用实践： SP 2.1 跟踪更改申请 SP 2.2 控制配置项 SG2 跟踪和控制更改 SP 2.1 跟踪更改申请 SP 2.1 跟踪更改申请 跟踪配置项的更改申请。 更改申请不仅来自新的或已更改的需求，也来自工作产品中的失效和缺陷。 分析更改申请以确定此更改对此工作产品、相关的工作产品、预算和进度的影响。 SP 2.1 跟踪更改申请 典型工作产品： 更改申请。 SP 2.1 跟踪更改申请 子实践 ： 启动并在更改申请数据库中记录更改申请。 分析更改申请中所建议的更改和补救措施的影响。 通过确保它们与所有技术和项目需求一致的活动评价更改。 评价更改对直接的项目和合同需求之外的影响。 对在多个产品中使用的配置项所作的更改可能解决一个产品中的一个直接问题