缺陷预防之RCA实践小记

RCA背景、概念、开展目的 IOWA 州立大学 质量管理 学 院认为:很多公司在设备发生故障后,都能够很快修复,但往往很难发现哪些是引起这些故障的根本原因,这样会导致故障会再次发生。这里所说的根本原因,是指 导致设备失效的基本原因,如果该原因得到纠正,将会避免该事故重发。根本原因分析技术是一个发现和消除根本原因的过程,能够有效防止这些问题的发生,只有 当这个根本原因被发现和消除后,这个问题才能够被彻底解决。

  而美国能源部1992年发布的《根本原因分析指南》(DOE-NE- STD-1004-92)中,把根本原因定义为:指一种原因,当这种原因被纠正以后,将会防止此类事故或者类似事故的再次发生。根本原因并不是一种仅仅导 致这次事故发生的原因,在更大的范围内,极有可能对发生的其他事故还存在着影响。根本原因最基本的特征应该是:从逻辑上能够被识别并能够被纠正。可能会有 一系列的原因都能够被识别,从一个导致另一个,但是这一系列的原因应该能够被追溯到最基本的,并且能够被识别和纠正的原因。

  在我国大亚 湾核电站的建设和运行过程中,由美国PII(performance improved international)公司提供了RCA方法,该公司把RCA定义为:通过一整套系统化、逻辑化客观化和规范化的分析方法,找出设备故障的故障机理 和根本原因,并通过制定合理的纠正行动彻底消除这些根本原因,从而恢复设备功能,防止同样或者类似故障重复发生的一种解决设备故障问题的分析技术。

  同样,RCA分析也早已在航空航天、医疗领域、应急处理等行业中广泛使用。

   根本原因分析(Root Cause Analysis 后简称RCA),本原因分析(RCA)是一项结构化的问题处理法,用以逐步找出问题的根本原因并加以解决,而不是仅仅关注问题的表象。根本原因分析是一个 系统化的问题处理过程,包括确定和分析问题原因,找出问题解决办法,并制定问题预防措施。在组织管理领域内,根本原因分析能够帮助相关者发现组织问题的症 结,并找出根本性的解决方案。

  笔者建议在软件测试相对成熟或流程清晰的质量团队或公司,可以有意识的开展RCA工作项RCA方法在软件产品质量管理中应用的目的在于:

  a、从缺陷与问题中进行学习

  b、系统化的确定需要改进的区域或过程;

  c、防止重复犯错

  拒绝空谈,为了让好的方法,更加具有执行力。笔者将阅读了国内、台湾、医疗行业的相关资料,整理如下,其中罗列准入与验收标准,方便大家可量化的执行。

  RCA验收目标

  1、RCA活动是有计划的,控制分析成本;

  2、RCA应包含缺陷分类分析与过程管理问题整理;

  3、RCA应包含对缺陷与问题的根本问题的分析与推理,结合不同角色收集得出;

  4、RCA的结果是一个或多个纠正操作建议(在开发过程中进行一些更改与优化,以消除产生错误的原因)

  5、应保持RCA结果的准确记录与跟踪;

  RCA进出标准与有效输入/出

  进入标准(缺陷分类分析与过程管理问题整理)

  1、缺陷分类分析进入;

  a、单次测试的缺陷计数,如  缺陷数≥X个需进行RCA分析;

  b、遗留缺陷计数;如  遗留缺陷数≥X个需进行RCA分析;

  c、按缺陷分类(缺陷严重等级、缺陷类型、) ;如  遗留性能缺陷数、遗留界面缺陷等需进行RCA分析;

  2、或事件触发;

  a、违背当前周期的质量目标的;

  b、重要“事件”或哨兵“事件”(如现场反馈严重缺陷、重复出现的缺陷等,又称单一缺陷或整整一类缺陷);

  c、过程管理发现问题(如提交质量低、迭代次数超计划、需求理解不一致、需求确认问题多)

  有效输入

  1、事件报告

  2、事件相关数据

  3、测量结论(以往RCA分析所确定的措施的实施情况);

  有效输出

  根本原因分析(Root Cause Analysis)应用XXX事件分析报告

  退出标准

  完成RCA应用XXX事件分析报告并经QA Manager确认;

  导致类似事件的同类原因未再次产生;

  笔者结合自身实践,整理出,可执行的RCA分析流程。简言之,算是个“最佳实践”分享给大家。

  RCA活动实施流程

  RCA活动角色划分(示例)








====================================分割线================================



最新内容请见作者的GitHub页:http://qaseven.github.io/

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
软件质量管理实践 ——软件缺陷预防、清除、管理实用方法 目录 前言 1 致谢 3 序 3 宣传语 4 目录 4 第4章 同行评审 5 4.1 同行评审与测试的关系 6 4.2 同行评审的种类和对象 7 4.2.1 同行评审的种类 7 4.2.2 同行评审的对象 8 4.3 同行评审过程 8 4.3.1 正式评审流程 9 4.3.2 技术审查流程 9 4.3.3 走查流程 10 4.4 同行评审方式的选择 10 4.4.1 三种同行评审方式的比较 10 4.4.2 同行评审的结果 11 4.4.3 正式评审的特征 11 4.4.4 工作产品的同行评审方式 11 4.5 迭代生命周期的审查 12 4.6 同行评审的注意事项 13 4.6.1 同行评审遵循的原则 13 4.6.2 同行评审关注的问题 14 4.6.3 同行评审通过的准则 14 4.6.4 同行评审的经验共享 14 4.6.5 文档审查重点 15 4.7 同行评审的度量 15 4.7.1 常用度量元 16 4.7.2 同行评审的质量准则 16 4.7.3 建议的同行评审效率 16 4.7.4 同行评审覆盖率 17 4.8 评审常见问题 17 4.8.1 文化问题 18 4.8.2 准备问题 18 4.8.3 焦点问题 19 4.8.4 人员问题 19 4.8.5 效率问题 20 4.8.6 效果问题 20 4.9 小结 20 第7章 软件度量 21 7.1 软件度量及其方针 22 7.2 度量活动 23 7.2.1 度量目标 23 7.2.2 度量元 25 7.2.3 度量模型 26 7.2.5 度量方法与采集(1) 28 7.2.5 度量方法与采集(2) 31 7.3 资源模型 32 7.3.1 资源模型的定义 32 7.3.2 项目级资源模型 34 7.3.3 组织级资源模型 35 7.3.4 软件质量度量 36 7.4 数据质量 37 7.4.1 数据的真实性 37 7.4.2 数据的同步性 37 7.4.3 数据的有效性 37 7.4.4 数据的一致性 37 7.5 软件度量相关问题 38 7.5.1 增加度量正确性的措施 38 7.5.2 软件过程性能 38 7.5.3 度量过程的常见问题 39 7.6 缺陷度量 40 7.6.1 什么是缺陷度量 40 7.6.2 缺陷度量元 41 7.6.3 缺陷密度的定义 41 7.6.4 缺陷密度的用途 42 7.6.5 缺陷管理库 42 7.7节"缺陷分析"。 43 7.7.1 缺陷种类分析 43 7.7.2 缺陷根源分析 44 7.7.3 缺陷注入-发现矩阵 45 7.7.4 收敛趋势分析 45 7.7.5 回归分析 48 7.7.6 缺陷排除分析 49 7.7.7 ODC缺陷分析 51 7.8 小结 51

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值