关闭

软件评估--->Bug的价值(产品市场角度分析)

815人阅读 评论(0) 收藏 举报
  总是在考虑,谁是公司直接财富的创造者,谁又是公司财富间接创造者,他们在各个岗位上的价值是怎么评估出来的。而公司的品牌价值又是怎么评估出来的?可是显然问题的范围太广,完全超出我的理解范围了。所以呢就从工作中的最小单位来评估,可能比较容易得出结果!评估Bug的价值这个思考过程应该很有创造性的!

  评估的第一个切入点问题:Bug的等级和每个等级Bug的价值是多少?


  公司内部对Bug分成P10,P20,P30,P40来分的。这个公司在接受CMM评估时,肯定会有明确定义的,可惜偶看不到。
从一个bug对产品质量的危害的严重程度,这个角度来看,我们可以大概衡量出这个bug在产品中的比重。显然这个和等级有相关性,P40的bug在产品中占的比例要比P30大的多,P30的又比P20的大的多。

//-------P40Bug的价值评估!-------
   这是一个角度衡量。P40的是最严重的,它危害是可能是整个产品不能用,或产品的一个模块的所有功能都不能使用,或者产品在某个支持的主流平台上不能工作。这种bug的价值应该几乎相当与这个模块的价值了。P40Bug和模块价值等价,从产品价值方面考虑,这种一种评估方法!这样的话P40Bug的价值就会依赖于模块功能在市场上的市价。结论:P40的bug就是模块价值的100%的比例。

//-------P30Bug的价值评估!-------
   这个P30的Bug,它主要应当是模块中的某一个功能不能用,出了问题。这个功能在模块中占的百分比,需要看具体的问题而定,具有一定的滑动性。模块有10个功能,其中有2个功能出了问题的,就是20%的比例吧!结论:P30的Bug是模块的价值*bug在模块中占的比例。

//-------P20Bug的价值评估!-------
   由于现在在项目CF的时候,只要求对P30以上的bug缴觅干净,所以P20的bug的价值在产品中几乎算不计了!

一个项目做完的时候,我们的统计一下,所有P40和P30的bug的价值,再将它折算成市价,哈哈,这样QA就能算出,这个项目中我们创造了多少的产品价值。一个产品在CC的时候的价值到Release的时候的价值,应该是在不断上升的,因为Bug的数量在上升嘛!QA在里面付出劳动了。

下期,会从产品生产线的内部角度分析Bug的价值。 它还应该是QA发现Bug付出的代价 + DEV修改Bug付出的代价。
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:9679次
    • 积分:169
    • 等级:
    • 排名:千里之外
    • 原创:8篇
    • 转载:0篇
    • 译文:0篇
    • 评论:0条
    文章分类
    文章存档