评审技术.ppt

第十二章评审技术
技术工作需要评审正像铅笔需要橡皮:
人非圣贤,孰能无过。
软件评审
软件评审是软件过程中的“过滤器”。也就是说,在软件工程的不同阶段进行软件评审,可以起到发现错误和缺陷,进而消除它们的作用。
在软件工程过程中可以进行的评审有很多种,本章主要介绍技术评审。
软件缺陷
缺陷放大模型
由此可见,问题发现越早,解决问题的代价相对就越小,这是软件开发过程中的黄金法则。
评审度量及其应用
准备工作量Ep
评估工作量Ea
返工工作量Er
工作产品规模WPS
发现的次要错误Errminor
发现的主要错误Errmajor
总评审工作量Ereview=Ep+Ea+Er
发现的错误总数Errtot=Errminor+Errmajor
错误密度=Errtot/WPS
评审:正式程度
参考模型的每个特性有助于确定评审的正式程度
评审的正式度提高需当:
1、明确界定每位评审人员的不同职责
2、为评审进行充分的计划和准备
3、为评审定义了清晰的结构(包括任务和内部工作产品)
4、评审人员对所做修改的后续跟踪
评审
计划和筹备
个人角色
扮演
会议组织
修改和验证
非正式评审
非正式评审包括与同事就软件工程产品进行的简单桌面检查,以评审一个工作产品为目的的临时会议(涉及两人以上),或结对编程评审。
正式技术评审
正式技术评审(FTR)是一种由软件工程师(以及其他人)进行的软件质量控制活动。
FTR的目标:
1、发现软件的任何一种表示形式中的功能、逻辑或实现上的错误
2、验证评审中的软件是否满足其需求
3、保证软件的表示符合预先指定的标准
4、获得以统一的方式开发的软件
5、使项目更易于管理
评审会议
每个评审会议都应该遵守以下约束:
评审会(通常)应该由3~5人参加
应该提前进行准备,但是占用每人的工作时间应该不超过2小时
评审会的时间应该小于2小时
评审报告和记录保存
评审问题清单有两个作用:
1、标识产品中存在问题的区域
2、作为行动条目检查单以指导开发人员进行修改。
评审指导原则
评审工作产品,而不是评审开发人员
制定并遵守日程表
限制争论和辩驳
要阐明问题,但是不要试图解决所有记录的问题
做笔记
限制参与者人数
为每个将要评审的工作产品建立检查清单
为FTR分配资源和时间
对所有评审员进行有意义的培训
评审以前所做的评审