查看完整版本: 关于配置审计和如何开展

关于配置审计和如何开展

[size=2]看到大家对配置审计比较关心，现收集了一些资料和自己的想法，请大家参考：）

1.什么是配置审计
　　配置审计的任务是验证配置项对配置标识的一致性。
　　配置审计工作主要集中在两个方面，即：
　　功能配置审计：验证配置项的实际功能是否与其软件需求一致。
　　物理配置审计：确定配置项符合预期的物理特性。这里所说的物理特性是指特定的媒体形式。
     
      概念有点抽象，功能审计有许多方法，比如通过测试的方法，能够知道编码是否与需求一致。物理审计，主要是
按照流程、规范等来检查配置标识、变更记录、配置状态等的准确性。

2.为什么要实施配置审计
　　目标是为了确保软件配置管理的有效性，尽管对配置项做了标识，实践了变更控制和版本控制，但如果不做检查或验证，仍然会出现混乱。

3.如何实施配置审计
　　
　　项目经理和配置经理确定审计的人员。
　　配置审计人员准备配置审核检查单，并制定审计计划。
　　配置审计人员按照计划安排时间进行审计，审计活动可能涉及到：
　　项目范围           配置项的入库及出库
　　评审记录           配置项的变更历史
　　测试记录           文件的命名
　　变更请求           版本的编号
　　配置审计人员将在审计中发现不符合现象，做记录，并发送给项目经理，并对问题进行跟踪。
　　[/size]

愚见

其实我对配置审计的执行目的一直都不明白：

    1、功能审计怎么做？因为我们现在的功能审计是在配置项入库时，也就是通过项目组评审的时候就已经验证了（最主要的是这个审计是让QA去做的），我们配置在后期不断的维护中要如何做这个功能审计呢？？

    2、那么我们干脆把功能审计舍去，我们配置只作配置审计，那么这个配置审计就只针对配置项规范，一致性进行审计。比如命名，版本信息，审核时间，审批人是否符合实际情况，是否符合要求！


所以我甚至一直怀疑这样的物理审计是否符合CMM要求？

配置审计应该是QA组织的吧。包括物理审计与功能审计。

CMM/CMMi应该没有要求你必须做功能审计或者物理审计，只说了Perform configuration audits to maintain integrity of the configuration baselines. 实施过程中只需要有相应的audit做审查那些项就行了，没必要分什么物理审计或者功能审计，浪费太多时间，还有可能越弄越糊涂。
^_^

虽然还没有太多的实践经验，
但是翻看了一些SCM的书籍以及结合公司实际项目情况之后，
发现配置审计一般也就是做一些配置项状态统计、报告以及对变更控制结果的审查之类的工作。
不晓得各位大虾在实际的软件产品生产过程中对配置审计部分工作都是如何开展的呢？
::em34::

在我们公司的配置管理中，配置审计一般都是作基线审计，其他的只是配置管理员平时的跟踪。基线审计中的功能审计主要是根据需求、评审、变更记录等，查看各个配置项及输出产品是否保持一致；物理审计主要是看是否按照计划输出相应的工作产品。QA只是对配置审计活动的监控，也是对配置活动的监督。
这是本人在实际工作中的理解，有加强或认识不够的请大家帮忙指点哦

能够清楚地了解配置审计是什么当然最好了。
不过不能为了完成配置审计而去做配置审计，如果能够通过做配置审计而反映出项目的某些不足，哪怕只是一丁点，那也没白做了。

现在想想，以前我们做的配置审计就是为了审计而审计。。。。。

我们公司目前做的就是物理审计,
但是事实上,就是为了审计而审计的.只是觉得费时费神,没有其他任何的好处.

8楼的朋友说得很对,我们公司为了应付认证,补很多不现实东东,

如何做功能审计，我觉得是个大问题，配置管理员不是测试人员，怎么知道功能有没有实现。还有，我们在实际做的过程中说要控制活动的使用，但是控制活动其实并没有达到控制修改哪些功能，配置管理员如何知道这个活动修改了哪些东西，没错，从CQ的变更集可以查看到修改了哪写文件，但是，怎么确定这些文件的修改“恰好”解决了存在的问题或者修复了某个功能，而没有修改别的东西。

回复 #10 killer215 的帖子

配置审计实际上是对配置管理的过程、配置管理规范中的规定进行检查和统计报告。完全同意前面一些意见，由于采用了ClearCase和ClearQuest工具，实际上原有一些配置审计的内容已经变得比较简单了，因为工具已经帮助记录了绝大多数信息，只要定期出一些报告或进行一些二次开发就可以获取相当多的信息。下面仅举一些例子：

1. 从ClearCase基线报告中可以获得该基线所包含的功能
2. 另一方面，在ClearQuest运行已关闭任务、变更或bug等的报告
3. 配置审计的功能检查可以核对当初产品/版本发布计划预计发布的功能与此是否吻合

在物理审计方面，结合一些构建分析工具（例如omake/clearmake）应该可以发现一些临时文件或废弃不用的文件，从而保证产品/版本发布的正确性和准确性，在产品打包时也可以将真正必要的文件打进去。有一个极端不好的例子，某版本共包含2000个文件，但真正有用的只500个，那这个配置审计就太成问题了。

应该还有许多例子，比如检查基线、CQ活动的命名是否符合规范了；是否某个活动的变更集无端异常（关联了1000个文件，但标题只是改一个小bug而已）等。

总之，一切有助于SCM中数据完整性、正确性的举动都可视作配置审计的范畴。当然在具体执行时根据工具、流程的不同，以及人力、资源和时间的限制可以有所侧重。

看了楼上各位对配置审计的讨论，想问两个问题：
1、功能审计是否和QC的部分活动进行了重复劳动？如果不是，二者的区别或者说侧重分别是怎样的。
2、配置审计的频度问题。我们原本是定义在每个基线处进行的，但两次基线间可能形成很多文档之类并且已经入库，如果在下次基线形成时再审计就要涉及到很多配置项的变更，而如果在配置项入库前都进行配置审计又太繁琐了（实际上入库时有简单的对其进行查看），请问各位是如何处理的。

回复 #10 killer215 的帖子

从CQ的变更集可以查看到修改了哪写文件，但是，怎么确定这些文件的修改“恰好”解决了存在的问题或者修复了某个功能，而没有修改别的东西。

这个配置管理员的确不可能知道文件的修改状态，但是文件在修改过后有验证人进行验证，那么验证人就必须要能判断是否真的修复了问题或功能，而且如果能真正做到细致的话，在CQ的变更里面还应该写明修改了哪些文件的哪些地方，这样更方便验证人有针对的进行验证（不过现实中感觉实施起来有一定的难度）；另外落实责任制，如果一旦发现修改后出现问题，查明是验证人还是修改人的责任进行相应的处罚也能够起到一定的作用。

[[i] 本帖最后由 朱雀_陵光 于 2007-9-6 10:54 编辑 [/i]]

配置的功能审计到底该怎么做?由谁去做?CM、QA、专门人员？我觉得CM没有能力去做功能审计，QA没有去做功能审计的职责。
配置的功能审计和评审和测试的区别在那里？
是不是评审和测试可以代替配置的功能审计呢？
这是一直困惑我的问题。。。。。。。::em54:: ::em54:: ::em54::

配置审计一般是和QA审计一起做的，但侧重点不一样，从某种程度上说，qa还需要对配置流程和活动进行审计

一些功能审计的例子：
1.        特性列表是否完整、准确体现需求规范的要求？
2.        特性列表中的每个特性是否都已实现？
3.        测试数据、规定的测试过程以及测试结果是否都已经审核认可？
4.        CR以及相关配置项是否都已入库？
5.        是否整个过程中不受任何CR影响的所有配置项都已经重新编译和测试？
6.        是否存在本基线对应的CR列表？
7.        CR列表中说明已解决的CR是否全部处于closed状态？

嗯,
xixiaojing666
问的问题,我也很有兴趣.

功能审计,我觉得由scm来执行肯定是不合适的.
可以让QA 来参与执行.

::em58::
配置审计认真学习一下.

我们的配置管理审计报告物理审计和功能审计
但具体怎么做都没有特别细的规定
所以觉得工作很没有头绪

回复 17# 的帖子

我们定义的是由系统工程师来做，QA负责参与整个审计过程，不知道其他公司是怎么落实的