2010.8.24 ITPUB在线交流--项目配置审计
本周二，飞泉流水向大家分享了项目配置审计的心得。审计经常在公司里听见，配置管理在PMBOK中也着重提出，但配置审计就鲜有耳闻了。内容如下：
配置管理的目标是保证项目工作产品的完整性和一致性。
这里说的配置审计，可能跟大家平时说的审计，不大一样。 外部审计，有很多种，有：ISO复审、CMMI评估、财务审计、项目审计等。 审计的目标，就是为了保证配置管理的目标。 IEEE中的定义：确认产品的完整性并维护构件间的一致性，即确保产品是一个严格定义的构件集合。 其实现在项目，多数是做了配置管理的， 但配置管理是否达成了预期目标，就很难保证。
基线是项目一个阶段的完整、确认的工作产品集合， 是下一个阶段所依赖的内容。 所以基线在配置管理中，是非常关键的成果。 一般来讲，为了保证基线的正确性，都需要在基线发布前，做一次配置审计。 这是对项目组成员和后续工作负责的行为。
项目配置审计一般分为二种。 一是，物理配置审计(PCA)-审计的执行是在验证建置的配置项遵照技术文档的定义。 主要是审计是否遵循了规范和约定， 如：文件是否存放正确，文件名是否正确，版本是否正确，相关记录是否完整，人员和权限是否按规范来分配的。物理配置审计可以保证有工作产品存在，但内容是否正确和一致，并不能保证 这就需要进一步的审计，就是 二、功能配置审计(FCA)-审计的执行是在验证配置项的测试功能特征，达到功能基线文档所指定的需求，而且操作及支持文档已完整及满足。 简单来讲，就是说后续工作产品，通过审计，达成了需求所要求的内容。
审计其实就是专业人员的检查。 物理审计，相对简单，只要查规范是否正确， 功能审计，要求就非常高， 主要是查内容是否正确，判断标准就是是否符合需求， 形成基线后，应该是相对稳定的。功能审计上面说了，就是专业人员的检查，一般是靠经验。 就是静态地看文档，不运行软件。 这个功能审计难易与否，还在于专业人员。文档和系统的差距， 其实这就不是审计的问题了，就是项目实施的问题。审计只是在系统产生过程中，规避一些内容遗失、不一致的情况， 监理可以做这些工作
如果他有能力，能做到过程中的配置审计，那么很多问题会提前被发现和解决。
除了项目的配置审计，组织级的配置管理工作，也需要审计， 只是审计机会，会有不同 时机。 项目审计，一般是在基线发布前，保证基线的正确性， 是事件驱动的。 组织级的审计，一般是定期的， 也可以是事件驱动，但这种事件，一般是配置库或配置工作出现了很大的问题，才想起来做的， 相当于亡羊补牢。
感觉这方面内容多是用于乙方的内部审计，对于甲方更多的还是物理配置审计的内容。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/352988/viewspace-672001/ ，如需转载，请注明出处，否则将追究法律责任。
