软件开发的质量红线
发布于 2024-10-02
1919
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
质量红线是一种确保项目质量不低于某个最低标准的概念,代表了项目管理中的底线要求。无论项目如何在速度、成本、质量和效率(多快好省)之间权衡,都不能跨越设定的质量红线。这个概念强调了质量管理的重要性,确保短期内的权衡不会损害长期利益。
在建立质量红线时,应考虑质量的投入与产出两个方面。质量投入包括评审和测试的工作量及其所占的百分比,以及测试用例的密度等。质量产出方面则涉及评审和测试中发现的缺陷密度,以及缺陷逃逸率等指标。这些指标可以是定量的值,也可以是非定量的,但非定量的质量红线应便于监测。
质量红线体现了公司对质量的最低承诺,并且随着时间的发展,客户要求的提高和公司管理水平的提升,这些质量红线可以逐步提高,以反映企业对长期质量的持续关注和改进。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 1254.3K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
软件项目管理的成功原则
来源:希赛网 作者: 任甲林 1 平衡原则 在我们讨论软件项目为什么会失败时可以列出了很多的原因,答案有很多,如管理问题、技术问题、人员问题等等,但是有一个根本的思想问题是最容易忽视的,也是软件系统的用户、软件开发商、销售代理商最不想正视的,那就是:需求、资源、工期、质量四个要素之间的平衡关系问题。 需求定义了"做什么",定义了系统的范围与规模,资源决定了项目的投入(人、财、物),工期定义
三轮自动代码评审,质量持续收敛
本文复盘了一个智能文档评审工具的Bug修复与质量提升过程。项目采用前后端分离架构,在修复Word预览失败等表面Bug时,发现深层架构问题——文档解析应迁移至前端。通过三轮"后置四区评审"(聚焦变更单元的四个维度),团队逐步解决严重问题:首轮发现公共模块缺失、CDN无降级等3个严重缺陷;次轮修复后仍暴露null处理等新问题;第三轮最终收敛到零缺陷。核心启示包括:1)多轮评审才能层层深入;2)修复常会引入次生问题;3)结构化评审方法比工具更重要。
快速学习COSMIC方法之四:早期快速估算功能规模的方法
在介绍详细的COSMIC方法之前,我们先介绍一下在项目早期,在需求没有详细到可测试的程度时,如何估算软件的规模。实际上很多公司为了减少度量的工作量,往往采用近似的估算方法进行确定项目的预算。 进行快速估算的原理为:通过分析历史的粗颗粒度需求与实际规模之间的相关关系,找到二者之间的换算关系,然后对于新的粗颗粒度需求参考历史的换算关系快速地得到近似规模。这里的粗颗粒度需求的规模可以是功能处理个数
经验管理与量化管理
经验管理是依赖于管理者的经验判断,选择、实施各种措施以达成管理目标的管理方式。管理者的经验有丰富与匮乏的区别,经验也有其适用的范围,有时正确,有时又可能错误。正如我们去看中医大夫,有的大夫经验丰富,很容易就能对症下药,对症后见效很快,但是有时也看不准,如果不对症,则吃了3天后可以进行调整,如果调整仍然不到位,说明经验失效了,这个病不是这个大夫所能应对的。有的大夫经验不够,难以对症下药,下药后见效慢或者无效。中医看病也有其一套推理的规则,这套规则可以称为经验法则、启发式规则或统计推断,从A推理出
流程管理的基本理念
澄清一下关于流程的基本概念与理念。
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线