扫码阅读
手机扫码阅读
各阶段缺陷检出密度的统计分析案例
246 2024-10-01
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
查看原文:各阶段缺陷检出密度的统计分析案例
文章来源:
麦哲思科技任甲林
扫码关注公众号
某企业通过收集10个项目的历史度量数据,分析了5个阶段的缺陷密度,包括需求评审、设计评审、代码评审、测试发现以及交付后3个月内的缺陷密度,并且以缺陷数/KLOC为单位进行统一计量。
通过箱线图分析,观察到第10个项目在代码评审、系统测试、交付后的缺陷密度中均为离群点,该项目由公司精英团队开发,前期缺陷多但交付后缺陷少,表明该项目的交付质量高,应吸取其成功经验。然而,由于其特殊性,该项目数据不具有普遍代表性,故从分析中剔除。
分析显示,代码评审阶段发现的缺陷最多,且离散程度大,表明该阶段的稳定性较差,需要优先改进。箱线图中的下半部分离散度大,暗示应从这些项目中识别问题并进行改善。而交付后缺陷的数量最少,分布也相对稳定。
对剩余9个项目的累计缺陷密度进行Gompertz拟合表明,随阶段的推进,平均累计缺陷密度逐渐增加,从需求评审的0.456至交付后的4.117。
对各阶段缺陷检出密度与交付缺陷密度进行相关性分析发现,二者间存在弱相关性。但是由于样本数据较少,分析的可靠性不高,需要积累更多数据后进行进一步的相关性分析。
想要了解更多内容?
查看原文:各阶段缺陷检出密度的统计分析案例
文章来源:
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 105K
麦哲思科技任甲林的其他文章
不可重现的BUG的应对策略
问题场景:有一些比较严重的BUG随机发生,难以查找规律的,测试工程师提交上去后,有可能会出现以下三个情形:1.开发人员试图重现,重现不出,Reject回来;2.开发人员找不到规律,所以不去解决,问题一直处于Open状态;3.开发人员因为问题难以解决,所以直接Resolved回来,觉得反正是偶发的,先改成解决状态再说。对开发人员、项目经理和测试工程师来说,正确的处理方法应该是怎样的?解决方案:1 缺
全功能点估算方法简介
说明:本文已刊登于《信息技术与标准化》07年第3期新一代的功能点规模估算方法: COSMIC-FFP1 引言软件规模估算是估计软件开发的工作量、成本与资源需求的基础,通过规模与其他度量数据还可以度量项目的生产率、缺陷密度,目前在工程界流行的估算方法是代码行估算方法和功能点分析方法(function points analysis,FPA法)。代码行估算方法是一种经验估算方法,通常会采用
实施敏捷的四个致命障碍
敏捷方法在中国推行的如火如荼,我也为多家公司做了敏捷的导入咨询,在实践中遇到了几个致命障碍,限制甚至阻止了敏捷方法的推行,我把有深刻体会的障碍总结出来,供大家在实践中规避之。障碍一:没有建立组织级的敏捷价值观与环境。 很多公司在导入敏捷时,先从一个项目开始尝试敏捷方法,试图在单项目内成功了,再推广到其他项目。这种初衷是好的,但是往往事与愿违,为什么呢?因为缺乏组...
软件项目用人十二策
1 高天赋原则:选择高水平的人员,赋予高水平的待遇,宁缺勿滥。 2 自我发展原则:选择有悟性的能自己不断进步的人参与到团队中来。 3 工作匹配原则:培养专长,稳定专业方向,在某个专业方向使其成为专家,分工时也按其专长进行分工。 4 职业发展原则:一专多能,定期转换方向,当在某个专业方向上成为专家后,要适时变换方向,使其更加全面。如果总是在一个方向上发展,可能导致该人无法寻找
数据、现象与原因
某公司积累了最近2年24个项目缺陷发生率的历史数据(缺陷发生率为系统测试发现的缺陷个数除以开发的工作量),如下表所示: 对上述的历史数据,按年份画箱线图比较分析如下: 针对上述的箱线图,是否可以下结论认为2013年开发质量提升了,开发人员犯的错误就少了呢? 其实未必。 如果对年份与项目的开发方式做卡方分析,则有如下的结论:汇总统
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线