需求变更对软件质量的影响
发布于 2024-10-02
1878
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
摘要
通过对某企业38个项目的历史数据分析,本文旨在验证需求变更数与软件缺陷数之间的关系。数据包括需求变更次数、代码规模、软件测试发现的总缺陷数、测试缺陷密度以及需求变更密度。
分析结果
首先,通过散点图分析总缺陷数与需求变更数的关系,发现二者之间存在正相关。删除显著的离群点后,重新绘制的散点图和拟合线图进一步确认了需求变更数的增加与总缺陷数增加之间的强相关性。
其次,研究单位代码行的需求变更次数与单位代码行的缺陷个数之间的关系。在排除离群点后,发现每百万行代码的需求变更次数与每千行代码测试发现的缺陷数之间存在弱相关。
结论
综合以上分析,可以得出结论:在该企业的历史项目数据中,需求变更的增加与系统中的缺陷增加之间存在一定的相关性。这一发现支持了初步的经验假设,即需求变更越多,软件缺陷也越多。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 1077.7K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
TSP中的10个量化法则
TSP(Team software process)是Humphery提倡的解决CMM如何做的一个模型,他认为采用了TSP之后,可以加快企业达到CMMI5级的速度,可以提高企业的质量。在TSP中Humphery提出多项度量数据,我从中整理了如下的10个量化法则和大家分享,其中前5个法则是关于工作量的分布,后5个法则是关于质量的。其实这些法则中具体数值的大小完全可以商榷,但是最关键的是蕴含在这些数值
三个团队的站立会议旁观笔记
今天早晨我旁观了3个团队的站立会议,三个团队的站会参与人员都是7个人,其中第2个团队是scrum of scrum,7个人是7个团队的代表,有高层领导旁观了第2个团队的站会。 做得好的地方归纳如下: 1在每日站会上沟通了需求、接口设计的变化,让整个团队都了解这些变化。 2开发人员在提到完成了,都强调完成...
无处不在的“接口病”
文章浏览阅读401次,点赞4次,收藏8次。本文揭示了系统间连接失效的普遍现象。文章系统分析了从人际沟通到技术系统的各类接口问题,如知识诅咒、部门推诿、系统不兼容等,指出其根源在于高耦合度与低内聚性。提出六大解决方案:简化接口、封装设计、标准化、容错机制、监控透明化和设立接口人,强调通过设计优化连接方式而非强化单方能力来解决问题。典型案例展示了如何通过中介平台简化租房流程,证明良好接口设计能显著提升协作效率。文章最终呼吁在各领域设计中重视接口优化,以预防协作失效。
如何选择与使用项目经理?
作者任甲林(转载自中国系统分析师/中国系统分析员) 软件项目管理是"以过程为核心、以度量为基础、以人为本"的,在此过程中需要充分地集成技术方法、工具、过程、资源(人力、资金、时间等)等要素,谁来领导这个集成工作呢?是项目经理。项目经理是项目组的灵魂,是项目组中很重要的一个角色,无论是对于个人英雄的时代,还是基于过程的管理时代,都必须依靠人来实现管理,这就是"以人为本"。无论管理多么正规,过程是
相关与不相关都是有价值的!
在对数据进行相关性分析时,通常我们是基于自己的经验,认为x与y可能相关,希望通过定量的分析证明我们的经验,但是实际上往往历史的数据并不支持我们的经验。即使不支持,这也是有价值的,也可以帮我们纠正一些错误的认识。请看下面的案例,在一家公司中搜集了37个历史项目的数据,我们想验证一下: 1 是否项目的规模越大,工期延误的时间就越长? 2 是否项目的规模越大,工期偏差率越大?...
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线