配置审计

配置审计是指在配置标识、配置控制、配置状态记录的基础上对所有配置项的功能及内容进行审查，以保证软件配置项的可跟踪性。

1. 配置审计的任务

配置审计是对软件进行验证的一种方法，其目的是检查软件产品和过程是否符合标准、规格说明和规程。配置审计的对象既可以是软件产品，又可以是软件过程；既可以是整个软件产品或过程，又可以是部分软件产品或过程。其主要任务是：

① 检查配置项是否完备，特别是关键的配置项是否遗漏； ② 检查所有配置项的基线是否存在，基线产生的条件是否齐全；

③ 检查每份技术文档作为某个配置项版本的描述是否精确，是否与相关版本一致； ④ 检查每项已批准的更改是否都已实现；

⑤ 检查每项配置项更改是否按配置更改规程或有关标准进行； ⑥ 检查每个配置管理人员的责任是否明确，是否尽到了应尽的责任； ⑦ 检查配置信息安全是否受到破坏，评估安全保护机制的有效性。

2. 配置审计的类型

配置审计的类型包括功能配置审计和物理配置审计等。

功能配置审计是验证一个配置项的实际工作性能是否符合它的需求规格说明的一项审查，以便为软件的设计和编程建立一个基线。即，通过对软件测试方法、测试流程及测试报告的评价，鉴定软件配置项的实际功能、性能是否达到了软件设计文档所规定的要求。

功能审计的主要内容：验证是否已经完成了产品构建；验证产品实现的用户功能是否正确；审核软件功能是否与需求一致，并符合基线文档要求；通常要审查 测试方法、流程、报告和设计文档等。

物理配置审计是对照设计规格说明检验已建立的某个配置项，其目的是为软件的设计和编码建立一个基线。即，通过对软件配置项交付版本的检测，鉴定文、图、物的一致性，并保证软件更改的完整性，所有要求的程序、数据、规程和文档都包括其中。

物理审计的主要内容：评估软件基线的完整性；评审配置管理库系统的结构；验证软件配置库内容的完备性和正确性；验证与适用的配置管理标准和规程的符合型。审核

要交付的组成项是否存在，是否包含所有必需的项目，如正确 版本的源代码、资源、文档等等。

3. 配置审计的措施

为确保变更的实现，有两种措施：正式技术复审和软件配置审计。正式技术复审主要考虑所变更对象在技术上的正确性。软件配置审计作为一种补充，主要考虑那些通常不在复审过程考虑的因素。例如，是否遵循了软件工程标准，是否说明了变更日期和作者等。

配置审计人员准备配置审核检查单，并制定审计计划。配置审计人员按照计划安排时间进行审计，审计活动可能涉及到：项目范围、配置项的入库及出库、评审记录、配置配置项的变更历史、测试记录 、文件的命名、变更请求、版本的编号。

配置审计人员将在审计中发现不符合现象，做记录，并发送给项目经理，并对问题进行跟踪。

4. 配置的检查和评审

发布审核

1、 发行文档是否已经明确规定了发行范围？

2、 所有已经发现的缺陷或隐含差错是否均作记录？ 3、 是否有文档说明了再次发行的环境？

4、 是否有文档说明了部件极其发行部件的版本情况？ 5、 是否所有发行的配置项相互之间协调一致？ 6、 发行的产品是否从配置仓库取出的合适版本？ 基线库和配置项审核

1、 基线库是针对每一个软件配置管理计划制订的吗？ 2、 配置项均已放入适当的极限库吗？ 3、 需要的配置项能否在基线库中找到吗？

4、 配置项的命名是根据软件配置管理计划规定的命名方法吗？ 5、 配置项的版本号是根据软件配置管理计划规定的吗？

6、 所有的配置管理计划是根据配置管理计划规定的条件纳入基线的吗？ 7、 配置项是否正确标识、确定版本并记载变更历史吗？ 实施变更的审核

1、 所有的变更申请均已经处理了吗？

2、 变更请求是否列入所有要做变更的配置项？

3、 在变更请求中所有被标识要变更的配置项都已经作了变更？都作了质量控

制？

4、 任何配置项的两个版本相互交换能查出来吗？ 5、 对配置项进行变更之前已经将变更请求文档化？

6、 对配置项进行变更之前，变更申请是否已经分析、评价和批准？ 其他方面审核

1、 配置仓库是否作了备份？

2、 是否有适当的保密或授权制度来保证只有经过授权的团队人员才能做检入

和检出操作？ 配置管理员应配合研发中心产品管理部定期对项目进行配置管理的审核。在审核过程中，提供所需要的配置管理计划及相关资料，在项目开发结束后，需提交所有关于项目的软件配置库。

审计流程： 识别配置审计的时间 指派审计者 定义审计范围 准备配置审计 通过评审、文档记录进行审计 识别不符合项 关闭不符合项 验证 配置审计时间： 软件交付或release时； 每个阶段结束时； 对于维护性项目，周期性地进行； 5. 配置审计的作用

配置审计的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现。审计机制保证修改的动作被完整地记录。

6. 配置文件清单的维护

配置文件清单的维护由配置管理员维护；

项目初期，配置管理员与项目组成员一起对开发过程中可能产生的文档的进行预计，并在配置文件清单中列出这些文档及其大致的计划提交时间；

在实际开发过程中，文档提交可能会产生一些变化，如新增某些文档、原计划的一些文档不再单独产生、文档计划提交日期的变更等，项目组应该及时通知配置管理员，由配置管理员及时更改配置文件清单中的相应项。

附件

配置的检查和评审可通过配置管理制度的审核内容来进行检查。相关的审核内容如下表：

审核分类 审核内容 检查情况 发布审核 发布文档是否清楚地定义发布的范围，包括应被纳入的更改请求？ 否 所有已知缺陷/bug是否已文档化？ 是 是否有适当的文档，它标识重建该发布所需的环境？ 否 是否有适当的文档，它说明构成该发布的成分及成分的版本？ 是 发布的所有项是否彼此同步（在时间上一致）？ 是 是否采用正确存储库中的正确成分的正确版本生成发布？ 是 存储库/配置项审核 存储库是否按计划定义？ 否 项是否已经进入正确的库？ 是 是否按计划中规定的命名约定项命名? 是 是否按照计划，规定项的版本号？ 是 是否按照计划中规定的事件已经将所有项入库？ 是 项是否有所要求的文档以识别项、版本和更改历史？ 是 更改实施审核 是否全部所要求的更改请求均已结束？ 是 是否更改请求标识出全部拟更改的项？ 是 是否可能在项的任何两个版本中间区分更改？ 是 项的文档是否足够，能向后追踪更改到相应的更改请求？ 是 是否有恰当方法能回到以前的版本？ 是 审核的其他方面 是否对库作了恰当的备份? 是 是否已测试过从备份中恢复? 是 在群组成员的工作目录中是否有任何未经许可的成分？ 是 是否有恰当的保密/批准手续以保证只有经授权的群组成员才能进行入库/出库？ 是

项目名称： 审计人员： 基线配置项列表 一致性 备注 填表说明： 1、 表示的正确性，正确的打，错误的打。 2、 内容的正确性，根据评审记录进行检查。 3、 完备性：在“基线配置项列表”一栏中列出的配置项，如果在实际审计时配置库中没有，则不满足完备性。 4、 一致性：根据跟踪矩阵进行检查。

配置项状态 项目编号 编写人 日期 所属基版本标公布静态动态状变更次数线 识 时间 状态 态 （排序） 配置项总数 配置项变更数 配置项变化率 基线审计检查表 项目编号： 审计日期 标识的正确性 内容的正确性 完备性 项目名称 当前阶段 配置项标序号 识 汇总 备注 备注 填表说明： 1、 静态状态：新增、删除、变更。 2、 动态状态：正在变更、冻结。 3、 配置项变化率=配置项变更数/配置项总数。

配置审计报告

项目名称 产品名称 配置审计人 审计内容 审计依据 物理审计(PCA) 意见 配置管理系统中的配置项的是否完备，标识是否正确，存放位置是否合理？ 项目经理 产品经理 审计日期 功能审计(FCA) 意见 软件配置项的实际性能是否符合它的需求？ 纠正和预防措施 配置管理员对问题要提出纠正和预防措施。 下次评审日期 签名

项目经理: 产品经理: 配置管理员: