软件工程实践者的研究方法chapter12.ppt

These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,1,Chapter 12,Review Techniques,Slide Set to accompanySoftware Engineering:A Practitioners Approach,7/e by Roger S.PressmanSlides copyright 1996,2001,2005,2009 by Roger S.PressmanFor non-profit educational use onlyMay be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering:A Practitioners Approach,7/e.Any other reproduction or use is prohibited without the express written permission of the author.All copyright information MUST appear if these slides are posted on a website for student use.,羽猾荫舆膛鱼呼灸趣毗汇诸复透缕失独量羞饭痞拈突膝地钡街巢油愚缔缚软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,2,Reviews,.there is no particular reason,why your friend and colleague,cannot also be your sternest critic.,Jerry Weinberg,填砒陇曲押恋烦躇泪打舅拓焊驴斡调页馋万仟癌喀凋纵窥故帕趾锄舜歉方软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,3,What Are Reviews?,a meeting conducted by technical people for technical peoplea technical assessment of a work product created during the software engineering processa software quality assurance mechanisma training ground,笛君当酚尝液册屡洪枕烩啃龟央纺蔫渊攒摹糯毋窖免钙眉猪悸笆雕蚊狡句软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,4,What Reviews Are Not,A project summary or progress assessmentA meeting intended solely to impart informationA mechanism for political or personal reprisal!,莫峻晤痈规藏津痹巧霍棱抡餐幂喊颐聚澳酱舌楞普既彻汛霄赐检孰占挤拽软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,5,What Do We Look For?,Errors and defectsErrora quality problem found before the software is released to end usersDefecta quality problem found only after the software has been released to end-usersWe make this distinction because errors and defects have very different economic,business,psychological,and human impactHowever,the temporal distinction made between errors and defects in this book is not mainstream thinking,俞瑰肄该雄勉掉馆糠啸菌后即淘涣颈滔粟访辣吧次渍髓呕冤历跳谅擂辙程软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,6,Defect Amplification,A defect amplification model IBM81 can be used to illustrate the generation and detection of errors during the design and code generation actions of a software process.,Errors passed through,Amplified errors 1:x,Newly generated errors,Development step,Errors fromPrevious step,Errors passed To next step,Defects,Detection,PercentEfficiency,航败杠垄演冰谊渝批住梁舞翔凤昼孤捷糕钎器恤洪澡草锣迭狮啊欧咽淋暴软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,7,Defect Amplification,In the example provided in SEPA,Section 15.2,a software process that does NOT include reviews,yields 94 errors at the beginning of testing andReleases 12 latent defects to the fielda software process that does include reviews,yields 24 errors at the beginning of testing andreleases 3 latent defects to the fieldA cost analysis indicates that the process with NO reviews costs approximately 3 times more than the process with reviews,taking the cost of correcting the latent defects into account,泪鹊瞥滴卡吩剥眩擞炯群斯却读脯卤寻径恶澈泡侵油籽漓析虹颅拙锹膘汉软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,8,Metrics,The total review effort and the total number of errors discovered are defined as:Ereview=Ep+Ea+Er Errtot=Errminor+ErrmajorDefect density represents the errors found per unit of work product reviewed.Defect density=Errtot/WPSwhere,娶甜哨翌漏吸爽慨岗掌菊冤硕诡轰瑰窘烛苇噪狰帘滋榴炙瞪因豫篡镀茎奇软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,9,Metrics,Preparation effort,Epthe effort(in person-hours)required to review a work product prior to the actual review meetingAssessment effort,Ea the effort(in person-hours)that is expending during the actual reviewRework effort,Er the effort(in person-hours)that is dedicated to the correction of those errors uncovered during the reviewWork product size,WPSa measure of the size of the work product that has been reviewed(e.g.,the number of UML models,or the number of document pages,or the number of lines of code)Minor errors found,Errminorthe number of errors found that can be categorized as minor(requiring less than some pre-specified effort to correct)Major errors found,Errmajor the number of errors found that can be categorized as major(requiring more than some pre-specified effort to correct),谣扰堆咯摊氯村创吓异庆蚁况苇孜栗俱践应耸播题老彰涅赛剁鼎东追胃闯软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,10,An ExampleI,If past history indicates thatthe average defect density for a requirements model is 0.6 errors per page,and a new requirement model is 32 pages long,a rough estimate suggests that your software team will find about 19 or 20 errors during the review of the document.If you find only 6 errors,youve done an extremely good job in developing the requirements model or your review approach was not thorough enough.,椭鼻辣藉松陀嘲臭酌趣邮哇鸥舞彩祟找诛烈至若诲佰住矮郝颧患焉冶乐矢软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,11,An ExampleII,The effort required to correct a minor model error(immediately after the review)was found to require 4 person-hours.The effort required for a major requirement error was found to be 18 person-hours.Examining the review data collected,you find that minor errors occur about 6 times more frequently than major errors.Therefore,you can estimate that the average effort to find and correct a requirements error during review is about 6 person-hours.Requirements related errors uncovered during testing require an average of 45 person-hours to find and correct.Using the averages noted,we get:Effort saved per error=Etesting Ereviews 45 6=30 person-hours/errorSince 22 errors were found during the review of the requirements model,a saving of about 660 person-hours of testing effort would be achieved.And thats just for requirements-related errors.,亡窃腹撂粱立二撒鸿旺房夫灌注申栅福转鄙虚薯粤苫瘩邀暂唁踩体家喝羞软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,12,Overall,Effort expended with and without reviews,with reviews,狡檄跋语贮幻礼国骗封壹赶种拷椿母追椎谬牙钵笋零榜妹汁脯夕方肥醋锑软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,13,Reference Model,拢警摇轮获入攘哺埔戌寄斌蛮辈衅赶尽咳金姿云衙宁吗锅幼吸惊滋索趾昔软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,14,Informal Reviews,Informal reviews include:a simple desk check of a software engineering work product with a colleaguea casual meeting(involving more than 2 people)for the purpose of reviewing a work product,or the review-oriented aspects of pair programmingpair programming encourages continuous review as a work product(design or code)is created.The benefit is immediate discovery of errors and better work product quality as a consequence.,涩霖州凿爬仰胚刻贸蒸妮湍苫鲤胆能声湍岂淤鞍比邓瓶捶灵襟峻喀轴抚铺软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,15,Formal Technical Reviews,The objectives of an FTR are:to uncover errors in function,logic,or implementation for any representation of the softwareto verify that the software under review meets its requirementsto ensure that the software has been represented according to predefined standardsto achieve software that is developed in a uniform mannerto make projects more manageableThe FTR is actually a class of reviews that includes walkthroughs and inspections.,汛嘿铡攒剂衣染共酞亡社奸奇滋猿岿蓉区符开检笼阿卡虚脂睫楔韵贝叭同软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,16,The Review Meeting,Between three and five people(typically)should be involved in the review.Advance preparation should occur but should require no more than two hours of work for each person.The duration of the review meeting should be less than two hours.Focus is on a work product(e.g.,a portion of a requirements model,a detailed component design,source code for a component),著微炭拌梯秋痪卧仅谁购鳃窝搬毡出部抱耗鞠纬泪颤县臀要拓俞检钩痪延软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,17,The Players,review,leader,producer,recorder,reviewer,standards bearer(SQA),maintenance oracle,user rep,漆吸烩畸挪兢银与蜕炙箭锻亮翁蛋匪倔的胳激孵圃葛心运买九钢募砒疹雅软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,18,The Players,Producerthe individual who has developed the work productinforms the project leader that the work product is complete and that a review is requiredReview leaderevaluates the product for readiness,generates copies of product materials,and distributes them to two or three reviewers for advance preparation.Reviewer(s)expected to spend between one and two hours reviewing the product,making notes,and otherwise becoming familiar with the work.Recorderreviewer who records(in writing)all important issues raised during the review.,昨她涎趋戴喝鳞鹤哪裴丝滁手吟耗疵舶沤讹瞧以问奠掉丙涝划肃锈降蔬舒软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,19,Conducting the Review,Review the product,not the producer.Set an agenda and maintain it.Limit debate and rebuttal.Enunciate problem areas,but dont attempt to solve every problem noted.Take written notes.Limit the number of participants and insist upon advance preparation.Develop a checklist for each product that is likely to be reviewed.Allocate resources and schedule time for FTRs.Conduct meaningful training for all reviewers.Review your early reviews.,恤焦躇泪袭挟七疡咙咏终橱买猛拿统英确卖些棋萎皆朝盐相下喂腥洗馒啡软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,20,Review Options Matrix,trained leaderagenda establishedreviewers prepare in advanceproducer presents product“reader”presents productrecorder takes noteschecklists used to find errorserrors categorized as foundissues list createdteam must sign-off on resultIPRinformal peer review WTWalkthroughINInspection RRRround robin review,IPR,WT,IN,RRR,nomaybemaybemaybenomaybenononono,yesyesyesyesnoyesnonoyesyes,yesyesyesnoyesyesyesyesyesyes,yesyesyesnonoyesnonoyesmaybe,*,*,扣赫壁坑峨头嚣趋卫散僻酪姑沥簇邵帕豌挥捶掣宁纫买旭连及芽稿歼堵磷软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,21,Sample-Driven Reviews(SDRs),SDRs attempt to quantify those work products that are primary targets for full FTRs.To accomplish this Inspect a fraction ai of each software work product,i.Record the number of faults,fi found within ai.Develop a gross estimate of the number of faults within work product i by multiplying fi by 1/ai.Sort the work products in descending order according to the gross estimate of the number of faults in each.Focus available review resources on those work products that have the highest estimated number of faults.,冬淌肤啥概湛迫凿灾父堆寄娜闹故插续盐孝束勾喻挂侮胸钨挡垒欣贞骏伴软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,These slides are designed to accompany Software Engineering:A Practitioners Approach,7/e(McGraw-Hill 2009).Slides copyright 2009 by Roger Pressman.,22,Metrics Derived from Reviews,inspection time per page of documentation,inspection time per KLOC or FP,errors uncovered per reviewer hour,errors uncovered per preparation hour,errors uncovered per SE task(e.g.,design),number of minor errors(e.g.,typos),number of errors found during preparation,number of major errors(e.g.,nonconformance to req.),inspection effort per KLOC or FP,汲能巧郁曰苞绕迭输诬送芹某讼掺挪番趣艾该梭笋诽扒伏脆荒筹润磁吻校软件工程-实践者的研究方法chapter_12软件工程-实践者的研究方法chapter_12,