软件评审PPT学习课件

软件质量保证和管理 Ch 9软件评审 1 第9章软件评审 9 1为什么需要评审9 2软件评审的角色和职能9 3评审的内容9 4评审的方法和技术9 5准备评审会议9 6召开评审会议9 7跟踪和分析评审结果9 8如何实施成功的评审 2 9 1为什么需要评审 从成本上来衡量缺陷发现得越晚纠正费用越高 而软件评审的重要目的就是通过软件评审尽早的产品中的缺陷 减少大量的后期返工 3 9 1为什么需要评审 从技术上来衡量进行审查也是非常必要的 由于人的认识不可能百分百地符合客观实际 因此生命周期每个阶段的工作中都可能发生错误 由于前一阶段的成果是后一阶段工作的基础 前一阶段的错误自然会导致后一阶段的工作结果中有相应的错误 而且错误会逐渐累积 越来越多 4 最后 及时进行软件评审不仅有利于软件质量的提高 还能进一步提高工程师的工作效率 1 开发工程师减少修订缺陷的时间 提高编程效率减少测试和调试时间 2 项目负责人缩短开发周期减少维护费用项目风险和质量问题得到很好控制 3 测试工程师可以将更多的精力放到测试用例设计上 以进一步提高测试效率 4 维护人员维护工作减少产品的可维护性增强 5 9 2软件评审的角色和职能 一般来说 对于正式的评审活动应组建评审小组 评审小组主要由如下角色构成 1 协调人在整个评审会议中起着缓和剂的作用 其主要任务如下 和作者共同商讨决定具体的评审人员安排正式的评审会议 与所有评审人员举行一个准备会议 确保所有的评审员都明确他们的角色和责任确保会议的输入文件都符合要求如果作者或者评审员没有为即将召开的评审会议做好充分的准备 则需要重新安排会议并通知大家确保大家的关注点都是评审内容的缺陷确保所有提出的缺陷都被记录下来跟踪问题的解决情况和项目组长沟通评审的结果 6 2 作者可以是部门经理或文档撰写人等 作者的主要职责如下 确保即将评审的文件已经准备好与项目组长 协调人一起定义评审小组的成员3 评审员评审员必须具有良好的个人能力 通常在评审员的选择上应该包含上一级文档的作者代表和下一级文档的指定作者 评审员的职责如下熟悉评审内容 为评审做好准备 在评审会上应该关注问题而不是针对个人主要的问题和次要的问可以被分别讨论在会议前或者会议后可以就存在的问题提出建设性的意见和建议明确自己的角色和责任做好接受错误的准备 7 9 3评审的内容 9 3 1管理评审9 3 2技术评审9 3 3文档评审9 3 4过程评审 8 9 3 1管理评审 管理评审实际就是质量体系评审 ISO8402 1994标准规定的定义是由最高管理者就质量方针和目标 对质量体系的现状和适应性进行正式评价 管理评审是以实施质量方针和目标的质量体系的适应性和有效性为评价基准 对体系文件的适应性和质量活动的有效性进行评价 体系审核的结果有时是管理评审的输入 即管理评审要对体系审核的 过程 和 结果 进行检查和评价 9 1 管理评审的目标 负有执行职责的供方管理者 应按规定的时间间隔对质量体系进行评审 确保持续的适宜性和有效性 以满足本标准要求和供方规定的质量方针和目标 1 适宜性 2 有效性 3 充分性2 管理评审的输入管理评审由最高管理者发起 要求各部门对管理体系目前的状况 适宜性 有效性 充分性 进行评审 10 管理评审的输入文件需要包含如下内容 质量管理体系运行状况 质量方针和质量目标的适宜性 有效性和充分性 内 外部审核结果改进 预防和纠正措施的状况 内部审核和日常发现的不合格项采取的预防和纠正措施的实施及其有效性的监控结果 上次管理评审提出的改进措施实施情况及验证信息 11 3 管理评审的输出管理者评审的输出是最高管理者对组织的管理体系做出的战略性决定和决策 其结果通常为 管理评审报告 该报告在一定时间内将成为组织开展各项管理活动的重要依据 这是一个组织在一个时间段内围绕最高管理者战略性决策开展各项管理 经营活动的重要依据 12 管理评审报告 需要包含如下内容 质量体系的总体评价 适宜性 有效性 充分性 质量管理体系及其过程的改进 包括对质量方针 质量目标 组织结构 过程控制等方面 产品是否符合要求的评价 有关产品的改进 包括是否需要进行产品 过程审核等与评审内容相关的要求 新资源的需求的决定和措施 13 9 3 1管理评审 质量管理体系运行状况内 外部审核结果改进 预防和纠正措施的状况上次管理评审提出的改进措施实施情况及验证信息 管理评审 质量体系的总体评价质量管理体系及其过程的改进产品是否符合要求的评价 有关产品的改进新资源的需求的决定和措施 输入 输出 对质量体系进行回顾和总结并确保其适宜性 有效性和充分性 14 9 3 2技术评审 技术评审是对产品以及各阶段的输出内容进行评估 技术评审的目的是确保需求说明 设计说明书与最初的说明书保持一致 并按照计划对软件进行了正确的开发1 技术评审的目标技术评审作为一项软件质量保证活动需要 作用如下 揭示软件在逻辑 执行以及功能和函数上的错误验证软件是否符合需求确保软件的一致性在完成技术评审的过程中 不仅需要关注上述的评审目标 还需要注意技术的共享和延续性 15 9 3 2技术评审 评审的目的评审的内容评审检查单其他必需文档 技术评审 技术评审报告 会议的基本信息存在的问题和建议措施评审结论和意见问题跟踪表技术评审问答记录 输入 输出 16 9 3 3文档评审 1 正确性2 完整性3 一致性4 有效性5 易测性6 模块化 系统和文档描述必须深入到模块 模块化指的是模块的独立性7 清晰性8 可行性9 可靠性10 可追溯性 17 9 3 4过程评审 过程评审的目的 评估主要的质量保证流程考虑如何处理 解决评审过程中发现的不符合问题总结和共享好的经验指出需要进一步完善和改进的地方 18 9 3 4过程评审 为了进行过程评审 需要成立一个专门的过程评审小组 评审小组需要走访软件生产涉及的各个部门和人员 包括开发工程师 测试工程师 甚至兼职人员等 整个评审流程 如图所示 19 在走访过程中 评审小组需要关注如下内容 质量保证流程在开发过程中是如何被遵循的还能采取什么措施来加强质量保证流程的效力目前的流程对项目进展是否有帮助 评审技术后 评审小组需要提交一份 评审报告 其中包括 评审记录评审后 对现有流程的说明和注释评审小组的建议 20 9 4评审的方法和技术 9 4 1评审的方法9 4 2评审的技术 21 9 4 1评审的方法 临时评审 Adhocreview 轮查 Pass round 走查 Walkthrough 小组评审 GroupReview 审查 Inspection 22 1 临时评审临时评审是最不正式的一种评审方法 2 轮查轮差又称为分配审查方法 作者将需要评审的内容发送给各位评审员 并收集他们的反馈意见 但轮查的反馈往往不太及时 3 走查走查也属于一种非正式的评审方法 它在软件企业中被广泛使用 产品的作者将产品向一组同时介绍 并收集他们的意见 在走查中 作者占有主导地位 由作者描述产品的功能和结构以及完成任务情况等 4 小组评审评审是有计划的和结构化的 非常接近于最正式的评审技术 23 5 审查审查和评审很相似 比评审更严格 是最系统化 最严密的评审方法 普通的审查过程包含了 制定计划 准备和组织会议 跟踪和分析审查结果等 审查具有其他非正式评审所不具有的重要地位 在IEEE中提到 通过审查可以验证产品是否满足功能规格说明 质量特性以及用户需求等 通过审查可以验证产品是否符合相关标准 规则 计划和过程提供缺陷和审查工作的度量 以改进审查过程和组织的软件工程过程 24 9 4 1评审的方法 审查 小组评审和走查异同点比较表 25 9 4 1评审的方法 如何选择正确的评审方法 选择评审方法最有效的标准是 对于最可能产生风险的工作成果 要采用最正式的评审方法 例如 核心代码的失效也会带来很严重的后果 所以也应该采用审查或小组评审的方法进行评审 而一般的代码 则可以采用临时评审 同桌评审等比较随意的评审方法 26 9 4 2评审的技术 缺陷检查表它列出了容易出现的典型错误 是评审的一个重要组成部分 规则集类似于缺陷检查表 通常是业界通用的规范或者企业自定义的各种规则的集合 评审工具的使用合理的利用工具 如NASA开发的ARM 自动需求度量 从不同角色理解不同的角色对产品 文档的理解是不一样的 场景按照用户使用场景对产品 文档进行评审 27 9 5准备评审会议 1 评审发生的时间各个阶段的 评审计划 的内容包括 各个阶段的评审时间 评审方式 评审组成员等 SQA在其提交的 质量保证计划 中 应根据各个阶段的 评审计划 制定相应的评审检查点 评审计划要确定评审发生的时间 评审的时间一般选在达到某个里程碑的时候 28 9 5准备评审会议 2 组建评审组项目组提出评审组长和评审组成员名单的建议 质量组根据项目组的建议 与相关部门或人员 如外项负责人 进行协商确定 选定评审组长对评审来说是非常重要的 评审组长需要和作者一起 策划和组织整个评审活动 对评审组长的要求如下善于制定和执行评审计划评审是公平 公正的具有较好丰富的技术技能和知识积极带领评审组员按时保质的完成评审任务 29 9 5准备评审会议 3 准备评审材料材料的筛选方法 基础性和早期的文档 如需求说明和原型等与重大决策有关的文档 如体系结构模型对如何做没有把握的部分 如一些挑战性模块 他们实现了不熟悉的或复杂的算法 或涉及复杂的商业规则等将不断被重复使用的部件总之 应该选择最复杂和最危险的部分进行审查 30 9 5准备评审会议 4 发送审查包一个审查包包含的内容 将被审查的可交付产品 文档 其中指明了需要审查的部分定义了可交付产品的前期文档相关标准或其他参考文档参与者需要的所有表格有助于审查者发现缺陷的工具 文档 如缺陷检查表 相关规则等用于验证可交付产品的测试文档评审员收到评审包后要阅读并理解其中的内容 然后采用相应的缺陷检查表或其他方法来检查产品和文档中可能存在的缺陷 并记下将在会议中提出的问题 31 9 5准备评审会议 5 制定活动进程表评审会议之前 评审组长还需要制定相应的活动进度表 安排会议房间 并将活动 日期 次数和地点通知评审组成员 在安排会议时 需要注意如下几点 至少提前2 3天通知小组成员会议的时间 地点等不要安排同一个人一天内参加多个评审会议根据工作情况 适时安排评审会议 不要因为评审过多影响项目进度 也不要项目过多而推迟评审的时间 32 9 6召开评审会议 评审会议时评审活动的核心 所有与会者都需要仔细检查评审内容 提出可能的缺陷和问题 由记录员记录在评审表格中 会议的目标是发现可能存在的缺陷和问题 1 会议启动在会议的一开始 评审组长需要接受每一位会议成员 简述每个人所承担的角色和职责 评审组长需要判断每一位评审人员是否都准备充分 如果评审组长认为一切都准备充分 则正式开始进行产品和文档的评审 33 9 6召开评审会议 2 评审开始评审的主要步骤 1 由评审员 作者进行演示或说明 2 评审员会就不清楚或疑惑的地方与作者进行沟通 3 协调人或记录员在会议过程中完成会议记录 1 清楚 简明对于记录的每一个问题和缺陷 都应该附有一个简短的说明 同时记录下该问题出现的位置 2 缺陷的分类对于发现的缺陷可以按照不同的范畴进行分类 起源 类型 严重性 34 9 6召开评审会议 3 评审决议评审结果 接受 评审内容不存在大的缺陷 可以通过有条件接受 评审内容不存在大的缺陷 修订其中的一些小缺陷后 可以通过不能接受 评审内容中有较多的缺陷 作者需要对这些缺陷进行修改 并在修改之后重新进行评审 评审未完成 由于某种原因 评审未能完成 还需要后续会议 35 9 6召开评审会议 4 评审结束评审结束之后 评审小组需要一系列的评审结果问题列表评审总结报告 会议记录 评审决议签名表问题列表说明了项目或产品中存在的问题 并需要后期跟踪 评审总结报告包含了评审的内容 评审人 会议总结等基本信息 36 9 6召开评审会议 评审中的注意事项 人身攻击 在评审过程中 所有的参与人都应该将矛盾集中于评审内容本身 而不能针对特定的参与人 无休止的争论 通常对于某些问题 评审组很难达成一致意见 这时 可以把问题记录下来 而如何认定则留给作者自己决定 偏离会议中心 在实际会议中 会议常常会发生偏离 如转到政治话题的讨论 鼓励所有人发言 鼓励不擅言辞的参与者就评审内容发表自己的看法 比如按照座位顺序轮流发表意见 37 9 7跟踪和分析评审结果 评审结果的跟踪1 评审结果为有条件接受的缺陷跟踪对于有条件接受的情况 被评审产品作者在评审会后需要对产品进行修改 修改期限一般为3 5个工作日 评审组对修改后的被评审产品进行确认 在两个工作日内提出反馈意见 评审组长做好评审会后的问题跟踪工作 确定评审决议中的问题是否最终全部解决 在满足结束此次评审过程的条件后 评审组长要将评审报告发给所有的评审组成员 被评审产品的作者 SQA人员 38 2 评审结果为不接受对于不接受的评审结果 并评审产品作者在评审会议后需要根据问题列表对产品进行全面修改 并将修改结果提交给所有的评审组成员评审组长检查修改后的产品 如果已经满足评审的基本条件 需要重新组织和召开评审会议对产品进行审查 39 评审结果的分析3 有效性有效性的分析要求对所有发现的缺陷进行统计 包括由客户发现的缺陷 4 效率和成本评审的效率越高