最近公司要过CMMI3，我是EPG小组的成员，主要负责配置审计的调查。大家能不能介绍一下配置审计的相关内容？
主要是以下几个方面：
1。配置审计的意义
2。配置审计的分类
3。进行配置审计的必要性
4。适合进行配置审计的项目类型
5。配置审计的步骤
6。进行配置审计的主要对象

小弟在此先谢谢各位大虾了！！

配置审计
  配置审计的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现。在某些情况下，它被作为正式的技术复审的一部分，但当软件配置管理是一个正式的活动时，该活动由SQA人员单独执行。 审计机制保证修改的动作被完整地记录，也就是说，记录了谁修改了这个工件，什么时候做的修改，为什么原因做出这个改动，以及修改了哪些地方。 在版本控制过程中，如果利用一些配置管理工具（或者版本控制工具）的支持，则可以自动地记录审计工作所需的四个“W”（Who、When、Why、What）。 同时配置审计工作应当可以说明如下信息。
配置审计应当说明的信息：
1. 变更要求被完成，并且对附加的修改已经执行了
2. 采用了正确的正式验证手段
3. 遵循了标准的要求
4. 变更的4W信息被完整记录，并和相关配置项关联

谢谢斑竹的说明，能不能详细说一下配置审计都需要进行哪些工作。
因为我现在要整理出来一个配置审计的流程，所以很多地方都不明白！请指导一下！小弟在此谢过了！

配置审计：

验证配置项信息与配置标识（需求、标准、流程…）的一致性

功能配置审计(FCA,Functional Configuration Audit)

物理配置审计(PCA,Physical Configuration Audit)

1.配置审计-What

FCA:验证配置项的功能特性与需求（原始需求、变更请求… ）的一致性

PCA:验证配置项的物理特性与期望（命名标准、变更流程… ）的一致性

2.配置审计-Why

预防提交错误的产品

捕获未完成的任务（原始需求、变更请求）

识别不同配置项之间的对应关系

确认配置项（们）已经被基线化

确认记录和文档维持可跟踪性

3.配置审计-When

软件交付或release时

每个阶段结束时

对于维护性项目，周期性地进行

4.配置审计-Who

非本项目组成员

其它项目中的配置控制者

内部审计者

SCM小组

5.配置审计-How

审计流程：

识别配置审计的时间[PM]

指派审计者[QA/Audit Group]

定义审计范围[PM&Auditors]

准备配置审计Checklist[Auditor]

通过评审（Review）、文档记录进行审计[Auditor]

识别不符合项[Auditor]

关闭不符合项[PM]

验证[Auditor]

很详细啊，一同学习了

谢谢斑竹啊！我可以试试，看能不能弄好，不明白的地方再问你。

一起学习，呵呵

共同进步

作者：任甲林　来源：希赛网
1、对模型研究不够深入
　　模型是多年软件工程经验的总结，里面的每一句话，每个例子都不是随便写上去的，都有其内在的含义在里面，需要仔细琢磨，仔细体会。作为EPG的成员，在遇到问题时，首先要做的事情是要去读模型，在模型中查找答案。市面上所有翻译的中文资料都不准确，所以要去读模型原文，以免以讹传讹。在读不懂的地方应该去读SW-CMM与SE-CMM，从那里获取类似的描述，如果还读不懂，可以去网络上搜索资料，与朋友交流。
　　当然，不能唯模型论，模型不会解决所有的问题，模型也只是描述了做什么，怎么做在模型里并没有详细描述，要解决怎么做的问题需要和有实践经验的专家进行沟通。只有真正理解了模型才能不唯模型论，才能根据实际进行裁剪。

2、 不善于与项目组沟通
　　规范的管理是着眼于未来的，可以降低犯错的概率，其效益可能在当前并不明显，规范的管理会改变开发人员的工作习惯，在他们的眼中可能认为规范是一种累赘，因此对规范的抵制是一种很自然的反应。
EPG是公司研发管理****的制订组织者，是体系推广者，项目组是体系的执行者，而EPG不是项目组的领导，在和项目组打交道时，不能以居高临下的姿态和项目组沟通，否则很容易引起项目组的反感，给体系的推广设置人为的障碍。
　　项目组里最有影响力的是项目经理，项目经理就是EPG的重点沟通对象。

3、不善于利用企业高层管理人员
　　过程改进也是一把手工程，尤其是在基础薄弱的组织中。如果缺少了企业高层的支持，体系的推广是寸步难行的。
　　EPG不是项目组的直接领导，不可以直接对项目下命令，因此在推广的过程要善于利用企业的领导，经常和领导沟通，和领导一起加深对研发管理的认识，从领导那里获得反馈，并借助领导的影响力促进体系在项目中的推广。
　　与领导的沟通是有技巧的，要根据领导的风格区别对待。有的领导喜欢直来直去，有的领导喜欢迂回曲折，有的领导喜欢独断专行，有的领导则比较民主。要将你的思想转换为领导的思想，就要采取一定的技巧，对症下药。

4、 不善于利用一切改进机会
　　为了推广体系，需要充分抓住一切在组织内教育员工、教育领导的机会。最典型的有4个机会：
　　（1）质量事故。一旦发生了质量事故就要刨根问底，追根溯源，以充分引起大家对质量的重视。
　　（2）成功案例。如果有个项目做的很成功，同样也要抓住机会，仔细深入地分析项目成功的原因，利用典型的成功案例教育大家。
　　（3）外部咨询。中国有句俗话：“外来的和尚会念经”，当有外部的咨询师或者评估师到企业时，也要充分利用这个机会，对员工和领导进行教育。
　　（4）内部调研。在企业里进行对管理现状的调查，是一种自底向上反应大家对组织规范管理需求的有效手段。管理永远是需要改进的，改进的动力来自于商务需要，也来自于群众的呼声，群众的呼声可以转换为商务需要。

5、 EPG本身作业不规范
　　EPG要以身作则，自己也要按规范办事，不能表现的很随意。比如：
　　EPG自己生产的文档不符合公司定义的各种的规范；
　　EPG自己的文档没有纳入配置管理；
　　体系文件的变更不遵守公司的变更流程；
　　EPG的工作缺乏计划性
　　对EPG的工作没有执行PPQA等等。
　　已身不正，何以正人？

6、 违背了循序渐进的思想
　　“以人为本，以过程为核心，以度量为基础，循序渐进”是当前各种管理模型的核心思想。管理的改进是文化的变革，要改良而非革命，不能拔苗助长，要冷水煮青蛙。一些软件开发中的基本实践看似简单，在企业里推行时却会困难重重，比如：需求文档化、设计文档化、计划文档化、同行评审、专职的测试等等。往往迫于商业目标的压力，在过程改进时，EPG会定义不切实际的改进目标，试图短期内见效，这样就要求项目组一次改进的地方太多，而这么做，很可能事与愿违，导致项目组比较抵触，即使短期内能够通过评估，一旦拿到证书，反弹也会比较大。

7、 忽略了裁剪指南
　　裁剪指南比体系本身更重要。僵化的体系是不可能真正在组织里推行下去的，要保持体系的灵活与敏捷，就必须定义详细的、实际的裁剪指南，并在实践中逐步完善。EPG的成员往往试图包罗万象，将体系定义的相当完备，在过程定义、模板定义上花费了大量的时间，而忽略了裁剪指南是体系的更重要的部分。这样导致在实际推广中，体系可以裁剪的选择余地很少，针对具体的项目组，往往会让项目组多做一些无法产生价值的活动，这样项目组就会产生一些抵触情绪。

8、 忽略了持续培训
　　在过程改进的初期会做CMMI的 introduction培训、过程域培训、管理技术的专题培训，在体系定义完成后，会做体系的培训。那些培训要么是集中在一段时间完成了，培训的密度比较高，效果并不好，要么间隔的时间比较长，培训后面时忘记了前面的内容。因此，需要在体系的推进过程中再将已经做过的培训的要点换个角度进行强化，使一些观念、一些做法深深的刻在每个人的脑子里，这样才能成为习惯，才能让执行者能够知其然，知其所以然，持之以恒地坚持下去。

9、 缺乏足够的软件工程经验
　　这一条实际上是在选择EPG成员时犯的错误。以CMMI模型的博大精深，要想充分理解其内涵，理解其精神，没有足够的软件工程背景是比较困难的。而很多企业的EPG成员恰恰就缺乏足够的软件工程经验，有经验的员工都去生产一线做项目经理、做部门经理，去直接创造商业价值了，间接创造商业价值或者会带来长期效益的管理活动便让一些缺少经验的人来做了，这实际上一种“脑体倒挂”。缺少经验的人需要到一线去工作，去锻炼，去提高，那些有经验的员工则需要充分贡献出其经验，充分发挥他们在企业里的正面影响力，而不是成为过程改进的阻力，这才是他们的价值的体现。

10、过分依赖咨询公司
　　EPG成员在建立公司内部过程体系的初期，往往会过分依赖外部咨询公司，要求咨询公司提供已成型的过程体系文档。每个组织都有其自身的特点，产品方向可能不同、组织结构可能不同、企业文化可能不同、人员结构可能不同、外部的商务环境也可能不同，因此企业的作业流程、文档格式等都可能不同。如果机械的照搬，那么势必会造成EPG建立的标准过程并不适合本组织，从而使过程改进见效缓慢，甚至夭折。

　　作者简介：任甲林，软件研发能力高级咨询顾问，10多年软件工程经验，曾任多家公司的研发总监。参与或主管了近50多个项目，在工作中积累了大量的研发管理经验，对CMMI、软件项目管理、软件公司管理、软件复用技术有较深的理解。

好贴，顶了，再收藏。