1CS 350, slide set 9M. OverstreetOld Dominion UniversitySpring 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 review someone else's work to identify: defects problems The purpose is NOT to fix, just to identify. Fixing too often becomes a distraction from inspecting. Can be used for almost any items produced in software development Requirements, test designs, HLD, DLD, test data, user manuals, ... .Inspection phases Briefing Often developer of item brings inspectors up to speed Review Must be done before meeting, so inspectors are prepared Meeting The formal review process Repair Done after meeting More effective if done with a scriptWhy are inspections effective? - 1 Reviewing decisions so you can be ready to explain them helps you improve your decisions Figuring out how to explain your work to someone else often helps you discovers problems in it.3Effective? - 2 Use collective knowledge The group often has a broader experience base than the developer alone; some may know what the common problems are Helps if inspectors can look at product from points of view:• Use, tester, coder, designer, ... . Can give opportunity to look at entire item at once Testing (the alternative) tends to looks only at details – one test case at a timeOther observations Testing is still needed even when inspections 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 from checklists. Checklists should be developed over time Most of use tend to make the same kinds of errors repeatedly Should be personal checklists4Inspection rates for preparation: guidelines only Requirements: fewer than 2 pages/hr. High level design: fewer that 5 pages/hr. Detailed design: fewer than 100 pseudocode 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 and inspectors Plan to spend about 50% of design time in inspectionInspection yield High inspection yield saves time Humphrey reports on Air Force project where with the use of inspections, testing time went from 22% of development schedule to 2.7%5Announcements Group assignments made Sent to UNIX accounts Let me know of problems, particularly contacting ALL members What’s due from groups: Group suggestion of what modules to implement• E-mail to cmo. Sent by Team Leader• Due by midnight Saturday. Goals (individual, group)•Due Tuesday midnight Weekly Reports.• Submitted once per week, starting this week• First due Monday by midnightTesting Concepts Review - 1 It a lot of work and can easily take more time, creativity than coding! NASA build a simulator 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 a correct 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 in the file. The test driver produces a report Note: code to be tested can fail in lots of ways besides getting wrong answers!• May not compile, may not like, may loop, may abort so that 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 driver3. A collection of reports, one report for each test case• Some generated by the test driver, some written by the tester6Test 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?Consider building a testing tool For cp, a correct version packs data into a packet on byte boundaries You give cp data, then check to see if cp puts the right stuff in the right place. Checking isn’t easy because of the packing. Consider using a version testalias.cpp to help build test data For example, give it a double, then let it print the corresponding 4 shorts.• Sometimes the corresponding 6 shorts! Depends on byte boundaries used by the double. How could this help build test data? Point:• Does this save you time?• Does this improve your testing?Traditional inspection roles Developer of item (code, test plan, requirements, user doc) – present to answer questions Presenter – present items being inspected, line by line Inspectors, usually at least two – the come prepared with a list of defects that they identify when presenter gets there Recording – takes notes, follows up Moderator – decides of inspectors are prepared, runs meeting, controls behavior7Typical Time script 1 week before inspection, developer briefs inspectors, providing them a complete set of items to be inspected Inspection should go no longer than 2 hours Moderator must stop inspection if inspectors are not prepared Follow-up options: If simple, left to recorder to sign off that all defects have be removed If not, may need to schedule a follow-up meetingFor TSP Follow inspection script in text (outline below) Use forms provided Use smaller group, maybe only 3 or 4 people with moderator covering role of presenter and recorder alsoEstimating yield with 2 inspectors 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)82 inspector report - 175.0760 153 29812 741.7380 68 3355 4 Sue58.3380 85 268 7 3GeorgeEst. YieldPrep TimeSize Time RateDefects Major MinorNameSent to moderator; prepared before inspectionInspection form - 24 2Unique
View Full Document