如何度量交付后的软件质量?
发布于 2024-10-04
2284
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
软件系统上线后质量评估摘要
软件上线后,客户体验和产品质量常常根据遇到的缺陷数量来评价。上线后发现的缺陷数量受到产品规模、产品质量、测试有效性和客户使用频次四个因素的影响。
产品好坏可通过一段时间内的缺陷密度来衡量,计算公式为:缺陷密度=发现的缺陷个数/产品的规模。理想情况下,缺陷密度应为零。为了客观度量产品规模,业界普遍采用功能点方法。但如果没有采用功能点,可以用开发工作量或合同价格来作为软件规模的代理。
度量软件交付产品质量时,优先采用以下公式:
- 上线后发现的缺陷个数/交付软件的功能点个数
- 上线后发现的缺陷个数/软件开发工作量
- 上线后发现的缺陷个数/软件合同额
- 上线后发现的缺陷个数/交付的代码行数
考虑两个相同规模的软件A和B的例子,它们的质量评估结果会因不同的指标而有所不同。A和B的长期缺陷密度均为每千功能点5个缺陷,但短期缺陷密度、注入的缺陷密度和缺陷逃逸率不同,这导致客户体验、开发和测试质量的评价结果各异。具体来说,软件B提供了更好的客户体验,而软件A具有更高的测试质量。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 948.2K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
理论与实践的完美结合:《软件项目估算》译者序
这本书需要仔细读。 没有哪一本书能够替代此书在如何建立生产率模型方面的严谨性与实用性,它讲的不是经验法估算工作量,而是模型法估算工作量。 它理论完备、严谨,并给出了工程化的软件工作量估算方法和大量的经验教训。 在给客户咨询的过程中,我帮客户识别、建立了大量的过程性能模型,积累了丰富的经验,但是,当我读到Alain的这本书时,我深...
先改进代码的质量
一个软件项目最重要的、必不可少的交付物是什么?程序! 如果程序不能正常执行,文档写的再多、再漂亮也无法帮助客户得到其预期的价值。 程序是程序员写出来的,要提高程序的质量,首先要提高程序员的编程水平。一个职业的程序员应该: (1) 熟悉编程工具; (2) 能够按照编码规范编写风格规范、通俗易读、形式正确的程序; (3) 能够编写逻辑正确、思路清晰、内容正确的程序;(4) 具备测试、评审代码
我说CMMI2.0之组织级培训(OT)
人、技术、过程三者并重。技术靠人来使用,过程靠人来执行,人是地基,是基础。同样的技术、同样的过程由不同人去落地,效果差别很大,因此要重视对人的能力的培养。 实践列表 OT 1.1 Train people. 培训人员 OT 2.1 Identify ...
规模估算的敏捷方法:策划扑克法
策划扑克是估算软件规模的一种敏捷方法。该方法的规模计量单位是故事点(story points),故事点只是一个计量单位的名称而已,你也可以给他命名为其他名字。故事点其实不仅仅是对规模的度量,也包括了对需求复杂度等其他因素的度量。故事点并非业界统一的一个度量单位,不象度量长度的单位:米,大家都知道1米有多长,你说的1米和他说的1米是等长的。故事点仅对本项目具有近似相等的规模,不同的项目所定义的故事点
在CMMI推广过程中EPG常犯的错误
1对模型研究不够深入模型是多年软件工程经验的总结,里面的每一句话,每个例子都不是随便写上去的,都有其内在的含义在里面,需要仔细琢磨, 仔细体会。作为EPG的成员,在遇到问题时,首先要做的事情是要去读模型,在模型中查找答案。市面上所有翻译的中文资料都不准确,所以要去读模型原文,以 免以讹传讹。在读不懂的地方应该去读SW-CMM与SE-CMM,从那里获取类似的描述,如果还读不懂,可以去网络上搜索资料,
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线