DOC PREVIEW
ODU CS 350 - Lecture Notes

This preview shows page 1-2-3 out of 10 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 10 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 10 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 10 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 10 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1CS 350 slide set 8M. OverstreetOld Dominion UniversityFall 2005Reading Appendix C: Software InspectionsOutline What are inspections? What makes inspections effective? Inspection methods Inspection data The inspection report: from INS2What are inspections? Two or more programmers reviewsomeone else's work to identify: defects problems The purpose is NOT to fix, just to identify. Fixing too often becomes a distraction frominspecting. Can be used for almost any itemsproduced in software development Requirements, test designs, HLD, DLD, testdata, user manuals, ... .Inspection phases Briefing Often developer of item brings inspectors upto speed Review Must be done before meeting, so inspectorsare prepared Meeting The formal review process Repair Done after meeting More effective if done with a scriptWhy are inspectionseffective? - 1 Reviewing decisions so you can beready to explain them helps youimprove your decisions Figuring out how to explain yourwork to someone else often helpsyou discovers problems in it.3Effective? - 2 Use collective knowledge The group often has a broader experiencebase than the developer alone; some mayknow what the common problems are Helps if inspectors can look at product frompoints of view:• Use, tester, coder, designer, ... . Can give opportunity to look at entireitem at once Testing (the alternative) tends to looks only atdetails – one test case at a timeOther observations Testing is still needed even wheninspections are conducted effectively Only inspect reviewed products Respect time of other people Trivial errors can distract from serious,perhaps subtle, flaws Saves embarrassmentChecklists For this kind of detailed activities,most of us work better fromchecklists. Checklists should be developed overtime Most of use tend to make the samekinds of errors repeatedly Should be personal checklists4Inspection rates forpreparation: guidelines only Requirements: fewer than 2 pages/hr. High level design: fewer that 5 pages/hr. Detailed design: fewer than 100pseudocode lines/hr Code: fewer than 200 loc/hr All of these are probably optimisticAssumes you're shooting for an A rather than a CMore rates: These things vary a lot; Depends on complexity of product Experience of developers andinspectors Plan to spend about 50% of designtime in inspectionInspection yield High inspection yield saves time Humphrey reports on Air Forceproject where with the use ofinspections, testing time went from22% of development schedule to2.7%5Testing Concepts Review - 1 It a lot of work and can easily take more time,creativity than coding! NASA builds simulators to plug the code into Concept (other approaches are sometimes better): Each module uses inputs to produce outputs The tester makes up inputs and determines the outputs acorrect program should produce from them.• This can be very difficult! The tester prepares a file of inputs and expected outputsTesting Concepts - 2 A test driver feeds the file inputs to a module,then compares the module’s output with those inthe file. The test driver produces a report Note: code to be tested can fail in lots of waysbesides getting wrong answers! May not compile, may not like, may loop, may abort sothat no run report is produced by the test driver. So after you’ve completed testing, you have:1. Files of test cases, perhaps many2. Code for a test driver & (if needed) several stubs3. A collection of reports, one report for each test case• Some generated by the test driver, some written by thetesterTest Concepts - 3 Problems: How do you know what to test?• Requirements coverage• Programming experience• Special cases• Extremes• Critical functionality How do you create expected outputs?6Traditional inspection roles—non-TSP version Developer of item (code, test plan,requirements, user doc) – present toanswer questions Presenter – present items beinginspected, line by line Inspectors, usually at least two – thecome prepared with a list of defects thatthey identify when presenter gets there Recording – takes notes, follows up Moderator – decides of inspectors areprepared, runs meeting, controls behaviorTypical Time script 1 week before inspection, developerbriefs inspectors, providing them acomplete set of items to be inspected Inspection should go no longer than 2hours Moderator must stop inspection ifinspectors are not prepared Follow-up options: If simple, left to recorder to sign off that alldefects have be removed If not, may need to schedule a follow-upmeetingFor TSP Follow inspection script in text(outline below) Use forms provided Use smaller group, maybe only 3 or4 people with moderator coveringrole of presenter and recorder also7Estimating yield with 2inspectors A: number of defects found by ins. 1 B: number of defects found by ins. 2 C: number of defects found by both Estimated defects: A×B/C Found defects: A+B-C Est. remaining: A×B/C-(A+B-C) Yield: [100(A+B-C)×C]/(A×B)2 inspector report - 1 75.0 760 153 298 12 7 41.7 380 68 335 5 4Sue 58.3 380 85 268 7 3GeorgeEst.YieldPrep TimeSize Time RateDefectsMajor MinorNameSent to moderator; prepared before inspectionInspection form - 2 4 2Unique defects 7 5 9Tot... ... 1 1 1N = 1000 19 1 1Test not dcl 13 1 1Converter 12 1 1.=>; 9 1 1}=>) 1 Inspectors (finding maj defects) A BDefectsMaj MinDefect Des.No.Completed during inspection by moderator8Computations From previous slides: A = 7 (for George) B = 5 (for Sue) C = 3 (found by both) Est. Defects: (5 x 7)/ 3 or 12 Yield is Found/Est. or 9/12 George’s yield: 7/12 Sue’s yield: 5/12Inspection form - 3Inspection summary Product size 380 Size measure LOCTotal defects for A: 7 Total defects for B: 5 Common 3Total defects (AB/C) 12 Number found(A+B-C) 9 Number left 3Meeting time: 43 Total inspection hrs 4.7 Overall rate 80.9Mechanics - 1 The person who has completed theproduct arranges the inspection The moderator is the quality/processmanager Moderator assess readiness of product forthe inspection Min group size to do this is 3:


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?