扫码阅读
手机扫码阅读
各阶段缺陷检出密度的统计分析案例

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


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

某企业通过收集10个项目的历史度量数据,分析了5个阶段的缺陷密度,包括需求评审、设计评审、代码评审、测试发现以及交付后3个月内的缺陷密度,并且以缺陷数/KLOC为单位进行统一计量。
通过箱线图分析,观察到第10个项目在代码评审、系统测试、交付后的缺陷密度中均为离群点,该项目由公司精英团队开发,前期缺陷多但交付后缺陷少,表明该项目的交付质量高,应吸取其成功经验。然而,由于其特殊性,该项目数据不具有普遍代表性,故从分析中剔除。
分析显示,代码评审阶段发现的缺陷最多,且离散程度大,表明该阶段的稳定性较差,需要优先改进。箱线图中的下半部分离散度大,暗示应从这些项目中识别问题并进行改善。而交付后缺陷的数量最少,分布也相对稳定。
对剩余9个项目的累计缺陷密度进行Gompertz拟合表明,随阶段的推进,平均累计缺陷密度逐渐增加,从需求评审的0.456至交付后的4.117。
对各阶段缺陷检出密度与交付缺陷密度进行相关性分析发现,二者间存在弱相关性。但是由于样本数据较少,分析的可靠性不高,需要积累更多数据后进行进一步的相关性分析。
想要了解更多内容?


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

麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 235.8K
麦哲思科技任甲林的其他文章
需求控制组的构成
在软件项目中常见如下的现象: 用户提出了需求变更,市场人员答应了,开发人员认为工作量太大,不好实现; 软件项目签订了合同,规定了价格,在后期的开发过程中,需求变更很多,变更的成本都是乙方承担,项目结束后发现项目做亏了; 用户提出了需求的变更,开发人员直接修改软件,没有通知相关人员; 用户张三提出了需求变更,开发人员修改了软件后,张三又认为不妥
我说CMMI2.0 之过程资产开发(PAD)
PAD, process assesses development 过程资产开发,也可以翻译为过程财富开发。过程资产指什么?与过程有关的组织级方针、过程描述、裁剪指南、检查单、模版、规程定义、培训材料以及项目组裁剪后的过程定义、经验教训、典型案例、计划等资料都是过程资产。要注意:组织级的过程资产库中包含了组织的过程定义。过程定义在哪里要求的?在II的SP2.2和PAD3.3! 实践列表...
项目计划评审时的36个检查点
在多次的运行检查中,发现很多项目的计划存在一些共性问题,根据这些问题,归纳出来36个检查点供大家参考. 1 是否定义了项目的组织结构? 2 是否定义了每种角色的职责? 3 PPQA是否有独立的渠道和高层沟通? 4 如果有客户或客户代表的参与,是否定义了他们的职责? 5 是否定义沟通了机制?(和客户的,和其他外部和伙伴的,内部成员的,和上级的,和其他项目组的) 6 是否定义了
为什么忽略管理的常识?
最近连续审查了几个客户的过程文档体系,有个问题,让我一直苦思:为什么我们总是忽略管理常识? 企业在实施CMMI的时候,为了满足模型的要求,在描述自己的过程时,习惯于照搬模型的描述。最典型的例子是PMC的描述,模型中描述了10个实践: SP1.1 监督项目的计划参数 SP1.2 监督承诺 SP1.3 监督风险 SP1.4 监督数据管理 SP1.5 监督项目相关人员的参与 SP1.6 执行进展评审 S
度量数据分析的3个层次
很多企业在实施CMMI 的MA过程域时,积累了大量的数据,但是不知道如何分析,没有充分发挥出这些数据的作用,花费了大量的人力收集来的数据没有给决策提供应有的帮助,很是可惜。究其根源,是不了解数据分析的方法。在咨询过程中,我总结了进行数据分析的3个层次: 1 简单观察分析 通过对数据进行整理(如排序、分类等),绘制成各种图形,通过这些图形观察出直观的结论,可以绘制的图形如:饼图、条形图、直方图、折线
加入社区微信群
与行业大咖零距离交流学习


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