软件质量管理实践全面总结

lsekfe

　缺陷综述
　　软件缺陷的定义
　　软件产品在某种程度上不能满足用户的需求。
　　软件缺陷的生命周期
　　从一个软件缺陷被发现、报告到这个缺陷被修复、验证、最后关闭的过程。
　　缺陷产生的原因
　　原因很多，例如重技术不重管理、项目监控和计划做得不够好、不扎实等等。
　　缺陷是谁产生的
　　任何人都有可能产生缺陷。
　　缺陷发现的手段
　　同行评审、测试、管理评审、QA发现、项目组内部发现、客户反馈。
　　需求开发与管理
　　需求的概念和层次
　　概念：需求就是以一种清晰、简洁、一致且无二性的方式，对待开发的各个有意义方面的陈述的集合。
　　层次：从应用角度看软件需求。
　　业务需求：反映组织机构/客户对系统产品高层次的目标要求。
　　用户需求：用户使用产品必须完成的任务。
　　功能需求：开发人员实现软件功能，使得用户能够完成的任务，从而满足业务需求。
　　需求管理
　　控制和维持需求的约定，需求追踪是双向的，正向由PM主导，其他人辅助，逆向由测试主导。
　　需求验证
　　评审为主，一般参与人员为各个技术的专家。
　　配置与变更管理
　　概念
　　一门用来记录并且控制软件产品数据的管理学科，是对各类工作产品的内容、版本、变更和发布进行控制。
　　忽视软件配置管理会导致如下现象：
　　A.已经排除的bug，反复出现
　　B.找不到最新修改的源代码
　　C.找不到原来的编程人员
　　D.发行的版本错误
　　E.软件正常安装后不能工作
　　F.异地不能正常工作
　　配置控制委员会CCB
　　一般项目经理会根据配置控制委员会的建议和批准管理各项活动并且控制它们的进程，一般组成人员：高层经理、项目经理、关键的RD、关键的QA、PPQA代表、CM代表、PM，CCB的组长不能是项目经理。
　　配置项
　　一般包含：计算机程序、开发者和用户的文档、数据等，每一个配置项需表明：作者、时间、原因、当前状态、版本号。
　　配置管理活动
　　内容：
　　A.制定配置管理计划
　　B.建立三库（开发库、受控库、发行库）
　　C.确定配置标识规则
　　D.进行版本管理和发行管理
　　E.实施变更控制
　　F.进行配置审计
　　G.报告配置状态
　　变更管理活动
　　发生在开发过程的所有阶段，从需求分析到产品开发再到维护。
　　变更追踪：处理变更及新增功能提交、评估、实施、验证与完成的流程。
　　实施变更管理重要的作用就是对变更进行度量分析。
　　变更申请流程：涉及的变更范围写明，通知项目经理——同意后，项目经理填写变更申请单—
　　—提交给CCB审批，告知CM（客户经理）。
　　同行评审
　　同行评审与测试的关系
　　开发阶段，专家对代码的一个评审，提高代码质量，减少测试成本，这样能够加深开发人员对工作的理解，预防bug，也避免在测试阶段大量返工。
　　同行评审的种类
　　正式评审、技术审查、走查。
　　同行评审的对象
　　产品需求规格书、用户界面规范与设计、设计模型、源代码、测试计划、设计、用例及步骤、项目计划。
　　正式评审的流程
　　预备会议-审查-评审会-书写评审报告-返工-跟踪。
　　QA发现的不符合问题的处理
　　QA的担当的角色
　　老师（指导项目）、警察（评价开发的过程）、医生（帮助项目组想办法解决问题）。
　　QA的职责要求
　　具备一定的知识和技能（有开发经验）
　　公平公正的素质
　　自信，较强大的沟通能力
　　QA特别关注的问题
　　项目计划制定不合理
　　维护需求的可追踪性和一致性容易出问题
　　配置管理容易出问题
　　对QA的误解
　　认为QA应该负责产品质量，产品质量应该是由每一个人负责。
　　认为QA就是编写文档和干零杂的人（开发经验、管理经验、项目管理知识、公平公正的素质、较强的沟通能力）。
　　认为QA只会站在组外品头论足、挑毛病。
　　认为QA就是关心开发过程是否规范，不关心产品质量、不关心技术。
　　QA工作的度量
　　投入的工作量占项目总体工作量的比例：QA工作量和配合管理工作量应该占总项目的5%以内。
　　QA发现的不符合问题数量：一个项目发现的bug量太少，得思考代码质量太好还是QA得能力问题，解决方法：安排另一名QA介入，查看结果，一般QA发现的bug数=开发人数，例如80-100人一月，则应发现80-100个bug。
　　总结并提供经验数量。
　　软件度量
　　软件度量的目的
　　理解、评价、控制、预测、改进。
　　软件度量应遵循的方针
　　根据信息需要和目标检测测量目标并予以维护。
　　软件度量的方法只是达到目的的手段，而其本身并不是目的。
　　以应用度量结果为中心，并非为了收集数据而收集数据。
　　规定度量元，说明如何获得度量数据，让开发参与其中。
　　规定如何对度量数据进行分析和报告，提供度量结果，将特定情境中的过程行为相关知识存储到经验数据库中。
　　度量活动
　　首先确定度量活动的首要目标，度量内容必须由公司的高管层决策、参与与支持。
　　度量目标：使用GQM方法，每一个项目都有一系列的目标、每一个目标都有一系列问题、每一个问题都应该有完整、可以量化的满意答案。
　　度量元：软件度量的内容（对产品济宁度量时，需要关注的信息对象基本属性的描述）。
　　度量模型：指关于要度量哪些度量元的需求规格说明，例如：是为了了解发现产品当前的质量情况、是为了了解组织过程的能力等等。
　　基本过程：度量承诺、度量计划、度量实施、度量评估、度量改善。
　　度量方法与采集：GOM、采集数据的人要统一模式、谁负责统计什么一定要明确，适当的时候可以进行自动化的支持来完成数据的精准。
　　数据质量
　　数据的真实性、数据的同步性、数据的有效性、数据的一致性。
　　软件度量相关问题
　　增加度量正确性的措施；
　　软件过程的性能；
　　度量过程常见的问题：度量过多/少、缺少管理承诺、缺乏度量数据的一致解释和理解、缺乏度量发面的灵活性、缺乏明确的责任人等等。
　　缺陷度量
　　什么是缺陷度量：对项目过程中产生的缺陷数据进行采集和量化，将分散的缺陷数据统一管理，使其有序而清晰，然后通过采用一系列数学函数，对数据进行处理，分析缺陷密度和趋势等信息，从而提高产品质量和改进开发过程。
　　一般来说，在软件质量保证过程中，需要度量的缺陷数据包括6大类缺陷发现手段发现的所有缺陷。如测试相关的缺陷，需要度量包括测试投入的工作量和成本数据、测试任务完成情况、测试规模数据、测试结果数据（包括缺陷数据、覆盖率数据）等。
　　缺陷度量
　　缺陷度量元：例如每个模块的各类缺陷数目、缺陷种类等等。
　　缺陷密度=已知缺陷数量/产品规模。
　　缺陷密度的用途：用于设定产品质量目标对软件的质量进行跟踪和管理。
　　缺陷分析
　　缺陷种类分析
　　缺陷根源分析
　　缺陷注入-发现矩阵
　　收敛趋势分析：前提是研发过程稳定、其质量表现大体一致
　　回归分析：在掌握大量观察数据的基础上进行分析
　　缺陷排除分析
　　ODC（正交缺陷分类）缺陷分析：适用场景，需要分析开发者和测试人员相关、与开发阶段相关、与顾客满意程度相关的产品质量的属性
　　缺陷管理
　　缺陷管理的目标
　　发现的每一个bug都能被解决
　　解决不一定是修正
　　收集缺陷数据，数据分析
　　缺陷管理的理念
　　保证进度、质量的理念、坚持流程、分析的理念、使用工具的理念。
　　质量控制工具——统计技术
　　“旧7种工具”：检查表、分层法、直方图、散点图、排列图、因果图、控制。
　　“新7种工具”：关联图、系统图、KJ法、矩阵图、分析法、PDPC法、矢线。