浅议质量管理

Floria ·
更新时间:2024-11-14
· 684 次阅读

“质量是企业的生命”、“质量是企业的尊严”等等已成为现代企业界的共识,质量对于从事软件的IT企业更是价值与尊严的起点,因为质量是软件产品的生命。

上世纪的工业时代,来自日本的全面质量管理(TQM)和美国的六西格玛(6σ)为用户带来了精良产品和美的享受。而今在中国的软件企业里面质量管理是一个“剪不断,理还乱”的话题,常常看到在一个软件产品或系统的工作链条上,所有的上下游角色都在忙于救火,平安无事后,又重复着同样的故事。看看现在中国软件企业中一旦出现BUG,则会一些八仙观点:“为质量生,为性能死,为找bug奋斗一辈子,吃工具的亏,上自动化的当,后倒在需求上”,“不,这是设计的问题”,“不,这是代码的问题”,“质量是测试出来的”。这些观点也成全了软件企业中测试部门或质量部门的“伟大的职责和尴尬的地位”!

纵然软件产品有它的不可见性和动态性导致它的“相对不可观测性”,但软件质量管理活动和项目工程活动未紧密结合才是重要的因素。而软件质量管理活动的驱使是企业质量体系制度和企业质量文化,在没有驱使动力下目前很多软件企业的质量管理现状如下:

1、责任链不清:中国是一个讲究责任的国度,但因软件开发的特点往往出现“剪不断,理还乱”的怪像。

2、软件质量保证(审查、复审和测试)没有贯穿到整个软件开发全过程中去。

3、在于这些软件产品对其质量内涵的把握,仅仅停留在减少软件运行错误、加强软件测试,避免软件缺陷的一般性层面,而对整个软件开发生命周期的全过程质量管理。

软件质量管理责任链模型

即使在软件项目管理中质量管理定义了很多,但需求依然不能完全被验证,设计依然不能全面被测试。需求的缺陷、设计的缺陷、代码的缺陷、测试执行的覆盖度不全等等,这些缺陷一旦在系统上线后被放大,那么修复的成本会有多高?看看一般软件项目的质量管理的责任链模型:

图表 1 软件项目质量管理责任链模型

质量缺陷从一开始人为的“被引入”了,并且随着“需求”、“设计”、“编码”的灰度降低则缺陷责任将被降低,缺陷的修复成本则反之。而现状是大部分项目在追赶进度,需求在未被完全验证或确认的情况下,已开展设计,再设计未被全面评审或测试的情况下,开发已跑步前进。设计的时候发现需求逻辑存在问题,开发的时候发现设计不够严谨…..当然并不是需求和设计,设计与开发必须串行,而是在一定粒度和耦合度下必须串行。

根据业界统计,软件产品在上线后发现的质量缺陷修复成本是在设计阶段修复成本的100多倍。而如何有效避免或降低后期产品缺陷呢?有效的手段是评审。

评审

评审是静态测试技术的重要组成部分,是对软件工作产品(包括代码)进行测试的一种方式,它应该在动态测试之前进行。评审通常是通过深入阅读、理解和检查文档来完成的。

评审包括管理评审、审查、技术评审、走查和非正式评审等不同的评审技术,评审的通用过程由以下六个阶段组成。

计划阶段:选择评审员,分配角色;为更加正式的评审类型(例如:审查)规定评审的入口准则和出口准则;选择需要进行评审的文档或文档章节等。 预备会阶段:分发文档,向评审参与者解释评审的目标、过程和文档;核对入口准则(针对更正式的评审类型)。 个人准备阶段:在评审会议之前,每位评审参与者准备各自的评审工作,标注评审对象中可能的缺陷、问题和建议。 评审会议阶段:讨论评审员提交的问题列表,并形成会议纪要(针对更正式的评审类型)。会议参与者可以标识缺陷、提出处理缺陷的建议或对缺陷做出决定。 返工阶段:修复评审过程中发现的缺陷,通常由作者进行。 跟踪结果阶段:检查缺陷是否已解决,收集度量数据,并评估出口准则(针对更正式的评审类型)。 目前业界内对质量管理比较严格的公司对于“ +36030.

个人准备阶段”和“评审会议阶段”打出了重拳,凡是在评审会议开始发现与会评审员超过1/3未进行评审预准备的则勒令终止会议。

评审与动态测试集成和单纯的动态测试相比能够给质量到底带来多大好处,下面引用一组数据说明:

图表 2 动态测试与评审和动态测试集成比对图

以上数据可以说明:1)评审可以发现产品70%~80%的缺陷,而动态测试发现缺陷很难逾越过50%的坎。2)整个过程的缺陷发现率从原来的75%(150/200)提高到了93.5%(187/200)。

评审可以降低测试和开发的成本,因为在项目的早期发现和修复缺陷的成本比在测试执行阶段发现和修复缺陷的成本小得多。同时,有效的评审可以减少动态测试执行的时间。下表是业界统计得到的在不同阶段修复缺陷的成本比例。

图表 3 不同阶段缺陷修复的成本

从上表可以看出,劣质质量成本(COPQ)到底是多少,劣质的质量产品到底在浪费了多少钱,豪取了组织中的多少利润?一般企业的COPQ可以占到运营成本的20%-30%,而这些是在财务科目上没有统计的,更别说分析了,但质量度量分析模型不作为本文重点。

软件产品质量内涵与全面质量管理

以客户为中心的软件产品质量要以用户满意为目标,质量内涵因子贯穿软件需求、设计、开发、交付等环节。下表为质量内涵因子:

图表 4 质量内涵因子

质量内涵因子既贯穿了整个生命周期,那软件质量管理是全过程、全面的质量管理。全面质量管理主要表现有:

1)客户满意:客户既包括终用户,也包括项目组内部工作的上下游的同事。要明确每一阶段的质量检测标准,绝不把不合格的工作件作为下一阶段的工作输入。

2)全员参与:质量不仅仅是测试、质量保证工程师等角色的事情,每个员工都有维护和改进质量的责任,并将合理的建议付诸于改进行动。

3)贯彻始终:在软件产品的每一个阶段都要执行质量内涵因子的全面质量管理,而不是测试阶段。

4)事前预防:防患于未然,必须将缺陷尽早的预防、发现和纠正。

5)持续改进:实施全面质量管理不可能毕其功于一役,必须利用PDCA方法进行持续改进,这也是质量管理的精华所在。

结束语

“空中飞人”乔帮主曾点评中国篮球虽可称霸亚洲,但没有篮球哲学。而现在的软件质量管理更像中国足球。当国际质量控制方法和理论达到高峰时,PhilipB.Crosby(零缺陷之父,世界质量先生)站出来为质量管理号脉说:“只有数量方法,没有质量哲学”。PhilipB.Crosby指出:"我们基本的工作哲学便是:预防为主,坚持‘第一次把事情做对‘的态度(全面质量管理的要素之一),使质量成为一种生活方式。"

质量是一种哲学,是自我不断的反省,是企业不妥协的经营理念或观念,有了观念,信仰才会产生,我们的行动、习惯、人格、命运也随之而改变了。日本经营之神松下幸之助曾说:“要做产品之前,一定要先做人”。人格的底线在哪里,软件的质量底线在哪里?制度、流程、法律、法规可以踩红线,唯独质量是不允许踩红线的,因为生命和尊严是不容被践踏!



质量管理

需要 登录 后方可回复, 如果你还没有账号请 注册新账号