扫码阅读
手机扫码阅读
代码评审的速度与缺陷密度是啥关系?
18 2024-10-02
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
查看原文:代码评审的速度与缺陷密度是啥关系?
文章来源:
麦哲思科技任甲林
扫码关注公众号
一家企业对8个项目的代码评审数据进行分析,虽然样本量有限,但其中仍可见一些规律。这些数据展示了代码评审中发现的缺陷密度和评审速度之间的关系。
根据收集的数据,得到了如下度量信息:
- 评审缺陷密度的范围从3.03个/kLoc到60个/kLoc不等。
- 评审速度的范围从100 loc/小时到3295 loc/小时。
通过对这些数据的散点图进行观察,发现了两个主要的趋势:
- 评审发现的缺陷密度与评审速度之间存在曲线相关性。
- 随着评审速度的增加,评审发现的缺陷数量逐渐减少。
为了深入研究这种关系,对缺陷密度进行了数学变换,即new y = 1/sqrt(评审缺陷密度),这样转换后可以与评审速度建立线性回归方程。通过这种变换,得到了以下回归方程:
new y = 0.1343 + 0.000138 * 评审速度(loc/小时)
最终,通过逆向运算,可以用上述方程来估计评审的缺陷密度,其计算公式为:
评审的缺陷密度 = 1 / (0.1343 + 0.000138 * 评审速度)^2
想要了解更多内容?
查看原文:代码评审的速度与缺陷密度是啥关系?
文章来源:
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
379 篇文章
浏览 58.9K
麦哲思科技任甲林的其他文章
度量体系建立与COSMIC方法应用36问
Q1:度量体系建设的难点有哪些?后来是采取哪些策略解决的?A1:难点:采集哪些数据是有用的?有了数据如何抓结论出来。Q2:故障解决闭环率,类似这种KPI考核指标,有什么好的方法可以高效推进闭环呢?A2: 分析故障解决的时间分布,看看哪个环节耗时最长,是否针对这个环节有改进措施。短期见效的措施最受欢迎。Q3:度量规模给传统公司带来了哪些价值啊?A3:有了规模才可以比较生产率和质量。从软件开发方的角度,通过生产率的度量,判断当前的生产率究竟是高还是低,比较不同项目组,不同部门..
缺陷清除率的简单分析
某项目采集了在一个迭代周期内缺陷的注入与发现数据。把缺陷注入分为了3个活动,把缺陷发现分为了4个活动,一个月内的统计数据见下表:某项目的缺陷清除率分析缺陷注入\缺陷发现Sprint planning设计与编码代码评审测试小计需求分析453 12设计与编码 27128测试 22小计4530342缺陷清除率33.3%62.5%96.8%100.0% 在此统计表中并没有采集到产品发布后的度量数据
迭代策划会议(Sprint Planning) 的实际案例
某项目组第一次采用敏捷方法进行开发,确定了迭代周期为三周。该项目组投入的资源如下:前端开发工程师一名;后端开发工程师一名;测试工程师一名;PO一名;SM一名;前后端开发采用不同的技术,熟悉前端开发的工程师不熟悉后端的技术,后端开发的工程师也不熟悉前端使用的技术。当第1周结束后,由于前端开发人员使用的是新技术,需要熟悉新技术,而后端工程师与测试工程师的投入都不到位,因此估算工作量与实际工作量差别比较...
对需求签字画押,有用吗?
客户: 任老师,咨询您一个问题。我们公司在产品开发过程中有个问题,就是变更。有时候项目内的变更甚至是目标或者大功能模块上的变更。比如项目开始时明确要做5个功能,做到中期变更说某个功能不做了,然后又变更说增加一个新功能。针对这种情况目前提出的解决方案是:在产品设计评审完成后,产研双方签字画押。想通过这种举动能唤醒评审双方对评审的重视程度,从而避免上述情况发生。您认为这是种有效解决问...
Lehman的软件演化定律
自20世纪70年代以来,M. M. Lehman通过对软件系统演化现象的观察,陆续总结了8条定律,称之为定律并非那么严谨,但是对于认识软件维护的规律,改进软件维护的过程具有很好的指导意义。1 (1974年)持续变更定律。系统必须持续调整以适应各种变化,否则这些系统将变得越来越不令人满意。2 (1974年)复杂度增长定律。随着系统的演化,其复杂度会逐渐增加,除非采取措施来降低或保持其复杂度。3 (1974年)自我调整定律。软件演化过程的是自调整的,每次演化版本的度量数据近似正态分布。4 .
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线