软件同级评审.pptVIP

软件同级评审 Peer Reviews In Software 同级评审是什么 由生产产品的作者以外的其他人检查工作产品，发现缺陷并寻找改进的契机 关注内在质量 是一种质量保证方法 是一种技术实践过程 是一种社会交互过程 SW-CMM 3级的一个关键过程域（KPA） CMMI 3级“验证”过程域的一个特定目标 同级评审的目的 是什么 发现缺陷，寻找改进契机 帮助作者设计出高质量的可交付产品 不是什么 评价作者的能力或表现 绩效评估的依据 同级评审的效果 HP：审查的投资回报率为10:1，每年节省21.4M$，上市时间缩短18个月 贝尔实验室：错误发现的费用降低到1/10，质量提高10倍 IBM：1h审查 = 20h测试 其它效果 在项目成员间传播知识 建立共同的期望，发现假设，建立对产品的一致认识 有助于开发简单的易于理解的产品，减少维护和改进的成本 有助于建立合作精神 人们为什么不做/不愿做评审 不理解、不知道如何做 认为测试比人工检查更为有效 没有时间作评审 我的工作不需要评审 过多地将个人价值与设计工作联系在一起 同级评审的文化障碍 两个极端 变懒了 想在交给别人评审前使得产品尽善尽美 作者与评审员 作者必须信任和尊重评审员，并接受其意见 评审员必须尊重作者的技能和辛勤劳动 管理者对评审的态度 支持评审，并为其提供必要的资源 决不要根据评审结果去评估个人业绩 应该评审哪些内容 所有工作成果都应该得到评审 需求规格说明 项目章程 项目计划 体系结构描述 用户界面设计及原型 源代码 测试计划、方案 用户手册 正式和非正式评审 审查：Inspection 1970年由 Michael Fagan@IBM 提出 最正式、最严密的一种评审技术 被认为是软件业中最实用的一种方法 被认为是发现软件错误最有效的方法 审查中的角色 作者：被审查产品的创建者 评审组长：与作者一起制定计划，组织和主持评审会议，完成评审报告 读者：在会议期间向其他参与者描述审查材料 记录者：记录会议中发现的缺陷 评审员 验证者：检查返工结果 小组评审：Team Review 由一组有资格的人来判断产品是否实用，并找出产品没有达到规范要求的地方 有计划的，结构化的 比起审查，有些角色和步骤被简化或省略了，一些限制也被放开了 作者可以作为评审组长 读者被省略 效率是审查的一半到2/3 适用于不需要严格审查过程的工作产品 走查：Walkthrough 有产品的作者将该产品向一组同时介绍，并希望他们给出意见 作者起主导作用 基本上是为了满足作者的需要 通常没有明确的计划 适用范围： 产品维护期的修改 设计 测试某种想法 评估测试文档：通过测试案例引导团队对系统在特定条件下如何运行达成共识 结对编程：Pair Programming 有两个开发者在同一台计算机上同时编写程序 无计划，无结构 利于交流 允许对每个人的观点进行持续的、非正式的评审 缺乏来自编程者以外的其他人的想法 同级桌查：Peer Deskcheck 除作者以外，只有一个人对工作产品进行检查 评审效果完全依赖于评审者本身的知识、技能和自律 作者对评审进程几乎一无所知 双人审查：两个人坐在一起进行评审，评审员同时充当读者的角色； 轮查：Passaround 又称为分配审查，是一种由多人组成的并行同级审查 由作者将工作副本发给几位评审员，搜集他们的意见 对比同级桌查： 反馈可能会及时一些 评审效果可能会好一些 临时评审：Ad-hoc Review 最不正式的一种评审 评审方法的选择 正式与非正式评审相结合 早期使用非正式评审迅速发现大量错误 后期使用正式评审来把关 80%的错误集中于20%的模块 对于复杂模块，采用正式评审 在非正式评审过程中发现问题较多的模块，应该进行正式评审 成本 一些指导原则 作为作者，应该保持开放的心态，愿意接受别人的改进意见，避免事事争论； 作为评审者，应该记住这并不是要你去显示你比作者更优秀 评审小组通常在3-7人 在评审期间应该努力去发现问题，而不是解决问题 会议应限制在两小时以内 正式评审之前要做好准备 * * * * 最正式 最不正式 审查 小组评审 走查 结对编程 同级桌查、轮查 临时评审 * *