51Testing软件测试论坛

标题: 对软件项目数据的统计分析 [打印本页]

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

作者: chengxq 时间: 2008-7-28 16:03
同问！？

作者: zhongmg108 时间: 2008-7-30 14:23
首先声明,我不是高手,只是给一些自己的想法,也不一定正确,仅供大家参考.

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

作者: chengxq 时间: 2008-8-4 10:53
谢谢LS的，LZ是我的马甲号，关于第二点没什么可说的，至于第一点，我知道你说的也是对的，如果严格按照这样去做，当然是最好的，但实际是--------
不过我还是感谢你，这方面我和项目组多提提建议。

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