Copyright © 1994 Carnegie Mellon University1Disciplined SoftwareEngineeringLecture #7 Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 Sponsored by the U.S. Department of DefenseCopyright © 1994 Carnegie Mellon University2Design and Code Reviews -Overview What are design and code reviews? Why should you do them? The PSP•review strategy•review principles•review measures Review considerationsCopyright © 1994 Carnegie Mellon University3What are Reviews? A review is a way to personally examine yourown work. It is one of a family of methods•inspections•walkthroughs•reviews They all have the objective of finding and fixingproduct defects early in the developmentprocess.Copyright © 1994 Carnegie Mellon University4Inspections Inspections were introduced by Fagan at IBM in1976. Inspections follow a structured process•done by peers•managers do not attend•each participant has a defined role•preparation is required•objective is to find problems Inspections are useful for requirements,designs, code, test cases, plans, etc.Copyright © 1994 Carnegie Mellon University5Walkthroughs Walkthroughs typically follow a meeting format•developer leads the audience through theproduct•audience may include peers, managers, orother interested parties•objective is to communicate or obtainapproval•no preparation is required Walkthroughs are most useful for requirementsand system design issues.Copyright © 1994 Carnegie Mellon University6Reviews In a personal review•professional privately reviews his/her product•objective is to find defects before the firstcompile and test•reviews are most effective when structuredand measured Reviews can be used for requirements, designs,and code.Copyright © 1994 Carnegie Mellon University7Why Do Reviews? - 1 Data show that it is much more efficient to finddefects in reviews than in testing•in unit test, typically only about 2 to 4 defectsare found per hour•code reviews typically find about 10 defectsper hour•experienced reviewers can find 70% or moreof the defects in a product•unit test rarely exceeds a 50% yield PSP data show that reviews find 2 to 5 times asmany defects per hour as unit testCopyright © 1994 Carnegie Mellon University8Defect Removal Rates - 12StudentsProgram Number051015202512345678910CompileCode ReviewUnit TestCopyright © 1994 Carnegie Mellon University9Why Do Reviews? - 2 After unit test, defect removal becomes muchmore expensive•in integration and system test it takes 10 to 40programmer hours to find and fix each defect•inspections typically take less than an hourper defect Some inspection data•O’Neil: 80-90% yield at 25 minutes/defect•Philips: 15 minutes/defect versus 8 hours intestCopyright © 1994 Carnegie Mellon University10Why Do Reviews? - 3 The reason to eliminate defects as early aspossible is because•every review, inspection, compile, and testfinds only a fraction of the defects•thus, the cleaner the code entering a phase,the cleaner it will be on exit. Early defect removal saves time and money•defects cost more to find and fix later in thedevelopment process•defects cost much more to find and fix afterdevelopment completionCopyright © 1994 Carnegie Mellon University11Why Reviews are Efficient - 1 In testing•you start with a problem•then you must find the bug•next, you devise a fix•finally, you implement and test the fix With reviews and inspections•you see the defect•then you devise a fix•finally, you implement and review the fixCopyright © 1994 Carnegie Mellon University12Why Reviews are Efficient - 2 In testing, it the system produces an unusualresult, then you must•detect that it was unusual•figure out what the test program was doing•find where it was in your program•figure out what defect could cause suchbehavior You are searching for the unplanned andunexpected. This can take a lot of timeCopyright © 1994 Carnegie Mellon University13Why Reviews are Efficient - 3 With reviews and inspections•you follow your own logic•when you find a defect, you know exactlywhere you are•you know what the program should do and didnot do•you thus know why this is a defect•you are therefore in a better position to devisea complete and effective fixCopyright © 1994 Carnegie Mellon University14The PSP Review Strategy The PSP objective is to produce the highestpossible program quality at every processphase The review strategy to achieve this is to•gather data on your reviews•study these data•decide what works best for you•adjust your process accordingly This is a continuous learning process usingdata on your own work.Copyright © 1994 Carnegie Mellon University15Review Principles PSP reviews follow a disciplined process with•entry and exit criteria•a review structure•guidelines, checklists, and standards The suggested PSP review goal is to find everydefect before the first compile or test. To address this goal, you should•use coding standards•use design completeness criteria•measure and improve your review processCopyright © 1994 Carnegie Mellon University16Design Review Principles Produce designs that can be reviewed. Follow an explicit review strategy. Review the design in stages. Verify that the logic correctly implements therequirements.Copyright © 1994 Carnegie Mellon University17Produce Designs that can beReviewed A reviewable design has•a defined context•a precise representation•a consistent and clear structure This suggests that•the design’s purpose and function beexplicitly stated•you have criteria for design completeness•the design is structured in logical elementsCopyright © 1994 Carnegie Mellon University18Follow a Review Strategy The review strategy specifies the order in whichyou review the design elements.•this depends on the product structure•the review strategy should thus be consideredduring design The objective should be to produce a designthat can be•reviewed in stages•tested in stages•integrated in stagesCopyright © 1994 Carnegie Mellon University19Review the Design in Stages By reviewing in stages, you ensure that allselected topics are carefully checked.Suggested review stages are 1. check that all elements have been designed 2. verify overall program structure and flow 3. check the logical constructs for correctness 4. check for robustness 5. check the function, method, and procedure calls to ensure proper use 6. check special
View Full Document
Unlocking...