selina 2007-1-4 14:25
对于缺陷管理，属不属于配置管理的范畴
缺陷管理，算不算配置管理的一部分。
有的人认为不算，觉得这是测试组的事情。
有的人认为算，因为缺陷与版本是关系紧密，像clearquest就与clearcase更是无缝集成的。
请各位谈谈自己的看法
lisaliu 2007-1-4 16:39
个人认为是输入配置管理的一部分,因为配置管理本身就包括每一个版本里面包含的错误数,已经每一个版本的具体功能说名,这些都需要从缺陷管理中获取,个人一件.仅供参考.
rocky_rup 2007-1-5 09:51
这个问题很值的讨论！
按照CMMI中，配置管理是属于支持过程域的，渗透到了需求、设计、编码、测试每一个过程活动中，因此，认为缺陷管理既属于测试，又属于配置管理是比较合适的观点。
若我们把缺陷管理简化为发现缺陷、修复缺陷、验证缺陷和关闭缺陷四个动作环节的话，不难发现这和变更请求管理极其相似，个人认为缺陷修复也是一种变更，是对一个质量水平虽不确定但却可以运行的特定版本的变更。
单从变更的角度上看，缺陷管理就应属于配置管理的范畴了，之外它还涉及到配置项、标识、版本、基线以及审计等。
不光是缺陷管理，需求管理中也是一样，有与配置管理交叉的地方...
qingqing 2007-1-5 13:10
同意rocky_rup，这个主题很值得讨论！
缺陷管理一般是指三个方面：
1。每一个缺陷被及时识别，并得到处理。（当然处理的方式有很多，但至少组织内要达成一致。）
2。缺陷趋势的分析。
3。缺陷数据的收集和总结，为组织提供缺陷预防等的数据。
公司一般都把缺陷管理作为测试team的一部分工作内容，但其实就像rocky_rup说的，如果缺陷也作为一种变更，
那就应该也作为配置管理的范畴了。
selina 2007-1-5 13:24
完全同意两位的意见
所以想和大家一起讨论这个话题
我觉得缺陷的出现就会引起变更
所以它就归到配置管理中
而测试组的话，应是测试的应用与执行。
比如，缺陷管理流程，并不由测试部门来定，而测试部，只是去执行这个流程
longtcg 2007-1-6 13:42
同意,本人认为,测试只不过是发现缺陷,而真正意义的缺陷还应该包括变更,有了缺陷就一定要去解决,这是测试不能完成的.
flyee_cn 2007-1-6 15:11
分成不同的阶段就跟不同的预联系到一起了，发现缺陷的过程跟ver，val联系到一起，后面的缺陷处理看你们怎么定义了，如果走变更流程的话跟CM就联系到一起了
shuku 2007-6-28 13:32
其实我想知道的是如果缺陷管理可以属于“变更管理”的一部分，那我们怎么去做？？
有哪位兄弟有具体的一套执行的思路或者方法么？？
W.ff 2007-6-28 15:12
配置管理之所以定义为支持类过程域，在这里就可以看出原因。
其实开发人员进行版本开发，然后交由测试组测试，测出的缺陷在返给开发,开发再看缺陷定义是否正确,正确就怎么怎么样,不正确又怎么怎么样.测试,统计,分析这些活动在这里看来没有配置管理也不是就做不了,不一定非得配置管理来做.但是,通过对CQ等工具的使用,使得整个缺陷处理的过程有了一个固定的模式,流程清晰化了,大家对故障的处理就轻松得多,高效的多了.支持类的作用就体现在这里,不是没有就不能活,但是有了就能活得更轻松.
就如前面各位所说,软件过程中的很多事务都是交错进行的,没法给出一个绝对的定义,我觉得也没有必要硬性说明某种活动是属于哪个范围的,.
[[i] 本帖最后由 W.ff 于 2007-6-28 15:27 编辑 [/i]]
毒药猪 2007-6-30 14:05
我个人认为缺陷管理过程的相关输出物都需要放入配置管理库中统一管理
Snow1 2007-9-18 13:08
缺陷管理是配置管理的一部分！！这一点毫无疑问
CMMI CM过程域中明确要求，配置管理要对变更进行跟踪控制，变更包括两部分：缺陷所引起的变更和从需求而来的变更。
所以缺陷管理属于配置管理的范畴是毫无疑问的！
xixiaojing666 2007-10-9 16:24
我觉得缺陷管理不属于配置管理的范畴,但是缺陷管理中的版本部分等等和配置管理有关系,需要进行配置管理,但不能因为版本需要配置管理,就说缺陷管理属于配置管理的范畴.
严格的讲我觉得缺陷管理和许多过程都有关系,比如VER\VAL\CM等等,但是如果说死它属于哪个过程,这个提法就不对,
根据本公司的特点,可以把缺陷管理流程定在VER\VAL\CM任何一个过程域,因为它和他们都有关系.
欢迎大家讨论,这只是我个人的观点.::em60:: ::em57::
阿布 2007-10-11 11:18
[quote]原帖由 [i]xixiaojing666[/i] 于 2007-10-9 16:24 发表
我觉得缺陷管理不属于配置管理的范畴,但是缺陷管理中的版本部分等等和配置管理有关系,需要进行配置管理,但不能因为版本需要配置管理,就说缺陷管理属于配置管理的范畴.
严格的讲我觉得缺陷管理和许多过程都有 ... [/quote]
nod
我觉得配置管理定义里说明的包括了哪些东西已经很清楚了，其中之一是变更的管理。
单说缺陷管理，是同CM，VER，VAL都有关的。我觉得不用讨论它到底应该被划分到哪个PA中。
例如需求管理，有RM，CM等都相关的。。。（还有一个PA叫什么的居然忘了，惭愧。REQM？）
lhjymry 2007-11-6 12:39
这个问题主要看公司是怎么定义缺陷管理的，和测试管理、变更管理肯定有交叉的地方，但是从测试的角度和从配置的角度来看缺陷，管理内容和重点一定有不同
helen_bj 2007-12-18 15:08
缺陷管理的一部分属于变更吧。。。
忘记是在哪里看见的，对变更进行分类，按照变更对象的类型来划分：文档变更和代码变更。代码变更主要是由问题单来引发的。
zhang88614 2007-12-18 17:32
回复 板凳 的帖子
说的挺好的，赞同你的观点。
owelowel 2008-4-11 10:48
缺陷的管理应该是属于配置管理的范畴吧．
测试应该只是尽量去发现这些缺陷．我想一般正规点的公司都有教给配置管理员来同意管理．
不过也有直接有测试部门直接管理．
veese 2008-4-11 11:32
缺陷，分解后有很多种。
1、如果可以忽略过去，那就不用管他了。
2、如果只需注明，不需要修正，那就写在文档里面就可以了。
3、如果需要修改程序，那就需要变更管理。
。
。
如上：2只需要对文档管理一下，3需要走配置管理中的变更流程。
我个人认为，配置人员是不应该去驱动软件开发，而是去维护这个过程。有一点像汽车和道路，配置人员是铺路的。
wenleili 2008-4-11 19:20
赞同rocky_rup 所说的，应该算配置管理的一部分，测试发现缺陷，开发需经过变更流程修改缺陷，并重新发布新的环境，这些都涉及到变更管理和版本控制
crppdzl 2008-4-12 22:53
本身没有包含关系,还是有相对独立性的
1、从理论上讲，配置管理过程涵盖软件产品的整个生命周期，但是从软件工程的角度上来说，应该还是有起独特的地方，并不能简单的和其他的活动混淆起来。这样也是刚刚从事配置管理工作容易犯晕的地方。
2、缺陷管理严格意义上来讲，因该属于测试范畴。但是从缺陷管理流程本身，其实和配置管理流程一样，同样涵盖了需求、设计、编码、构造、发布、部署、运行等阶段，可以根据企业的情况来定义整个缺陷管理流程。如果仅仅从流程的涵盖面或流程的覆盖范围去判断属于某个范围显然是不合适的。流程本身就应该是跨部门、跨专业领域