产品质量管理改进方案Louis Lou 目录2一、质量管理的基本理念2二、产品开发的基本质量策略3三、质量管理的基础33.1 ISO 9126质量模型43.2 缺陷划分53.3 缺陷修复优先顺序和时间要求5四、产品的质量目标54.1 功能准确性64.2 性能的时间特性64.3 兼容性64.4 易更改性6五、质量管理的职责划分75.1 决策层75.2 控制层75.3 执行层8六、产品开发各阶段的质量管理86.1 需求阶段96.2 设计阶段106.3 编码阶段116.4 集成阶段126.5 系统测试阶段12七、小结质量管理的基本理念质量基本理念:质量是一种战略,是一种从小Q产品质量向大Q经营质量转化的战略。
质量是一种文化,是一种全员参与的文化;质量是一种意识,是一种预防胜于检查的意识;质量是一种境界,是一种追求零缺陷的持续改进的境界。
质量目标应该来源于商业目标驱动,商业目标决定了软件的价值。
提高软件质量的目标仍然是为了盈利和创造更大的效益,而不是创造完美无缺的产品。
商业目标决定了质量目标,而不该把质量目标凌驾于商业目标之上。
如果某些质量属性并不能产生显著的经济效益,我们可以忽略它们,把精力用在对经济效益贡献最大的质量要素上。
质量成本分为四个部分:a.预防成本(培训,学习);b.鉴定成本(检查,评审);c.内部损失(如:包括返工,报废和保修成本);d.外部损失。
其中前两类是好质量成本,后两类是坏质量成本。
我们质量成本的目标:消灭坏质量成本和全力提高各种质量预防措施和质量控制的效率。
管理者或质量部门的工作重点不是制定出多少检查规则,而是如何让大家潜移默化的形成一种质量意识的问题。
当大家都形成了某种质量意识后,最终形成组织的质量文化。
在企业唯有文化生生不息,大道而无为,形成零缺陷的企业文化是质量管理的最高境界。
产品开发的基本质量策略KANO模型定义了三个层次的顾客需求:基本型需求、期望型需求和兴奋型需求。
基本型需求是顾客认为产品“必须有”的属性或功能。
当其特性不充足(不满足顾客需求)时,顾客很不满意;当其特性充足(满足顾客需求)时,无所谓满意不满意,顾客充其量是满意。
期望型需求要求提供的产品或服务比较优秀,但并不是“必须”的。
产品属性或服务行为的有些期望型需求连顾客都不太清楚,但是却是他们希望得到的。
在市场调查中,顾客谈论的通常是期望型需求,期望型需求在产品中实现的越多,顾客就越满意;当没有满意这些需求时,顾客就不满意。
兴奋型需求要求提供给顾客一些完全出乎意料的产品属性或服务行为,使顾客产生惊喜。
当其特性不充足时,并且是无关紧要的特性,则顾客无所谓,当产品提供了这类需求中的服务时,顾客就会对产品非常满意,从而提高顾客的忠诚度。
对于质量需求,我们一定要满足基本需求,尽可能满足期望型需求。
根据产品的市场策略,针对性的达到一部份兴奋型需求。
产品质量不是靠测试和评审出来的,而是靠设计出来的。
系统需求的质量决定了设计的质量。
设计的质量决定了开发的质量。
我们在开始做产品规划的时候,就应该基于产品的市场定位明确提出产品的基本质量要求,并确保在后续的工序中充分考虑并满足该需求。
在定义产品的质量要求时可以参考下述质量模型(ISO 9126质量模型)。
质量管理的基础在质量管理中,我们需要有一个明确的质量目标。
在定义产品的质量目标时,可以参考ISO 9216质量模型。
另外,我们需要规范化缺陷的重要性和严重性分类,以此作为质量度量和分析的基础并为后续的缺陷处理提供参考。
ISO 9126质量模型功能性软件所实现的功能达到它的设计规范和满足用户需要适合性准确性互操作性依从性安全性可维护性软件在运行维护过程中,如果出现了运行故障或者扩展新功能和性能,软件系统要具有可分析性和良好的扩展性,重新设计后的软件需要具有稳定和可测试性易分析性易更改性稳定性易测试性可靠性在满足一定条件的应用环境中,软件能够正常维持其工作能力,在出现一些错误操作时,软件可以具有容错性,如果软件意外退出,重新启动系统后可以恢复最近的软件数据。
成熟性容错性易恢复性可移植性为使一个软件从现有运行平台向另一个运行平台过度的适应程度和平台可替换性,旧系统升级和改造,需要跨不同的操作系统。
兼容性易安装性一致性易替换性易使用性为用户提供方便,用户在理解、学习和操作软件的过程中付出努力的程度要最低。
易理解性易学习性易操作性性能在规定条件下,实现软件功能所需的响应时间和计算机资源(CPU、内存、磁盘空间和数据吞吐量)的使用程度达到最优化。
也叫做软件的“效率”。
时间特性资源特性缺陷划分按优先级(或重要性)的划分:P1:阻挡性或灾难性的、必须修复的缺陷(Must Fix);P2:应该修改的缺陷(Should Fix);P3:有时间就修改的缺陷(Fix if we have time);按严重性的划分:S1:崩溃、信息损失、丢失主要功能;S2:非关键的功能障碍,系统不稳定,非关键程序逻辑的执行被阻碍;S3:各种影响到用户使用产品的小问题,使用不便,轻微的使用界面的精致性的问题;缺陷修复优先顺序和时间要求S1/P1 最严重最重要第一修复(3小时内)S2/P1 较严重最重要第二修复(1天内)S3/P1 不严重最重要第四修复(2天内)S1/P2 最严重较重要第三修复(1-2天内)S2/P2 较严重较重要第五修复(2-3天内)S3/P2 不严重较重要第七修复(1-2周内)S1/P3 最严重不重要第六修复(3-5天内)S2/P3 较严重不重要第八修复(2-4周内)S3/P3 不严重不重要第九修复(4周以后)在上表中,将缺陷的严重性、重要性和修复时间要求统一了起来,我们应该重点关注红色区域,兼顾黄色区域。
这对我们的缺陷修复工作具有指导意义。
产品的质量目标以质量模型为指导,根据具体产品在该产品平台战略中的定位,设定产品在各个质量要素和质量特性上的具体指标。
对于现阶段的CIPAce产品,我们要关注的质量特性主要有功能准确性、安全性,易更改性和稳定性,容错性,兼容性和易安装性,易操作性和性能的时间特性,其中尤以功能准确性、性能的时间性、兼容性和易更改性为重。
在产品研发的各个阶段的里程碑审核时,都要确保已经达到产品的整体质量要求。
在产品发布时,一定要达到预定的产品质量指标,具体指标如下。
功能准确性在产品发布前的两周严格测试中没有发现S3/P1(第四修复)以上缺陷,不存在未关闭的S3/P1(第四修复)以上缺陷。
发布前的两周内发现的S1/P3(第六修复)以上缺陷率不超过0.2%(2个S1/P3(第六修复)以上每千行代码),不存在未关闭的S1/P3(第六修复)以上缺陷。
未关闭的其他缺陷率不超过0.8%。
提示:该定义的前提是已经有了比较完善的功能准确性的测试用例。
性能的时间特性在产品预定的环境中(如1,000 Mbps局域网,Web服务器:Intel Xeon E5405 2.0G CPU,8G Memory;DB服务器:Intel Xeon E5405 2.0G CPU,4G Memory),20个并发用户页面相应时间<1秒,100个并发用户页面相应时间<3秒。
(该特性还需要根据具体情况再调整)兼容性客户端支持操作系统:Window 2000/XP/Vista 浏览器:Microsoft IE 6.0 (SP1)/IE7.0/IE8.0, Mozilla Firefox 3.0 Web服务器操作系统:Windows 2003+SP1/2008 (待完善) 易更改性客户发现缺陷修复的容易程度(Hot fix)以及我们对系统更新的容易程度(定时更新)。
(待完善) 质量管理的职责划分谁对软件质量负责?全员负责。
任何与软件开发、管理工作相关的人员都对质量产生影响,都要对质量负责。
谁对软件质量负最大的责任?谁的权利越大,他所负的质量责任就越大。
全员质量意识和质量态度是质量管理的重中之重。
培养质量态度的最简单方式就是为自己的质量事故买单,而且是加倍的买单。
驾驶飞机的驾驶员每次执行飞行任务都会异常认真负责,因为出现事故自己也会有生命危险,没有补救措施,所以必然会100%的认真对待。
向我们这次的CIP Internal项目的推行也是一种方式。
人无完人,每个人都有思维盲区或考虑不周的地方,但后续的检查或测试是为前面工作的思维盲区服务的,而不是为不负责任的态度服务的。
我们必须形成所有人员都要为自己质量负责的工作态度和企业文化。
对于公司决策层、控制层和执行层,明确各层的质量管理权力和职责。
决策层对于决策层来说,要引导树立全员参与、预防胜于检查和追求零缺陷的企业文化,关注企业战略目标的实现,负责企业质量管理中重大事情的决策,审核批准产品质量目标,提供质量管理的资源,提供质量管理和质量控制技能的培训,推行企业的质量体系,推行企业的质量管理知识积累(知识管理)。
控制层控制层负责搭建质量管理平台,贯彻落实公司的质量理念,实现公司设定的产品质量目标,制定质量管理方法,开发质量管理工具,制定质量计划,监督质量控制工作的执行,对发现的质量问题进行统计分析并制定相应的解决方案。
负责企业的质量管理知识积累(知识管理,包括管理管理技能相关的知识积累和经典缺陷积累等)。
执行层执行层负责执行具体的质量控制和质量保证活动,如编写测试用例,执行各种测试,进行各项工作的QA检查等等。
对于CIPAce的产品开发,控制层的工作由CIP项目经理、各项目主管负责(以后成立模块开发项目小组的话,由该小组的项目经理负责,该小组的质量目标一定要和产品质量目标持平或更高),执行层的工作由测试人员负责。
现在我们严重缺失一个在项目组中切实可行的过程规范和具体的QA工程师,缺少一定明确的规程规范和对执行过程的监控。
产品开发各阶段的质量管理在产品的开发过程和系统的客户实施中,不管是瀑布型还是迭代型还是敏捷开发,其工作都可以分为需求分析、系统设计、编码和测试几种。
对于瀑布型的软件开发生命周期而言,其阶段性是最为明显的,各个阶段的工作也是最为独立、明确的。
在各个阶段的工作过程中以及阶段结束的里程碑审核工作中,都需要进行各种质量管理(QA,QC,缺陷预防,缺陷统计分析和改进建议)工作。
下面分各个阶段进行阐述。
需求阶段需求阶段可以分为客户需求和系统需求两个阶段。
对我们而言,可以说0.3或者0.4需求版本之前是客户需求阶段,主要是确定了需求的业务目标、业务范围、主要业务对象、主要业务对象的生命周期、主要业务功能以及业务功能的操作流程。
0.4以后才开始做系统需求的工作,系统需求的工作主要是对客户需求的进一步细化和分支、异常处理分析,分析出系统业务方案(包括业务流程或业务对象的生命周期驱动、业务功能的具体逻辑分析和UI规划等)和各项对应的质量指标等。