缺陷管理，算不算配置管理的一部分。
有的人认为不算，觉得这是测试组的事情。
有的人认为算，因为缺陷与版本是关系紧密，像clearquest就与clearcase更是无缝集成的。

请各位谈谈自己的看法

个人认为是输入配置管理的一部分,因为配置管理本身就包括每一个版本里面包含的错误数,已经每一个版本的具体功能说名,这些都需要从缺陷管理中获取,个人一件.仅供参考.

这个问题很值的讨论！

按照CMMI中，配置管理是属于支持过程域的，渗透到了需求、设计、编码、测试每一个过程活动中，因此，认为缺陷管理既属于测试，又属于配置管理是比较合适的观点。

若我们把缺陷管理简化为发现缺陷、修复缺陷、验证缺陷和关闭缺陷四个动作环节的话，不难发现这和变更请求管理极其相似，个人认为缺陷修复也是一种变更，是对一个质量水平虽不确定但却可以运行的特定版本的变更。

单从变更的角度上看，缺陷管理就应属于配置管理的范畴了，之外它还涉及到配置项、标识、版本、基线以及审计等。

不光是缺陷管理，需求管理中也是一样，有与配置管理交叉的地方...

同意rocky_rup，这个主题很值得讨论！

缺陷管理一般是指三个方面：
1。每一个缺陷被及时识别，并得到处理。（当然处理的方式有很多，但至少组织内要达成一致。）
2。缺陷趋势的分析。
3。缺陷数据的收集和总结，为组织提供缺陷预防等的数据。


公司一般都把缺陷管理作为测试team的一部分工作内容，但其实就像rocky_rup说的，如果缺陷也作为一种变更，
那就应该也作为配置管理的范畴了。

完全同意两位的意见
所以想和大家一起讨论这个话题

我觉得缺陷的出现就会引起变更
所以它就归到配置管理中
而测试组的话，应是测试的应用与执行。
比如，缺陷管理流程，并不由测试部门来定，而测试部，只是去执行这个流程

同意,本人认为,测试只不过是发现缺陷,而真正意义的缺陷还应该包括变更,有了缺陷就一定要去解决,这是测试不能完成的.

分成不同的阶段就跟不同的预联系到一起了，发现缺陷的过程跟ver，val联系到一起，后面的缺陷处理看你们怎么定义了，如果走变更流程的话跟CM就联系到一起了

其实我想知道的是如果缺陷管理可以属于“变更管理”的一部分，那我们怎么去做？？

有哪位兄弟有具体的一套执行的思路或者方法么？？

配置管理之所以定义为支持类过程域，在这里就可以看出原因。

其实开发人员进行版本开发，然后交由测试组测试，测出的缺陷在返给开发,开发再看缺陷定义是否正确,正确就怎么怎么样,不正确又怎么怎么样.测试,统计,分析这些活动在这里看来没有配置管理也不是就做不了,不一定非得配置管理来做.但是,通过对CQ等工具的使用,使得整个缺陷处理的过程有了一个固定的模式,流程清晰化了,大家对故障的处理就轻松得多,高效的多了.支持类的作用就体现在这里,不是没有就不能活,但是有了就能活得更轻松.

就如前面各位所说,软件过程中的很多事务都是交错进行的,没法给出一个绝对的定义,我觉得也没有必要硬性说明某种活动是属于哪个范围的,.

[ 本帖最后由 W.ff 于 2007-6-28 15:27 编辑 ]

我个人认为缺陷管理过程的相关输出物都需要放入配置管理库中统一管理