实例:评审速度与缺陷密度之间的相关性
发布于 2024-10-02
1670
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
某公司的项目分为MIS类软件开发和嵌入式软件开发,共搜集了52次需求评审的度量数据,分别记录在表一和表二中。这些数据涵盖了需求评审的速率和在评审过程中发现的缺陷密度两个方面。
通过将MIS类软件开发和嵌入式软件开发项目的数据分别绘制成散点图(图一和图二),可以直观地观察需求评审的缺陷密度与速率之间的关系。
分析这52次评审的数据显示了一个共同趋势:评审速率的提升往往伴随着缺陷密度的降低,即评审越快,发现的Bug越少。这一趋势在两类项目的散点图中均得到了体现。
进一步的分析可以从以下几个方面展开:
- 对两类项目的缺陷密度与评审速率数据进行双曲线拟合,从而获得两者之间的量化关系。
- 建立缺陷密度的过程性能基线,计算其均值以及上下限。
- 根据设定的缺陷密度目标值,确定评审速率的适宜上限。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 1085.4K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
过程改进:宽度优先还是深度优先?
在过程改进时有这样一种现象:在组织内有很多项目,但是只有参与正式评估的项目严格按照CMMI的体系在做,其他项目基本没有按此体系在做。企业在得到2级的评估时是这样,得到3级的评估时还是这样,得到4-5级的评估时仍然如此。体系在组织内根本就没有推广开来,而是限定在小范围内的一部分项目的一段时间内。 过程改进应该是一种企业文化的变革,仅仅限定在一段时间的局部项目项目的改进不可能形成企业的文化变更,这种
我说CMMI2.0 之监督与控制
监督与控制PA,简写为MC(Monitor and Control),是对照计划监督与管理计划的执行情况。实践列表 MC 1.1 Record task completions. 记录任务完成情况 MC 1.2 Identify and resolve i...
我说CMMI2.0之同行评审
同行评审,不是通过测试去发现缺陷,而是通过专家阅读文档、代码发现缺陷,是在实现之前发现缺陷的最有效手段。同行评审这个PA是从VER中剥离出来的,原来1.3版本的VER与VAL合并成了VV PA,让熟悉最早的SW-CMM.1.1的从业者感受到了复古之风。这个PA的实践描述通俗易懂,最好理解。但是,很多公司做了同行评审,效果不好。我之前写过多篇博客讲解同行评审如何做的问题,分别列举到对应的...
结论简单,教训深刻:一个大型项目关于需求工程的反思
某公司承担一个大型软件项目的开发,该项目的计划工期为2年,实际工期为2.5年。该项目为本公司新进入的一个行业,公司在其他行业里有相近软件的开发经验,但是对进入的这个行业并不熟悉。本项目采用了瀑布模型,高峰期70多人参与,最少时也有30多人参与。投入了接近100人年的工作量,而浪费的工作量大概在25人年,需求返工的比例占了40-50%。项目结束后做了复盘,我作为外部咨询顾问参与了项目回顾...
缺陷清除率的简单分析
某项目采集了在一个迭代周期内缺陷的注入与发现数据。把缺陷注入分为了3个活动,把缺陷发现分为了4个活动,一个月内的统计数据见下表:某项目的缺陷清除率分析缺陷注入\缺陷发现Sprint planning设计与编码代码评审测试小计需求分析453 12设计与编码 27128测试 22小计4530342缺陷清除率33.3%62.5%96.8%100.0% 在此统计表中并没有采集到产品发布后的度量数据
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线