CS 350: Introduction to Software EngineeringLecture TopicsWhat is Quality?The PSP Quality Focus -1The PSP Quality Focus -2The Economics of QualityTesting Alone is IneffectiveRemoving Defects in TestQuality and ProductivityDefect-removal Methods -1Defect-removal TimesDefect-removal Methods -2Defect-removal Rates -1Slide 14Why Reviews are EfficientReview PrinciplesThe Code Review ChecklistDesign Review PrinciplesReviewable DesignsThe Design Review StrategyQuality MeasuresPhase YieldYield EstimatesPotential Control ParametersSlide 25Yield versus Review Rate -3Defect Removal Leverage (DRL)Cost of Quality (COQ) -1Cost of Quality (COQ) -2Cost of Quality (COQ) -3Review ConsiderationsReviewing Before CompileSlide 33Slide 34Reviews and InspectionsDefect PreventionDefect Prevention Strategy -1Defect Prevention Strategy -2Messages to RememberCS 350: Introduction toSoftware EngineeringSlide Set 5Software QualityC. M. OverstreetOld Dominion UniversityFall 2005Fall 2005 CS 350/ODULecture Topics What is quality?The economics of qualityDefect-removal methodsDesign and code reviewsQuality measuresReview considerationsFall 2005 CS 350/ODUWhat is Quality? Basic definition: meeting the users’ needsneeds, not wantstrue functional needs are often unknowableThere is a hierarchy of needs.Do the required tasks.Meet performance requirements.Be usable and convenient.Be economical and timely.Be dependable and reliable.Fall 2005 CS 350/ODUThe PSP Quality Focus -1To be useful, software must install quickly and easilyrun consistentlyproperly handle normal and abnormal casesnot do destructive or unexpected thingsbe essentially bug-freeDefects are not important to users, as long as they do notaffect operationscause inconveniencecost time or moneycause loss of confidence in the program’s resultsFall 2005 CS 350/ODUThe PSP Quality Focus -2The defect content of software products must be managed before more important quality issues can be addressed.Low defect content is an essential prerequisite to a quality software process.Since low defect content can best be achieved where the defects are injected, engineers shouldremove their own defectsdetermine the causes of their defectslearn to prevent those defectsFall 2005 CS 350/ODUThe Economics of QualitySoftware is the only modern technology that relies on testing to manage quality.With common quality practices, software groups typicallyspend 50+% of the schedule in testdevote more than half their resources to fixing defectscannot predict when they will finishdeliver poor-quality and over-cost productsTo manage cost and schedule, you must manage quality. To get a quality product out of test, you must put a quality product into test.Fall 2005 CS 350/ODU 7Testing Alone is IneffectiveOverloadHardware failureOperatorerrorData errorResourcecontentionConfigurationSafe and secure region = tested (shaded)Unsafe and insecure region = untested(black)Fall 2005 CS 350/ODURemoving Defects in TestWhen performing a task thousands of times, economics would suggest that you use the most efficient methods.A 50,000 LOC system with traditional development methods wouldhave 25+ defects/KLOC at test entry - 1250 defectstake 12,500+ programmer hours to testbe late and over budgetAt the typical rate of 10+ hours per defect, this is 6 programmer years.Fall 2005 CS 350/ODU 9Quality and Productivity100 developers40 hours x 50 weeks200,000 hours50% test time = 100,000 hours in testManaged quality = 60% increased team productivityCurrent MethodsManaged Quality100,000 for development2 LOC/hour = 200 KLOC20% test time = 40,000 hours of test160,000 for development2 LOC/hour = 320 KLOCFall 2005 CS 350/ODUDefect-removal Methods -1The principal ways to find and fix defects are by compilingunit testingintegration and system testingteam inspectionspersonal reviewsSince you will likely have to remove lots of defects, you should use the most efficient methods.Fall 2005 CS 350/ODUSource: Xerox110100100010000Time in MinutesDesignReviewDesignInspect.CodeReviewCodeInspect.UnitTestSystemTestDefect-removal Phase522225321405Defect-removal TimesFall 2005 CS 350/ODUDefect-removal Methods -2In a personal reviewyou privately review your productyour objective is to find and fix defects before testReviews are most effective when they are structured and measured.Use reviews for requirements, designs, code, and everything else that you develop.Also continue to use inspections, compiling, and testing.Fall 2005 CS 350/ODUDefect-removal Rates -1 Even at the personal level, it is more efficient to find defects in reviews than in testing.Unit test finds only about 2 to 4 defects per hour.Unit test finds about 50% of the defects.Code reviews find about 6 to 10 defects per hour.Practiced reviewers can find 70% or more of the defects before compiling or testing.Fall 2005 CS 350/ODUDefect-removal Rates -20510152025301 2 3 4 5 6 7 8 9 10Program NumberDefects Removed per HourCompileCRDLDRTest810 DevelopersFall 2005 CS 350/ODUWhy Reviews are EfficientIn testing, you must detect unusual behaviorfigure out what the test program was doingfind where the problem is in the programfigure out which defect could cause such behaviorThis can take a lot of time.With reviews and inspections, you follow your own logicknow where you are when you find a defectknow what the program should do, but did not know why this is a defectare in a better position to devise a correct fixFall 2005 CS 350/ODUReview PrinciplesPSP reviews follow a defined process with guidelines, checklists, and standards.The PSP review goal is to find every defect before the first compile or test.To address this goal, you shouldreview before compiling or testinguse coding standardsuse design completeness criteriameasure and improve your review processuse a customized personal checklistFall 2005 CS 350/ODUThe Code Review ChecklistYour reviews will be most effective when your personal checklist is customized to your own defect experience.Use your own data to select the checklist items.Gather and analyze data on the reviews.Adjust the checklist with experience.Do the reviews on a printed listing, not on the screen.The checklist defines the review steps and the suggested order for performing them. Review for one
View Full Document