您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 质量控制/管理 > 软件质量管理-第三章
第三章软件评审目录一、评审的基础知识–评审的定义–评审目的–评审的必要性–评审的分类–评审方式–评审结果–评审中存在的误区二、研究室的评审过程–评审计划–评审准备–评审会议及纪律–评审需要注意的问题–评审结论–评审表格介绍–评审的验证三、评审结项后新闻稿的撰写四、案例分析一、评审的基础知识问题一:什么是评审?评审的定义•Review(IEEEStd1028-1988)isanevaluationofsoftwareelementorprojectstatustoascertaindiscrepanciesfromplannedresultsandtorecommendimprovement.评审是对软件元素或者项目状态的一种评估手段,以确定其是否与计划的结果保持一致,并使其得到改进。•verifieswhethertheworkproductcorrectlysatisfiesthespecificationsfoundinanypredecessorworkproduct,suchasrequirementsordesigndocuments检验工作产品是否正确的满足了以往的工作产品中建立的规范,如需求或设计文档。•评审是指进行软件产品验证的活动,其目的是为了及早和高效地从软件工作产品中识别并消除缺陷。•评审会议重点在于确定产品的缺陷而不是如何解决问题。在会议结束之后,软件产品的生产者依据同行评审记录修正软件产品缺陷,然后由同行评审负责人确认缺陷的修正。•通过评审,可以将问题记录下来,使得具有历史可追溯性。评审目的评审的必要性•从技术角度进行的审查是保证软件质量的重要措施,由于人的认识不可能百分之百地符合客观实际,因此生命周期每个阶段的工作中都可能发生错误。由于前一阶段的成果是后一阶段工作的基础,前一阶段的错误自然会导致后一阶段的工作结果中有相应的错误,而且错误会积累起来,如下图所示。原始要求正确的规格说明错误的规格说明需求分析设计正确的设计错误的设计对错误说明的设计编码正确编码错误编码对错误设计的编码对错误说明的编码测试正确功能可改正的错误不可改正的错误潜伏的错误不完善的软件产品问题二:我们所描述的评审与技术评审一样吗?如果不一样,有什么区别?与技术评审不同,评审的对象一般是部分软件工作产品,其重点在于发现软件工作产品中的缺陷。参会者为和生产者在被评审的软件工作产品上有相同的开发经验和知识的人员。一般来讲,不建议管理者作为同行参与同行评审,也不应使用同行评审的结果去评价产品生产者。与技术评审的区别评审的分类•一般来说,评审(PeerReview)包括下面几种:检视(Inspection)团队评审(TeamReview/TechnicalReview)走查(WalkThrough)结对编程(PairProgramming)同行检查(PeerDeskCheck)特别检查(AdhocReview)评审方法间的区别—各种评审的正式程度最正式最随意检视团队评审走查结对编程同行检查特别检查评审方法间的区别所有的评审活动都是下列活动的组合:•计划•研究评审对象•举行评审会议•修正错误•确认修正评审种类计划准备会议修正确认检视有有有有有团队评审有有有有有走查有无有有无结对编程有无持续的进行有有同行检查无有可能会有有无特别检查无无有有无评审方式会议评审与邮件评审•会议评审就是组织内外的专家召开评审会议,根据评审的内容和要求进行讨论、分析并就最终结果达成一致的评审方式。软件需求、软件设计、测试大纲需要进行会议评审。•邮件评审是通过发送邮件给项目相关人员进行的评审方式。项目开发计划等需要邮件评审评审的结果•评审结果一般有条件通过、通过、不通过这几种,如果是不通过,还要再次评审,如果是有条件通过,则需要说明什么条件(比如修改某某东西),下次就不用再开评审会了,作者修改完成后,发邮件给相关人员,多长时间内评审员要使用邮件回复评审意见,由组织者负责收集。选择正确的评审方法选择评审方法最有效的标准是:对于最可能产生风险的工作成果,要采用最正式的评审方法。对于需求分析报告,因为它的不准确和不完善会给软件的后期开发带来极大的风险,所以必须要采用最正式的评审方法,如检视或者团队评审。又如,核心代码的失效也会带来很严重的后果,所以也应该采用检视或者团队评审的方法进行评审,而一般的代码,采用同行检查或者特别检查就可以满足要求了。误区一:评审参与者不了解评审过程如果评审参与者不了解整个的评审过程,就会有一种自然的抗拒情绪,因为大家看不到做这件事情的效果,感觉到很迷茫,这样会严重的影响大家参与评审的积极性。评审中的误区误区二:评审人员评论开发人员,而不是产品评审的主要目的是发现产品中的问题,而不是根据产品来评价开发人员的水平。但是往往会出现把产品质量和开发人员水平联系起来的事情,于是评审变了“味”,变成了“批斗大会”,极大的打击了开发人员的自尊心,以至严重的影响了评审的效果。误区三:评审没有被安排进入项目计划参与评审需要投入大量的时间和精力,应该被安排进入项目计划中。但是现实的情况往往是,评审变成了“义务工”,参与评审的人员必须加班加点才能完成评审任务。如此一来,出现评审人员对评审对象不了解的情况也就不足为奇了。误区四:评审会议变成了问题解决方案讨论会评审会议主要的目的是发现问题,而不是解决问题,问题的解决是评审会议之后需要做的事情。但是,由于开发人员对技术的追求,评审会议往往变成了问题研讨会,大量的占用了评审会议的时间,导致大量评审内容被忽略,留下无数的隐患。误区五:评审人员事先对评审材料没有足够了解任何一份评审材料都是他人智慧和心血的结晶,需要花足够的时间去了解、熟悉和思考。只有这样,才能在评审会议上发现有价值的深层次问题。在很多的评审中,评审人员因为各种的原因,在评审会议之前对评审材料没有足够的了解,于是出现了评审会议变成了技术报告的怪现象。二、研究室的评审过程岗位及职责•项目组负责人:提交《项目开发计划》,计划各个阶段进行评审的时间、评审方式、评审组成员,组织项目组成员解决评审提出的问题。•被评审产品作者:提交被评审产品,负责对《评审意见表》中提出的问题进行反馈,在评审会上进行项目陈述,解决评审提出的问题。•评审组成员:提交《评审意见表》,在评审会上发表意见。•评审组长:负责评审策划、评审准备、主持评审以及评审后续工作。•会议记录者:负责记录、整理并提交会议记录。•SQA:主要职责为审核整个评审活动。评审计划•项目负责人在提交的《项目开发计划》中,要指明项目各个阶段的评审计划。具体内容包括:各个阶段评审时间、评审方式、评审组成员等。•SQA在其提交的《质量保证计划》中,应根据《项目开发计划》中描述的各个阶段评审计划,制定相应的评审检查点。评审准备1、组建评审组•项目组提出评审组长和评审组成员名单的建议,质量组根据项目组的建议,与相关部门或人员(如外项负责人)进行协商确定。•评审组成员一般包括:室主任、被评审产品项目组负责人(项目组负责人非被评审产品作者的情况)、与该项目有关的研究室成员、质量保证人员、测试人员、前一阶段技术骨干、后一阶段技术骨干等。2、提交评审材料•被评审产品作者需要准备好待评审的产品、评审意见表和检查表。•待评审的产品可以是需求规格说明书、设计说明书、代码、测试大纲等。•评审意见表。•检查表随评审对象的不同而不同,分为:需求规格说明书检查表、设计说明书检查表、代码检查表、测试大纲检查表四种。•被评审产品作者将待评审产品以邮件的方式发送给评审组长,评审组长将收到的待评审产品附上评审意见表和检查表,以邮件方式发送给所有评审组成员。3、评审意见的处理•评审组成员收到评审材料后,审查待评审产品,填写评审意见表。并在2工作日内,将评审意见表以邮件的方式发送给被评审产品作者。•被评审产品作者解决评审提出的问题,修改被评审产品并填写评审意见表的“处理办法”一栏,在2工作日内以邮件的方式回复给相应的评审组成员。•评审组成员根据修改后的被评审产品和项目组填写的“处理办法”进行反馈,填写“是否已改正”一栏,在1工作日内以邮件的方式将反馈后的评审意见表发送给被评审产品作者、评审组长、SQA人员。•评审组长对评审意见表进行汇总,并分析各评审组成员的意见,可能有如下几种情况:如果意见基本一致,或问题比较明确并已得到解决时,可与质量组协商决定采用会签评审方式,直接形成评审结论;如果存在一些需要会议讨论的问题,则采用会议评审方式;如果存在的问题数目很多达不到会议评审的条件,则评审组长需督促被评审产品作者进一步修改评审材料,直到符合上述两种情况为止。•对于直接形成评审结论的情况,应将评审结论以邮件方式通知所有的评审组成员以及被评审产品作者;对于采用会议评审的情况,需要继续下面的过程。4、指派会议记录者•项目组负责人指派会议记录者,会议记录者一般由项目组成员担当。•会议记录内容应该包括:被评审的软件工作产品的标识;软件工作产品的规模;评审组的规模和组成;每个评审员的准备时间;评审会议的时间长短;发现和改正的缺陷的种类和数目;返工工作量等。•会议议程以时间的先后顺序,将整个会议分为多个阶段。需要记录会议各个阶段的主要议题、发言人、使用的主要文档、阶段起止时间。•会议总结要包含两点主要内容:首先是会议各主要成员所达成一致的结论和决议,其次是议而未决的事项。•会议总结同时要明确出待解决问题的提出者和指派的主要负责人,便于日后进行问题追踪。•最后要指出本次会议的缺陷和限制,作为今后会议改进的参考,使会议过程朝着更高效、更有意义和更规范的方向改进。•参见《会议记录编写指南》。注意:1.要记录围绕中心议题展开的有关活动,会议讨论、争论的焦点及其各方的主要见解,权威人士或代表人物的言论,会议开始时的定调性言论和结束前的总结性言论,对会议产生较大影响的其他言论或活动等。2.对于会议的一般性内容,可以有重点地、扼要地记录,不必“有闻必录”。所谓重点、要点,是指发言人的基本观点和主要事实、结论。对于特别重要的内容或者特别重要的发言,一定要作详细记录。5、评审组长发出评审会议通知•评审组长与参加评审会的人员商定评审会议时间,通知综合部预订会议室。在评审会时间地点确定后,评审组长要以邮件的方式向所有参加评审会的人员发出评审会议通知。6、参加评审会人员确认•参加评审会人员在接收到评审组长发出的评审会议通知后,需要向评审组长进行确认。可以采用邮件、BQQ或口头确认等方式。召开评审会议•评审组长宣布评审会议开始。•评审会议由评审组长主持,首先要说明评审的目的、要求和评审过程。•被评审产品作者陈述被评审产品内容。在陈述过程中可以穿插提问。•评审组成员和项目组成员就发现的问题展开讨论。•评审组长对会议进行总结。•评审组长总结评审发现的问题,并将这些问题汇总到新的评审意见表中去。评审会后由被评审产品作者、项目组负责人指定的其他相关人员对评审意见表中的问题进行适当处理。•产生评审结果。•评审组成员以投票的方式,产生评审结果。评审结果由评审组长宣布,分为:通过、修改后通过、不通过三种。对于不通过的情况,还需要在日后重新召开评审会议。•会议记录者要对整个会议过程进行详细的记录,可以参见《会议记录编写指南》。会议纪律1、不要迟到,到场人员都需要在签到表上进行签字。如有特殊原因不能参加会议需要事先向组长请假。2、不能无故不出席会议。3、开会时,不能喧哗,有意见者逐一提出,保证会议进行畅通。4、不要在会议室接听电话。5、不要在会议期间吃东西。6、不要在会议期间闲聊。7、不要看与会议无关的资料。评审时还需要注意以下几个问题•人员方面可以少而精,一般是3-7人。人员的选择上,尽可能找到合适的评审人员。•评审会是为了发现被评审产品的问题,要始终围绕着存在什么问题,而不是去追究责任人。评审工作只对事,不对人。•评审会议上不应讨论发现的问题如何解决,以提高评审会的工作效率。发现的问题如何解决是评审会后的事。•评审组成员会前多做准备,多熟悉材料,可以减少陈述的时间。•评审组长要维持会议程序,尽可能不要离题、转移话题
本文标题:软件质量管理-第三章
链接地址:https://www.777doc.com/doc-6031405 .html