笨猪 发表于 2008-7-25 14:06:13

对软件项目数据的统计分析

最近工作的疑问:
1.如我们在同行评审的时候,我们发现的问题数,然后根据评审的时间,可以算出其中的效率,问题是,我们是否可以建立问题数的收敛率来说明,项目的一个品质质量呢?举例:如我第一次发现10个问题,然后修改,在评审,发现5个问题,然后再修改在评审发现2个错误,那么按照这样的收敛率,是否可以反映出质量目标呢?其次对于评审的效率,我们是否可以建立一个模型,但是如何建立我没有想明白,希望高人同时指点(这问题个人认为也适用于测试)
2.现在按照CMMI等模型的要求,对数据进行收集分析,但是对于一个项目,那些数据的收集分析是重要的,那些事不重要的,好像任何资料上都没有定义,可能会说,根据项目的实际情况来,但是现在的实际情况是,大范围,国人对品质的忽略(可以从品质人员待遇和开发人员的比较而来),小范围是,我们公司从CMMI导入到CMMI4,其实很大一部分是由于文档下的CMMI4,在实际的过程改进中,员工们更多的是将CMMI和项目对立起来(为了写文档而文档)以及IT行业的跳槽,到导致了,员工的品质管理概念很难建立起来,所以我们的项目经理,除了技术外也不清楚需要什么数据?那作为品质管理人员如何去做呢?
希望高人指点!

chengxq 发表于 2008-7-28 16:03:08

同问!?:'(

zhongmg108 发表于 2008-7-30 14:23:01

首先声明,我不是高手,只是给一些自己的想法,也不一定正确,仅供大家参考.

1.如我们在同行评审的时候,我们发现的问题数,然后根据评审的时间,可以算出其中的效率,问题是,我们是否可以建立问题数的收敛率来说明,项目的一个品质质量呢?举例:如我第一次发现10个问题,然后修改,在评审,发现5个问题,然后再修改在评审发现2个错误,那么按照这样的收敛率,是否可以反映出质量目标呢?其次对于评审的效率,我们是否可以建立一个模型,但是如何建立我没有想明白,希望高人同时指点(这问题个人认为也适用于测试)
这个问题我觉得应该放在整个评审活动中去解决,以获得更好的评审结果(更少的时间,发现更多的缺陷,最大程度地提高产品质量)。从你描述的评审活动来看,你们的评审活动效率并不高,而且不可行,评审专家不可能反复地去投入评审活动。
我觉得一个高效评审活动应该注意以下几个环节:评审计划、评审专家、评审入口准则、评审准备、评审问题确认、评审出口准则、评审问题修改和跟踪等。
评审活动又可分为内部评审和外部评审,在提交外部评审之前,工作产品一定要确保经过充分的内部评审,这是外部评审的入口准则,当然可能说得比较含糊,明确一点说就是:没有明显的描述错误和语法错误、使用正确的文档模板等。
一定要严守评审活动的入口和出口,在提交外部评审前,一定要确保文档的质量水平;出口准则包括,确保发现缺陷的确认、修改、验证,相关的批准,配置管理活动等。
项目质量的目标在做质量计划时应该已经明确,包括产品质量目标和过程质量目标。产品质量目标也就是指产品的缺陷密度(=缺陷个数/产品规模);过程质量目标主要指过程的有效性(该阶段评审发现缺陷百分比=该阶段评审发现缺陷个数/该阶段引入缺陷总数)。
另外要注意在缺陷计数时,应该统一标准,什么样严重程序的缺陷应该计算进去(一般的语法、错别字等提示类缺陷不计算进去的,但可以用来判断初始文档质量)。
其实,不同公司的项目特点不同,其适用的模型可能也有所区别,但关键是你想用该模型反映什么,那么模型是否有效反映了结果,还要考虑数据收集的成本。
2.现在按照CMMI等模型的要求,对数据进行收集分析,但是对于一个项目,那些数据的收集分析是重要的,那些事不重要的,好像任何资料上都没有定义,可能会说,根据项目的实际情况来,但是现在的实际情况是,大范围,国人对品质的忽略(可以从品质人员待遇和开发人员的比较而来),小范围是,我们公司从CMMI导入到CMMI4,其实很大一部分是由于文档下的CMMI4,在实际的过程改进中,员工们更多的是将CMMI和项目对立起来(为了写文档而文档)以及IT行业的跳槽,到导致了,员工的品质管理概念很难建立起来,所以我们的项目经理,除了技术外也不清楚需要什么数据?那作为品质管理人员如何去做呢?
这些其实需要公司建立相应的度量规范,同时要建立相应的工具支持,在工具中已经明确了数据的收集范围,每一个度量项的定义。这个是组织级QA要解决的问题,不是项目级QA所能解决的。
关于国内的质量观念问题,说来话长,与商业环境有关,我觉得最重要的一点是国内客户对供应商太宽容。在日本和欧美,低劣产品的供应商是无法生存的,所以在质量管理上下功夫是不得不做的工作。因为用户只给产品提供商一次机会,如果你的产品一旦出了问题,那对不起了,用户会毫不犹豫地将该供应商从名单中划去,不会再给你机会。
坦白地讲,我们国内的很多software engineer只能称得上是programmer,因为他们工程方面的知识极度贫乏。这个原因也是多方面的,与公司短视和对员工的成长不关心有很大关系。

chengxq 发表于 2008-8-4 10:53:35

谢谢LS的,LZ是我的马甲号,关于第二点没什么可说的,至于第一点,我知道你说的也是对的,如果严格按照这样去做,当然是最好的,但实际是--------
不过我还是感谢你,这方面我和项目组多提提建议。
页: [1]
查看完整版本: 对软件项目数据的统计分析