扫码阅读
手机扫码阅读
代码评审的速度与缺陷密度是啥关系?

我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。


麦哲思科技任甲林
扫码关注公众号

一家企业对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 成员,中国分部主席
425 篇文章
浏览 236K
麦哲思科技任甲林的其他文章
例说需求跟踪矩阵的作用
9月21日,我作为外部的专家参加了一个客户的测试用例评审会议,该测试用例文档在开此评审会议之前曾经在测试组进行了内部评审。与会的评审专家包括了:2个项目的需求与开发人员,3个测试人员,2名QA人员,1名外部的咨询顾问。 会议开始,由作者对照测试用例文档开始讲解每个测
快速学习COSMIC方法之八:如何识别功能处理
在上一讲中我们讨论了对功能处理概念的理解,那是我们识别功能处理的基础。本节我们将继续讲解如何识别功能处理。在度量手册中,对识别功能处理给出了如下的规则:a) 一个功能处理应该完全属于某层且仅属于某一层的一个软件块的度量范围。b) 一个功能处理至少包含两个数据移动,一个输入加上一个输出或写。一个功能处理中数据移动的数量没有上限。c) 一个执行中的功能处理,当其响应了触发输入并满足FUR时
多团队协同开发的18条实践
本文总结了18条多团队协同开发的实践。
案例:非功能性需求的设计
很多项目组在设计文档中仅仅是把非功能性需求的描述拷贝到设计文档的非功能性章节。因此特地设计了两个简单的需求给大家参考,希望能够引导设计人员重视非功能性需求的设计。
白话SCRUM 之四:燃尽图
Burn down chart翻译为燃尽图或燃烧图,很形象,是Scrum中展示项目进展的一个指示器。我一直认为用户故事、每日站立会议、燃尽图、sprint review、sprint retrospective真是越琢磨越有味道的好东西,也因此很喜欢scrum这种方法,这些实践简单有效、经典! 燃尽图的样例如下: 横坐标为工作日期,纵坐标估计剩余的工作量,每个点代表了在那一天估计剩
加入社区微信群
与行业大咖零距离交流学习


PMO实践白皮书
白皮书上线
白皮书上线