软件技术评审PPT课件

软件技术评审BYPMT05V1.00Confidentialitylevel密级:（内部公开）部门:北研质量部日期:2005/06/01小游戏:找一找下面的图片有什么不同不要交流;限时:1分钟找到多少个不同点?!时间到不同点:共有10处课程目的了解业界软件技术评审方法掌握我司软件技术评审流程学习我司软件技术评审工具分享多年的实际应用开发经验课程主要内容软件技术评审方法IPD-CMM软件评审流程我司常用软件技术评审工具常见的软件技术评审的误区软件技术评审软件技术评审方法IPD-CMM软件技术评审流程华为常用软件技术评审工具常见的软件技术评审的误区软件技术评审方法软件技术评审的定义借助他人对软件交付物进行检查发现缺陷或获得改进优化的机会强有力的软件质量保证活动之一CMM中定义为PeerReview软件技术评审方法软件技术评审的意义降低返工（rework）的成本业界的一些数据：相对于通过review发现缺陷的rework成本，测试发现缺陷的rework成本是其14.5倍,而客户发现缺陷的rework成本是其68倍－－一家德国软件公司产品发布后发现缺陷的rework成本是在设计阶段的45倍Earlierwefindandcorrectdefects,Moremoneyandtimewewillsave软件技术评审方法常见的软件技术评审形式InspectionWalkthrough4EyesReview最正式的最不正式的Inspection4EyesReviewWalkthrough软件技术评审方法Inspection的基本特点定义质量目标由经过培训的团队参加由经过培训的组织者组织（作者不能是组织者）明确参加人员角色和职责有正式的文档规程引导向管理者上报review结果清晰的入口和出口条件对缺陷进行跟踪直至关闭记录过程和质量数据，并根据数据进行review流程和软件开发过程进行改进软件技术评审方法Walkthrough的基本特点没有明确的质量目标有正式的会议作者就是组织者作者就软件交付物对评审人进行讲解没有正式的文档规程引导不必向管理者上报review结果很少有正式的记录过程和质量数据，无法根据数据进行review流程和软件开发过程进行改进软件技术评审方法4EyesReview的基本特点临时的、事件驱动的仅仅是为了找出一个bug更多的是团队协助为了作者发现问题提供了另外一种角度最不正式的review软件技术评审方法3种review形式的比较－1评审类型评审的活动准备会议纠正验证Inspection●●●●●Walkthrough●　●●　4EyesReview　　●●　软件技术评审方法3种review形式的比较－2要素InspectionWalkthrough4EyesReview组织者组织者作者无讲解员专门的讲解员作者无粒度smallchunks由作者自己判断一段代码、一段文字使用记录员YESMaybe无遵循规程YESMaybe无定义参加人员角色YESNONO使用checklistYESNONO数据收集和分析YESNONO产品评价决策YESNONO软件技术评审方法选择合适的review形式基于风险考虑：交付物存在缺陷的可能性以及如果存在缺陷的影响用最正式的形式去review高风险的交付物用最经济的形式去review低风险的交付物用收集数据来判断对某一工作产品，哪种review形式最有效软件技术评审方法哪些因素会因增加风险指数而需要特别关注复杂的逻辑或算法而其必须精确和最优过度的开发进度压力开发人员技能缺少足够培训或经验产品的关键、基础模块可能被重用的模块或作为模板的模块有众多接口的模块软件技术评审方法度量分析缺陷预防软件技术评审方法更重要的是形成一种文化－－拥抱评审，把它作为改进软件质量、提高生产率以及加快个人学习进度的强有力的方法软件技术评审方法IPD-CMM软件技术评审流程华为常用软件技术评审工具常见的软件技术评审的误区软件技术评审IPD-CMM软件技术评审流程角色项目经理作者讲解员REVIEW人员记录员组织者可兼任不可兼任各司其职IPD-CMM软件技术评审流程步骤介绍会议？1.计划阶段3.准备阶段2.介绍会议YN7.跟踪阶段6.返工阶段YN第三小时会议？4.Review会议5.第三小时会议入口准则出口准则计划阶段IPD-CMM软件技术评审流程代码：<=500行(NBNC)文档：<=40页Review资料内容太多时，应分成几次Review入口准则：？是否符合文档？是否已用工具检查工作产品名称角色名字Review会议召开的时间Review关注点项目经理指定组织者作者自检工作产品组织者规划本次Review检查入口准则准备Review包(工作产品/参考资料Review表单/查检表)指定Review人员（3-6人）组织者将Review包、Review通知单发给相关人员IPD-CMM软件技术评审流程项目准备.........项目计划................键入文本启动......作者组织者介绍REVIEW流程及相关要求Review人员向组织者提出申请组织者裁决是否召开介绍会议若召开则：介绍工作产品及相关资料介绍会议IPD-CMM软件技术评审流程准备阶段Review的对象是工作产品而不是作者Review工作要充分收到组织者发来的Review包审核工作产品、发现缺陷填写Review表单反馈Review表单给组织者Review人员检查Review表单裁决是否需要增加Review投入组织者IPD-CMM软件技术评审流程Review会议Review的对象是工作产品而不是作者关注于缺陷的发现而非解决缺陷属性有三种“严重”“一般”“提示”组织者召开Review会议讲解员讲解工作产品大家共同确认问题“Review表单中记录的问题”“会上发现的问题”当争执不下时组织者应做出裁决对已确认的问题进行分类组织者决定是否召开第三小时会议记录员记录所有的问题及分类，并发给组织者组织者更新Review表单IPD-CMM软件技术评审流程第三小时会议更新后的Review表单Review表单？组织者决定是否召开第三小时会议会上：大家对Review表单中未解决的问题给出决议大家对Review表单中已确认的问题讨论解决记录员进行记录组织者更新Review表单IPD-CMM软件技术评审流程返工Review表单更新后的工作产品更新后的Review表单作者修改BUG作者更新Review表单作者IPD-CMM软件技术评审流程跟踪收到Review表单和工作产品对照Review表单、验证工作产品中的缺陷更改正确若缺陷未修改正确，返回给作者继续修改更新Review表单、并分发给相关人员？出口准则是否满足缺陷修改正确Review表单更新并分发遗留缺陷/问题上报IPD-CMM软件技术评审流程职责：项目经理项目经理组织者Review人员挑选制定Review计划、明确日程选择合适的组织者和Review人员IPD-CMM软件技术评审流程职责：作者确保工作产品已准备好在介绍会议上讲解工作产品在Review会议结束后修改已确认的所有缺陷作者TypetextIPD-CMM软件技术评审流程职责：组织者1组织者确保入口准则得到满足键入文本键入文本键入文本键入文本键入文本键入文本确保Review流程是否得到遵循指明Review时的关注点确保所有Review人员已充分检视组织安排Review会议的后勤工作组织管理会议，以防无休止的争论裁决有异议的问题IPD-CMM软件技术评审流程职责：组织者2组织者确保Review进度得到控制确保团队关注于发现工作产品的问题而非作者的问题确保Review会议上发现问题而非解决问题确保所有缺陷得到分类整理IPD-CMM软件技术评审流程职责：组织者3组织者PM评审表单？确保所有缺陷得以修正确保跟踪阶段发现的新缺陷已记录到Review表单中所有遗留问题上报PMIPD-CMM软件技术评审流程职责：讲解员讲解员在Review会议上通过讲解来引导Review团队浏览工作产品。IPD-CMM软件技术评审流程职责：记录员记录员负责记录Review会议上的信息。IPD-CMM软件技术评审流程职责：review人员Review人员会议室寻找被Review工作产品中的缺陷参加Review会议如果需要，参加第三小时会议填写Review表单并上交IPD-CMM软件技术评审流程裁减原则对于变更发生后的工作产品Review该如何进行呢？CR的类型优化型增强型纠正型会议室“严重”“一般”“提示”直接召开Review会议项目经理指定一到两名人员跟踪不能裁剪不能裁剪可裁剪：可裁剪：IPD-CMM软件技术评审流程裁减原则项目工作产品是在其他项目工作产品上的增强和修改时，如果不对原工作产品进行Review，需要在PHB或偏差申请中描述，并标识相应风险。如果项目的工作产品是在其他项目的工作产品上增强和修改的，这种增强和修改是否需要对原工作产品Review？可裁剪：IPD-CMM软件技术评审流程北研所客户化的一些review流程制定组织者提前对评审对象进行分解，有针对性的分配给不同专家与评审专家沟通，获得。请用下面的作为通知发给相关人，记得每次评审的这个表格抄送给EPG和项目的QA。IPD-CMM软件技术评审流程北研所客户化的一些review流程制定评审后，组织者把每个评审专家的实际预审投入，发现的问题详细的记录在ReviewSummery表单中，发给EPG和项目QA，由他们对这次评审做个分析和评价。这可是天上掉馅饼，何乐不为呢？软件技术评审方法IPD-CMM软件技术评审流程华为常用软件技术评审工具常见的软件技术评审的误区软件技术评审华为常用软件技术评审工具IPD-CMMv3.0ReviewFormhttp://bjpal->IPD-CMM->ReviewQAM01F01－ReviewNoteReview通知单QAM01F03－PreReviewForm预审表单QAM01F04C－ReviewSummaryFormReview汇总表单QAM01C01－ReviewChecklistReview查检表华为常用软件技术评审工具CodeReviewToolDocumentReviewTool四象限分析法http://bjpal->工具数据库-->开发工具->ReviewTool软件技术评审方法IPD-CMM软件技术评审流程华为常用软件技术评审工具常见的软件技术评审的误区软件技术评审常见的软件技术评审的误区误区一：参与者不了解review流程症状:参与者对自己在review中的角色、职责以及如何进行review中的活动，各有各的理解；项目组成员对自己的产品哪些应该review、什么时候进行review、用什么样的review方法根本不清楚；一次review上，review太多的资料，结果却是两手空空....常见的软件技术评审的误区误区一：参与者不了解review流程措施:培训！培训将最好的团队建设活动，培训将能确保每个成员都能准确理解review的过程。一般而言4-8个小时的培训基本足够了；但对于正式review的组织者而言，可能要更多一些。培训内容的准则是遵循公司所制定的review规程。常见的软件技术评审的误区误区二：对人不对事症状:Review变成了一场人身攻击会、批斗会.挖苦作者的风格、嘲笑作者的技能。当作者感受到自己受到攻击，他（她）会开始对抗：拒绝配合；以后不愿意提交产品review；甚至寻求报复的机会。常见的软件技术评审的误区误区二：对人不对事措施:在进行review前，要强调review是发现产品的问题而不是对作者进行批斗。review不是给review专家一个机会展示自己比其他人有多聪明，而是要通过集体的智慧、观察力、经验来发现产品的缺陷，提高产品的质量。当你发现问题的时候，这样表达：“我没有发现这个地方的变量被初始化”也许比“你怎么忘记了把这个变量初始化了”要更好一些。常见的软件技术评审的误区误区三：没有计划症状:对于许多项目而言，review从来不会出现在项目WBS或进度安排中；即使项目计划上有，也仅仅是以里程碑的形式出现而不是任务；里程碑是一个以“zero-time”定义的。没有计划，导致当需要review专家参与的时候，review专家已经没有时间了，他已经安排其他事情了!常见的软件技术评审的误区误区三：没有计划措施:做好计划，以任务的形式将review体现到项目计划中。要估计出review专家个人准备的时间、review会议的时间、rework的时间。常见的软件技术评审的误区误区四：Review会议演变成问题解决会症状:开发人员天性都喜好解决问题，喜欢提出对问题的优雅的解决方案。但这并不是review会议所想要的。Review会议的目的是发现缺陷、确认问题。如果会议演变成问题解决会议，对产品的检验就嘎然而止；争论变得无休止；部分参与者变的无所适从。当意识到更应该去发现缺陷的时候，时间已经所剩无几...于是匆匆结束review，很多缺陷却还在“花丛中笑”.常见的软件技术评审的误区误区四：Review会议演变成问题解决会措施:开正式的Review会议的目的是对专家反馈的意见进行确认并试图发现更多的问题。正式的review会议之所以比非正式的更有效，是因为它有组织者；当review进展偏离的正常的轨道，组织者有责任及时把会议纠正到正常秩序来。一般而言，对问题的讨论是不可避免的，如果这个问题能在1－2分钟等讨论清楚，那么就讨论它；反之，还是把它放在会议之外解决吧。当然，可能会有这样的情况，某个缺陷很严重，严重到不把这个问题解决了，后面的review就无任何意义，那么就把它改成问题解决会议。常见的软件技术评审的误区误区五：Review专家还没有准备…症状:你早上8：45来到工位上打开Notes，收到一个加了"!"的邮件，通知你早上9：00到D304参加XXXXreview会议，并附件了10M的资料。你只有15分钟时间，你能review出问题来吗？你不了解项目的背景，不了项目的约束假设，不了解项目的关联，你即使参加了会议，就能发现问题了吗？常见的软件技术评审的误区误区五：Review专家还没有准备…措施:75％的缺陷都是在专家个人准备的时候发现的，这就是为什么组织者在开会前需要收集专家个人准备review的时间，以确定会议时候能进行。所以项目经理要做好项目计划，提前安排好review的个人准备时间。常见的软件技术评审的误区误区六：让不合适的人参加症状:如果让一个对产品、项目还不熟悉、技能还比较欠缺的人参与review，也许唯一收获就他通过review了解了产品，但对工作产品质量的提高却没有任何贡献。同样，高级经理的参与，也有可能导致比较差的review效果，因为如果作者感觉到经理仅仅是在数缺陷个数以对他进行评价的时候，作者就会变的犹豫，也有可能破坏同事之间的气氛。常见的软件技术评审的误区误区六：让不合适的人参加措施:一个review一般3－7人效率是最高的。review的专家应该包括工作产品的上下游的人。如：设计文档的review，就应该包括作者本人，需求文档的作者、编码的责任人、完成测试的责任人，也应该包括对该领域很熟悉的人。常见的软件技术评审的误区误区七：过多关注风格，忽略内容症状:如果当你浏览review发现的缺陷列表，发现大部分缺陷都是风格上的，那么你应该很紧张了：也许很多重要的、逻辑上、算法上的问题都被忽略了。常见的软件技术评审的误区误区七：过多关注风格，忽略内容措施:风格可以是缺陷，但不应该成为review发现缺陷的主体。作者要在写作之前，即可能接受相关培训，要尽量使用提供的模板；作者写完之后，要即可进行自检。常见的软件技术评审的误区走出误区走出自我对事不对人仅仅去发现问题，而不要试图去修改控制会议时间（<=2Hr.）避免纠缠风格问题，除非它真的影响你尽早的、经常的进行正式或非正式的review总结Wow!PeerReviewdefinitelyisoneofthemostpowerfulsoftwarequalitytoolsavailable.Iwouldneverworkinateamthatdidnotperformthem.Questions?写在最后在实际工作中，大家可以不断积累经验，指导自己的项目进行高效Review。运用之妙存乎一心小诗一首：你是风儿我是沙，你是蜜蜂我是花。你是梳子我是头发，你是牙膏我是牙刷。谢谢