如何度量交付后的软件质量?
发布于 2024-10-04
1897
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
软件系统上线后质量评估摘要
软件上线后,客户体验和产品质量常常根据遇到的缺陷数量来评价。上线后发现的缺陷数量受到产品规模、产品质量、测试有效性和客户使用频次四个因素的影响。
产品好坏可通过一段时间内的缺陷密度来衡量,计算公式为:缺陷密度=发现的缺陷个数/产品的规模。理想情况下,缺陷密度应为零。为了客观度量产品规模,业界普遍采用功能点方法。但如果没有采用功能点,可以用开发工作量或合同价格来作为软件规模的代理。
度量软件交付产品质量时,优先采用以下公式:
- 上线后发现的缺陷个数/交付软件的功能点个数
- 上线后发现的缺陷个数/软件开发工作量
- 上线后发现的缺陷个数/软件合同额
- 上线后发现的缺陷个数/交付的代码行数
考虑两个相同规模的软件A和B的例子,它们的质量评估结果会因不同的指标而有所不同。A和B的长期缺陷密度均为每千功能点5个缺陷,但短期缺陷密度、注入的缺陷密度和缺陷逃逸率不同,这导致客户体验、开发和测试质量的评价结果各异。具体来说,软件B提供了更好的客户体验,而软件A具有更高的测试质量。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
440 篇文章
浏览 717.2K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
白话SCRUM 之二:product backlog
在SCRUM方法中明确要求了3个文档: 1 product backlog 2 sprint backlog 3 burn-down chart Product backlog 中列举了本项目应该实现的需求,需求采用了用户故事的方式进行描述,用户故事是一句简短的采用用户熟悉的术语表达的需求,是用户讲给开发人员的故事,不是开发人员讲
决策与解决方案练习结果分析
2008年3月4日对15人进行了DAR过程域的培训,针对一个设计方案选择的场景进行练习。划分为3个小组,每组5人。练习持续45分钟,点评45分钟。第1组练习的结果:评价指标权重方案1方案2方案3开发时间3321系统收益3
案例:客户满意度的综合统计分析
采集了客户满意度的数据后,可以从哪些维度进行统计分析呢?本文给出了一个具体案例,通过七张图分析客户满意度的数据!
图解敏捷性能合弄结构APH之:valuing合弄
图一:valuing合弄的目的与性能等级图二:valuing合弄的活动各种敏捷方法的原则参见博客:https://blog.csdn.net/dylanren/article/details/87184790。 图三:valuing合弄使用的敏捷仪式和技术说明:为便于图形化表达,每种敏捷仪式或技术没有映射到具体的活动,敏捷活动与敏捷仪式是多对多的映射关系。 ...
如何高效的工作
请思考敏捷方法中的3个基本原则:沟通、简单、反馈。这3个原则可以用来指导我们进行高效的工作。1 任务明确,不要做无用功。 何谓任务明确? 任务的输出是什么?在输出中包含哪些内容要明确列举出来。 任务的完成标准是什么? 任务的完成时间是什么时候? 是否有其他的约束条件? 要和任务的布置人员明确上述内容。 比如要你写给某客户写一个方案,则首先要明确:
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线