近身战兵txt下载何老狐:软件评审

来源:百度文库 编辑:九乡新闻网 时间:2020/10/22 06:29:31

  软件评审并不是在软件开发完毕后进行评审,而是在软件开发的各个阶段都要进行评审。因为在软件开发的各个阶段都可能产生错误,如果这些错误不及时发现并纠正,会不断地扩大,最后可能导致我们开发结果不可控。

  软件评审是相当重要的工作,也是目前国内开发最不重视的工作。 

(1)评审目标 

  。发现任何形式表现的软件功能、逻辑或实现方面的错误;  
  。通过评审验证软件的需求;  
  。保证软件按预先定义的标准表示;  
  。已获得的软件是以统一的方式开发的;  
  。使项目更容易管理。 

(2)评审过程 

  A、召开评审会议:一般应有公司评审委员会组织,会前每个参加者做好准备。 

  B、会议结束后必需有结果性东西:接受该产品,不需做修改;由于错误严重,拒绝接受;暂时接受该产品。 

  C、评审报告与记录;所提出的问题都要进行记录,在评审会结束前产生一个评审问题表,另外必须完成评审简要报告。 

(3)评审准则 

  。评审产品,而不是评审设计者(不能使设计者有任何压力);  
  。会场要有良好的气氛;  
  。建立议事日程并维持它(会议不能脱离主题);  
  。限制争论与反驳(评审会不是为了解决问题,而是为了发现问题;  
  。指明问题范围,而不是解决提到的问题;  
  。展示记录(最好有黑板,将问题随时写在黑板上);  
  。限制会议人数和坚持会前准备工作;  
  。对每个被评审的产品要尽力评审清单(帮助评审人员思考);  
  。对每个正式技术评审分配资源和时间进度表;  
  。对全部评审人员进行必要的培训;  
  。及早地对自己地评审做评审(对评审准则的评审)。


评审会议流程一般采取以下几个步骤:评审会议的准备、评审会议的召开、评审会议的跟踪三大环节。
  
  一、 评审会议的准备

  会议的发起人召集会议,发出评审通知(评审内容、会议时间、会议地点、参加人员等),并且将相关待评审的相关资料也发送给参加会议的评委;主要的目的有两个:第一、让参加会议的人员对会议的内容有一定的了解,在会议前做好准备,避免盲目的参加会议而浪费自己和其他人的时间;第二、如果该评委在会议时间有其他紧急的事情,可以及早反馈给会议召集人,必便召集人重新确定评委或者评审会议改期召开。
  
  二、 评审会议的召开

  一般情况下,确定一个会议主持人;其主要的职责是控制会议的进度、时间、协调会议中出现的偏差。
  
  对于待评审的工作产品由其生产者采用“走读”的形式进行讲解,在讲解的过程中回答评委提出的问题。
  
  会议记录人主要是记录会议中发现的所有问题,方便会后的修改完善。
  
  SQA人员参加会议主要的关注点在于对照SQA的检查表Checklist检查评审的流程是否符合规范。
  
  三、 评审会议的跟踪

  将记录的问题汇总到《评审记录表》,由项目组进行修改、完善;SQA监督所有问题是否封闭。

附录:
  
  (1) 列举重要工作产品评审的重点:
  
  A 计划的评审
  
  主要是关注的核心在于估计是否准确;人员安排是否合理;以上两个方面如果合理,项目的进度就不会出很大的问题。
  
  B 需求的评审
  
  主要关注需求来源、需求的准确性、需求的完整性,避免产生二义性;最好让测试人员和客户参加,以便让各角色达成共识。
  
  C 总体设计的评审
  
  在总体设计评审中,最好将已经评审通过的需求文档从配置管理库中提出,对照总体设计是否和需求一致;另外,技术领域专家参加评审还要关注于设计的合理性、可实现性以及完整性。
  
  D 代码评审
  
  由项目组内进行代码审核,主要关注代码的格式、整体逻辑、变量的命名、程序注释等表面的属性;至于运行质量应当放在单元测试中解决。
  
  E 管理性的评审
  
  管理性的评审一般放在里程碑、项目结束后进行。准备的资料包括前期工作的总结,是否按照计划执行、出现的问题的数目、解决了多少、未解决的问题、是否对后期有影响等。
  
  (2) 评审中应当把握的几个原则:
  
  A 评审工作产品,而不是评审生产者
  
  评审涉及到别人和自我。如果进行的恰当,可以使所有参与者体会到温暖的成就感。如果不恰当,则可能陷入审问的气氛之中。应当温和的指出错误,会议的气氛应当是轻松和建设性的;不要试图贬低或者羞愧别人。主持人应当加以引导,以保证会议始终处于恰当的气氛和态度中,如果失去控制应立即休会。
  
  B 制定日程,并且遵守日程
  
  各中会议都有一个主要的缺点:放任自流。评审会议必须保证不要离题和按照计划进行。主持人要有维持会议的程序的责任,有人在转移话题的时候应当提醒。
  
  C 限制争论和辩驳
  
  评委提出问题时,未必所有人都能认同该问题的严重性或者能马上打成一直的意见。不要花费时间争论这一问题,应当记录在案,留会后讨论。

D 对各个问题发表见解,但是不要试图解决所有记录的问题
  
  评审会议不是解决问题的会议。问题的解决由生产者自己或者其他人的帮助下完成。问题的解决方案应当在会后进行。
  
  E 作书面笔记
  
  有时候让记录员在黑板上作笔记是个好主意,在记录的时候,评委可以推敲措词,确定问题的优先次序。
  
  F 限制参与人数,并且坚持事先做准备
  
  俩个人的脑袋好过一个,但是14个脑袋未必就好过4个。将评审涉及的人员数量保证保持在最小的值上。所有参与会议的人员要事先作好准备。
  
  G 为每个可能要评审的工作产品建立一个检查表
  
  检查表能帮助评审主持人组织会议,并帮助每个与会人员将注意力集中在重要问题上。
  
  H 为评审分配资源和时间
  
  评审要占项目组的资源和时间。所以,评审会议一定要作为软件工作活动的任务加以调度。可以在综合计划中考虑进去。
  
  I 对所有的评审者进行有意义的培训
  
  为了提高效率,所有参与评审会议的人都应当接受正式的培训。
  
  J 会议时间的控制
  

  为了提高效率,每次评审会议只评审一个工作产品,并且时间最长不能超过2个小时。所以要求,在评审准备时候各位评委事先作好准备。