物理配置审计验证已构建出的配置项符合定义和描述它的技术文档，重点在于配置项的完整性，如配置项包含的工作产品是否存在？配置项的标识是否正确等。

　　功能配置审计验证配置项的开发已经被完全满足的审计行为，即验证配置项已经达到了在功能或已分配的配置标识中刻画的性能和功能特性，并且其运行和支持文档是完整的和满意的，重点在于一致性和正确性，主要表现为配置项的对应关系是否正确，如详细设计是否对应了概要设计、相应的变更请求是否全部被执行、待发布版本是否与发布计划内容一致、数据库配置是否与需求一致等等重点还在于工作产品与需求的一致性。

　　物理配置审计的范围是开发配置项和基准配置项，功能配置审计的范围是基准配置项。

　　物理配置审计一般由CME独立完成，功能配置审计一般由CME借助评审、测试等活动的结果完成。

　　物理审计的方法：

　　根据《配置审计检查单》去检查，该有的配置项是否都有了？文件命名与计划中的命名规则是否一致？存放位置与计划是否一致？版本设置与计划中的版本设置规则是否一致？控制权限是正确？

　　功能审计的方法：

　　a） 检查与需求的一致性、完整性：根据《需求追踪矩阵》对配置库的基准项进行检查，看看所有需求是否都已经不多不少地被实现了？并纳入了基准库？如果物理审计中基准项的审计没有问题，我们也可以通过《需求追踪矩阵》对《配置状态报告》中基准项进行检查，看看所有需求是否都已经不多不少地被实现了？

　　b） 验证工作产品与需求的符合程度：查看所有基准项评审和测试报告，看看所有的基准项是否都已经通过各级评审及测试？

　　c） 交付给客户的文档与软件的功能一致性：检查交付客户的文档是否与当前新的基准中的需求一致

　　【配置状态记录维护和发布】

　　CME在执行配置管理活动时需进行记录以保证其可追溯性。其内容包括：

　　● 配置管理记录维护：需要被记录的配置管理活动及内容如下：

　　　　● 基准建立情况：记录基准建立时间、基准版本、基准（变更）内容、提交者、配置者、变更请求编号

　　　　● 变更请求情况：变更请求编号、变更来源、变更对象（含变更内容、变更前后版本）、变更影响分析、变更实施日期

　　　　● 配置审计情况：审计日期、审计时机、审计对象（含版本）、审计不符合项、不符合项类别、不符合项纠正情况

　　● 配置状态报告发布：CME应每周/月发布配置状态报告，以便高层管理者、SQA、PM、项目成员及其它受影响的组织/个人通过配置状态了解项目状态。报告内容主要为受控库，报告内容应侧重于报告周期内基准建立、变更、产品发布情况及相应的统计分析。

　　对于基准建立和基准变更都需要记录基准建立情况，基准变更需要额外记录变更请求跟踪情况。基准变更的本质是变更请求流程+基准建立流程，两者通过 变更请求编号 进行关联。

　　配置管理工作是贯穿整个项目生命周期的核心基础工作之一，只有利用配置管理的理论把项目条理化、清晰化，才能将如需求、设计、开发、测试等其他工作纳入正确的轨道，保证整个项目的顺利进行。配置管理策划/计划是实施其它配置管理活动的前提条件，基准建立和基准变更控制是配置管理的核心工作，配置管理活动提供的状态报告和数据统计也为软件度量提供了决策依据。配置管理活动为项目管理提供了各种监控项目进展的视角，为项目经理确切掌握项目进程提供了保证。配置管理也为开发人员提供了一个协作的平台，在此平台上，大家能够更有效率的交流和协作。可以说，配置管理活动是软件开发的基石！