51Testing软件测试论坛

标题: 《产品量化管理》讨论贴 [打印本页]

作者: gangshang521 时间: 2008-11-25 14:51
标题: 《产品量化管理》讨论贴

产品量化管理

Author: Vince

http://blog.csdn.net/vincetest

关键词：量化、质量、进度、成本、缺陷、缺陷率、KLOC、漏测率、质量系数、进度系数

产品研发主要从质量、进度、成本这三方面考虑并在其中获取平衡点，本文主要从质量、进度来考虑产品的量化管理，在文中主要以数据表格化的形式来体现。
一、质量基础数据

产品名称	产品设计阶段			开发阶段			测试阶段			运营维护
产品名称	需求文档(页)	总规格	缺陷规格	设计文档(页)	代码(行)	遗留BUG数（个）	测试文档(页)	BUG数（个）	漏测BUG(个)	失误次数
×××产品	×××规格设计(25)	50	5	×××架构设计(30)	50000	5	×××测试方案(15)	50	2	0

表格数据说明：
1、规格数量是以最小功能特性点为单位计算；
2、BUG数量是以公认有效Bug来计算
3、数据来源：
【需求文档】产品设计人员编写的产品设计所有文档
【总规格】产品设计的规格总数或特性总数
【缺陷规格】开发人员或测试人员发现的规格错误总数
【设计文档】开发人员编写的所有文档包括系统设计、详细设计等
【代码】开发人员编写的代码行数
【遗留BUG数】开发人员尚未解决的问题总数，是指所有未解决的开发类问题，并非仅只测试人员发现的问题。
【测试文档】测试人员编写的所有文档比如测试方案、测试用例等
【BUG数】测试人员发现的被公认的有效问题
【漏测BUG】开发人员、合作伙伴、客户反馈在经过测试发布后发现的Bug
【失误次数】运营维护过程中出现的任何问题比如内容失效、数据错误等

[ 本帖最后由 gangshang521 于 2008-11-25 16:32 编辑 ]

作者: gangshang521 时间: 2008-11-25 14:58
二、进度基础数据

产品名称	产品设计阶段			开发阶段			测试阶段
产品名称	计划工期	实际工期	得分	计划工期	实际工期	得分	计划工期	实际工期	得分
×××产品	20	18	9	30	35	6.57	10	10	8

表格数据说明：
1、工期以人天计算；
2、数据来源：
【计划工期】计划完成的工期，如果中途因特殊原因经审批可申请变更
【实际工期】实际完成的工期
【得分】参见Sheet【度量方法】描述

作者: gangshang521 时间: 2008-11-25 14:59
三、度量数据

产品名称	质量度量					进度度量(分)				总体系数 SQ∑
产品名称	设计缺陷率(%)	遗留BUG率(%)	代码缺陷率(KLOC)	漏测率(%)	Q∑	产品设计	开发	测试	S∑
×××产品	10	10	1	3.8	6.62	9	6.57	8	7.83	7.225

表格数据说明：
1、该表格为总体数据度量结果，详情可查阅【质量基础数据】和【进度基础数据】；
2、表格中各项度量数据根据【质量基础数据】和【进度基础数据】及【度量方法】计算而得。

作者: gangshang521 时间: 2008-11-25 14:59
四、度量方法

度量指标	度量方法
设计缺陷率	N = (缺陷规格/总规格)*100
遗留BUG率	N = (遗留BUG数/BUG数)*100 公式说明： 1.Bug数量以测试人员发现的有效Bug为基准 2.对于后期发现的漏测Bug也纳入计算
代码缺陷率	N = (BUG数/代码行)*1000 公式说明： 1.Bug数量以测试人员发现的有效Bug为基准 2.以1K行代码为单位级别及KLOC计算
漏测率	N = (漏测BUG/Bug总数)*100 公式说明： 1.Bug数量以测试人员发现的有效Bug为基准 2.漏测BUG为测试发布后非测试人员发现的Bug 3.Bug总数为测试人员发现的Bug与漏测BUG之和
质量系数Q∑ (10分制)	N ＝[100 －（设计缺陷率＋遗留BUG率＋(代码缺陷率*10)＋漏测率）]/10 公式说明： 1.N值越高质量就越好 2.可以考虑为各指标加权计算。
阶段进度值（10分制）	N = 8 ＋ [（计划工期－实际工期）/基准工期]*10 公式说明： 1.工期单位人天,8分为基准合格分数。 2.提前或者按时完成时计划工期即为基准工期，当延迟完成时实际工期即为基准工期 3.N值最大为10 4.若一直未完成则N为0 5.开发人员解决问题的进度也纳入开发总进度一起计算
进度系数S∑ （10分制)	N = (产品设计进度值＋开发进度值＋测试进度值)/3 公式说明： 1.N值越高进度就越好 2.N值为各阶段进度的均值 3.可以考虑为各阶段加权计算。
总体系数SQ∑ （10分制)	SQ∑ = Q∑WQ + S∑WS 公式说明： 1.WQ、WS分别为质量和进度的权重值，WQ＋WS ＝ 1，默认WQ＝WS＝0.5； 2.SQ∑值越大说明产品研发运作越好。
特殊说明	1.如果进度压缩或者其他不可抗拒因素须注明即可。 2.根据度量结果以项目为单位对数据进行分析并提出改进方案及计划，持续改进。

作者: gangshang521 时间: 2008-11-25 15:01
终于Copy完毕，拍砖的火速，希望多多的人参与讨论、参与拍砖。共同学习探讨。

作者: chengxq 时间: 2008-11-25 15:53
楼主，刚大概的看了一下（质量），总结的很好，崇拜！
个人说点想法，只是为了抛砖引玉
首先，量化管理很适合中国，中国这样的国情也只能通过量化管理进行我们软件的项目管理
如果在国内，弄点感性的东西，很多东西都无法执行，只有通过数据，事实来说话
其次，如果像楼主这样的计算，前提我感觉很重要，不能忽略前提，就是说，我们的测试，review的
有效性要比较高，具个例子来说，如果我们开发的工作产品质量不是很高，但是由于我们的测试有效性
比较低，大家也就是随便点点，那么按照你的质量模型，那个质量系数就会很高，所以前提保证我们的
有效性
还有说点细节，就是我们测试注入和测试检出的问题，在楼主你的模型中，我没有发现需求的注入与检出的
字眼，不知道楼主是如何考虑的，希望和大家分享
在质量模型中，你也说到这个加权值得问题，我想知道，你这个权值如何得来，根据历史经验还是根据项目
的实际比重呢，楼主是否有相应的经验呢，个人感觉这个点是比较难把握的，如果权值分配不合理，那质量
系数值就不一样，而且可能会相差很大，那么你的模型的有效性如何考虑呢
呵呵，说的有点多了，楼主，希望能将你的学识和大家沟通探讨！
谢谢！

作者: gangshang521 时间: 2008-11-25 16:25
呵呵，很高兴版主参与讨论。我发这个贴也希望起个抛砖引玉的作用。我的认知如下：
一、就像版主所说的那样，现在不论大小公司都有流程有规范，但是实际执行很是困难，这些都是很感性的东西，往往被别人认为是制定流程或规范的人在忽悠大家。这样一来就缺乏权威，也就缺乏执行度。
有了统计度量数据之后，我们就有评估依据了，可以这么理解：数据就相当于目标，规范相当于过程，比如告诉过路人终点和到达这个终点的路线，而这个路线本身就是一条直线。我想过路人到达这个目标肯定是走直线了，这里所谓的直线就是规范和流程。举个实在的例子：开发人员将没有做稳定没有达到测试准则的东西就拿出来测试测试人员测试出来的Bug自然就很多，直接影响到代码缺陷率，也就能影响开发人员的绩效，这就是不规范的例子。这就自然会引导流程规范。

二、对于版主所说的测试的有效性那肯定是要保证的。还有其他统计数据来源的可靠性急准确性也需要保证。这些都需要规范来支撑。对于质量评估模型中的权值这个需要团队中的技术专家来衡量了。或者大家一起评估。

三、对于这方面的经验来说我可能也算是一个新手，呵呵，对于这个《产品量化管理》也是我的一个新想法，这个也很容易操作。正准备在公司执行。所以是否科学和合适有待于考证。希望广大同仁一起探讨。

非常感谢版主支持！

作者: gangshang521 时间: 2008-11-25 16:30
补充：需求的注入与检出这点确实没有明显的提及，算是一个遗漏点。需求的注入对于每个公司不一样，需要根据实际情况，我暂时没好的想法，正在考虑中。。。。。，对于检出可以由下游人员比如开发人员测试人员来执行，甚至后期的运营。

这点大家都多发表下看法谢谢！

作者: chengxq 时间: 2008-11-25 16:36
LZ你好，我说句话，你可能不太高兴，不过我没有别的意思啊，只是为了探讨和沟通
首先：这个可执行性，刚才你也说了，通过规范来保证有效性，那么我们公司的规范是否成熟，我们的人员是否成熟，如果开发组遇到进度等问题的时候，那我们的规范如何考虑？

其次：关于这个质量系数，对于越高越好，我有点疑问，应该不是越高越好，因为我们的在缺陷检出的时候，肯定会发现一些缺陷，缺陷的高低都是不正确的，现在按照这个模型，是要求越低越好，好像有出入

再次：个人的建议，如果我们能保证我们的过程，那收集出另外的质量模型可能更加有利，这个模型就是，一定的规模下
缺陷的发现和遗漏的比例是多少，区间是多少，这样可能还有点收集意义，对于你上面说的质量系数，可能需要改进

希望能再次探讨，我想知道你打算如何去做，可能有什么问题，呵呵

作者: gangshang521 时间: 2008-11-25 16:52
呵呵，事先声明，我们是学术探讨，不存在高兴与不高兴，反之有人指出我还觉得高兴，有意思。真心话哈。

关于质量模型。一定的规模下缺陷的发现和遗漏的比例是多少，这点确实相对科学。对于质量模型也是我的一个初步的设想，肯定存在问题。能指出来，很不错。这也是我发帖出来讨论的初衷。

作者: gangshang521 时间: 2008-11-25 16:54
呵呵。就我们俩讨论，其他人呢。都来参与呀

作者: chengxq 时间: 2008-11-25 17:26
标题: 回复 11# 的帖子
这个板块不是这个网站的主流板块，来的人不是很多
呵呵

作者: e_tiger 时间: 2009-5-26 15:08
严重关注，我也正在考虑我们公司的量化管理方式，有一个操作上的问题想问楼主，所有基础数据是怎么采集的？由各项目组上报还是自己在配置管理、QC等工具上去统计的？

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)