同行评审专题讲座v5

《同行评审专题讲座v5》由会员分享，可在线阅读，更多相关《同行评审专题讲座v5（71页珍藏版）》请在金锄头文库上搜索。

1、1软件同行评审麦哲思科技（北京）有限公司2目录 评审的分类 审查的基本原理 审查的详细过程 审查的其他说明3一 评审的分类为什么需要评审 开发过程中的评审 评审的分类 如何选择评审类型4缺陷注入缺陷消除需求设计构造测试需求设计构造测试缺陷注入缺陷消除需求设计构造测试需求设计构造测试什么样的Bug无法通过测试发现？什么样的Bug无法通过测试发现？讨论：为什么需要评审(review)5审查成功的案例-业界Yourdon和3个有经验的软件人员用45分钟时间审查了一个200行程序， 发现了25个错误，其中有5个错误是不可能通过测试发现 在软件维护方面，Freedman和Weinberg报告，在引入审查

2、前，变更维护 出错率为55%，引入审查之后，这一出错率降至2。 AT&T的贝尔实验室在其开发中引入审查后,生产率提高了14 。 IBM公司报道，每小时的审查可节约20小时的测试。 TRW对一个大型软件进行了研究，发现2019个由用户发现的错误导致代 码变更。分析结果表明，在这些错误中，通过代码审查可以发现62.7% ，通过设计审查可以发现57.7% 。 Litton数字系统在审查中投入了3%的总项目工作量，使得系统集成和系 统测试发现的缺陷数量减少了30%。 Raytheon在两年中将返工率从41%降低到20%，同行评审是重要的手段。6审查成功的案例-我们的客户 某公司2009年11月初开始启

3、动过程改进，第一阶段改 进代码走读、系统测试、度量过程。 该公司是产品开发类项目，产品开发的周期比较短， 销量比较大，质量要求比较高。 2010年1月中旬对12月份代码走查过程改进的效果进 行了分析。 该公司每天下午5点到6点为固定的代码走读时间，对 当天完成的代码进行走查。2人结对，一个作者，一个 专家。 经过1个月的坚持，该措施效果显著。712月份代码走查的平均数据812月份各部门代码走查效率的分析912月份缺陷检出密度的分析1012月份代码走查与系统测试效率的比较11生命周期中的评审客户需求 系统需求 软件需求 用例模型 测试大纲 （其它）构架 概要设计 详细设计 用例 （其它）代码 用

4、户手册 培训材料 （其它）测试计划 系统测试 集成测试 验收测试 （其它）客户需求 系统需求 软件需求 用例模型 测试大纲 （其它）构架 概要设计 详细设计 用例 （其它）代码 用户手册 培训材料 （其它）测试计划 系统测试 集成测试 验收测试 （其它）需 求设 计构 造测 试需 求设 计构 造测 试生命周期中可交付的内容生命周期阶段生命周期中可交付的内容生命周期阶段里程碑（门槛）评审项目后置评审里程碑（门槛）评审项目后置评审12评审的类型 管理类评审 管理类评审的目的在于向上层管理者提供信息，解 决管理问题，做出管理决策，如：发布产品、继续 或取消项目、批准或拒绝提案、调整项目资源。 项目后

5、置评审 对完成的项目进行评审，让未来的项目吸取教训。 项目状态评审 向项目经理和其他项目成员提供项目状态信息，如 里程碑进度、识别的风险、遇到的问题。 技术评审 技术类评审的目的在于检查工作产品是否符合原先 的要求，发现工作产品中的缺陷。13同行评审的类型 有同行参加的技术类评审称为同行评审,同行评审分为 3类 走查(walk throuh),通常以非正式的方式进行。走 查本身也分正式和非正式。 技术评审(technical review)，针对特定技术专题 的评审。 审查(inspection),一般比较正式，规定参加人员 ，要报告审查结果数据。 审查是本课程的重点14走查流程 作者可以在评

6、审会前分发评审材料 评审员各自审查评审材料 作者在会上介绍工作产品概况 小组进行讨论，在讨论中作者详细介绍走查工作产品 评审员 记录错误 建议变更 建议改进 整理记录的笔记，作为项目文件的报告 作者可以发布走查报告15技术评审流程评审组长确定评审重点 需要注意的特定问题 需要满足的特殊标准或规格说明 需要检查的接口或依赖关系组长分发材料评审员各自审查评审材料组长主持评审组长发布发现报告 问题和/或弱项清单 小组对如何解决这些问题和/或弱项清单的建议 行动事项16审查流程作者和主持人分发评审材料 要审查的工作产品 参考文档 审查检查单 记录表格评审员审查材料和记录缺陷评审员参加记录会议 根据个人

7、的输入创建总的清单 加入会议中发现的问题 不讨论问题和建议作者根据问题单进行返工主持人验证返工的完成所有与会人记录发现的缺陷和花费的时间等数据17评审之间的关系 对所给的工作产品来说，某些（但不是所有的）评审 可能是有效的W WTRTRININ工作产 品元素工作产品草案完成的工作产品W： 走查TR：技术评审IN：审查工作产 品元素工作产品草案完成的工作产品W： 走查TR：技术评审IN：审查18评审方式的比较-1走 查技术评审审 查 目的评价工作产品 改进工作产品 考虑候选方案 教育参与人员讨论候选方案 表明工作产品符合规 格说明、计划和标准 变更都正确实现在一定详细的颗粒度基 础上,对工作产品

8、的缺 陷进行定位和排除入口准则 需要在产品计划中 标识或者由小组成 员或管理人员提出发布了评审目的； 作者准备好了； 工作产品准备好了工作产品符合已建立的 就绪准则评审材料 的数量中等中等到较多，根据评 审目的而定相对较少参与人员 数量2人或更多3人或更多37人参加者技术组长和同行技术组长和同行同行小组 评审主持 人作者通常是技术负责人主持人19评审方式的比较-2走 查技术评审审 查 个人评审 不要求要做个人评审要做个人评审 陈述者通常是作者作者或组员读者或无 决策权作者有权作出决定评审组给出建议，管 理人员或技术组长根 据评价作出决定小组选择评审的结论； 缺陷必须排除变更验证 留待其它的项目

9、控 制手段技术负责人验证，作 为评审报告的一部分主持人验证返工报 告可能是走查报告， 记录缺点和问题， 改进建议技术评审报告，包括 缺点和问题清单以及 行动清单缺陷清单和度量元总结收集度量 元非正式需求；可能 收集非正式需求；可能收 集要求所有审查人进行收 集20讨论：你们的评审是如何进行的？现在是否使用？评审类型其它？审查技术评审走查你们的组织使用了哪一种评审，是如何进行的？21选择评审类型的准则 评审目的 排除缺陷 讨论解决方案 关于工作产品进行培训 评审可用的时间 需要及时反馈 需要全面修理 进行审慎决策 可用的专家和个人22练习：选择评审类型时间：15分钟 分组规模：每组不超过7人 要

10、求：识别出你们认为比较重要的3个工作产品，定义其评审类型 ，说明评审的目的，识别评审的参与人员角色工作产品工作产品评审的类型评审的类型评审的目的评审的目的参与的人员参与的人员1234523建议的审查基本集阶段阶段文档文档评审方式评审方式 用户需求说明书（技术复审 可行性分析报告审查 软件需求规格说明 书（SRS）先走查或技术复审，再审查WBS分解结果技术复审 软件估算记录技术复审 软件开发计划技术复审 软件测试计划或大 纲技术复审需求跟踪矩阵同SRS一起评审 系统测试用例走查 软件架构设计先技术复审，再审查 软件详细设计走查或技术复审 系统测试用例技术复审 集成测试用例技术复审 源代码通常情况

11、下进行走查，重点模块进行技术复审或审查 单元测试用例走查 用户手册（操作手 册、安装手册、维 护手册）先走查或技术复审，再审查测试阶段测试报告走查 其他变更申请技术复审设计阶段实现阶段立项阶段需求与策划阶段24二 审查的基本原理25软件审查的历史最初开始于IBM的Michael Fagan 在70年代早期使用；在1976年发表论文 首先在IBM内部传授，然后向外部推广 首先应用于编码，然后扩展到需求和构架 包含了其他人的工作成果 AT&T的Ebenau和Strauss Tom Gilb和Dorothy Graham 现在的许多其他作者和培训员 已经证明，审查是一项人员密集型工作，在消除缺陷方面

12、 往往比测试更有效。26软件审查的基本目的 软件审查的基本目的是在软件工程过程的早期，通过协 助软件开发人员识别和修复其工作中的错误，改进软件 质量 虽然审查不能解决所有问题，例如，审查并不能代替测 试。但审查的成效很大，所有软件组织都应当在其工作 的所有主要方面，如需求、设计、实施、测试、维护和 文档，应用审查或类似的技术评审方法27错误预防或检测的概率45.7%需求测试46.1%集成测试8.3%算法测试72.9%单元测试检测技术62.7%代码审查 *57.7%设计审查 *26.3%编码标准28.7%设计标准预防技术*虽然本表把审查列为错误预防技术，实际上，审查同时也是 一种重要的错误检测技

13、术概率=本技术发现的错误数/总错误数*虽然本表把审查列为错误预防技术，实际上，审查同时也是 一种重要的错误检测技术概率=本技术发现的错误数/总错误数28审查过程应遵循的基本原则-11. 审查是正式的、结构化的过程，用到一系列审查清单，涉 及一系列所定义的参与人员角色 2. 应根据审查产物的不同制定相应的通用审查清单和标准， 必要时可以进行剪裁以适应特定项目的要求。审查清单应 涵盖审查计划、准备、实施、结束和报告准则。 3. 记录会议开始前，评审人应准备好自己所关注和将要提出 的问题 4. 审查的重点在于发现问题，而非解决问题。加上第3条要 求的准备工作，可以最大程度避免在记录会议中浪费时间 5

14、. 将审查数据输入到组织度量库中，用于监测审查效果，并 管理和跟踪产品质量29审查过程应遵循的基本原则-26. 找到主要的问题：造成用户80%痛苦的那20%的缺陷 7. 评审组要对结果共同负责，根据审查结果采取后续行 动是关键 8. 记录审查中发现的事项，但不要成为评审个人性能的 根据 9. 对于技术人员工作的审查，应由技术人员进行，管理 人员不要参与。但应将审查结果和解决所发现问题的 日期通知管理人员。30三 审查的详细过程31审查过程活动主持人和作者选择 和准备材料主持人选择小组和 安排审查评审员审查工 作产品小组记录缺陷主持人和作者选择 和准备材料主持人选择小组和 安排审查评审员审查工

15、作产品小组记录缺陷作者返工产品主持人验证返工作者返工产品主持人验证返工角色分配 材料分发角色分配 材料分发准备准备返工返工记录会议个人评审概况会议记录会议个人评审概况会议32准备:选择主持人 具备一定的技术能力，但并不一定是技术专家 需要有丰富的评审主持经验 了解组织的开发过程、评审过程和相关标准 不能是评价作者业绩的领导 作者或作者之一不能作为主持人33准备：选择主持人 主持人的职责 保证评审材料已准备好 召集合适的评审组 设定合适的开会时间 确保材料已经为评审做了恰当地标记 设定在评审中使用的期望比率（页数/小时） 标出需要关注的主要问题或最近发现的问题 培训新的审查员（通过概况会议或在他

16、们座位旁边 给予指导） 保证记录会议达到目的 确认完成返工34 作者和主持人决定工作产品中需要评审的部分 根据生命周期/开发计划检查工作产品是否准备好 选择或节选合适的规模 选择值得评审的部分 不要在一次评审中涵盖太多的内容 组织级设置被审查产品份量的上限，如一般来说，每 阶段审查的代码量不宜超过 500 LOC 作者和主持人选择和准备小组材料 审查的工作产品 使用的检查单和指南 作为被审查的工作产品的基准的参考工作产品(如工 作产品的规格要求)准备：选择评审材料35准备:选择评审小组成员 小组成员必须熟悉 所开发的产品 开发过程 关于审查的知识 尽管很多人关心审查结果，但审查目的是协助生产 者改进工作。