配置管理之”配置审计(Configuration Audit)”

“SUP.8.BP8: 验证配置项的信息 / Verify the information about configured items”要求验证配置项及其基线的完整性，并确保基线的一致性。

在项目中，需要回答这样一个问题：如何确保“恰当地”建立了基线？特别是与客户有关的交付基线：

• 基线中是否包括了正确的文件（并行开发、有不同的Variant、分布式开发等场景时，这个问题尤为重要）？
• 所有计划交付的变更是否都已包括在内？
• 基线内容是否按照计划通过了测试？

​

为了回答上述问题，通常采用的对基线的验证方式，叫做“配置审计(Configuration Audit)”。

配置审计的目的是确保配置项(工作产品)的完整性(integrity)。

配置审计实施的不充分，可能会发生如下的情况：

• 已经修复的缺陷不时地再次出现
• 提交的功能最终没有包含在发布版本中

接下来，具体来看一下配置审计相关的Topic：

配置审计(Configuration Audit)

An audit conducted to verify that a configuration item or acollection of configuration items that make up a baseline conforms to a specified standard or requirement. (From CMMI-Dev V1.3)

为验证构成基线的一个或一组配置项是否符合规定的标准或需求而进行的审计。

配置审计(Configuration Audit)的类型

与基线配置审计相关的，主要有两种类型的配置审计：

• 功能配置审计（functional configuration audit, FCA）：

审计配置项的”功能正确性”，也就是配置项是按照流程要求完成了开发（如：实施了有效的评审或测试活动），配置项已达到要求的功能与质量属性特征。

• 物理配置审计（physical configuration audit, PCA）

审计配置项的“物理上的正确性”，例如：基线所包含文件、版本等的完整性/一致性等。

从如上两种类型的配置审计，可以看出：

配置审计的目的是从功能角度（如何执行从需求到测试的产品开发不同技术流程）和从物理角度（工作产品的构成、以及应用的Change）客观地评价工作产品的完整性。

配置审计示例（以软件架构设计为例）：

功能审计(FCA)：

• 正确建立了“软件架构设计”及其上游输入(软件需求规约)之间的追溯性

• 每个软件需求至少有一个软件架构设计元素与之关联
• 每个软件架构设计元素至少与一个能证明其合理性的软件需求相关联

• 有效实施了软件架构设计的技术评审

• 必要的相关方都参与了评审
• 有效使用了评审检查单，保证了评审的充分性和客观性
• 评审发现的问题有跟踪直至关闭

物理审计(PCA)：

• “软件架构设计”已置于配置管理系统中进行配置控制
• “软件架构设计”已按照配置管理计划的要求，进行了正确标识（如：命名、版本等）
• “软件架构设计”的属性是正确的，如：文档状态、密级标识等
• “软件架构设计”有进行正确的变更控制。例如：在上个版本基线基础上的所有变更，均执行了"变更控制程序"、文档变更履历与工作产品的变更是一致的。

补充说明：

项目中，有时还会实施【配置管理审计(Configuration Management Audit)】或【配置库审计(ConfigurationLibrary Audit)】，是定期对整个配置库进行审计，用来检查配置管理规则(如：命名规则、存储位置、权限等)的符合性。

配置管理系列文章的最后一篇！

推荐阅读：

• ​​ASPICE VDA Guideline解读(19)：SUP.8 配置管理​​
• ​​配置管理之配置项识别​​
• ​​配置管理之基线​​
• ​​配置管理之”变更控制”​​
• ​​配置管理之”配置状态记录”​​
• ​​Automotive SPICE和Automotive SPICE评估的那些事​​
• ​​如何达到并维持Automotive SPICE能力度级别​​
• ​​浅谈Automotive SPICE Level 3​​
• ​​上海先起之仨人谈起公众号文章合集下载！​​

文章转载自公众号：仨人谈起