《产品量化管理》讨论贴

gangshang521

产品量化管理

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

二、进度基础数据

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

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

gangshang521

三、度量数据

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

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

gangshang521

四、度量方法

度量指标	度量方法
设计缺陷率	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

终于Copy完毕，拍砖的火速，希望多多的人参与讨论、参与拍砖。共同学习探讨。

chengxq

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

gangshang521

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

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

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

非常感谢版主支持！

gangshang521

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

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

chengxq

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

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

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

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

gangshang521

呵呵，事先声明，我们是学术探讨，不存在高兴与不高兴，反之有人指出我还觉得高兴，有意思。真心话哈。

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

gangshang521

呵呵。就我们俩讨论，其他人呢。都来参与呀

chengxq

这个板块不是这个网站的主流板块，来的人不是很多
呵呵

e_tiger

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