DOC PREVIEW
ODU CS 350 - Lecture Notes

This preview shows page 1-2-3-4-5 out of 14 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 14 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 14 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 14 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 14 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 14 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 14 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1CS 350: Introduction toSoftware EngineeringSlide Set 5Software QualityC. M. OverstreetOld Dominion UniversityFall 2005Lecture Topics What is quality? The economics of quality Defect-removal methods Design and code reviews Quality measures Review considerationsWhat is Quality? Basic definition: meeting the users’needs needs, not wants true functional needs are oftenunknowable There is a hierarchy of needs. Do the required tasks. Meet performance requirements. Be usable and convenient. Be economical and timely. Be dependable and reliable.2The PSP Quality Focus -1 To be useful, software must install quickly and easily run consistently properly handle normal and abnormal cases not do destructive or unexpected things be essentially bug-free Defects are not important to users, as longas they do not affect operations cause inconvenience cost time or money cause loss of confidence in the program’s resultsThe PSP Quality Focus -2 The defect content of software products mustbe managed before more important qualityissues can be addressed. Low defect content is an essentialprerequisite to a quality software process. Since low defect content can best beachieved where the defects are injected,engineers should remove their own defects determine the causes of their defects learn to prevent those defectsThe Economics of Quality Software is the only modern technology thatrelies on testing to manage quality. With common quality practices, software groupstypically spend 50+% of the schedule in test devote more than half their resources to fixing defects cannot predict when they will finish deliver poor-quality and over-cost products To manage cost and schedule, you must managequality. To get a quality product out of test, you mustput a quality product into test.3Fall 2005 CS 350/ODU 7Testing Alone is IneffectiveOverloadHardware failureOperatorerrorData errorResourcecontentionConfigurationSafe and secure region = tested (shaded)Unsafe and insecure region = untested(black)Removing Defects in Test When performing a task thousands oftimes, economics would suggest thatyou use the most efficient methods. A 50,000 LOC system with traditionaldevelopment methods would have 25+ defects/KLOC at test entry -1250 defects take 12,500+ programmer hours to test be late and over budget At the typical rate of 10+ hours per defect,this is 6 programmer years.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 KLOC4Defect-removal Methods -1 The principal ways to find and fixdefects are by compiling unit testing integration and system testing team inspections personal reviews Since you will likely have to removelots of defects, you should use themost efficient methods.Source: Xerox110100100010000Time in MinutesDesignReviewDesignInspect.CodeReviewCodeInspect.UnitTestSystemTestDefect-removal Phase522225321405Defect-removal TimesDefect-removal Methods -2 In a personal review you privately review your product your objective is to find and fix defectsbefore test Reviews are most effective when theyare structured and measured. Use reviews for requirements,designs, code, and everything elsethat you develop. Also continue to use inspections,compiling, and testing.5Defect-removal Rates -1 Even at the personal level, it is moreefficient to find defects in reviews thanin testing. Unit test finds only about 2 to 4 defects perhour. Unit test finds about 50% of the defects. Code reviews find about 6 to 10 defects perhour. Practiced reviewers can find 70% or moreof the defects before compiling or testing.Defect-removal Rates -2810 DevelopersWhy Reviews are Efficient In testing, you must detect unusual behavior figure out what the test program was doing find where the problem is in the program figure out which defect could cause such behavior This can take a lot of time. With reviews and inspections, you follow your own logic know where you are when you find a defect know what the program should do, but did not know why this is a defect are in a better position to devise a correct fix6Review Principles PSP reviews follow a defined process withguidelines, checklists, and standards. The PSP review goal is to find every defectbefore the first compile or test. To address this goal, you should review before compiling or testing use coding standards use design completeness criteria measure and improve your review process use a customized personal checklistThe Code Review Checklist Your reviews will be most effective when yourpersonal checklist is customized to your owndefect 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 thescreen. The checklist defines the review steps and thesuggested order for performing them. Review for one checklist item at a time. Check off each item as you complete it.Design Review Principles In addition to reviewing code, yourshould also review your designs. This requires that you produce designs that can be reviewed follow an explicit review strategy review the design in stages verify that the logic correctly implementsthe requirements7Reviewable Designs A reviewable design has a defined context precise representation consistent and clear structure This suggests that the design’s purpose and function be explicitlystated you have criteria for design completeness the design is structured in logical elementsThe Design Review Strategy Produce designs that can be reviewed instages. The suggested review stages are as follows.1. Review against the requirements to ensure thateach required functions is addressed by thedesign.2. Verify the overall program structure and flow.3. Check the logical constructs for correctness.4. Check for robustness, safety, and security.5. Check the function, method, and procedure callsto ensure proper use.6. Check special variables, parameters, types, andfiles for proper


View Full Document

ODU CS 350 - Lecture Notes

Download Lecture Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?