如何度量交付后的软件质量?
发布于 2024-10-04
2812
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
软件系统上线后质量评估摘要
软件上线后,客户体验和产品质量常常根据遇到的缺陷数量来评价。上线后发现的缺陷数量受到产品规模、产品质量、测试有效性和客户使用频次四个因素的影响。
产品好坏可通过一段时间内的缺陷密度来衡量,计算公式为:缺陷密度=发现的缺陷个数/产品的规模。理想情况下,缺陷密度应为零。为了客观度量产品规模,业界普遍采用功能点方法。但如果没有采用功能点,可以用开发工作量或合同价格来作为软件规模的代理。
度量软件交付产品质量时,优先采用以下公式:
- 上线后发现的缺陷个数/交付软件的功能点个数
- 上线后发现的缺陷个数/软件开发工作量
- 上线后发现的缺陷个数/软件合同额
- 上线后发现的缺陷个数/交付的代码行数
考虑两个相同规模的软件A和B的例子,它们的质量评估结果会因不同的指标而有所不同。A和B的长期缺陷密度均为每千功能点5个缺陷,但短期缺陷密度、注入的缺陷密度和缺陷逃逸率不同,这导致客户体验、开发和测试质量的评价结果各异。具体来说,软件B提供了更好的客户体验,而软件A具有更高的测试质量。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 1251.3K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
案例:缺陷状态数据分析
有网友询问如表1所示的原始数据如何分析,发现问题,我觉得很有代表性,试着分析进行了分析,供大家参考。 表1: 11个项目的缺陷状态原始数据 产品名称 未解决 设计如此 重复Bug 外部原因 已解决 ...
如何分析各类时长数据?
本文列举了分析时长数据时的注意事项,并结合实例给出了时长数据的常用分析方法。
快速学习COSMIC方法之二:COSMIC方法的度量过程
COSMIC方法的度量分为三个阶段:1 度量策略阶段2 映射阶段3 度量阶段在度量策略阶段,主要包括四个活动: 1)确定度量目的:为什么执行本次度量。比如你要度量一个房子的面积,是为了卖房子?是要装修?还是为了装中央空调?目的不同,度量的范围不同,度量的结果也不同。卖房子是要包含建筑面积与分摊面积的,装修房子要考虑套内面积与晾台面积,而装中央空调时只考虑套内面积,目的不同,度量的范围不同,度
相关与不相关都是有价值的!
在对数据进行相关性分析时,通常我们是基于自己的经验,认为x与y可能相关,希望通过定量的分析证明我们的经验,但是实际上往往历史的数据并不支持我们的经验。即使不支持,这也是有价值的,也可以帮我们纠正一些错误的认识。请看下面的案例,在一家公司中搜集了37个历史项目的数据,我们想验证一下: 1 是否项目的规模越大,工期延误的时间就越长? 2 是否项目的规模越大,工期偏差率越大?...
三轮自动代码评审,质量持续收敛
本文复盘了一个智能文档评审工具的Bug修复与质量提升过程。项目采用前后端分离架构,在修复Word预览失败等表面Bug时,发现深层架构问题——文档解析应迁移至前端。通过三轮"后置四区评审"(聚焦变更单元的四个维度),团队逐步解决严重问题:首轮发现公共模块缺失、CDN无降级等3个严重缺陷;次轮修复后仍暴露null处理等新问题;第三轮最终收敛到零缺陷。核心启示包括:1)多轮评审才能层层深入;2)修复常会引入次生问题;3)结构化评审方法比工具更重要。
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线