《软件工程-实践者的研究方法》chapter-12-cn-评审技术

TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitionersApproach,7/e(McGraw-Hill,2009).Slidescopyright2009byRogerPressman.,1,第十二章,评审技术,SlideSettoaccompanySoftwareEngineering:APractitionersApproach,7/ebyRogerS.PressmanSlidescopyright1996,2001,2005,2009byRogerS.PressmanFornon-profiteducationaluseonlyMaybereproducedONLYforstudentuseattheuniversitylevelwhenusedinconjunctionwithSoftwareEngineering:APractitionersApproach,7/e.Anyotherreproductionoruseisprohibitedwithouttheexpresswrittenpermissionoftheauthor.AllcopyrightinformationMUSTappeariftheseslidesarepostedonawebsiteforstudentuse.,评审,ThesecoursewarematerialsaretobeusedinconjunctionwithSoftwareEngineering:APractitionersApproach,6/eandareprovidedwithpermissionbyR.S.Pressman&Associates,Inc.,copyright1996,2001,2005,2,.没有特别的原因说明为什么你的朋友和同事不能成为你最严格的批评人,JerryWeinberg,什么是评审?,由技术人员领导，并面向技术人员的一个会议在软件工程过程中，对一个工作产品的技术评估一种软件质量保证机制一个培训园地,ThesecoursewarematerialsaretobeusedinconjunctionwithSoftwareEngineering:APractitionersApproach,6/eandareprovidedwithpermissionbyR.S.Pressman&Associates,Inc.,copyright1996,2001,2005,3,评审不是,项目总结和进度评估一个信息发布会议对人员的评估,ThesecoursewarematerialsaretobeusedinconjunctionwithSoftwareEngineering:APractitionersApproach,6/eandareprovidedwithpermissionbyR.S.Pressman&Associates,Inc.,copyright1996,2001,2005,4,WhatDoWeLookFor?,ErrorsanddefectsErroraqualityproblemfoundbeforethesoftwareisreleasedtoendusersDefectaqualityproblemfoundonlyafterthesoftwarehasbeenreleasedtoend-usersWemakethisdistinctionbecauseerrorsanddefectshaveverydifferenteconomic,business,psychological,andhumanimpactHowever,thetemporaldistinctionmadebetweenerrorsanddefectsinthisbookisnotmainstreamthinking,TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitionersApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.,5,软件缺陷对成本的影响,在软件过程的环境中，术语缺陷(defect)和故障(fault)是同义词，两者都是指在软件发布给最终用户(或软件过程内其他框架活动)后发现的质量问题。术语错误(error)来描绘在在软件发布给最终用户(或软件过程内其他框架活动)之前软件工程师(或其他人)发现的质量问题。正式技术评审的主要目标是在软件过程中发现错误，以使它们不会在软件交付之后变成缺陷(fault)正式技术评审最明显的优点就是可以早些发现错误，以防止将错误传递到软件过程的后续阶段。,缺陷放大和消除,可以用“缺陷放大模型”来说明在软件工程过程的设计和编码活动中错误的产生和检测。该模型如下图所示：,TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitionersApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.,7,Errorspassedthrough,Amplifiederrors1:x,Newlygeneratederrors,Developmentstep,ErrorsfromPreviousstep,ErrorspassedTonextstep,Defects,Detection,PercentEfficiency,DefectAmplification,AdefectamplificationmodelIBM81canbeusedtoillustratethegenerationanddetectionoferrorsduringthedesignandcodegenerationactionsofasoftwareprocess.,TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitionersApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.,8,Errorspassedthrough,Amplifiederrors1:x,Newlygeneratederrors,Developmentstep,ErrorsfromPreviousstep,ErrorspassedTonextstep,Defects,Detection,PercentEfficiency,DefectAmplification,IntheexampleprovidedinSEPA,Section15.2,asoftwareprocessthatdoesNOTincludereviews,yields94errorsatthebeginningoftestingandReleases12latentdefectstothefieldasoftwareprocessthatdoesincludereviews,yields24errorsatthebeginningoftestingandreleases3latentdefectstothefieldAcostanalysisindicatesthattheprocesswithNOreviewscostsapproximately3timesmorethantheprocesswithreviews,takingthecostofcorrectingthelatentdefectsintoaccount,TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitionersApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.,9,评审度量及其应用,软件工程组织要定义一套可以用来评估其工作效率的度量来理解每项活动的有效性。可以为所进行的每项评审收集以下评审度量数据：准备工作量Ep在实际评审会议之前评审一个工作产品所需的工作量（单位：人时）。评估工作量Ea实际评审工作中所花费的工作量(单位：人时)。返工工作量Er修改评审期间发现的错误所用的工作量(单位：人时)。工作产品规模WPS被评审的工作产品规模的衡量(例如UML模型的数量、文档的页数或代码行数)。发现的次要错误Errminor发现的可以归为次要错误的数量（要求少于预定的改错工作量）。发现的主要错误Errmajor发现的可以归为主要错误的数量（要求多于预定的改错工作量）。通过将所评审的工作产品类型与所收集的度量数据相关联，这些度量数据可以进一步细化。,Metrics,Preparationeffort,Eptheeffort(inperson-hours)requiredtoreviewaworkproductpriortotheactualreviewmeetingAssessmenteffort,Eatheeffort(inperson-hours)thatisexpendingduringtheactualreviewReworkeffort,Ertheeffort(inperson-hours)thatisdedicatedtothecorrectionofthoseerrorsuncoveredduringthereviewWorkproductsize,WPSameasureofthesizeoftheworkproductthathasbeenreviewed(e.g.,thenumberofUMLmodels,orthenumberofdocumentpages,orthenumberoflinesofcode)Minorerrorsfound,Errminorthenumberoferrorsfoundthatcanbecategorizedasminor(requiringlessthansomepre-specifiedefforttocorrect)Majorerrorsfound,Errmajorthenumberoferrorsfoundthatcanbecategorizedasmajor(requiringmorethansomepre-specifiedefforttocorrect),TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitionersApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.,11,AnExampleI,Ifpasthistoryindicatesthattheaveragedefectdensityforarequirementsmodelis0.6errorsperpage,andanewrequirementmodelis32pageslong,aroughestimatesuggeststhatyoursoftwareteamwillfindabout19or20errorsduringthereviewofthedocument.Ifyoufindonly6errors,youvedoneanextremelygoodjobindevelopingtherequirementsmodeloryourreviewapproachwasnotthoroughenough.,TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitionersApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.,12,AnExampleII,Theeffortrequiredtocorrectaminormodelerror(immediatelyafterthereview)wasfoundtorequire4person-hours.Theeffortrequiredforamajorrequirementerrorwasfoundtobe18person-hours.Examiningthereviewdatacollected,youfindthatminorerrorsoccurabout6timesmorefrequentlythanmajorerrors.Therefore,youcanestimatethattheaverageefforttofindandcorrectarequirementserrorduringreviewisabout6person-hours.Requirementsrelatederrorsuncoveredduringtestingrequireanaverageof45person-hourstofindandcorrect.Usingtheaveragesnoted,weget:Effortsavedpererror=EtestingEreviews456=30person-hours/errorSince22errorswerefoundduringthereviewoftherequirementsmodel,asavingofabout660person-hoursoftestingeffortwouldbeachieved.Andthatsjustforrequirements-relatederrors.,TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitionersApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.,13,评审的成本效益,有评审和没有评审时花费的工作量,TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitionersApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.,14,withreviews,参考模型,TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitionersApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.,15,非正式评审,非正式评审包括:与同事就软件工程产品进行的简单桌面检查以评审一个工作产品为目的的临时会议结对编程评审两人一起工作和分享思想共同解决复杂的软件开发。他们不断进行检查彼此的产品，从而以最有效的形式尽早去除缺陷。如果作为结对编程的结果生产出的工作产品的质量明显优于单个人的工作，在质量方面的节约，足以弥补结对编程带来的“冗余”。,TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitionersApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.,16,InformalReviews,Informalreviewsinclude:asimpledeskcheckofasoftwareengineeringworkproductwithacolleagueacasualmeeting(involvingmorethan2people)forthepurposeofreviewingaworkproduct,orthereview-orientedaspectsofpairprogrammingpairprogrammingencouragescontinuousreviewasaworkproduct(designorcode)iscreated.Thebenefitisimmediatediscoveryoferrorsandbetterworkproductqualityasaconsequence.,TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitionersApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.,17,正式技术评审,正式技术评审（FTR）是一种由软件工程师(以及其他人)进行的软件质量控制活动。FTR的目标是：发现软件的任何一种表示形式中的功能、逻辑或实现上的错误；验证评审中的软件是否满足其需求；保证软件的表示符合预先指定的标准；获得以统一的方式开发的软件；使项目更易于管理。FTR实际上是一类评审方式，包括走查(walkthrough)和审查(inspection)。每次FTR都是以会议形式进行的，只有经过适当的计划、控制和参与，FTR才能获得成功。,TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitionersApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.,18,FormalTechnicalReviews,TheobjectivesofanFTRare:touncovererrorsinfunction,logic,orimplementationforanyrepresentationofthesoftwaretoverifythatthesoftwareunderreviewmeetsitsrequirementstoensurethatthesoftwarehasbeenrepresentedaccordingtopredefinedstandardstoachievesoftwarethatisdevelopedinauniformmannertomakeprojectsmoremanageableTheFTRisactuallyaclassofreviewsthatincludeswalkthroughsandinspections.,TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitionersApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.,19,评审会议,评审会（通常）应该由3-5人参加应该提前进行准备，但是占用每人的工作时间应该不超过2小时评审会的时间应该少于2小时FTR应该关注的是整个软件中的某个特定部分（例如：只走查各个构建或者一小部分构建，不要试图评审整个设计）,TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitionersApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.,20,TheReviewMeeting,Betweenthreeandfivepeople(typically)shouldbeinvolvedinthereview.Advancepreparationshouldoccurbutshouldrequirenomorethantwohoursofworkforeachperson.Thedurationofthereviewmeetingshouldbelessthantwohours.Focusisonaworkproduct(e.g.,aportionofarequirementsmodel,adetailedcomponentdesign,sourcecodeforacomponent),TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitionersApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.,21,参与人员,ThesecoursewarematerialsaretobeusedinconjunctionwithSoftwareEngineering:APractitionersApproach,6/eandareprovidedwithpermissionbyR.S.Pressman&Associates,Inc.,copyright1996,2001,2005,22,评审会主席,生产者,记录员,复审者,(SQA),维护人员,用户代表,ThePlayers,ProducertheindividualwhohasdevelopedtheworkproductinformstheprojectleaderthattheworkproductiscompleteandthatareviewisrequiredReviewleaderevaluatestheproductforreadiness,generatescopiesofproductmaterials,anddistributesthemtotwoorthreereviewersforadvancepreparation.Reviewer(s)expectedtospendbetweenoneandtwohoursreviewingtheproduct,makingnotes,andotherwisebecomingfamiliarwiththework.Recorderreviewerwhorecords(inwriting)allimportantissuesraisedduringthereview.,TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitionersApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.,23,评审会议参与人员,评审会议由评审会主席、所有评审员和开发人员参加。其中一位评审员还充当记录员的角色，负责记录在评审过程中发现的所有重要问题。FTR一般从介绍会议日程并由开发人员做简单的介绍开始。然后由开发人员“走查”该工作产品，并对材料做出解释，而评审员则根据预先的准备提出问题。当发现了明确的问题或错误时，记录员逐一加以记录。,ThesecoursewarematerialsaretobeusedinconjunctionwithSoftwareEngineering:APractitionersApproach,6/eandareprovidedwithpermissionbyR.S.Pressman&Associates,Inc.,copyright1996,2001,2005,24,评审指导原则,评审工作产品，而不是评审开发人员。制定并遵守日程表。限制争论和辩驳。要阐明问题，但是不要试图解决所有记录的问题。做笔记。限制参与者人数。为每个将要评审的工作产品建立检查清单。为FTR分配资源和时间。对所有评审员进行有意义的培训。评审以前所做的评审。,TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitionersApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.,25,ConductingtheReview,Reviewtheproduct,nottheproducer.Setanagendaandmaintainit.Limitdebateandrebuttal.Enunciateproblemareas,butdontattempttosolveeveryproblemnoted.Takewrittennotes.Limitthenumberofparticipantsandinsistuponadvancepreparation.Developachecklistforeachproductthatislikelytobereviewed.AllocateresourcesandscheduletimeforFTRs.Conductmeaningfultrainingforallreviewers.Reviewyourearlyreviews.,TheseslidesaredesignedtoaccompanySoftwareEngineering:APractitionersApproach,7/e(McGraw-Hill2009).Slidescopyright2009byRogerPressman.,26,指导评审,ThesecoursewarematerialsaretobeusedinconjunctionwithSoftwareEngineering:APractitionersApproach,6/eandareprovidedwithpermissionbyR.S.Pressman&Associates,Inc.,copyright1996,2001,2005,27,准备好在评审之前评估这个产品,评审产品，而不是生产者,语音轻柔，问问题而不是指责,坚守评审日程,提出问题，而不是解决他们,避免讨论其他问题坚持技术正确性,有计划的评审,记录以及上报所有评审结果,1.,2.,3.,4.,5.,6.,7.,8.,评审选项矩阵,Thesecoursewarematerialsaretobeusedinc