产品质量管理改进方案.doc

产品质量管理改进方案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 2003SP1/2008 (待完善) 易更改性 客户发现缺陷修复的容易程度（Hot fix）以及我们对系统更新的容易程度（定时更新）。(待完善) 质量管理的职责划分 谁对软件质量负责？全员负责。任何与软件开发、管理工作相关的人员都对质量产生影响，都要对质量负责。谁对软件质量负最大的责任？谁的权利越大，他所负的质量责任就越大。 全员质量意识和质量态度是质量管理的重中之重。培养质量态度的最简单方式就是为自己的质量事故买单，而且是加倍的买单。驾驶飞机的驾驶员每次执行飞行任务都会异常认真负责，因为出现事故自己也会有生命危险，没有补救措施，所以必然会100%的认真对待。向我们这次的CIP Internal项目的推行也是一种方式。 人无完人，每个人都有思维盲区或考虑不周的地方，但后续的检查或测试是为前面工作的思维盲区服务的，而不是为不负责任的态度服务的。我们必须形成所有人员都要为自己质量负责的工作态度和企业文化。 对于公司决策层、控制层和执行层，明确各层的质量管理权力和职责。 决策层 对于决策层来说，要引导树立全员参与、预防胜于检查和追求零缺陷的企业文化，关注企业战略目标的实现，负责企业质量管理中重大事情的决策，审核批准产品质量目标，提供质量管理的资源，提供质量管理和质量控制技能的培训，推行企业的质量体系，推行企业的质量管理知识积累（知识管理）。 控制层 控制层负责搭建质量管理平台，贯彻落实公司的质量理念，实现公司设定的产品质量目标，制定质量管理方法，开发质量管理工具，制定质量计划，监督质量控制工作的执行，对发现的质量问题进行统计分析并制定相应的解决方案。负责企业的质量管理知识积累（知识管理，包括管理管理技能相关的知识积累和经典缺陷积累等）。 执行层 执行层负责执行具体的质量控制和质量保证活动，如编写测试用例，执行各种测试，进行各项工作的QA检查等等。 对于CIPAce的产品开发，控制层的工作由CIP项目经理、各项目主管负责（以后成立模块开发项目小组的话，由该小组的项目经理负责，该小组的质量目标一定要和产品质量目标持平或更高），执行层的工作由测试人员负责。现在我们严重缺失一个在项目组中切实可行的过程规范和具体的QA工程师，缺少一定明确的规程规范和对执行过程的监控。 产品开发各阶段的质量管理 在产品的开发过程和系统的客户实施中，不管是瀑布型还是迭代型还是敏捷开发，其工作都可以分为需求分析、系统设计、编码和测试几种。对于瀑布型的软件开发生命周期而言，其阶段性是最为明显的，各个阶段的工作也是最为独立、明确的。在各个阶段的工作过程中以及阶段结束的里程碑审核工作中，都需要进行各种质量管理（QA，QC，缺陷预防，缺陷统计分析和改进建议）工作。下面分各个阶段进行阐述。 需求阶段 需求阶段可以分为客户需求和系统需求两个阶段。对我们而言，可以说0.3或者0.4需求版本之前是客户需求阶段，主要是确定了需求的业务目标、业务范围、主要业务对象、主要业务对象的生命周期、主要业务功能以及业务功能的操作流程。0.4以后才开始做系统需求的工作，系统需求的工作主要是对客户需求的进一步细化和分支、异常处理分析，分析出系统业务方案（包括业务流程或业务对象的生命周期驱动、业务功能的具体逻辑分析和UI规划等）和各项对应的质量指标等。除了需要对该阶段的具体工作和交付物进行质量管理外，该阶段的主要交付物系统需求规格说明书是以后各个阶段的质量管理的详细目标。因此，在系统需求规格说明书中，一定要明确定义产品在各个质量特性上的具体参数指标，并对某些业务功能提出的特定要求参数指标。 质量管理活动 预防措施：学习相关业务的理论知识和行业经验；学习类似软件的功能；参考需求分析文档模板展开各项工作； Q A：严格按照各个小版本设定的目标进行工作，减少无效工作； Q C：在各个小版本上检查是否完成了该小版本的目标；进行需求评审； 统计分析：最严重需求缺陷率（多少个缺陷每功能点） 和需求缺陷率； 经验积累：评审时应重点进行逻辑分支完整性检查；进行业务接口完整性检查；易用性检查；兼容性定义检查；。 设计阶段 对于设计工作，可以分为系统设计和模块设计两个阶段。这里的系统设计和模块设计与我们平常所说的概要设计和详细设计有所区别。系统设计和模块设计是从设计所设计的范围和影响而言，概要设计和详细设计是从设计的深度而言的。 系统设计指的是从整个产品的角度进行的一个基础设计，如架构设计和一些基础核心模块（如工作流、Meta Data、Audit Trail、Custom Report等）的设计；详细设计指的是具体模块的设计（如Proposal模块的设计，Ranking模块的设计）。系统设计在很大程度上决定了系统的各项质量指标的界限。模块设计是在系统设计的框架基础上进行的。 由此，我们应该加强在产品系统层级上的系统设计，进一步明确架构师和DBA的职能工作。在系统设计阶段，我们就应该积极引进“垂直原型”对架构设计的各项质量指标进行测试，尽早消除架构缺陷。 在详细设计中，严格遵照系统设计的框架要求进行设计，恪守产品上的设计规范和各种接口。并对照详细设计模板，确保设计明确、完整。 在设计阶段产生的缺陷大多都是S1缺陷。如果遗漏到以后阶段，那么修复的成本会非常高。由于该阶段的设计方案会直接影响后续编码工作的测试难易程度，所以也要对有关的测试方案有所设计，设定需要进行白盒单元测试的范围（考虑到成本，我们只会针对性的选择部分业务逻辑复杂，性能要求高的地方进行白盒单元测试）。例如，我们对某业务逻辑进行单元测试的时候，并不期望同时测试该业务所涉及到的数据库操作，如果没有将数据访问的方法通过接口分割出来，那我们就没法用Mock来模拟数据访问，而只测试这部分业务逻辑的正确性了。 质量管理活动 预防措施：在设计阶段，积极引进“垂直原型”对设计的各项质量指标进行测试； QA：重点关注评审流程的规范性，确保评审工作的效果和效率（杜绝形式主义）； QC：设计评审； 统计分析：最严重设计缺陷率（多少个缺陷每功能点） 和设计缺陷率； 需求缺陷率（该阶段会发现需求阶段的缺陷，以评价需求阶段的工作质量）； 经验积累：1，严格对照设计模板展开设计，减少疏漏；2，注重架构依从性和接口完整性的检查。 编码阶段 对于编码工作，是我们现在出现质量问题的重灾区。从软件行业来说，引起质量缺陷最多的阶段是设计阶段。这说明两点：1，我们现在的设计质量控制的比编码质量控制好；2，编码的质量水平严重低于行业水平。究其原因，我们可以发现现在对于编码阶段的质量控制非常少，虽然一直都有计划要采取代码检查抽查，白盒测试都手段进行质量控制，但基本上都是由于资源和时间的原因而没有进行。导致测试和稳定的过程非常的漫长，把资源和时间都耗费在修复缺陷这个焦油坑里。工作失控。 测试驱动开发(TDD)以不断的测试推动代码的开发，既简化了代码，又保证了软件质量。这里的开发指的不仅仅是编码，而是包括设计和编码。在开始真正编码（前面已经有提到设计时要一同考虑测试设计，在这里主要关注的是测试对编码的驱动部分）前，先编写白盒单元测试的测试用例的好处是非常明显的，可以加深编码人员对相应功能需求和设计的掌握，并通过用例的评审对编码人员的理解进行考核。与编码同时，测试人员编写具体的功能测试用例、集成测试用例和补充系统测试用例，为后续测试工作做好准备。 质量管理活动 预防措施：1，对开发、测试人员进行需求和设计培训；2，要求开发人员对功能测试用例进行反讲； QA：日构建和持续集成的搭建；保证每天的开发工作没有降低系统的质量水平； QC：代码检查（设计人员负责），白盒单元测试（开发人员负责），快速跟进的功能单元测试（测试人员负责），渐增性的自动化测试（测试人员负责），阻断性测试；编码阶段评审，重点功能的性能测试，兼容性测试，易用性测试； 统计分析：按模块、重要性、严重性统计，缺陷原因分析； 各开发人员的开发缺陷率统计与分析（按严重性分级）；缺陷趋势分析； 设计缺陷率（该阶段会发现设计阶段的缺陷，以评价设计阶段的工作质量）； 需求缺陷率（该阶段会发现需求阶段的缺陷，以评价需求阶段的工作质量）； 经验积累：暂无。 说明： 阻断性测试（即冒烟测试）:引入该测试的目的是确保开发人员没有提交的代码没有S1缺陷，不影响测试的正常进行； 编码阶段评审：我们一直没有这个阶段的评审。引入该评审主要是两个目的：a，用以确保待集成的代码已经达到了设定的质量要求（具体的质量要求待完善）；b，确保待集成的模块已经根据系统设计的要求完成各集成接口的开发。微软的开发流程中，在集成之前，对开发的功能进行了一次确认测试。对我们来说，进行一次阶段评审应该可以达到同样的目的了。 集成阶段 根据系统设计，将代码阶段通过评审的模块集成到系统中。对于系统集成，建议采取渐增式集成（需要在做开发计划时就考虑将集成时间错开，多个功能同时集成会带来较高的集成风险）。开发完一部分，集成一部分，测试一部分。只有前面的集成通过测试后才集成下一部分。 质量管理活动 预防措施：1，在需求部分有明确的产品运行环境定义；2，在设计阶段，确保有准确、完整的集成设计； QA：重点关注系统配置管理的及时性和完整性，日构建和持续集成； QC：集成接口的代码检查，集成接口的功能测试，自动化测试，阻断性测试； 统计分析：按模块、重要性、严重性统计，缺陷原因分析； 各开发人员的开发缺陷率统计与分析（按严重性分级）；缺陷趋势分析； 编码缺陷率（该阶段会发现编码阶段的缺陷，以评价编码阶段的工作质量）； 设计缺陷率（该阶段会发现设计阶段的缺陷，以评价设计阶段的工作质量）； 需求缺陷率（该阶段会发现需求阶段的缺陷，以评价需求阶段的工作质量）； 经验积累：重点功能的性能测试。 系统测试阶段 系统集成完毕后，系统的功能基本已经冻结。该阶段的主要工作是对系统进行整体测试。其质量目标就是前面所定义的产品质量目标。 质量管理活动 预防措施：1在需求部分有明确的产品运行环境定义；2，在设计阶段，确保有准确、完整的集成设计； QA：重点关注系统配置管理的及时性和完整性，日构建和持续集成； QC：重点关注跨模块的功能测试，系统性能测试，易安装性测试，自动化测试，阻断性测试； 统计分析：按模块、重要性、严重性统计，缺陷原因分析； 各开发人员的开发缺陷率统计与分析（按严重性分级）；缺陷趋势分析； 集成缺陷率（该阶段会发现集成阶段的缺陷，以评价编码阶段的工作质量）； 编码缺陷率（该阶段会发现编码阶段的缺陷，以评价编码阶段的工作质量）； 设计缺陷率（该阶段会发现设计阶段的缺陷，以评价设计阶段的工作质量）； 需求缺陷率（该阶段会发现需求阶段的缺陷，以评价需求阶段的工作质量）； 经验积累：易安装性测试。 小结 “道为本，术为用；术合于道，相得益彰；道术相离，各见其害；轻道重术，则智术滥用，手段极尽，故生酷吏与小人。”在道、术的权衡与运用之中，我们的目标应该是“因术以明道而至于道”。在任何的管理工作都应该遵循这样的道理。 在该改进方案中，还有很多的内容缺失和不足。没有阐明一个明确、清晰的质量管理体系，没有涉及到质量活动的经验积累如何进行、具体QC活动是如何开展等等。但我相信，以此为蓝本，我们一定可以在质量管理上有一个大的提升，因为我们明白了我们的目标在哪里，我们应该做什么。对于怎么做，我们可以边干边学。 目标已如北极星，努力工作！Impossible is nothing! PAGE PAGE 5