项目质量管理课件(PPT81页).pptVIP

6.6.1 度量要素 项目度量：项目的规模、成本、工作量、进度、生产力、风险、顾客满意度 产品度量：以质量度量为中心，包括功能性、可靠性、易用性、可维护性、可移植性 过程度量：成熟度、管理、生命周期、生产率等 第6章　项目质量管理 6.1 质量管理概述 6.2 项目质量的组织保证 6.3 质量计划 6.4 软件评审方法和过程 6.5 缺陷预防和跟踪分析 6.6 质量度量 6.7 过程质量管理 6.4 软件评审方法和过程 6.4.1 软件评审的方法和技术 6.4.2 角色和责任 6.4.3 软件评审过程 6.4.4 如何有效地组织评审 软件评审 不管你有没有发现他们，缺陷总是存在，问题只是你最终发现它们时，需要多少纠正成本。评审的投入把质量成本从昂贵的、后期返工转变为早期的缺陷发现。 ——卡尔·威格 软件评审的方法 临时评审（Ad hoc review）：自发使用 轮查（Passroud）：邮件分发审查，异步进行 互为复审：两个人工作内容和技术比较接近，涉及人员很少，复审效率较高，如极限编程 走查（Walkthrough）：对评审对象要从头到尾检查一遍 审查（Inspection）：系统化、严密的集体评审方法 最不正式 最正式 临时评审 轮查 互为复审 走查 会议审查 软件评审方法（续） 在软件开发过程中，各种评审技术交替使用，其原则： 在不同的开发阶段和不同的场合选择适合的评审方法 需求和设计评审初稿：轮查 需求和设计最终定稿之前：评审会议 代码评审：互为评审、自发采用“临时评审” 对最可能产生较大风险的工作成果，要采用最正式的评审方法 需求分析报告：走查或者会议评审 核心代码：走查或者会议评审 软件评审技术 检查表技术：简单、提高评审效率、改进评审质量。例如缺陷检查表列出容易出现的典型错误，帮助找出缺陷，排除隐患 场景分析技术：更能发现错误和问题，耗时多。多用于需求文档评审，发现遗漏和多余的需求 工具：提高效率，如IBM的RRP、NASA的ARM，对导入的文档统计分析，找出各种词语的出现概率，对完整性和二义性进行分析 6.4.2 评审过程中的角色和责任 小组组长 作者 读者 记录者 评审员 审核者 协调者 6.4.3 软件评审过程（1） 软件评审过程（2） 计划 确定被评审对象 确定期望达到的评审目标 计划选用的评审方法 会议准备 确定评审组长：经验丰富、技术能力强、工作认真负责、不能和作者有密切关系（保持评审客观性） 选定评审材料，找出哪些是必须评审的 分发评审材料 制定相应的活动进度表，提前2-3天通知小组成员 软件评审过程（3） 召开会议： 简要说明待审查内容、重申会议目标 详细说明评审材料，了解各评审员对材料的了解是否一致 如理解不一致，容易发现问题（二义性、遗漏、错误假设），从而找出缺陷 记录问题和缺陷 记录员向小组重述记录的缺陷 评审决议 座次图 主持人 作者 记录员 列席人员 内审员 技术专业人员 软件评审过程（4） 评审决议的几种情况 接受 有条件接受：修订其中的一些小缺陷后通过 不能接受 评审未完成 问题跟踪（返工） 验证作者是否恰当地解决了评审会上所列出的问题 考虑是否需要再次召开评审会议 评审注意事项 明确自己的角色和责任； 熟悉评审内容，为评审做好准备，做细做到位； 关注问题，针对问题阐述观点，而不是对人； 可以分别讨论主要的问题和次要的问题； 在会议前或者会议后可以就存在的问题提出自己的建设性的意见； 提高沟通能力，采取适当的、灵活的表述方式； 对发现的问题，要跟踪到底。 6.4.4 如何有效地组织评审 什么叫有效评审： 尽可能、尽早地发现问题和缺陷 高效、省时、省力 实施要点： 把握好流程和评审目标 认真、仔细地阅读评审材料，不断思考 善于提问 充分沟通 一切围绕用户需求进行 。用户？用户的操作习惯？用户的业务流程？应用场景和操作模式 评审组织方法 分层评审方法 （高层次、低层次） 先总体后细节，避免过早陷入细节，只见树木，不见森林 高层次评审：主要评审产品是否满足客户的需求和期望，是否具有合理的功能层次性和完备性，能否满足客户各个方面的需求 低层次评审：逐字逐行地评审文档的各项描述，包括文字、图表，要求准确、完整、清晰。比如，需要较高的性能、多数情况下支持….. Web页的刷新响应时间不超过3秒（不专业、不明确） 每一个页面访问的响应时间不超过3秒 评审组织方法（续） 分类评审方法 （分业务需求、功能需求、非功能需求、用户操作性需求等 ） 业务需求：最基本的需求、核心需求。用户的高层代表关注。资深人员（测试经理）参加评审。 功能性需求：用户的中层人员关注。用户的中层人员和各个功能模块负责人参加评审。 操作性需求：用户的操作人员关注。具体操作人员和测试工